Re: Host Centric Multi-Homing

[Cedric de Launois <delaunois@info.ucl.ac.be>]

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

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