Subject: re: draft-huitema-multi6-hosts-03

From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" <[email-masked]>
Date: Sun, 15 Feb 2004 03:10:58 -0600

> 3.2 Source address selection
   > [...] 
   > Choosing the source address will affect the reverse path of the
   > connection, as the source address of the message will become the
   > destination address of the responses.

    +-- ISPA --+
S --+          +-- ISPC
    +-- ISPB --+

S is MH to A&B; A, B and C are inter-connected and engage in private peering. 
remember C is not a transit between A and B (although, it is fairly common to 
have C accidentally misconfigured as a transit.) The site S lacks a PI space.
S picks a prefix allocated by A, as it gives better performance.

In this case, A's aggregation is not broken and hence, it just announces its
prefix to both B and C. B's aggregation is broken and it announces both
its own prefix & S's prefix Sa to A&C (assuming we avoided the ingress 
filtering problem by the magic stuff mentioned in the draft.)  ISP C, on the
other hand, will choose a route to S through B and not A (due to longest
prefix match.) So, the traffic route can disagree with the AS path advertised 
by BGP. It may be due to routine removal of routing information at ISP level 
in the name of aggregation, filtering and local policy setting. hence, it is 
not possible to predict the reverse path based on the source address (unless, 
if we depend on an external measurement system.)

As for dest address selection, trying every other prefix is the only current
option. Alternatively, one can think in terms of router level feedback to
end systems about path coditions ( sally floyd's Quickstart proposal can be 
easily extended to support such a feature.) But, I presume, we don't have 
enough machinery to predict path reliability at router level.

If we observe closely, it is hard to do address selection at user level
(although, it has more incentive.) else, an external measurement system (in
the form of overlay) can routinely measure the Internet space and can provide
path reliability details. but, it is still hard due to provider centric 
routing policy control. So, how about this? Lets relegate the address 
selection problem to providers and just work on multi addressing at transport
level ( for it can act as a hint to provider based selection.) It will also
allow a limited form of user control.

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 16 Feb 2004 12:28:26 +0100

Hi Senthilkumar,

thanks for reading and commenting the draft.

below...

> S picks a prefix allocated by A, as it gives better performance.

Well, this is what mh sites do in IPv6, but this has the problem of adding
routes to the global routing table, so Host Centric multihoming for IPv6
proposes otherwise.

In this case, the mh site will have TWO prefixes one per ISP and will have
to select which one to use.

Each ISP only announces its own aggregate (no additional more specific
routes to describe mh sites)

So none of the ISP aggregation is broken

This implies that each prefix is only routed through a single ISP and not
any of them as in IPv4

This is why the source address selected determines the return path.

> if we depend on an external measurement system.)

see above.

Note that when i mention the return path, i am really only considering which
one of the ISPs of the multihomed site will be used by return packets. Other
parts of the the return path are out of the reach of the multihomed site.

> allow a limited form of user control.

Well, there are two different scenarios to consider IMHO.

In one case, you have the upgraded transport layers or even applications
that are aware that multiple prefixes are available and know how to manage
them. This type of transport and apps will be able to really benefit from
multiple paths. Host centric proposal does not preclude that. If the
transport or app selects a single source and destination address, the IP
layer of a host implementing host centric multihoming will honor this
selection.

So, no problem with your approach and host centric multihoming, i guess.

The other case is when neither the app nor the transport is capable of
handling multiple locators, just imaging most of the current apps and
transport.
In this case the app or the transport is only capable of sending packets to
a given destination and it may retry when the selected destination is
unreachable.

Host centric multihoming goal is to provide multihoming benefits in this
scenarios, without requiring modifications to transport, nor apps nor
external hosts.

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 16 Feb 2004 12:37:53 +0100

> Well, this is what mh sites do in IPv6, but this has the problem of adding
                                      ^^
I meant IPv4.

Sorry,
regards, marcelo