Subject: Host Centric Multi-Homing

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 26 Jan 2004 17:53:58 +0100

Hi,

We would like to submit this new version of the Host Centric Multi-Homing
draft for the WG consideration

http://www.it.uc3m.es/marcelo/draft-huitema-multi6-hosts-02.txt

Coments are welcome,

Tahnks, marcelo

---

From: Cedric de Launois <[email-masked]>
Date: Tue, 27 Jan 2004 12:06:51 +0100

> http://www.it.uc3m.es/marcelo/draft-huitema-multi6-hosts-02.txt

Hi Marcelo,

Thanks for the new draft ! Here are some comments :

Section 3.3

Your example seems broken.
You wrote : 
  "To communicate with Y, X [...] will choose the source address [...]
   A:X"

and then :
  "If the chosen exit router at Site X is RXB, the packet will flow
   freely"

Substitute RXB by RXA ? 
Moreover, in your example, which address is used to contact Y : C:Y or
D:Y ?

I understand the problem but please, correct and/or clarify the example.

Section 4

Three components interacts in the multiaddress multihoming problem :
the source address, the ingress filters and the intradomain routing.
Essentially, I would divide the solutions into three categories,
depending on which component is adapted in order to solve the problem :

 a) Honor source address and routing, adapt filtering
 b) Honor source address and filtering, adapt routing
 c) Honor routing and filtering, adapt source address

Your section 4.1 is equivalent to a). Your section 4.2 is equivalent
to b) and section 4.3 to c), but I would move the "exit router
discovery" procedure from c) to b). I explain : in this case, we don't
adapt the source address. Instead, we use tunnels to force the routing
system to convey the packet to where the host wants. That is : we adapt
the routing and honor source address selection and filtering.

Note that I'm not sure about the "exit router discovery" procedure being
superior to the source address discovery. The use of tunnels reduces
the MTU. While this is acceptable for e.g. particular QoS applications,
we should not impose this mechanism for the general case.

Section 4.4

The case described in this section appears to me as a special case of : 
 c) Honor routing and filtering, adapt source address
That is : we just adapt the source address on the fly, at the site
exit router.

7. Proposed solution

   "In this section,
   we will present the recommended ways to solve the site exit issue and
   how to trigger rapid reactions to local failures."

What do you mean by "local failures" ? Failures that occur inside the
mh site ? Link failures between the mh site and an ISP ? Failure of
an ISP of the mh site ?

Section 7.1 Multihoming solution for big sites

Only relaxing the source address check does not completely solve
the IPv6 multihoming problem. Remember that to preserve scalability
the site advertises prefix PA only to ISP A. If ISP A is down, we must
prevent the use of prefix PA since BGP doesn't know that it can route
packets with destination prefix PA to another ISP of the mh site,
say ISP B.
Thus we also need a mechanism for big sites to manage wich prefixes
can be used and which cannot.

7.2.2.2.2 Reaction to other failures modes

   "the proposed mechanism to
   identify available paths will be based on the trial and error
   procedure."

This is probably the base generic mechanism. All others mechanisms
described (router renumbering, router advertisement, ...) only give
hints about which prefix should be tried first. The base mechanism
of trial and error is always needed, e.g. when a host
doesn't get a response because the return path is broken somewhere
in the Internet.
So I suggest to present it as the base mechanism, and present
others as optimizations.

Section 8.1.2

What about outbound traffic engineering ? Even
the simplest mh site might want to balance its traffic between
e.g. its DSL and Wireless lines.

Pure editorial notes :

Section 8.1.3 

"Performance enhancements can be obtained by appropriate development
 if destination address selection and source address selection
 algorithms."

 s/if/of/

Section 8.1.4

 "The Policy table defined in [15] allows to preffer"

 s/preffer/prefer/

 "the policy table allows to express the preffered exit path"

 s/preffered/preferred/

Thanks,

Cedric

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 27 Jan 2004 17:19:22 +0100

Hi Cedric,

thank you very much for your comments, some answers online...

I have already updated the draft with some of your comments, you can check
it at the same location:

> I understand the problem but please, correct and/or clarify the example.

I am sure you do :-)

I have already corrected it in the new version

> discovery" procedure from c) to b).

Yes, i have considered this option since it makes sense to me too.

However, this approach is basically focused on who actually has to deal with
the problem.
In the first case you simply relax address checks, in the second case you
modify the oruting system in order to deal with the problem, in the third
case, the hosts solves the problem, either forcing the source address or
forcing the exit router.

I mean, there are multiple different ways to classify the different
approaches and some people would probably see one approach more natural of
the others, but this will vary with people.

As i said earlier, i like also what you are proposing but i also find the
presented approach valid.

> I explain : in this case, we don't

The problem with source address discovery is what to do with the first
packet. I mean, with site exit discovery, the first packet can be tunneled
towards the appropriate exit, while with source address discovery you
probably have to discard it. So as solution for the site exit issue seems
inferior. However, for reacting to topological changes it is suitable, since
the selected source address cannot be used.

> mh site ? Link failures between the mh site and an ISP ? Failure of

yes this is not clear. I have dropped the "local"

> can be used and which cannot.

You are right, of course.

The idea is to use a similar but simpler mechanism to the one proposed for
medium sites.

> So I suggest to present it as the base mechanism, and present

The presented approach is incremental.

Using Radv to deprecate a prefix can be implemented with legacy hosts while
the trial and error procedure requires updating the hosts.

So the proposed approach is incremental, and the first steps are those that
don't impose much changes. Then the next steps provide a more general
solution but impose more changes.

> e.g. its DSL and Wireless lines.

The policy table of the default address selection mechanism can provide some
of the stuff that you need, but we should inlcude it in the text i guess.

> Pure editorial notes :

fixed.