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

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

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

Regards
Sri



On 5/27/14 11:58 AM, "Brian Haberman" <[e-mail]> wrote:

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