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

From: [email-masked]
Date: Wed, 20 Jul 2005 15:50:02 -0400

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-03.txt
	Pages		: 41
	Date		: 2005-7-20
	
This document is an analysis of multihoming in the context of network
   mobility (NEMO) in IPv6.  As there are many situations in which
   mobile networks may be multihomed, a taxonomy is proposed to classify
   the possible configurations.  The possible deployment scenarios of
   multihomed mobile networks are described together with the associated
   issues when network mobility is supported by RFC 3963 (NEMO Basic
   Support).  Issues are classified according to the Working Group which
   is the best chartered to solve them.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-03.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-03.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-03.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: Masayuki Kumazawa <[email-masked]>
Date: Thu, 21 Jul 2005 11:44:11 +0900

Hello authors,

I have a question about the multihoming analysis draft -03.

>4.10  Prefix Ownership

>   When a (n,*,1) network splits, (i.e. the two MRs split 
>   themselves up), MRs on distinct links may try to register the only 
>   available MNP. 

I think it may also happen in (n,*,n).

In the case MR1 configured with MNP1 and MR2 with MNP2 are merged 
into one mobile network, MR1 and MR2 may be configured with both MNP1 
and MNP2.
The configuration will provide benefits of multihoming.

But when the mobile network splits, or MR1 and MR2 are 
disconnected, each MR must be re-configured only with its own 
prefix.

Does the situation make sense?

Best regards,
Masayuki

<[email-masked]> From [email-masked]
>implementation to automatically retrieve the ASCII version of the
-----------
M.Kumazawa

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 21 Jul 2005 13:37:51 +0800

> Does the situation make sense?

Possibly.  But the question is now what possible benefits can {MR1 and
MR2 both be configured with MNP1 and MNP2} brings.  From the point of
view of a MNN, it sees two different prefixes: MNP1 and MNP2, with two
default routers.  There is no significant differences for the MNN
whether both the default routers announced the same prefixes.

We are not talking about fault recovery here (where MR1 or MR2 fails).
If a router (say MR1) fail, then a router re-numbering would almost
certainly be necessary so that MNP1 can still be used.  This means that
HA must have a way of monitoring whether MR1 has failed, and re-delegate
MNP1+MNP2 to MR2.  But all these issues have nothing to do with the
specific problem of "split network", they are covered elsewhere.

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 21 Jul 2005 13:49:16 +0800

Hello all,

Just wish to give some updates on the draft.

We enlisted Marcelo Bagnulo, who have been giving us valuable comments,
as a co-author for the draft.  With his help, we re-structured Section 4
quite a bit.  So those who'd read previous version of the draft would
definitely want to re-read Sect 4 to catch up to date.

Other minor changes include: 
- the addition of Section 5, where we tabularize the multihoming issues
presented in Sect 4 against each of the 8 configurations.
- breaking the references into normative and informative
- minor changes throughout the draft in an attempt to close some of the
ML issues.

For an update to the ML issues, please see:
http://www.mobilenetworks.org/nemo/draft-ietf-nemo-multihoming-issues/
To date, we have a total of 22 ML issues, 4 open, 18 closed.

/rgds
/cwng

On Wed, 2005-07-20 at 15:50 -0400, [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-03.txt

---

From: Masayuki Kumazawa <[email-masked]>
Date: Thu, 21 Jul 2005 16:44:22 +0900

Hello Chan-Wah,

<[email-masked]> From Chan-Wah Ng-san

>whether both the default routers announced the same prefixes.

I don't think it meaningful to configure each MR with a different MNP 
in a mobile network with multiple fixed MRs either.

However, "split network" assumes portable MRs.
So "merged network" will happen as well as "split network".

At first MR1 and MR2 forms different networks with different MNPs, 
or MNP1 and MNP2.
MNN1 is currently connected to MR1 and configured with an address 
of MNP1.

After MR1 and MR2 are merged, MNN1 can use MR2 as an alternative 
default router.

When they split, MNN1 can't use MR2 but can keep using MR1 with 
the address with MNP1. 

3.  Usage scenarios of the following draft explains possible 
scenarios.
http://www.ietf.org/internet-drafts/draft-kumazawa-nemo-tbdnd-02.txt

>specific problem of "split network", they are covered elsewhere.

I'm sorry but I can't understand why you refer to fault recovery.
Do you mean that multiple MNPs in a mobile network enables fault 
recovery?

Best regards,
Masayuki

<[email-masked]> From Chan-Wah Ng-san
-----------
M.Kumazawa

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 21 Jul 2005 16:18:23 +0800

Hello Kumazawa-san,

> in a mobile network with multiple fixed MRs either.
Good, we are in agreement (so far) then.

> After MR1 and MR2 are merged, MNN1 can use MR2 as an alternative 

Now, this is the problem.  If MR2 did not register MNP1, how can it be
the default router?  HA will discard the packet forwarded by MR2.
So, you are proposing that they use tbdnd to allow MR2 to register for
that MNP too.

As far as I see, there are a few possible solutions:

(a) Use tbdnd, thus allowing MR2 to tunnel src=MNP1.MNN1

(b) MR2 to simply ICMP redirect packets with src=MNP1::MNN1 back to MR1 

(c) MNN1 to be Shim6-enabled: use src=MNP2:MNN1 when it want to use MR2
as the exit router, use src=MNP1:MNN1 when it want to use MR1 as exit
router.

> When they split, MNN1 can't use MR2 but can keep using MR1 with 

Now I understand what your original mail is trying to say. Sorry, my
mistake, I mis-interpreted your mail.  I initially thought you were
trying to say that "there is a problem when they split".

But, now, I think you are trying to say "there is a problem when they
merge". :) Right?

> Do you mean that multiple MNPs in a mobile network enables fault 

Ah, nevermind.  I was thinking of why would anyone want to re-configure
MR1, MR2 to advertise both MNP1 and MNP2, so the only reason I could
think of is fault tolerance, or for fault recovery.

/rgds
/cwng

---

From: Romain KUNTZ <[email-masked]>
Date: Thu, 21 Jul 2005 17:22:48 +0900

Hello,

I have few comments about this draft on section 4.2  (Ingress 
Filtering). You say:
>  If a packet with a source address configured from a
>  specific MNP is tunnelled to a home agent that does not handle that
>  specific MNP the packet may be discarded either by the home agent or
>  by a border gateway in the home network.

If the implementation is complying with RFC3963, IMHO it's even sure 
that such packet will be discarded by the HA. cf section 9 of RFC3963:

The Home Agent has to verify that packets received through the bi-
directional tunnel belong to the Mobile Network [...] The source address
of the inner IPv6 header MUST be topologically correct with respect
to the IPv6 prefixes used in the Mobile Network.

>   o  For the (*,1,n) cases, there is not such a problem since there is
>       a single HA, accepting all the MNPs.

The problem will not occur on HA, but what about on the MR in case you 
have multiple MRs ? Maybe one MR is configured to drop packets whose 
source addresses are built from a prefix that is not advertised by the 
MR. You suggest it for the (n,n,n) case few lines after:

> o  If the two tunnels are available, MNN cannot forward packet with
>       source address equals P1.MNN to MR2.  This would cause ingress
>       filtering at HA2 to occur (or even at MR2). 

Regards,

-- 
Romain KUNTZ
[email-masked]

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 21 Jul 2005 17:03:23 +0800

Hello Romain,

> to the IPv6 prefixes used in the Mobile Network.

Correct.  The sentence "... the packet may be discarded ... ", the word
"may" should be "will".

> >       filtering at HA2 to occur (or even at MR2). 

True.  I would propose rewriting the original bullet: 

   o  (*,n,n) are the cases where the ingress filtering presents some
      difficulties.  In the (1,n,n) case the problem is simplified
      because all the traffic from and to the NEMO is routed through a
      single MR.  Such configuration allows the MR to properly route
      packets respecting the constraints imposed by ingress filtering.
      The more complex case is the (n,n,n) case.  A simplified case
      occurs when all the prefixes are accepted by all the HAs, so that
      no problems occur with the ingress filtering.  However, this
      cannot be always assumed, resulting in the problem described
      below.

to 

   o  For the (1,1,n) cases, there is not such a problem since there 
      is a single MR and a single HA, accepting all the MNPs.  

   o  For the (n,*,n) cases, if all the MRs registers all the MNPs,
      there is not such a problem, since there 
      is all the HAs are accepting all the MNPs.  

   o  The remaining cases is where ingress filtering presents some
      difficulties.  In the (1,n,n) case the problem is simplified
      because all the traffic from and to the NEMO is routed through a
      single MR.  Such configuration allows the MR to properly route
      packets respecting the constraints imposed by ingress filtering.
      The more complex case is the (n,*,n) case where not all the MRs
      registers all the MNPs, which results in the problem described
      below.

What do you think?

/rgds
/cwng

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Jul 2005 12:16:09 +0200

Hi Romain,

thanks for the comments, see my reply below...

> MR. You suggest it for the (n,n,n) case few lines after:

Why would you wanted to do this?
I mean, if there only one HA, then the HA will be accepting all the 
MNP, so why would you configure the MR to discard some of the MNPs?

Regards, marcelo

---

From: Romain KUNTZ <[email-masked]>
Date: Thu, 21 Jul 2005 19:21:04 +0900

Hello Chan-Wah

>       is a single MR and a single HA, accepting all the MNPs.  

Ok

>       is all the HAs are accepting all the MNPs.  

My concern here is how all HA can register all MNPs? As you say
in the original text, this cannot be always assumed.
We can end up with the same issues as described in 4.4
(HA Synchronization) and 4.10 (Prefix Ownership).

>       registers all the MNPs, which results in the problem described

I would rather classify like this:

    o  For the (1,1,n) case, there is not such a problem since there
        is a single MR and a single HA, accepting all the MNPs.

    o  For the (1,n,n) cases, there is not such a problem because all the
        traffic from and to the NEMO is routed through a single MR.
        Such configuration allows the MR to properly route packets
        respecting the constraints imposed by ingress filtering.

    o  (n,*,n) are the cases where the ingress filtering can occur on MRs
        and HAs. If all the prefixes were accepted by all the HAs, no 
problems
        would occur with the ingress filtering.  However, this cannot be
        always assumed, resulting in the problem described below.

What do you think?

Romain

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Jul 2005 12:30:35 +0200

El 21/07/2005, a las 12:21, Romain KUNTZ escribió:

> Hello Chan-Wah
>
> Chan-Wah Ng wrote:
>> True.  I would propose rewriting the original bullet:    o  For the 
>> (*,1,n) cases, there is not such a problem since there is
>> to    o  For the (1,1,n) cases, there is not such a problem since 
>> there       is a single MR and a single HA, accepting all the MNPs.
>
> Ok
>
>>       there is not such a problem, since there       is all the HAs 
>> are accepting all the MNPs.
>

As i mentioned, i fail to see why in the case where there is only one 
HA, the MR would filter any MNP, could you explain the rationale for 
this configuration?

Regards, marcelo

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 21 Jul 2005 19:37:45 +0900

> >>   o  For the (*,1,n) cases, there is not such a problem since there
> >is>       a single HA, accepting all the MNPs.
> >
> > The problem will not occur on HA, but what about on the MR in case
> > you have multiple MRs ? Maybe one MR is configured to drop packets
> > whose source addresses are built from a prefix that is not
> > advertised by the MR. You suggest it for the (n,n,n) case few lines
> > after:
> >
> 

I would see things the other way round: wouldn't the MR need some sort
of way to synchronize so that MNPs are not discarded ?

Thierry

---

From: Romain KUNTZ <[email-masked]>
Date: Thu, 21 Jul 2005 19:43:12 +0900

Hello Marcelo,

> HA, the MR would filter any MNP, could you explain the rationale for 

For example, imagine that two (1,1,1) mobile networks (whose MR have the 
same HA, but advertise different prefixes) merge in one mobile network, 
forming a (2,1,2) NEMO. Before merging, each MR might have some 
filtering policies on its interface. Once merged, the policy would still 
apply if the MR do not synchronize.
Do you think this scenario is not rational?

Regards,

Romain

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Jul 2005 13:15:00 +0200

El 21/07/2005, a las 12:43, Romain KUNTZ escribió:

> For example, imagine that two (1,1,1) mobile networks (whose MR have 
> the same HA, but advertise different prefixes) merge in one mobile 
> network, forming a (2,1,2) NEMO. Before merging, each MR might have 
> some filtering policies on its interface. Once merged, the policy 
> would still apply if the MR do not synchronize.

yep, good enough for me

my question now is if we are considering the merging scenario like this 
in the analysis...
I mean, i guess that there is quite a difference in terms of complexity 
if we are cosnidering some form of static nemos than when considering 
this form of dynamic nemos that merge and split...

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Jul 2005 13:17:53 +0200

> of way to synchronize so that MNPs are not discarded ?

well, i guess it depends on the scenario being considered. I mean, if 
you are considering some static scenario, like a nemo in a train or 
plane, then, i guess that MNP are manually configured or through dhcp 
and the situation is pretty stable, so i would say that we don't need 
that.

OTOH, if we are dealing with the scenario the Romain mentions of 
merging and spliting with a relatively high frequency, then we may need 
this. But i guess that in this environment we may need a more in depth 
analysis in order to see if there are additional stuff needed, since 
the constraints may greatly differ

regards, marcelo

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 21 Jul 2005 20:24:48 +0900

> > I would see things the other way round: wouldn't the MR need some
> > sort of way to synchronize so that MNPs are not discarded ?
> >
> 
> merging and spliting with a relatively high frequency, then we may
> need this. But i guess that in this environment we may need a more in
> depth analysis in order to see if there are additional stuff needed,
> since the constraints may greatly differ

Actually, the NEMO WG is still supposed to decide which of the
scenarios are reasonable to support vs optional. Deciding on this would
drive the issues on which we need to work on.

So far, the analysis document is just here to list the issues, not to
solve them.

Thierry