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

On Wed, Jul 24, 2019 at 9:06 PM Pascal Thubert (pthubert)
<pthubert@cisco.com> wrote:
> Another thing that the draft should do imho is a more comprehensive review of the problems that are associated with reactive. Coming from the router side I’m probably more sensitive to that than others and I’d de happy to contribute.

Thanks for offering your help, Pascal!
However I have some reservations about turning this particular
document into 'reactive behaviour of ND problem statement'. First of
all it does sound a bit biased towards a particular solution which
makes me think that such analysis should belong to 6man@.  I'm not
saying such document shouldn't exist, I'm just not sure such analysis
belongs to this draft.

> > Le 23 juil. 2019 à 21:53, Brian E Carpenter <brian.e.carpenter@gmail.com> a écrit :
> >
> > 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
> >> .
> >>
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
SY, Jen Linkova aka Furry