Subject: [RRG] Locator/identifier separation : assumptions on locators

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 19 Mar 2007 11:57:56 +0100

Dear All,

During my presentation on Saturday (
http://www.info.ucl.ac.be/~obo/pres/IRTF-Prague.pdf ), I discussed
several assumptions/objectives for the utilization of locators.

I think that it would be useful to discuss them on the mailing list in
order to reach consensus and make further progress on mechanisms based
on the loc/id separation.

Olivier

-------------------------------------------------------------------------

1. Locators have a fixed length

 This is mainly because locators will be placed inside fixed-length
headers. Typical locators are IPv4 and IPv6 addresses although we may
invent new locators later.

2. Locator attachment

 A new interdomain architecture should not force locators to be only
attached to a given type of equipement. The architecture should be
support the association of locators to :
 - hosts
 - routers
 - middleboxes
 - proxies
 -...

 The exact point of attachment of the locator will be an engineering
decision that depends on the environment where it is deployed. For
example a large server site or an SME may prefer host-attached locators
while a large enterprise network would use middleboxes and a university
network would prefer proxies.

3. Number of locators associated to an identifier

 The architecture should not specify the exact number of locators that
will be associated to an identifier. It should be possible to change the
number of locators associated to each identifier.

4. Dynamic assignement of locators

 We should not start by assuming that locators will be statically and
manually configured. Otherwise, we'll end up finding that changing
locators will be impossible for customers. We should assume that
locators will be assigned dynamically (by a mechanism to be defined) and
that :
- each locator will have a lifetime
- it will be possible to renew locators
- it will be possible to deprecate, temporarily or permanently, a locator

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Scott W Brim <[email-masked]>
Date: Tue, 20 Mar 2007 13:10:12 -0400

> invent new locators later.

All the others look fine but this one brings up goals.  This brings up
one of the elephants not being discussed: how willing are we to
consider revolutionary ideas?  Let the endpoints have globally unique
IP "addresses" as identifiers, but there is no reason we couldn't use
variable length locators in routing (at least core routing), except
for compatibility.  Tony can tell you about championing variable
length addresses the last time around.  I don't see any gain in VLAs
at this point, but we might as well explicitly discuss the idea and
decide so.  The packet header form will follow the address form.

swb

---

From: Tony Li <[email-masked]>
Date: Tue, 20 Mar 2007 18:15:05 +0100

On Mar 20, 2007, at 6:10 PM, Scott W Brim wrote:

> I don't see any gain in VLAs

Perhaps we should reverse this.  Do we agree that we're working with  
v6/v4 header formats?  If so, then there's no way of doing a VLA (or  
VLL).

I'm still a champion of VLLs, just because we need the aggregation in  
the locator space, and our insanely poor usage of the namespace.

Tony

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 21 Mar 2007 21:22:16 +0100

Tony,
> v6/v4 header formats?  If so, then there's no way of doing a VLA (or  VLL).

I think that if we want to make progress in the RRG, there should be
competition between different proposals. I hope that several different
proposals for a new architecture will be developped within the group.
Concerning the utilization of locators, it seems reasonable to assume
that they will be of fixed size if the proposed solution is built on top
of IPv4 or IPv6. If the solution relies on another "infrastructure" than
IPv4/v6, then VLL might be an option.

Olivier

-- 
CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/~obo

---

From: Tony Li <[email-masked]>
Date: Wed, 21 Mar 2007 23:27:25 +0100

> proposals for a new architecture will be developped within the group.

Agreed, of course.

> IPv4/v6, then VLL might be an option.

I take from this that you want the flexibility to work outside of the  
v4/v6 framework.  I'm fine with that, I'm just happy to be explicit  
about it.

Tony

---

From: [email-masked]
Date: Thu, 22 Mar 2007 15:51:16 EDT

By the following I am only talking about a long-term solution.
 
Endpoint identifier /locator split : Yes definitely.
Each of these two items may get a structure. Lixia showed some for the  
locator.
Wrt the EID: An AFI (address family identifier) may indicate the kind of  
identifier. Currently E.164 addresses (telephone numbers) are mapped by DNS to  
IP-addresses.
This is not necessary (at least in a long-term solution), if we have the  
locator in addition.
There may be further address families we don't even know as of today  
(e.g.one  for all intelligent traffic lights:-)?). By going for multiple  address 
families (IPv4, IPv6 will of course also be such families) another dead  sin from 
the start becomes obvious: Different processing like unicast, versus  
anycast, versus multicast, versus broadcast, versus mp2p, versus  mp2mp should be 
signalled by means of some mode of operation field in the  header - and not by 
separate address ranges. Imagine to have individual address  ranges for all  
address families and for all of these modes of operation  ! What a bad design! 
Look at IPv6 : it introduces some anycast  address range instead of abolishing 
the multicast addresss range! This is my  view on EIDs.
 
My view on the split itself: See the gain for TE when traffic towards one  
and the same egress locator can easily be identified for the sake of  
TE-treatment !
 
A single word about the locator: This is the most  interesting object for all 
who are interested in future proven routing  technology, isn't it? 
 
Heiner

In einer eMail vom 21.03.2007 23:28:40 Westeuropäische Normalzeit schreibt  
[email-masked]:

Agreed,  of course.

Tony