RE: Host Centric Multi-Homing

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

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:

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


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

I am sure you do :-)

I have already corrected it in the new version

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

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

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.

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

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

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

You are right, of course.

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

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

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.

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

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.