Subject: RE: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt

From: "Richard Draves" <[email-masked]>
Date: Mon, 10 Sep 2001 23:06:40 -0700

> > Perhaps it would be best to just remove the "no route" clause from 
> > Rule 1, and say that a destination D is considered unusable if 
> > Source(D) is undefined or if the next-hop neighbor for D is 
> known to 
> > be unreachable.
> 
> The problem with "known to be unreachable" is that it is a 
> very transient condition as RFC 2461 is done. At least the 
> way I read 2461 when NUD declares that a neighbor is 
> unreachable it goes ahead and redoes next hop determination 
> etc but it doesn't retain any state about the node being 
> unreachable - instead it effectively forgets this knowledge.
> 
> Thus declaring to be unreachable is an event and not a state. 
> So I don't see what you can check - the fact that the event 
> ocurred in the last millisecond?

I think whether this state is retained after NUD decides that a neighbor
is unreachable is implementation dependent. I had in mind other ways
that an implementation might know that the neighbor is unreachable. For
example if the interface is currently unplugged from the link on which
the neighbor resides, the neighbor is unreachable. Basically by saying
"known to be unreachable" without being more specific I'm trying to give
implementations some flexibility.

Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Sep 2001 10:54:15 +0200 (CEST)

> implementations some flexibility.

If that's the intent it might be good to give the implementors some
advise in addition to flexibility.
Thus giving examples (perhaps in an appendix) of what implementors might want
to consider "unreachable".

While the unplugged interface is hard data there might be other cases
where an implementation might have softer information that
a peer might be unreachable. An example of this is the issue about
what to do when all addresses are considered to be on-link (when there
are no default routers).
I don't know if it makes sense to try to cover such non-binary information
in the architecture for address selection since I suspect it would
add significant complexity.

  Erik