Subject: Re: Why I support deprecating SLs

From: Dan Lanciani <[email-masked]>
Date: Sun, 6 Apr 2003 16:01:35 -0400 (EDT)

Leif Johansson <[email-masked]> wrote:

|Dan Lanciani wrote:
|
|>|(provider
|>|independence perhaps)? Please make the distinction for the sake of clarity.
|>
|>Re-read what I wrote above.  Give them globals with the same (or better)
|>level of stability as their private addresses.
|>  
|>
|So you are talking about  renumbering,  provider independence, etc. IMO 
|this discussion
|would benefit from a bit more precision. The heart of the problem as I 
|see it is this:
|site-locals are put forward as a solution to problems that very few 
|people in the IETF
|agree is enough of a problem

Well, that does clear things up a bit.  I had heard that these problems were
"hard" and that we were going to work on them "later," but your explanation
makes more sense.

|to warrant fundamental change to the 
|architecture.

Could you clarify your terminology here?  By ``fundamental change to the
architecture'' do you mean _not_ removing the site-locals that have been a
part of that architecture for years?  So not making this ``fundamental change''
means changing the architecture to remove site-locals?

Or are you saying that once site-locals are gone the IETF will be unwilling
to allow any additional changes to the architecture to solve the renumbering,
PI, etc. problems because these problems are not ``enough of a problem'' to
warrant fundamental changes in the architecture?

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
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: Leif Johansson <[email-masked]>
Date: Sun, 06 Apr 2003 22:01:53 +0200

>means changing the architecture to remove site-locals?
Disregarding your attitude; one part of the fundamental change I refer 
to (and the one
I care most about) is the fact that applications will have to know about 
topology if
site-local gets deployed. Address selection as described in the current 
address arch
draft is imo undeployable. Moreover I don't believe that applications 
should have to
care about address selection or know about topology. Judging from the 
traffic on the
list and from the discussion at the mike in the SF meething i'd say that 
quite a few
agree with me on that point.

       leifj

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 07 Apr 2003 10:07:09 +0200

Leif Johansson wrote:
...
> Moreover I don't believe that applications 
> should have to

I'm afraid I don't agree with you. On the contrary, middleware that
cares about performance and survivability absolutely has to care
about path selection in some way or another. But I think this is
a somewhat separate issue from ambiguous SLs and the specific scope 
problems that they cause.

  Brian

---

From: Leif Johansson <[email-masked]>
Date: Mon, 07 Apr 2003 19:01:03 +0200

>problems that they cause.
Even at the risk of polluting the thread ;-) I'll bite: Could you give 
an example
of such middleware?

       leifj

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Apr 2003 09:58:15 +0200

> Even at the risk of polluting the thread ;-) I'll bite: Could you give

Reliable message passing systems such as <advert>MQ Series</advert>

On-line transaction processing

Remote data base write/update access

All of these need to seek maximum performance (transactions per second)
and minimum latency, and to retain connectivity 24x7 whatever happens
in the network. That means probing for highest performance paths or for
alternate paths when connectivity fails. Today this has to be done in
the crudest way possible (try address A and if that's no good, try
address B). 

   Brian