Re: [netext] FW: New Version Notification fordraft-korhonen-netext-redirect-03

[Yungui Wang <w52006 at huawei.com>]

Hello

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

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.

> > 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.
> 
> The rfLMA won't even try to do the redirection unless the MAG  
> 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  
> 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. 

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.

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

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