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

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

Hi Erik, 

Sorry about the delay in responding.

----- Original Message -----
From: Erik Nordmark <erik.nordmark@sun.com>
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