Subject: [netext] Comments on draft-korhonen-netext-redirect

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 29 Jul 2009 12:00:03 -0700

Hello,

I have a few comments on the runtime LMA assignment functionality.

- I am not comfortable with the second solution, the one where the first LMA
just forwards the PBU to the second LMA and the response comes back from the
second LMA. Anwyay, we SHOULD NOT have two solutions. We should pick one.
The proxied one is better.

Have you guys also considered a solution where the PBA comes back from the
first LMA with the redirect mobility option, and then the MAG sends a PBU to
the second LMA? This would involve an additional round trip, but is a much
simpler solution that does not involve forwarding or proxying of the PBU
between the LMAs. Since this additional round trip is during the initial
session setup, I don't think it is a big deal

- I think the draft should be extended to also address LMA-initiated
redirect. Not just redirects when the MAG sends a PBU. This would be a
mid-session redirect. You would need a new mobility header message from the
LMA to the MAG to do this redirect. One option would be to re-use the HA
Switch Message from RFC 5142 and carry the redirect mobility option in this
message. This would avoid defining a new message.

I can provide some text on LMA-initiated redirect if you want.

- I would like to see the following paragraph expanded as per the previous
conference call we had with the chairs, Jonne and Jari. :)

   In case of
   load balancing, the runtime assignment approach is just one
   implementation option.  MAGs and LMAs can implement other solutions
   that are, for example, completely transparent at PMIPv6 protocol
   level and do not depend on the functionality defined in this
   specification.

It needs to say that there are implementations where the multiple
application blades in a chassis are visible to the external networks as one
LMA with one IP address. The load balancing between these application blades
is done transparently without having to redirect the MAG to another LMA.

- You should also highlight the fact that the IKEv2 redirect mechanism
(draft-ietf-ipsecme-ikev2-redirect-11.txt) is not sufficient here. It is
good enough for Mobile IPv6, but not for PMIPv6, since IKEv2 is not run
between the MAG and the LMA for every session setup. Just once, with the
same IPsec SA re-used for all mobility session setups. This is just to avoid
questions later in the standardization phase when folks ask you why the
IKEv2 redirect mechanisms cannot be used. As I understand it, the default
redirect mechanism for Mobile IPv6 in 3GPP specs is the IKEv2 redirect
mechanism.

Hope this helps.

Vijay

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 30 Jul 2009 10:03:11 +0800

Hi Vijay,

I'm sorry for jumping into the discussion.

> session setup, I don't think it is a big deal

I very agree with you and I have submitted a draft about this solution.
http://tools.ietf.org/html/draft-cui-netext-lma-redirection-solution-00

Because I missed the deadline, I failed to request a slot for this draft.

Regards

Xiangsong

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Jouni Korhonen" <[email-masked]>; "Sri Gundavelli (sgundave)" 
<[email-masked]>; "Hidetoshi Yokota" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 30, 2009 3:00 AM
Subject: [netext] Comments on draft-korhonen-netext-redirect

> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: jouni korhonen <[email-masked]>
Date: Thu, 30 Jul 2009 11:29:29 +0300

Hi Vijay,

> The proxied one is better.

If you check the presentation material I have provided, it should  
answer this ;)

> session setup, I don't think it is a big deal

We have considered it (for real, I even wrote a version of draft -00  
with that approach) but chose not to go with an additional roundtrip  
at the end.

> message. This would avoid defining a new message.

Currently I am not too enthusiast of LMA initiated explicit mid- 
session LMA reassignment. If we were to proceed to that direction,  
RFC5142 could be adjusted for it. I would avoid defining any new  
messages.

> conference call we had with the chairs, Jonne and Jari. :)

I should remind that, for an unknown reason to me, I was not part of  
that call. Therefore, I generally feel uncomfortable referring it as a  
common agreement to scope my document. We can discuss this, no problem  
with that.

> is done transparently without having to redirect the MAG to another  

And the above existing text is not enough to apply for this case? I  
think it is.

> (draft-ietf-ipsecme-ikev2-redirect-11.txt) is not sufficient here.  

We don't reference to the above draft in our document, so I don't  
understand the dependency.

> redirect mechanism for Mobile IPv6 in 3GPP specs is the IKEv2 redirect

Hmm, right. Current text says that the SAs with r2LMAs and rfLMAs must  
have been setup in advance. The text could be more explicit here and  
more verbal on the background assumptions & issues regarding the SAs.

> Hope this helps.

Thanks. It always does.

Jouni

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 30 Jul 2009 09:36:54 -0700

Hi Jouni,

> If you check the presentation material I have provided, it should

Ok, cool.
 
> with that approach) but chose not to go with an additional roundtrip

Hmm... I still think it would be lot simpler to just redirect the MAG to the
new LMA. Proxying the PBU obviously is a bit tricky. Does the first LMA
replace the destination address of the PBU with the new LMA's IP address? Or
does the first LMA append some sort of information to the proxied PBU? Will
the hop count get incremented? We probably need some more information on how
the proxied PBU looks like.

> RFC5142 could be adjusted for it. I would avoid defining any new

Well, we do have a mechanism currently for MIPv6 and PMIPv6 to redirect the
MN/MAG to another HA/LMA in the middle of a session. It is a Proposed
Standard. It would be good, if that mechanism is consistent with the runtime
assignment of the LMA. It would be a bad idea to have two different sets of
mechanisms.

Or are you saying that the LMA initiated mid session redirect does not have
any use cases?
 
> common agreement to scope my document. We can discuss this, no problem

Jouni, I sent the comments assuming your document is going to become the WG
document soon. You are of course free to have whatever text you want in your
document. :)

BTW, that call was about adding the LMA redirect to the NETEXT charter. If
you remember, there was no time for discussing this during the BoF. There
was a 2 min presentation followed by 30 seconds time at the mic. I had some
concerns. The redirect item was not amount the list of items originally
proposed for the NETEXT charter. This call was about discussing my concerns
before adding the item to the NETEXT charter. We weren't discussing a
specific draft.

And after the call, I updated you on what was discussed.

If you prefer, I can bring this up during the consensus call for adopting
the document then.
 
> And the above existing text is not enough to apply for this case? I

Not really. Runtime LMA assignment can be done transparently among multiple
application blades without any external node knowing about it. It is
actually a solution for the problem we are trying to address. I can provide
the text if you want.

> understand the dependency.

I was trying to say that the IKEv2 redirect has become the default redirect
mechanism for MIPv6. So there might questions later on on why that is not
sufficient for PMIPv6 too. So adding some text that says it is not really
application, because IKEv2 is not run between the MAG and the LMA for every
session setup, would be good.

> more verbal on the background assumptions & issues regarding the SAs.

Ok.

Vijay

---

From: jouni korhonen <[email-masked]>
Date: Thu, 30 Jul 2009 20:24:58 +0300

Hi Vijay,

On Jul 30, 2009, at 7:36 PM, Vijay Devarapalli wrote:

[snipeti-snap]

> the proxied PBU looks like.

These are good questions. I would still argue that what happens  
between the rfLMA and the r2LMA in this particular scenario is  
internal to the "LMA system". However, I do not mind describing a  
possible solution approach or two, especially if it makes things  
clearer for other folks.

> Or are you saying that the LMA initiated mid session redirect does  

I am not saying it does not have use cases. However, I could argue the  
mid-session redirect would be far far less probable to happen than  
during the initial PBU/PBA exchange. And the mid-session redirect is  
not trivial, unless we can state that there is no need to preserve the  
HNP.

> document soon. You are of course free to have whatever text you want  

Ah, well that is what I hope too ;)

> you remember, there was no time for discussing this during the BoF.  

Well, I was not there. I was using my proxy while handing off to other  
continent. Anyway, got your point.

> If you prefer, I can bring this up during the consensus call for  

Heh ;)

> application blades without any external node knowing about it. It is

Sure. One can do it transparently. We specifically do not want  
complete transparency, thus these modifications to the base protocol.

> actually a solution for the problem we are trying to address. I can  

Sure, go ahead.

> session setup, would be good.

Right, good point. Will add this.

>> more verbal on the background assumptions & issues regarding the SAs.

Cheers,
	Jouni

[snapeti-snip]