Subject: proposal for text change in source address selection

From: Alain Durand <[email-masked]>
Date: Tue, 11 Dec 2001 13:27:49 -0800

The following text is a suggestion to modify Section 4, rule 8.

Previous text:

    Rule 8: Use longest matching prefix.
    If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then choose SA.
    Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then
    choose SB.

    Rule 8 may be superseded if the implementation has other means of
    choosing among source addresses. For example, if the implementation
    somehow knows which source address will result in the "best"
    communications performance.

Proposed test:

    Rule 8: Use longest matching prefix.
    If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then choose SA.
    Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then
    choose SB.

    Rule 8 may be superseded if the implementation has other means of
    choosing among source addresses. For example, if the implementation
    somehow knows which source address will result in the "best"
    communications performance.

    Also, an implementation that has knowledge of the prefix lengths
    associated to the candidate source addresses MAY choose to
    limit longest prefix match to those particular prefix lengths instead
    of doing it on the full 128 bits.

    Rule 9: optional tie breaker

    If the above rules failed to choose a source address, an implementation MAY
    either decide to pick a candidate source address randomly or to take the
    smallest one in the lexicographic order. This rule is optional.

--------------------------------------------------------------------
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 Dec 2001 23:48:53 +0100 (CET)

>     of doing it on the full 128 bits.

I think the above description is insufficient for an implementor to understand
what the implementor might optionally do.
Thus I'm concerned that folks will read this and do something quite different
than we intend. 

>     smallest one in the lexicographic order. This rule is optional.

I don't understand the problem this is trying to solve.
I thought there was an argument (and perhaps not agreement) that predictable
behavior (having a single host? all hosts with the same configuration?)
pick the same source address for a given destination.

The above doesn't solve that problem. So what problem is it trying to solve?

Confused,
  Erik

---

From: Alain Durand <[email-masked]>
Date: Wed, 12 Dec 2001 15:08:24 -0800

>Thus I'm concerned that folks will read this and do something quite different

I'll send clearer text.

>The above doesn't solve that problem. So what problem is it trying to solve?

My recollection of the discussion is that some people think that
predictability is a good think and other think that randomness is good.
This text (maybe not very well formulated) intend to say
"If you think that predictability is not a good think, order randomly the 
addresses,
  if you think predictability is a good thing, then here is a way to 
achieve it"

         - Alain.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Dec 2001 01:10:37 +0100 (CET)

>   if you think predictability is a good thing, then here is a way to 

But those are different implementors having different opinions, and it
is up to the operators to deal with any issues relating to this.

So I think we need to understand what the operational concerns, if any,
are in this space.
Do they prefer predictability across nodes i.e. all nodes in the site
makes the same choice (assuming same config), that a single node always
make the same choice, or that a single node randomly chooses.
I can see operational arguments for either one, but I'm not an operator.

  Erik

---

From: Robert Elz <[email-masked]>
Date: Thu, 13 Dec 2001 15:46:20 +0700

I have no problem with the general thrust of the proposed text.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Dec 2001 15:19:42 +0100

I would expect predictability to be useful in a diffserv context
(it will make it easier to configure classifiers). 

It might also make multihoming easier to think about.

   Brian