Hi Rich.
> Section 4 specifies a couple exceptions to the usual rule that
> advertising preferences or specific routes requires coordinated
> admin of the routers. In particular, I think common scenarios like
> VPN or two independent ISPs should be handled correctly without
> coordinated admin of the routers.
Section 4 has some "mays", some of which might better be
should/SHOULDs. I.e., an admin SHOULD set a low priority if the router
doesn't reach the internet (due to connectivity or firewall).
perhaps also, SHOULD NOT set high priority unless it has control over
all the routers at issue and can thus make sensible decisions.
Does it ever make sense to advertise a high preference in the absence
of more detailed knowledge of the topology?
Also, in chatting with Erik Nordmark, he indicated that at one point
there were some discussions about adding a client capability to have a
map table that mapped received preferences into other values, to
handle situations where the received preferences didn't have the
desired result. Would that be a useful thing to have?
> > However, the MAY seems ill-advised, as the Destination Cache may also
> > include other information (e.g., path MTU info?) that should not be
> > flushed as a side-effect of such a route change. Can the above be
> > implemented reasonably without resorting to just flushing the table
> > and rebuilding whenever a change is present?
> I view this as a quality of implementation issue. In many
> environments advertised preferences & routes might change rarely so
> a minimal implementation might choose simplicity. However my
> implementation does what you want - it incrementally revalidates
> Destination Cache Entries when routes & preferences change.
One problem with the above is you assume that the implementor has
knowledge about the enivironments in which technology will be
deployed, and can thus make such tradeoffs. Is this a valid assumption
here? I suspect that in this case, the implementor can only assume
that it will be deployed in general and widely-diverse enivoronments
and that the above assumptions simply cannot be reasonably made.
It would be better if the spec did not allow poor implementation
choices (that have undesirable consequences on the internet) to be
considered "in conformance with the standard".
> > Q: who has implemented this draft? Can they comment on the
> > implementations issues mentioned above?
> I've implemented it (except for the new load-sharing part). Yes, the
> kernel needs to know all the routes.
> Keep in mind that the new Conceptual Sending Algorithm (section 3.2)
> applies only to hosts. Optimized router implementations, designed to
> support zillions of routes, are not affected.
Agreed. I'd still be interested from other folks that have (or are
considering) implementing it.
> > > Note that in addition to the preference value in the
> > message header,
> > > a Router Advertisement can also contain a Route
> > Information Option
> > > for ::/0, with a preference value and lifetime. Encoding a
> > > preference value in the Router Advertisement header has some
> > > advantages:
> > >
> > > 1. It allows for a distinction between "best default
> > router" and
> > > "best router for default", as described below in section 5.1.
> > >
> > > 2. When the best default router is also the best router for
> > > default (which will be a common case), encoding the preference
> > > value in the message header is more efficient than
> > having to send
> > > a separate option.
> >
> > After a number of re-reads, I still do not understand the above
> > distinction. I think I understand the example, but the explanatory
> > text above is not intuitive at all.
> You mean you don't understand the distinction between "best default
> router" and "best router for default"?
Its a subtle distinction and the terms used to distinguish are not
very intuitive.
> I have to give credit to Steve Deering for pointing it out to
> me. Here's the idea again (although I think section 5.1 already says
> this):
Note that the paragraph quoted above which introduces the terms
precedes section 5.1 quite a lot.
> Suppose you have a host with two next-hop routers, R1 and R2. R1
> connects the host to the rest of the internet. R2 connects the host
> to a specific /48. 99% of the host's traffic goes to that /48. Then
> R2 is the best default router for the host, because sending traffic
> to R2 will produce the fewest Redirects. But R1 is the best router
> for ::/0.
I understand the example (though I'm not immediately convinced the
distinction is terribly useful). But that doesn't mean the definitions
of the terms will make sense to the reader. It would be nice if you
could define/explain the two terms without having to use that
example. Can't the difference be described intuitively, and not with a
circular definition?
two suggestions. The first reference to the words (which doesn't
define them) includes a forward reference to much later in the
document. It would be nice to not need the reference, since the first
use of the terms doesn't at all explain them. The later words could
be better:
I.e.,
The best default router is not quite the same thing as the best
router for default. The best default router is the router that will
generate the fewest number of redirects for the host's traffic. The
best router for default is the router with the best route toward the
wider internet.
How about changing the last part of the last sentence:
The best router for default is the router with the best route
toward the wider internet.
But, I still think these terms are confusing and not particularly useful.
> Sure, would you just use "..."?
Something like:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |Resvd|Prf|Resvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (Variable Length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > If the Reserved
> > > (10) value is received, the Route Information Option
> > > MUST be ignored.
> >
> > Why ignored? In the case where PrF is in the message header, the rules
> > say treat the value as 00. What is the motivation for handling these
> > two case differently?
> Actually, when Prf in the message header is 10, the rules say to
> treat the *Router Lifetime* as 0. This means there is no default
> route, which is like ignoring the Route Information Option. So I
> think the two cases are handled similarly.
Not quite the same. A lifetime of 0 would update/replace the lifetime
for an existing route. Just ignoring the option wouldn't do that.
I think what you want here is to design for future extensibility. If
sometime in the future, someone were to define a usage for the 10
value, you wouldn't want existing implementations to do things that
prevent the new usage. Seems like having such entries be completely
ignored would be more flexible than having it treated like a lifetime
of 0. I.e, the current semantics might effectively prevent being able
to define the value later because of what existing implementations
will then do with it.
But, given that there are existing implementations that will never
look at the preference value, I think the safest thing to do is go
with "treat the value as if it had the default preference".
> > > Route Lifetime
> > > 32-bit unsigned integer. The length of time
> > in seconds
> > > (relative to the time the packet is sent) that the
> > > prefix is valid for route determination. A
> > value of all
> > > one bits (0xffffffff) represents infinity.
> >
> > Note that the lifetimes in ND are only 16-bits. It seems like it would
> > be better to be consistent in the two documents. It is not immediately
> > clear that a lifetime of longer htan 18.2 hours (the max per ND's 16
> > bits) is useful in practice. (Indeed, it may be worse the
> > useful in that an (incorrect) entry with a long timeout can
> > take days to weeks to expire.)
> >
> > Use 16 bits here as well?
> Actually, ND is inconsistent wrt lifetimes. Router Lifetime is 16
> bits but Prefix Lifetimes are 32 bits.
So it is. But I would argue that the two lifetimes in ND are for
orthogonal concepts (i.e, usability of a particular router
vs. on-link/autoconfig for a given prefix). The lifetimes in this
document all correspond to routing entries through a particular
router.
> > > When a host avoids using a non-reachable router X and
> > instead uses
> > > another router Y, and the host would have used router X
> > if router X
> > > were reachable, then the host SHOULD probe router X's
> > reachability
> > > by sending a Neighbor Solicitation. A host MUST NOT
> > probe a router's
> > > reachability in the absence of useful traffic that the
> > host would
> > > have sent to the router if it were reachable. In any case, these
> > > probes MUST be rate-limited to no more than one per minute per
> > > router.
> >
> > details are left unspecified here, but may be significant. For one
> > thing, the above says "sending a Neighbor Solicitation". Is that what
> > a probe is? Or does sending probes include retransmitting? The
> > document isn't clear on this.
> The probes are normal Neighbor Solicits. They will either be unicast
> or multicast depending on the state of the NCE.
> Probes are not retransmitted, unless the host continues to generate
> new Destination Cache Entries.
> To go into more detail - per the Conceptual Sending Algorithm,
> sometimes a host will send a packet to a reachable router instead of
> an otherwise-better unreachable router. If the unreachable router
> would have been used if it were reachable, then the host sends a
> probe to the unreachable router. But these probes are rate-limited,
> so the host doesn't send too many, and the probes are only sent if
> the host is continuing to generate traffic that would have been sent
> to the router if it were reachable.
> Hence, the host will notice when the unreachable router becomes
> reachable so the host can start to use the better router.
My point is that some of the above explanation would be useful to
capture in the draft itself. Right now, it's left as detail.
For one thing, "probe" is defined in ND. "probe" as used in this
document, seems somewhat different (i.e, no retransmits via
timers). Just clarifying this point would help, I think.
> Picking a random order once and then using RR would not be
> sufficient. It would be vulnerable to periodic application traffic
> patterns. On the other hand, designs that for example hash the
> destination address to choose among the routers should be
> allowed. In any case, sounds like this text will be moving to
> another document.
OK.
> > > 4. Router Configuration
> >
> > applicability? intended usage, restrictions?
> >
> > The preference values (both Default Router Preferences and Route
> > Preferences) should not be routing metrics or automatically derived
> > from metrics: the preference values should be configured. The High
> > and Low (non-default) preference values should only be used when
> > someone with knowledge of both routers and the network topology
> > configures them explicitly. For example, it could be a common
> > network administrator, or it could be a customer request to
> > different administrators managing the routers.
> >
> > Not clear this is workable in practice.
> Of course if you are a network administrator managing your own
> routers this is workable. If you are a large customer you might have
> sufficient leverage.
I don't understand the last comment. I agree that within an enteprise,
setting the preferences (for use within the enterprise) makes
sense. But that is only one applicability. I also thought this was
aimed at home users with connections to their coporate VPN and the
dsl/cable ISPs. In the latter case, the admins won't coordinate. Since
this is also an important usage, it would be good to be sure the
document explains how things will work in that environment as well.
> > An administrator of a router may configure the router to advertise
> > specific routes for directly connected subnets and any shorter
> > prefixes (eg, site, NLA, or TLA prefixes) for networks to which the
> > router belongs.
> >
> > Nit: TLA/NLA terminology is no longer in use.
> >
> > Separate references into normative/non-normative sections.
> Would it be OK to mark each reference as normative/non-normative?
Maybe. I understand this is a problem with the Word template not doing
this automatically. Let me see about this.
Thomas
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
