Jorge, Lots of thanks! Regards, Sasha
From: Jorge Rabadan (Nokia) <jorge.rabadan=40nokia....@dmarc.ietf.org> Sent: Wednesday, November 20, 2024 12:10 AM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com> Cc: bess@ietf.org; rtg-...@ietf.org; Zheng Zhang <zhang.zh...@zte.com.cn>; draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org; Greg Mirsky <gregimir...@gmail.com>; Donald Eastlake <d3e...@gmail.com> Subject: Re: [EXTERNAL] [RTG-DIR]Rtgdir early review of draft-ietf-bess-evpn-redundant-mcast-source-10 Hi Sasha, OK, after discussing with other co-authors we can do that. Thanks! Jorge From: Alexander Vainshtein <Alexander.Vainshtein=40rbbn....@dmarc.ietf.org<mailto:Alexander.Vainshtein=40rbbn....@dmarc.ietf.org>> Date: Tuesday, November 19, 2024 at 12:32 AM To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, rtg-...@ietf.org<mailto:rtg-...@ietf.org> <rtg-...@ietf.org<mailto:rtg-...@ietf.org>>, Zheng Zhang <zhang.zh...@zte.com.cn<mailto:zhang.zh...@zte.com.cn>>, draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org<mailto:draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org> <draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org<mailto:draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org>>, Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>, Donald Eastlake <d3e...@gmail.com<mailto:d3e...@gmail.com>> Subject: RE: [EXTERNAL] [RTG-DIR]Rtgdir early review of draft-ietf-bess-evpn-redundant-mcast-source-10 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. Jorge, Lots of thanks for a prompt response. I can confirm that, from my POV, the reference to P2MP BFD drafts is sufficient. Please note that RFC 9026 (that, IMHO and FWIW) addresses a similar problem in Multicast IP-VPN) does not use anything similar to EVPN-BFD, it refers to RFC 8562 instead. My 2c, Sasha From: Jorge Rabadan (Nokia) <jorge.rabadan=40nokia....@dmarc.ietf.org<mailto:jorge.rabadan=40nokia....@dmarc.ietf.org>> Sent: Monday, November 18, 2024 9:22 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Cc: bess@ietf.org<mailto:bess@ietf.org>; rtg-...@ietf.org<mailto:rtg-...@ietf.org>; Zheng Zhang <zhang.zh...@zte.com.cn<mailto:zhang.zh...@zte.com.cn>>; draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org<mailto:draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org>; Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>; Donald Eastlake <d3e...@gmail.com<mailto:d3e...@gmail.com>> Subject: Re: [EXTERNAL] [RTG-DIR]Rtgdir early review of draft-ietf-bess-evpn-redundant-mcast-source-10 Hi Sasha, Note that the redundant mcast sources draft is not only for P2MP tunnels. So, is your suggestion that we should remove the EVPN-BFD draft as a reference and leave the other one? Thanks, Jorge From: Alexander Vainshtein <Alexander.Vainshtein=40rbbn....@dmarc.ietf.org<mailto:Alexander.Vainshtein=40rbbn....@dmarc.ietf.org>> Date: Sunday, November 17, 2024 at 9:07 AM To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, rtg-...@ietf.org<mailto:rtg-...@ietf.org> <rtg-...@ietf.org<mailto:rtg-...@ietf.org>>, Zheng Zhang <zhang.zh...@zte.com.cn<mailto:zhang.zh...@zte.com.cn>>, draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org<mailto:draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org> <draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org<mailto:draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org>>, Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>, Donald Eastlake <d3e...@gmail.com<mailto:d3e...@gmail.com>> Subject: RE: [EXTERNAL] [RTG-DIR]Rtgdir early review of draft-ietf-bess-evpn-redundant-mcast-source-10 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. Jorge, Lots of thanks for a prompt response. ++ Greg and Donald as I am discussing the EVPN BFD draft with them. I cannot say, of course, in which way my concerns abut the EVPN-BFD draft would be resolved. These concerns are based on a naïve observation that, AFAIK, for the 20+ years of coexistence of both BGP/MPLS IP-VPNs and BFD in the industry nobody has ever expressed any interest in “BGP/MPLS IP-VPN Network Layer OAM” – so why should EVPN Network Layer be different? From my POV using BFD for P2MP tunnels should suffice for the purpose of the redundant MC source draft, because I do not see which problems that could be identified by EVPN BFD but not by BFD for P2MP tunnels it could use as triggers for selecting an alternative MC source. What, if anything, do I miss here? Regards, Sasha From: Jorge Rabadan (Nokia) <jorge.rabadan=40nokia....@dmarc.ietf.org<mailto:jorge.rabadan=40nokia....@dmarc.ietf.org>> Sent: Friday, November 15, 2024 3:23 AM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Cc: bess@ietf.org<mailto:bess@ietf.org>; rtg-...@ietf.org<mailto:rtg-...@ietf.org>; Zheng Zhang <zhang.zh...@zte.com.cn<mailto:zhang.zh...@zte.com.cn>>; draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org<mailto:draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org> Subject: Re: [EXTERNAL] [RTG-DIR]Rtgdir early review of draft-ietf-bess-evpn-redundant-mcast-source-10 Hi Sasha, Disclaimer: I’m not a BFD expert. Section 5.3 (use of BFD in the HS solution) is purposedly kept light, since defining the mechanics of BFD is not the goal. The procedures work perfectly well without BFD, however we wanted to open the door to potential and OPTIONAL faster fault detection if the withdrawal of BGP updated was not sufficient for the operator in some cases. I think we are open to add more details in that section if it helps and the WG wants, but we wanted to avoid this to become a BFD spec. My understanding is that RFC8562 explains how BFD can be used in a multipoint fashion, but draft-ietf-bess-evpn-bfd<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-bfd-08> explains its applicability to EVPN. So in theory I think it would be enough for us to use the EVPN-BFD draft as an informative reference. About your issues with the EVPN-BFD draft, it is really for the EVPN-BFD authors to resolve. Once resolved, what are you suggesting to include in our section 5.3 to address your concerns? Let us know and we can work together to do that in the next version. Thanks! Jorge From: Alexander Vainshtein <Alexander.Vainshtein=40rbbn....@dmarc.ietf.org<mailto:Alexander.Vainshtein=40rbbn....@dmarc.ietf.org>> Date: Wednesday, November 13, 2024 at 11:58 PM To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, rtg-...@ietf.org<mailto:rtg-...@ietf.org> <rtg-...@ietf.org<mailto:rtg-...@ietf.org>>, Zheng Zhang <zhang.zh...@zte.com.cn<mailto:zhang.zh...@zte.com.cn>>, draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org<mailto:draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org> <draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org<mailto:draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org>> Subject: RE: [EXTERNAL] [RTG-DIR]Rtgdir early review of draft-ietf-bess-evpn-redundant-mcast-source-10 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. Jorge, Lots of thanks for your email. I have tried to understand to which specific procedure in the EVPN-BFD draft<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-bfd-08> the Hot Standby solution<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-redundant-mcast-source-11#section-5> refers, but failed to do so. EVPN-BFD is only mentioned as an option to monitor “the status of the multipoint tunnels used to forward the Single Flow Group packets from the redundant G-sources”. What’s more, to the best of my understanding: The only procedures from the EVPN-BFD draft that are mentioned are those for bootstrapping EVPN-BFD sessions In addition, the procedures defined in the BFD for P2MP LSP draft<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-p2mp-bfd-08> are mentioned in your draft. Can you please clarify: Whether the status of the multipoint tunnels used to forward the Single Flow Group packets from the redundant G-sources, if available, would be used by the “downstream PEs connected to the receivers in the tenant network” for selection of the current active source? Why the procedures defined in RFC 8562<https://www.rfc-editor.org/rfc/rfc8562.html> and BFD for P2MP LSP draft are not sufficient for this purpose? The context for my questions is my position (publicly expressed on the BESS WG list) that the mechanisms defined in the EVPN-BFD draft do not address any real problem, and that, therefore, this draft should not be progressed. Regards, and lots of thanks in advance, Sasha From: Jorge Rabadan (Nokia) <jorge.rabadan=40nokia....@dmarc.ietf.org<mailto:jorge.rabadan=40nokia....@dmarc.ietf.org>> Sent: Wednesday, November 13, 2024 4:05 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>; draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org<mailto:draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org> Cc: bess@ietf.org<mailto:bess@ietf.org>; rtg-...@ietf.org<mailto:rtg-...@ietf.org>; Zheng Zhang <zhang.zh...@zte.com.cn<mailto:zhang.zh...@zte.com.cn>> Subject: Re: [EXTERNAL] [RTG-DIR]Rtgdir early review of draft-ietf-bess-evpn-redundant-mcast-source-10 Hi Sasha, The reason is because the hot standby procedure is used for ingress replication or p2mp as defined in the EVPN-BFD draft.. and when we discussed this, the feedback from the WG (mostly Greg) was to add a reference to the EVPN-BFD draft. Thanks. Jorge From: Alexander Vainshtein <Alexander.Vainshtein=40rbbn....@dmarc.ietf.org<mailto:Alexander.Vainshtein=40rbbn....@dmarc.ietf.org>> Date: Sunday, October 27, 2024 at 4:05 AM To: draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org<mailto:draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org> <draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org<mailto:draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, rtg-...@ietf.org<mailto:rtg-...@ietf.org> <rtg-...@ietf.org<mailto:rtg-...@ietf.org>>, Zheng Zhang <zhang.zh...@zte.com.cn<mailto:zhang.zh...@zte.com.cn>> Subject: [bess] Re: [EXTERNAL] [RTG-DIR]Rtgdir early review of draft-ietf-bess-evpn-redundant-mcast-source-10 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 all, I have looked up the draft, and I do not understand the reference to the EVPN-VFD draft in Section 5.2 of the draft<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-redundant-mcast-source-10#section-5.2>. This section says: In addition to using the state of the EVPN A-D per EVI, EVPN A-D per ES or S-PMSI A-D routes to modify the Reverse Path Forwarding check on (*,G)/(S,G) as discussed in Section 5<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-redundant-mcast-source-10#sect-5>, Bidirectional Forwarding Detection (BFD) protocol MAY be used to monitor the status of the multipoint tunnels used to forward the Single Flow Group packets from the redundant G-sources. The BGP-BFD Attribute is advertised along with the S-PMSI A-D or Inclusive Multicast Ethernet Tag routes (depending on whether Inclusive PMSI or Selective PMSI trees are used) and the procedures described in [I-D.ietf-bess-evpn-bfd] [I-D.ietf-mpls-p2mp-bfd] are used to bootstrap multipoint BFD sessions on the downstream PEs. If the purpose of using BFD is “to monitor the status of the multipoint tunnels used to forward the Single Flow Group packets from the redundant G-sources”, why is not the mechanism defined in the BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP draft<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-p2mp-bfd-08> not sufficient? Regards, Sasha From: Zheng Zhang via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> Sent: Thursday, October 24, 2024 7:38 AM To: rtg-...@ietf.org<mailto:rtg-...@ietf.org> Cc: bess@ietf.org<mailto:bess@ietf.org>; draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org<mailto:draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org> Subject: [EXTERNAL] [RTG-DIR]Rtgdir early review of draft-ietf-bess-evpn-redundant-mcast-source-10 Reviewer: Zheng Zhang Review result: Ready Hello I have been selected to do a routing directorate “early” review of this draft. https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-redundant-mcast-source/<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-redundant-mcast-source> The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. Document: draft-ietf-bess-evpn-redundant-mcast-source-10.txt Reviewer: Zheng Zhang Review Date: Oct 24th, 2024 Intended Status: Standards Track Summary: No issues found. This documents is ready to proceed to next step. Comments: Generally, the draft written clearly. Please consider the comments listed to improve the draft. Overall, please replace the [I-D.ietf-bess-evpn-irb-mcast] with [RFC9625]. Please find the comments below with ZZ>. Multicast Source Redundancy in EVPN Networks draft-ietf-bess-evpn-redundant-mcast-source-10 Abstract ...... 1. Introduction ...... The solution provides support for Warm Standby and Hot Standby redundancy. Warm Standby is defined as the redundancy scenario in which the upstream PEs, attached to the redundant sources of the same tenant, make sure that only one source of the same flow can send multicast to the interested downstream PEs at the same time. In Hot Standby mode, the upstream PEs forward the redundant multicast flows to the downstream PEs, and the downstream PEs make sure only one flow is forwarded to the interested attached receivers. ZZ> It's better to move the Warm Standby and Hot Standby explaination to Terminology section. ...... 4. Warm Standby (WS) Solution for Redundant G-Sources The general procedure is described as follows: ZZ> It's better to add a 'specification' sub-section for the solution procedure description. 1. Configuration of the upstream PEs ...... 2. Signaling the location of a G-source for a given Single Flow Group ...... * The S-PMSI A-D route is imported by all the PEs attached to the tenant domain. In order to do that, the route will use the SBD-RT (Supplementary Broadcast Domain Route Target) in addition to the BD-RT (Broadcast Domain Route Target) of the Broadcast Domain over which the G-traffic is received. The route SHOULD also carry a Designated Forwarder Election Extended Community and a flag indicating that it conveys an SFG. The Designated Forwarder Election extended community and its use is specified in [RFC8584]. ZZ> Since the SBD-RT may not existed if there is no multiple BDs, please add "if the SBD exists" to the SBD-RT description. ...... 4.1. Warm Standby Example in an OISM Network ...... The Warm Standby solution works as follows: ...... 2. Signaling the location of S1 and S2 for (*,G1) Upon receiving (S1,G1) traffic on a local Attachment Circuit, PE1 and PE2 originate S-PMSI A-D (*,G1) routes with the SBD-RT (Supplementary Broadcast Domain Route Target), Designated Forwarder Election Extended Community and a flag indicating that it conveys a Single Flow Group. ZZ> The "a flag" indicates the "Single Flow Group (SFG) flag" defined in Multicast Flags Extended Community Flag, right? Please replace the 'a flag' with the "SFG flag". ...... The end result is that, upon receiving reports for (*,G1) or (S,G1), the downstream PEs (PE3 and PE5) will issue SMET routes and will pull the multicast Single Flow Group from PE1, and PE1 only. Upon a failure on S1, the Attachment Circuit connected to source S1 or PE1 itself will trigger the S-PMSI A-D (*,G1) withdrawal from PE1 and PE2 will be promoted to Single Forwarder. ZZ> Please add "IGMP/MLD" in front of "reports for (*,G1) or (S,G1)" in the first sentence. ...... 5. Hot Standby Solution for Redundant G-Sources ZZ> It's better to add a 'specification' sub-section for the solution procedure description. 1. Configuration of the PEs ...... Contrary to what is specified in the Warm Standby method (that is ...... The downstream PEs will locally select an Ethernet Segment Identifier for a given Single Flow Group, and will program a Reverse Path Forwarding check to the (*,G)/(S,G) state for the Single Flow Group that will discard (*,G)/(S,G) packets from the rest of the Ethernet Segment Identifiers. The selection of the Ethernet Segment Identifier for the Single Flow Group is based on local policy. ZZ> So different downstream PEs may select different upstream PE, this may be described explicitly in the paragraph. ...... 3. Distribution of DCB (Domain-wide Common Block) ESI-labels and G-source ES routes ...... b. The EVPN A-D per EVI and A-D per ES routes MUST include the route target SBD-RT since they have to be imported by all the PEs in the tenant domain. ZZ> Since the SBD may not existed, please add "if the SBD exists" to indicate. ...... 5.3. Hot Standby Example in an OISM Network ...... 2. PE1 and PE2 advertise S-PMSI A-D (*,G1) and EVPN ES, A-D per ES and A-D per EVI routes Based on the configuration of step 1, PE1 and PE2 advertise an S-PMSI A-D (*,G1) route each. The route from each of the two PEs will include TWO ESI Label Extended Communities with ESI-1 and ESI-2 respectively, as well as route target BD1-RT plus SBD-RT and a flag that indicates that (*,G1) is a Single Flow Group. ZZ> Same with previous comments, please replace "a flag" with "SFB flag". And in the sentence 'The route from each of the two PEs will include TWO ESI Label Extended Communities with ESI-1 and ESI-2 respectively,' please use lower case for the "TWO", if it has no special meaning. [End of Review] 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
