RE: Consensus on identifier/locator split?

["Ayyasamy, Senthilkumar (UMKC-Student)" <saq66@umkc.edu>]

>How ought we (if at all) deal with the notion of a virtual end point 
>such as a "content routed" service like CNN?  Particularly in the face 
>of mobile nodes.  If we deal with it at all we don't want TCP 
>connections breaking, and yet one wants to find the closest server 
>hosting this identity (whatever that means).  I raise this because one 
>way of looking at the answer would be to simply have a server appear 
>with multiple agencies in the routing system.  That's inelegant and 
>expensive.  DNS and anycast is incomplete due to mobility.

Currently, content routing is done by putting the burden onto 
DNS. The scheme is attractive, because it requires no change 
to both the router and host. But, makes changes to DNS (like 
CNAME record etc) depending on the content distribution type.
I guess, many in IETF are so much concerned about overloading 
critical infrastructures like BGP and DNS. Other than that,
a lot of measurement based local optimization and assumptions
affect the granularity of the server selection process. so,
we need a solution which does not depend on DNS. 

as you mention above, content routing can be done using IP 
mobility; there by preserving transport level connectivity.
MIP6 can be used for redirection without the need for DNS. 
For example, consider CNN server (replicated) as a mobile 
node, request router being the home agent and the client be
the correspodent node. In our case, the request router(home
agent) must make a server selection based on server load, 
available BW info and proximity etc; unlike DNS based 
server selection. Here, the load/proximity information is
the equivalent of "location update" as in MIP. 


btw, I agree with you that it is one way of looking at 
the locator/identifier separation.

>If CNN doesn't do it for you,

CNN doesn't do the request routing. They are just a 
content provider. All the intelligent routing control 
is done by third party distribution service providers 
like akamai. 


[ from your other mail ]
>It's already done below the application layer in many cases, 
>particularly when trying to determine the "closest" data 
>center. All I'm asking really is that we consider all the 
>knobs that exist today, across a broad set of areas, when 
>looking at architectural choices.  I'm not asking anything 
>more specific.

something more tangible? so, whatever solutions proposed in 
multi6 should purely be judged by:

o its dependence on previous loc/id separation solutions,like 
  MIP. major architectural changes (like new  namespace) 
  should be done else where.

o required change to routers/hosts

o offcourse, other requirements listed in the draft.

MIP6 based proposals seems like a way to move forward. 


[replying to Tony's post]
> Do we have consensus about splitting the address into 
> locators and identifiers?

Yes. But, a dedicated group of experts (NSRG) was not 
able to come to a conclusion on the "type" of loc/id
split. so, multi6 should avoid making major long term
architectural changes. 


  -- senthil