Subject: Re: about draft-ohira-assign-select-e2e-multihome-00.txt (was :Re: Callfor presentations)

From: "Kenji Ohira" <[email-masked]>
Date: Wed, 9 Jul 2003 19:54:24 +0900

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Marcelo,

Please forgive me for my late reply.

At the beginning, I revised my draft. So please read my revised draft.
It can be downloaded from
ftp://ftp.ietf.org/internet-draft/draft-ohira-assign-select-e2e-multihome-01.txt .

> What do you mean by "the proposed way to multi-home"?
> I mean, I couldn't find in the draft a description of any mechanisms to
> multi-home...
My proposal can be summarized as follows.
1. Assign IP addresses hierarchically.
  e.g.: When a site A subscribes to a local ISP L and M, a host H in 
        the site A has addresses L:A:H and M:A:H.
2. Use source address based routing.
        In case of the above example, a packet with L:A:H as source
        address will go through ISP L and a packet with M:A:H as source 
        address will go through ISP M. End hosts (further more, end 
        applications) can select which ISP a packet will go through.

> I guess that there should be a reference to a concrete mechanism
> proposal, Otha's e2e multihoming perhaps? but there are no references in
> the draft, could you clarify this form me?
Too right. My draft is based on Ohta's e2e multihoming.
It is my mistake that the old draft did not have reference to Ohta's
draft. So I added the reference to my revised draft.
Then, some points are different from Ohta's draft.
First, I think that if we assign IP addresses hierarchically then all 
nodes do not have to know full routes.
Second, we proposed to use source address based routing.
It allows end hosts to select prefer route without full routes.
At this time, it should be noted that source address based routing is applied 
only to default routes because if a node have some explicit route then 
it is reasonable to use that explicit route.

> Besides, if i understand the draft correctly, it is about ingress
> filtering and source address based routing, so have you checked C.
> Huitema's draft about host centric multi-homing? 
Following your indicate, I read Huitema's draft and I understand that 
Huitema's solution is using tunnel at site exit router.
It sounds good because Huitema's solution does not require any 
changes on end hosts and routers in a site (except for site exit routers).
However, using tunnel sometimes causes routers to select not prefer 
route. Still more, site exit router may become single point of failure.
And then, it is the most important point, we regard selecting source 
address as selecting route. Selecting source address is no less important 
for end hosts (furthermore, applications on the end hosts) to select proper 
route than selecting destination address. Even if there is no ingress filter, 
each packet should go through adequate site exit router according to its 
source address.
At this time, it should be noted that Huitema's proposal is considerable 
as an option while routers and/or hosts do not support source address 
based routing enough.

Best regards,

July 9, 2003 (JST +0900)
----
Kenji Ohira
Graduate School of Informatics, Kyoto University, JAPAN
mailto: [email-masked] / [email-masked]

---

From: Cedric de Launois <[email-masked]>
Date: 10 Jul 2003 11:59:00 +0200

>         applications) can select which ISP a packet will go through.

AFAIK the 2 points above were also suggested in Huitema's draft.
>From my point of view your suggestion is :

1. Use Huitema's Host-Centric Multihoming with source-base routing
2. Let the end-hosts' applications decide which source address to use,
   i.e. change end-hosts' API and applications (this is not clear in
   your draft)

Is that correct ?

If yes, how do you perform the source address selection ?
Does that mean that all applications on the end hosts need to be
modified in order to benefit from multihoming ?

Cédric

---

From: "Kenji Ohira" <[email-masked]>
Date: Fri, 11 Jul 2003 16:04:03 +0900

Cedric,

>    i.e. change end-hosts' API and applications (this is not clear in
Yes. You are faultlessly correct.

> If yes, how do you perform the source address selection ?
First of all, I think that multihoming can not nor should not be conclude 
within IP layer and that the source address selection is not issue in IP layer similarly.
So, this issue is out of scope of my draft.
Still more, this is why the title of my draft is not 'host-centric' but 'end-to-end' multihoming.

Of course, I know that this issue is still difficult in transport or application layer.
In my draft, I introduce a naive but workable method that examining each path 
determined by a pair of source address and destination address one by one in 
order of  match length between the source address and destination address.
Here, I would like to introduce more intelligent mechanism of selection such as
your NAROS system.

> modified in order to benefit from multihoming ?
No. I think that we can assume a certain 'typical model' of application and that
extended TCP or SCTP will be able to treat with multihoming for this model.
In this case, applications do not need to be modified.
However, someone/some applications may require to control the parameter for 
multihoming by itself.
For those, we have one solution by end-to-end path selection with extended 
socket APIs of TCP for end-to-end multihoming.
A. Matsumoto, co-author of my draft, is now working on this issue.
So please read draft-arifumi-lin6-multihome-api-00.txt.

July 11, 2003 (JST +0900)
----
Kenji Ohira
Graduate School of Informatics, Kyoto University, JAPAN
mailto: [email-masked] / [email-masked]