Subject: [nemo] about draft-ietf-nemo-multihoming-issues-01

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 16 Nov 2004 19:16:14 +0100

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

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

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

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

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

Next you have a typo in

For those failures that can't be
    receovered (such a failure of the access router), a heartbeadt
                                                                ^
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

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

Finally, separate the references in normative informative

Regards, marcelo

------------------------------------------
Please note that my former email address
[email-masked] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------