EVPN Port-Active Redundancy Mode
draft-ietf-bess-evpn-mh-pa-13
Yes
Gunter Van de Velde
No Objection
Deb Cooley
Erik Kline
Orie Steele
Note: This ballot was opened for revision 11 and is now closed.
Gunter Van de Velde
Yes
Deb Cooley
No Objection
Erik Kline
No Objection
Jim Guichard
No Objection
Comment
(2024-12-02 for -11)
Sent
Thanks for the document. Minor fixes from nits: == Missing Reference: 'ES' is mentioned on line 229, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-bess-evpn-vp
John Scudder
No Objection
Comment
(2024-12-04 for -11)
Sent
Thanks for this document. It was a bit dense to review, but I do appreciate the brevity! I have a few comments you may want to consider. In particular, please consider the comment on Section 3.2 MAY/MUST, which talks about what might be a bug in the spec (if it's not a bug in my understanding). ### Abstract, you had one job The most important job of an abstract is to give the reader a quick hint of what the document is about. This abstract doesn't do that: This document builds on the existing redundancy mechanisms supported by EVPN and introduces a new Port-Active redundancy mode. The missing, crucial, part is a brief hint of what the "new Port-Active redundancy mode" *is*, e.g. "new active/standby redundancy mode, called 'Port-Active'." ### Section 3.1, spell out RR Please spell out "BGP Route Reflector" or expand as "BGP RR (Route Reflector)". ### Section 3.2, MAY or MUST? c. When ESI is configured on a Layer-3 interface, the Ethernet- Segment (ES) route (Route Type-4) MAY be the only route exchanged by PEs in the redundancy group. Do you mean "MUST be the only"? As you've written it, it's also fine for various other routes to be exchanged. For that matter as you've written it, it would also be fine for no RT-4 to be exchanged, since by definition MAY can be ignored. ### Section 5, advanced synchronization? To enhance convergence during failure and recovery when Port-Active redundancy mode is employed, advanced synchronization between peering PEs may be beneficial. The Port-Active mode poses a challenge since the "standby" port may be in a down state. Transitioning a "standby" port to an up state and stabilizing the network requires time. For Integrated Routing and Bridging (IRB) and Layer 3 services, synchronizing ARP / ND caches is recommended. Additionally, associated VRF tables may need to be synchronized. For Layer 2 services, synchronization of MAC tables may be considered. Is all of this "advanced synchronization" non-standard implementation-specific stuff left as an exercise to the reader? Is it supposed to be obvious what to do? (It's not, to me.) If the synchronization techniques are out of scope, I suggest saying so. If they're referring to existing standardized techniques, I suggest supplying references. ### Section 5.2, wut I am sad to say that without diving deep into all the underlying specifications, I have no idea what the backward compatibility of this solution is, because you don't summarize it plainly. I can't even guess. :-( The options would seem to be that inserting a noncompliant PE will - make the network melt down (probably not this one) - make the extension in this spec fail to function (what happens instead? active/active?) - something else (what?) It would be great to make this a little more comprehensible to someone who doesn't have the nuts and bolts committed to memory.
Murray Kucherawy
No Objection
Comment
(2024-12-04 for -11)
Sent
In Section 3.2, bullet (g), why is this only a SHOULD? When might an implementer or operator decide to do otherwise? Same question around the SHOULD in Section 4.1.
Orie Steele
No Objection
Paul Wouters
No Objection
Comment
(2024-12-01 for -11)
Sent
Roman Danyliw
No Objection
Comment
(2024-12-04 for -11)
Not sent
Thank you to Paul Kyzivat for the GENART review.
Warren Kumari
No Objection
Comment
(2024-12-04 for -11)
Sent
Purely out of interest / curiosity: Why are you using Bit 5, and not 2 or 3 or 4? I'm guessing that some other drafts are using this, but ¯\_(ツ)_/¯
Zaheduzzaman Sarker
No Objection
Comment
(2024-12-04 for -11)
Sent
Thanks for working on this specification. Thanks to Wesley Eddy for the TSVART review. My understanding is that even if CE is multihomed to two or more PEs only one path is active at a time, this simplifies the loss handling and reordering concerns.
Éric Vyncke
No Objection
Comment
(2024-11-27 for -11)
Sent
# Éric Vyncke, INT AD, comments for draft-ietf-bess-evpn-mh-pa-11 Thank you for the work put into this document. As for most I-Ds coming from the BESS WG, it is really difficult to read and to understand, so bear with my lack of BESS context in my review, therefore my review is rather superficial. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Stéphane Litkowski for the shepherd's concise write-up including the WG consensus *and* the justification of the intended status. Other thanks to Antoine Fressancourt, the Internet directorate reviewer (at my request), please consider this int-dir review: https://datatracker.ietf.org/doc/review-ietf-bess-evpn-mh-pa-11-intdir-telechat-fressancourt-2024-11-27/ (it has just been posted but I expect authors to interact with Antoine, notably on the readability of the document) I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Abstract Should there be a reference for MC-LAG ? ## Section 1 Should there be an introduction to MC-LAG already in the introduction or move section 2 as a sub-section of section 1 ? Again, possibly due to my lack of BESS context, but I fail to find an explanation of `active/standby multi-homing at the interface level`, and I am sure that other readers will welcome a definition. Some graphics would help a lot. If I *guess* correctly, then is packet ordered delivery also a benefit ? If so, then please state it. ## Section 2 Are I1 and I2 interfaces or links in figure 1 ? BTW, using the aasvg tool will render figures as SVG, i.e., much nicer in HTML (worth investigating but no need to reply). It is unclear whether there could be more than 2 links/interfaces in this set-up. The text should be clear on this aspect. If only one link is active, then does it still qualify as a LAG member ? ## Section 3.1 Please provide references for VXLAN, SRv6, LDP. In the same vein and if not mistaken, there are multiple protocols using the term "designated forwarder", so, let's be specific. ## Section 4.1 Please expand "AC-DF" Figure 2 has names for the bits, but the names for bits 2 & 5 are not used in the text. ## Section 4.2 Should there be more explanation for the implementers on how the modulo approach work ? ## Section 10 s/the following coauthors have also contributed/the following people have also contributed/ ?