Subject: RE: [nemo] Multiple Egress vs multihoming

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 20 May 2003 11:32:39 +0100

> 
> I agree it is not important how many egress interfaces a 
> mobile router has.  That's not what 'w' is.  'w' is used to 
> differentiate between whether there is a single mobile router 
> or multiple mobile routers in the mobile network.
> 
> > 
> > In other words it seems to me that the w is not too 
> useful... For me, 
> > the problems are still the 4 I listed before. If I'm missing 
> > something, sorry about that :)
> 
> You may have misunderstood 'w'. See if you still think there 
> is no difference whether there is a single MR or there is multiple MR.
> 

I call an x case what Julien refers to as w=0 (as opposed as you). And I
call a y case what both of you call w=1. 
Quoting "
 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.

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

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

I think Julien is better with his w=0, if he removes   "OR a Mobile
Router have more than one Interface". But then the problems for w=0 and
w=1 are not exclusive (as I'll detail further, read on). So w is just
misleading. I think it brings nothing and should be dropped.

> > 
> > Let me describe further the problems I see, x cases, Tarzan 
> and JetSet 
> > and y cases, Shinkansen and doublebed:
> > 
> > Tarzan: One MR building and registering (to same HA) 
> several CareOf in 
> > order to maintain connectivity while moving is a MH(x=0)
> 
> I interpret x=0 as a single HA.  

Yes, and it's an x meaning multiple careOf active in parallel.

> 
> > 
> > The Tarzan problem is the introduction of multiple CareOfs 
> registered 
> > in parallel. This breaks the MIP paradigm. Whether they are on a 
> > single or multiple interfaces of the MR may not ne important, but I 
> > expect that they'll be on different access routers. Anyway, this 
> > introduces the load balancing / high availability problem in both 
> > directions. I understand that FMIP has already studied this some. 
> > Maybe we can start from there.
> > 
> > JetSet: one MR that registers its prefix to Paris and New 
> York at the 
> > same time in order to optimize routing is a MH(x=1)
> > 
> I interpret x=1 as two or more HA.
> 
> > The JetSet is the case where the multiple CareOfs are not 
> registered 
> > to the same HA. The HAs may be far away from each other. The JetSet 
> > problem is the collaboration of the HAs in order to accept multiple 
> > registrations, and the selection by the MR of the best 
> via-HA to the 
> > correspondent. Correlated problem is to get the packets onto the 
> > active tuunels on the HA side. This is the problem for 
> which I pointed 
> > out that a dynamic routing over the MRHA is needed, 
> including for me 
> > whatever causes the MNP prefix to be injected in the Home 
> AS routing 
> > protocol while the MR is registered.
> > 
> > Shinkansen: A train with one prefix, one careof per MR and 2 MRs, 
> > which is a MH(y=0).
> > 
> I interpret y=0 as a single prefix advertised to MNNs.  The 
> way you define it, it will be a (w=1,x=*,y=0) under Julien 
> and my classifications.

It may not be an x at all if one MR does not actually register (hot
stand by). This is not the problem addressed.
But for most practical cases, yes.

> 
> > Shinkansen is about the high availability of a prefix being 
> registered 
> > by 2 different MRs. The problem is to make that transparent to the 
> > MNNs, so that if the MRHA tunnel of one MR fails, the MNNs traffic 
> > move to the other MR. Note that if we have both routers registering 
> > the same prefix at the same time, this is an x case too. But the 
> > second MR can be in hot standby, in which case this is not a x case.
> > 
> > doubleBed: 2 MRs happening to share the same wireless media 
> for their 
> > mobile prefix (Erik's problem) is a MH(y=1)
> 
> I interpret y=1 as a multiple prefix advertised to MNNs. The 
> way you define it, it will be a (w=1,x=*,y=1) under Julien 
> and my classifications.
> 
> 

Again, it may not be an x. But for most practical cases, yes.

> > Say MR1 has prefix P1 and HA1, and that MR2 has P2 via HA2. 
> doubleBed 
> > problem is basically to allow traffic with a careOf in P2 
> to flow via 
> > MR1. This requires MR1 to accept P2 in its ingress filtering 
> > selection. This also requires, if MR2 is down, the HA1 
> sends traffic 
> > for P2 over MRHA1. In other words, MR1 has and advertises 
> P2. Julien's 
> > case with an intermediate router is a good one. For me, 
> this is a case 
> > where the MN is not a stub anymore, and should be ruled out 
> of scope 
> > real quick.
> > 
> > If you see other problems to be solved please update this 
> discussion. 
> > I could also help on the draft if you wish...
> 
> We will have agree on each others taxonomy first ...  I admit 
> that our 8 classifications may be a bit overkill, and some of 
> them may turn out to trivial.  But IMHO, a draft should be 
> there to document such a deduction of triviality and the 
> draft Julien and I are co-authoring is exactly to do this.
> 

There is a difference between trivial and irrelevant...

> In trying to merge our classifications, I way I see it is this:
> 
> Tarzan is (w=0,x=0,y=*)
> JetSet is (w=0,x=1,y=*)
> Shinkansen is (w=1,x=*,y=0)
> Doublebed is (w=1,x=*,y=1)
> 

No. According to Julien's definition:

Tarzan is (w=0,x=0)     	whether there's a y at all does not
change the problem addressed here
JetSet is (w=0,x=1)
Shinkansen is (w=1,y=0)
Doublebed is (w=1,y=1)

You are in multihoming if you are either x, y or both. In your Julien's
terms, for w=0 or w=1. Both w values can be split in 2 subcases, ending
up with my list. Look at your cases... For instance, what is (w=0, x=0,
y=*)?

> By the way, on careful inspection of your definitions, your x 
> and y are not orthogonal but mutually exclusive, since Tarzan 
> and JetSet specifies (one MR) and Shinkasen and Doublebed 
> specifies 2 MRs.
> 

No. They are defining problems that are orthogonal and should be
addressed separately. I just expressed the 4 problems in the mail you
answer to, please read that much carefully, and feel free to improve it
for what's missing or unclear.

Let's illustrate what I mean by orthogonal: for instance, you have the
Tarzan problem in a train with 2 MRs and one prefix, where both MR
attach to the same HA.That Tarzan problem should still be handled the
Tarzan way, even though there are 2 MRs. The fact that there are 2 MRs
causes that there is the Shinkansen problem to solve as well, and that
it should be solved the Shinkansen way, regardless of the fact that
there are 2 CareOfs in parallel, which has already been solved by
Tarzan. 

Is that a bit clearer now? If not, please enumarate your 8 possibilities
and tell me the 8 specific problems you have to solve, the way I just
expressed the 4 that I understand... Maybe it will help. I think you are
still configuration minded at this point... There are many many of them,
but not as many problems, hopefully.

Pascal

---

From: Chan-Wah Ng <[email-masked]>
Date: 21 May 2003 20:20:25 +0800

> misleading. I think it brings nothing and should be dropped.
Sorry.  Can't see any difference between so-called "Julien's definition"
and "my definition".  I always thought between Julien and me are in
sync.  And no, I did not see where you give explanations of why 'w'
should be dropped.

-- 8= 8< 8= -- some portions snipped -- 8< 8= 8< --

> change the problem addressed here

I think that's where we differs in terminologies.  I guess a taxonomy
should cover everything.  What I hope to do is that every single
situation where nemo is multihomed will fall into one of the
(w=?,x=?,y=?) category.  That's why I don't see any difference between
saying (w=0,x=0) and (w=0,x=0,y=*).

On that same note, are you claiming that there is no multihomed network
that your classification do not cover?

-- 8= 8< 8= -- some portions snipped -- 8< 8= 8< --

> 
> 
> please enumarate your 8 possibilities

I hope so too!  Which is precisely why we chose to first classify all
multihomed mobile network into some number of categories, and then
identify which categories contains problem that need to be solved by
NEMO WG.  Some categories may contain similar problem, and solving one
will solve some of the others... it doesn't matter right now.  

Okay, here are the 8 in (w,x,y) tuple: (these are written just off my
mind, so pardon me if they appear to lack careful analysis)

(0,0,0) = One MR, one HA, one prefix
As far as I see it can either have more than one care-of-address
addressed to one HoA (multiple interface sharing same HoA but different
CoA), or it can have different CoA-HoA pairs.  Either way, it should be
a MIPv6 problem.

(0,0,1) = One MR, one HA, multiple prefix.
If the MR has only one HoA with multiple CoA and multiple subnet prefix,
we need a way for HA to be able to register that the multiple prefixes
are tied to that HoA.  I guess it should be a NEMO problem.

(0,1,0) = One MR, multiple HA, one prefix
Can MR register the same HoA in two different HAs?  If not, the problem
is simply a HoA-CoA pair per HA.  There is also the question of same
prefix-careof in two different HA.  Need to analyse further.

(0,1,1) = one MR, multiple HA, multiple prefix
largely similar to (0,1,0), but now you have additional prefix coming
in.  This may be easily solved if we demand that each prefix be taken
care of by separate HA.

(1,0,0) = multiple MR, one HA, one prefix.
May not have any problem at all if the MRs are manually configured to
announce same prefix.  Prefix delegation is also possible since the MRs
are handled by same HA.  HA will see two HoA-CoA pair sharing taking
care of the same subnet prefix.

(1,0,1) = multiple MR, one HA, multiple prefix
May not have any problem at all if each MR take care of separate prefix.

(1,1,0) = multiple MR, multiple HA, one prefix
Question of multiple HA handling the same prefix.
Also question of how to do prefix delegation between two MRs with
different HA.

(1,1,1) = multiple MR, multiple HA, multiple prefix
May not have any problem at all if each MR take care of separate prefix.

Comments?  (perhaps Julien would like to add more)

/cwng

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 21 May 2003 12:12:03 -0700

can we stick to the following categories when we discuss
multihoming on this list? half the time I find myself trying
to figure out which multi-homing scenario is being referred
to when I read a particular mail on the list.

I find the following very clear.

Vijay

---

From: "Subrata Goswami" <[email-masked]>
Date: Wed, 21 May 2003 13:18:14 -0700

Hi, I think the notation suggested by Chan-Wah Ng is very useful,
although a little non-intuitive. Instead of using only 0/1 we should
use -n to n for the 3 fields.  Thus  

(1,1,1)    signifies  (One MR, one HA, one prefix)
(0,0,0)    signifies  ( no MR,  no HA,  no prefix )
(l,m,n)    signifies  ( l MR,  m =< HA ,  n =<  prefix) 
(-1,-1,-1) signifies  (  ?,    ?,   ?)

Subrata

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Vijay Devarapalli
> Sent: Wednesday, May 21, 2003 12:12 PM
> To: Chan-Wah Ng
> Cc: Pascal Thubert (pthubert); Julien Charbon; IETF NEMO WG
> Subject: Re: [nemo] Multiple Egress vs multihoming
> 
> 
> > addressed to one HoA (multiple interface sharing same HoA but 
> > different CoA), or it can have different CoA-HoA pairs.  
> Either way, 
> > it should be a MIPv6 problem.
> > 
> > If the MR has only one HoA with multiple CoA and multiple subnet 
> > prefix, we need a way for HA to be able to register that 
> the multiple 
> > prefixes are tied to that HoA.  I guess it should be a NEMO problem.
> > 
> > Can MR register the same HoA in two different HAs?  If not, the 
> > problem is simply a HoA-CoA pair per HA.  There is also the 
> question 
> > of same prefix-careof in two different HA.  Need to analyse further.
> > 
> > announce same prefix.  Prefix delegation is also possible since the 
> > MRs are handled by same HA.  HA will see two HoA-CoA pair sharing 
> > taking care of the same subnet prefix.
> >