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

[Brian Haberman <[e-mail]>]

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

Regards,
Brian


On 5/27/14 1:05 PM, Sri Gundavelli (sgundave) wrote:
> 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
>>