Hi Authors, Please find below my review of the latest version of the draft:
Abstract: The abstract refers to RFC7432bis but don’t make RFC7432bis as normative reference and also drafts is marked as updating RFC7432. Here you should make a choice, either you base the draft on RFC7432 and not mention RFC7432bis, or base your draft on RFC7432bis, but then you should make it normative ref. As a consequence, you’ll have a downref until RFC7432bis is published. I think this is a major issue that needs to be solved before moving fwd. Introduction: “EVPN-IRB enables advertising…”. [SLI] Were you expecting to put a reference here instead of EVPN-IRB ? While EVPN and IRB are considered as well known, EVPN-IRB is a bit weird. But I guess it’s a reference to RFC9135. If yes, this must be modified. I would potentially right it as “EVPN IRB ([RFC9135]) enables…”. We need to have the reference immediately, not only at the end. Also in the document, you should choose between EVPN IRB and EVPN-IRB. Unfortunately, I see that RFC9135 is not consistent 😊 But it’s good to have consistency here. “While a fixed 1:1 mapping between IP and MAC is a common use case that is addressed via existing MAC mobility procedure » [SLI] I would add: “MAC mobility procedure, defined in [RFC7432]” “VM move”. [SLI] I guess you’ll need to expand VM on first use. Maybe adding a bit of context before would be helpful (IRB mobility scenarios in datacenter for instance). “Content presented in this document is independent » [SLI] “Content” is probably too wide IMO. I would write it as “The proposed solution is independent …” “It is also largely” [SLI] I would remove largely. Either it’s independent, or it’s not 😊 [SLI] I would personally remove the paragraphs “Content presented…” and “In addition to symmetric”, in favor of a slightly modified version of the last paragraph: “ This document covers mobility for the following cases, independently of the overlay encapsulation (e.g.: MPLS, NVO Tunnel):¶<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility#section-1-9> * Symmetric EVPN IRB overlay¶<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility#section-1-10.1> * Asymmetric EVPN IRB overlay¶<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility#section-1-10.2> * Routed EVPN overlay¶<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility#section-1-10.3> “ Section 1.1: As sections 3,4,5 are dealing with problem statement/background, wouldn’t it be better/more clear to group them in a big section ? You can keep your existing 3,4,5 sections as subsections of the bigger one. Section 2: Please check https://www.rfc-editor.org/materials/abbrev.expansion.txt and I think you could remove from your list anything which is considered as well known. And also please check for abbrevations that require expansion on first use. Section 4: For readability purpose, I would always use the same naming conventions for the IP to MAC bindings, sometimes you use IP1-MAC1, sometimes IP1-M1 across the sections. Section 5: “It is possible for host to be learnt on say, PE1” [SLI] I would just say: “It is possible for host VM route be learnt on PE1” Section 6/7/8/9 [SLI] s/LOCAL/Local|local/g. Why using LOCAL as upper case ? Section 7.1: [SLI] I have a philosophical issue with the parent/child relationship you describe. If MAC is parent of MAC-IP, how could MAC be truly optional as a child cannot exist without its parent. Section 8.1/8.2/8.4/8.5 [SLI] s/should be computed/MUST be computed/g. IMO, you cannot use “should” and then MUST in your bullets. Section 8.3: [SLI] s/is required/IS REQUIRED Section 8.5 “If this is a SYNCed MAC-IP on a local ES, it would also result in a derived SYNC MAC Mx route entry” [SLI] I find the beg of the sentence of bit weird, could you improve it ? Section 8.6: [SLI] Change title to “Interoperability”, same in the text of the section. s/should be computed/MUST be computed . Why using should here and must in other cases, any reason ? Section 10: Why do you use DUPLICATE/FROZEN as upper case ? You need to make it lower case Section 13: You missed a “e” at the end of Patrice’s last name.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
