[bess] Re: [Shepherding AD review] review of draft-ietf-bess-evpn-irb-extended-mobility-17

["Gunter van de Velde (Nokia)" <[e-mail]>]

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 <[e-mail]>
Sent: Thursday, October 17, 2024 1:03 AM
To: Gunter van de Velde (Nokia) <[e-mail]>
Cc: [e-mail]; BESS <[e-mail]>
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