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

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

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

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