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

[Brian Haberman <[e-mail]>]

Hi Sri,

On 5/21/14 1:47 PM, Sri Gundavelli (sgundave) wrote:
> Hi Brian,
> 
> Thanks for your review comments. Please see inline.
> 
> 
> On 5/21/14 6:49 AM, "Brian Haberman" <[e-mail]> wrote:
> 
>> 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.
> 
> 
> Agree. We will update the draft to reflect consistent terminology use.
> 

Cool.

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

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