Hi John, Many thanks for a comprehensive review and comments. I have just uploaded rev21 to address all (except one) of the comments.
Please see inline for details. ---------------------------------------------------------------------- > 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. > [NM]: ack. I see that the definition and usage of the SYNC terminology in the document could be better. Made a few changes in rev21 to make this clearer - I have renamed the terms SYNC MAC route and SYNC MAC-IP route as "Peer-Sync-Local MAC Route" and "Peer-Sync-Local MAC-IP Route" respectively and also added new definitions for them in section 2 that I think define these terms accurately. As you pointed out, there was one section where this route was referred to as the "REMOTE SYNC route". Have fixed that such that the document consistently uses the defined terms "Peer-Sync-Local MAC Route" and "Peer-Sync-Local MAC-IP Route" everywhere. In addition, I have also enhanced the text in section 5.3 to explain what these routes mean. This also addresses the all caps issue. > > ---------------------------------------------------------------------- > 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. > [NM]: ack. addressed in rev21. > > ### 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. > [NM]: Makes sense. Have not yet made this change but will try and do this together with the RFC editor. > > ### 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. > [NM]: ack, certainly not the intent to be limited to DC. fixed in rev21. > > ### Section 2, LAG > > Please define LAG. You could do it inline instead of adding a definition, > if > you want. > [NM]: ack. added in rev21. > > ### Section 3.3, MC-LAG > > Please expand or reference MC-LAG. > [NM]: ack. added in rev21. ### 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"? > [NM]: Wow, that's a great catch. Yes, it should be "sequence number N+1 or M+1, whichever is greater". Fixed in rev21. ### 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? > [NM]: yes, that makes sense. fixed in rev21. > > ### 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. :-) > [NM]: yup, certainly not the intent :) Have updated the text as above. > > ### 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? > [NM]: yes, we concluded that this isn't a concern with duplicate address detection in place. Without a duplicate scenario, 32 bit sequence number space (4 billion) seems sufficient if you consider that for a host that moves every ten seconds, this translates to 7K years before the sequence number will wrap. Thanks, Neeraj
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
