wfm > 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
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
