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

From: Greg Daley <[email-masked]>
Date: Mon, 14 Mar 2005 14:59:27 +0000 (GMT)

Hi Erik, 

Sorry about the delay in responding.

----- Original Message -----
From: Erik Nordmark <[email-masked]>
Date: Wednesday, March 9, 2005 5:16 pm
Subject: Re: [DNA] Comments on draft-narayan-dna-hosts-bcp

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

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

regarding different reachability for unicast and
multicast: 

I think that there may be a situation where 
a device only uses unicast signaling to associate
with an AP, and multicast is broken because of
the motion of the node.  This isn't only related
to Link-Re/Establishment events, but also may 
occur if the node experiences changes within a 
wireless cell.

Where the network is bridged, I agree that
there is unlikely to have been changes in the 
router availability which can't be handled by 
existing Router Discovery.

So I guess that the problem may be real, but not
sufficiently well described or understood to
list in the BCP at this time.

Perhaps this is something worth treating later
(in a different document) if there's a
demonstrated need.

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

I agree with your characterization of the 
brdiged network.  That wasn't my focus.

The 802.11 network wasn't specifically my focus
either.  There will be networks where a node
discovers or is instructed to take a cell using
network side messages.

Where there isn't explicit acknowledgement of 
'toward network' frames at the MAC layer, then
upper layer confirmation from Layer 3 should be
used.

Is it worth saying something like that in the
document?  (considering also that many MACs have
these mechanisms and it may not matter in those
cases).

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

I think there was a section describing using 
previous knowledge, including recently visited
networks.

Perhaps we can revisit the text to make it more
explicit.

I don't think that's a hint issue, rather
a decision issue about change probing, or
identification of the network.

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

Yes.  It is mentioned, but wasn't listed in the 
e-mail.
 
> > 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?

There are timing relationships with other layers
for example MLD, which needs to be run before 
_and_ after change detection, based on the DAD
state, and the results of the detection.

Is this the sort of thing we should describe?
 
> >> 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.

This is not specified up front. You're right.

It needs to be.

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

Oh well, it's always possible to have a short 
statement up front, and reference the detail
elsewhere as needed.

Thanks for your feedback.

Greg

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 14 Mar 2005 10:12:08 -0800

> occur if the node experiences changes within a 

It's true that the L2 packet loss might be higher for multicast than for 
unicast, but in any L2 with L2 connections/associations, I don't see 
this making a difference when the routers are attached to a wired 
network. Either the multicast packet makes it to the AP or not, and if 
it makes it to the AP then all the routers will see it (because the 
wired part of the network works well.)
Of course, if the routers are not on a wired segment then things are 
different; there would be an increase probability that one router sees a 
RS but not the other router.

But this still doesn't make a case for verifying (unicast) bidirectional 
reachability with the old router, since unicast works well.

The discrepancy between multicast and unicast packet loss rate does hint 
at a possible optimization. At high multicast loss rate it can be 
significantly faster to send a unicast packet to the old router and 
receive a unicast response, they trying to get a multicast RS to one router.
But it only helps in the case when you are on the same link. And I would 
assume that a DNA host has the status-quo assumption i.e. unless it can 
determine that it has moved it continues to use the information for the 
(old) link. Thus sending unicasts would help speedup the DNA procedure 
when on the same link, but without any unicast the host will assume it 
is on the same link so the time it takes to verify this doesn't matter.
The only difference I can see is how long time the host will be in DAD 
optimistic mode (but DAD doesn't work well with high multicast loss rate 
so this is a bit of a rat hole).

Thus I don't see where sending a unicast packet to the old router would 
help at all.

> (in a different document) if there's a

It sure makes sense understanding the motivation and the tradeoffs better.

> upper layer confirmation from Layer 3 should be

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?

> Perhaps we can revisit the text to make it more

ok

> Is this the sort of thing we should describe?

Yes.
FWIW I think there is some text about this in the solutions framework doc.

    Erik