RE: draft-huitema-multi6-hosts-03

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

Hi Senthilkumar,

thanks for reading and commenting the draft.

below...


>
>    > 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.

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.


>
> 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.)

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.

>
> 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.
>

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

>
>
>