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

From: [email-masked]
Date: Tue, 22 Feb 2005 16:06:24 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Mobility Working Group of the IETF.

	Title		: Analysis of Multihoming in Network Mobility Support
	Author(s)	: T. Ernst, et al.
	Filename	: draft-ietf-nemo-multihoming-issues-02.txt
	Pages		: 36
	Date		: 2005-2-22
	
This document is an analysis of multihoming in the context of network
   mobility (NEMO).  As there are many situations in which mobile
   networks may be multihomed, a taxonomy is proposed to classify the
   possible configurations.  We also describe possible deployment
   scenarios and we attempt to identify issues that arise when mobile
   networks are multihomed while mobility supports is taken care by NEMO
   Basic Support.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-nemo-multihoming-issues-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 24 Feb 2005 17:41:30 +0800

Hello all,

Like to highlight what are the main changes to this version of the
draft.  Changes are basically minimal, with the most important change as
the addition of the authors' opinions on which WG(s) is/are better
suited to address each of the issues listed in Sect 4.

These additions, as I'd said, is largely the opinions of the authors, so
it is subjected to the WG's consensus.  Would thus like to make use of
the slot in Minneapolis to talk a little about it.

Thanks,

/rgds
/cwng

On Tue, 2005-02-22 at 16:06 -0500, [email-masked] wrote:
> reference to remote file attachment
> Content-Type: Message/External-body; access-type="mail-server";
> server="[email-masked]"
> 
> Content-Type: text/plain
> Content-ID: <[email-masked]>
> 
> ENCODING mime
> FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-02.txt

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 24 Feb 2005 11:51:54 +0100

Hi,

a while ago i made several comments about the previous version of this  
draft, which you can find in  
http://www.ietf.org/mail-archive/web/nemo/current/msg01970.html but is  
didn't receive any answer and i think they were not included in the  
draft, could some of the authors comment on that?
Thanks, marcelo

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 24 Feb 2005 21:41:42 +0800

Hello Marcelo,

> draft, could some of the authors comment on that?

I am sorry, I must have missed your earlier mail.  Let me response to it
now.

On Tue, 2004-11-16 at 19:16 +0100, marcelo bagnulo braun wrote: 
> Hi all,
> 
> just some additional comments about this draft
> 
> Section 2. states that:
> 
>     One thing the reader has to keep in mind is that in each of the
>     following 8 cases, the MR may be multihomed if either (i) multiple
>     prefixes are advertised on the home link, (ii) multiple prefixes are
>     advertised on the visited link,
> 
> Now, i am not sure the ii) case is relevant here. I mean, in this case, 
> the visited network is the one that is multihomed, not the NEMO. In 
> this case, the MR will be just on more node within the multihomed 
> visited network. I don't have a strong opinion on this, just that i was 
> puzzled when i saw it there, since this doesn't fail into my definition 
> of nemo multihoming. anyway...

The impact of case (ii) are mostly concerned with a general multihomed
mobile node.  Since the operation of NEMO Basic Support is largely based
on Mobile IPv6, concerns of multihomed mobile node would impact a mobile
router as well.  So, for completeness, we feel it is necessary to voice
it out.  Later in the issues section, we should have pointed that
concerns for the case (ii) are not NEMO-Specific, and recommends that
NEMO to be compatible with whatever solutions other WG comes up with.

> 
> 
> Section 4.3 Ingress Filtering states that:
> 
>        A simple solution is to require all
>        MNNs to set their default router to the MR that advertises the MNP
>        the MNNs configured their addresses from.
> 
> Now this is not simple as it seems.
> What if you have the following configuration
> 
> 
>     +----+           +-----+
>     | MR1|           | MR2 |
>     +----+           +-----+
>       |                 |
>     -----------------------
>               |
>             +----+
>             | R  |
>             +----+
>               |
>      -----------------
>           LAN2
> 
> What is R supposed to advertise in LAN? I guess that in order to apply 
> this approach in this configuration you will need to add an additional 
> router in LAN2 so that you have two routers so that each one can 
> advertise a different prefix (this basically means that you will need 
> to build as many paralel netwroks as you have prefixes (this is not 
> what i would call simple)
> I guess that simply adding that in some configurations like the one i 
> depicted above this mechanism is not good would be enough

Hmm, let's explore this a bit further.  Router R is also an MNN on the
NEMO, yes?  So it should follow the same rule.  Now R can advertise both
prefixes, but it must add a route to its routing table so that all
packets with source prefix P1 is routed to MR1, and all packet with
source prefix P2 is routed to MR2 (assuming MR1 advertises P1 and MR2
advertises P2).

Would this work?

> Next, in the same section it is stated that:
> 
>      For a possible approach, see [12].
> 
> I haven't read the latest version of this draft, but i don't know how 
> this draft can help here, i mean the problem here is a problem with 
> source address selection not with destiantion. I mean you need a 
> mechanism to convey the hosts the following information: for a source 
> address with prefix P1, you must use a give router for forwarding. Last 
> version i read of 12, it stated that: for a destination address the use 
> router X, which is different and not what is needed. am i missing 
> something? besides, the previous comment still holds here. i.e. the 
> configuration depicted above is not trivially supported.
> 
> Then, it is stated that:
> 
>        If the tunnel to HA1 is broken, packets would be sent through the
>        tunnel to HA1 are diverted through the tunnel to HA2.
> 
> Well, i guess this is not only a problem with ingress filtering but 
> also about fault tolerance. I mean, even if there were no ingress 
> filtering in place, the reply packets addressed to the address that 
> contains the prefix corresponding to the HA that is down wouldn't reach 
> the nemo, becuase of the failure. with ingress filtering neither 
> forward packet will flow, i agree, but the main issue is related with 
> the failure not with the ingress filtering imho
> 
> Then i suggest a minor change of wording where it is stated that:
> 
>        If HA2 (or
>        some border gateway in the domain of HA2) performs ingress
>        filtering, packets with source address configured from MNP P1 may
>        be discarded.
> 
> s/may/will
>   i mean if there is ingress filtering in place, then the packet will be 
> discarded for sure :-)

agree :).

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

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

> Next you have a typo in
> 
> For those failures that can't be
>     receovered (such a failure of the access router), a heartbeadt
>                                                                 ^

thanks, it is corrected in version -02.

> Now, i am not sure that sections 4.7  MR Synchronization and 4.8  
> Prefix Delegation are really needed.
> I mean the issues presented in this section are:
> 
>     For doing so, the issues discussed below must be addressed,
>     preferably dynamically.
> 
> I am not sure that MR sync and Prefix delegation MUST be addressed, 
> imho this depends on the solution you are considering. I can easily 
> think a host based solution that doesn't requires MR sync.
> 
> In section 4.10  Source Address Selection i think that a big issue is 
> missing w.r.t. fault tolerance. I mean, in the case that the source 
> address is linked to a given HA, then the source address selection will 
> impact the fault tolerance capabilities, since if the source address 
> corresponding to the HA that is down is picked, the return packets 
> won't make it. So you need to use the source address selection 
> mechanism to obtain fault tolerance. all this consideration is missing 
> here, and imho it is very important.
> for additional considerations on this, please refer to 
> draft-huitema-multi6-addr-selection-00.txt

Thanks, we will read the draft and add appropriate considerations wrt to
source address selection.
> 
> section 4.11  Impact on the Routing Infrastructure
> i simply suggest to remove it. I mean, i don't think that multiple 
> routes to a nemo will be announced in the DFZ. If this is the case, 
> multi6 has failed, and for now, we are a bit more optimistic :-)

OK, unless there is any strong objection against removing this issue.

> Finally, separate the references in normative informative

Hmmm...  is that necessary?  I mean, the draft itself is an
informational document.

Once again, I apologize for missing this mail last November.  Rest
assure we would addressed the concerns you have in the -03 version.

/rgds
/cwng

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 24 Feb 2005 11:42:24 +0100

Hi,

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 26 Feb 2005 21:28:57 +0100

Hi Chan-Wah,

> NEMO to be compatible with whatever solutions other WG comes up with.

ok

> source prefix P2 is routed to MR2 (assuming MR1 advertises P1 and MR2

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

> best approach for us is to provide more extensive reference to all the

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.

I think that you have try to do this in the new version of the draft, i 
will comment on that on another message.

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

> Hmmm...  is that necessary?  I mean, the draft itself is an

I think so, but i guess the chairs can tell us about this.

> assure we would addressed the concerns you have in the -03 version.

no problem, thanks for the draft.
I will try to comment on the v3 soon.

Regards, marcelo

---

From: Chan-Wah Ng <[email-masked]>
Date: Tue, 01 Mar 2005 10:39:55 +0800

Hello Marcelo,

> Hi Chan-Wah,
-- 8< consensus portions snipped >8 --

> approaches that you can use for dealing with ingress filtering in 

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.

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

-- 8< consensus portions snipped >8 --

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

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

> I think so, but i guess the chairs can tell us about this.

Would the chairs care to comment?

/rgds
/cwng