Hi Jorge, Thanks for your clear response.
I can’t help thinking in terms of RFC7432bis with BDF when I think about rfc9251bis changes such as the below. This raises my following procedural question: Since both RFC9251bis and RFC7432bis are on the BESS WG table, and assuming both express the group consensus, aren’t we supposed to somehow coordinate such "improvement" issues? e.g. add this reference to RFC7432bis BDF solution in rfc9251bis. I guess that assuming rfc7432bis is firstly embraced by the BESS WG, only then we can consider the addition of such BDF based high availability solution to the rfc9251bis draft. (or vice versa) Thanks again, Nitsan From: Jorge Rabadan (Nokia) <jorge.rabadan=40nokia....@dmarc.ietf.org> Sent: Wednesday, March 12, 2025 8:39 PM To: Nitsan Dolev <nitsan.do...@rbbn.com>; bess@ietf.org; saja...@cisco.com; stho...@cisco.com; manka...@cisco.com; ke...@arrcus.com; Alexander Vainshtein <alexander.vainsht...@rbbn.com> Cc: Roger David <roger.da...@rbbn.com>; Michael Gorokhovsky <michael.gorokhov...@rbbn.com> Subject: [EXTERNAL] Re: Proposed changes rfc9251bis draft Hi Nitsan, Sure, I think a sentence could be added to say that non-DFs may optionally send the SMET routes. We can discuss among the co-authors and suggest something. Note that the concept of a Backup Designated Forwarder (BDF) is not defined in RFC7432, it is only in rfc7432bis. Only implementations compliant with rfc7432bis can advertise the SMET from both the DF and BDF while excluding other non-DF nodes. Thanks. Jorge From: Nitsan Dolev <Nitsan.Dolev=40rbbn....@dmarc.ietf.org<mailto:Nitsan.Dolev=40rbbn....@dmarc.ietf.org>> Date: Wednesday, March 12, 2025 at 10:30 AM To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, saja...@cisco.com<mailto:saja...@cisco.com> <saja...@cisco.com<mailto:saja...@cisco.com>>, stho...@cisco.com<mailto:stho...@cisco.com> <stho...@cisco.com<mailto:stho...@cisco.com>>, manka...@cisco.com<mailto:manka...@cisco.com> <manka...@cisco.com<mailto:manka...@cisco.com>>, ke...@arrcus.com<mailto:ke...@arrcus.com> <ke...@arrcus.com<mailto:ke...@arrcus.com>>, Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Cc: Roger David <roger.da...@rbbn.com<mailto:roger.da...@rbbn.com>>, Michael Gorokhovsky <michael.gorokhov...@rbbn.com<mailto:michael.gorokhov...@rbbn.com>> Subject: RE: Proposed changes rfc9251bis draft You don't often get email from nitsan.dolev=40rbbn....@dmarc.ietf.org<mailto: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. Hi Jorge, Thanks for your prompt response. Regarding the first issue; thanks for this clarification. We are on the same page. Regarding the second issue, I agree that the DF might not be the only MH-ES mate PE that will advertise the same (x,G) SMET route. Yet IMHO, RFC9251bis shall explicitly highlight the high availability use cases and the steps to be taken to reduce related (x,G) packet loss. Meaning that in case failure of the MH-ES AC / PW connected to the DF PE, or in case of DF node failure or core isolation, the BDF node SHALL advertise the related (x,G) SMET route (though not forward the traffic to the related MH-ES interface before becoming DF). Then upon becoming DF, the related (x,G) traffic can be immediately forwarded by the new DF to the CE. If the BDF will send the related (x,G) SMET route only AFTER becoming DF then wait for the remote PEs to process the SMET route then send the traffic this behavior will result in high packet loss. Such packet loss in case of, say, real time Video Multicast traffic may result in breakage of I-frame which may recover after 2-5 seconds. If we focus on a specific MH-ES, sending SMET route by the DF and the BDF (which will only forwards the related (x,G) traffic becoming the DF), will help reducing packet loss considerably. If more PEs advertise the related (x,G) SMET Route it is a waste of BW on the core. WDYT ? Regards, Nitsan 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<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<mailto:Nitsan.Dolev=40rbbn....@dmarc.ietf.org>> Date: Monday, March 10, 2025 at 4:08 AM To: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, saja...@cisco.com<mailto:saja...@cisco.com> <saja...@cisco.com<mailto:saja...@cisco.com>>, stho...@cisco.com<mailto:stho...@cisco.com> <stho...@cisco.com<mailto:stho...@cisco.com>>, manka...@cisco.com<mailto:manka...@cisco.com> <manka...@cisco.com<mailto:manka...@cisco.com>>, ke...@arrcus.com<mailto:ke...@arrcus.com> <ke...@arrcus.com<mailto:ke...@arrcus.com>> Subject: [bess] Proposed changes rfc9251bis draft You don't often get email from nitsan.dolev=40rbbn....@dmarc.ietf.org<mailto: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
