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

[Greg Daley <Greg.Daley@eng.monash.edu.au>]

Hi Erik, 

----- Original Message -----
From: Erik Nordmark <erik.nordmark@sun.com>
Date: Tuesday, March 8, 2005 10:31 am
Subject: [DNA] Comments on draft-narayan-dna-hosts-bcp

> 
> Since nobody is paying attention to jabber, I can't contribute in 
> real time.


Sorry, we're not up with the latest technology.
We'll try to get it rectified for Thursday
(it maynot be so important for you then).

> 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,)

Fair enough.

>  - the draft is quite long (partly because it goes into discussing 
> all 
> the different constraints)
>  - 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  - 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.

Definitely.

The length may not be something which canbe handled, without
explicit rationalization of text. I'mglad that you've started on this
below.

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

!

We may be able to salvage something !!!


Seriously though.  If we're working on the recommendations which
is there any validity in the structure?



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

Sounds good.  

I'll have time to comment on each in turn later (batteries)

It's nice to have the feedback.

Can we compile a list here on-list (or on an issue-list) and vet
the concepts before inclusion into the next version?

Hope to see you soon,

Greg