Re: [netext] multi-LMA : how to handle

["Mohana Jeyatharan" <[e-mail]>]

Hi Marco,

Thanks for reply.  Please see some replies in-line.

BR,
Mohana
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
Behalf
> Of Marco Liebsch
> Sent: Wednesday, November 25, 2009 7:08 PM
> To: Mohana Jeyatharan
> Cc: [e-mail]
> Subject: Re: [netext] multi-LMA : how to handle
> 
> Hi Mohana,
> 
> please see in-line for my answer to your question.
> 
> Mohana Jeyatharan wrote:
> > Hi Qin, Marco and all,
> >
> > Have been following the thread and I have one clarifying question.
> > In the multi LMA scenario that is being discussed, is CN.LMA
involved
> > during every handoff event in identifying the CN.MAG address and
> > informing to Mn's MAG?
> >
> Without pointing to a particular solution but arguing more general, I
> think
> the LMAs should be involved and have mayor control in setting up as
> well as in maintaining the localized routing states on the MAG, as
they
> are the only common nodes (common on a per MN basis) which have the
> most up to date location information about the MN and the CN
respectively.
> This is LMA1 for MN and LMA2 for CN.

[Mohana] I agree that setting up routing states, LMA has important role.
But I am not so convinced about the involvement of LMA in maintaining
routing states (handoff case). Bcos after local MAG RO is set up,
packets don't pass through LMA and local mechanims such CTX can be used
to handle RO.  Ofcourse if CTX is not used for some reason(operator
choice) then perhaps LMA control even during handoff (as you propose)
can be used.  Another point is LMA need not unnecessarily keep state for
local MAG RO. If MN MAG and CN MAG are quite close, then involving LMA
which can even be in another administrative domain can delay the local
MAG path setup especially when you have on going session as in the
handoff case.  Anyway, I am not saying that LMA involvement should not
be there. It all depends.

Another scenario is where MN LMA and CN LMA do not have trust. Then what
mechanism can be used to set up localized routing? I guess currently
such scenario is out of scope of the discussion.  

> > If AAA is used as a common trusted entity in identfying CN.LMA
address
> > and also helping in creating SA between Mn'MAG and CN'LMA, I am just
> > wondering whether AAA can be used to tell MN's MAG that it owns this
> > prefix(Mn prefix) and CN's MAG that it own the prefix(CN prefix) and
> > when bi-directional tunnels are setup between MAG using PBU/PBA such
> > validation fron AAA can be used to create the routing states at MN's
MAG
> > and CN's MAG.  Bcos in the multi LMA scenario, AAA will perhaps be
the
> > common trusted entity.
> >
> I do not think that the AAA should be used as mobility anchor, even
though
> the AAA might have information about mobility related states. For
sure,
> he'll have
> information about each MN's assigned LMA. So, I think the AAA *could*
> be used to find the MN's and the CN's LMA once during the setup of a
> localized routing path. After the setup, LMA1 and LMA2 should be
known.
> And I do not think that the localized routing solution should be
> dependent on the AAA server, hence the solution should work without
> any AAA infrastructure at all.

[Mohana] Ok. Since AAA was discussed I was thinking more along this
line.  If LMA1 (MN LMA)and LMA2 (CN LMA) have trust then no need of a
common trusted anchor.  But if they are not then was wondering whether
we need a common trusted anchor to securly establish local MAG RO.
Perhaps we can keep the scenario where there is loose trust between LMAs
out of discussion for now as I mentioned previously.

> > Just wondering whethe r CN.LMA needs to be involved during handoff
> > process or CTX and such prefix validation from a common trusted
entity
> > (AAA) between LMA1 and LMA2 can be used in setting up the MAG to MAG
RO
> > path.  If LMA is configured as the initiator of MAG to MAG RO, then
> > MN.MAG and CN.LMA association may be needed but if MAG is the
initiator
> > of RO then perhaps this can be avoided in the handoff case.
> >
> both LMAs should be involved as they do not change and they have the
> most recent location information. However, as we propose, even though
> both LMAs are involved in the signaling, one LMA should have the
> control (e.g. LMA2). Then the maintenance during handover cannot run
> into a deadlock situation and the solution does not need the AAA
server
> as common anchor.
> > Also I have few general opinions on MAG initiated RO or LMA
initiated
> > RO.
> > Definitely as folks have discussed and identified, LMA is definitely
> > used in detection of CN.MAG and aid in establishing RO, but MAG can
be
> > initiator of local MAG RO eventhough MN and CN are not attached to
the
> > same MAG.  Perhaps the MAG is informed of CN addresses by MN using
some
> > L2 mechanism and hence it can initiate RO for a bunch of CNs
> > simultaneously.
> I don't think you need L2 here, as a data packet from MN to CN, which
> is forwarded by the MN's MAG, carries the CN's IP address.
> Or did I misunderstand your proposal?
> 
> >  Thus LMA need not wait for session to be started
> > between every MN and each CN to establish the RO.
> >
> Ah, maybe now I get your point. You propose to set up a localized
> routing path between the MN and a set of potential CNs before
> data will be sent, right?

[Mohana] Yes.

 I think an important question to answer here
> is how long localized routing states will be kept alive? Our current
view
> (and implementation) sets localized routing states up when the're
needed
> (when data is sent). They are removed when a session terminates, say
> after a timeout in case no further data packets reset the timer. These
> states are rather soft-states. 

[Mohana] My thinking was to setup states if the MAG thinks that
communication with certain CNs need to be optimized. Based on
application or the type of service domain in which CN is placed the MAG
may initiate such local rotuing request.  Ofcourse once the session is
complete the local MAG RO can be torn down.  Suppose you are frequently
communicating with such CNs then local MAG RO states can be kept for a
long time.

If you set them up before there is data,
> I am wondering when you delete them again? And how should the
> MN decide if a localized route to CN1, CN2, etc makes sense? Their
> location is transparent to the MN. 

[Mohana] are you refering to CNs placed in another provider domain with
repect to MN.  In such a case, probably localized routing is not
essential.  MN's MAG does not know anything about where CN is.  It just
wants RO based on some information given to CN.  In such a case LMA
needs to assist.  Anyway as all of us have agreed LMA definitely needs
to play its role in supporting local MAG RO.

Thanks.
What do you think?
> 
> marco
> 
> 
> 
> >
> > Thanks.
> >
> > BR,
> > Mohana
> >
> >
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> >>
> > Behalf
> >
> >> Of Qin Wu
> >> Sent: Wednesday, November 25, 2009 4:44 PM
> >> To: Marco Liebsch
> >> Cc: [e-mail]
> >> Subject: Re: [netext] multi-LMA : how to handle
> >>
> >> Hi, Marco:
> >> please see my comments inline.
> >>
> >> Regards!
> >> -Qin
> >> ----- Original Message -----
> >> From: "Marco Liebsch" <[e-mail]>
> >> To: "Qin Wu" <[e-mail]>
> >> Cc: <[e-mail]>
> >> Sent: Tuesday, November 24, 2009 7:21 PM
> >> Subject: Re: [netext] multi-LMA : how to handle
> >>
> >>
> >>
> >>> Hi Qin,
> >>>
> >>> please see inline for brief comments.
> >>>
> >>> Qin Wu wrote:
> >>>
> >>>> Hi, Marco:
> >>>> Thank for your reply, please see my comments inline.
> >>>>
> >>>> Regards!
> >>>> -Qin
> >>>> ----- Original Message -----
> >>>> From: "Marco Liebsch" <[e-mail]>
> >>>> To: "Qin Wu" <[e-mail]>
> >>>> Cc: <[e-mail]>
> >>>> Sent: Monday, November 23, 2009 5:46 PM
> >>>> Subject: Re: [netext] multi-LMA : how to handle
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> Hi Qin,
> >>>>>
> >>>>> please find my comments inline.
> >>>>>
> >>>>> Qin Wu wrote:
> >>>>>
> >>>>>
> >>>>>> Hi, Marco:
> >>>>>> Thank for your raising discussion on Multi-LMA issue.
> >>>>>> Please see my comments inline!
> >>>>>>
> >>>>>> Regards!
> >>>>>> -Qin
> >>>>>> ----- Original Message -----
> >>>>>> From: "Marco Liebsch" <[e-mail]>
> >>>>>> To: <[e-mail]>
> >>>>>> Sent: Friday, November 20, 2009 5:44 PM
> >>>>>> Subject: [netext] multi-LMA : how to handle
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Folks,
> >>>>>>>
> >>>>>>> as a follow up of our discussion about localized routing in a
> >>>>>>> multi-LMA setup, I'd like to initiate a general and clarifying
> >>>>>>> discussion about signaling paths to set up and maintain a
> >>>>>>> localized routing path, as current solution proposals cover
> >>>>>>> different approaches.
> >>>>>>>
> >>>>>>> We had the discussion about PMIPv6 domains vs provider domains
> >>>>>>> and came to the conclusion that it's not mandatory for MN and
CN
> >>>>>>> to share the same PMIPv6 domain.
> >>>>>>>
> >>>>>>> Assume MN connects to MAG1 and LMA1, whereas CN connects
> >>>>>>> to MAG2 and LMA2. MAG1 shares a PMIP domain with LMA1
> >>>>>>> and MAG2 shares a PMIP domain with LMA2. We cannot assume
> >>>>>>> that MAG1 shares a PMIP domain with LMA2.
> >>>>>>>
> >>>>>>> Now, there are two questions to solve:
> >>>>>>> (1) Who detects and initiates localized routing, MAG or LMA
> >>>>>>>
> >>>>>>>
> >>>>
> >>>>>> [Qin]: I think Both have its value and are applicable to
> >>>>>>
> > different
> >
> >> scenarios. Whether using MAG initiated or using LMA initiated
depends
> >>
> > on
> >
> >>>>>> who detects localized routing, in other words, if MAG detects
> >>>>>>
> > local
> >
> >> routing is possible, then MAG initiated is more appropriate.
> >>
> >>>>>> e.g., As described in RFC5213, in the scenario where MN and CN
> >>>>>>
> > attach
> >
> >> to the same MAG, MAG initiated local routing can
> >>
> >>>>>> be used to negotiate with LMA and enfoce local routing on the
> >>>>>>
> > MAG.
> >
> >>>>
> >>>>> Only in single MAG case it may make sense that the MAG detects
and
> >>>>> establishes
> >>>>> a localized route. However, even in such case, the LMA must
> >>>>>
> >> control/enforce
> >>
> >>>>> the setup of the localized route as per RFC5213. So, the LMA
> >>>>> is the point of control and my personal opinion is that this is
> >>>>> reasonable, as the
> >>>>> LMA maintains states beyond a single MAG. And, dependent on the
> >>>>>
> >> mechanism
> >>
> >>>>> behind HNP assignment (address pools, delegation, ...), the LMA
> >>>>>
> > may
> >
> >> know if
> >>
> >>>>> the setup of a localized route is useful (in case CN is local)
or
> >>>>>
> > not.
> >
> >>>> [Qin]: Right, single MAG case is more appropirate to apply MAG
> >>>>
> >> initiated local routing. Also single MAG case can be divided into
two
> >>
> > sub
> >
> >> cases: i.e.,A11 and A12 described in the PS draft. These two sub
cases
> >> should be taken care in the solution draft.
> >>
> >>>> On the other hand, I agree LMA control the setup of localized
> >>>>
> > routing,
> >
> >> but it seems to me who initiate localized routing does not depend
on
> >>
> > who
> >
> >> control  the setup of the localized route. In the MAG initiate
> >>
> > localized
> >
> >> routing, MAG can initiate local routing with LMA to see whether
> >>
> > localized
> >
> >> routing is available.
> >>
> >>> yes, we can have 3 different ways to do this:
> >>> (1) MAG1 detects and requests LMA1 to set up localized routes
> >>> (2) MAG1 detects and requests LMA2 to set up localized routes
> >>> (3) LMA1 detects and sets up localized routes
> >>>
> >> [Qin]: Okay.
> >>
> >>>>
> >>>>>> If LMA is responsible for local routing, then LMA inititated
and
> >>>>>>
> > MAG
> >
> >> initiate both can be used.
> >>
> >>>>>> e.g., in the scenario where MN and CN attach to the different
> >>>>>>
> > MAGs
> >
> >> but connect to the different LMA or the same LMA.
> >>
> >>>>>>
> >>>>> Since the LMA needs to enforce localized routing in all cases, I
> >>>>> personally see the
> >>>>> LMA as detector.
> >>>>>
> >>>>>
> >>>> [Qin]: Okay.
> >>>>
> >>>>
> >>>>
> >>>>> If for some reason the MAG may be able to detect, it should
> >>>>> inform the LMA of the attached MN to enforce localized routing.
> >>>>>
> >>>>>
> >>>> [Qin]: I agee.
> >>>>
> >>>>
> >>>>
> >>>>>>> (2) How to synchronize distributed states? Will LMA1 contact
> >>>>>>> LMA2 or will MAG1 contact LMA2
> >>>>>>>
> >>>>>>> If an existing SA is the only indicator to set up a PMIPv6
> >>>>>>> domain, then one solution could be to set up an SA dynamically
> >>>>>>> between MAG1 and LMA2, which needs to be re-done every time
> >>>>>>> MN1 performs a handover to a different MAG, say MAG1*. This
> >>>>>>> may be a disadvantage and will blow up PMIPv6 domains, which
> >>>>>>> are rather administratively configured, in my opinion.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> [Qin]: It seems to me SA setup each time MN handover to the new
> >>>>>>
> > MAG
> >
> >> is one generic issue we should face for all the Multi-LMA cases.
> >>
> >>>>>> In other words,When using LMA1 to signal with LMA2 for states
> >>>>>>
> >> synchroizing, it has the same problem. Suppose MN connect to the
LMA1,
> >>
> >>>>>> each time the MN handover from previous MAG  to the new MAG,
the
> >>>>>>
> > new
> >
> >> MAG needs to setup SA with the LMA1 dynamically again.
> >>
> >>>>>>
> >>>>> there is a big difference between localized routing associations
> >>>>>
> >> between
> >>
> >>>>> MAGs
> >>>>> and handover between MAGs.
> >>>>>
> >>>>>
> >>>> [Qin]: No doubt to this.
> >>>>
> >>>>
> >>>>
> >>>>> Handover is between globally adjacent ARs/MAGs, hence, I think
an
> >>>>>
> > LMA
> >
> >>>>> maintains an SA with an MN's MAG and potential handover targets.
> >>>>>
> >>>>>
> >>>> [Qin]: How?  You can not predict the direction of MN's movement,
> >>>>
> > i.e.,
> >
> >> to which MAG the MN will move. Therefore
> >>
> >>>> you can not expect there is an SA between LMA and handover
targets
> >>>>
> >> beforehand.
> >>
> >>> well, don't confuse SA with forwarding tunnel. The SAs between MAG
> >>>
> > and a
> >
> >>> particular LMA
> >>> should be pre-established when the MN arrives, whereas the
> >>>
> > forwarding
> >
> >>> tunnel may exist
> >>> or may be set up dynamically when the MN arrives.
> >>>
> >> [Qin]: I agree SA and forwarding tunnel are two different things.
But
> >>
> > the
> >
> >> common aspect of both is
> >> SA and forwarding tunnel for one MN can be reused by the other MN
who
> >> arrives at the same MAG
> >> and routes the packet  to the same tunnel end point, i.e., LMA.
Right?
> >>
> >>
> >>>>> If you
> >>>>> would establish them each time a handover occurs, this would
have
> >>>>>
> >> impact
> >>
> >>>>> to the handover latency. Don't think this is how PMIP is
deployed.
> >>>>>
> >>>>>
> >>>> [Qin] As I said in the previous mail, the possible way to fix
this
> >>>>
> >> issue is
> >>
> >>>> SA or tunnel setup for the first MN between MAG and LMA can be
> >>>>
> > shared
> >
> >>>> by the other MNs who are attaching to the same MAG and register
to
> >>>>
> > the
> >
> >> same LMA as the first MN.
> >>
> >>> I understood your point, but I do not agree :-) I do not think
that
> >>>
> > a
> >
> >>> MAG should establish an SA
> >>> with any LMA dynamically when the MN arrives, in particular not
with
> >>>
> > an
> >
> >>> LMA which does not
> >>> serve the MN but the CN.
> >>>
> >> [Qin]: It seem to me it does not matther whether SA is
pre-established
> >>
> > or
> >
> >> dynamically established.
> >> The key point is whether SA can be shared by all the MNs who are
using
> >>
> > the
> >
> >> same path between MAG and LMA.
> >>
> >>
> >>>> that is to say, the SA or tunnel between MAG and LMA is not
per-MN
> >>>>
> > or
> >
> >> per-CN and can be reused
> >>
> >>>> by all the MNs and CNs upon it is setup at the first time.
> >>>> In this sense, it avoid establishing SA each time a handover
> >>>>
> > occurs.
> >
> >>>> If this is true, SA between MN's MAG(MAG1) and CN's LMA(LMA2) is
> >>>>
> > not
> >
> >> neccessary to be established
> >>
> >>>> again if SA between MAG1 and LMA2 has already been setup.
> >>>>
> >>>>
> >>>>
> >>>>> Now,
> >>>>> localized routing between MN and CN could mean that MN's MAG and
> >>>>>
> > CN's
> >
> >>>>> MAG are pretty far apart.
> >>>>>
> >>>>>
> >>>> [Qin] As described in PS draft, We should limit MN's MAG and CN's
> >>>>
> > MAG
> >
> >> within the same domain, am I right?
> >>
> >>> Even if they are in one provider domain, distance between MAGs can
> >>>
> > be
> >
> >>> huge. Multiple LMAs may
> >>> be used by the provider to distribute load and to be responsible
for
> >>>
> > a
> >
> >>> smaller region (subset of MAGs).
> >>>
> >> [Qin]: To me, the physical distance is not big issue. The more
> >>
> > important
> >
> >> thing is whether communication between MAGs is within the
> >> same provider domain or acrosss provider domain.
> >>
> >>
> >>>>> Different LMAs could serve different PMIPv6
> >>>>> domains. I don't think it's reasonable to merge these PMIP
domains
> >>>>> dynamically by means of establishing an SA between MN's MAG and
> >>>>> CN's LMA.
> >>>>>
> >>>>>
> >>>> [Qin]: Same as above.
> >>>>
> >>>>
> >>>>
> >>>>> Rather LMAs could take care about the setup of the route
> >>>>> between these MAGs. If both LMAs are in different PMIP domains
> >>>>> but in the same provider network, such signaling is simple.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> From the other aspect, in the Multi-LMA scenario, when MAG1
talks
> >>>>>>
> >> with LMA2, if there is no SA between MAG1 and LMA2, we can ask
> >>
> >>>>>> LMA2 exchange with AAA server to do authorization and validate
> >>>>>>
> >> whether MAG1 can fetch CN's MAG address from LMA2.
> >>
> >>>>>>
> >>>>> Who is "we" ("...we can ask LMA2...")? It's MAG1, right?
> >>>>>
> >>>>>
> >>>> [Qin]: Right, the example is MN's MAG1 requests CN's MAG2 address
> >>>>
> > from
> >
> >> LMA2, LMA2 should validate the message from MN's MAG1 using AAA
> >>
> > mechanism.
> >
> >>>>
> >>>>>> Also since SA is setup between one MAG and one LMA, upon the
> >>>>>>
> > first MN
> >
> >> who is attaching to the MAG triggers this MAG to setup SA with LMA,
> >>
> >>>>>> the SA can also be used by the other MN who attach to the same
> >>>>>>
> > MAG to
> >
> >> protect the data traffic between MAG and LMA Therefore the second
MN
> >>
> > who
> >
> >>>>>> is attaching to the same MAG may not setup SA again. Because
all
> >>>>>>
> > the
> >
> >> existing SA can be reused.
> >>
> >>>>>> Therefore SA setup is not a big issue, the biggest issue is:
> >>>>>> 1) who discover CN's LMA address?
> >>>>>> 2) how does he discover CN's LMA address?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> "Who?" should be the LMA, as you need to discovery only once,
> >>>>>
> > whereas
> >
> >>>>> if it's the MAG, each handover MAG needs to discover again,
unless
> >>>>>
> > you
> >
> >>>>> make the localized routing protocol dependent on CTX, which is
not
> >>>>> a good approach.
> >>>>>
> >>>>>
> >>>> [Qin]: For the handover case, If CTX is used with localized
routing
> >>>>
> >> protocol, discovery is done once as well.
> >>
> >>>> But CTX is not the only way.
> >>>> Besides CTX, there is another possible way to deal with handover
> >>>>
> > case
> >
> >> for multi-LMA.
> >>
> >>>> Since it is MN's MAG or CN's MAG who is responsible for setup
> >>>>
> > localized
> >
> >> routing path, LMA still
> >>
> >>>> needs to inform the MN's MAG to CN's MAG or inform the CN's MAG
to
> >>>>
> > MN's
> >
> >> MAG.
> >>
> >>>> Therefore when MN handover from MN's previous MAG to the MN's new
> >>>>
> > MAG,
> >
> >> it is not MN's LMA but MN's new MAG who is first to know that MN's
> >> handover happen, then MN's new MAG can trigger LMA to notify CN's
MAG
> >>
> > to
> >
> >> update MN's MAG address at CN's MAG,
> >>
> >>>> then CN's MAG updates localized routing path with MN's new MAG.
> >>>>
> >>>>
> >>> I think the basic assumption for the solutions should be that the
> >>>
> > MN's
> >
> >>> handover
> >>> target MAG does not know more than what PMIPv6 as per RFC5213
> >>>
> > requires,
> >
> >>> which is the LMA where to send the PBU to and does not cover any
> >>>
> >> localized
> >>
> >>> routing information. The information and states about localized
> >>>
> > routing
> >
> >>> could be
> >>> re-established (instead of transferred) by a common anchor, which
> >>>
> > does
> >
> >> not
> >>
> >>> change: The LMA.
> >>> draft-oulai even sets up localized routing states on both MAGs
> >>>
> > without
> >
> >>> any signaling between MAGs at all. We proposed something similar
in
> >>> draft-abeille, which was named 'proxy mode'. Such approach has
some
> >>> advantages if there is no SA between MAGs.
> >>>
> >> [Qin]: Since localized routing protocol can be used between source
> >> MAG(i.e., MN's MAG) and LMA,
> >> it also can be used between target MAG and LMA. I don't think it is
a
> >>
> > big
> >
> >> issue.
> >> Also in some case, MN's prefix and CN's prefix should be validated
to
> >> create for valid routing between MAGs.
> >> therefore LMA can notify both MAG that MN's prefix or CN's prefix
is
> >>
> > valid
> >
> >> each time handover happens.Also LMA can tell target MAG the
> >>
> > information
> >
> >> about localized routing.
> >> On the other hand, when routing path is established, target MAG
need
> >>
> > to
> >
> >> install localized routing states. This mechanism is quite similar
to
> >>
> > the
> >
> >> routing optimization between MN and CN described in RFC3775 and
> >>
> > RFC4866.
> >
> >>> marco
> >>>
> >>>
> >>>
> >>>> In this way, discovery is done only once as well.
> >>>>
> >>>>
> >>>>
> >>>>> "How?" could be different approaches. Static solutions could be
> >>>>>
> > based
> >
> >> on
> >>
> >>>>> the LMA's knowledge about address/HNP pools for HNP assignment
> >>>>> to attaching MNs. Dynamic solutions could be based on a AAA
> >>>>>
> >> infrastructure
> >>
> >>>>> as you referred to above. I don't think this particular "How?"
> >>>>>
> > should
> >
> >> be
> >>
> >>>>> addressed
> >>>>> by the localized routing solution.
> >>>>>
> >>>>>
> >>>> [Qin]: I agree.
> >>>>
> >>>>
> >>>>
> >>>>>> One example is , If AAA based CN's LMA discovery can be used,
we
> >>>>>>
> > can
> >
> >> ask AAA server push the keying materails which is used to protect
the
> >> trust relationship between MN's MAG and CN's LMA to the MN's MAG
and
> >>
> > CN's
> >
> >> LMA respectively. In this sense, the trust relationship between
MN's
> >>
> > MAG
> >
> >> and CN's LMA can be easily setup.
> >>
> >>>>>>
> >>>>>>
> >>>>>>> The other alternative is that PMIPv6 domain stractures are not
> >>>>>>>
> >> touched
> >>
> >>>>>>> and LMA1 will signal with LMA2 to synchronize states of MN and
> >>>>>>>
> > CN.
> >
> >>>>>>> Advantage would be that LMAs do not change during a handover
and
> >>>>>>> will keep states on one place.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> [Qin]: if using LMA1 signaling with LMA2 for state
synchronizing,
> >>>>>>
> > how
> >
> >> does LMA1 know LMA2 address?
> >>
> >>>>>>
> >>>>> Same as MAG1 may discover LMA2, with many advantages if you do
> >>>>>
> > this
> >
> >> from
> >>
> >>>>> LMA1.
> >>>>>
> >>>>> marco
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>> Any opinions?
> >>>>>>>
> >>>>>>> marco
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> netext mailing list
> >>>>>>> [e-mail]
> >>>>>>> https://www.ietf.org/mailman/listinfo/netext
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> _______________________________________________
> >>>> netext mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/netext
> >>>>
> >>>>
> >> _______________________________________________
> >> netext mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/netext
> >>
> 
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext