Thanks Jorge, let me know if this answers your question. Or you have some open questions.
From: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> Date: Monday, March 10, 2025 at 5:02 AM To: Nitsan Dolev <Nitsan.Dolev=40rbbn....@dmarc.ietf.org>, bess@ietf.org <bess@ietf.org>, Ali Sajassi (sajassi) <saja...@cisco.com>, Samir Thoria (sthoria) <stho...@cisco.com>, Mankamana Mishra (mankamis) <manka...@cisco.com>, ke...@arrcus.com <ke...@arrcus.com> Subject: Re: Proposed changes rfc9251bis draft Hi Nitsan, About the first issue, I don’t think the text excludes single-homed CEs, if you interpret Ethernet Segment as a per RFC7432 (or rfc7432bis): https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-10#section-3 “Ethernet Segment (ES): When a customer site (device or network) is connected to one or more PEs via a set of Ethernet links, then that set of links is referred to as an 'Ethernet segment'.” So an ES also include single-homed CEs. About the second issue, I see where you are coming from, and these are my comments in case they help: * The text is written saying that the DF sends the SMET route, but I don’t think there is normative text saying that “ONLY the DF” MUST send the SMET route. * In many cases, when multiple multihomed ESes are connected to the same group of PEs, different PEs may be elected as the Designated Forwarder (DF) for each ES. So the end result is that you may well see all the PEs sending SMET routes if there are receivers in all the ESes, because each PE is DF for at least one ES. * In general, the decision of sending an SMET from all PEs in the ES is a trade-off between bandwidth consumed in the network and convergence upon failure on the DF. If your implementation decides to send SMET routes from all the PEs to optimize the latter, this will not cause any interop issue. In fact, in the implementations that I know the best, that’s what we do by default. My two cents. Thanks. Jorge From: Nitsan Dolev <Nitsan.Dolev=40rbbn....@dmarc.ietf.org> Date: Monday, March 10, 2025 at 4:08 AM To: bess@ietf.org <bess@ietf.org>, saja...@cisco.com <saja...@cisco.com>, stho...@cisco.com <stho...@cisco.com>, manka...@cisco.com <manka...@cisco.com>, ke...@arrcus.com <ke...@arrcus.com> Subject: [bess] Proposed changes rfc9251bis draft You don't often get email from nitsan.dolev=40rbbn....@dmarc.ietf.org. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Dear co-authors, Your help with the following two issues in rfc9251 will be most appreciated: Both issues refer to section 6.1 'Local IGMP/MLD membership Report Synchronization': Firstly, I would like to propose a fix in a sub-section that describe the PE actions upon reception of a withdrawal of an IGMP Membership Report Synch route from another PE. This sub-section has the following sentence: " If the DF no longer has the IGMP Membership Request (x,G) state for that BD on any ES for which it is the DF, it MUST withdraw its SMET route for that (x,G) group in that BD." This sentence seems to ignore the possibility that the related PE may have also received an IGMP Report (x,G) message from an AC or PW VES that is connected to a single homed CE (for which case DF is not relevant), in which case this PE will still have an IGMP Membership Request (x,G) state, and therefore will still have to advertise the SMET Route for the related (x,G). IMHO, this sentence shall be fixed to explicitly explain that the SMET Route shall be withdrawn ONLY if IGMP report (x,G) was NOT received from any MH or SH CE. The second issue refers to the advertisement of SMET (x,G) route ONLY by the MH-ES DF upon the creation of IGMP Membership Request (x,G) state; In this RFC only the DF of the related multihomed ES advertises the (x,G) SMET Route. Which means that only the DF will receive the related (x,G) traffic (Assuming no other MH-ES mate PE has another AC/PW from which related IGMP Report (x,G) was received). However, in case of failure of the related MH-ES AC on the DF or in case of failure of the PE that is elected as DF, we will have packet loss until he following procedures are completed: DF election The advertisement of SMET (x,G) Route by the newly elected DF then wait for the remote PE, behind which the source resides, to process the above routes and send the traffic to the newly elected DF. This might cause high traffic loss for the related (x,G) traffic. I wander, can we assume that the related Multihomed Ethernet Segment BDF mate PE also advertise a related SMET route (x,G) and receive the related (x,G) traffic but forward it to the related AC when it becomes DF? This might shorten the packet loss in case of DF failure quite significantly. Looking forward to your response, Nitsan Dolev Ribbon Comunication 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.
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
