Re: Barry Leiba's No Objection on draft-ietf-6man-resilient-rs-05: (with COMMENT)

Suresh Krishnan <suresh.krishnan@ericsson.com> Mon, 16 March 2015 05:12 UTC

From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>
Subject: Re: Barry Leiba's No Objection on draft-ietf-6man-resilient-rs-05: (with COMMENT)
Thread-Topic: Barry Leiba's No Objection on draft-ietf-6man-resilient-rs-05: (with COMMENT)
Thread-Index: AQHQXaHW26Jx7m2bzkSIfRPI4dhZ7g==
Date: Mon, 16 Mar 2015 05:12:33 +0000
Message-ID: <E87B771635882B4BA20096B589152EF628B2460F@eusaamb107.ericsson.se>
References: <20150313152437.30738.60495.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/EtPwy98LYRVV3AFXgN4QRjMIdD4>
Cc: "ot@cisco.com" <ot@cisco.com>, "draft-ietf-6man-resilient-rs.all@ietf.org" <draft-ietf-6man-resilient-rs.all@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, "6man-chairs@ietf.org" <6man-chairs@ietf.org>
Precedence: list

Hi Barry,
   Thanks for your comments. Please find responses inline.

On 03/13/2015 11:24 AM, Barry Leiba wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> -- Section 1 --
>
>     In certain scenarios, these router solicitations
>     transmitted by the host might be lost. e.g. The host is connected to
>     a bridged residential gateway over Ethernet or WiFi.  LAN
>     connectivity is achieved at interface initialization, but the
>     upstream WAN connectivity is not active yet.
>
> Purely minor editorial: I got a little tangled in that, and suggest tying
> it together better this way:
>
> NEW
>     In certain scenarios, these router solicitations
>     transmitted by the host might be lost. For example, if the
>     host is connected to a bridged residential gateway over
>     Ethernet or WiFi, LAN connectivity is achieved at interface
>     initialization but the upstream WAN connectivity is not
>     yet active.
> END

Sounds good. Will make this change.

>
> -- Section 3 --
>
>     Implementations of this specification MAY provide a configuration
>     option to enable or disable the use of such potentially infinite
>     retransmissions.  If the implementation provides such a configuration
>     option, it MUST be able to enable/disable retransmissions on a per-
>     interface basis.
>
> I find this a slightly odd usage of MAY and MUST: you're making the
> configuration option entirely optional, but then you're saying that if I
> have that configuration option, it MUST work a certain way.  Is it really
> better not to be able to disable the infinite retransmissions at all,
> than to make it all or nothing?  What is harmed by having a configuration
> option that affects all interfaces at the same time... that is worse than
> not having that configuration option at all?

The mechanism specified in the draft is more robust that the default 
algorithm specified in RFC4861. The intent is to let this become the 
default RS sending algorithm for newer implementations.

Now consider a host with multiple interfaces, with one of them being 
attached to a link that is not IPv6 enabled. The administrator might 
wish to manually turn off RS sending on that link since it will simply 
cause traffic without any benefits. Without interface-level granularity 
such scenarios will lead to resilient RS being turned off on all 
interfaces, and hence will lead to lower reliability on the hosts' 
interfaces attached to IPv6 enabled links. Hence the MUST. Does that 
clarify things a bit? If not, we can work on rewording it.

Thanks
Suresh

Re: Barry Leiba's No Objection on draft-ietf-6man… Suresh Krishnan
Barry Leiba's No Objection on draft-ietf-6man-res… Barry Leiba