Subject: RE: Some Comments on ID/Loc Separation Proposals

From: "Tony Li" <[email-masked]>
Date: Thu, 20 Nov 2003 09:28:17 -0800

Erik,

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.

Tony

|  -----Original Message-----
|  From: Erik Nordmark [mailto:[email-masked]] 
|  Sent: Thursday, November 20, 2003 8:03 AM
|  To: J. Noel Chiappa
|  Cc: [email-masked]
|  Subject: Re: Some Comments on ID/Loc Separation Proposals
|  
|  
|  > I will suggest again that we take "identifier" to mean 
|  "name with basically
|  > no properties/functionalities" (other than identfying the 
|  thing which it
|  > names). To allow me to be precise hereo, I'll use the term 
|  "NF-identifier"
|  > when I want this meaning.
|  
|  Two points
|  
|  The folks in this WG seems to have gravitated to using
|  the term "identifier" to mean the name of a host (or stack).
|  I sometimes use the term "IP identifier" to make it clear 
|  where in the
|  stack it is relevant.
|  I don't know if it makes sense to use some other term at 
|  this point in time;
|  we do need to know what we mean and write it down.
|  
|  I don't know if there is any utility to NF-identifiers.
|  All uses of identifiers I can think of at least need some way to
|  verify to whom the identifier has been assigned. That might 
|  be because I'm
|  thinking about what you call names of objects and not pure 
|  identifiers.
|  Thus knowing where an NF-identifier would be useful would 
|  help clarify
|  things in my head.
|  
|    Erik
|  
|  
|

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Nov 2003 10:23:54 -0800 (PST)

> In this case, what does an "identifier" bind to?  

If the load balancing is transparent - with one IP address for
the service - then the identifier would bind to the load balancer
and the LB effectively has a private interface with actual servers.
Thus that case is out of scope.

If the load balancing is visble to the clients as multiple different
IP addresses then there is an pen issue and an opportunity that
is pointed out in the NOID draft.

In this case with NOID you can have multiple identifers=FQDNs
	www.example.com	for the service
	wwwN.example.com for each of the N servers

Since we propose adding a new "M6 capable" RR in the DNS
we have the option of making that new RR help distinguish
between case of multiple locators assigned to the same host/stack
and multiple locators assigned to different hosts/stacks providing
the service.
An example (probably not be best approach) of how this could be 
done is to have the M6 RR contain
the FQDNs for the host (the set of wwwN above) and a lookup
of the www1 etc would return the locators for that host.
Thus each host would have a unique FQDN, which would be part of 
the "cost" of using NOID together with this form of load balancing.

Other schemes might be able to use other approaches. For instance,
in CB64 all the locators for all the nodes could be in the AAAA
RRset for www.example.com and the client can see whether there
is one or multiple hosts by comparing the 64-bit hash of the 
public key; those AAAA RRs with the same hash are locators for
the same host. Hence the M6 layer can limit rehoming to be between
locators assigned to the same host.

Thus I think multihoming is an opportunity to make the
destinction between services and host names in the DNS more clear
for multihomed sites.

   Erik

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Nov 2003 14:30:14 -0500

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Nov 2003 09:09:07 +0100

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