Subject: [nemo] FW: Multiple DRs on a link

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

Hi:

This discussion happened at IPV6 WG, I thought it was relevant to copy
Nemo...

Pascal

> -----Original Message-----
> From: Soliman Hesham [mailto:[email-masked]]
> Sent: mercredi 17 mars 2004 09:38
> To: Pascal Thubert (pthubert); Jari Arkko
> Cc: [email-masked]
> Subject: RE: Multiple DRs on a link
> 
> 
>  > > => There are many different reasons. I sent a verly long
>  > > email about this to nemo (monet back then). One simple
>  > > scenario is that you might be walking around with a PAN
>  > > that happens to have 2 MRs on a single link (e.g. a laptop
>  > > and a mobile phone). The two MRs could share the same ingress
>  > > link and have different egress links. For instance your laptop
>  > > might have a WLAN card and your mobile might have a cellular
>  > > interface. Once you walk into an airport lounge or starbucks
>  > > you'll suddenly have a multihomed PAN. By definition, each MR
>  > > must have a separate home prefix. So each will advertise
>  > > a different prefix on the ingress side.
>  >
>  > Hi Hesham:
>  >
>  > I fail to understand the "by definition" here. Nemo does not
>  > prevent 2
>  > different MRs from registering the same MNP. It's like
>  > multiple parallel
>  > routes. What's not duplicated is the Home address... In
>  > fact, I proposed
>  > a test to check that both registrations actually end up in a
>  > same link,
>  > otherwise there's a problem equivalent to the DAD problem in
>  > MIP6. Not
>  > much success on that proposal, though
> 
> => Hmm, that's interesting. I must have missed that in the
> spec. So, my concern is similar to yours, how does the HA
> check whether the MRs are in the same place?? Seems like
> a dangerous feature to have. I'm surprised this wasn't discussed
> during LC.
> 
> Hesham

---

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

Hi:

Pascal

---

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

> a dangerous feature to have. I'm surprised this wasn't discussed
Well, Nemo requires that some authorization be run, that's not described
in the spec. Such a test could take place there, or the authorization
could bar a second registration for a same prefix, I guess.

Pascal

---

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

Pascal

---

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 17 Mar 2004 07:50:37 -0500

> could bar a second registration for a same prefix, I guess.

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

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 17 Mar 2004 07:50:37 -0500

Hesham

---

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

> Sent: mercredi 17 mars 2004 13:51
> To: Pascal Thubert (pthubert); IETF NEMO WG
> Subject: RE: [nemo] FW: Multiple DRs on a link
> 
> 
> 

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. In fact, the
Nemo spec is very open to future add-ons, and was wanted that way.

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

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. 

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

Pascal

---

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 17 Mar 2004 22:36:45 -0500

Thierry,

 > Back to the point, this probably requires a delegation 
 > mechanism between
 > the 2 MRs, this could be explained in a separate document, but
 > dis-allowing it in NEMO Basic Support would break the spirit of 
 > 
 > R12: The solution MUST function for multihomed MR and multihomed
 >         mobile networks as defined in [NEMO-TERMS]).

=> I didn't suggest that.

 > 
 > draft-ietf-nemo-requirements-02.txt
 > 
 > So, I'm against removing this capability (several MRs on the 
 > link) and
 > the like.

=> Me too. I am suggesting that if there is more
than one MR they should advertise different prefixes.
I.e. one prefix per MR. No anycast prefixes.
This has its own problems but it needs to be solved 
for multihoming in general.

 > 
 > What the NEMO Basic Support specification should say is that
 > configuration other than one single mobile subnet (i.e. not 
 > multihomed
 > or nested) or not guaranteed to work properly without additional
 > mechanisms.
 > 

=> I think this is orthogonal to my suggestion but I
agree with adding this to the spec.

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 17 Mar 2004 22:36:45 -0500

Thierry,

Hesham

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 18 Mar 2004 10:11:59 -0000

>  > > => 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.
>  > >
>  > 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.
> 
> 
What do you mean? If there are 2 MNs configured with a same Home Address, they MAY or MAY not get the same answer from DHAAD. They MAY be registering to different HAs. It can simply depend on which HA gets the DHAAD from the Internet, and whatever load balancing algorithm they have. Do I miss something? 

And like I said, If 2 MNs have a same Home Address, MIP will react differently whether they register to a same HA of to different ones. Or if one is at home and the other attempts to register. 

Nemo will act as MIP for the Home Address, and if that test is passed, Nemo will accept the duplicate prefixes, insert both routes, and leave it up to the routing protocols and the traffic splitting in place to get the packets forwarded. As a result, in most cases, you'll see packets over both tunnels. If there's no misconfiguration, the packets will end up in the same link anyway. As usual.

>  > 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
> 
> => Because this case does not exist in MIPv6.
> 
Seems you are more optimistic then I am :) I would not pretend that such a thing as misconfiguration does not exist in MIPv6. Just configure the same Home Address on 2 MNs and look? Then plug one at home and try binding the other one. Or the other way around?

>  > 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.
> 
> => 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).
I think we agree on that. Hopefully the 2 registrations do lead to the same place, since we want the 2 MRs to share the same ingress link; or else, it's a misconfiguration  - or the net admin knows that he is doing some fine trick and whatever words we put in the spec he is on his own -. 
Again, Nemo gives you the same level of service as OSPF or ISIS. After that it is about the professional skill of deployment people.

> 
>    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.
> 
> => 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.
Disagree. It was discussed at the WG. It's skill OK to voice your opposition but it was discussed. It was even specifically voiced at IETF 57, as I pointed out, and was part  of nemo basic draft 00.
 
> 
>   This happens every day with your favorite ISP. If the net
>  > admin has configured a same prefix in 2 different places, shit
>  > happens...
> 
> => 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...
All I'm saying is that if a network administrator of your ISP configures a same prefix on 2 different link, you'll reach the closest one, or, if you're in the middle, you may end up reaching them alternatively. Shit happens, and the IGP in place does not prevent that at all.
Should Nemo do more? If so, why?

Maybe all this discussion is because of a misunderstanding in the initial statement. I have in mind a configuration where an MNP is co-owned by 2 MRs that share an ingress link. The set (MR1+ingresslink+MR2) moves together as a whole. They are an atomic system. Link a plane with a wire between the 2 MRs. Maybe for you the ingress link is a fixed AP, like a hotspot at a Café, in which case the connectivity between the 2 MRs would be occasional? In that case, giving those MRs a same MNP is a misconfiguration, of course. And my point here is that the classical IGPs do not actively check for such a misconfiguration, either.

> 
>  > 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
Not because it's not agreed upon, because it's not normative. The text was judged complex and not part of the protocol. There was no specific behaviour associated to it...

> 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.
Well I believe that the plane case I gave as example is perfectly legitimate. It's enough for me to say that Nemo, as any routing protocol, should not bar anything like that. But yes, I agree that there's room for a multihoming usage draft that would details the can's and can'ts.

Pascal

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 18 Mar 2004 10:11:59 -0000

Pascal

Pascal

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 18 Mar 2004 06:10:04 -0500

> What do you mean? If there are 2 MNs configured with a same 
 > Home Address, 

=> That's a bug of course and is **_detectable_** because:
   A. There SAs should not both match the same HoA
   B. If they (SAs) do someone will complain and the misconfig will
      be rectified.

   they MAY or MAY not get the same answer from 
 > DHAAD. They MAY be registering to different HAs. It can 
 > simply depend on which HA gets the DHAAD from the Internet, 
 > and whatever load balancing algorithm they have. Do I miss 
 > something? 

=> I think you are talking about a misconfig case. I'm
talking about what the protocol is designed to do. And
of course if people misconfig things will not work
as planned. This goes for every protocol.

 > Nemo will act as MIP for the Home Address, and if that test 
 > is passed, Nemo will accept the duplicate prefixes, insert 
 > both routes, and leave it up to the routing protocols and 
 > the traffic splitting in place to get the packets forwarded. 
 > As a result, in most cases, you'll see packets over both 
 > tunnels. If there's no misconfiguration, the packets will 
 > end up in the same link anyway. As usual.

=> I understand what you're saying for the "fixed" MR case.
But, if the MR moves this will cause problems. Do you agree
with that? 

 > Seems you are more optimistic then I am :) I would not 
 > pretend that such a thing as misconfiguration does not exist 
 > in MIPv6. Just configure the same Home Address on 2 MNs and 
 > look? Then plug one at home and try binding the other one. 
 > Or the other way around?

=> You mean configure the _same_ SA for both MNs? I hope
not! Of course that will cause problems. I can't see how
this is an analogy to what we're talking about.

 > I think we agree on that. Hopefully the 2 registrations do 
 > lead to the same place, since we want the 2 MRs to share the 
 > same ingress link; or else, it's a misconfiguration  - or 
 > the net admin knows that he is doing some fine trick and 
 > whatever words we put in the spec he is on his own -. 
 > Again, Nemo gives you the same level of service as OSPF or 
 > ISIS. After that it is about the professional skill of 
 > deployment people.

=> Where is what you're saying reflected in the spec? Please
point me to a reference that an admin will read.

 > Disagree. It was discussed at the WG. It's skill OK to voice 
 > your opposition but it was discussed. It was even 
 > specifically voiced at IETF 57, as I pointed out, and was 
 > part  of nemo basic draft 00.
 >  

 > All I'm saying is that if a network administrator of your 
 > ISP configures a same prefix on 2 different link, you'll 
 > reach the closest one, or, if you're in the middle, you may 
 > end up reaching them alternatively. Shit happens, and the 
 > IGP in place does not prevent that at all.

=> Huh ?? It sounds like you're talking about anycast.
Please name one case where this can happen to unicast.
If this happens, then if Host_A tries to talk to Host_B
then sometimes it will end up talking to Host_C in the 
middle of the connection.

 > Maybe all this discussion is because of a misunderstanding 
 > in the initial statement. I have in mind a configuration 
 > where an MNP is co-owned by 2 MRs that share an ingress 
 > link. The set (MR1+ingresslink+MR2) moves together as a 
 > whole. They are an atomic system. Link a plane with a wire 
 > between the 2 MRs. Maybe for you the ingress link is a fixed 
 > AP, like a hotspot at a Café, in which case the connectivity 
 > between the 2 MRs would be occasional? In that case, giving 
 > those MRs a same MNP is a misconfiguration, of course. 

=> Again, I can't see any of this in the spec. I don't 
think it's unreasonable to expect the spec to clarify
this. This is something in your head and is not explained
anywhere. There is a BIG difference between fixed routers
using IGPs and MRs (in the general case). I know that
MRs can be fixed in relation to each other but I
don't expect everyone reading the spec to guess this.

 > Not because it's not agreed upon, because it's not 
 > normative. The text was judged complex and not part of the 
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^     
 > protocol. There was no specific behaviour associated to it...
   ^^^^^^^^
=> If you really believe the underlined text then why 
are you insisting on not making sure that it's explicily
stated in the spec that this is not supported by the protocol?

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 18 Mar 2004 06:10:04 -0500

^^^^^^^^

Hesham

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 18 Mar 2004 14:03:11 -0000

>  > > => There is never 2 HAs visible on the IP layer.
Still disagree, see later

>       be rectified. > 

I'm not sure about what you mean MIP is designed to do here. I see DHAAD as a potential way to load balance bindings between HAs. I believe that MIPv6 is meant for that (3rd bullet page 103 asks for an randomization that actively load balances BCEs over HAs of equal preference). When you have multiple HAs, it is most probable that overtime, the BCEs will be distributed somehow between the HAs of equal highest preference. If you disagree with this statement, I'd wish to discuss that on the MIP6 ML. If you agree with this statement, then you see how a binding for a same Home Address is accepted by the same HA and rejected by a second HA. 

> as planned. This goes for every protocol.
Sure. 
MRs with a same prefix and moving relatively to each other is a misconfiguration.
>From plain common sense, isn't it?
And yes, long as we're talking misconfiguration, I'm happy with the MIP6 protocol as it is, if there's a way to detect the situation and alert. Thus my proposal for an optional DND test for Nemo. But at the end of the day, your case B above applies to Nemo if the prefix is duplicated, "someone will complain and the misconfig will be rectified". So Nemo is nothing better or worse than MIP6 or IGPs, it inherits from them.

> But, if the MR moves this will cause problems. Do you agree
I meant as I said that the MR-link-MR is an atomic system moving together relative to the infrastructure. Like in a plane. And they MUST NOT split, otherwise I do agree it's a misconfiguration -or a very very specific trick-.

> this is an analogy to what we're talking about.

No, because the SA is associated to the Home Address. Nemo does not change MIP for this. The 2 MRs have 2 different Home Addresses. But The MNP is authorized for one or more Home Addresses. The 2 Home Addresses can be from the same MNP, but they should have different SAs.

> point me to a reference that an admin will read.

Can I say common sense? Part of the nemo way is to split the purely normative part (to become standard track) and the usage recommendations (aimed at informational) in separate drafts. I understand that you recommend a usage draft for Nemo multihoming. I do agree. Maybe it's a bit early because we are missing the full picture. But maybe also it's good to document what we already know...

> middle of the connection.

I was trying to say that IGPs do not generally include configuration error detection. And that it is already possible to misconfigure a network and cause such a situation that a subnetwork is seen at 2 different places, so Nemo is nothing new, and that does not mean that Nemo is incomplete. 

There are some rules and these rules are not necessarily enforced by the protocols. Rather, they are part of the know how of network designers. Duplication of a subnet is avoided in general, and can be done is very particular cases. And this happens outside of the scope of the IGP. This is a deployment issue.

> don't expect everyone reading the spec to guess this.

Well seems that the authors collectively guessed otherwise. Ubiquity of a prefix is a very specific thing. But then again, I'm not against a usage draft on multihoming that would word that giving how the protocol is expected to be used. We already did that for the home network configuration. That's part of the spirit.

>  > normative. The text was judged complex and not part of the
Well, I'm happy with the nemo text the way it stands. I agreed to remove the original text that said that nemo is open to multihoming. Because it is, even if you do not write it down. That's what I meant here. What's not part of the protocol was removed from the draft, but can be place in usage drafts.

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 18 Mar 2004 14:03:11 -0000

Sure. 

Pascal

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 18 Mar 2004 09:11:58 -0500

Pascal, 

I believe I answered your scenarios in the other email
(the last email I sent) which discussed the questions 
that need to be asked and how multihoming (for the 
scenarios you mentioned) can already be handled today
without any ambiguity. So I suggest that we take
it from there instead of arguing the points below.

As to the clarity of the spec, I don't think "it's
clear to the authors" is a good way to go. I sure
hope that every spec is clear to the authors! but
obviously that's not a benchmark. 

Hesham

 > From: Pascal Thubert (pthubert) [mailto:[email-masked]]
 > Sent: Thursday, March 18, 2004 9:03 AM
 > To: Soliman Hesham; Thierry Ernst
 > Cc: IETF NEMO WG
 > I'm not sure about what you mean MIP is designed to do here. 
 > I see DHAAD as a potential way to load balance bindings 
 > between HAs. I believe that MIPv6 is meant for that (3rd 
 > bullet page 103 asks for an randomization that actively load 
 > balances BCEs over HAs of equal preference). When you have 
 > multiple HAs, it is most probable that overtime, the BCEs 
 > will be distributed somehow between the HAs of equal highest 
 > preference. If you disagree with this statement, I'd wish to 
 > discuss that on the MIP6 ML. If you agree with this 
 > statement, then you see how a binding for a same Home 
 > Address is accepted by the same HA and rejected by a second HA. 
 > 
 > 
 > And yes, long as we're talking misconfiguration, I'm happy 
 > with the MIP6 protocol as it is, if there's a way to detect 
 > the situation and alert. Thus my proposal for an optional 
 > DND test for Nemo. But at the end of the day, your case B 
 > above applies to Nemo if the prefix is duplicated, "someone 
 > will complain and the misconfig will be rectified". So Nemo 
 > is nothing better or worse than MIP6 or IGPs, it inherits from them.
 > 
 > I meant as I said that the MR-link-MR is an atomic system 
 > moving together relative to the infrastructure. Like in a 
 > plane. And they MUST NOT split, otherwise I do agree it's a 
 > misconfiguration -or a very very specific trick-.
 > 
 > 
 > No, because the SA is associated to the Home Address. Nemo 
 > does not change MIP for this. The 2 MRs have 2 different 
 > Home Addresses. But The MNP is authorized for one or more 
 > Home Addresses. The 2 Home Addresses can be from the same 
 > MNP, but they should have different SAs.
 > 
 > > 
 > Can I say common sense? Part of the nemo way is to split the 
 > purely normative part (to become standard track) and the 
 > usage recommendations (aimed at informational) in separate 
 > drafts. I understand that you recommend a usage draft for 
 > Nemo multihoming. I do agree. Maybe it's a bit early because 
 > we are missing the full picture. But maybe also it's good to 
 > document what we already know...
 > 
 > > 
 > I was trying to say that IGPs do not generally include 
 > configuration error detection. And that it is already 
 > possible to misconfigure a network and cause such a 
 > situation that a subnetwork is seen at 2 different places, 
 > so Nemo is nothing new, and that does not mean that Nemo is 
 > incomplete. 
 > 
 > There are some rules and these rules are not necessarily 
 > enforced by the protocols. Rather, they are part of the know 
 > how of network designers. Duplication of a subnet is avoided 
 > in general, and can be done is very particular cases. And 
 > this happens outside of the scope of the IGP. This is a 
 > deployment issue.
 > 
 > > 
 > Well seems that the authors collectively guessed otherwise. 
 > Ubiquity of a prefix is a very specific thing. But then 
 > again, I'm not against a usage draft on multihoming that 
 > would word that giving how the protocol is expected to be 
 > used. We already did that for the home network 
 > configuration. That's part of the spirit.
 > 
 > > 
 > Well, I'm happy with the nemo text the way it stands. I 
 > agreed to remove the original text that said that nemo is 
 > open to multihoming. Because it is, even if you do not write 
 > it down. That's what I meant here. What's not part of the 
 > protocol was removed from the draft, but can be place in 
 > usage drafts.
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > Pascal
 >

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 18 Mar 2004 09:11:58 -0500

Pascal, 

Hesham