Hi Benoit Yes, I am working on it. I will get you a date by the end of the week of when a draft will be ready.
Thanks Rajesh On 1/20/15, 5:40 AM, "Benoit Claise (bclaise)" <[email protected]> wrote: >Dear draft-ietf-opsawg-capwap-alt-tunnel and >draft-xue-opsawg-capwap-alt-tunnel-information authors, > >Can you please a draft version according to Sri's plan below. > >Regards, Benoit >> 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
