MIME-Version: 1.0
References: 
 <173230056584.188.6761580363738894727@dt-datatracker-bd58d7968-z29pc>
In-Reply-To: 
 <173230056584.188.6761580363738894727@dt-datatracker-bd58d7968-z29pc>
From: Neeraj Malhotra <neeraj.ietf@gmail.com>
Date: Mon, 2 Dec 2024 17:50:50 -0800
Message-ID: 
 <CAF3QiHFuM7mDi=CY8j1Vf1fpg8UEXs54uGnd3zqB2UU3Jp3G2A@mail.gmail.com>
To: Brian Haberman <brian@innovationslab.net>
Content-Type: multipart/alternative; boundary="000000000000ad7789062853e520"
Message-ID-Hash: G7254QI2M57ONZVIDIZNR75Z6XPO4MNT
CC: int-dir@ietf.org, bess@ietf.org,
 draft-ietf-bess-evpn-irb-extended-mobility.all@ietf.org, last-call@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BInt-dir=5D_Re=3A_=5Bbess=5D_Intdir_telechat_review_of_draft-iet?=
	=?utf-8?q?f-bess-evpn-irb-extended-mobility-18?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/int-dir/LZbWPPFcUSishfZdINfJfiHeBlU>

--000000000000ad7789062853e520
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFAM Brian Haberman via Datatracker <
noreply@ietf.org> 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 editor=
s
> and
> shepherd(s) should treat these comments just like they would treat commen=
ts
> from any other IETF contributors and resolve them along with any other La=
st
> 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 draf=
t
> 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 implemente=
rs
> 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 efficien=
t
> 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 a=
m
> 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

--000000000000ad7789062853e520
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div>Hi Brian,</div><div><br></=
div><div><div>Thanks for the review and comments. Have uploaded rev19 to ad=
dress comments received from you and other=C2=A0reviewers.=C2=A0</div><div>=
<br></div><div>Please see inline for details.</div></div><br><div class=3D"=
gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On=
 Fri, Nov 22, 2024 at 10:36=E2=80=AFAM Brian Haberman via Datatracker &lt;<=
a href=3D"mailto:noreply@ietf.org">noreply@ietf.org</a>&gt; wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);=
padding-left:1ex">Reviewer: Brian Haberman<br>
Review result: Ready with Nits<br>
<br>
I am an assigned INT directorate reviewer for<br>
&lt;draft-ietf-bess-evpn-irb-extended-mobility&gt;. These comments were wri=
tten<br>
primarily for the benefit of the Internet Area Directors. Document editors =
and<br>
shepherd(s) should treat these comments just like they would treat comments=
<br>
from any other IETF contributors and resolve them along with any other Last=
<br>
Call comments that have been received. For more details on the INT Director=
ate,<br>
see <a href=3D"https://datatracker.ietf.org/group/intdir/about/" rel=3D"nor=
eferrer" target=3D"_blank">https://datatracker.ietf.org/group/intdir/about/=
</a><br>
&lt;<a href=3D"https://datatracker.ietf.org/group/intdir/about/" rel=3D"nor=
eferrer" target=3D"_blank">https://datatracker.ietf.org/group/intdir/about/=
</a>&gt;<br>
<br>
As with other directorate reviews, I will note that portions of this draft =
are<br>
difficult to read primarily due to the content being very targeted to exper=
ts<br>
in the EVPN space. The comments below, in my mind, are nits as implementers=
<br>
will be able to fill in the gaps that are addressed in other specifications=
.<br>
<br>
1. The document assumes, without justifying, that the existing sequence num=
ber<br>
approach is the best way to solve the various mobility scenarios. It is qui=
te<br>
possible that other approaches for handling mobility may be more efficient =
in<br>
the long run.<br></blockquote><div><br></div><div>[NM]: ack. Given that thi=
s document is an enhancement on top of RFC 7432 and RFC 9135, new mechanism=
s were not considered in the scope of this document. They can however be pr=
oposed independently.</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-styl=
e:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
2. I was not able to dig into all of the existing specifications, but I am<=
br>
curious as to why the case of new MAC + new IP doesn&#39;t need to be handl=
ed. I<br>
would assume such a situation in an EVPN should be handled as a new instanc=
e of<br>
a VM, but wanted to get clarity.<br></blockquote><div><br></div><div>[NM]: =
yes, sequence number inheritance and assignment methods specified in sectio=
n 6 of this document are applicable to a new MAC=C2=A0+ new IP as well. Whe=
n applied to a new MAC=C2=A0+ new IP, they would result in the lowest seque=
nce number chosen by an implementation for a new local route (typically 0) =
to be assigned.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:soli=
d;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
3. RFC 7432 only says that sequence number wrapping needs to be handled, bu=
t<br>
doesn&#39;t specify how it should be handled. With this document redefining=
<br>
assignment of these sequence numbers, I think it would be wise to specify h=
ow<br>
wrapping should be handled to ensure clear interoperability.<br></blockquot=
e><div><br></div><div>[NM]: I did discuss this with other authors. We concl=
uded that with the existing mechanism for duplicate address detection in pl=
ace, 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.<=
br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-lef=
t-color:rgb(204,204,204);padding-left:1ex">
<br>
4. Section 6.8 discusses optional ways to speed convergence. There is notio=
nal<br>
text in there discussing ARP/ND probing. Should there be mention of more<br=
>
explicit techniques such as gratuitous ARP/ND messages from the host? For I=
Pv6,<br>
snooping MLD messages of hosts joining the All-Nodes group?<br></blockquote=
><div><br></div><div>[NM]: Intent of this section is to describe PE behavio=
r and specifically triggers for proactive ARP/NDP probing from a PE that ca=
n help improve convergence following a host move. Host side behavior such a=
s Grat=C2=A0ARP is not considered within the scope of this document. PE imp=
lementations do typically use a variety of snooping policies for host learn=
ing but that are dependent on packets (MLD, DHCP, etc.) independent of mobi=
lity. These, however, are dependent on host behavior and may not always gua=
rantee faster convergence.=C2=A0</div><div><br></div><div>Thanks,</div><div=
>Neeraj</div><div><br></div></div></div>

--000000000000ad7789062853e520--