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

[Sathya Narayanan <sathya@research.panasonic.com>]

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