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 <noreply@xxxxxxxx> 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
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
