MIME-Version: 1.0
In-Reply-To: <52E03BB4.8040309@acm.org>
References: <CAKD1Yr29S=O5L4DfhNoiVieWPkgBJ2veuOu6ig5rwgK4ELz7Xw@mail.gmail.com>
 <52D96663.6060005@sonic.net>
 <CAKD1Yr3pCQ15uFz36MvKG3Q_Vzt27ws0aG1=94377FFaJtWV7g@mail.gmail.com>
 <52DA0ABA.8030903@acm.org>
 <CAKD1Yr1zSfAOv8j9XgB_ph9uaUUNW0yrJhfjJTsSTYHNKYNx9A@mail.gmail.com>
 <52E03BB4.8040309@acm.org>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Wed, 22 Jan 2014 14:48:34 -0800
Message-ID: <CAKD1Yr2CjJ=J_YOBMK7NwBgjNUvVf348VhTEDZ5eWiw-6xCMXg@mail.gmail.com>
Subject: Re: Reducing the battery impact of ND
To: Erik Nordmark <nordmark@acm.org>
Content-Type: multipart/alternative; boundary=089e0111e0daf6d82104f096ed2b
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG <ipv6@ietf.org>,
 =?UTF-8?Q?Andrew_=F0=9F=91=BD_Yourtchenko?= <ayourtch@gmail.com>
Precedence: list

--089e0111e0daf6d82104f096ed2b
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 22, 2014 at 1:44 PM, Erik Nordmark <nordmark@acm.org> wrote:

> The approach you advocate is insufficient to ensure better robustness for
> at least two reasons:
>   - the lifetime(s) of the prefixes are independent of the lifetimes of
> the default routers. Hence in this approach a host can have default routers
> but no prefixes.
>

This can be tricky to implement, but in principle, the host has this
information already.


>  - the reachability state in the NCEs is independent of the default router
> list - per RFC 4861 the router stays in the default router list even if it
> is unreachable. Thus your last router might be unreachable but with
> remaining lifetime - it was the next-to-last router in the list that was
> reachable.
>
> Solving those without risking hosts sending lots of RSs during failure
> events or resulting in a steady state of RSs from hosts seems tricky.


I agree that there are a lot of corner cases here.


> Changing from periodic RAs to (effectively) periodic RSs as you propose
> would change RFC 4861 is a very fundamental way.
>
> It may or may not be the right thing to do for the future, but I think
> that requires a bit more work then forcing some edits into a document which
> has almost completed the WG process. I think resilient-rs has significant
> benefits in its current form and scope.
>

Fair enough. That said - if that's what we want to do, then resilient-rs
should make it clear that it is only for initial solicitations and thus
does not specify or allow behaviour on multicast-capable links where there
are no periodic multicast RAs, because the IPv6 standards as written do not
work on such links.

--089e0111e0daf6d82104f096ed2b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jan 22, 2014 at 1:44 PM, Erik Nordmark <span dir=3D"ltr">&lt;<a href=3D=
"mailto:nordmark@acm.org" target=3D"_blank">nordmark@acm.org</a>&gt;</span>=
 wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><span style=3D"color:rgb(3=
4,34,34)">The approach you advocate is insufficient to ensure better robust=
ness for at least two reasons:</span><br>

</div>
=C2=A0- the lifetime(s) of the prefixes are independent of the lifetimes of=
 the default routers. Hence in this approach a host can have default router=
s but no prefixes.<br></blockquote><div><br></div><div>This can be tricky t=
o implement, but in principle, the host has this information already.</div>

<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
=C2=A0- the reachability state in the NCEs is independent of the default ro=
uter list - per RFC 4861 the router stays in the default router list even i=
f it is unreachable. Thus your last router might be unreachable but with re=
maining lifetime - it was the next-to-last router in the list that was reac=
hable.<br>


<br>
Solving those without risking hosts sending lots of RSs during failure even=
ts or resulting in a steady state of RSs from hosts seems tricky.</blockquo=
te><div><br></div><div>I agree that there are a lot of corner cases here.</=
div>

<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"><span sty=
le=3D"color:rgb(34,34,34)">Changing from periodic RAs to (effectively) peri=
odic RSs as you propose would change RFC 4861 is a very fundamental way.</s=
pan><br>

</div>
<br>
It may or may not be the right thing to do for the future, but I think that=
 requires a bit more work then forcing some edits into a document which has=
 almost completed the WG process. I think resilient-rs has significant bene=
fits in its current form and scope.<br>

</blockquote><div><br></div><div>Fair enough. That said - if that&#39;s wha=
t we want to do, then resilient-rs should make it clear that it is only for=
 initial solicitations and thus does not specify or allow behaviour on mult=
icast-capable links where there are no periodic multicast RAs, because the =
IPv6 standards as written do not work on such links.</div>

</div></div></div>

--089e0111e0daf6d82104f096ed2b--