nemo@ietf.org
[Top] [All Lists]

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

Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-02.txt
From: Chan-Wah Ng
Date: Thu, 24 Feb 2005 21:41:42 +0800
Hello Marcelo,


On Thu, 2005-02-24 at 11:51 +0100, marcelo bagnulo braun wrote:
> 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
> 

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

<Prev in Thread] Current Thread [Next in Thread>