Subject: RE: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)]

From: "Michel Py" <[email-masked]>
Date: Wed, 27 Nov 2002 17:14:55 -0800

Keith,

>> Michel Py wrote:
>> Here's the dilemma: if the scope of GUPI is global, how
>> could you guarantee that people won't pay their ISPs to
>> leak the GUPI address in the defaultless routing table?

> Keith Moore wrote:
> If people don't want their addresses to be publically
> routable, why would they pay their ISPs to route them?

My point precisely:
GUSL -> Scope is site-local  -> no public routing.
GUPI -> Scope is global      -> if there is public routing
        this solves the multihoming issue (unfortunately,
        by exploding the routing table.)

>> The big difference is that with GUSL we would have
>> extended the scope to friendly sites, not to global.
>> The risk of GUSL ending up global PI could be managed.

> I don't see how this is changed by a decision to not
> use FEC0::/10 for globally unique addresses.

Because the scope of this new block would be global, if have not misread
you (instead of local).

> But there still seems to be an inherent conflict between
> those who are demanding non-routable addresses (is anyone
> else demanding this?) and those who want GUPIs to be
> routable.  If there's really sufficient demand for both
> maybe we need separate blocks.

Since London I have tried to push a multihoming draft that implements
local PI as identifiers. I've heard "It's based on PI, I won't even read
it" and "PI sucks, don't waste your time".

What makes you think that GUPI would be different? You don't even have
the multihoming carrot. Don't get me wrong: I'm not against GUPI on the
principle, just pointing out that it has been stalled in multi6 forever.

In other words: I'm not saying we should not work on it because it's
bad, but because it's a waste of time today. Later, maybe. When the
multihoming crud hits the fan.

What we could achieve quickly is GUSL, with a mention that it must not
be used for multi-site. Taking out the ambiguity and the multi-site
would be good steps to limit site-local issues.

Let's try to nail this before fighting the GUPI battle.

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: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 20:57:27 -0500

>         by exploding the routing table.)

Not necessarily.  There appear to be solutions for global routing 
of distinct prefixes  which do not explode the routing table, 
but they don't solve multihoming either.
 
> Because the scope of this new block would be global, if have not misread

What you seem to be trying to do is to say that since we don't
currently know how to scale global routing of non-aggregatable
prefixes, we need an architectural limitation to prevent it.
I don't believe that it's appropriate to wire limitations of 
current routing technology into the addressing architecture.  

> it" and "PI sucks, don't waste your time".

Well, since Atlanta there is evidence of considerable interest in
PI identifiers.  So maybe people are coming around...  

> principle, just pointing out that it has been stalled in multi6 forever.

multi6 is working on different things.  If it turns out that they find
a way to globally route GUPIs, that would be great.  But we don't need to 
solve the global routing problem to make globally scoped PI addresses useful.

> bad, but because it's a waste of time today. 

Actually I think the lack of GUPIs is one of the biggest things blocking
progress of this group - it's forcing people to try to make SLs do things
that they simply cannot do well given the assumptions that are already
wired into the architecture and into code.

Keith