Re: [bess] rfc9251

["Mankamana Mishra (mankamis)" <[e-mail]>]

Hi Shasha

Proxy querier behavior expects implementation to generate IGMP join locally on LAN after getting SMET joins. IP address depends on implementation. It can pick IP address from IRB or internal querier configuration.

Is there any specific case that has issue?

Mankamana

From: Alexander Vainshtein <[e-mail]>
Date: Sunday, March 17, 2024 at 5:27 AM
To: Ali Sajassi (sajassi) <[e-mail]>, Samir Thoria (sthoria) <[e-mail]>, John E Drake <jdrake=[e-mail]>, Mankamana Mishra (mankamis) <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: RE: rfc9251
Hi all,
Yet another question related to RFC 9251.

Section 4.2 of RFC 9251<https://datatracker.ietf.org/doc/html/rfc9251#section-4.2> says:


As mentioned in the previous sections, each PE MUST have proxy querier functionality for the following reasons:

  1.  to enable the collection of EVPN PEs providing Layer 2 Virtual Private Network (L2VPN) service to act as a distributed multicast router with an anycast IP address for all attached hosts in that subnet
  2.  to enable suppression of IGMP Membership Reports and Membership Queries over MPLS/IP core

I wonder whether Source IP address of the queries mentioned above is presumed to be an IP address of an anycast EVPN IRB as defined in RFC 9135,  and, if yes, is this EVPN IRB assumed to be Symmetric or Asymmetric.

Regards, and lots of thanks in advance,
Sasha

From: Alexander Vainshtein
Sent: Sunday, March 17, 2024 2:06 PM
To: Ali Sajassi (sajassi) <[e-mail]>; Samir Thoria (sthoria) <[e-mail]>; John E Drake <jdrake=[e-mail]>; '[e-mail]' <[e-mail]>; [e-mail]
Cc: '[e-mail]' <[e-mail]>
Subject: RE: rfc9251

Hi all,
Re-sending to the authors since the address : [e-mail]<mailto:[e-mail]> is invalid.

Regards,
Sasha

From: Alexander Vainshtein
Sent: Sunday, March 17, 2024 2:01 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: rfc9251

Hi all,
I have a question regarding expected DP behavior in conjunction with RFC 9521: Are the PEs that support this RFC expected to decrement TTL in IP headers of multicast IP packets they forward?

This question is equally applicable to the “last mile” PEs that have received IGMP/MLD Joins and advertised them as SMET routes, and to the “first mile” PEs that receive and install these SMET routes.

The context for this question is my understanding that multicast IP traffic that is forwarded based on IMET route (e.g., to the PEs that have not advertised ability to advertise SMET routes)   does not undergo TTL decrement.

I have failed to find an answer to my question in the text of RFC 9251.

Your timely feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha



Disclaimer

This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.