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

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

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.

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.


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

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


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


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

> Does this sound like a plan?

ok

    Erik