Re: [netext] Comments on :draft-wu-netext-local-ro-04.txt

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

Hi Qin,

Please see some replies below.

BR,
Mohana

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
Behalf
> Of Qin Wu
> Sent: Monday, November 23, 2009 11:14 AM
> To: Mohana Jeyatharan
> Cc: [e-mail]
> Subject: Re: [netext] Comments on :draft-wu-netext-local-ro-04.txt
> 
> 
> ----- Original Message -----
> From: "Mohana Jeyatharan" <[e-mail]>
> To: "Qin Wu" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Friday, November 20, 2009 5:44 PM
> Subject: RE: Comments on :draft-wu-netext-local-ro-04.txt
> 
> 
> Hi Qin,
> 
> Please see my short comments below.
> 
> BR,
> Mohana
> 
> > -----Original Message-----
> > From: Qin Wu [mailto:[e-mail]]
> > Sent: Friday, November 20, 2009 4:26 PM
> > To: Mohana Jeyatharan
> > Cc: [e-mail]
> > Subject: Re: Comments on :draft-wu-netext-local-ro-04.txt
> >
> > Hi, Mohana:
> > Thank for your quick response, please see my feedback inline.
> >
> > Regards!
> > -Qin
> > ----- Original Message -----
> > From: "Mohana Jeyatharan" <[e-mail]>
> > To: "Qin Wu" <[e-mail]>
> > Cc: <[e-mail]>
> > Sent: Friday, November 20, 2009 12:10 PM
> > Subject: RE: Comments on :draft-wu-netext-local-ro-04.txt
> >
> >
> > Hi Qin,
> >
> > Thanks for reply.  Please see some replies in-line.
> >
> > BR,
> > Mohana
> >
> > > -----Original Message-----
> > > From: Qin Wu [mailto:[e-mail]]
> > > Sent: Friday, November 20, 2009 10:19 AM
> > > To: Mohana Jeyatharan
> > > Cc: [e-mail]
> > > Subject: Re: Comments on :draft-wu-netext-local-ro-04.txt
> > >
> > > Hi, Mohana:
> > > Sorry for my late reply. Also thank you for your review and
> comments.
> > > please see my reply inline.
> > >
> > > Regards!
> > > -Qin
> > > ----- Original Message -----
> > > From: "Mohana Jeyatharan" <[e-mail]>
> > > To: "Qin Wu" <[e-mail]>
> > > Cc: <[e-mail]>
> > > Sent: Monday, November 16, 2009 9:59 AM
> > > Subject: Comments on :draft-wu-netext-local-ro-04.txt
> > >
> > >
> > >
> > > Hi Qin,
> > >
> > > Read your ID.  I have few comments.
> > >
> > > Please see below.
> > >
> > > BR,
> > > Mohana
> > >
> > > In abstract,
> > > "In case the correspondent node is
> > >     connected to another local mobility anchor, the local mobility
> > >     anchors connected by the correspondent node needs to be
> discovered
> > >     firstly so that it can notify its mobile access gateways
> attached
> > by
> > >     the correspondent node to the mobile access gateway attached
by
> > the
> > >     mobile node afterwards."
> > >
> > > <<<[Mohana] In abstract it is not very clear which entitiy
notifies
> > CN's
> > > MAG to MN's MAG. Perhaps a rewording may be useful>>>
> > >
> > > [Qin]: Yes, what we are really saying here is CN's LMA will notify
> > CN's
> > > MAG to MN's MAG when MN's MAG
> > > communicate with CN's LMA using normal PBU/PBA. Maybe the proper
way
> > to
> > > say would be
> > > "
> > > so that the discovered local mobility anchor notity its mobile
> access
> > > gateways attached by the correspondent node......
> > > "
> > [Mohana] So, the description is tied to CN's LMA notifying MN's MAG
to
> > CN's MAG. Ok, understand.  But some description on MN's LMA
notifying
> > CN's MAG to MN's MAG will be also useful in the inter-LMA scenario.
> > What I am not clear is why is MN's MAG connected to CN's LMA?
> Probably
> > this is another scenario addressed in scetion 7(inter LMA case).
> Anyway
> > I will leave it for now.  If MN's MAG is connected to CN's LMA, then
> > such passing (CN's LMA passing CN MAG address to MN's MAG)is
propoer.
> > Otherwise Cn's LMA will need to pass CN's MAG address to MN's LMA.
> >
> > [Qin]: Your understanding is correct. In the Inter-LMA local routing
> > scenario,
> > MN and CN attach to different MAGs and registers to different LMA
> > respectively.
> > In this scenario, MN's LMA does not know CN's MAG address, what we
can
> do
> > here
> > is to let MN's MAG talk with CN's LMA, then CN's LMA can tell MN's
MAG
> > about
> > CN's MAG address.
> > but if MN and CN share the same LMA, then it does not matter whether
> MN's
> > LMA or
> > CN's LMA notitfy CN's MAG to MN's MAG,
> > because MN's LMA is CN's LMA.
> 
> [Mohana] Ok, do not want to dwell on this too much. So you are saying
> that CN MAG address is passed to MN MAG by CN LMA.  A short question I
> have is how does CN LMA address is known to MN MAG.  Anyway, I need to
> read the inter-LMA part in more detail.
> 
> [Qin]: PMIP6 mobility entities discovery( i.e., LMA) described in PS
draft
> will be used to
> obtain CN LMA address. In our solution I-D, one AAA mechanism can be
> adopted to perform
> PMIP6 mobility entities discovery. The details can be read in another
I-
> D,i.e., draft-wu-dime-pmip6-lr-01.
> 
> >

[Mohana] Ok, so when LMA1(MAG1(Mn)) and LMA2(MAG2(CN)) are in the same
domain, I guess this mechanism AAA based can be used to find CN LMA
address.  But when LMA of Mn and LMA of CN are in different domains, and
MN and CN placed in another visited domain, then discovery of CN LMA
address may be more difficult using the AAA.  Am I right to say that?
Also it depends whether the solution space is looking at LMAs placed in
different provider domains and MN and CN placed in another visited
domain.

> > > In abstract, Mobile access gateways create and refresh bindings
> > >     using proxy binding update and acknowledgement messages.
> > >
> > > <<<[Mohana] What is the reason for this.  Is this refering to PBU
to
> > LMA
> > > or PBU to MAG?  Perhaps more clarity on this will help.>>>
> > >
> > > [Qin]: Okay, actually PBU/PBA will be used between MAGs to create
> > binding
> > > when it is the first time for MAGs to setup localized routing
path.
> > > during handover case, PBU/PBA will be used between MAGs to refresh
> > binding.
> > > The reason to create and refresh bindings between MAGs attached by
> > mobile
> > > node and correspondent node is quite similar to correspondent
> > registration
> > > in the Mobile IPv6 Routing optimization between mobile node and
> > > correspondent node described in the section 11.7.2 of RFC3775.
> > > i.e., allowing correspondent node to cache mobile node's proxy
> care-of
> > > address or allowing mobile node to cache correspondent node' proxy
> > care-of
> > > address,
> > [Mohana]I agree with your approach of using PBU/PBA for routing
state
> > setup and tunnel setup between MAGs and think that is a good
approach
> > and tied to RFC 5213 way.  From further reading of your draft I
> > understand this.  All I wanted to say is that in abstract, a
> mentioning
> > of PBU/PBA from MAG to MAG introduces more clarity.  That is all.
> >
> > [Qin]: Okay, agree.
> >
> > >
> > > In conventions used section it is mentioned
> > >
> > > Local routing: Traffic between MN and CN does not pass through LMA
> > >    and is locally routed in the same PMIPv6 domain.
> > >
> > > <<<[Mohana] Perhaps a re-wording may be necessary when referring
to
> > > PMIPv6 domain. This should be aligned with the PS draft
terminology.
> > It
> > > should be same provider domain running PMIPv6 or some thing like
> > > that.>>>
> > >
> > > [Qin]: Okay, will check the wording to be consistent with PS
draft.
> > >
> > > In conventions used section it is mentioned
> > > Local Routing Optimization Request (LROREQ): A message initiated
by
> > >    the MAG or LMA requesting the MAG or LMA to establish local
> routing
> > >    optimization path between MN and at least one pair of CNs who
> > >    communicate with MN.
> > > <<<[Mohana] why is there reference to at least one pair of CN.
Are
> u
> > > saying at least a single CN? Not very clear>>>
> > >
> > > [Qin]: Right, thank for your good catching and correction.  The
> reason
> > to
> > > say at least one CN is
> > > in some cases, maybe MN will communicate with more than one CN, in
> > this
> > > sense, LROREQ
> > > message may be sent from MN's LMA to each MAGs attached by
serveral
> > CNs
> > > which is communicating with MN.
> > > or sent from MN's MAG to each LMA which is registered by more than
> one
> > CNs
> > > which is communicating with MN during inter-LMA handover case.
> > >
> > [Mohana]Ok, sure I understand your intention proabably a minor
> > re-wording would do.
> >
> > [Qin]: Right.
> >
> > > In section 3 Scenario analysis for PMIPv6 local routing
> > >
> > > <<<[Mohana]The text before the figure 1 is refering to PMIPv6
> domain.
> > > Again I think this should be single administrative/provider domain
> > > running PMIpv6.>>>
> > >
> > > [Qin]: Okay.
> > >
> > > In figure 1,
> > > <<<[Mohana]the MAG1 is connectedto IPv4 only or IPv4/IPv6
transport
> to
> > > LMA.>>>
> > >
> > > [Qin]: I am okay with this change in the figure 1.
> > >
> > > In last para in section 3 which is
> > > In all the above scenarios, MN is allowed to roam within its
PMIPv6
> > >    domain (i.e, MN's home domain in which MN's LMA is located) or
> move
> > >    from one PMIPv6 domains(i.e., MN's visited domains)to another.
CN
> > >    should stay with MN within the same PMIPv6 domain, e.g., MN
moves
> > to
> > >    the visited domain to which CN belongs. Another example is MN
and
> > CN
> > >    move to the same visited domain to which MN's LMA or CN's LMA
> does
> > >    not belong.
> > > <<<[Mohana] Here PMIPv6 domain should be chnaged to administrative
> > > domain. Probably re-writing with respect to MN in home or visited
> > domain
> > > and CN inhome or visited domain may be useful.  Currently the text
> is
> > > not very clear>>>
> > >
> > > [Qin]: Agree there is room for improvement here, this paragraph
will
> > be
> > > reworded in accordance with the
> > > terminologies used in the PS draft
> > [Mohana] Ok, thanks.
> >
> > > In section 4,
> > > <<<[Mohana] the first bullet should be changed to administrative
> > domain
> > > instaed of PMIPv6 domain.  The second bullet says MN and CN
attached
> > to
> > > same LMA.  But in section 3 it is mentioned inter LMA scenario as
> > well.
> > > So, I am a bit confused as to whether the solution is not handling
> > inter
> > > LMA scenario.>>>
> > >
> > > [Qin]: Yes, inter LMA scenario will be handled in one separate
> section
> > of
> > > our Solution I-D. Our solution I-D mainly focuses on specifying
the
> > > localize drouting protocol based on the first two scenarios
> described
> > in
> > > the section 3. the common aspect of the first two scenarios is it
> does
> > not
> > > require PMIP6 mobility entities discovery described in the PS
draft.
> > As
> > > regarding to the inter-LMA local routing scenario, it depends on
> PMIP6
> > > mobility entities discovery, extra extended PMIP6 signaling is
> > required
> > > between MN's MAG and CN's LMA. Therefore inter-LMA local routing
> case
> > is
> > > separated from section 4 which is concentrating on the first two
> > scenarios
> > > and addressed in the independent section, i.e., section 7.
> >
> >
> > [Mohana]  Ok, understand. Do not know why I got confused.  Probably
a
> > section outline may be helpful and I leave it to you to handle.
> >
> > [Qin]: Okay.
> >
> > >
> > > In section 4.1
> > >  <<<[Mohana] In this section there is reference to three different
> > types
> > > of flags such as intra-LMA local routing flag, intra-MAG local
> routing
> > > flag, Enable detect local routing flag.  A description of these in
> > > section 2 would be better for easy understanding.>>>
> > >
> > > [Qin]: Okay. Thank for your suggestion.
> > >
> > > In section 4.1, para 3, it is mentioned After successful local
> routing
> > > optimization process, if MN and CN
> > >    attach to the different MAGs, i.e., MAG1, MAG2 and intra-LMA
> > >    localrouting flag is set to value one, the MAG1 to which the MN
> > >    attaches may send PBU message to the MAG2 which the CN attaches
> to.
> > > <<<[Mohana]Here I think there needs to be a rephrasing of
sentence.
> I
> > > think you are referring to MN connected to MAG 1 and CN connected
to
> > > MAG2 and intra LMA flag is set at the MAG and PBU/PBA exchange
> between
> > > th etwo MAGs.  The sentence is not clear.>>>
> > >
> > > [Qin]: Okay, maybe we could say:
> > > "
> > > MAG1 to which the MN is connected may send PBU message to the MAG2
> to
> > > which the CN
> > > is connected.
> > > "
> > [Mohana] probably somewords along the above lines may be useful.
> >
> > > In section 4.1, in para 3 it is mentioned that MN's MAG is
informed
> of
> > > CN MAG via LROResponse from LMA (assuming MAG initiated RO) and
CN's
> > MAG
> > > is informed of Mn'sMAG via LRO response and both MN's Mag and CN's
> > MAGs
> > > are engaged in bi-ditectional PBU/PBA.
> > >
> > > <<<[Mohana]Here I have some comments.
> > > Mn's MAG will do LROReq to LMA. LMA can pass CN's MAG address in
new
> > > option.  Then MN's MAG can start PBU with CN's MAG.  But the
> question
> > I
> > > have is how does CN's MAG create the routing state for MN prefix.
> How
> > > does the CN's MAG know that this prefix is owned by MN and MN's
MAG
> is
> > > actually proxying that prefix?
> > >
> > >
> > > The same when CN's MAG does PBU to MN's MAG.  Probably, after
> getting
> > > the PBU from MN's MAG, CN's MAG can start PBU with CN's MAG.  But
> > again
> > > to create the the routing state for CN's prefix at MN's MAG the
MN's
> > MAG
> > > should know the prefix CN owns is valid prefix. Otherwise, I don't
> see
> > > how a valid routing state can be created.
> > >
> > > So, by reading this I feel a prefix ownership kind of information
is
> > > needed in the PBU.>>>
> > >
> > > [Qin]: My understanding is if CN's MAG trusts MN's MAG, then CN's
> MAG
> > must
> > > believe the prefix sent from MN's MAG is owned by MN. Because MN's
> MAG
> > can
> > > check whether prefix is ownd by MN and used to create a valid
> routing
> > > before it send the prefix to the CN's MAG. That is to say we can
> > assume
> > > there is a trust relationship between MN's MAG and CN's MAG. In
oder
> > for
> > > this, two possible ways in my mind are,
> > > 1) we assume a prior agreement between MN's MAG and CN's MAG.
> > > 2) the second way is we use IPSEC to setup Security association
> > between
> > > MN's MAG and CN's MAG.
> > > By these two ways mentioned above, we can have trust relationship
> > between
> > > MAGs, But what if MN's MAG establish trust relationship with CN's
> MAG
> > and
> > > send the forged MN's prefix to CN's MAG, I think the prefix
> ownership
> > > validation may be useful in this scenario to help create valid
> routing
> > > state at CN's MAGs
> > > Therefore I would like to address this security threat in our
> solution
> > I-
> > > D.Thanks for your good points.
> >
> >
> > [Mohana] Thanks Qin.  Although I liked the Pbu way of establishing
> > tunnel between MAGs, this prefix validation seemed important to
> address
> > the security part. In RFC 5213, LMA is the prefix delegator so such
> > issue is not needed.  But here, the CN's MAG need such validation.
> > Thanks for addressing this part.
> >
> > [Qin]Agree.
> > >
> > > In the handover mechanims in section 4.1.1, it is mentioned that
the
> > > nMAG1 will get context from old MAG (pMAG1).
> > >
> > > <<<[Mohana] But the question I have is when nMAG1 does PBU to CN's
> > MAG,
> > > how can CN's MAG know that this prefix of MN is valid and nMAG1 is
> > > proxying the preifx.  Bcos during handoff, the LMA is not
involved.
> > > nMAG1 has no issue in knowing that MN;s prefix is given by LMA
> because
> > > when it does PBU to LMA it will know that this is a valid prefix.
> But
> > > that is not the case with CN's MAG.>>>
> > >
> > > [Qin]: Good question, when MN hands over from pMAG1 to nMAG1 and
> keeps
> > on
> > > communication with CN, there is no trust relationship beforehand
> > between
> > > nMAG1 and MAG2 to which CN is connected.  That is true. But I
think
> > MN's
> > > prefix will keep unchanged during handover. The only change to MN
is
> > MN's
> > > Proxy CoA will . Is it necessary/mandatory to ask CN's MAG to
> validate
> > > MN's prefix ownership each time MN hands over? In my
understanding,
> > prefix
> > > ownership validation can be understood as routing reachability
> > test(RRT)
> > > procedure defined in the RFC3775. But I am not sure RRT procedure
> will
> > be
> > > done each time MN hands over according to RFC3775.
> >
> > [Mohana] For the handover case, just as in new establishment, the CN
> > needs to know that the nMAG is proxying the prefix.  So the prefix
> > validation method as for new connection can be used here. The RFC
3775
> > way of prefix validation is one way but there is more signaling.
> > Probably some assurance from LMA will be good regarding prefix
> validity.
> > I think this is critical bcos in handover case, LMA is not involved.
> So
> > to assure fast handoff one would not want the LMA to be involved.
> > Furthermore, using your method a distributed handoff management can
be
> > done without the involvement of pMAG of MN notifying anything to
> CN'MAG.
> > What I am saying is nMAG of MN can handle the PBU with CN's MAG
> without
> > old MAG of MN being involved and this will expedite handover state
> > convergence.  The only thing that is needed in MN's nMAG to tell CN
I
> > own/proxy this prefix and prefix is valid.
> >
> > [Qin]: Okay, let me try to understand what you are explaining about
> prefix
> > ownership validation.
> > It seems to me, there are three possible ways to do this task:
> > 1) pMAG of MN notify CN's MAG that MN's prefix is valid.
> > 2) LMA of CN notify CN's MAG that MN's prefix is valid.
> > 3) nMAG of MN itself notify CN's MAG that MN's prefix is valid
> > In these three ways, the 3) seems more straightforward and efficient
> than
> > 1) and 2) to  fulfill prefix owndership validation during handover.
> > But in some cases, e.g., MN and CN register to the same LMA, LMA may
> > notify both MAGs associated with MN and CN that MN's prefix and CN's
> > prefix are valid before PBU/PBA exchange between MN's MAG and CN's
MAG
> > happens. That is to say, prefix owndership validation also can be
done
> > during LROREQ/LRORSP exhange between MAG and LMA.
> > Anyway, I think prefix ownership validation is necessary and useful
> > feature that can be used to create valid routing.
> >
> [Mohana] Thanks for the good break down and analysis. As you have
> identified
> 3) seems more straightforward and efficient. When you are refering to
> LMA involved in prefix validation, I think you are refering to LMA
> initaited RO case.  I need to further look at your ID for LMA
initiated
> RO scenario and how LMA is involved during handoff procedures.  I will
> get back to you soon on this with a little more comments on this
> procedure. Thanks.
> 
> [Qin]: As regarding to LMA involved prefix validation, I think it also
can
> be applicable to MAG Initiated RO case. But one more message from LMA
is
> required to notify the CN's MAG MN's prefix is valid upon LMA
receiving
> LROREQ message from MAG. In other words,  e.g., MN's MAG requests CN's
LMA
> to validate CN's prefix ownership by sending LROREQ message including
MN-
> CN pair mobility option, LMA respond to MN's MAG with LRORSP, at the
same
> time, LMA notify CN's MAG that MN's prefix is valid by sending LROREQ
to
> CN's MAG.

[Mohana] Ok, agree that even in MAG initiated RO case, LMA can be
involved in giving prefix validation.  But then again as you have said
there is additional signaling from LMA to CN.MAG which can be avoided
using method [3].
> 
> > > Also in section 4.1 in second paragraph it is mentioned that MAG
can
> > > send LRO req to LMA when Mn and CN are not attached to same MAG.
> > > <<<[Mohana] In this case, how does MAG know the CN address.  What
> > value
> > > will be attached in the Mn-CN pair mobility option.  Is there some
> L2
> > > message sent from Mn to MAG and all CN addresses are given in
these.
> > > Probably such mentioning will be useful>>>
> > >
> > > [Qin]: How MAG know the CN address actually is beyond scope of
this
> > > solution I-D. The possible way is MAG may look at data packet'
> > destination
> > > address to know CN address.For the case where one MN communicates
> with
> > one
> > > CN, MN-CN pair mobility option may include one MN's info and one
> CN's
> > info.
> > > MN's. For the case where one MN communciates with several CNs,
MN-CN
> > pair
> > > mobility option may include one MN's info and several CNs' info.
> >
> > [Mohana] Ok, thanks. I was just analyzing the benefits of MAG
> initiated
> > RO as opposed to LMA initiated RO and wanted to highlight some
> benefits
> > when MAG initiates RO.  I guess how MAG gets the information need
not
> be
> > covered in the draft and it can be out of bound signaling.
> >
> > [Qin]: Okay, understand. In my opinion, MAG initiated RO is more
> > applicable to the local routing
> > described in RFC 5213 than LMA initiated RO. But we can not exclude
> LMA to
> > initiate RO as well.
> >
> >
> > > I have more comments.  But rather than sending all at once I
thought
> I
> > > will stop here for now.
> >
> > > Thanks.
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > [mailto:[e-mail]]
> > > > On Behalf Of [e-mail]
> > > > Sent: Monday, October 26, 2009 4:30 PM
> > > > To: [e-mail]
> > > > Subject: I-D Action:draft-wu-netext-local-ro-04.txt
> > > >
> > > > A New Internet-Draft is available from the on-line
Internet-Drafts
> > > > directories.
> > > >
> > > > Title           : Proxy MIP extension for local routing
> > > optimization
> > > > Author(s)       : W. Wu, B. Sarikaya
> > > > Filename        : draft-wu-netext-local-ro-04.txt
> > > > Pages           : 32
> > > > Date            : 2009-10-26
> > > >
> > > > This document extends local routing in proxy Mobile IPv6 and
> defines
> > > >  a localized routing optimization protocol within one PMIPv6
> domain.
> > > >  The protocol supports IPv4 transport network operation, IPv4
home
> > > >  address mobility and handover. The Local mobility anchor/mobile
> > > >  access gateway initiates local routing for the mobile and
> > > >  correspondent node by sending messages to each mobile access
> > > >  gateway/local mobility anchor. In case the correspondent node
is
> > > >  connected to another local mobility anchor, the local mobility
> > > >  anchors connected by the correspondent node needs to be
> discovered
> > > >  firstly so that it can notify its mobile access gateways
attached
> > by
> > > >  the correspondent node to the mobile access gateway attached by
> the
> > > >  mobile node afterwards. Mobile access gateways create and
refresh
> > > > bindings
> > > >  using proxy binding update and acknowledgement messages.
> > > >
> > > > A URL for this Internet-Draft is:
> > > >
> http://www.ietf.org/internet-drafts/draft-wu-netext-local-ro-04.txt
> > > >
> > > > Internet-Drafts are also available by anonymous FTP at:
> > > > ftp://ftp.ietf.org/internet-drafts/
> > > >
> > > > Below is the data which will enable a MIME compliant mail reader
> > > > implementation to automatically retrieve the ASCII version of
the
> > > > Internet-Draft.
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext