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

From: Benoit Claise <[email-masked]>
Date: Mon, 01 Dec 2014 16:37:43 +0100

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] <mailto:[email-masked]>>
> Date: Thursday, November 20, 2014 at 12:30 AM
> To: "Benoit Claise (bclaise)" <[email-masked] 
> <mailto:[email-masked]>>, 
> "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>, 
> "[email-masked] 
> <mailto:[email-masked]>" 
> <[email-masked] 
> <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[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] Y/es, 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)
>
>  1. Discover and negotiation of alternate tunneling capability. These
>     are  independent of specific alternate tunnel method
>  2. [*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] 
> <mailto:[email-masked]>>
> Date: Wednesday, November 19, 2014 at 11:50 AM
> To: "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>, 
> "[email-masked] 
> <mailto:[email-masked]>" 
> <[email-masked] 
> <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[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
>
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 3 Dec 2014 07:59:18 +0000

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.

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]<mailto:[email-masked]>>
Date: Monday, December 1, 2014 7:37 AM
To: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[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

Regards

Rajesh
From: Rajesh Pazhyannur <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 20, 2014 at 12:30 AM
To: "Benoit Claise (bclaise)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[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)

  1.  Discover and negotiation of alternate tunneling capability. These are  independent of specific alternate tunnel method
  2.  [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.

Regards

Rajesh
From: "Benoit Claise (bclaise)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 19, 2014 at 11:50 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[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

---

From: Benoit Claise <[email-masked]>
Date: Fri, 19 Dec 2014 16:05:57 +0100

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
>
>
>
>
>
>
> To: "Rajesh Pazhyannur (rpazhyan)" <[email-masked] 
> <mailto:[email-masked]>>, 
> with the information elements for CAPWAP (not the others one). This 
> way, this draft would be a complete solution.
>> <mailto:[email-masked]>" 
>> <[email-masked] 
>> 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.
>>
>> <mailto:[email-masked]>" 
>> <[email-masked] 
> .

---

From: "Scott O. Bradner" <[email-masked]>
Date: Fri, 19 Dec 2014 10:08:16 -0500

wfm

> On Dec 19, 2014, at 10:05 AM, Benoit Claise <[email-masked]> wrote:
> 
>> From: "Benoit Claise (bclaise)" <[email-masked]>
>> To: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>> Cc: "[email-masked]" <[email-masked]>
>>> From: Rajesh Pazhyannur <[email-masked]>
>>> To: "Benoit Claise (bclaise)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>>> Cc: "[email-masked]" <[email-masked]>
>>> 	• 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.
>>> From: "Benoit Claise (bclaise)" <[email-masked]>
>>> To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>>> Cc: "[email-masked]" <[email-masked]>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg