Subject: [netext] FW: New Version Notification for draft-korhonen-netext-redirect-03

From: jouni korhonen <[email-masked]>
Date: Tue, 15 Sep 2009 10:24:12 +0300

FYI

We submitted an updated version of the Runtime LMA Assignment I-D a  
while ago. This revision should address the comments we received in  
Stockholm or at least add the basis for further work on those areas.

Cheers,
	Jouni

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: September 10, 2009 1:59:06 AM GMT+03:00
> To: [email-masked]
> Cc: [email-masked],[email-masked]
> Subject: New Version Notification for draft-korhonen-netext- 
> redirect-03
>
>
> A new version of I-D, draft-korhonen-netext-redirect-03.txt has been  
> successfuly submitted by Jouni Korhonen and posted to the IETF  
> repository.
>
> Filename:	 draft-korhonen-netext-redirect
> Revision:	 03
> Title:		 Runtime LMA Assignment Support for Proxy Mobile IPv6
> Creation_date:	 2009-09-10
> WG ID:		 Independent Submission
> Number_of_pages: 23
>
> Abstract:
> This document describes a redirect functionality and corresponding
> mobility options for Proxy Mobile IPv6.  The redirect functionality
> allows a dynamic runtime assignment of a Local Mobility Anchor and
> redirecting the mobility session to the assigned Local Mobility
> Anchor.
>
>
>
> The IETF Secretariat.
>
>

---

From: Yungui Wang <[email-masked]>
Date: Tue, 15 Sep 2009 16:33:56 +0800

Hello Jouni

It is observed that the assigned r2LMA would be stored/updated into the MN's
profile on the policy store. May I know when it happens and who does? 

B.R.
Yungui

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of jouni korhonen
> Sent: Tuesday, September 15, 2009 3:24 PM
> To: [email-masked]
> Subject: [netext] FW: New Version Notification 
> fordraft-korhonen-netext-redirect-03
> 
> FYI
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>

---

From: jouni korhonen <[email-masked]>
Date: Tue, 15 Sep 2009 13:11:00 +0300

Hi,

> profile on the policy store. May I know when it happens and who does?

Yes, r2LMA information would be stored into the policy profile. On the  
MAG side this would happen when the PBA containing the Redirect  
mobility option arrives. If the remote policy store needs to be  
updated, it would be done e.g. by r2LMA using the LMA-HAAA interface  
described in draft-ietf-dime-pmip6.

I will add some text to the I-D regarding the policy profile update.

Cheers,
	Jouni

---

From: Yungui Wang <[email-masked]>
Date: Wed, 16 Sep 2009 09:17:13 +0800

Hello

That's okey. There are other two minor comments. 

1, I think, the 'Redirect-Capability Mobility Option' is not essential. In
my understanding, the common MIP/PMIP system has provided the general
capability negotiation mechanism. That's, if there is an extended mobility
option is not supported or identified, the receiver can just discard it
silently. Isn't it? On the other side, even if the LMA doesn't return the
'Redirect Mobility Option', for implementation, the MAG which has enabled
the redirection function may re-register the MN to another LMA when it
receives a failed PBA, e.g. 130.
Therefore, for simplification, the capability option can be removed.

2, I can't catch the logic of SA check described in the section 5.3.2. (at
the 3th and 4th paragraph)
In my understanding, if there is no SA between the MAG and the r2LMA, how
can the r2LMA accept the PBU and create the mobility session at before? On
the other hand, the SA check is necessary to another case described in 5.4.
However, I don't see how the MAG does that. Are there some local policies on
the MAG, or does the MAG check it according to the MN's profile downloaded
from policy store, or ...?

B.R.
Yungui

> From: jouni korhonen [mailto:[email-masked]] 
> Sent: Tuesday, September 15, 2009 6:11 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [netext] FW: New Version Notification 
> > It is observed that the assigned r2LMA would be 
> stored/updated into  
> > the MN's

---

From: jouni korhonen <[email-masked]>
Date: Wed, 16 Sep 2009 08:53:47 +0300

Hi,

Thanks for feedback. See some answers inline.

> capability negotiation mechanism. That's, if there is an extended  

By common capability negotiation mechanism do you mean flags in PBU/ 
PBA headers? If so, it was a design choice not to allocate more of  
those.

> silently. Isn't it? On the other side, even if the LMA doesn't  

The current design makes use of this behavior that LMAs silently  
ignore mobility options they do not understand. In that way a MAG  
supporting redirection and a LMA not supporting redirection can  
fallback to RFC5213 normal operation.

> receives a failed PBA, e.g. 130.

This is of course possible already within RFC5213 scope but that is a  
MAG implementation specific fallback operation rather than a guided  
redirection.

> Therefore, for simplification, the capability option can be removed.

Hmmm.. I don't fully agree with this. The Redirect-Capability option  
is also used as an indication from a MAG if it wants to be redirected  
or not. Also we currently embed IPv4 information on that option. Of  
course this could be achieved with PBU/PBA flags but so far I am not  
convinced that those would be better than using a mobility option.

> can the r2LMA accept the PBU and create the mobility session at  

Good point. This is an obvious error and needs to be fixed.

> from policy store, or ...?

The MAG is supposed to know with whom it has SAs with by  
configuration. That would be a normal SAD/SPD lookup. If none of the  
existing SAs match, then either the PBU/PBA exchange fails or the  
dynamic creation of the SA is initiated.

Cheers,
	Jouni

---

From: Yungui Wang <[email-masked]>
Date: Wed, 16 Sep 2009 16:12:16 +0800

Hello 

> is also used as an indication from a MAG if it wants to be 
> redirected  or not. 

I am confused about that. In my mind, the Capability option is just used to
tell the rfLMA by the MAG that 'supports' the following 'Redirect mobility
option'. Isn't it? The motivation that the rfLMA decides to redirect the
session should be dependent on the blade architecture or the rfLMA self's
load, etc. as described in the section 1. I don't think the Capability
option will affect its motivation. At this point, the Capability option is
actually useless for the rfLMA. Hence, the MAG doesn't need to tell it to
the rfLMA. 

> Also we currently embed IPv4 information on that option. 
> Of course this could be achieved with PBU/PBA flags but so far I am not  

Please see above. No flags needed too.

> Good point. This is an obvious error and needs to be fixed.

That's Okey.

> 
> > the other hand, the SA check is necessary to another case 
> described  
> > in 5.4.

Please see the detailed use case. 
In my understanding, there are three sets of LMA addresses on the MAG. The
first (set_A) is coming from local configuration independent from the
individual MN. The second (set_B) is for the special MN, e.g. acheived by
draft-ietf-netlmm-lma-discovery mechanism. The third (set_C) is provided by
this draft.
You said configuration check seems a little ambiguous. I wonder if the MAG
checks that the set_C belongs to both set_A and set_B.  

B.R.
Yungui

---

From: jouni korhonen <[email-masked]>
Date: Wed, 16 Sep 2009 12:34:09 +0300

Hi,

> option'. Isn't it? The motivation that the rfLMA decides to redirect  

So you agree the Redirect-Capability option is ok for indicating  
redirection support.

> actually useless for the rfLMA. Hence, the MAG doesn't need to tell  

The rfLMA won't even try to do the redirection unless the MAG  
expresses its capability for it. In Section 3 we mandate that MAG-LMA  
do not "remember" the prior redirection capability indications. That  
allows e.g. the MAG to prohibit midsession redirections.

The other reason is to get the same behavior of the protocol whether a  
MAG supports redirection or not. A MAG should never be redirected if  
it does not support the feature where as a LMA does. Therefore, the  
redirection may only be triggered when a MAG so indicates.

> checks that the set_C belongs to both set_A and set_B.

I see your point. We can clarify this for sure. The check is against  
SAs, not address set_[AB]. At the end, SAs must be configured for all  
set_[ABC] addresses for the protocol to succeed. I am not sure whether  
we should mandate anything there other than saying that SAs must be in  
place.

Cheers,
	Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 16 Sep 2009 09:17:28 -0700 (PDT)

Hi Jouni,
  I noticed that you defined:

Redirect-Capability Mobility Option
such an option to me seems more like AAA issue and as such it should go to dime or radext.
In RFC 5213, PCOs are defined such as 

EnableMAGLocalRouting
for similar purposes.

Regards,

Behcet
----- Original Message ----
> From: jouni korhonen <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Wednesday, September 16, 2009 12:53:47 AM
> Subject: Re: [netext] FW: New Version Notification fordraft-korhonen-netext-redirect-03
> 
> Hi,
> 
> By common capability negotiation mechanism do you mean flags in PBU/PBA headers? 
> If so, it was a design choice not to allocate more of those.
> 
> The current design makes use of this behavior that LMAs silently ignore mobility 
> options they do not understand. In that way a MAG supporting redirection and a 
> LMA not supporting redirection can fallback to RFC5213 normal operation.
> 
> This is of course possible already within RFC5213 scope but that is a MAG 
> implementation specific fallback operation rather than a guided redirection.
> 
> Hmmm.. I don't fully agree with this. The Redirect-Capability option is also 
> used as an indication from a MAG if it wants to be redirected or not. Also we 
> currently embed IPv4 information on that option. Of course this could be 
> achieved with PBU/PBA flags but so far I am not convinced that those would be 
> better than using a mobility option.
> 
> > 
> The MAG is supposed to know with whom it has SAs with by configuration. That 
> would be a normal SAD/SPD lookup. If none of the existing SAs match, then either 
> the PBU/PBA exchange fails or the dynamic creation of the SA is initiated.
> 
> 
> Cheers,
>     Jouni
> 
> > 
> > B.R.
> > Yungui
> > 
> >>>>> From: IETF I-D Submission Tool

---

From: Yungui Wang <[email-masked]>
Date: Thu, 17 Sep 2009 09:54:19 +0800

Hello

> So you agree the Redirect-Capability option is ok for indicating  

Agree. But I don't think it is useful for the rfLMA and the MAG. 
For the rfLMA, please see below.
For the MAG, as I said in the previous mail, the MIP/PMIP protocol has
addressed that new mobility option (here is the Redirect option) can be
silently droped by the receiver.

> > actually useless for the rfLMA. Hence, the MAG doesn't need 
> to tell  
> > it to
> > the rfLMA.
> 
> expresses its capability for it. 

Here I still don't understand what's the motivation of the rfLMA doing
redirection. As you described, it seems that the rfLMA does redirect just
because of the MAG supports it.
In my mind, as described in section 1 of the draft, for example, if a load
balancer acting as the rfLMA is located in the PMIPv6 system, the depolyment
has decided what it can do is redirection. It doesn't need the Capability
indication.
Another case, for example, if the rfLMA is overloaded, it may do redirect
too.

> In Section 3 we mandate that MAG-LMA  
> it does not support the feature where as a LMA does. 

I don't think that is useful/essential. Without the Capability indication,
the rfLMA still has to return the failed PBA in the certaion situations.

> SAs, not address set_[AB]. At the end, SAs must be configured 
> for all set_[ABC] addresses for the protocol to succeed. 

Agree.

> I am not sure whether  
> we should mandate anything there other than saying that SAs 
> must be in place.
> 

It is easily convinced that the set_C always belongs to set_A. However, it
may be possible that the set_C doesn't belong to set_B. Hence, there may
exsit some issues.

B.R.
Yungui