Re: [DNA] Comments on draft-narayan-dna-hosts-bcp

[Erik Nordmark <erik.nordmark@sun.com>]

Sathya Narayanan wrote:
> Erik -
> 
> Thanks for your comments.
> 
> <snip>
> 
>> I have rather serious concerns about basing the hosts BCP draft on
>>  the text in this draft for several reasons. The high-level ones
>> are: - the draft is written to much in a negative form (e.g., make
>>  sure you take this constraint into account) instead of a list of
>> positive suggestions (do X, then Y,)
> 
> I am not sure if this is entirely true about the draft. I have been
> emphasizing the following point about this draft - there are two
> parts to it - one the sections until 6 which is generic DNA related
> recommendations and the rest specific/extra information. I will try
> to make this point in the draft itself for the next version. Your
> comment about 'negative form' is possibly true in the second half.

But even the first half doesn't have much concrete suggestions.
For instance, I don't see any text in that part suggestion
  - to perform optimistic DAD when a "link up" is received
  - to immediately terminate the optimistic mode if it turns out that the
    host hasn't moved to a different link

It is equally silent on MLD.

>> - the draft is quite long (partly because it goes into discussing
>> all the different constraints)
> 
> Yes - because of the additional information. Do you feel that these
> additional sections are not useful?

I think they add confusion to what an implementor needs to do to follow 
the recommendations. Hence I'd argue for as short as possible, perhaps 
with design rationale as an appendix.

> I am not sure which line in the draft makes this recommendation. Can
> you please point it out to me? I don't think that was our intention
> ever?
> 

The draft says:
    Confirming bi-directional reachability with the default router
    implicitly provides verification for the IP configuration.

I was assuming that this meant to a global address of the router, since 
both the link-local addresses and L2 addresses are not guaranteed to be 
globally unique for all interfaces. For instance, a router is free to 
use the same L2 address and link-local address on all its interfaces.

So perhaps I was jumping to conclusions, but if I did, the above 
suggestion in the draft is plain broken.

> Agreed. Would you prefer that we remove this section  6.1.4?

I think I was actually impolite enough to suggest we start from scratch, 
taking all the thinking that has gone into this draft into account.

> I think you are recommending that the BCP become a small addition to
> CPL and point to CPL for everything. As I mentioned today in the
> meeting, right now, the BCP points to CPL for inferring 'link-change'
> but has recommendations on inferring 'same-link'. I am not sure about
> this - I need to think about it.

See above whether some of those "same link" suggestions are broken or not.

I actually don't see the need for "same link" detection that is separate 
from CPL's movement detection; it just adds complexity.
(Yet, I do acknowledge that a NS/NA exchange with the global address of 
an old router is currently faster than a RS/RA exchange due to the 
random delays in the latter. But once we get routers supporting the DNA 
solution, which will include immediate RAs being returned, then applying 
that optimization will be extra packets to no benefits.)

I do really care about the WG developping a compact set of 
recommendations, and making them easily understandable for an 
implementor. But I don't really care who authors which draft or RFC, 
thus I'm not trying to argue that the CPL draft is the best basis for a BCP.

    Erik