John Scudder has entered the following ballot position for draft-ietf-bess-evpn-irb-extended-mobility-20: Discuss
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-irb-extended-mobility/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this document. I found it relatively easy to read and understand; I appreciate the effort that must have gone into making it so. That being said, I do have one major concern I would like to DISCUSS. I suspect it will be relatively easy to resolve. I also have several comments I hope you'll consider. ## DISCUSS ### SYNC Throughout the document, you reference SYNC, e.g., in Section 5.3, "Local and SYNC route learning can occur..." I couldn't find a definition of what you mean by "SYNC route learning" (and similar) anywhere. There are some terms in the terminology section that define "SYNC XXX" but those definitions are not very useful if I don't know what "SYNC" is, and I don't. If SYNC is a term defined elsewhere in the EVPN document set, please provide a reference. If it's supposed to be obvious to the reader... it wasn't obvious to this reader, and I tried. I think this needs to be addressed for this document to be clear. As a less important point, why is SYNC capitalized as if it were an acronym (or RFC 2119 keyword)? If it's not an acronym, and if it's not already a term that's well-established in some existing RFC and too late to change, then I implore you to consider revising it to something that is LESS SHOUTY. That aspect of it isn't DISCUSS-worthy but since I was talking about SYNC here anyway I figured it was a good place to mention it. ### Section 6.4, REMOTE SYNC Upon receiving a REMOTE SYNC, the corresponding local MAC Mx (if REMOTE SYNC is capitalized as if it were a specific term the reader is expected to understand. I don't see it defined anywhere. It's not obvious to me. Also, the same minor point about ALL CAPS applies here. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENT ### Throughout, IP and MAC Like Éric Vyncke, I find the use of "IP" to mean "IP address" and "MAC" to mean "MAC address" mildly distasteful, and I suggest you consider using the full names throughout. If you don't want to cut a new version to do this, you could request the RFC Editor help you with it. In a few cases it rises beyond just an aesthetic problem -- in some cases, for example, you use "MAC" to mean "MAC address" and in others, you seem to use it to mean "MAC route". Not using the full name can create ambiguity. A specific example of this is the final bullet of Section 6.8 which talks about "local MAC age-out". My initial assumption was that you were talking about aging out an ARP or ND cache entry, but then you have a sentence that contradicts that assumption. I'm left with the guess that you must mean "MAC route". I hope this helps illustrate that this problem is not only personal preference but impacts clarity. ### Section 2, consider alphabetizing I see that this section is organized sort-of topically, but overall I think it would be more valuable if alphabetized. ### Section 2, Data Center? Your definition of "EVPN PE" makes it specific to data centers. As far as I know, EVPN is far from being limited to data centers. Consider rewriting this to generalize. ### Section 2, LAG Please define LAG. You could do it inline instead of adding a definition, if you want. ### Section 3.3, MC-LAG Please expand or reference MC-LAG. ### Section 5.2, N+1, or max(N+1, M+1)? In such cases, a host-IP move to a different physical server results in the IP moving to a new MAC binding. A new MAC-IP route resulting from this move must be advertised with a sequence number higher than the previous MAC-IP route for this IP, advertised from the prior location. For example, consider a route Mx-IPx currently advertised with sequence number N from PE1. If IPx moves to a new physical server behind PE2 and is associated with MAC Mz, the new local Mz-IPx route must be advertised with a sequence number higher than N and the previous Mz sequence number M. This allows PE devices, including PE1, PE2, and other remote PE devices, to determine and program the most recent MAC binding and reachability for the IP. PE1, upon receiving this new Mz-IPx route with sequence number N+1, would ^^^^^^^^^^^^^^^^^^^ update IPx reachability via PE2 for symmetric IRB and update IPx's ARP/NDP binding to Mz for asymmetric IRB, while clearing and withdrawing the stale Mx-IPx route with the lower sequence number. Shouldn't the marked text be "sequence number N+1 or M+1, whichever is greater"? ### Section 8.2.1, SHOULD or MUST? A MAC-IP route SHOULD be treated as duplicate if either: * The corresponding MAC route is marked as duplicate via the existing detection procedure. * The corresponding IP is marked as duplicate via the extended procedure described above. The SHOULD implies that one of the listed conditions might exist, but it's still OK to *not* treat the route as duplicate. What is an example of a case where it's fine not to treat the route as a dup? Put differently, why isn't this a MUST? ### Section 8.3, intuition duplicate MAC detection procedures specified in [RFC7432] can be applied intuitively to IP-only host routes for duplicate IP detection. In our specifications, we should never be asking the reader to intuit what the right thing to do is! A perfect specification requires no intuition at all, because it's so precise. So when I saw this, I was concerned. Maybe what you meant was something like "procedures similar to the duplicate MAC detection procedures specified in [RFC7432] can be applied, with the necessary changes, to IP-only host routes for duplicate IP detection, as follows:" Is that right? Please reassure me you are not expecting the implementor to go with their gut. :-) ### Section 9, sequence number consumption Thank you for addressing the increased rate of sequence number consumption. Am I correct that there is no serious concern about sequence number wrap, or the consequences of wrap, either because the underlying EVPN mechanisms deal with it smoothly, or because you have evaluated that sequence wrap is still low-probability? _______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
