Subject: RE: draft-ipngwg-default-addr-select-00.txt

From: [email-masked]
Date: Fri, 29 Oct 1999 16:15:55 -0400

Steve,

I see the connection with site-local addresses.

But  the site filtering is easy, without any additional stuff, and the
matter of configuring a site border router is a *one, two, but not many
more* boxes matter.  Site addresses do not present a problem because all
routers on a site will forward site local packets on all interfaces,
EXCEPT:

     - the interfaces that have the "same site subnet ID",  and
     - the interfaces  that are marked as connected to links that "go
outside" the site.

Such interfaces (that  "go outside") may be marked by simply configuring
them with NO site addresses.

Alex

Steve Deering <[email-masked]> on 10/29/99 12:03:57 PM

Sent by:  Steve Deering <[email-masked]>

To:   Alex Conta/US/3Com
cc:   Richard Draves <[email-masked]>, [email-masked]
Subject:  RE: draft-ipngwg-default-addr-select-00.txt

At 8:35 AM -0700 10/29/99, Steve Deering wrote:
>At 11:12 AM -0400 10/29/99, [email-masked] wrote:
>>So  a node should know that two or more interfaces are on the same link?
>>I am not sure how you had in mind that this would be done. Could you
>>elaborate on this?
>
>Alex,
>
>Today, it could be known only via manual configuration.  We could think
>about specifying a protocol for auto-detecting that situation (e.g., send
>a link-local multicast out each interface and see if it arrives on any
>othe interface), but given the rarity of the situation, I don't think
>that's an urgent work item.
To follow up my own message, the reason I pointed out this technicality
(that a node may have more than one interface to the same link) is to
suggest that it would be good if implementations didn't wire in the
assumption that 1 link = 1 interface.  For example, you will probably
have some sort of data structure for an "attached site" that lists
or points to the set of interfaces attached to that site, and it
would be a good idea to have an analogous data structure for an
"attached link" that lists the set of interfaces attached to that
link; of course that list will by default contain a single interface
and will very rarely contain more than one interface.
Steve
--------------------------------------------------------------------
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]
--------------------------------------------------------------------

--------------------------------------------------------------------
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: Steve Deering <[email-masked]>
Date: Fri, 29 Oct 1999 17:23:19 -0700

At 4:15 PM -0400 10/29/99, [email-masked] wrote:
>more* boxes matter.

Alex,

I don't know why you are leaping to the conclusion that my suggestion
implies the need to configure many boxes.  The sensible default for every
box will be assume that each interface is attached to a different link.
Only those boxes for which that assumption is false would have to be
configured, which today is a very, very small number of boxes.  If
in the future it becomes more common for nodes to have multiple interfaces
attached to the same link, we could easily develop a protocol to
automatically detect that situation and autoconfigure the link-to-
interface-set relationship.

>  Site addresses do not present a problem because all

I'm confused by what you are saying, above, which seems to indicate
that we have different models in our heads of how site scopes work.  I
guess my slides in Tokyo weren't enough to get us on the same page, and
I know I have to get the document done that I promised on this topic.

One aspect of the confusion is that you seem to be thinking in terms
of a router distinguishing only between "inside" and "outside" a single
site, whereas the model I have is that a router should be capable of
being attached to multiple sites (via different interfaces), not just
a single site.  I'm not sure email is the best way to resolve our model
mismatch -- let me work on my document, and we can also talk in Washington.

At 4:49 PM -0400 10/29/99, [email-masked] wrote:
>Why would one put link local addresses in a router extension header?

To force the packet to go from one node on a link, through another
node on the same link, to reach a third node on the same link.

> A link-local address has no topological information, albeit a site-local
>address has: the subnet number, or ID, which makes a crucial difference:
>site local packets can be forwarded within the site.

For forwarding non-global addresses, you must take into account which
interface it arrived on, or more accurately, which zone it arrived from
(which is a piece of topological information).  This is true for both
link-local and site-local addresses.

The (possibly only conceptual) link-local routing table within a router
for each of its attached links is trivial, and does not require any
topological information to be embedded in link-local addresses to work.
In the normal case of a single interface, I, to a single link L, the
link-local routing table for that link looks like this:

	<my own link-local address on I>       next-hop = upper-layer
	FF80::/10                              next-hop = I

In the case of two interfaces, I1 and I2, to a single link L, the table
looks like this:

	<my own link-local address on I1>      next-hop = upper-layer
	<my own link-local address on I2>      next-hop = upper-layer
	FF80::/10                              next-hop = I1
	FF80::/10                              next-hop = I2

There is (conceptually) a separate such table for each link, and you use
knowledge  of the arrival interface of a link-local-destined packet to
determine which table to use to forward such a packet.

At 6:29 PM -0400 10/29/99, [email-masked] wrote:
>Phylosphically, and technically, if you forward, then you need to know
>where to forward, and if the
>destination does not tell you anything about "where", then there must be a
>different place, or state, or mechanism that provides you the "where".

Yes, in this case, the state is knowledge of your own link-local address(es)
and knowledge of the arrival interface (or link).  That is all that is
necessary to make a forwarding decision for link-local destinations.

Steve