On Dec 19, 2014, at 10:05 AM, Benoit Claise <[email protected]> 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 protected]>
Date: Monday, December 1, 2014 7:37 AM
To: "Rajesh Pazhyannur (rpazhyan)" <[email protected]>,
"[email protected]"
<[email protected]>,
"[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
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 protected]>
Date: Thursday, November 20, 2014 at 12:30 AM
To: "Benoit Claise (bclaise)" <[email protected]>,
"[email protected]"
<[email protected]>,
"[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
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 protected]>
Date: Wednesday, November 19, 2014 at 11:50 AM
To: "[email protected]"
<[email protected]>,
"[email protected]"
<[email protected]>
Cc: "[email protected]" <[email protected]>
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 protected]
https://www.ietf.org/mailman/listinfo/opsawg
