Re: Some Comments on ID/Loc Separation Proposals

[Brian E Carpenter <brc@zurich.ibm.com>]

There is an abstract distinction between 

1) identifiers used for rendez-vous
2) identifiers used for binding 
and 3) identifiers used to maintain a session after binding.

Historically we thought of FQDNs being in 1:1 correspondence with 
IP addresses, except that we normally used the FQDN for rendez-vous, 
and the IP address for binding and session maintenance. 

Load balancing, anycast, and virtualization seem to have split apart 
the three functions.

Rendez-vous and binding have already occurred before multihoming enters 
the picture. I think multi6 only needs to consider the session maintenance 
ID and I ask people not to get distracted by the rendez-vous
ID or the binding ID in this discussion. 

(In TCP, the session maintenance ID is the IP address, and in SCTP
it's the default primary transport IP address, in fact.)

   Brian

Keith Moore wrote:
> 
> Perhaps there are bigger fish to fry, but it's absolutely necessary to
> make that distinction before we can make significant progress in
> separating IDs from LOCs.  You need both kinds of identifiers.  I
> informally think of them as "initial identifiers" vs. "connection
> endpoint identifiers", the former being an identifier associated with
> the (perhaps virtual) host that you initially attempt to contact; the
> latter being an identifier associated with the particular host that
> maintains the state necessary to continue conversations in progress.
> Such state may be at the kernel or the application level.
> 
> > Several folks have asked us how NOID would work with respect
> > to "hosts" that appear to be a single entity yet are
> > implemented using load-balancers and multiple actual servers.
> >
> > In this case, what does an "identifier" bind to?
> >
> > Noel is trying to make a semantic distinction between an
> > identifier that might be bound to one particular server in
> > the group and a different identifier that would be bound to
> > the entire "entity" of a balancer and servers supporting
> > a particular address.
> >
> > While I think that this is an interesting and useful distinction,
> > I also think that we have bigger fish to fry at the moment.