Date: Wed, 31 Jul 2002 15:12:18 -0400
From: Thomas Narten <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| 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).
Thomas, the point of the SHOULD etc words is to tell the implementor
what to implement. They're not at all effective in attempting to control
how people actually configure the equipment.
And in any case, this is certainly not the doc to be attempting to tell
people how to do that - if you want a BCP on setting up IPv6 routers in
nice ways, then get someone to write one (as well as what prefs to set,
and when, it could go into what lifetimes to use in various situations, etc).
But none of that belongs here (or not pretending to be any more than general
commentary so the implementor can understand what the user might want to
do with the implementation).
| Does it ever make sense to advertise a high preference in the absence
| of more detailed knowledge of the topology?
"None of your business."
I will configure the preferences of the routers I manage in the way
that makes my net work for me. All that is needed of the IETF is
to provide the tool for me to use (and if you also want to give some
"good usage" advice, that's OK as well, but it should not be as part
of the protocol spec).
| 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?
Maybe. But this is a quality of implementation issue. I think this kind
of thing only matters when one is attempting to specify things like "if
I see any normal or high pref routers on interface A, that's what I want
to use as my default, but if all I see is low, and there is a high pref
router on interface B, then use that one" ...
All this is really beyond the scope of the protocol of router prefs though.
| 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.
Naturally. This applies to all implementation choices in just about
everything, from how much RAM is (and can be) installed, to what protocols
are supported.
If the implementor hasn't implemented the protocols with the features
that are required, or in the way that makes sense for a particular
environment, then that implementation should not be used there.
| 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".
If they actually have undesirable consequences for the internet, I'd
agree. But I don't see that here, only possibly undesirable consequences
for the customer who installed the equipment. Given that, thanks for
caring, but I want to be able to acquire cheap implementations when those
are adequate for my purposes.
| > 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.
It isn't that subtle, but it is also not very important in most cases.
It sounds as if it should be, but unless the implementation is ignoring
redirects, it isn't the volume of traffic that matters, but the number
of different destinations. Then the best default router, and the best
route to default, tend to be the same thing (you get one redirect for
each local destination, and use that redirect to send large amounts of
traffic), you get no redirects for the large numbers of different
destinations all over the net, to each of which you probably send almost no
traffic at all. That's better than no redirects for the comparatively
smaller number of local hosts, and lots of redirects for all the rest,
or it is in many cases.
If we had "redirect this prefix" instead of just "redirect this address"
then there would be almost no rationale at all for splitting the two
concepts. "Type C" hosts (which will probably turn out to be most of
them) won't care anyway, they'll see the routes announced, and rarely ever
see any kind of redirect.
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
