Subject: [nemo] Assigning the same prefix to multiple MRs

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 17 Mar 2004 09:26:24 -0500

> > => That seems too handwavy for a standards track doc. What
 > > is the point of having the same prefix for more than one MR
 > > anyway? Is it a quick fix for multihoming ? I'm not sure
 > > that this is even true because even the MR might not always
 > > know if it should send a BU or not for its own prefix.
 > > 
 > > Perhaps this (I'm reluctant to call it feature)
 > > capability should be removed and only have 1 prefix per MR.
 > 
 > I'm not sure it's a quick fix. But it's an opening for sure. 
 > Multihoming
 > will have a harder time if we bar that situation blindly. 

=> I think this capability is added blindly actually. I
don't think we'll do much for the multihoming problem
compared with potentials bugs. More on this below.

 > Taking the train case, I see it as a value to be able to 
 > configure the 2
 > MRs with the same mobile prefix. If the configuration is controlled
 > properly then that's no problem. Seems nicer to me to probe 
 > for error as
 > opposed to forbid...

=> How can you probe for error? This is a general 
solution I presume and not limited for the train case.
a network with more than one MR assigned the same home
prefix can become unreachable if the 2 MRs are in different
places. Id the two MRs are separated for whatever reason
none of them will know who should register the prefix.
In fact, they won't even know if they are separated. 
So I don't think this is a good idea. At least not 
without several cautions and very specific use cases.

 > 
 > Now, whether you support this configuration or not, you may want to
 > check for it anyway. DAD is not wanted in MIP but it's checked for. 

=> DAD is wanted of course, but it needs to be faster.
In any case, DAD is part of IPv6, MIP didn't add it.
This is a new thing added by nemo, for what seems to
be a limited gain. The least we could do is add "CAREFUL"
all over it to make sure that people understand what this 
means. Personally, I'd prefer to remove this and have it 
studied properly as part of a multihoming scenario.

 > 
 > And if the check is added and finds that the situation is OK, why bar
 > it?

=> I haven't seen the check you refer to so I can't
tell. But independently of the check, there needs 
to be a rigorous analysis of the impacts. For example,
what happens if the check fails? which MR gets the lucky
tunnel ;) what happens when an MR boots or part of the network
moves away for any reason (failures or mobility) ? 

Hesham