Subject: RE: Identifier/locator recap

From: "Tony Li" <[email-masked]>
Date: Sun, 16 Mar 2003 15:55:53 -0800

Iljitsch,

You did a fine impersonation.  

At this point, I'm quite happy not to sweat the 8+8/GSE/16+16
distinction.  If we can get to consensus that we need separation
of locators and identifiers, then we will have made good progress.
Let's agree on the macro before we work out the micro.

Tony

|    -----Original Message-----
|    From: Iljitsch van Beijnum [mailto:[email-masked]] 
|    Sent: Sunday, March 16, 2003 7:24 AM
|    To: Bound, Jim
|    Cc: [email-masked]
|    Subject: Identifier/locator recap
|    
|    
|    On Sun, 16 Mar 2003, Bound, Jim wrote:
|    
|    > Could you write up your technical idea without a lot of 
|    man hours to
|    > describe and why it solves the multihome problem.
|    
|    I'm not Tony, but:
|    
|    Traditional multihoming as is done in IPv4 will not scale.
|    
|    An alternative is to give each host in a multihomed site 
|    an address for
|    each ISP the site is connected to. When (the link to) one 
|    ISP fails, the
|    communciation is diverted over the other ISP. However, 
|    current transport
|    protocols are unable to jump to new addresses in 
|    mid-session. Solution:
|    separate the identifier and locator functions of the IP address.
|    Transport protocols then use the identifier, which doesn't 
|    change during
|    the lifetime of the session, while IP uses the locator, 
|    which may be
|    changed at any time in order to route around broken parts of the
|    network.
|    
|    A few things that need to be addressed to make this happen:
|    
|    - Locators must always be present in each packet. But what 
|    about the
|      identifiers? Do we include them in each packet (= 
|    tunneling) or are
|      they implied?
|    
|    - How do we discover identifiers and/or locators?
|    
|    - How to we authenticate the relationship between locators and
|      identifiers?
|    
|    There is also the question of what makes good identifiers. 
|    HIP uses the
|    fingerprint of a cryptographic key. MHAP uses 
|    provider-independent IPv6
|    addresses that aren't visible in the global routing table. 
|    I myself have
|    suggested to use FQDNs as the first choice.
|    
|    Note that there seems consensus here that we shouldn't try 
|    to revive GSE
|    or 8+8: some kind of "16+16" would be much easier to deploy.
|    
|    Iljitsch
|    
|    
|

---

From: Eliot Lear <[email-masked]>
Date: Sun, 16 Mar 2003 18:46:19 -0800

> Let's agree on the macro before we work out the micro.

I would like to second Tony's request.  We would do well to fully 
understand all of the architectural limitations to making this 
separation happen.  There is now a lot of work in this space from which 
we can build.  HIP, 8+8, and MIPv6 are good starting points.  The NSRG 
still has a forthcoming RFC on these points.

Eliot

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 19 Mar 2003 07:10:42 +0100 (CET)

> Let's agree on the macro before we work out the micro.

To me this is a no brainer because I can't see how there
can exist a scalable approach to multihoming that doesn't
separate identifiers and locators.

At some level one could argue that host multi-addressing is scalable
(at the expense of moving complexity to the hosts and applications).but
my concern is that host multi-addressing will more or less have
the hosts track with source/destination combinations (which approximate
routing paths at some rough level) work vs. doesn't.
To get fast failover this essentially turns into doing end-to-end "hello"
traffic instead of relying on the local hello traffic performed by the routing
protocols. So I think there are severe limitations in making this scale.
(And trying to aggregate this end-to-end "hello" traffic will just
cause a reinvention of routing.)

From the email traffic I'm guessing there is a significant fraction of the
folks on this list that think that identifier/locator separation is necessary
for the long-term solution.
There seems to be more disagreement about possible shorter term steps.

But I could be misreading things...
  Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 19 Mar 2003 08:45:09 +0100 (CET)

> protocols. So I think there are severe limitations in making this scale.

There is one big fat advantage to having this in the hosts: those
already track the end-to-end status of sessions.

Doing it in middleboxes is more complex, but it should be doable without
spending too much bandwidth on reachability tests: a middlebox typically
communicates with many other middleboxes (or hosts) and many of these
sessions share a significant amount of infrastructure. So rather than do
a reachability check for each session every 90 seconds (yes, this is
very long but it's the same as the BGP hold time listed in RFC 1771 and
Cisco even uses 180 seconds by default) the middlebox can simply do a
reachability check for say 1/300th of all sessions each second. That
means each sessions will be checked every 5 minutes. But as checks start
to fail, their number is increased, starting with ones that fall inside
the same 32. The effect is that the closer the failure is to the
middlebox, the faster it will be detected. Only when the path between
two middleboxes shares no infrastructure with other paths, and this
non-shared infrastructure fails, it may be necessary to wait the full
300 seconds.

Iljitsch

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 19 Mar 2003 07:01:15 -0800

Erik Nordmark wrote:
> But my concern is that host multi-addressing will more or less have 
> the hosts track with source/destination combinations (which
> approximate routing paths at some rough level) work vs. doesn't. To
> get fast failover this essentially turns into doing end-to-end
> "hello" traffic instead of relying on the local hello traffic
> performed by the routing protocols. So I think there are severe
> limitations in making this scale. ...

Erik's comment above let me back to an observation that
I made some time ago, but which I failed to write up
before this.

It looks like that if we go for the locator/identifier
separation and multi-addressing, we go for an architecture
where we combine today's hop-by-hop routing with some limited
source routing.  The routers continue to do hop-by-hop
routing on addresses, just as today.  However, either the
hosts or some middleboxes start doing what is effectively
some kind of limited source routing:  based on the identifier
they select the best destination/source address pair from
a number of possibilities.  In that way they affect the
route that the packet takes, i.e., perform source routing.

To perform high quality source routing there should be
some idea of the topology.  That idea does not need to be
detailed; often simple RTT estimates might be enough.
But something is needed.  I think Christian's slides
contained a fairly good summary of this.

I don't know if this observation is of any value.
I just wanted to post it in the case that it might
help people in their thinking.

--Pekka Nikander

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 19 Mar 2003 11:57:12 -0500

I concur with Erik Nordmark's analysis of things.

On Wednesday, Mar 19, 2003, at 02:45 America/Montreal, Iljitsch van 
Beijnum wrote:
> Doing it in middleboxes is more complex,...

	Middleboxes break the end-to-end principle and are generally not
desirable architecturally.

	Since we have at least one architectural approach (i.e. 
identifier/locator
separation) that does not need/use any middleboxes, please let us all 
agree
that middlebox approaches are not desirable here -- and not discuss them
at any further length in this WG.

IMHO,

Ran
[email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Mar 2003 00:13:49 +0100 (CET)

> identifier/locator separation) that does not need/use any
> middleboxes, please let us all agree

I agree middleboxes aren't desirable. On the other hand, I doubt very
many people will applaud a clean architecture if that means they have to
upgrade large numbers of individual hosts rather than a few middleboxes.
And it's not just deployment; implementing policies on individual hosts
is much harder than doing it on middleboxes or border routers.

Iljitsch

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 20 Mar 2003 22:32:05 +0859 ()

Ran;

> desirable architecturally.

Right. However, to be honest, DNS servers are middleboxes.

But, they are not intelligent but dumb middleboxes.

Load concentration, caused by the violation of the e2e principle,
is taken care of by light weight protocol. Never say X.500.

Lack of reliablity, caused by the violation of the e2e principle,
is taken care of by multiple servers.

DNS servers are necessary evil that the point is not to
introduce yet another evil

> at any further length in this WG.

But, we need DNS.

With IPv6 with 16 bytes of an address, we are a lot more motivated to
favour domain names over raw address than with IPv4.

With multiple addresses (or locators), we are motiveted even more.

In general, if we want to introduce structure unrelated to the
network topology, we have similar problem as DNS.

							Masataka Ohta