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]
<mailto:[email protected]>>
Date: Monday, December 1, 2014 7:37 AM
To: "Rajesh Pazhyannur (rpazhyan)" <[email protected]
<mailto:[email protected]>>,
"[email protected]
<mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>,
"[email protected]
<mailto:[email protected]>"
<[email protected]
<mailto:[email protected]>>
Cc: "[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[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] <mailto:[email protected]>>
Date: Thursday, November 20, 2014 at 12:30 AM
To: "Benoit Claise (bclaise)" <[email protected]
<mailto:[email protected]>>,
"[email protected]
<mailto:[email protected]>"
<[email protected]
<mailto:[email protected]>>,
"[email protected]
<mailto:[email protected]>"
<[email protected]
<mailto:[email protected]>>
Cc: "[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[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] 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 protected]
<mailto:[email protected]>>
Date: Wednesday, November 19, 2014 at 11:50 AM
To: "[email protected]
<mailto:[email protected]>"
<[email protected]
<mailto:[email protected]>>,
"[email protected]
<mailto:[email protected]>"
<[email protected]
<mailto:[email protected]>>
Cc: "[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[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
