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

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

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

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

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