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

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 20 Jul 2004 12:22:32 +0200

Hi,

Some comments about this draft...

- General comment: Is this draft about IPv4 or IPv6 or both? I mean, i  
think that there are lots of IPv6 specific points, but there are also  
some IPv4 considerations (or at least that how i understand it, for  
instance the case of reference [9] perhaps?). Perhaps explicitly  
stating in the introduction the IP protocol version considered could be  
helpful

- Section 2.

I am not sure how valuable is to include the discussion about whether  
the MNNs are multihomed or not. I mean, this is basically a study on  
the mobile network, i don't think that host multihoming issues are  
interesting. Moreover, i don't agree that a node with multiple  
addresses can be called a multihomed node, imho this is a node within a  
multihomed network in many cases.

What does "companion document" means? (same question for the document  
referred in section 3) Should these docs be considered part of this  
spec?

- Section 2.3  (1,n,1): Single MR, Multiple HAs, Single NEMO-Prefix

    The (1,n,1) mobile network has only one MR advertising a single
    NEMO-prefix.  The MR, however, is associated to multiple HAs,
    possibly one HA per Home Address, or one HA per egress interface.  No
    assumption is made on whether or not the HAs belongs to the same
    administrative domain  (it may be justified to locate HAs in distinct
    ISPs according to [Section 5.1.2. Possibly Multihomed, An Identical
    Prefix from a Different Origin] [9])

I don't understand the case where there is a single prefix and multiple  
HAs placed in different administrative domains. I mean, if the HAs are  
in different administrative domains, they will have different prefixes,  
so there will be multiple nemo-prefixes in the nemo. The case  
considered in reference [9] is about the same prefix that it is  
announced with different ASN as origin. This can be AFAIU, because the  
announcing site don't have its own ASN, so the prefix is announced with  
the provider's ASN, but i don't think that this case is related to the  
topic here considered.

Bottom line is that i don't see that the case where there is a single  
nemo prefix with multiple HAs in different administrative domains makes  
much sense. I would suggest to remove The last sentence (starting from  
"No assumption....) . I  am not suggesting to ban the scenario neither,  
just don't explicitly mention it.

- Section 2.6  (n,1,n): Multiple MRs, Single HA, Multiple NEMO-Prefixes

    The (n,1,n) mobile network has more than one MR advertising different
    global routes and different NEMO-prefixes.

Why do the MRs have to announce _different_ global routes and  
_different_ prefixes?
I mean wouldn't be possible that all the MRs announce the same global  
routes (like a default route, for instance) and the same prefixes

- Section 2.7 (n,n,1): Multiple MRs, Multiple HAs, Single NEMO-Prefix

    The (n,n,1) mobile network has more than one MR advertising different
    global routes.

Same comment than above.

    The mobile network is associated with multiple HAs at
    any one time.  No assumptions are made on whether or not the HAs
    belongs to the same administrative domain.  However, the MRs
    advertises the same NEMO-prefix.

Same comment than Section 2.3.

- Section 2.8  (n,n,n): Multiple MRs, Multiple HAs, Multiple  
NEMO-Prefixes

    The (n,n,n) mobile network has multiple MRs advertising different
    global routes and different NEMO-prefixes.

Same comment than in Section 2.6.

- Section 3

Perhaps it would be worthy to include a brief description of the goals  
and benefits of multihoming, in order to make the document self  
contained.
I don't understand the difference between Load sharing and load  
balancing in the case of a nemo.
Perhaps it would be worthy to include a reference to RFC 3582 	
- Section 3.1

Case x=1

I would say that this scenario also achieves other goals, such as load  
sharing, load balancing, and preference setting, since the MR can  
receive load through the different media simultaneously and it can  
choose which traffic to route through each media based on preferences

Case x=N

The train example: why this case doesn't provides ubiquity support? i  
mean, it is stated that different ISPs can be used...
Moreover, if load sharing is provided, why preference settings are not  
supported? i mean,. if multiple access are simultaneously available,  
the MR can choose to use one link or the other to route traffic based  
on preferences, right?

The PAN example. Again, why preference setting is not one of the  
achieved benefits in this scenario? The PAN can choose to send some  
traffic through GPRS and other through WLAN (which it would make a lot  
of sense imho). Same for load sharing or load balancing

The same comments about additional benefits also apply to some of the  
remaining examples

- Section 3.2 Prerequisites

Preference settings.

I would add that multiple tunnels must be maintained simultaneously in  
this section too.

       A mechanism must be provided to the user or the application to
       decide which of the available bi-directional tunnel should be
       used.

Well, the preferences can also be set in the MR or the routing system   
(as in current IPv4 multihoming), or even in the MNN (using RFC 3484  
policy table for instance).

- Section 4.1 Path survival

Only the case (0,0,0) is analyzed and a solution is referenced, why is  
so? are the other cases less interesting or is simply the lack of  
proposals for other scenarios? imho, there are other relevant  
scenarios, and i would considered all the relevant scenarios or none of  
them at all.

- section 4.3 Ingress filtering

The scenario considered in this section makes several assumptions that  
i would challenge in the general case:
- It assumes that there are several MR (there may be problems with  
ingress filtering even in a scenario with a single MR, if the MR does  
not considers the source address when forwarding packets)
- It assumes that each MR announces a single prefix (which imho it may  
not be so)
- It assumes that each MR has a single tunnel and each MR has a tunnel  
with a different HA (imho, a general approach to multihoming should    
consider the case where each MR has multiple tunnels and that multiple  
MR have tunnels with the same HA)
- It assumes that the NEMO is composed of a single link, since it  
assumes that all the routers within the nemo announce a single prefix.  
I mean what happens in the scenario where a MNN is a router? would this  
router announce a single prefix too? this would imply that alll the  
node below this router only see a single prefix, so they don't really  
benefit from multihoming.

Are those assumptions being assumed and if so why this is so? wouldn't  
make sense to consider a more general scenario?

I am not sure that i understand why reference [12] is a useful approach  
to deal with the issue presented in this section, could you expand on  
this?

Later on it is stated that:

    o  Switching addresses is time consuming since nodes have to wait for
       addresses to get deprecated [13].

Well, i guess you can announce a prefix with lifetime set to 0, so you  
don't have to wait until its lifetime expires, right?

- Section 4.4 Failure Detection

imho i think there is a topic related with this section that is  
missing, which is the ubiquity support and media availability  
detection. I mean, one of the reasons for nemo multihoming is ubiquity  
support, so it is likely that available media will change over time. A  
mechanism to detect available media is required. This would be similar  
to a failure detection mechanism perhaps?

This section only considers the case of failures in the first link,  
shouldn't it also be considered other failure modes?

- Section 4.10   Impact on the Routing Infrastructure

    In the (1,n,1) case with HAs located in distinct ISPs/ASs, multiple
    routes directed to the mobile network may be advertised in the
    Internet.

this is possible in IPv4 today, but it is not really acceptable in  
IPv6, (that is what multi6 is trying to avoid, at least for end sites)
Moreover, this is generally possible for the same site (for instance an  
ISP with multiple connection) but i don't see how this would work for  
different ISP announcing the same prefix, this seems more like  
anycasting

    This may provide shorter paths, but this would add a
    burden in routing tables as the route would be published in the
    Internet Router Registry for multiple ASs.

What is the Internet Router Registry?

- Appendix A.1

s/Eric Nordmark/Erik Nordmark

- Appendix B.1

It is stated that:

    In the case where multiple MRs are on the mobile network, each MR has
    to detect the presence of other MR.  A MR can do so by listening for
    Router Advertisement message on its *ingress* interfaces.

In can see that this covers the case where both MR are on the same  
link. However, what if the MRs are in different links, would this be  
enough or   using routing protocols is needed?

- Appendix B.2

It is stated that:

    When a MR detects that the link be which its current bi-directional
    tunnel with its HA is using is down,

i think this needs some rephrasing

- Appendix B.2.2

AFAIU, in this section is being assumed that each MR has a different  
nemo-prefix assigned, is this correct?
I mean, what happens if there is s single nemo prefix?
What happens if there are multiple nemo prefixes but all the MR  
announce all of them?
How does the MR creates a CoA of the "other" MR in this case?

El 14/07/2004, a las 4:28, Thierry Ernst escribió:

>
> Dear all,
>
> I think this problem statement for multihoming in NEMO would interest
> some of you. This is now a NEMO WG document, so we will most likely
> discuss the document during our NEMO WG meeting, on Monday August 2nd.
>
> I guess the NEMO WG would appreciate if some of you could join the
> discussion, so that we make sure there is a good interaction between
> both WGs.
>
>
> Thierry.
>
> --  
> Thierry Ernst, PhD
> WIDE at Keio University, Japan
> IETF NEMO WG co-chair  
> http://www.ietf.org/html.charters/nemo-charter.html
> WIDE NAUTILUS WG co-chair http://www.nautilus6.org
>
>
> De: [email-masked]
> Fecha: 13 de julio de 2004 22:03:49 GMT+02:00
> Para: [email-masked]
> Cc: [email-masked]
> Asunto: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-00.txt
>
>
> 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-00.txt
> 	Pages		: 33
> 	Date		: 2004-7-13
> 	
> 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-00.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-00.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-00.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.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
>
>

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 20 Jul 2004 21:10:48 +0900

Thanks to your comments Marcelo.

> stating in the introduction the IP protocol version considered could be  

Sure, we will fix this.

> multihomed network in many cases.

This is a good point, but if we want to benefit from multihoming, we
(not necessarily the NEMO WG) will need to consider some issues that
impact on MNNs. So, the purpose of draft-ietf-nemo-multihoming is to
list all such issues. After that, we will have to decide what issues
should be solved, then which ones should be addressed by the NEMO WG,
and how to solve the other issues within the IETF community.

> referred in section 3) Should these docs be considered part of this  

Arrrh, there is a typo here:

The text says "companion document [7]" as below:

   [6]   Ernst, T., "Goals and Benefits of Multihoming",
         draft-multihoming-generic-goals-and-benefits-00 (work in
         progress), February 2004.
 
An update of this draft should show off soon. You can get the update from:
http://www.nautilus6.org/doc/drafts/draft-multihoming-generic-goals-and-benefits-01.txt

   [7]   Montavont, N., Wakikawa, R. and T. Ernst, "Analysis of
         Multihoming in Mobile IPv6",
         draft-montavont-mobileip-multihoming-pb-statement-01 (work in
         progress), Feb 2004.

An update of this draft should show off soon. You can get the update from:
http://www.nautilus6.org/doc/drafts/draft-montavont-mobileip-multihoming-pb-statement-01.txt

> the provider's ASN, but i don't think that this case is related to the  

OK, we might need to look at this case and ref [9] a bit closer. 

> just don't explicitly mention it.

We thought that mentioning the scenario would have helped to avoid a
discussion on this ;-)

> routes (like a default route, for instance) and the same prefixes

Of course that is possible, so that would be case (n,1,1). Here, we just
list the case in order to list the issues (the issues are discussed
later); after that we will have to decide what are good practices and
what aren't.

> Perhaps it would be worthy to include a reference to RFC 3582 	

Ref [6]-01 does this, so we just refer to ref [6] right now. We will have
to decide the future of ref [6], though. If [6] is published, there is
no reason to put in more text in draft-ietf-nemo-multihoming IMHO.

RFC 3582 is referenced from [6]-01, [6] will need to be improved to
catch the differences or using the same definition.

> The same comments about additional benefits also apply to some of the  

OK, we didn't cite some benefits, it doesn't mean it's not possible. I
agree we need to improve this.

> policy table for instance).

OK to all the above.

> scenarios, and i would considered all the relevant scenarios or none of  

OK. That may be too many scenarios to list, though ?
 
> make sense to consider a more general scenario?

It's not assumed. If the reader thinks so, we should change the text to
reflect that this is an instance case, used for commodity, in order to
explain the issue. 

Any suggestion to improve the text ?
- listing ALL the cases that lead to the issue
- listing SOME of the cases that lead to the issue
- listing NO case
- have a table at the end summarizing which issue happens in which case

> to deal with the issue presented in this section, could you expand on  

We will take a look on this.

> don't have to wait until its lifetime expires, right?

Right, that's a way to solve the issue, isn't it ? The point is that if
you don't set the lifetime appropriately, it would happen. We should be
clearer on this.
 
> to a failure detection mechanism perhaps?

May be our section "Failure detection" could be split in two, etc. We will take a look at it.

> shouldn't it also be considered other failure modes?

Probably, yes.

> different ISP announcing the same prefix, this seems more like  

Basically, the reasons why we pointed out to multi6 is clearly a way to
say that more investigation is needed on this issue, and that there is a
work in progress in that WG. We will definitely put in more text here,
following the progress of Multi6.

> What is the Internet Router Registry?

Ah, don't know myself ;-)
 
> How does the MR creates a CoA of the "other" MR in this case?

I guess we will need a careful look on the appendix.

Thanks again for all your valuable comments.

Thierry.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 20 Jul 2004 15:29:58 +0200

[...]

> later); after that we will have to decide what are good practices and

Ok, so i would suggest to remove the "different" from "different global 
routes" and from "different NEMO-prefixes" so that the more general 
case is presented, agree?

>> Same comment than in Section 2.6.

[...[
> OK. That may be too many scenarios to list, though ?

Perhaps moving the solutions to the appendix would make the document 
more clear?

> - have a table at the end summarizing which issue happens in which case

Well, i guess that there may be problems with ingress filtering as long 
as there are multiple NEMO prefixes available so i would add the 
multiprefix concern in the initial sentence i guess.

I agree that an example is useful to understand the issue, but perhaps 
adding a bit of general description of the problem before going to the 
example could provide a broader view. Perhaps mentioning that there are 
other relevant scenarios where could be issues would also help.

[...]

> I guess we will need a careful look on the appendix.

I think that the approach presented in this appendix is very 
interesting. However i wonder if this should be placed in an appendix 
of a analysis document. I would say that this should be moved to a 
separate document covering the nemo multihoming support approach and 
that this document should study in detail the proposed approach in all 
the relevant scenarios in order to verity that it provides the desired 
capabilities.

Regards, marcelo

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 21 Jul 2004 11:38:00 +0800

Hello Marcelo,

Thank you for your very valuable comments.  See responses inline.

/rgds
/cwng

> case is presented, agree?

Hmm, how about: "different" -> "multiple"?  Agree that MRs need not
necessarily announce different prefixes.

> other relevant scenarios where could be issues would also help.

Point noted.  I need to ponder a bit more on the various assumptions you
listed, especially the part on MNN = router.  

> the relevant scenarios in order to verity that it provides the desired 

This solution has always been with the draft since its initial
incarnation (i.e. draft-ng-nemo-multihoming-issues-00.txt).  I agree
that having it in a separate document is the more desirable approach.

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 21 Jul 2004 20:53:29 +0800

Hello marcelo,

some responses to your comment on Appendix B.

> enough or   using routing protocols is needed?

When two MRs are on different links, this implies there must be a third
router within the NEMO, right?

Anycase, this is a bit complicated, as you now thread into nested
NEMO.   More serious thought need to into it, but I suspect we might end
up re-inventing MANET if one goes deeper into such cases.  Suffice to
say that the mechanism in Appendix B would not work if only one MR is
advertising a global route on any link of the NEMO.

> i think this needs some rephrasing

Yep, like "be"->"by"

> nemo-prefix assigned, is this correct?

Not really.  No assumption is made on the number of prefixes.

> How does the MR creates a CoA of the "other" MR in this case?

In the case where the other MR advertises all the prefixes it owns,
there is no need to do recovery, since an alternate route exits for all
the prefixes anyway (through the other MR).  The MR can simply set
Lifetime=0 and forces all MNNs to use the other router as their default
router.  No harm done.

In the case where at least one prefix was not advertised by the other
MR, it will autoconfigures an address based on the prefix advertised by
the alternate MR, and use it as the CoA.  The BU it sent will only
register the prefix that was not advertised by the other MR.

Any problem here?

/rgds
/cwng

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 21 Jul 2004 15:34:12 +0200

Hi Chan-Wah,

> necessarily announce different prefixes.

In this case the resulting text would be:

     The (n,1,n) mobile network has more than one MR advertising
     multiple global routes and multiple NEMO-prefixes.

I wonder if this cannot be interpreted as if each one of the MR is 
advertising more than one prefix, precluding the case where each MR 
advertises a single prefix (each MR advertising a different prefix)
I don't want to get into excesive detail with this, but perhaps 
something like the text below can be general enough:

     The (n,1,n) mobile network has more than one MR and
     multiple global routes and multiple NEMO-prefixes are advertised.

[...]

> that having it in a separate document is the more desirable approach.

Well as i mentioned, i guess that this approach deserves to be fully 
developed, and all the relevant senarios need to be considered, and 
imho an appendix is not the place to include all this detailed 
information.

Regards, marcelo

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 21 Jul 2004 22:20:39 +0800

Hello Marcelo,

On Wed, 2004-07-21 at 21:34, marcelo bagnulo braun wrote:
> >>>> different

Looks good!  Thanks!

> imho an appendix is not the place to include all this detailed 

I'll most certainly agree. 

/rgds
/cwng

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 21 Jul 2004 17:13:26 +0200

> advertising a global route on any link of the NEMO.

Well, my observation was more general. I mean, RA are link scoped, so 
when you have more than one link, some info may be lost. In this case, 
the info lost is the info about what router is announcing which prefix, 
i guess. Suppose a case where you have three MR and three different 
prefixes and each MR is in a different link and regular routers in 
between. Suppose now that only a single MR is working, how do the other 
MR identfy which prefix they have to use to configure the new CoA?
In this case, there are three prefixes being announced and a MR whose 
link has failed, knows that his prefix is not to be used, but it has 
not enough info to decide which one of the other two prefixes to use to 
configure the new CoA.
Agree?
You probably need a mechanism to allow a MR to withdraw its own prefix 
when it discovers that its link is no longer working. But for this you 
cannot use RA, you need to move to router renumbering or dhcp, i guess

Another issue that it is not covered in this solution is the ingress 
filtering compatibility. I eman, in the regular situation, when the two 
prefixes are available, you may have problems with ingress filtering, 
unless you use source address based routing or something similar, 
right? i guess you need additional mechanisms to deal with this, like 
tunnels between the MR in order to forward the packet through the MR 
that is linked to the provider that has delegated the Nemo prefix that 
is included in the source address of the packet.

> register the prefix that was not advertised by the other MR.

Well, the point is that when there is a single prefix in the nemo, you 
don't need this solution :-), at least not all of it. You still need 
the mechanisms to detect failures in the tunnel.
Depending on the number of home agents, you may need a routing protocol 
to discover which HA to use.
Something similar happens when there are multiple prefixes but all of 
them are supported by all the HAs. In this case, you don't need this 
double tunneling stuff, and the mechanism that is used for the single 
prefix case will work fine here also.

In addition, you can probably optimize the double tunneling issue when 
there is a single HA, since this HA knows both MR. imho this is a very 
common case, especially when you are using multihoming to provide 
ubiquity rather than fault tolerance.

My point is that there are several scenarios that have different 
approaches and require different variations/optimizations, so it would 
be good to describe all of them and define which tools are required in 
each scenario.

makes sense to you?

regards, marcelo

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 22 Jul 2004 11:21:36 +0800

> not enough info to decide which one of the other two prefixes to use to 

Yes.

> cannot use RA, you need to move to router renumbering or dhcp, i guess

That is one area I wish to avoid (to keep the solution simple), but from
our discussion it seems unavoidable.

> is included in the source address of the packet.

Point noted.

> be good to describe all of them and define which tools are required in 

Yes.  Great, thank you for these discussions, it certainly helps me to
see how the solution should be further developed.

/rgds
/cwng