Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship

From: Benoit Claise <[email-masked]>
Date: Wed, 25 Feb 2015 10:24:14 +0100

Dear draft-ietf-opsawg-capwap-alt-tunnel authors,

I put this draft in AD watching status, as opposed to AD review. This is 
the correct state.

Regards, Benoit
> Hi Benoit
>
> Yes, I am working on it.
> I will get you a date by the end of the week of when a draft will be ready.
>
> Thanks
>
> Rajesh
>
> On 1/20/15, 5:40 AM, "Benoit Claise (bclaise)" <[email-masked]> wrote:
>
>> Dear draft-ietf-opsawg-capwap-alt-tunnel and
>> draft-xue-opsawg-capwap-alt-tunnel-information authors,
>>
>> Can you please a draft version according to Sri's plan below.
>>
>> Regards, Benoit
>>> wfm
>>>
>>>> On Dec 19, 2014, at 10:05 AM, Benoit Claise <[email-masked]> wrote:
>>>>
>>>> On 03/12/2014 08:59, Sri Gundavelli (sgundave) wrote:
>>>>> Hi Benoit,
>>>>>
>>>>>> Let me propose a solution: augment
>>>>>> draft-ietf-opsawg-capwap-alt-tunnel with the information elements for
>>>>>> CAPWAP (not the others one).
>>>>> The above draft defines number of encapsulation modes and that list
>>>>> includes, CAPWAP, L2TPv2, L2TPv3, IP-in-IP, PMIPv6, GREv4 and GREv6.
>>>>> Each of those tunnel types can be activated with a set of tunnel
>>>>> parameters. These parameters include source IP, destination IP, sport,
>>>>> dport, GRE key ..etc. To most part this is about identifying a common
>>>>> set of parameters, providing definition for those parameters and
>>>>> grouping the relevant one's for each of the encapsulation modes.
>>>>> Taking GREv4, GREv6, IP-in-IP or PMIP (uses GRE), each are not
>>>>> radically different from the others and the above common parameter set
>>>>> is sufficient for these modes.  To create a tunnel with GRE with IPv4
>>>>> transport is not any different from GRE with IPv6 transport, or for
>>>>> that matter for IP-in-IP mode.
>>>>>
>>>>> It is to be noted there are no proposed changes to any of these
>>>>> encapsulation modes, or to the control protocols activating those
>>>>> encap modes. Its mostly about activating a         tunnel state with a
>>>>> set of parameters.  If at all, CAPWAP data plane may be bit complex
>>>>> and even L2TP as its unclear if the control protocol has semantics for
>>>>> the L2TP peers to separate control and data plane. If not, it requires
>>>>> changes to the L2TP protocol. So, its easier to keep CAPWAP +
>>>>> GRE/IP-in-IP modes in the main spec as the work has a well defined
>>>>> scope.
>>>> If it works for the WG, it works for me. Any objections anybody?
>>>> That would imply a new draft and a new consensus call.
>>>>
>>>> Regards, Benoit
>>>>> So, my suggestion is to allow draft-ietf-opsawg-capwap-alt-tunnel  to
>>>>> also support GRE/IP-in-IP modes and have draft-xue focus exclusively
>>>>> on L2TP extensions and move it on a fast track. IMO, this is a
>>>>> reasonably split.  I'm also happy to provide the text for the above
>>>>> encap modes and ensure the changes do not delay the publication.
>>>>>    
>>>>>
>>>>> Regards
>>>>> Sri
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> From: "Benoit Claise (bclaise)" <[email-masked]>
>>>>> Date: Monday, December 1, 2014 7:37 AM
>>>>> To: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]>,
>>>>> "[email-masked]"
>>>>> <[email-masked]>,
>>>>> "[email-masked]"
>>>>> <[email-masked]>
>>>>> Cc: "[email-masked]" <[email-masked]>
>>>>> Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and
>>>>> draft-xue-opsawg-capwap-alt-tunnel-information relationship
>>>>>
>>>>> Hi Rajesh,
>>>>>
>>>>> I'm concerned that:
>>>>> - draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete
>>>>> solution
>>>>> - draft-ietf-opsawg-capwap-alt-tunnel requires the encoding from
>>>>> draft-xue-opsawg-capwap-alt-tunnel-information, an individual draft.
>>>>> - draft-xue-opsawg-capwap-alt-tunnel-information covers 6 different
>>>>> tunnel types, and required expertise from many different group. This
>>>>> might take some time...
>>>>>
>>>>> Let me propose a solution: augment
>>>>> draft-ietf-opsawg-capwap-alt-tunnel with the information elements for
>>>>> CAPWAP (not the others one). This way, this draft would be a complete
>>>>> solution.
>>>>> And if people wants alternate tunnel types, this would be done in
>>>>> draft-xue-opsawg-capwap-alt-tunnel-information
>>>>>
>>>>> Regards, Benoit
>>>>>
>>>>>> Hello
>>>>>>
>>>>>> I realized there was a typographical error in my response below.
>>>>>> Please see corrections.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Rajesh
>>>>>> From: Rajesh Pazhyannur <[email-masked]>
>>>>>> Date: Thursday, November 20, 2014 at 12:30 AM
>>>>>> To: "Benoit Claise (bclaise)" <[email-masked]>,
>>>>>> "[email-masked]"
>>>>>> <[email-masked]>,
>>>>>> "[email-masked]"
>>>>>> <[email-masked]>
>>>>>> Cc: "[email-masked]" <[email-masked]>
>>>>>> Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and
>>>>>> draft-xue-opsawg-capwap-alt-tunnel-information relationship
>>>>>>
>>>>>> Hi Benoit
>>>>>>
>>>>>> But now I wonder: why do we have two different drafts, as opposed to
>>>>>> a single one?
>>>>>>
>>>>>> This is a good question.
>>>>>>
>>>>>> [original] Yes, you are correct that
>>>>>> draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete
>>>>>> solution and needs something like
>>>>>> draft-ietf-opsawg-capwap-alt-tunnel to complete the solution.
>>>>>> [corrected statement] Yes, you are correct that
>>>>>> draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete
>>>>>> solution and needs something like
>>>>>> draft-xue-opsawg-capwap-alt-tunnel-information to complete the
>>>>>> solution.
>>>>>>
>>>>>> The best answer I have is  that we wanted the keep the following two
>>>>>> areas separate (and in different drafts)
>>>>>> 	€ Discover and negotiation of alternate tunneling capability. These
>>>>>> are  independent of specific alternate tunnel method
>>>>>> 	€ [original] Definition of tunnel specific message elements. While
>>>>>> draft-ietf-opsawg-capwap-alt-tunnel contains message elements for
>>>>>> most of the tunneling methods defined in
>>>>>> draft-ietf-opsawg-capwap-alt-tunnel, I had anticipated separate
>>>>>> drafts for each tunneling protocol.
>>>>>> [corrected] 2 Definition of tunnel specific message elements. While
>>>>>> draft-ietf-opsawg-capwap-alt-tunnel contains message elements for
>>>>>> most of the tunneling methods defined in
>>>>>> draft-xue-opsawg-capwap-alt-tunnel-information I had anticipated
>>>>>> separate drafts for each tunneling protocol.
>>>>>>
>>>>>> Finishing 1. would allow 2. to be completed separately and
>>>>>> independently in potentially different drafts (and potentially
>>>>>> different groups with relevant expertise). It is somewhat akin
>>>>>> (though not identical) to separation between RFC 5415 and RFC 5416
>>>>>> where RFC 5415 is wireless technology independent and RFC 5416 is
>>>>>> 802.11 specific.
>>>>>>
>>>>>> Hope the above  makes sense.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Rajesh
>>>>>> From: "Benoit Claise (bclaise)" <[email-masked]>
>>>>>> Date: Wednesday, November 19, 2014 at 11:50 AM
>>>>>> To: "[email-masked]"
>>>>>> <[email-masked]>,
>>>>>> "[email-masked]"
>>>>>> <[email-masked]>
>>>>>> Cc: "[email-masked]" <[email-masked]>
>>>>>> Subject: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and
>>>>>> draft-xue-opsawg-capwap-alt-tunnel-information relationship
>>>>>>
>>>>>> Dear CAPWAP authors,
>>>>>>
>>>>>> After the draft-xue-opsawg-capwap-alt-tunnel-information
>>>>>> presentation at the last IETF meeting, I've been wondering about the
>>>>>> relationship between the two drafts:
>>>>>> - draft-ietf-opsawg-capwap-alt-tunnel provides the tunnel types
>>>>>>     Note:this draft is currently in AD review, so close to be sent to
>>>>>> the IESG.
>>>>>> - draft-xue-opsawg-capwap-alt-tunnel-information provides the
>>>>>> encoding of the tunnel-specific fields.
>>>>>>
>>>>>> I believe I'm correct that the draft-ietf-opsawg-capwap-alt-tunnel
>>>>>> doesn't provide a complete solution without
>>>>>> draft-xue-opsawg-capwap-alt-tunnel-information?
>>>>>>
>>>>>> I'm aware of the changes between version 3 and 4 (attached picture
>>>>>> and
>>>>>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-alt-tunnel
>>>>>> -04.txt)
>>>>>>
>>>>>> But now I wonder: why do we have two different drafts, as opposed to
>>>>>> a single one?
>>>>>>
>>>>>> Regards, Benoit
>>>>>>
>>>>>>
>>>>> .
>>>> _______________________________________________
>>>> OPSAWG mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/opsawg
>>> .
>>>
> .
>