IESG state changed to AD is watching from AD Evaluation::AD Followup 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 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
