Subject: RE: [nemo] Multiple Egress vs multihoming

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 24 Apr 2003 11:02:51 +0200

> > I beg to differ.  Requirement 13.1 does not equate to 
  > > "Multiple MRs with different HAs advertising same prefix".  
  > > Why in the first place would two MR choose to advertise the 
  > > same network prefix if they does not belong to the same 
  > > administration domain?
  > 
  > It's one way of being multihomed. You have a mobile network 
  > in a train.
  > One prefix. But you want redundancy (load sharing?) 

=> I was confused by the previous mail and thought 
that you must have made this assumption to get the previous
conclusion. Multihomed mobile networks do not need to use
multihoming for redundancy. They mightbe multihomed because
they just happened to have two MRs, period. So the initial
aim should be to make this configuration work (i.e. how
to route outbound traffic through the right MR). I fully
agree that multihoming for redundancy should be done 
later and not part of basic nemo. 

Hesham

---

From: William D Ivancic <[email-masked]>
Date: Thu, 24 Apr 2003 08:47:46 -0400

>
>If you have 2 MRs, and 2 real static routes of equal cost, the router
>behaviour is a round robin traffic splitting, unless you add policies to
>the picture.
> >>If the HA has static routes to the mobile network via two MRs, and only
>one is reachable, half of the packets are dropped. Now, it's a pain.<<

Pascal, could you explain the last statement better.  If an MR is 
unreachable, I think the binding goes away and therefore the route.  I 
think the picture in my head and the one being described are different.

Will

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 24 Apr 2003 13:58:25 +0100

Hi William:

A static route does not go away. That's the point. You code it and it's
stays there. If we make it dynamic, then you're right. For instance,
upon registration, Nemo installs the route. Or the route is via a tunnel
that is externalized. But is the route is in the form 'MR via MR's home
address' then since the home address is expected to be on the home
network, the route is used...

Pascal

> -----Original Message-----
> From: William D Ivancic [mailto:[email-masked]] 
> Sent: jeudi 24 avril 2003 14:48
> To: Pascal Thubert (pthubert)
> Cc: Chan-Wah Ng; IETF NEMO
> Subject: RE: [nemo] Multiple Egress vs multihoming
> 
> 
> 
> >
> >behaviour is a round robin traffic splitting, unless you add 
> policies 
> >to the picture.
> > >>If the HA has static routes to the mobile network via two 
> MRs, and 
> > >>only

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 25 Apr 2003 08:08:12 +0100

> > The difference is that R1 and R2 will always be there, 
> reachable. And 
> > I guess that soon as you have 2 of them, a sensible network 
> designer 
> > would start thinking of a routing protocol. If R1 and R2 become 
> > mobile, there's a chance that one of them is able to bind 
> and not the 
> > other. With static routes, you'll get only half of the packets 
> > through, which is not the desired result.
> > >
> 
> AH, but you never answered the first part.  For non-mobile 
> case, what will happen if R2 is down?  Is it any different in 
> a mobile case?

Sorry, I thought that was implicit. Same problem, half the packets
dropped. This is why a sensible network designer etc...

> > > 
> > If they have the same home address, there's a single static 
> route, so 
> > all the packets go over that route. The question is the 
> coordination 
> > between the MRs to register to the same HA or the 
> coordination between 
> > the HAs to accept that multiple registration and share the load 
> > accordingly (there are clustering techniques that allow that much).
> > 
> 
> Yes, yes, I agree that if they must have the same HoA, then the HAs
> and/or MRs must coordinate.   I have no dispute on that.  What I
> disagree is "they must have the same HoA".

Same home Address for both makes a single static route, all the packets
to that route. If there's a distribution, it happens at BCE time, when
choosing between multiple parallel registrations, which is DYNAMIC, this
time. The problem is to have both MRs register to the same HA and make
as if there was a single MR with multiple CareOf (Tarzan). Or else you
need to coordinate the HAs, but it seems even a bigger change from MIPv6
because of ND interaction.

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 25 Apr 2003 08:50:18 +0100

> > on different interfaces is IMHO to be supported implicitly (R13.2). 
> It can be either 1 MR with multiple egress interface, or 
> multiple MRs. For each cases, we can have the distinctions as 
> Pascal suggested of single-vs.-multiple HA, and 
> single-vs.-multiple mobile network prefix.  It turns out that 
> on top of Pascal's (x,y), I have (w,x,y), where {w=0: 1 MR 
> with multiple egress interface, w=1: 2 or more MRs }.
> 
> With, that, I have the following taxanomy tree:
> 
> 
> [Multi-egress NEMO]
>  |
>  +->[Multi-Interface]: Single MR with multiple egress interface
>  |   |
>  |   +->[Single HA]: all HoA-CoA bindings sent to same HA
>  |   |   |
>  |   |   +->(A)[Single Prefix]: MR advertises a single prefix
>  |   |   |
>  |   |   +->(B)[Multiple Prefix]: MR advertises multiple prefices
>  |   |
>  |   +->[Multiple HA]: HoA-CoA bindings to different HAs
>  |       |
>  |       +->(C)[Single Prefix]: MR advertises a single prefix
>  |       |
>  |       +->(D)[Multiple Prefix]: MR advertises multple prefices
>  |
>  +->[Multi-MR]: Multiple MR
>      |
>      +->[Single HA]: all HoA-CoA bindings sent to same HA
>      |   |
>      |   +->(E)[Single Prefix]: both MRs advertise same prefix
>      |   |
>      |   +->(F)[Multiple Prefix]: MRs advertise different prefices
>      |
>      +->[Multiple HA]: MRs send HoA-CoA bindings to different HAs
>          |
>          +->(G)[Single Prefix]: both MRs advertise same prefix
>          |
>          +->(H)[Multiple Prefix]: MRs advertise different prefices
> 
 
I add proposed in the initial mail that a MR with multiple interfaces
fell into the sense (R13.2). The real thing is whether there are more
then one active CareOf at a given point of time, which is where we
extend MIP. If you look at it, You can autoconf more than one CareOf on
a single interface if you hear from more than one AR, and this is
already a multihoming scenario (so there is multihoming with w=0!).
Whether the ARs are on the same egress link or different egress links of
a same MR does not seem to impact the mobility protocol, does it? That
may impact QoS related issues, though, but it seems far from basic nemo.

Also, it seems to me that the x and y directions should be orthogonal.
This is a design decision. The protocol changes that allow multiple
CareOf should not be related to the protocol changes that allow multiple
MRs. This assumption may be eliminating some solutions, but I think it's
the clean approach. It is related to the parallel discussion we are
having with the same title.

With all this in mind, I reduced the problem set to 4 cases, knowing
that a solution for either x must allow either y and reciprocally.

To come back to your classification, I'd suggest you start thinking for
w in terms of CareOf as opposed to links. Read my initial mail
carefully, I spent quite some time wording it. A second point is that I
associate the CareOf with the prefixes, not the home addresses. Think
about it with Ryuji's draft in mind.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 25 Apr 2003 17:00:11 +0100

Hi Julien:

I like your work very much. Very useful and constructive :) I hope we
keep your pictures in the final taxonomy.

A general remark, the fact that the multiple careofs are one the same
interface or on different interfaces does not strike me as relevant.
There must be a way for the MR to sort out the available careOfs and use
the best one(s). The interface that provides a careOf is relevant in
that selection. But the protocol to the Home Agent is not impacted, is
it?

>   + Single HA              [Just one HA for CoAs for a same prefix]
>   + Multiple Prefix        [Announced by Egress Routers]
> 

Right.

> 
>   Not only for Shinkansen and DoubleBed because, you can have this
> case:
> 
>           P
>          --->
>           _         _____
>     _  |-|_|-|  _  |     |
>    |_|-|     |-|_|-|     |-|        _
>     _  |     |     |_____| |  _  |-|_|
>    |_|-|  _  |             |-|_|-|
>        |-|_|-|                   |
> 
>          --->
>           P
> 
>    MNNs   MR   AR  Internet  AR    HA
> 
>   Which is a Tarzan case. [Single HA for CoAs of a same Prefix]
> 

You're right :)

> 
>   So for the Tarzan you can have:
> 
>    - One multi-addressed MR.
> 
>                AR2 [P2]
>     _           _   _____
>    |_|-|  _  |-|_|-|     |
>     _  |-|_|-|  _  |     |-|        _
>    |_|-|     |-|_|-|_____| |  _  |-|_|
>                            |-|_|-|
>                                  |
>                AR1 [P1]
> 
>    MNNs   MR        Internet  AR    HA
> 
> 
>    - One "Multi-egress-interfaced" MR.
>                     _____
>     _           _  |     |
>    |_|-|  _  |-|_|-|     |-|        _
>     _  |-|_|=|     |_____| |  _  |-|_|
>    |_|-|     |             |-|_|-|
>                                  |
> 
>    MNNs   MR   AR  Internet  AR    HA
> 
> 
>   - Two MR in multi-site case.
> 
>           P
>          --->
>           _         _____
>     _  |-|_|-|  _  |     |
>    |_|-|     |-|_|-|     |-|        _
>     _  |     |     |_____| |  _  |-|_|
>    |_|-|  _  |             |-|_|-|
>        |-|_|-|                   |
> 
>          --->
>           P
> 
>    MNNs   MR   AR  Internet  AR    HA

Yes, they are all Tarzan. The most typical in my mind is:
Note that the [=] sign is extended to mean 'may or may not be the same
interface'

                AR2 [P2]
     _           _   _____
    |_|-|  _  |-|_|-|     |
     _  |-|_|=   _  |     |-|        _
    |_|-|     |-|_|-|_____| |  _  |-|_|
                            |-|_|-|
                                  |
                AR1 [P1]
 
    MNNs   MR        Internet  AR    HA

> 
>    In all this examples the HA will have two CoAs for the 
> same prefix in one HA. According with your definition they 
> are Tarzan cases.
> 

Shinkansen and doubleBed are Tarzans by definition. 
I meant x and y to be orthogonal, not mutually exclusive.
I just hope that the problems can be addressed separately.   

> > Any IPv6 node may build multiple global addresses. Long as 
> we do not 
> > register several CareOfs at the same time, it's not a Nemo 
> issue, it's 
> > a standard feature.
> 
>   I just add a remark :
> 
>     - Example with one MR multi-addressed.
> 
>                AR2 [P2]
>     _           _   _____
>    |_|-|  _  |-|_|-|     |
>     _  |-|_|-|  _  |     |-|        _
>    |_|-|     |-|_|-|_____| |  _  |-|_|
>                            |-|_|-|
>                                  |
>                AR1 [P1]
> 
>    MNNs   MR        Internet  AR    HA
>  
>   P1/P2: Differents IPv6 /64 Prefix.
> 
>   And of course Ingress Filtering is made on AR1 and AR2.
> 
>   So the MR may have this two IPv6 global address :
> 
>    P2:EUI-64-MR and P1:EUI-64-MR
> 
>   If the bi-directional tunnel between the MR and the HA pass 
> through AR2 and if AR2 is destroyed by Tarzan anger [the real 
> one] and so its reachability to the Internet lost, how the 
> NEMO mechanism should deal with this case ?
>   So I think Multi-Addressed Multi-Homing is an important 
> case in NEMO, not just a standard fearture. [But maybe I'm 
> wrong]. Also maybe it will be resolve by the same mechanism 
> in NEMO, so I put it with the Multi-Interfaced case.
> 

Reread me well: I meant that if you register only one CareOf at a given
point of time, it is a standard MIP flows.
If a MIP MN sees 2 ARs on a link, it can build 2 careOfs, but can only
bind the primary. If the primary careOf fails to bind, or times out
rebinding, a standard MIP MN should go try the next available careOf.
That process is not necessarily described in MIPv6, but should it? 

Now, if you have 2 concurent tunnels, it is a whole new problem, to be
designed :) . The HA may try to load balance over the 2 tunnels, and if
one dies, we must make sure the HA knows quite fast. For instance by
encapsulating over TCP or SCTP. 
Anyway, it's one of the good problems to resolve if we want multiple
careOfs.
Multihoming is not trivial, we'll have to decide whether to amend the
requirements draft for basic about that.

> > Comments anyone?
> 
>   I think you have found the good discrimants to classify the 
> Multi-Homing in NEMO. So I have just read the Chan Wah Ng's 
> mail [2], and just by taking again his classification and ours :
> 
>  And I obtain (w, x, y) :
> 
>   with
> 
>   w: 0: A Mobile Router have more than one Global IPv6 Address.
>         OR a Mobile Router have more than one Interface.
>      1: There is more then one Egress Mobile Router.
> 
I expect that in any case you imply that multiple CareOfs are registered
in parallel, right?

>   x: 0: There is single HA for CoAs of a same Prefix.
>      1: There is muliple HA for CoAs of a same Prefix.
> 

I meant mobile prefixes, no the prefix that the careOf is built upon.
I'm sure you mean that too?

>   y: 0: A single Prefix is announced by Egress Router(s).
>      1: Muliple Prefix are announced by Egress Router(s).
> 

I meant present on INGRESS; see the discussion with Hesham; is this a
typo or is there a misunderstanding between us?

I do agree with your vision. My view is a summarization to focus on
where the problems are in my own view. We may start your standpoint and
see what are the meaningful case between the 8 combinations. For
instance (0,0,1) is a trivial extension of (0,0,0). Like this, we'll
find my 4 problems, and other if I missed some? Do you want to pursue
that way?

Pascal

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 30 Apr 2003 05:53:56 +0200 (CEST)

> because of ND interaction.

Pascal,

I don't understand what you think is the "bigger change".

Routing protocols already do such "coordination" in the the same
route can arrive at the same router (within the home site) from
different routers = HAs.

So I don't understand why routing protocols are excluded from the thinking.

What am I missing?

One thing that matters in this multihoming picture which everybody seems
to be omitting is the location of the Home Agents with respect to
administrative boundaries.

The case when one or more MRs (one with multiple interfaces/CoAs or
two MRs each with a CoA) have separate HAs where the HAs are in the
same admin domain can be made to work very well by having the HAs advertise
the prefix route for the mobile network into the IGP.
(Whether the HAs do this only when the tunnel is "up" or whether a routing
protocol is run over the MR-HA tunnels is at some level a detail here.)

The case (with one or more MRs as above) where the HAs are in different
admin domains is quite different.
If you want routing to scale you can't use a single prefix for the mobile
network in this case since that prefix would need to get advertised in BGP. 
Essentially this case becomes the site multihoming problem; the mobile network
is a site which has to ISPs - one running each HA.
Thus to the extent that site multihoming is solved this is also
something that the Nemo WG doesn't need to worry about.

   Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 30 Apr 2003 07:16:45 +0100

Seems this one was never published by the nemo list ???

> From: Pascal Thubert (pthubert) 
> Sent: mardi 29 avril 2003 09:10
> To: 'Ryuji Wakikawa'; [email-masked]'
> Cc: [email-masked]'
> Cool!
> It reminds me of your draft on network registration. Good 
> ideas and a lot of work ahead :)
> 
> Question: if we use your other draft, could the MR just have 
> several IP addresses on its mobile network, and use that as 
> ID? Does not seem to me we are short of these!
> 
> To be honest, I believe that if we have to include 
> multihoming in the picture for basic, you approach seems to 
> be the most straightforward, leading to the simplest 
> solution. At the expense of the support of home network, 
> which pains me some, but I could accept it considering the rewards.
> 
> If we do that, we are back to the case with several routes to 
> a same network. 
> 
> Also, the various MR addresses may be owned by the same MR or 
> by different MRs. So what?
> 
> If you associate a distance to the advertisement, the HA can 
> use that to select the best CareOf. 
> 
> As I said, it's yet an other (simple) routing protocol, and 
> we need to understand how these routes are injected to the 
> routing table of the HA, and then redistributed to the others 
> (you need a metric that can be configured on the HA for 
> instance). I would not use the Routing protocol of the AS of 
> the HAs to do that, because I'd contain it inside a HA 
> multicast group, even if that group spans outside of the AS (JetSet).
> 
> You may recognize my initial comments on your other draft here :)
> 
> Anyway, I believe that this protocol between HA is really a 
> key for both your drafts to turn into a solution.
> 
> Pascal
> > From: Ryuji Wakikawa [mailto:[email-masked]]
> > Sent: mardi 29 avril 2003 00:49
> > To: [email-masked]
> > Cc: Pascal Thubert (pthubert); [email-masked]
> > Subject: Re: [nemo] Multiple Egress vs multihoming
> > 
> > 
> > 
> > Hi Pascal, and thanks watari.
> > 
> > Let me summarize the draft briefly.
> > We propose how to register multiple CoAs with single HoA.
> > It is very simple, we assign new ID number to each interfaces 
> > on MN. MN always registers bindings with the ID.
> > 
> > For example,
> >  - IF1 has CoA1 and ID1.
> >  - IF2 has CoA2 and ID2.
> > 
> >  single HoA
> >   +- MN-+
> >   |     | 
> >  IF1   IF2
> > 
> > MN sends BUx with HoA, CoAx and IDx.  HA will have multiple
> > bindings of MN which are association of HoA and either CoA1 
> > or CoA2. Then, HA searches BC with ID and HoA. Managements of 
> > each binding are done with correspondent ID respectively.
> > 
> > This ID is not only used for multiple binding managements but
> > also it could be used to associate some policies to a 
> > binding. For example, if MN want to receive TCP packets by 
> > IF1, it could send a policy
> > (TCP->ID1) somehow (by MIP or by applications) to HA. Before 
> > HA can search BC with ID and HoA, it can decide which binding 
> > is used for outgoing packets by the policy.
> > 
> > Policy parts are not discussed in the draft, yet.
> > 
> > regards,
> > ryuji
> > 
> > At Mon, 28 Apr 2003 17:37:04 +0900 (JST),
> > Masafumi Watari wrote:
> > > 
> > > Hello,
> > > 
> > > You can find the draft in the URL below.
> > > 
> > > 
> > http://www.ietf.org/internet-drafts/draft-> 
> > wakikawa-mobileip-multipleco
> > > a-00.txt
> > > 
> > > regards,
> > > watari
> > > 
> > > On Mon, 28 Apr 2003 07:53:04 +0100,
> > > "Pascal Thubert (pthubert)" <[email-masked]> wrote:
> > > 
> > > > Hi Ryuji:
> > > > 
> > > > I was not aware of your draft, nor could I find it in th
> > eitf site
> > > > or on google. Is that something you just submitted?
> > > > 
> > > > Pascal
> > > > 
> > > > > From: Ryuji Wakikawa [mailto:[email-masked]]
> > > > > Sent: samedi 26 avril 2003 03:03
> > > > > To: Hesham Soliman (EAB)
> > > > > Cc: Pascal Thubert (pthubert); Chan-Wah Ng; IETF NEMO
> > > > > Subject: Re: [nemo] Multiple Egress vs multihoming
> > > > > 
> > > > > 
> > > > > Hi Hesham
> > > > > 
> > > > > > => I'm interested to know how multiple care-ofs 
> could work in
> > > > > > MIP. We did that for FMIP some time ago but it was based on 
> > > > > > bi-casting for a short period (1 second). I will 
> > comment on the
> > > > > > rest of the email separately.
> > > > > 
> > > > > There are some researches for multiple CoA on MIP. 
> > > > > draft-montavont-mobileip-mmi-00.txt and 
> > > > > draft-wakikawa-multiplecoa-00.txt
> > > > > 
> > > > > regards,
> > > > > ryuji
> > > > > 
> > > > 
> > > > 
> > 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 30 Apr 2003 11:31:51 +0100

> If MR has two egress interfaces, then MR assigns two MR-A for 
> each egress interfaces and uses MR-A as ID of egress 
> interface.  Since MR-A is stored in BU and also in binding 
> cache, "ID field" in draft-multiplecoa is no longer needed 
> for MR.  It indicates no extensions is needed to the current 
> draft-wakikawa-nemo-basic.

nice

> 
> > Also, the various MR addresses may be owned by the same MR or by 
> > different MRs. So what?
> 
> MR can own several MR addresses. IPv6 allows to assign 
> various addresses to a same node/interface.
> 

My point was that if the ID is a MNET address as I proposed, and if, as
a consequence, we have a different address on the MNET per registration
(per careof), it should make no difference whether there's a single MR
or several of them. I think it's a nice feature, for the shinkansen
case...

> I will consider all possible cases such as Tarzan, JetSet, 
> Shinkansen, and doubleBed. I will update 
> draft-wakikawa-basic-nemo before next IETF. 
> 

We have to talk about the L3 HA-HA protocol; and whether the MRs need to
be involved as well. ThatMUST be in your draft too, otherwise you're
limited to a single HA, which sadly I'm not ready to accept ;)

> # BTW, Shinkansen is name of express train in Japan. I don't 
> know how # many people recognize what is Shinkansen :-p

I thought there were more people knowing it then TGV... Though there are
a lot of French and France resident in the ML :)

Pascal