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

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

Greg Daley wrote:
> Personally, I di think that some level of
> reachability detection is required.
> 
> I'm not sure if it's fodder for the document.
> Is the existing 2461/bis document sufficient?
> 
> There was some indication of why downlink and
> uplink packet flows (and unicast/multicast)
> are assymetric in their reachability properties.
> Do you think there is unnecessary to have
> here?  Is it unnecessary anywhere?

Greg,

Perhaps there are flaky links where NUD as currently defined is 
suboptimal (or, alternatively, those links are just to flaky for real 
use). But the issue is whether this has anything to do with DNA.

The suggestion in the draft is that when there is a hint from L2 that 
something might have changed (could be cause by associating with a 
different 802.11 AP for instance), it is important to reverify 
bidirectional reachability with the router.
I don't see this helping in the example case of 802.11 with the routers 
on a wired network behind the APs (and I can't come up with a real-world 
example where it would be useful.)

In the 802.11 example case, the association procedure means that the 
station has bidirectional reachability to the new AP.
The wired Ethernet between the APs and the router(s) is well-behaved in 
that it has transitive and reflexive reachability. This means that if 
the router was bidirectionally reachable from one of the APs it will 
also be from the other AP, except in the extremely rare case that a 
partial failure occurs on the wired Ethernet (a network partition, a 
switch port or cable failing or becoming unidirectional, etc).
Such failures are extremely rare, but the key point is that there isn't 
any correlation between such failures and a host moving from one AP to 
another.
So even if these failures in the wired Ethernet where quite common, it 
wouldn't make sense to only do aggressive verification after a L2 hint; 
instead you'd want to uniformly be more aggressive with respect to NUD.
And given that these failures are extremely rare, I suspect the current 
NUD timers are fine.

Do you have a case where 1) checking for bidirectional reachability 
after the L2 hint is critical and 2) frequent checking for bidirectional 
reachability when these is no hint (hence no L2 change) is not needed?

I can't think of one, but it could be my stuffy head this week...


>> background
>> assumptions (which goes into the L2 "link up" hint)
> 
> 
> We had a section on initiation.
> Does some of that go in here?
> 
> There's a lot of detail about 
> Hysteresis, Trust of Hints, Simultaneous Hints
> etc in the draft-narayana-dna-hosts-.
> 
> Is this:
> 
> a) inappropriate
> b) poorly written
> c) too verbose
> d) partly applicable.

I haven't read that part of the draft yet, but my gut feel is that it is 
partly applicable, and it might very well be possible to carry some of 
that text forward verbatim.
As an aside, there might be L2 specific techniques that can make DNA 
work better. For instance, if a host discovers that it associated with a 
different 802.11 AP, and that it was using that AP (the MAC address aka 
bssid) a few minutes ago, and has remembered DNA information about it, 
it would be possible to short-cut the DNA procedures. But I don't know 
if such L2 specific techniques belongs in a host BCP, or somewhere else.

>> cookbook (what steps a host goes through, with DAD, MLD, and CPL)

BTW: Makes sense to talk about DHCPv6 here as well, but I suspect that 
only shows up when 1) a link change has been detected and 2) the new 
link is using DHCPv6 based on the bits in the RA.

> With regard to the other protocols, is this only
> the actual message exchanges required or
> interactions with other layers?

I'm not sure I understand the second part. What interaction do you have 
in mind?

>> security considerations
> 
> 
> Is there anything in the security considerations
> which you think is useful?

I suspect there is, but I'd have to read this particular section more 
carefully to be able to give a stronger answer.

> For example: the authorization and DNA subsection?
> 
> 
>> (optional appendix with design rationale)
> 
> 
> Are there any more general concepts we need 
> here?  Is it just indicating how things match
> the goals?

I think you'd want to introduce the concepts up front (in the 
introduction or background).
What I thought of for "design rationale" would be things that answer the 
readers question of why is it done this way.
Taking an example. Assume the document recommends that after a L2 'link 
up' the addresses on the interface are moved to optimistic state, but 
that the DAD probe is deferred until the first RA is received.

The reader might wonder why.
One way to answer this is inline by saying something like
	Since we don't know whether a link change has happened yet, it might be 
the case that the host is attached to a different link, and the 
addresses are not unique on that link. Hence switching to optimistic 
state is conservative since, since no neighbor caches can be disturbed 
in the case when there is a duplicate. Deferring the DAD probe until an 
RA is received saves on packets in the case when there was no link 
change, since no DAD probe is needed in that case.

Alternatively, this type of explanatory text can be moved to an appendix 
on design considerations. I guess the tradeoff between inline and an 
appendix depends on how extensive the explanations need to be.

    Erik