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

From: Sathya Narayanan <[email-masked]>
Date: Mon, 07 Mar 2005 23:16:33 -0500

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.
>  - 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?

>  - the draft includes suggestions or recommendations which don't 
> seem 
> to add much to the capability (such as verifying the routers 
> global 
> addresses in addition to the prefixes), which just adds to the 
> complexity 
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 includes suggestions or recommendations 
> which are 
> optimizations (such as doing a NS/NA exchange with a old default 
> router, 
> in addition to the RS/RA exchange), and it would be good to flag 
> these 
> as optimizations. Once we have a DNA protocol (with changes on the 
> router for fast delivery of RAs etc), such optimizations might 
> actually be counterproductive (they might just add load to the link), thus 
> I think we should be very careful about recommending this.

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

> 
> So while the draft has useful background information on the constraints, 
> but I'd suggest that we start from scratch on writing down the recommendations.
I hope my responses above will make you re-consider this suggestion. I think there is a good amount of things, both in terms of content and structure in the draft that is useful for the BCP. We can incorporate your suggestions  below in the appropriate sections.

> I think the list of recommendations is quite short. Here is a guess at a list:
>  - hosts should implement optimistic DAD (to reduce any DAD-related delays)
>  - hosts should have a mechanism by which the L2 (the device 
> driver) can
>    notify the upper layers when a new L2 connection has been 
> established    and can send and receive packets
>  - hosts which can connect to different L2 connections at the 
> same time
>    (for instance, an 802.11 card with two radios which can associate
>    with two different APs at the same time) should not hide the fact
>    that there are two interfaces but instead expose this to IP as
>    separate interfaces
>  - hosts should implement CPL
>  - when a L2 "link up" notification is received by IP, it should 
> switch    to optimistic DAD mode since it might have moved to a 
> different link
>    where the addresses are not unique
> 	- This includes sending the MLD join for the solicited node
>          multicast group(s)
> 	- The RS for CPL is sent in while in optimistic mode
>  - should CPL detect that the the host has moved to a different link,
>    then any other multicast groups need to be reported using MLD
>    (optionally, this can be done while in optimistic mode?)
>  - should CPL detect that the host has NOT moved to a different link,
>    then the optimistic mode can be turned off
> 
> It think that's the minimum useful set for L2 agnostic DNA BCP.
> 
> Comments?
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.

thanks,
Sathya

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 08 Mar 2005 11:54:01 -0800

Sathya Narayanan wrote:
>>  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)
> 

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