Re: Agenda for Vienna

[Erik Nordmark <Erik.Nordmark@sun.com>]

> Some notions that seem relatively undisputed:
> 
> - we separate the identifier and locator functions so we can have 
> multiple locators and still have a single identifier
> - IP in transit works with locators, everything above the IP layer with 
> the identifier

Yep. And I think tunneling is one approach to implement this.

There might be an attribute of transparency that can be derived from the above
(not that I know we'd agree on it): 
Assume that layer X in the stack is operating on locators (where there might
be arguments for X=transport and X=application, but that is separate
discussion) then X will send a packet with some source locator and some
destination locator.
The transpareency attribute would be that the X layer on the receiver
receive the same packet (apart from TTL) as the sender sent.


> This leads to the following questions:
> 
> - what should identifiers look like?

More detailed questions in this area are:
 - are identifiers flat or do they have internal structure?
 - are (the fields of) the identifiers managed for uniqueness and other
   purposes or are they more or less random? (If there is internal structure
   potentially different fields can be different in this respect.)

> - assuming applications use identifiers, how do we know which locators 
> go with a certain identifier?

And potentially at different time scales:
 - find a set of potential locators from an identifiers (whether or not
   they are currently usable)
 - find a set of usable locators for an identifier (taking into account
   failures that affect one locator but not others)

And potentially at different granularity:
 - site mapping (from site part of identifier to site part of locator)
 - host mapping (allowing host multihoming and host IP mobility)

> - when receiving packets, how do we know (= better than take her word 
> for it) the correspondent's identifier?

Agreed.

If there is a system that maps to identifiers to locators there is
also the issue of authenticating and authorizing entries (new and updates)
to that system.

> Then there is the address selection problem. We know that the current 
> "pick one and die if it doesn't work" approach is no good so we have to 
> come up with something better.

I assume you meant "locator selection" and not "address selection". :-)
 
   Erik