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
