Re: Architecture [Re: Agenda for Vienna]

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Iljitsch;

> > My draft draft-ohta-e2e-multihoming-03.txt:
> 
> >                The Architecture of End to End Multihoming
> 
> > discusses, as is obvious from its title, architectural issue on
> > host based approach. It, of course, mention loc/id separation.
> 
> In this draft you say TCP (and other protocols, leaving those alone for 
> a moment) should get multiple addresses from the application.

Well, basically, I say hosts should have multiple addresses. It is,
of course, at IP layer.

Protocols above IP are, expected to exploit the benefit of
the feature.

> This is 
> what SCTP already does.

That's fine.

> I don't see how this is separating the locator 
> and identifier functions, it's just more instances of the combined 
> locator/identifier we're used to.

Reasoning in the draft is related to reverse look up with local
addresses.

The more strong reason is that implementation becomes a lot easier
but is not an architectural point

> I feel this approach isn't a good one both for architectural reasons 
> and for deployment reasons (this simply needs too many changes to too 
> many things).

It is architecuturally of course that a change at the IP layer
affects many things.

As for deployment, change is optionaly.

As I wrote several times already in this ML, our code is running
interoperating with leagacy hosts.

> The current architecture doesn't differentiate between 
> identifiers and locators so it imposes limits on one because of the 
> requirements for the other. This is messy. Having more of those 
> combined locator/identifier addresses just increases the mess linearly. 

That is an abstract nonsense against the running code.

> On the other hand, separating the identifier and locator functions 
> makes it possible to have both the advantages of a stable identifier 
> and the advantages of flexible locators.
> 
> However, I do agree that TCP knows much more about reachability than IP 
> so in practice we'll want to take advantage of that. But there are 
> other ways to skin this particular cat than selecting layer 4 as the 
> place to solve the multihoming problem.

IP layer, (layer 3), of course, is the place to solve the problem
of IP addresses.

Layers above, including but not limited to 4, are, of course,
affected.

NAT is a example (hopefully to a reverse direction) of how a simple
change at IP layer has tremendous effects on layers above.

A good news with out code is that upper layers are not affected
if a host or its peer chooses to stay to be as reliable as
a singly homed host.

							Masataka Ohta