HI Neeraj, Many thanks for the updates, the text is more clear now. I’ll do the write up and proceed.
Stephane From: Neeraj Malhotra (nmalhotr) <nmalh...@cisco.com> Sent: Monday, October 16, 2023 11:31 PM To: slitkows.i...@gmail.com; Stephane Litkowski (slitkows) <slitk...@cisco.com>; draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org; bess@ietf.org Cc: bess-cha...@ietf.org Subject: Re: Chair review of draft-ietf-bess-evpn-irb-extended-mobility-15 Hi Stephane, Thanks for catching all of these – have addressed them in rev17. Regarding, Section 5.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. [NM]: child -> parent relationship explained in “section 5.1 Sequence number Inheritance” is a local view of a PE that *does* maintain both local MAC and local MAC-IP routes with corresponding sequence number attributes. Local MAC itself is NOT optional on a PE. It is only a separate advertisement of this MAC to other PEs that is optional (since the MAC reachability is already signaled together with MAC-IP route). I have updated the text in “section 3.1 Optional MAC Only RT-2” and “section 5.1 Sequence number Inheritance” to explicitly clarify this. Hope, this makes sense. Thanks, Neeraj From: slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com> <slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>> Date: Monday, October 16, 2023 at 8:14 AM To: Neeraj Malhotra (nmalhotr) <nmalh...@cisco.com<mailto:nmalh...@cisco.com>>, Stephane Litkowski (slitkows) <slitk...@cisco.com<mailto:slitk...@cisco.com>>, draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org<mailto:draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org> <draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org<mailto:draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>> Subject: RE: Chair review of draft-ietf-bess-evpn-irb-extended-mobility-15 Hi Neeraj, Thanks for the updates. Couple new « mistakes »: * Abstract should not use xtarget references, you could use “RFC7432” as plain text but not using the reference tag. You should also not use normative language “IS REQUIRED” in the abstract. * Introduction: s/envoronments/environment and s/containairized/containerized (same issue in terminology section) * In Section 1.1, I think your section reference haven’t followed the new structure. Section 6 should be Section 4, Section 8 should be Section 6. Few things, not addressed or that needs explanation: Section 6.3: [SLI] s/is required/IS REQUIRED Section 6.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 ? [SLI2] The “If this is a” doesn’t sound good for a written document and not accurate enough. Could we say “ On receiving a” ? Section 5.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 11: You missed a “e” at the end of Patrice’s last name. [SLI] My mistake, there was also a “t” missing: should be “Brissette” Brgds, Stephane From: Neeraj Malhotra (nmalhotr) <nmalh...@cisco.com<mailto:nmalh...@cisco.com>> Sent: Thursday, October 12, 2023 12:53 AM To: Stephane Litkowski (slitkows) <slitk...@cisco.com<mailto:slitk...@cisco.com>>; draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org<mailto:draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org>; bess@ietf.org<mailto:bess@ietf.org> Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> Subject: Re: Chair review of draft-ietf-bess-evpn-irb-extended-mobility-15 Hi Stephane, Many thanks for the detailed review and comments. Have updated the document addressing all of the comments below. Specifically regarding the issue of referencing rfc7432 or rfc7432bis, I have modified the reference to be on rfc7432 since existing 7432 is sufficient as a reference for all procedures covered in this document and it alleviates unnecessary dependency on publication of 7432bis. Thanks, Neeraj From: Stephane Litkowski (slitkows) <slitk...@cisco.com<mailto:slitk...@cisco.com>> Date: Wednesday, October 11, 2023 at 6:14 AM To: draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org<mailto:draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org> <draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org<mailto:draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>> Subject: Chair review of draft-ietf-bess-evpn-irb-extended-mobility-15 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
