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

[jouni korhonen <[e-mail]>]

Hi Vijay,

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

[snipeti-snap]

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

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.

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


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

Ah, well that is what I hope too ;)

> 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

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


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

Heh ;)

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

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  
> provide
> the text if you want.

Sure, go ahead.

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

Right, good point. Will add this.


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

Cheers,
	Jouni


[snapeti-snip]