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

[Fernando Gont <[e-mail]>]

On 23/7/19 20:51, Jen Linkova wrote:
> On Wed, Jul 24, 2019 at 4:39 AM Fernando Gont <[e-mail]> 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".
> 
> I'm confused. I'm not sure I understand how you came to the conclusion
> that we are trying fix the protocol in v6ops because 6man wouldn't do
> this.

This part of section 3,
   o  Hosts SHOULD send at least one unsolicited NA packet to all-
      routers multicast address (ff02::2) as soon as one of the
      following events happens:

      *  (if Optimistic DAD is used): a new Optimistic GUA is assigned
         to the host interface.

      *  (if Optimistic DAD is not used): a GUA changes the state from
         tentative to preferred.

seems to me a protocol update.

In any case, my comment was meant to say "if there's a problem to be
solved, don't be shy..there's nothing scary about updating the protocol
spec"


> First of all, main goal of the draft in question is to describe an
> operational problem and discuss potential ways to deal with it.

That's certainly perfectly fine and valuable, per-se.



> Based on the analysis the draft currently suggests that there  are
> "valid reasons in particular circumstances when the particular
> behavior (violate SHOULD NOT and create a STALE entry upon receiving
> an unsolicited NA) is acceptable or even useful".

It would seem to me that when a spec says "SHOULD/SHOULD NOT", there's
leeway for implementations to don't follow that. However, if there is a
case where the default advice actually is the opposite, one should
update the original advice/requirement.



> It does not change
> ND as a protocol because RFC4861 does allow such behaviour (otherwise
> it would have said 'MUST NOT') so I'm inclined to say that it's not a
> protocol change..




If one were to pursue this way of solving the problem, wouldn't we want
the default advice to contradict (SHOULD vs SHOULD NOT) what's in RFC4861
> However I see why it might be seen as a protocol change and I'm
> willing to either:
> - write an additional 1-page draft for 6man updating 4861 based on
> analysis provided in this draft;
> - get this draft adopted and/or reviewed by 6man
> - whatever other ways to make sure all appropriate  reviews are done, " full
>    implications should be understood and the case carefully weighed" etc ;)

I'd say describe the problem and evaluate possible solutions in 6man. If
v6ops sees that the change in RFC4861 is warranted, then the operational
advice from v6ops should make it happen in 6man.



> Anyway, as I've said, I have no problem go to 6man with it - but I
> guess we need to look at all proposed solutions, decide which way we
> want to go and, if RFC4861 needs to be updated - well, I guess it
> SHOULD be easy ;)

Indeed! ;-)


-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492