Hi, Great, many thanks Gunter for comments again.
Neeraj > On Oct 29, 2024, at 5:51 AM, Gunter van de Velde (Nokia) > <[email protected]> wrote: > > > Hi Neeraj, > > Thanks for considering the feedbacks. > > I requested IETF LC and moved the document into the next phase of the > processing pipeline. > > G/ > > From: Neeraj Malhotra <[email protected]> > Sent: Thursday, October 17, 2024 1:03 AM > To: Gunter van de Velde (Nokia) <[email protected]> > Cc: [email protected]; BESS <[email protected]> > Subject: Re: [bess] [Shepherding AD review] review of > draft-ietf-bess-evpn-irb-extended-mobility-17 > > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > > Hi Gunter, > > Apologies again for taking some time and many thanks for a very detailed > review to improve the draft readability as well as some very good comments. > Categorization of comments as [major], [minor], [re-edit] really helps. > > I have uploaded a rev18 that: > > Incorporates all the suggested [re-edit] comments. Many thanks for taking the > time to provide all text improvements that significantly improve the overall > readability. > Addresses all of the [minor] and [major] comments, except for a few > exceptions that are answered below. For clarity, I am enumerating all [major] > and [minor] comments below to explicitly mark the comments that are addressed > in rev18 and exceptions that are explained below. > > > [major] > > This abstract is very detailed and makes it hard to understand on a high > > level what exactly the content of the draft is all about. I view upon a > > abstract as the textblob one gives to your people manager to make him/het > > understand what the document is all about. What about the following > > abstract textblob proposal, making high level draft intent better > > understandable for non-EVPN technology wizards > > [NM]: corrected. Have re-written the abstract taking some parts from your > proposed text. > > > [minor] > > What about section 5? it exists in the draft. I assume the intent is > > informational > > [NM]: corrected. Added section 5 as informational that serves as a foundation > for specifications in subsequent sections. > > > [major] > > Is SRv6 intentionally missing from this list? > > [NM]: corrected. added SRv6 as one of the overlay encapsulations. Procedures > in this spec are applicable independent of the overlay encapsulation. > > > [major] > > I believe that this is ambigious terminology. add RFC references to the > > base RFC that documents each type of overlay PE > > [NM]: redefined the term “Overlay” in the terminology section as “L3 and L2 > Virtual Private Network (VPN) enabled via NVO, SRv6, or MPLS service layer > encapsulation”. Let me know if this is clear. > > > [minor] > > s/physical Ethernet/Physical ethernet/ > > [NM]: corrected. > > > 258 * RT-5: EVPN route type 5 carrying IP prefix reachability. > > > > [minor] > > add references to RFC7432 > > [NM]: corrected. > > > 260 * MAC-IP: IP association for a MAC, referred to in this > > document may > > 261 be IPv4, IPv6 or both. > > > > [minor] > > Is this specified in a document somewhere, or is this explicit to this > > document itself? > > [NM]: It is used in a few other drafts in a different context. Definition in > this document is to emphasize that when used in this document, it refers to > both IPv4 and IPv6. I have redefined it as follows to make it clearer – “IPv4 > and/or IPv6 address and MAC binding for an overlay host.” > > > 273 * SYNC MAC-IP sequence number: In the context of EVPN > > multi-homing, > > 274 this refers to sequence number received with a SYNC MAC-IP > > route. > > > > > > [minor] > > Is the SYNC something outlined in this draft itself, or is this procedure > > specified in another document? > > I assume this is based upon the priciples of RFC7432 using the MAC > > Mobility Extended Community > > [NM]: yes, SYNC terminology is specifically defined and used in this draft. > Not aware of this terminology being used in another draft or RFC. > > 523 all PE devices that the ES is multi-homed to. There is need > for a > 524 mechanism to ensure consistency of sequence numbers assigned > across > 525 these PEs. > > [major] > * The text talks about PE3 and PE4 and about ESI-2, but the figure does not > show this. > Can figure be corrected to show these components? > This will make it more clear how inconsistency with sequence numbers > manifests. > > [NM]: corrected. > > [minor] > unsure why in thi informational section in the last paragraph uppercase MUST > is used. BCP14 language does not apply to informational textblobs > > [NM]: corrected. > > 859 local OR remote. The MAC-IP to MAC parent relationship > described > 860 earlier in this document in section 5.1 MAY be used to achieve > this > 861 logic. > > [major] > * for my own understanding: in section 6.2 first bullet point, make me wonder > if the connected ESI is share between two PEs. Would the requirement > potentially lead to a count to infinity when two PEs connect to a shared ESI? > > [NM]: Local MAC sequence number assignment method listed in this section is > intended to synchronize the sequence numbers between multi-homing PEs that > share the ESI if the local MAC sequence number is less than what is received > from the other PE. It is not intended to increment the sequence number beyond > what is received from the other PE. I have elaborated the text for this in > this section to make this clearer. > > * section 6.6: How would an implementation detect that the remote > implementation does not support the behavior? Could that be explicit > explained in the text? > > [NM]: Corrected. This section is essentially a specification on how a remote > MAC sequence number must be interpreted if different sequence numbers are > received for MAC and MAC-IP from the same remote PE. Implementing this > specification ensures that the PE will be able to interoperate with another > PE that does not synchronize sequence numbers between MAC and MAC-IP (using > inheritance). It does not require any explicit knowledge of the remote PE > being compliant or non-compliant or for this logic to be conditional based on > remote PE’s compliance. I have updated the text to be clearer in this regard. > > * section 6.7: THis section i did not understand. Too many moving parts. Can > this be explained more explicit or elaborative? > > [NM]: Corrected. updated the section to explain the scenario and remediation > better. > > * section 6.8: What network figure is referenced towards? > > [NM]: There is no figure attached to this section. PE1 and PE2 are used as > two example PEs in the network to illustrate the mobility convergence > scenarios in this section. I have updated the section to say this. > > 909 hosts advertised via NA messages with 0-bit=0. Please refer to > 910 [RFC9161]. > > [major] > * Unsure what purpose of 0-bit=0 is and where it is explained in RFC9161. > Some explicit reference and explanation could help the draft > > [NM]: Corrected. This is a good catch. There was a typo in the draft (should > be O bit / flag and not 0-bit). This refers to Override flag in NA messages. > Reference in this draft is essentially to maintain the behavior defined in > RFC 9161, which is to not apply EVPN mobility and duplicate address detection > procedures to anycast IPv6 hosts learnt via NA with O flag set to 0. I have > fixed the typo in the draft to explicitly refer to Override Flag (O Flag) so > it can be clearly mapped to handling specified in RFC 9161. > > 1083 need for a route clearing CLI for recovery from duplicate / > frozen > 1084 state is truly optional. > > [major] > * what is the 0-bit=0? please add a specific reference > > [NM]: corrected. Same as above. > > > Please do let me know if we need to revisit any of the comments above or > anything new comes up. > > Thanks, > Neeraj
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
