Re: Spencer Dawkins' Discuss on draft-ietf-6man-resilient-rs-05: (with DISCUSS and COMMENT)

[Suresh Krishnan <[e-mail]>]

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

On 04/07/2015 11:07 AM, Spencer Dawkins at IETF wrote:
> Hi, Brian,
>
> On Tue, Apr 7, 2015 at 8:30 AM, Brian Haberman <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Hi all,
>
>     On 4/6/15 11:07 PM, Spencer Dawkins wrote:
>      > Spencer Dawkins has entered the following ballot position for
>      > draft-ietf-6man-resilient-rs-05: Discuss
>      >
>      > When responding, please keep the subject line intact and reply to all
>      > email addresses included in the To and CC lines. (Feel free to
>     cut this
>      > introductory paragraph, however.)
>      >
>      >
>      > Please refer to
>     http://www.ietf.org/iesg/statement/discuss-criteria.html
>      > for more information about IESG DISCUSS and COMMENT positions.
>      >
>      >
>      > The document, along with other ballot positions, can be found here:
>      > http://datatracker.ietf.org/doc/draft-ietf-6man-resilient-rs/
>      >
>      >
>      >
>      >
>     ----------------------------------------------------------------------
>      > DISCUSS:
>      >
>     ----------------------------------------------------------------------
>      >
>      > I'm piling on Barry's Comment as a Discuss, which should be easy to
>      > discuss, but ... in this text:
>      >
>      > 3.  Configuring the use of retransmissions
>      >
>      >    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.
>      >
>      > You can tell me that it's a LAN, so the transport ADs can go back to
>      > sleep, but I was surprised that this configuration option was a MAY.
>      >
>      > I was also surprised that there was no guidance about the default
>     setting
>      > (on or off), but let's start with the MAY.
>      >
>      > IP does get tunneled to new and exciting places ... and infinite
>      > retransmissions are infinite ...
>
>     I went back and re-read Barry's Comment and the resulting response and
>     felt unsatisfied.
>
>     Barry & Spencer, let me know if I am misinterpreting your concerns...
>
>     It appears odd to give such concrete guidance as "enable/disable
>     retransmissions on a per-interface basis" for a function that is
>     completely optional.  After some thought, I am trying to figure out why
>     it would be optional since typical NA/NS/RA/RS functionality is
>     per-interface anyway.
>
>     Given what is being described, I would think we would want to encourage
>     implementers to provide a configuration option rather than make it
>     optional.  The text could be re-written (without 2119 keywords) as such:
>
>     NEW:
>     Implementations of this specification are encouraged to provide a
>     configuration option to enable or disable potentially infinite RS
>     retransmissions. Providing an option to enable/disable retransmissions
>     on a per-interface basis allows network operators to configure RS
>     behavior most applicable to each connected link.
>
>
> So, without 2119 keywords, I'd prefer "strongly encouraged", but
> "encouraged" is an improvement.
>
> My other point was - if there's a  configuration option for this, I
> would prefer that the group make a recommendation about default settings.

Sounds good.

>
> I'd prefer "off by default", but could be convinced that "on by default"
> has benefits that outweigh the costs.

I am not exactly sure what you mean by "off by default" but the goal is 
to enable persistent RS sending by default for increasing the robustness 
for ND. If you mean that the option to disable should be "off by 
default", I fully agree and can make the change right away.

Thanks
Suresh