John Scudder has entered the following ballot position for draft-ietf-bess-evpn-mh-pa-11: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-mh-pa/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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. _______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
