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

From: [email-masked]
Date: Thu, 27 Oct 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)	: C. Ng, et al.
	Filename	: draft-ietf-nemo-multihoming-issues-04.txt
	Pages		: 44
	Date		: 2005-10-27
	
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-04.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-04.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-04.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: Romain KUNTZ <[email-masked]>
Date: Fri, 28 Oct 2005 17:26:39 +0900

Dear authors,

I have few comments relative to this draft.

> 4.2. Ingress Filtering

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

When you have multiple MR, ingress filtering can happen sooner than at
the HA: at the MR. You say it a bit later, in the example:

> This would cause ingress filtering at HA2 to occur (or even at MR2).

You also say:
> 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

draft-montavont-monami6-multihoming-pb-statement-05 has a section
speaking about ingress filtering (6.1.2) from the node point of view.
Adding a reference could be useful, as it seems more tricky than stated
in the draft.

> 4.3. HA Synchronization
[...]
> In the (*,n,*) mobile networks, a single MNP would be registered at
> different HAs.

Do you mean (*,n,1)?

BTW, the draft-tsukada-nemo-mr-cooperation-analysis-00 tries to list
some requirements that should be taken into account when designing a
MR-cooperation solution. We tried to take into account the issues
described in the multihoming-issue draft.

Regards,

-- 
Romain KUNTZ
[email-masked]

---

From: Chan-Wah Ng <[email-masked]>
Date: Fri, 28 Oct 2005 16:59:47 +0800

Hello, Romain,

> > This would cause ingress filtering at HA2 to occur (or even at MR2).

Okay, so the sentence should be changed to:
"For (1,1,*) and (n,1,n) cases ..."

We then need to address (n,1,n) separately, or perhaps group this case
into (n,n,n).  I need to review the text a bit to address this, get back
to you once I have a satisfactory resolution ready.

> Adding a reference could be useful, as it seems more tricky than stated

No dispute there (considering I wrote the text on both drafts ;)).  Will
do that.

> > In the (*,n,*) mobile networks, a single MNP would be registered at

Right, thanks for catching that.

> described in the multihoming-issue draft.

Indeed, I saw the draft announcement, but have no time to read it before
submitting -04, and I don't want to simply reference a draft I have not
yet read.

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: Mon, 31 Oct 2005 14:19:07 +0800

> Adding a reference could be useful, as it seems more tricky than stated

Hello Romain, 

See if the following modified text suits you:

   o  For the (*,*,1) cases, there is not such an issue, since there is
      a single MNP.

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

   o  For the (n,1,n) case, though ingress filtering would not occur at
      the HA, it may occur at the MRs, when each MR is handling
      different MNPs.

   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.
      In this case, the single MR may face ingress filtering problems
      that a multihomed mobile node may face, as documented in [7].

      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.

/rgds
/cwng

---

From: Romain KUNTZ <[email-masked]>
Date: Tue, 01 Nov 2005 00:40:21 +0900

Hello Chan-Wah,

>       since there is a single HA, accepting all the MNPs.

I believe (n,1,1) is included in the first statement, and (1,1,1) is 
trivial, so you can just say (1,1,n). It's more coherent IMHO, as you 
speak about "all the MNPs".

>       cannot be always assumed, resulting in the problem described

Otherwise it looks good to me.

thanks,

-- 
Romain KUNTZ
[email-masked]