Subject: [OPSAWG] ID Tracker State Update Notice: <draft-ietf-opsawg-capwap-alt-tunnel-04.txt>

From: IETF Secretariat <[email-masked]>
Date: Wed, 25 Feb 2015 01:23:10 -0800

IESG state changed to AD is watching from AD Evaluation::AD Followup
On 1/20/15, 5:40 AM, "Benoit Claise (bclaise)" <[email-masked]> 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-masked]> 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/