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

From: [email-masked]
Date: Tue, 2 Nov 1999 15:20:21 -0500

Steve,

You may be right: your document will clarify the issues discussed and we
could also have an off-line discussion to eliminate any confusion.

But would like to underline on the list that, from my side, this discussion
takes or took place because THE COST OF IPv6 UNICAST FORWARDING ENGINES IS
A CONCERN.

To sum-up, prior to this thread,  in some people's understanding (wishful
perhaps), the IPv6 UNICAST FORWARDING was ONE MECHANISM, that applied to
all unicast destination addresses, with one SIMPLE exception: packets with
LINK-LOCAL address destination  WERE NOT FORWARDED.  The exception was
SIMPLE and COST EFFICIENT because it didn't require any additional
mechanism.

Also part of the sum-up,  we (in this discussion) seem to  contemplate two
models:

---------
MODEL I.

1. The IPv6 UNICAST FORWARDING consists of ONE MECHANISM, based on  the
longest prefix match.

2. The IPv6 UNICAST FORWARDING is based on a service model, in which **the
destination address carries the entire forwarding information**.

3. IP v6 LINK-LOCAL UNICAST FORWARDING is excluded. because packets that do
not carry topological information in their destination address require
additional mechanisms to be forwarded.

4.  IPv6 UNICAST FORWARDING can achieve any packet delivery order - traffic
engineering- on a link, site, organization, or the global Internet, by
using the right combination of destination addresses that contain
topological information, and routing extension header.

MODEL II.

1. The IPv6 UNICAST FORWARDING consists of SEVERAL  MECHANISMS, of which
one is based on  the longest prefix match. Each mechanims is different
froThe mechanisms are different separate

2. The IPv6 GLOBAL and SITE UNICAST FORWARDING are based on the topological
information carried in the unicast destination address.

3. The IPv6 LINK FORWARDING is based on link information, which is not
carried in the packet header destination address.  This information is
configured or gathered through some other mechanisms -- that need
definition --  and allows packets to be forwarded on the same link, when a
node has one or more interfaces  connected to that same link.

4.  IPv6 UNICAST FORWARDING can achieve any packet delivery order - traffic
engineering- on a link, site, organisation, or the global Internet, by
using the right combination of destination addresses and routing extension
header.
-------------

Note or conclusion:

1. both models achieve over-all the same packet delivery functions.

2. MODEL I is simpler and cheaper than MODEL II because it consists of ONE
MECHANISM.

3. the restriction of MODEL I in regards of link-local forwarding, applies
to a very low frequency occurrence, and it can be circumvented by site, or
global address use.

4.  the absence of the restriction in MODEL II has an additional cost that
pays off in a case that has a reduced frequency of occurrence:  nodes that
have more than one interface connected to the same link.

 Alex

Steve Deering <[email-masked]> on 10/29/99 08:23:19 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 4:15 PM -0400 10/29/99, [email-masked] wrote:
>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.
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
>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.
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
--------------------------------------------------------------------
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: Tue, 2 Nov 1999 13:31:16 -0800

Alex,

I disagree with your characterization of the issue.  I think you are
the one arguing for two mechanisms: one for link-locals and another for
the other unicast scopes.  I am arguing for a *single* mechanism --
longest-match look-up -- operating (conceptually) on multiple
different routing tables (FIBs), one for each attached scope zone.

>1. both models achieve over-all the same packet delivery functions.

No, I don't think your model handles all the site-local cases.

>2. MODEL I is simpler and cheaper than MODEL II because it consists of ONE

No, my model consists of one mechanism.  Your model consists of one
mechanism plus special-case handling of link-locals, which is effectively
a second mechanism.

>to a very low frequency occurrence, and it can be circumvented by site, or

No, we don't know that link-local communication will be low frequency in
all cases.  There may be scenarios (e.g., home networks) where there is
significant link-local communication (e.g., audio packets from a stereo
to some speakers).

>have more than one interface connected to the same link.

No, the absence of a restriction in my model has no additional cost,
because special-case code for restricting link-locals is *absent*.

Steve