Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft

[Brian E Carpenter <[e-mail]>]

As has been extensively discussed on another thread, we sadly lack a method
of getting operational notes with *rough* consensus out quickly, because
our process for BCP, or worse for standards track, can take years instead
of weeks.

Y'all can prove me wrong by sending this draft to the IESG in a month
or so, and then worry about updating RFC4861 at normal IETF speed.

(After writing that, I am a bit embarassed that RFC6343 took six months.)

Regards
   Brian

On 24-Jul-19 07:19, David Lamparter wrote:
> On Tue, Jul 23, 2019 at 06:59:23PM +0100, Fernando Gont wrote:
>> On 23/7/19 12:39, Brian E Carpenter wrote:
>>> 1) Yes, we should *obviously* do this.
>>> 2) If the charter prevents that, fix the charter.
>>
>> I'm all for fixing problems and getting stuff done. And, if there's no
>> other way than fixing the charter, so be it.
>>
>> However, it would seem to me that, the "bug" here is that we're
>> defaulting to "6man wouldn't get this done, so let's do it elsewhere".
> 
> The discussion I see here is that we've located an operational issue
> with the IPv6 neighbor cache on routers, we have several candidates for
> fixing it, and each of these may or may not need a protocol change to go
> through 6man.
> 
> Discussing whether any particular working group "gets things done" seems
> tangential to the question at hand.
> 
>> IMO, should be willing to maintain its protocols, improve them, and fix
>> problems where necessary.
>>
>> If a BCP is to go against the protocol spec recommendation for the
>> general case, that's an indication that the protocol should be updated.
> 
> Although I don't write the neighbour management code, I do write code
> that operates routers and I have absolutely no concerns in understanding
> that a particular "SHOULD" statement has turned out to be a bad choice
> for the specific situation of first-hop routers.
> 
> Whether this is a specification change, to me, is decided by the intent.
> The intent under consideration here is:
> 
>    When a valid Neighbor Advertisement is received (either solicited or
>    unsolicited), the Neighbor Cache is searched for the target's entry.
>    If no entry exists, the advertisement SHOULD be silently discarded.
>    There is no need to create an entry if none exists, since the
>    recipient has apparently not initiated any communication with the
>    target.
> 
> The intent I see is that in most cases there's no point in having
> devices consume memory, and the "SHOULD" is correct behaviour for hosts.
> Routers *DO* "need to create an entry if none exists".  I don't see a
> conflict with 4861's intent, which I take as "don't open yourself to DoS
> attacks".  The router /will have the neighbor cache entry anyway/, just
> with a delay, later, and the resulting annoyance.
> 
> 4861 just failed to invoke the magic 8-ball correctly to make the
> authors omniscient and recognize the specific circumstances under which
> this SHOULD is maybe not the best idea.  This is implementation guidance
> based on operational experience.  Just write it down and get it out
> there.
> 
> 
> -David
> .
>