Subject: [netext] Review of I-D: draft-ietf-netext-pmip6-lr-ps

From: <[email-masked]>
Date: Mon, 10 Jan 2011 21:34:14 +0000

I-D: draft-ietf-netext-pmip6-lr-ps-03.txt

Review comments:

General:
The I-D illustrates multiple scenarios and use cases for optimized
routing. However the WG has clearly noted that the scope of such
localized routing should be limited to the scope of a single PMIP6
domain. Inter-LMA routing is also out of scope. These points should be
noted in the I-D as being relevant to the solution scope.
Additional comments below:

Issues:

- It would be good to note in the introduction that RFC5213 (Sec
  6.10.3) does allow packets between an MN and CN attached to a common
  MAG to be routed without having to traverse thru the LMA.

- The scope of Localized routing as far as I understand is between
  nodes that are attached to a common LMA. There is no inter-LMA
  routing. The definition of localized routing in sec 2 seems to
  indicate otherwise.
"  Localized Routing: Result of signaling to set up routing states on
      relevant network entities to allow forwarding of data packets
      between an MN and a CN, which are attached to the same provider
      domain without intervention of the MN's LMA and the CN's LMA in
      data forwarding.
"

Proposed change:
Localized routing: The capability to route packets between an MN and
CN which are attached to a common LMA but potentially different MAGs
without having to traverse the LMA is refered to as localized
routing. 

- In sec 3.2, it would be useful to show the concept of a PMIP6 domain
  in the figure (Fig 1). You could make the argument that there could
  be multiple LMAs within the scope of a single PMI6 domain. However
  the PS doc needs to clearly state that the scope of LR is only
  between nodes that are served by a common LMA.

- Also in Fig 1, you may want to illustrate multiple MAGs within the
  scope of a single LMA.

- Case A11 is already handled by RFC5213. So maybe you can just
  mention it as such.

- W.r.t A12 you need to also consider whether MAG1 is part of the same
  PMIP6 domain or is associated with LMAs that are in different PMIP6
  domain. Do both LMAs have to authorize (EnableMAGLocalRouting flag)
  in order for this to work?

- It is okay to include A22, but only as a potential use case. You may
  want to emphasise that the WG is not considering this use case
  because of the complexities involved.

- In Sec 3.3.2:
"Optional mechanisms for negotiating the IP version to use
   as well as the encapsulation mode to use are outside the scope of the
   NetExt WG's solution for localized routing."
   
   Why does the PS I-D have to say anything about solution scope?

- The functional requirements in Sec 4 appear to be specifying a
  solution. This section could be safely dropped IMO.

Editorial:

- s/for network-based localized mobility management (NetLMM) which
  takes basic operation for registration, de-registration and handover
  into account. /for network-based localized mobility managment.

- s/Even though an MN may be attached to the
   same or a different MAG as its Correspondent Node (CN) within the
   same provider domain, packets being associated with their
   communication will traverse the MN's and the CN's LMA./Packets
   associated with a session between an MN and CN which are attached
   to the same PMIP6 domain via a common LMA are always routed via the
   LMA. 

- s/The NetLMM Extensions (NetExt) Working Group has an objective to
   design a solution for localized routing in PMIPv6./An optimized
   approach to routing of packets between nodes attached to a common
   LMA is considered useful. The NetLMM Extensions (NetExt) working
   group has a charter item to specify a localized routing solution
   for Proxy Mobile IPv6.

Rewrite the following with better clarity:
" In case one or both nodes hand over to a different MAG, the localized
   routing protocol maintains the localized routing path.  Relevant
   protocol interfaces may include the interface between associated
   MAGs, between a MAG and an LMA as well as between LMAs.
"

- s/3.1.  General observation/Background and justification

- s/At least some deployment would benefit from having such
   communication localized, rather than traverse the core network to the
   LMA(s)./Deployment benefit in terms of reduced backhaul is realized
   by having packets between an MN and CN associated with a common LMA
   localized to the relevant MAGs.

- s/Localized routing is crucial at least/Localized routing is
  relevant at least

- s/Hence, providing the
   necessary protocol specification to enable localized routing in
   PMIPv6 is necessary./Hence, specifying optimizations to packet
   routing between nodes attached to a common LMA has performance and
   cost benefits.

- s/3.2.  Analysis of different use cases/ Use Case analysis

- s/The following list summarizes some key functions, which need to
   be performed by the PMIPv6 enabled network infrastructure to
   substitute mobile nodes in setting up a direct route./The following
   is a list of some of the key functions which need to be implemented
   by the MAG and LMA nodes in a PMIP6 enabled network.

- In Sec 5, it would be worthwhile to also include some analysis text
  regarding which of the roaming scenarios may be considered out of
  scope at the present time.
 
-Basavaraj

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 12 Jan 2011 17:55:35 +0100

Hi Raj,

thanks for your review and comments. Please see inline.

[email-masked] wrote:
> domain.
I think section 3.2, where we start the analysis, can mention this. What 
about
starting with the following intro:
'This problem statement focuses on local communication between PMIPv6
managed nodes being attached to MAGs sharing the same provider domain.'

>  Inter-LMA routing is also out of scope.
I think routing between two LMAs is nothing we can influence. That happens
when two MNs communicate, even without localized routing.

>  These points should be
Is the sentence above for section 3.2 ok with you?

>   MAG to be routed without having to traverse thru the LMA.
Ok, we address this in 3.1, but can also refer to it in the Intro. 
However, I think that
RFC5213 just *considers* it without *supporting* it. This means, the 
spec mandates
the LMA to control such local routing, but means to control are not 
available.
So, what about adding the following to the Intro:

Intro:
'...[RFC5213] addresses the need to enable local routing of traffic 
between two nodes
being attached to the same MAG, but does not specify the complete procedure
to establish such localized routing state on the shared MAG...'

> without having to traverse the LMA is refered to as localized
Same as above, I do not think this can be influenced. When two
PMIP managed MNs communicate, their traffic always traverses
their LMAs, hence is routed between their LMAs. This has nothing
to do with the localized routing issue. Hence, we cannot exclude this
from the PS. Limiting the scope of a solution for LR to single MAG
operation, this is something different. However, the NetExt WG's
solution draft also specifies LR for multi-LMA scenarios.
So, why shouldn't this be considered then in the PS.

>   between nodes that are served by a common LMA.
3.2 does not make an assumption about PMIP domains, as it's not relevant.
We went through the exercise to discuss and define the terms of PMIP domain
versus provider domain. We use these terms as agreed. NetExt WG scope 
limitation
to consider only MAGs sharing the same provider domain is explicitly 
mentioned
in 3.2. Do you agree this is sufficient? Btw, distribution of LMAs and 
MAGs between
different provider domains is discussed in the roaming section, which 
has been requested
some time ago. I think this helps to understand the limitations.

> - Also in Fig 1, you may want to illustrate multiple MAGs within the
Not exactly clear to me what you propose. It's just an architecture picture
without associating MAGs to LMAs. This is done in section 3.2 and
section 5. Maybe you can provide an example what you want to
show in Fig 1 and indicate what's the advantage of showing this in Fig. 1.

> - Case A11 is already handled by RFC5213. So maybe you can just
Ok, same proposal as above, we can refer to what RFC5213 covers.
Basically it would be the same text as I proposed above. Is this ok
with you?
One question: How does RFC5213 localized routing distinguish
A11 from A12? And how do LMAs control the mandated enforcement of
localized routing?

>   in order for this to work?
I do not know. I also cannot find this described in RFC5213. That's
why I doubt this is specified and supported by RFC5213. How to handle this?

>   because of the complexities involved.
Ok, I can add a statement. But is this really the responsibility of the 
Problem Statement?
Why should we enter the solution space and scope here? It's something the
charter should indicate, isn't it?

>    Why does the PS I-D have to say anything about solution scope?
Raj, now I am confused. Should the PS now refer to NetExt limitations or
not? For the A22 scenarios you want to have it, for other things not. Please
take a decision and let us know.

>   solution. This section could be safely dropped IMO.
You're the only one proposing this so far. If the WG thinks this
should be out, no problem. We don't see this as solution. The bullets
just follow the problem analysis and list what's to be done to address 
the problems.
This also differentiates the problems from MIPv6 RO problems.
Maybe we can have more opinions on this?

Btw, there were some comments from Xiangsong and we revised text to
avoid solution specifics.

>   into account. /for network-based localized mobility managment.
ok.
>    to the same PMIP6 domain via a common LMA are always routed via the
Why do you propose mixing again provider with PMIP domain?
PMIP domain is not relevant here. 'provider domain' has been added
here as requested to highlight the NetExt limitation, where both MAGs
must share the same provider domain. I don't think we need to
mention NetExt scope limitations in every second sentence..

For remaining editorial comments, I'll take over relevant comments
which make text clearer. Most of the other proposals for editorial
changes make an effort to limit the description to single LMA scenario,
which even conflicts with NetExt scope, as the solution covers
scenarios with multiple LMAs. So, would it be ok to keep the
general PS, but mention the NetExt scope in the PS once? I think
this is sufficient and should be clarified first.

marco

> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>