Re: [netext] Security question on anycast mode of draft-ietf-netext-redirect-01

[jouni korhonen <[e-mail]>]

Hi,

On May 7, 2010, at 10:46 AM, Xiaoyan Jiang wrote:

> 2010/5/7 jouni korhonen <[e-mail]>
> Hi,
> 
> On May 7, 2010, at 10:20 AM, Xiaoyan Jiang wrote:
> 
> > Hi   Jouni
> >
> > When there are multiple LMAs in the same PMIP damain, how are the LMAs associated with each other? And, from the MAG's perspective, what' s the difference between the LMAs?
> 
> Associated with each other? I don't really understand the question. Those LMAs are within the same Redirection Domain and under the same administration. This does not really differentiate from any anycast deployment.
> 
> Ok, I know, it is like the anycast deployment.
>  
> From a MAG point of view, when using anycast addressing, it sees no difference between LMAs. When runtime assignment takes place, the MAG learns the individual LMA that was picked up. The MAG will eventually have a separate SA with each individual LMA (either dynamically or manually established).
> 
> I mean when MAG selects LMA for MN to register, it just considers the load factor or there are other factors, such as the different LMA provides different service?

The MAG does not generally do such decision. The decision which LMA at the end gets assigned to the MAG (and the MN) takes place in the rfLMA. The only selection the MAG does is to located a LMA (actually a rfLMA in runtime LMA assignment scope) based on generic criteria such as provided services (see discussion around this in draft-ietf-netlmm-lma-discovery-03).

- Jouni



>   
> Xiaoyan Jiang
> 
> 
> - Jouni
> 
> >
> > Thank you!
> >
> > > o  LMAs with multiple IP addresses: a cluster of LMAs or a blade
> > >      architecture LMA may appear to the routing system as multiple LMAs
> > >     with separate unicast IP addresses.  A MAG can initially select
> > >      any of those LMA IP addresses as the LMA Address using e.g., DNS-
> > >      and AAA-based solutions.  However, MAG's initial selection may be
> > >      suboptimal from the LMA point of view and immediate redirection to
> > >      a "proper LMA" would be needed.  The LMA could use [RFC5142] based
> > >      approach but that would imply unnecessary setting up of a mobility
> > >      session in a "wrong LMA" with associated backend support system
> > >      interactions, involve additional signaling between the MAG and the
> > >      LMA, and re-establishing mobility session to the new LMA again
> > >      with associated signaling.
> >
> > Xiaoyan Jiang
> >
> 
>