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

[Qin Wu <[e-mail]>]

Hi, Mohana:
Thank for your feedback, please see my comments below.

Regards!
-Qin
----- Original Message ----- 
From: "Mohana Jeyatharan" <[e-mail]>
To: "Qin Wu" <[e-mail]>; "Marco Liebsch" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, November 25, 2009 6:28 PM
Subject: RE: [netext] multi-LMA : how to handle


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?  

[Qin]: Good question, in our solution I-D, when MN handover to the new MAG, suppose CN's MAG address keeps unchanged during MN's handover,
CTX can be used between previous MN's MAG and new MN's MAG to inform the CN's MAG address to the MN's MAG. The big advantage is
LMA invlovement can be avoided each time MN's handoff.
That is to say, CN's LMA is only involved when MN's MAG does not know CN's MAG. Upon MN's MAG know CN's MAG and CTX is allowed between
MAGs, MN's new MAG can fetch CN's MAG from MN's previous MAG and update localized routing path between MN's new MAG and CN's MAG without involvement of CN's LMA.

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.

[Qin]: No, AAA server can not keep track of MN or CN's movement as LMA do, each time MN or CN handoff,
MN's MAG address will differ from the previous one  and is updated into MN's LMA. It is the same case with CN's MAG address.
But wherever MN or CN moves, the MN's LMA and CN's LMA will keep unchanged. Therefore MN's LMA and CN's LMA can
may be maintained as a  configured entry in the CN's policy profile located in AAA server.

Just wondering whether 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.

[Qin]: 
As I said above, if CTX is allowed and CN's MAG keeps unchanged during MN's handover, CN's LMA involvement may be not necessary. 

But if CTX is not available during MN's handover, the MAG may ask the common trusted entity (AAA) between MN's LMA and CN's LMA to inform
MN's LMA and CN's LMA respectively for prefix validation. And then MN's LMA inform MN's MAG that prefix is valid, also CN's LMA informs CN's MAG 
that prefix is valid, is this your idea? 
Anyway I think AAA based mechanism should be out of scope of the solution I-D.


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.  Thus LMA need not wait for session to be started
between every MN and each CN to establish the RO.

[Qin]: I am not sure L2 mechanism can be used for detection. I think there are other
ways using L3 mechanism. But it should be beyond scope of solution I-D.
Besides this, I share your opinion.

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