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

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

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

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

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

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

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

In figure 1, 
<<<[Mohana]the MAG1 is connectedto IPv4 only or IPv4/IPv6 transport to
LMA.>>> 

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

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

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

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

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

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

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