Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-02.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 3 Mar 2005 18:02:21 +0100

Hi Chan-Wah,
>>
>> indeed, but this essentially means that you are adopting source 
>> address
>> depedendent (SAD) routing within the nemo, which one of the general
>> approaches that you can use for dealing with ingress filtering in
>> multihomed environments.
>
> Yes, in fact, having normal MMNs (host) to use different default 
> routers
> corresponding to different source address prefix is also a form of
> SAD-routing.
>

well, there is a difference between source routing and source address 
dependent routing, right?
I mean i think that MNM select among different default router is a form 
of source routing but not actually SAD routing. But in any case, i 
think this is perhaps too much distinction.

>
>> Now, this is not as simple as it seems since basically you are 
>> changing
>> the routing paradigm within the network, which may have unforeseen
>> consequences (i am not trying to spread fud here, just re-stating some
>> concerns that were expressed during the discussions of these topics in
>> multi6)
>>
>> In addition, R does no need to be a MR, it just need to implement SAD
>> routing, no need for the complete MR functionality.
>>
>> So, this problem is general to all mutlihomed networks, and the
>> approaches imho are the same whether the network is mobile or not. for
>> general approaches to the ingress filtering problem in multihomed
>> networks, please refer to  draft-huitema-multi6-ingress-filtering-00
>>
>
> Agreed.  How about we rewriting the statement to:
>
>     A possible approach to solving this is to employ some kind of 
> source
>     address dependent routing in the MNNs (such as requiring MNNs to
>     set their default router to the MR that advertises the MNP the MNNs
>     configured their address from). There are certain issues and
>     considerations associated with such an approach, and the readers
>     are referred to [draft-huitema] for a more detailed analysis.
>

The only thing that bothers me about the default router part is that it 
is not trivial from this to deduce that also mobile routers have to do 
this, which is as you mentioned earlier, required for this to work. see 
what i mean?

> -- 8< consensus portions snipped >8 --
>
>>>>
>>>> Later on, it is stated that
>>>>
>>>>     To avoid ingress filtering mechanisms dropping packets in such
>>>>     situations, MR(s) can stop advertising P1.  This would prevent
>>>> MNNs
>>>>     from using the address auto-configured on this prefix.
>>>>
>>>> Now for this you need additional stuff:
>>>> first you need a mechanism to detect the failure that is addressed
>>>> later on on the draft (i would suggest a reference to the next
>>>> section)
>>> OK.
>>>
>>>> Second you need to use something like router renumbering or dhcp
>>>> prefix
>>>> delegation when the nemo has more than one link, since Router
>>>> advertisment is link scoped.
>>>
>>> OK.  But most of this occurs in normal site multihoming, so I guess 
>>> the
>>> best approach for us is to provide more extensive reference to all 
>>> the
>>> work done in multi6.
>>>
>>
>> agree, but most of the items above also fall into this category. For
>> instance all the ingress filtering problems, source address selection
>> issues, failure detection mechanisms also are common with multi6 ones.
>>
>
> Yes, in the next version, we would reference more extensively to the
> work done in multi6.
>
>> I think that you have try to do this in the new version of the draft, 
>> i
>> will comment on that on another message.
>>
>>>>
>>>> I mean, all this ingress filtering stuff is not so easily solved in
>>>> the
>>>> general case, imho in some configurations you will need or:
>>>> - a mesh of tunnels between the MR
>>>> - source address dependetn routing in the nemo
>>>
>>>> see draft-huitema-multi6-ingress-filtering-00.txt for more details
>>>>
>>>
>>>> Section 4.4  Failure Detection it is stated that
>>>>
>>>>     There are other failure modes to consider as well, such as
>>>> failure at
>>>>     home agent, failure at access routers, or in general failure of 
>>>> a
>>>>     link or node along the path from the mobile router to the home
>>>> agent.
>>>>     By the nature of the routing infrastructure, failure of
>>>> intermediate
>>>>     nodes or links are recovered by the the routing infrastructure 
>>>> by
>>>>     choosing a different route.
>>>>
>>>>
>>>> this is clearly not the case in multihoming. I mean in the case 
>>>> where
>>>> the multihomed nemo has multiple prefixes and each one is associated
>>>> with a different home link, the communication will be preserved by
>>>> using a differnet address that is routed through a different home
>>>> network, In this case, you need to change addresses, so the routing
>>>> infrastructure will not do the trick.
>>>> I mean, in the other failure modes you cannot assume that the 
>>>> problem
>>>> will be solved by the routing infrastructure (if not multi6 would be
>>>> out of work :-)
>>>
>>> I think you misinterpret that statement, or equally probable, we did
>>> not
>>> write the statement clearly.  What it mean is that for failure that
>>> occurs in routing infrastructure, the routing infrastructure would
>>> recover itself ... since IETF designed it to self-healing.  I guess 
>>> we
>>> should re-write the statement to clearly state that.
>>>
>>
>> Well, i think that the problem is more complex than this, let me try 
>> to
>> expand on this.
>>
>> Suppose that we have a (*,n,n) nemo, where each HA is located is a
>> different home network, which has a different global prefix. So this
>> means that if there is a failure in one of the home networks, the nemo
>> is reachable through the alternative home netwrok, but using an
>> alternative address/prefix.
>>
>> Now suppose that an outage occurs in the routing infrastructure that
>> affects the path between the Internet and one of the Home networks, As
>> you say, the routing system will attempt to obtain alternative paths.
>> More precisely, this means that BGP will identify the outage, identify
>> alternative paths and the reconverge to the alternative route. The
>> problem is that this may take a while (180 sec is the recommended 
>> value
>> for BGP to detect an outage, then you need to reconverge, which may
>> take also a while)
>>
>> Now, in this scenario, probably the multihoming mechanisms of the nemo
>> will react faster than the routing system in some cases. so probably
>> even if the outage can be recovered through the routing system,
>> multihoming mechanisms will provide a better response and react 
>> faster.
>> Makes sense?
>>
>> I mean, multihoming mechanisms of multi6 are end to end, so there are
>> no failures modes that are not covered by them (by definition)
>>
>
> That I concur.  So, may I suggest that we add a few statements after 
> the
> original text to describe that (1) recovery would be faster by using
> multihoming mechanism than to rely on routing infrastructure, and (2)
> NEMO WG should adopt any multihoming solution developed by multi6.
>

ok, but i am not sure that multi6 will provide all that nemo needs

regards, marcelo

>
>>>> Finally, separate the references in normative informative
>>>
>>> Hmmm...  is that necessary?  I mean, the draft itself is an
>>> informational document.
>>
>> I think so, but i guess the chairs can tell us about this.
>>
>
> Would the chairs care to comment?
>
> /rgds
> /cwng
>

---

From: Chan-Wah Ng <[email-masked]>
Date: Fri, 04 Mar 2005 12:10:43 +0800

Hello Marcelo,

> think this is perhaps too much distinction.

Well, I don't know.  The term "source-address-dependent" routing is new
to me.  To me, if the forwarding agent makes routing decision taking
into consideration the source-address of a packet, it is source routing.

> this, which is as you mentioned earlier, required for this to work. see 

Yes, let me try again:

    A possible approach to solving this is to employ some kind of source
    address routing in the MNNs (such as requiring MNNs to 
    set their default router to the MR that advertises the MNP the MNNs
    configured their address from, and requiring LFR to make routing
    decision based on the source address when forwarding packets within
    a NEMO).  There are certain issues and considerations associated
    with such an approach, and the readers are referred to
   [draft-huitema] for a more detailed analysis.

> ok, but i am not sure that multi6 will provide all that nemo needs

We have two (perhaps more) possible options here:
(1) to charter NEMO-WG to solve multihoming issues that are specific to
NEMO,
(2) to wait and see what solution multi6 comes up with.

I think we can defer debating on this after hearing what you would
present next Wednesday?

/rgds
/cwng

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 4 Mar 2005 17:12:29 +0100

> into consideration the source-address of a packet, it is source 

I think this is not the case...
I mean source address dependent routing is when the routing decision 
takes into account the source address of the packet.
Source routing, AFAIK, i when the source of the packet determines the 
route of the packet. For instance you can do source routing in IP when 
you include all the intermediate nodes in the packet (you can also do 
loose source routing when you only includes some of the intermediate 
nodes)

So, one solution for ingress filtering is source address dependent 
routing. In this case the source (i.e. the host) does not determines 
the path that the packet will follow. Actual routing is still performed 
by the routers, which now also take into account the source address.

The other option is to let the host to determine the full path, through 
for instance a routing header. In this case, the routers still look 
only to the destiantion address, but is it the endpoint the one that 
determines the path. This is more similar to the case where the hst 
determines the default router depending on the prefix that is 
announced. But again, this is merely a terminology issue i guess.

>     configured their address from, and requiring LFR to make routing
                                     ^^^
I don't think you need both of those.
I mean if you manage that all the routers perform SAD routing, then you 
don't care about what hosts do. I mean if hosts select the wrong 
default router, the router will react since it is also taking into 
account the source address.
(sorry for not bringing this out earlier)
So my point (now) is you only need routers to perform SAD routing. 
Hosts don't need to support nothing new in this case (which is good 
imho)

> -- 8< consensus portions snipped >8 --

...

> I think we can defer debating on this after hearing what you would

ok.
I think that multi6 has some very strong assumptions that may not hold 
true in multiple scenarios that are relevant for nemo. In particular, 
multi6 assumes that if you change the prefix, then you are changing the 
exit path. This assumtions is clearly not true for any (*,*,1) 
scenario, for instance.

Regards, marcelo