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

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 17 Mar 2004 17:21:17 -0000

> without several cautions and very specific use cases.

Say MR1 and MR2 own a same MNP. MR1 registers to HA1 including explicit
prefix for MNP.
The MR2 registers to HA2 including the same prefix. Say that either HA1
and HA2 are the same or that there's a backend protocol between the 2,
such as HAHA or an existing IGP, that would hint HA2 that HA1 has
already a binding for MNP. 

The idea for 'DND' is for HA2 to test the connectivity to MR1 via MR2.
For instance, a probe to MR2 that'd be tunneled via MR1's MRHA tunnel,
maybe with a TTL of 1 for the inner packet, that ensures that it would
not go any further but onlink.

In particular, Nemo allows that the MR uses an address from its MNP to
register Home. So say that MR1's home address is MNP::1 and MR2's is
MNP::2. So if HA2 simply pings MNP::2 before accepting the registration,
it means that the MR1 and MR2 share the same link (because the packet
will be attracted by HA1, tunneled to MR1, and MR1 will deliver it on
the ingress interface to the MNP, or drop it if MR2 is not there.

> studied properly as part of a multihoming scenario.

What do you mean remove? Saying it is unlawful does not prevent it. Only
a runtime test will say if we end up in that situation. This is what I
tried to mean with the analogy, sorry if I failed.

> moves away for any reason (failures or mobility) ?
Agreed. We need to give it more thoughts to it and we knew it. We
started an effort on multihoming and HAHA in part for that purpose. But
I'm still convinced that Nemo should stay as it is, simple and open. 

Today we cover by that case by deployment recommendations, and tomorrow
we'll add protocol elements to allow more flexibility. Eg: today in
works in a train because the train moves as a single piece. But the
operational constraint for the time being is that the routers in the
train are paired or something, never to be separated unless they are
reconfigured. It is expected that the MRs that share a MNP move
together. Because they are LINKed by their back end.

In the absence of a DND test, there's nothing but words to prevent MNP
duplication anyway. And the words should be in the deployment
recommendations, not in the draft, IMHO. Note that the initial
discussion is about multiple DRs in IPv6 on a same link, and the
problems if they are incoherently deployed. This did not prevent IPv6
from moving forward, but yes, there's room for enhancements.

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 17 Mar 2004 17:21:17 -0000

Pascal

---

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 17 Mar 2004 19:40:42 -0500

> not go any further but onlink.

=> And what happens when the test doesn't work? Which
MR do packets get tunnelled to?
Of course there is no such interaction defined today
between HAs.

 > What do you mean remove? Saying it is unlawful does not 
 > prevent it. 

=> How do we stop a MN from registering with 2 CoAs
in MIPv6? The spec states that one BU overwrites
an existing one. Simple! I see no reason why this 
spec should allow that when it's explicitly disallowed 
in MIPv6. Especially when the issue has not been sufficiently
addressed in the spec. Of course we can address it in another
spec (or in this one if people think it's really 
urgent), but none of this is happening now. So I think
we got the worste of both worlds in the current spec.

    Only
 > tried to mean with the analogy, sorry if I failed.

=> That's ok, but if the spec disallows it and some 
implementer decides to do it anyway that's their problem.

 > I'm still convinced that Nemo should stay as it is, simple and open. 

=> Open to bugs? Without a complete solution this thing
is a bug. I think we should either hold the spec until
it's fixed or explicity disallow it like MIPv6.
Either solution is fine with me.

 > 
 > Today we cover by that case by deployment recommendations, 

=> Not enough IMO. BTW, having re-read the HA operations
 section, there is not even a hint at allowing two MRs to
have the same prefix. There is also not a hint about disallowing
this case. I think that, given this discussion, it's necessary
to add something to that section to explicitly get it off the fence!

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 17 Mar 2004 19:40:42 -0500

Only

Hesham

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 18 Mar 2004 08:41:27 -0000

> -----Original Message-----
> From: Soliman Hesham [mailto:[email-masked]]
> Sent: jeudi 18 mars 2004 01:41
> To: Pascal Thubert (pthubert); IETF NEMO WG
> Subject: RE: Assigning the same prefix to multiple MRs
> 
> 

A type above, I meant "The idea for 'DND' is for HA2 to test the
connectivity to MR2 via MR1".
The test is done prior to accepting MR2's binding. If the test does not
work, MR2 registration fails. Like DAD.

> we got the worste of both worlds in the current spec.
Yes and no: it works as you say if the 2 regs come to the same HA. But
if there are 2 HAs, the second looses just like in the test I propose;
also if the node is at home and there's a second binding for the same
Home address, the binding looses. MIPv6 is not consistent in that case
and  Nemo is not worse either. 

Also, a Nemo prefix registration is a route updating. There can be
parallel routes, this is nothing new and actually very useful for path
redundancy. You can not compare a MIPv6 registration of a Mobile Host,
which is a nothing but a remote ND operation, with the Nemo explicit
registration of a prefix, which is a routing action. So we apply MIPv6
thinking to the Home Address of the MR, but we apply routing thinking to
the prefix. This happens every day with your favorite ISP. If the net
admin has configured a same prefix in 2 different places, shit
happens...
> implementer decides to do it anyway that's their problem.
I think it should not prevent anything. Against the spirit. Maybe words
in the usage draft or something to discourage uncontrolled behaviours or
something?

> Either solution is fine with me.
Do you mean OSPF is a bug? OSPF by itself will not prevent a prefix
duplication. Actually some very controlled deployments use that for site
redundancy. If I remember well, the Nagano Olympics site worked that way
a few years ago, but I may be wrong on that specific one. Leave
something for deployment guys, they know their job.

> to add something to that section to explicitly get it off the fence!
Well, the hint was there in version 00. I was asked to remove it. Also
please look at slide 9 of 11 (looks like a borg thing now) of
http://www.mobilenetworks.org/nemo/ietf57/slides/nemo-ietf57-basic.pdf 

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 18 Mar 2004 08:41:27 -0000

Pascal

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 18 Mar 2004 03:59:30 -0500

> work, MR2 registration fails. Like DAD.

=> Right so MR2 and the network behind it become
unreachable because MR1 is possible down! That's not
good.

 > Yes and no: it works as you say if the 2 regs come to the 
 > same HA. 

=> That's the only case we have now. One HoA, one CoA, one HA.

   But
 > if there are 2 HAs, 

=> There is never 2 HAs visible on the IP layer.

 > Home address, the binding looses. MIPv6 is not consistent in 

=> Because this case does not exist in MIPv6.

 > redundancy. 

=> Sure if parallel paths lead to the same destination.
This is the whole point, they may not lead to the same
destination. You're basically asking for anycast prefixes. 
Anycast is not useful if you want to have reliable 
communication with the same host (i.e. a reachable host).

   You can not compare a MIPv6 registration of a 
 > Mobile Host,
 > the prefix. 

=> I'm saying that if you want to do that then apply
it properly. At the moment it's not applied properly.
It seems like this feature was not agreed on and things
were left hanging in the air. I suggest that we either
fix it or make it clear that it's not allowed.

  This happens every day with your favorite ISP. If the net
 > admin has configured a same prefix in 2 different places, shit

=> I don't know what you' rereferring to here. None
of this happens today. I think you have parallel
redundant paths mixed up with this. They're not the
same thing. ISP routers don't move while advertising
a prefix which cannot be reached through them...

 > something for deployment guys, they know their job.

=> See my comments above.

 > Well, the hint was there in version 00. I was asked to 
 > remove it. 

=> So it seems like it's not agreed on. In this case
I'd just add something in the draft that makes it clear
that you can't do that. Maybe another draft is needed
to add this.

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 18 Mar 2004 03:59:30 -0500

But

Hesham