Subject: RE: My Thoughts on Site-Locals

From: "Michel Py" <[email-masked]>
Date: Thu, 3 Apr 2003 16:39:52 -0800

Margaret,

>> Michel Py wrote:
>> Why don't you simply make this a requirement? I have
>> heard many times that issue about the convexity although
>> I don't remember opposition to coupling the site boundaries
>> with the AS or routing area.

> Margaret Wasserman wrote:
> We probably would have...  Except that around the time that
> we actually formulated the correct solution, the WG started
> doubting the validity of site-border routers and started
> considering various alternatives for limiting site-local
> usage.
> The scoped addressing architecture has basically been
> on-hold ever since, waiting for us to make up our collective
> minds about site-locals.
> If the consensus to deprecate them does not hold, I'm not
> quite sure what we are going to do... We certainly don't
> have consensus to do any further work on site-locals,

To the contrary, I think this is the only consensus we have.

First, this "consensus" on deprecation (if there is one which remains to
be seen) does not exist for two big reasons:

1. Most of the votes were taken without knowing what it really meant.
It's a consensus on vaporware.
Note that this is not a criticism; Bob and you obviously had something
else in mind and if there is something you failed it's only that you did
not have the right inspiration when you had to improvise and that you
allowed a few agitators in the room bully you into this vaporware
instead of sticking to the plan.
In the pot calling the kettle black dept. I would say that you did not
pay enough attention to room dynamics and too much to your presentation
:-(

2. I don't see how any consensus can be reached without a detailed
explanation about the consequences on the scoped architecture.

Second, by your own account we do need to prepare documents about what
to do next. Call it deprecation if you want what I call it is that we
have more work to do on site-locals and on the scoped architecture.

> and it isn't clear how we can ever finalize the scoped
> addressing architecture without some type of decision
> on this issue.  Perhaps we can break out the
> non-contentious parts and advance those parts?

I believe we can progress on three topics:
- Ambiguity
- Convexity / defining the site borders.
- Tuning the compromise.
Unfortunately this requires people that are for IPv6 and not against and
that are willing to compromise. I regret to report that at this point I
count only three: Bob Hinden, you and me.

Michel.

--------------------------------------------------------------------
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: Thomas Narten <[email-masked]>
Date: Thu, 03 Apr 2003 21:36:36 -0500

Michel,

> pay enough attention to room dynamics and too much to your presentation

I find the above unhelpful and not true. Saying the votes were taken
"without knowing what it really meant" is FUD. I was in the room and I
sure felt like I knew what was being asked.

I also went to the microphone before the question was asked to point
out that what we were talking about by deprecation was "something to
the left of the limited model". Nobody seemed to question that. I
don't think anyone can claim folks didn't know what was being
asked. To suggest otherwise is an attempt to cast FUD.

> explanation about the consequences on the scoped architecture.

I think a fair number of people do feel like they understand the
consequences even if they aren't all written down in one document that
explains it all in easy to understand steps. I have certainly had long
conversations about this issue with numerous folk that I think do
understand the implications -- and it is those implications that make
people uncomfortable.

I also think that the consequences and implications are subtle and not
immediately easy to understand. I say that because it has taken a long
time for the number of folk to understand the consequences and be
concerned about them to reach critical mass. Everyone seems to start
off from the "what's the big deal?" perspective. Heck, I thought SLs
were fine too if we go back 5 years. It wasn't until we really started
thinking hard about them that their problems started becoming better
understood.

I've seen it now (somewhat independently) in the zeroconf WG too,
where similar issues have been discussed with LL addressing for
IPv4. There are plenty of people there that don't see what is hard
about scoping and that it's not a big deal to make applications handle
them. But over time, more people have also come around to
understanding that there are issues, and there are problems with
scoping.

And if you go to applications people (that is, those folk that spend
their lives doing applications rather than stack work) they seem much
more concerned on average that scoped addresses have significant (bad)
implications for applications.

> have more work to do on site-locals and on the scoped architecture.

Clearly, that needs to be done. But there is a basic chicken-and-egg
problem. If the the WG isn't going to deprecate SLs, why would anyone
bother writing the document calling for their deprecation? The purpose
of the current discussion is to figure out whether we should go to the
next steps of making changes in various documents.

> count only three: Bob Hinden, you and me.

I don't understand what you are trying to say above, but if the
implication is that the only members of the WG that are being
reasonable and willing to listen are those listed above, I find that
rather offensive.

Thomas

---

From: Brian Haberman <[email-masked]>
Date: Fri, 04 Apr 2003 08:37:14 -0500

<snip>

>>non-contentious parts and advance those parts?

We need to break out some of it regardless.  If everyone recalls,
I pointed out that pieces of the scoped addressing architecture
still needs to be done in order to support the scoped multicast
addresses.

> - Convexity / defining the site borders.

I can comment on the convexity issue.  Section 5 of the scoped
addressing architecture has the following:

      Each zone is required to be "convex" from a routing
      perspective, i.e., packets sent from one interface to any
      other interface in the same zone are never routed outside
      the zone.

No one has objected to it.  I have implemented the routing of
scoped addresses.  I can guarantee convexity in the protocol.
Does it work?  Yes.  Is it a performance hit?  Absolutely.
And as Alex pointed out in another message, the complexity gets
worse when scope boundaries have to be reflected in area borders.

> count only three: Bob Hinden, you and me.

Quite an insulting comment.

Regards,
Brian

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 4 Apr 2003 08:29:17 -0800

Thomas Narten wrote:
> ...
> I've seen it now (somewhat independently) in the zeroconf WG 
> too, where similar issues have been discussed with LL 
> addressing for IPv4. There are plenty of people there that 
> don't see what is hard about scoping and that it's not a big 
> deal to make applications handle them. But over time, more 
> people have also come around to understanding that there are 
> issues, and there are problems with scoping.
> 
> And if you go to applications people (that is, those folk 
> that spend their lives doing applications rather than stack 
> work) they seem much more concerned on average that scoped 
> addresses have significant (bad) implications for applications.

This should not be surprising. Given that the applications community
blindly assumes there is a single addressing scope, when they bump into
the reality of the deployed network there will be problems. Proclaiming
that scopes are bad for applications does not make the filtering that
causes scopes go away. 

> Clearly, that needs to be done. But there is a basic 
> chicken-and-egg problem. If the the WG isn't going to 
> deprecate SLs, why would anyone bother writing the document 
> calling for their deprecation? The purpose of the current 
> discussion is to figure out whether we should go to the next 
> steps of making changes in various documents.

The discussion that should have happened first is 'what alternatives do
we have to deal with the requirements that network managers are using SL
to deal with?' Without a clear replacement, and with comments that some
real problems are 'uninteresting', the network manager will insist on
keeping the current tool. Once we provide alternatives that meet all of
the requirements, nobody will care about keeping SL as currently
defined. If we fail to meet all the requirements, there will still be a
need for the current SL in those environments. There is no point in
getting rid of SL now, only to reintroduce it later when we have failed
to meet a set of requirements with viable alternatives.

Tony

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 4 Apr 2003 18:30:20 +0200 (CEST)

> scoped addresses.  I can guarantee convexity in the protocol.

Brian,

I thought the hard part about ensuring convexity wasn't about the routing
protocol itself, but ensuring convexity in the forwarding of a packet
with
	dst = global address assigned to site
	src = site local address

For things to work such a packet must stay inside the site even though
it's destination address is a global address.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 4 Apr 2003 18:39:05 +0200 (CEST)

> Correct.  My statement was for the protocol, not the forwarding.
> That is why I made the follow-on comment about complexity.  The
> next-hop interface's ifindex for the global destination address
> would have to be checked to ensure that it has the same zone ID
> as the interface on which the packet was received.  So, it leads
> to more checks during forwarding AND requires the forwarding table
> to potentially maintain multiple next-hops for the global addresses.

I don't think that is sufficient.
If all the entries in the RIB for the prefix point outside the site
then you have no choice but to drop the packet on the floor.

If the sender had used a global source the packet would have made it
through.

   Erik

---

From: Brian Haberman <[email-masked]>
Date: Fri, 04 Apr 2003 11:36:20 -0500

In other words, the global prefixes learned from within the site
have to be "marked" so they don't get confused with prefixes
learned from outside the site.

Brian

---

From: Brian Haberman <[email-masked]>
Date: Fri, 04 Apr 2003 11:54:09 -0500

> If the sender had used a global source the packet would have made it

Yes.  I agree that would happen.  That is why it has an operational
component as well.  Lets say we have something like this:

         +------------ Internet -------------+
         |                                   |
      office1 ------ site local / ------- office2
                       global

A node in office1 could communicate with a node in office2 using
any combination of SLs and Globals (per the existing specs) as long
as both offices were in the same site.  Using your example of
global dest and SL src, everything is fine until the internal link
breaks.  Now, the source node would get back a "scope exceeded"
ICMP message when the router tries to send the packet over the
Internet.  So now the source picks a global src to go with the GL
dest.  The packet may get through unless the routers or firewalls
drop it when they realize that the destination is really inside
but isn't reachable.  If it does get through, then the source may
have sent sensitive information over the Internet without encrypting
it.

What I am saying is that the routing and forwarding can be made to
work, but it is kludgy and a big impact on performance.

Brian

---

From: Markku Savela <[email-masked]>
Date: Fri, 4 Apr 2003 20:12:56 +0300

> 	dst = global address assigned to site

I must be missing something. There is really nothing hard about it, as
far as I can see.

When packet comes in from a interface A, you pick scope ids from that
inteface (or just remember where it came from) and get

    dst, id-A[global] (well, for global not techinally needed)
    src, id-A[site]

Then you forward the packet normally with "dst", and find it lands on
interface B. The only additional test to do is:

    if (id-A[site] != id-B[site])
       drop packet/or icmp out of scope.

This is clearly explained in scoping architecture, I
thought.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 04 Apr 2003 20:11:02 -0500

Tony,

"Tony Hain" <[email-masked]> writes:

> keeping the current tool.

You have said a number of times now that network managers want and
need SLs.

Question: Do you believe that if we keep SLs, this implies
that we will indeed need to complete the work on multi-site nodes and
that multi-site nodes will become necessary in practice to deal with
what I expect the common practice of nodes being in multiple sites
simultaneously (as I described in an earlier note)?

(One of the things that happened at the SF meeting was that a number
of people expressed skepticism at the viability of a limited usage
"compromise" where we could use SLs in a limited fashion.)

Thomas

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 4 Apr 2003 17:46:31 -0800

Thomas Narten wrote:
> > The discussion that should have happened first is 'what 
> alternatives 
> > do we have to deal with the requirements that network managers are 
> > using SL to deal with?' Without a clear replacement, and 
> with comments 
> > that some real problems are 'uninteresting', the network 
> manager will 
> > insist on keeping the current tool.
> 
> You have said a number of times now that network managers 
> want and need SLs.
> 
> that we will indeed need to complete the work on multi-site 
> nodes and that multi-site nodes will become necessary in 
> practice to deal with what I expect the common practice of 
> nodes being in multiple sites simultaneously (as I described 
> in an earlier note)?
> 

I also believe that multi-sited nodes will be commonplace. With a viable
PI space, I would expect most all of the multi-sited nodes to use that
because the places that really want the ambiguity feature are not likely
to want external access from nodes visiting another site. With PI the
node needs to keep straight which domains should be retrieved from which
DNS servers, and then which interface on the multi-sited node is
attached to the returned prefix. The only difference I see between the
work required for this vs. SL is that the multi-sited node can use the
prefix assigned to an interface as a key, rather than having to create a
local one to track where the name resolution came from. Either way it
has to track which domains are available over which logical interface. 

> (One of the things that happened at the SF meeting was that a 
> number of people expressed skepticism at the viability of a 
> limited usage "compromise" where we could use SLs in a 
> limited fashion.)

I have never believed that any of compromise approaches made any sense.
Those are about mandates counter to the network managers goals. The
majority of network managers will only choose SL because we don't offer
a viable PI option. If we fix that and provide a way to simply configure
a massive number of local use devices, the demand for the ambiguous SL
will diminish. 

Tony

---

From: Randy Bush <[email-masked]>
Date: Fri, 4 Apr 2003 21:08:11 -0800

just in case folk have short memories, i am strongly against
site-locals.  they attempt to solve a routing problem with
an address hack, a la rfc 1918.  they are unneeded complexity.
now is the time to abjure them.

randy

---

From: "Tony Hain" <[email-masked]>
Date: Sat, 5 Apr 2003 08:04:59 -0800

Randy Bush wrote:
> site-locals.  they attempt to solve a routing problem with an 
> address hack, a la rfc 1918.  they are unneeded complexity. 

They solve an addressing problem PI, where other proposed approaches
create a routing problem. Until there is a routable PI space, we need an
unroutable one. We have to solve the problems in the right order.

Tony

---

From: Greg Daley <[email-masked]>
Date: Mon, 07 Apr 2003 10:22:28 +1000

Hi Tony,

I think that your statement is correct
(about SL providing a PI non routeable address system).

I'm pretty sure though that SL is not a good
solution for connected networks though because
of the ambiguity issues which have been described
endlessly.

GUSL may work well enough, although any good scheme which
provides globally routable (unique) provider independent
addresses, will provide a valid prefix for site local.

Please continue your work with the PI addressing scheme,
since it has the opportunity remove the need for
(ambiguous) connected SL.

Greg D.