Subject: Re: [arch-d] Benefits of identity/location separation?

From: Christian Vogt <[email-masked]>
Date: Tue, 08 May 2007 22:25:46 +0300

Hello Noel,

I think you came up with a very good capture of immediate benefits that
an ID/locator split would have today.  One may add that the split
provides a new means for access networks to choose an ISP for outgoing
packets without conflicts with ingress filtering.  And possibly anycast
might benefit as well.

Yet, the main point I would like to make is not to extend your benefits
list, but to emphasize that the effect and the benefits of an ID/locator
split strongly depend on /where/ the split is implemented:  directly in
the hosts, or somewhere in the network.  HIP is usually associated with
a host-based ID/locator split [1], whereas LISP, eFIT, et al. place the
split on the border between an access network and its ISP(s).  I prefer
to use the term "locator/locator split" when referring to approaches
such as LISP or eFIT.

   [1] As a matter of fact, network-based HIP implementations are
       likewise conceivable, especially during a transition phase,
       as Pekka Nikander described in
       [draft-nikander-ram-generix-proxying].

If the ID/locator split is inside a host, the host still needs to have
multiple IP addresses, each with a prefix that topologically corresponds
to the respective upstream path.  In other words, a host-based split
still does not do away with access networks' desire for PI addressing
space.  This has two disadvantages:  (i) The operators continue to face
the same limitations with respect to traffic engineering:  Hosts still
choose the IP source addresses in outgoing packets and thereby determine
the ISP that the packets must be forwarded through.  (ii) Network
reconfiguration is expensive when an access network switches ISPs since
existing prefixes must be replaced.

On the other hand, as you say, a host-based ID/locator split helps a lot
for host mobility, locally within an access network as well as across
access networks.  And it also helps for host multi-homing, where -- in
contrast to access network (or "site") multi-homing -- the host has
multiple interfaces to possibly different access networks (see also
Thomas Henderson's email earlier in this thread).  A host-based split
would also make multicast (and perhaps anycast) conceptually cleaner.

With a locator/locator split inside the network -- say, at the border
between an access network and its ISPs --, traffic engineering becomes
more facile, and only border routers need to be reconfigured when the
access network changes ISPs.

On the other hand, a locator/locator split does not support host
multi-homing, neither does it facilitate host mobility except when local
within a single access network.  It also has no benefits WRT multicast
and anycast.

In the above, I have considered mobility only in the sense of "session
continuity", and I have disregarded the aspect of host reachability.
However, when it comes to host reachability, a network-based
locator/locator split actually has an advantage because it makes a
(stationary) home agent's or other rendez-vous server's IP address
stable even when the access network changes ISPs.

So in summary, I would argue that both types of splits are necessary to
satisfy all objectives that we have today:  An ID/locator split on the
host for session continuity despite mobility, host multi-homing,
multicast, and anycast.  And in addition a locator/locator split further
upstream in the network, easing ISP changes, access network
multi-homing, traffic engineering, and reachability for mobile hosts.
The two kinds of splits are truly orthogonal and complementary.

Kind regards,
- Christian

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Tony Li <[email-masked]>
Date: Tue, 8 May 2007 13:12:04 -0700

> existing prefixes must be replaced.

Christian,

I'm not following you at all here.  If the ID/locator split is at the  
edge of the network, the host needs multiple locators, but there need  
only be a single identifier.  This is also true if the ID/locator  
split is at the host.

Could you clarify?

Tony

---

From: Christian Vogt <[email-masked]>
Date: Wed, 09 May 2007 10:39:26 +0300

Hi Tony,

just up front:  By "edge of the network", you mean the "border between
the access network and an ISP", right?  This is what I was describing as
the locator/locator split in the network.

What the recent proposals for a network-side locator/locator split
pursue is to allow for PI addressing space inside an access network,
while still using aggragatable PA addressing space for packet forwarding
across ISPs.  The way they do this is, at a high level, by translating
IP addresses from PI addressing space to IP addresses from PA addressing
space.  Multiple PA IP addresses thereby map onto the same PI IP address
iff the access network is multi-homed -- because each ISP maps its own
PA IP address onto the same PI IP address of a host.

This is why you end up with only a single locator in the access network.
 This locator is independent of the ISPs, which is exactly what many
access network operators desire for traffic engineering and ISP changes.
 ISPs don't care so much if there are multiple locators for the same
host because they deal with only one of those locators anyway.

The recent proposals tend to call the single locator used in the access
network an "endpoint identifier", a term that I am not very happy with,
as explained in my previous email.

Does this make things clearer?

- Christian

Tony Li wrote:
>> If the ID/locator split is inside a host, the host still needs to
>> have multiple IP addresses, each with a prefix that topologically
>> corresponds to the respective upstream path.  In other words, a
>> host-based split still does not do away with access networks'
>> desire for PI addressing space.  This has two disadvantages:  (i)
>> The operators continue to face the same limitations with respect to
>> traffic engineering:  Hosts still choose the IP source addresses in
>> outgoing packets and thereby determine the ISP that the packets
>> must be forwarded through.  (ii) Network reconfiguration is
>> expensive when an access network switches ISPs since existing
>> prefixes must be replaced.
> 
> 
> Christian,
> 
>  edge of the network, the host needs multiple locators, but there
> need only be a single identifier.  This is also true if the
> ID/locator split is at the host.
> 
> Could you clarify?

---

From: "Alvaro Vives Martinez" <[email-masked]>
Date: Wed, 9 May 2007 18:23:07 +0200

Hello Brian,

> There's a sense in which Noel's question was in my mind when I wrote
> draft-carpenter-idloc-map-cons-00.txt. Noel has told me he's going
> to comment on that on the RAM list, but here would work too...
> 
> Just to complete the picture, we should probably also document the
> disadvantages of identity/location separation.
> 
> Quoting my own draft:
>     As implied by the previous section, there are cases where a split
>     would increase rather than decrease confusion.  Enterprise network
>     operations would be turned upside down.  Firewalls would have to deal
>     with fundamental change, since identifiers rather than locators would
>     be the focus of many attacks.  The way the DNS and the socket API are
>     related to each other might change.  Any upper layer implementation
>     that believes that an IP Address is both a Locator and an Identifier
>     would be in even greater trouble than today.  And of course the
>     fragile superstructure built on NATs and ALGs would be severely
>     challenged.
> These are all practical, operational disadvantages. Are there any
> architectural disadvantages?

IMHO in a layered model, where locator applies to one layer (lets say
internetwork layer) and identifiers to other layer (over the interntwork
layer), the introduction of the "split" requires a mapping mechanism.

Although quite obvious, the mapping mechanism is part of the described
architecture. It could be more or less complex but never null, IMHO.

Best regards,
Alvaro

> 
>      Brian
> 
> On 2007-04-22 17:01, Noel Chiappa wrote:
> > I was recently talking with someone of the recent discussion, and they
> made
> > the point that they hadn't seen a clear enumeration of the benefits of
> > separation of location and identity.
> >
> > This is something I tend not to think about in detail, because I am
> always
> > mindful of the Great Architecture dictum ("the hallmark of great
> architecture
> > is not how well it does the things you knew it needed to do, and it was
> > therefore designed to do, but how well it does things nobody had thought
> of
> > at the time it was designed"). E.g. nobody who did TCP/IP had any real
> idea
> > of the Web (the closest we came was something like the world of John
> > Brunner's "Shockwave Rider"). Not surprising; new things tend not to get
> > thought up until the architecture enables them. So, I tend to think in a
> very
> > different way (asking things like "does this structure express some
> > fundamental truth about the way things ought to be organized").
> >
> > However, it would probably be a useful exercise if we can enumerate, and
> to
> > some degreee evaluate, all the *immediate* benefits which separation of
> > location and identity will give us. Here are the ones I can come up
> with:
> >
> > - Multihoming: A number of aspects of multihoming are easier with
> separation.
> >   Specifically:
> >   - Avoiding having to give hosts multiple "addresses". With anything
> vaguely
> >     like the current routing architecture, we cannot support widespread
> >     multihoming purely within the routing (i.e. PI addresses). The only
> other
> >     technically feasible approach that years of work have identified is
> for
> >     such hosts have to have multiple addresses. Howeever, this seems to
> be
> >     an operation non-starter, and is the big objection to designs like
> SHIM6.
> >   - Keeping connections open if one address becomes unreachable (this
> applies
> >     to hosts with multiple interfaces too).
> >
> > - Provider independence for small organizations: It's much easier to
> switch
> >     providers if the low-level naming of hosts doesn't change when this
> >     happens. Currently, the only other ways to provide this are PI-
> addresses
> >     (which don't scale to support many small sites), and NAT.
> >
> > - Mobility: Mobility (especially as distinct from portability - the
> former
> >     term is taken to include keeping connections open) is basically
> >     impossible without separation of location and identity. Mobile6
> basically
> >     does this now, albeit with both namespaces being IPv6 addresses.
> >
> > - Multicast: Right now, the notion of the membership of a multicast
> group,
> >     and the distribution tree thereto, are inherently entangled. My
> feeling
> >     is that until we can separate the two, widespread multicast
> (especially
> >     lots of small groups) will be technically infeasible.
> >
> > Alas, I have a feeling I am missing a great deal, but I don't think well
> at
> > this level. Can others expand on this list?
> >
> > 	Noel
> >

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: "Alvaro Vives Martinez" <[email-masked]>
Date: Wed, 9 May 2007 18:32:24 +0200

Hello Dave,

> Noel Chiappa wrote:
> This is an important exercise, but it is equally important that it be
> done with sufficient scope.  For example, as Brian suggests, the
> negatives also have to be considered.
> 
> I also suggest that the characteristics of the split can have a massive
> impact on the characteristics of the result.
> 
> An obvious example is the level at which the constructs are provided.
> Since locator must remain with IP, the question is where the identifier
> is used and whether it is globally unique, persistent and/or public.
> 
> So, for example, it can be observed that we already have one kind of
> loc/id split, between IP Address and Domain Name.  That has some
> strengths and it has some weaknesses.  Any other choice for creating a
> new identifier venue will equally have trade-offs.

The difference, IMO, is that DNS/IP mapping is used within the same layer,
the application layer, and for the same thing. It only makes things easier
for human beings.

The loc/id split being discussed, IMHO, provides its benefits from the use
of locs and ids in different "layers" and for different things (roughly
said).

Best regards,
Alvaro

> 
> Further, the granularity of the benefits (goals?) makes a difference.
> The need to have the IP layer support identifier is based on some
> critical assumptions.
> 
> For example, there is a continuing assumption that two flows with
> different locator-pairs must be handled in the aggregate, by the IP
> infrastructure, if they are part of the same upper-level transmission,
> such as a TCP connection.  While this sounds completely reasonable, it
> well might not be necessary or even appropriate.
> 
> For example, just as a route tends to be relatively stable for the life
> of a given TCP connection, the amount of locator-pair changeability
> during a connection might actually be quite small.  If it is, then there
> is no real need for the IP infrastructure to know that the different
> locator-pairs are related.  This, in turn, means that the identifier
> might well be appropriate to provide at a higher layer, rather than a
> lower one.
> 
> d/
> --
> 
>    Dave Crocker
>    Brandenburg InternetWorking
>    bbiw.net
> 

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org