Add VLAN-aware MLD Snooping support

[AnandhiDhanabalan]

Adds VLAN-level MLD snooping support to SAI by introducing SAI_VLAN_ATTR_MLD_SNOOPING_ENABLE. This enables independent control of IPv6 multicast (MLD) snooping alongside existing IGMP (IPv4) snooping.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[kcudnik]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[AnandhiDhanabalan]

@kcudnik , This PR also has enum alias added. The failure seems to be related to this. Can you help fix it ?

  SAI_VLAN_ATTR_IGMP_SNOOPING_ENABLE,

    /** @ignore - for backward compatibility */
    SAI_VLAN_ATTR_CUSTOM_IGMP_SNOOPING_ENABLE = SAI_VLAN_ATTR_IGMP_SNOOPING_ENABLE,

[kcudnik]

squash commits and force push

[AnandhiDhanabalan]

@tjchadaga could you please assign a reviewer for this PR

[kcudnik]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[AnandhiDhanabalan]

@kcudnik, the failure appears to be due to the enum alias usage. Should I take any action on this, or will you be handling it? Please advice.

**2026-08-07T17:46:29.4352920Z WARNING: Both enums have the same value SAI_VLAN_ATTR_IGMP_SNOOPING_ENABLE and SAI_VLAN_ATTR_CUSTOM_IGMP_SNOOPING_ENABLE = 0x00000014**
2026-08-07T17:46:29.4353576Z processing commit 9611265
2026-08-07T17:46:29.4353918Z ERROR: please correct all 0 error(s) and all 1 warnings before continue
2026-08-07T17:46:29.4354361Z make: *** [Makefile:89: all] Error 1
2026-08-07T17:46:29.4367116Z 
2026-08-07T17:46:29.4409303Z ##[error]Bash exited with code '2'.
2026-08-07T17:46:29.4538788Z ##[section]Finishing: Metadata check

[kcudnik]

i think problem is taht SAI_VLAN_ATTR_CUSTOM_IGMP_SNOOPING_ENABLE is ignored, which is legitimate enum in previous commits, make @ignore enum you are adding, and assign it by SAI_VLAN_ATTR_CUSTOM_IGMP_SNOOPING_ENABLE

 /** @ignore - for backward compatibility */
    SAI_VLAN_ATTR_IGMP_SNOOPING_ENABLE = SAI_VLAN_ATTR_CUSTOM_IGMP_SNOOPING_ENABLE

you will need to squash commits and force push, check locally before you do that ,

[AnandhiDhanabalan]

@kcudnik, just to confirm my understanding: with the following definition, SAI_VLAN_ATTR_IGMP_SNOOPING_ENABLE is the enum being marked as @ignore, correct?

/** @ignore - for backward compatibility */
   SAI_VLAN_ATTR_IGMP_SNOOPING_ENABLE = SAI_VLAN_ATTR_CUSTOM_IGMP_SNOOPING_ENABLE 

In my case, SAI_VLAN_ATTR_CUSTOM_IGMP_SNOOPING_ENABLE is the existing attribute that I want to deprecate/ignore, while SAI_VLAN_ATTR_IGMP_SNOOPING_ENABLE is the new attribute. My understanding from the existing @ignore usage is that the @ignore annotation should be placed on the enum that needs to be deprecated. Could you please confirm the intended definition?

[kcudnik]

no, @ignore is placed on attribute that have the same enum ID as other exdisting attribute, if you have both wih the same value, none of them can be depreacated

[AnandhiDhanabalan]

@kcudnik , I’m seeing the same meta error irrespective of how the enum is defined. Capturing the error below:

WARNING: Both enums have the same value SAI_VLAN_ATTR_IGMP_SNOOPING_ENABLE and SAI_VLAN_ATTR_CUSTOM_IGMP_SNOOPING_ENABLE = 0x00000014
ERROR: please correct all 0 error(s) and all 1 warnings before continue
make: *** [Makefile:89: all] Error 1

Tried both variants:

    /**
     * @brief IGMP Snooping enable or disable control for VLAN
     *
     * IGMP Snooping enable control for VLAN. Default is
     * disabled
     *
     * @type bool
     * @flags CREATE_AND_SET
     * @default false
     */
    SAI_VLAN_ATTR_IGMP_SNOOPING_ENABLE,

    /** @ignore - for backward compatibility */
    SAI_VLAN_ATTR_CUSTOM_IGMP_SNOOPING_ENABLE = SAI_VLAN_ATTR_IGMP_SNOOPING_ENABLE,

and

    /**
     * @brief IGMP Snooping enable or disable control for VLAN
     *
     * IGMP Snooping enable control for VLAN. Default is
     * disabled
     *
     * @type bool
     * @flags CREATE_AND_SET
     * @default false
     */
    SAI_VLAN_ATTR_CUSTOM_IGMP_SNOOPING_ENABLE,

    /** @ignore - for backward compatibility */
    SAI_VLAN_ATTR_IGMP_SNOOPING_ENABLE = SAI_VLAN_ATTR_CUSTOM_IGMP_SNOOPING_ENABLE,

In both cases, meta flags duplicate enum values.

I also noticed similar @ignore usage is already present (e.g. in sainexthopgroup.h):

typedef enum _sai_next_hop_group_type_t
{
    /** Next hop group is ECMP, with a dynamic number of members, unordered */
    SAI_NEXT_HOP_GROUP_TYPE_DYNAMIC_UNORDERED_ECMP,

    /** @ignore - for backward compatibility */
    SAI_NEXT_HOP_GROUP_TYPE_ECMP = SAI_NEXT_HOP_GROUP_TYPE_DYNAMIC_UNORDERED_ECMP,

Could you please confirm:

• whether enum aliasing like this is still allowed for new additions, or
• if meta checks have been tightened and we should avoid introducing aliases?

If aliases are not allowed, I’ll retain only SAI_VLAN_ATTR_CUSTOM_IGMP_SNOOPING_ENABLE and avoid adding the new name. Please advise what’s the preferred approach.

[AnandhiDhanabalan]

@kcudnik , Gentle reminder — awaiting your inputs.

[kcudnik]

I don't remember exact conditions, @ignore was added specifically for this purpose, please analyse the parse metadata code to see which line generates that error, and make sure your commit is on top of master, if you are behind master, or you have multiple commits in the PR that go back and forth for same enum then this problem will happen,

please also consider using git blame to check how other ignore was indroduced such as #655

also as friendly reminder, im just doing community service here, and i don't have always time to take a look at everything what is happening on this repo

[AnandhiDhanabalan]

@kcudnik , Thanks for the guidance — the issue was in the metadata ancestry handling.

The fix is applied in BuildCommitHistory (ancestry.pl), where @ignore enums were not being properly respected during history reconstruction, causing the duplicate-value warning for the alias (SAI_VLAN_ATTR_CUSTOM_IGMP_SNOOPING_ENABLE).
Do review and approve the change

Validation
Rebased on latest master
make -C meta passes cleanly (no warnings/errors)
Verified behavior with alias enums

as friendly reminder, im just doing community service here, and i don't have always time to take a look at everything what is happening on this repo
Thanks for your time and continued support to the SAI community—it’s really appreciated.

[kcudnik]

@AnandhiDhanabalan here you go kcudnik@9e6d4e8

this is only commit you need on master, and you don't need to touch ancestry.pl, it works you can cherrypick it and rebase on master in your branch

[AnandhiDhanabalan]

@kcudnik, although the code below is syntactically valid, it is semantically incorrect. It implies that SAI_VLAN_ATTR_IGMP_SNOOPING_ENABLE is to be ignored, whereas in reality SAI_VLAN_ATTR_CUSTOM_IGMP_SNOOPING_ENABLE should be ignored.

    SAI_VLAN_ATTR_CUSTOM_IGMP_SNOOPING_ENABLE,

    /** @ignore - for backward compatibility */
    SAI_VLAN_ATTR_IGMP_SNOOPING_ENABLE = SAI_VLAN_ATTR_CUSTOM_IGMP_SNOOPING_ENABLE,

I still feel ancestry.pl may need to be revisited to handle @ignore correctly. However, given the current release timeline, I will drop the changes related to SAI_VLAN_ATTR_CUSTOM_IGMP_SNOOPING_ENABLE for now and take this up separately later.

I’ll update my PR accordingly and keep you posted.

[kcudnik]

For me it seems like those values shuld not be equal to eachother, still everything is fine even in this configuration, ignore attribute is introduce just to not cause confusion for metadata parser, still values, parser, serialization and deserialization will work correctly, in your approach you are removeing item that was introduced at the beginning, which is not ok, and making this or ancestry will require some more complex re-work.

note that ancestry.pl is using history file which only uses history and ignored values is not saved in %HISTORY hash, bneacuse it don't need to be, only latest one from commit are validated, and by adding ignored to existing value, and then introducing new one, will always result in error that both values have the same value, since previous walue will be always in HISTORY hash, ignored values are not.

as said this change will require some more complex rework, to not break existing logic, in your previous attempt you used undefinded values to compare which resulted in bad logic causing errors, thats unfortunate mistake :/

[kcudnik]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[AnandhiDhanabalan]

@tjchadaga can you approve this PR ?

[kcudnik]

please add meaningful description

[AnandhiDhanabalan]

please add meaningful description

Done

[AnandhiDhanabalan]

@tjchadaga can you approve this PR ?