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

Hi Jouni,

On 7/30/09 1:29 AM, "jouni korhonen" wrote:

> Hi Vijay,
> 
> On Jul 29, 2009, at 10:00 PM, Vijay Devarapalli wrote:
> 
>> 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.
> 
> If you check the presentation material I have provided, it should
> answer this ;)

Ok, cool.

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

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.

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

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?

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

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.

>>   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.
> 
> And the above existing text is not enough to apply for this case? I
> think it is.

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.

>> - You should also highlight the fact that the IKEv2 redirect mechanism
>> (draft-ietf-ipsecme-ikev2-redirect-11.txt) is not sufficient here.
>> It is
> 
> We don't reference to the above draft in our document, so I don't
> 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.

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

Ok.

Vijay

> 
>> 
>> Hope this helps.
> 
> Thanks. It always does.
> 
> Jouni
> 
> 
> 
>> 
>> Vijay
>> 
>> 
>> _______________________________________________
>> netext mailing list
>> netext@ietf.org
>> https://www.ietf.org/mailman/listinfo/netext
> 