Subject: Re: AD comments on draft-ietf-ipv6-router-selection-02.txt

From: Robert Elz <[email-masked]>
Date: Thu, 01 Aug 2002 18:51:58 +0700

Date:        Wed, 31 Jul 2002 15:12:18 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 1 Aug 2002 19:30:45 +0200 (CEST)

> 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 don't understand what this means.
"Best router for ::/0" is the same as best default router in my mind.

As far as I can tell the distinction you are trying to make only makes
sense when the question asked is "which is the best router for prefix P".
But the node cares about "which is the best router for destination D" - nodes
don't send packets to prefixes - they send packets to addresses.

So I'm utterly confused.

  Erik

---

From: Thomas Narten <[email-masked]>
Date: Fri, 02 Aug 2002 12:49:33 -0400

> how people actually configure the equipment.

SHOULD (or should) are used both to tell implementors what to
implement and to make recommendations on how stuff ought to be
configured/deployed/used. A goal of having shoulds on how things
should be configured is to prevent ill-thought settings from being
used by default. We do this all the time. Its prudent
damage-avoidance.

> and when, it could go into what lifetimes to use in various situations, etc).

Its common to mix applicability stuff in with a protocol standard. We
do it far more often than writing a separate standalone applicability
document.

> "None of your business."

In other words, are you saying the document should provide no guidance
to admins on how they should configure things, because that is by
definition out of scope in a protocol docuent? If so, I disagree.

> "good usage" advice, that's OK as well, but it should not be as part

Noone is saying you can't configure things the way you want. A SHOULD
means, do this unless you understand what you are doing, understand
the consequences of doing something different, but want to do
something different anyway.

> All this is really beyond the scope of the protocol of router prefs
  though.

You seem to be making it sound like a protocol spec should document
only the on-the-wire part, and things relating to configuration are
out-of-scope. If this is your point, I disagree on principle.

> environment, then that implementation should not be used there.

You are assuming that an end user will have the choice of not using a
feature. If the device is (say) a PDA, you might not have the ability
to turn it off or otherwise control its usage. For better or worse, I
think there are fewer and fewer places where the implementor really
has a good idea of where something will be deployed. Consequently, we
have to assume things will be deployed in the general internet, not in
some sort of restricted environment (or include an applicability
statement saying where something shouldn't be used).

> are adequate for my purposes.

My text relates to flushing the entire ND cache and losing associated
cached PMTU information. Are you saying this is OK to do this and
doesn't have harmful consequences?

Thomas