Subject: Re: [OPSAWG] 答复: 答复: Another CAPWAP document

From: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]>
Date: Tue, 14 Apr 2015 15:15:49 +0000

Hello Jianjie

On 4/13/15, 8:05 PM, "Youjianjie" <[email-masked]> wrote:

>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.

The current draft does allow for different AR to be provided for different
SSIDs. So it should support the scenario you describe.
Could you take another look at the draft and see if there any gaps.

>
>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.

The AC provided information (AR, etc) is on a WLAN basis.

>
>Thanks,
>Jianjie
>
>
>> -----邮件原件-----
>> 发件人: Rajesh Pazhyannur (rpazhyan) [mailto:[email-masked]]
>> 发送时间: 2015年4月14日 4:45
>> 收件人: Youjianjie; Warren Kumari; [email-masked]
>> 主题: Re: [OPSAWG] 答复: Another CAPWAP document
>> 
>> 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
>> >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,
>> >>
>> >> 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
>> >>
>> >> _______________________________________________
>> >> OPSAWG mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/opsawg
>> >_______________________________________________
>> >OPSAWG mailing list
>> >[email-masked]
>> >https://www.ietf.org/mailman/listinfo/opsawg
>