Subject: [netext] AD Evaluation: draft-ietf-netext-pmip-cp-up-separation

From: Brian Haberman <[email-masked]>
Date: Wed, 21 May 2014 09:49:46 -0400

All,
     I have completed my AD evaluation of
draft-ietf-netext-pmip-cp-up-separation as a part of the publication
process.  This document is well-written, concise, and nearly ready for
IETF Last Call.  I only have two comments/issues I would like to see
resolved.

1. The document uses several different terms to refer to the plane
responsible for the transit of user data.  I see "user plane" and "data
plane" used within the document.  Additionally, the folks in the routing
area use the term "forwarding plane".  Unless "user plane" is a
term-of-art within the mobility space, I would suggest harmonizing the
text and using a single term (data or forwarding) to describe the plane.

2. What is the plan for the publication of the CP separation
requirements document that is referenced in this document?  It seems
rather silly to publish the solution spec before the requirements.
Should they advance together?  Incorporate the requirements into this
document?

Once we iron these issues out, the publication process can proceed.

Regards,
Brian

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 21 May 2014 17:47:49 +0000

Hi Brian,

Thanks for your review comments. Please see inline.

>text and using a single term (data or forwarding) to describe the plane.

Agree. We will update the draft to reflect consistent terminology use.

>Should they advance together?  Incorporate the requirements into this

We have the following text that talks about the assumptions around this
interface. The draft is primarily driving this definition for the
deployment-scenario where the CP and DP functions exist on the same IP
node. Figure-1 reflects this. However, the draft does not disallow the
separation of CP and DP functions across different IP nodes. That's surely
the goal here. But, there is no desire to mandate one specific interface
between CP and DP entities. That interface may emerge as a generic
interface and this draft (PMIP-split-CP-DP) being one of the applications
leveraging that interface. The interface can be based on OpenFlow, FORCES,
some vendor specific interface, or the referenced draft based on
extensions to routing control plane.  There is no dependency on one
specific interface for realizing the CP/DP split per this spec. Most
likely vendors may not agree on a single interface between a controller
and a data plane node and so we tried to stay neutral on that aspect.

---
Section 1:

   Note that the interface between the control and user plane is out of
   scope in this document.  It is required to setup a data path on the
   user plane according to the control signaling on the control plane.
   Several IETF working groups are addressing this interface as
   described in [RFC5415], [RFC5812], [RFC5810],
   [I-D.matsushima-stateless-uplane-vepc].  Techniques from Software
   Defined Networking (SDN) [RFC7149] may also be applied.

--

Regards
Sri

---

From: Brian Haberman <[email-masked]>
Date: Thu, 22 May 2014 07:57:02 -0400

Hi Sri,

> Agree. We will update the draft to reflect consistent terminology use.

Cool.

>    Defined Networking (SDN) [RFC7149] may also be applied.

The above makes sense and would be a good addition to the draft, but I
am still a little concerned with the text surrounding the reference to
draft-wakikawa-req-mobile-cp-separation.  I think that it is the wording:

This separation brings more flexible deployment and management of LMA
and MAG(s) of Proxy Mobile IP as described in
[I-D.wakikawa-req-mobile-cp-separation].  To meet this requirement...

Should I parse this as the reference to the draft is only to relate the
use cases rather than the actual requirements?  If so, I could change
"To meet this requirement" to "To facilitate this approach" or something
similar.

Or am I missing something?

Regards,
Brian

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 27 May 2014 17:05:26 +0000

Hi Brian,

Sorry for the delay. Please see inline.

>"To meet this requirement" to "To facilitate this approach" or something

Reference to I-D.matsushima is intended to be an example.

How about the following text:

OLD:

NEW:

The LMA-CP and the LMA-DP functions are typically deployed on the same IP
node and in such scenario the interface between these functions is
internal to the implementation. Deployments may also choose to split the
LMA-CP and the LMA-DP functions across IP nodes. In such deployment
models, there needs to be a protocol interface between the LMA-CP and the
LMA-DP functions and which is outside the scope of this document. Possible
options for such interface include OpenFlow [Ref-1], FORCES [Ref-2], use
of routing infrastructure [I-D.matsushima-stateless-uplane-vepc] or vendor
specific approaches. This specification does not mandate a approach, or a
specific protocol interface and views this interface as a generic
interface relevant more broadly for other protocol systems as well (Ex:
IPSec, L2TP, Mobile IPv6).

Regards
Sri

---

From: Brian Haberman <[email-masked]>
Date: Tue, 27 May 2014 14:58:17 -0400

Sri,
     I believe your proposed changes help clarify the text.  Go ahead
and submit an update with all the changes discussed.

Regards,
Brian

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 27 May 2014 19:00:40 +0000

Thanks Brian. We will post the revised I-D.

Regards
Sri