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

["Sri Gundavelli (sgundave)" <[e-mail]>]

Hi Brian,

Sorry for the delay. Please see inline.


On 5/22/14 4:57 AM, "Brian Haberman" <[e-mail]> wrote:

>Hi Sri,
>
>>>
>>> 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.


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


How about the following text:

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



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
















>
>Or am I missing something?
>
>Regards,
>Brian
>