[Int-dir] Re: [bess] Intdir telechat review of draft-ietf-bess-evpn-irb-extended-mobility-18

[Neeraj Malhotra <[e-mail]>]

Hi Brian,

Thanks for the review and comments. Have uploaded rev19 to address comments
received from you and other reviewers.

Please see inline for details.

On Fri, Nov 22, 2024 at 10:36 AM Brian Haberman via Datatracker <
[e-mail]> wrote:

> Reviewer: Brian Haberman
> Review result: Ready with Nits
>
> I am an assigned INT directorate reviewer for
> <draft-ietf-bess-evpn-irb-extended-mobility>. These comments were written
> primarily for the benefit of the Internet Area Directors. Document editors
> and
> shepherd(s) should treat these comments just like they would treat comments
> from any other IETF contributors and resolve them along with any other Last
> Call comments that have been received. For more details on the INT
> Directorate,
> see https://datatracker.ietf.org/group/intdir/about/
> <https://datatracker.ietf.org/group/intdir/about/>
>
> As with other directorate reviews, I will note that portions of this draft
> are
> difficult to read primarily due to the content being very targeted to
> experts
> in the EVPN space. The comments below, in my mind, are nits as implementers
> will be able to fill in the gaps that are addressed in other
> specifications.
>
> 1. The document assumes, without justifying, that the existing sequence
> number
> approach is the best way to solve the various mobility scenarios. It is
> quite
> possible that other approaches for handling mobility may be more efficient
> in
> the long run.
>

[NM]: ack. Given that this document is an enhancement on top of RFC 7432
and RFC 9135, new mechanisms were not considered in the scope of this
document. They can however be proposed independently.


>
> 2. I was not able to dig into all of the existing specifications, but I am
> curious as to why the case of new MAC + new IP doesn't need to be handled.
> I
> would assume such a situation in an EVPN should be handled as a new
> instance of
> a VM, but wanted to get clarity.
>

[NM]: yes, sequence number inheritance and assignment methods specified in
section 6 of this document are applicable to a new MAC + new IP as well.
When applied to a new MAC + new IP, they would result in the lowest
sequence number chosen by an implementation for a new local route
(typically 0) to be assigned.


>
> 3. RFC 7432 only says that sequence number wrapping needs to be handled,
> but
> doesn't specify how it should be handled. With this document redefining
> assignment of these sequence numbers, I think it would be wise to specify
> how
> wrapping should be handled to ensure clear interoperability.
>

[NM]: I did discuss this with other authors. We concluded that with the
existing mechanism for duplicate address detection in place, this can only
happen when the actual number of legitimate moves for a host exhausts the
32 bit / 4 billion sequence number space. For a host that moves every
minute, this amounts to ~7K years. In other words, not likely to run into.
If at all, we still decide to specify a handling for sequence number
wrapping in future, we should be able to add this to 7432bis draft.


>
> 4. Section 6.8 discusses optional ways to speed convergence. There is
> notional
> text in there discussing ARP/ND probing. Should there be mention of more
> explicit techniques such as gratuitous ARP/ND messages from the host? For
> IPv6,
> snooping MLD messages of hosts joining the All-Nodes group?
>

[NM]: Intent of this section is to describe PE behavior and specifically
triggers for proactive ARP/NDP probing from a PE that can help improve
convergence following a host move. Host side behavior such as Grat ARP is
not considered within the scope of this document. PE implementations do
typically use a variety of snooping policies for host learning but that are
dependent on packets (MLD, DHCP, etc.) independent of mobility. These,
however, are dependent on host behavior and may not always guarantee faster
convergence.

Thanks,
Neeraj