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

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

Hi Brian,

We just posted -04 version. It includes the changes that we discussed.

Regards
Sri



On 5/27/14 12:00 PM, "Sri Gundavelli (sgundave)" <[e-mail]>
wrote:

>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
>>>>
>>
>
>_______________________________________________
>netext mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/netext