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

[Neeraj Malhotra <[e-mail]>]

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