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

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

Hi, 

----- Original Message -----
From: Erik Nordmark <erik.nordmark@sun.com>
Date: Monday, March 14, 2005 7:21 pm
Subject: Re: [DNA] Comments on draft-narayan-dna-hosts-bcp

> Greg Daley wrote:
> 
> > I'm starting to think that the possibility
> > of them not being on a wired segment 
> > is increasing with time.
> 
> Having the routers float around in some wireless L2 mesh is ok as 
> long 
> as the packet loss rate is not too much higher for multicast than 
> unicast.And if the packet loss rate is much higher for multicast 
> than unicast 
> then I think we have more issues are ND (NS/NA address resolution, 
> DAD, 
> and router discovery all use multicast).
> But this seems to have little to do with DNA.

Agreed.
 
> FWIW A long time ago I did a partial sketch on a ND variant which 
> could 
> be used to minimize multicast by having hosts register their IP->L2 
> mappings with some agents on the link (and the agents could be the 
> routers) and then do implicit or explicit unicast queries of these 
> agents instead of using multicast DAD and NS.
> In such a scheme multicast would only be needed when no agent 
> addresses 
> are known on the link.

Indeed, it would virtually become an NBMA network.

There was also work by Grenville Armitage 
with MARS/IPv6 over ATM which may be a
heavier mechanism that covers similar issues.


> 
> > With regard to optimizations, 802.11 itself
> > treats Router Solicitations as Unicast, when going 
> > to the DS (wired side).  So the host won't
> > prejudice itself just from the RS.
> 
> Is this a standard, or just something some 802,11 device drivers do?

This is part of 802.11, which comes from 
having the toDS bit set. (which specifies
use of the three address format, with the
AP as a unicast next step forwarding address).

I can dig out the stanza number if you like.
 
> > Should we put some consideration for the
> > router side document to indicate that
> > in some situations downstream multicast is
> > more unreliable than unicast?
> 
> FWIW It isn't clear to me whether the "router side document" is a 
> BCP 
> for the operational folks (who can control which routers advertise 
> which 
> prefixes etc) or the folks that implement routers (who can change 
> the 
> routers to unicast more and multicast less).
> 
> Shouldn't the latter (the "recommendations for those that modify 
> the 
> router code") be to implement the DNA solution?
> 
> In any case, I think the DNA solution should be done so that 
> solicited 
> RAs are unicast in most cases (but if there are 100 RSs per second, 
> then 
> it might make sense to respond with a single multicast RA).
> Unicasting the RAs in the solution is rather natural since we want 
> to 
> make the RA delivery be fast.

Yes this should be relied upon in the standard.

I think that in the case that these 
options can already be configured, Such as with
RADVD and its UnicastOnly flag, the advice
can be offered today though.

It's allowed in the existing standard, so if it's
available, people can take advantage of it.

 
> 
> >>I'm having a hard time understanding what this means. We have NUD 
> >>in all 
> >>cases, thus sooner or later the host will detect if one of the 
> >>default 
> >>routers isn't working. Are you saying that such information 
> should 
> >>be 
> >>"exported" to L2 so that L2 can use it to make handover decisions?
> > 
> > 
> > 
> > No, it's already being done with RA setting
> > the STALE flag.  The question is whether we need
> > to do anything more.
> 
> Ah.
> 
> > The STALE flag causes at least 5 seconds delay.
> > If that's OK for this rare case then we may or may
> > not may a statement on the issue...
> 
> Presumably we want a DNA solution that after the RS/RA exchange, 
> the 
> router which responded (with a unicast) is marked as reachable. 
> That 
> doesn't mean it was the same as any previous router on the link, 
> but it 
> provides more NUD information to the host at no additional cost.

Certainly, otherwise there will be a check within
a few seconds after (but that doesn't need 
specification here).


> > Let's get an issues list made up based on your
> > review and the discussion here (am in Atlanta,
> > so it may be a bit tardy).
> 
> ok
> 
> > Then when we get a new version of the framework
> > draft, we can see where the text best fits.
> 
> It isn't going to be perfect, but I started the edits to the 
> framework 
> draft on Friday so hopefully I'll have something to send out in a 
> few days.

Thanks,

Greg