Subject: [OPSAWG] Another CAPWAP document

From: Warren Kumari <[email-masked]>
Date: Fri, 10 Apr 2015 13:08:39 -0400

Hi all,

Please take a look at "CAPWAP Control and Data Channel Separation for
Multi-provider Scenario"
(https://tools.ietf.org/html/draft-you-opsawg-capwap-separation-for-mp-00)

This document was discussed somewhat at the face to face meeting in Dallas.
We have discussed this document with our ADs and have decided that it
is sufficiently different to the CAPWAP ALT Tunnel (which is with the
IESG), and that ALT Tunnel is sufficiently fgar in the process that we
will keep this document separate...

So, please take a look at it, and provide initial feedback We will
consider having a call for adoption if there is enough evidence of
interest....

W
-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Youjianjie <[email-masked]>
Date: Mon, 13 Apr 2015 08:28:16 +0000

Hi,

This document supports the WTP establishes data tunnels with different Access Routers (ARs), which may belong to different Virtual Network Operators (VNOs).
The slides are available: https://tools.ietf.org/agenda/92/slides/slides-92-opsawg-4.pdf
Your questions and comments are appreciated.

Thanks,
Jianjie

> -----邮件原件-----
> 发件人: OPSAWG [mailto:[email-masked]] 代表 Warren Kumari
> 发送时间: 2015年4月11日 1:09
> 收件人: [email-masked]
> 主题: [OPSAWG] Another CAPWAP document
> 
> Hi all,
> 
> We have discussed this document with our ADs and have decided that it is
> sufficiently different to the CAPWAP ALT Tunnel (which is with the IESG), and
> that ALT Tunnel is sufficiently fgar in the process that we will keep this
> document separate...
> 
> So, please take a look at it, and provide initial feedback We will consider having
> a call for adoption if there is enough evidence of interest....
> 
> W
> --
> I don't think the execution is relevant when it was obviously a bad idea in the
> first place.
> This is like putting rabid weasels in your pants, and later expressing regret at
> having chosen those particular rabid weasels and that pair of pants.
>    ---maf
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]>
Date: Mon, 13 Apr 2015 20:44:38 +0000

Hello…

Can the authors explain why the problem statement for this cannot be
addressed within the framework of the
"Alternate Tunnel Encapsulation for Data Frames in CAPWAP”. Specifically,
what are the gaps ?

The alternate tunnel draft does allow for different AR to be specified for
different WLANs.
One gap is whether such capability (supporting one alternate tunnel versus
multiple alternate tunnels) needs to be negotiated or not ?

Regards

Rajesh

On 4/13/15, 1:28 AM, "Youjianjie" <[email-masked]> wrote:

>Hi,
>
>This document supports the WTP establishes data tunnels with different
>Access Routers (ARs), which may belong to different Virtual Network
>Operators (VNOs).
>The slides are available:
>https://tools.ietf.org/agenda/92/slides/slides-92-opsawg-4.pdf
>>consider having
>>idea in the
>>regret at

---

From: Youjianjie <[email-masked]>
Date: Tue, 14 Apr 2015 03:05:26 +0000

Hi Rajesh,

Thanks for the questions!

[draft-ietf-opsawg-capwap-alt-tunnel-04] describes: "the AC provides the alternate tunnel encapsulation message element containing the tunnel type and a tunnel-specific information element while configuring the WTP."
From the format of Alternate Tunnel Encapsulations Type (Figure 6), it seems only one tunnel is specified between the WTP and AR.

[draft-you-opsawg-capwap-separation-for-mp-00] focuses on the multi-VNOs scenario. When the WTP joins the AC, if the WTP services multi-VNOs (i.e. different SSID for different VNO, and user data can be directly steered to its corresponding VNO domain via the WTP and AR tunnel), then the AC should provide the WTP with multiple tunnel information (e.g. SSID, AR address for each tunnel). Actually this draft is not bound with tunnel encapsulation negotiation proposed in [draft-ietf-opsawg-capwap-alt-tunnel-04]. These two drafts can be complementary.

So I think the main gap is during the WTP configuration, what kind of information AC shall provide? Alternate Tunnel Encapsulations? multiple tunnel information for different VNOs? I think this depends on the specific scenarios.

Thanks,
Jianjie

> -----邮件原件-----
> 发件人: Rajesh Pazhyannur (rpazhyan) [mailto:[email-masked]]
> 发送时间: 2015年4月14日 4:45
> 收件人: Youjianjie; Warren Kumari; [email-masked]
> 主题: Re: [OPSAWG] 答复: Another CAPWAP document
> 
> Hello…
> 
> addressed within the framework of the "Alternate Tunnel Encapsulation for
> Data Frames in CAPWAP”. Specifically, what are the gaps ?
> 
> >>(https://tools.ietf.org/html/draft-you-opsawg-capwap-separation-for-mp
> >>-00
> >>)
> >>
> >>IESG), and  that ALT Tunnel is sufficiently fgar in the process that
> >>we will keep this  document separate...
> >>
> >> This is like putting rabid weasels in your pants, and later
> >>expressing regret at  having chosen those particular rabid weasels and
> >>that pair of pants.
> >>    ---maf
> >>