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

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

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

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

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

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

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

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

>
> Hope this helps.

Thanks. It always does.

Jouni

>
> Vijay
>
>
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext