Hi,


We just uploaded a new version merging all the comments we’re received.

There're no duplication or confliction with the current WG draft. Your comments 
are appreciated.



Thanks,

Jianjie





A new version of I-D, draft-you-opsawg-capwap-separation-for-mp-01.txt

has been successfully submitted by Jianjie You and posted to the IETF 
repository.



Name:               draft-you-opsawg-capwap-separation-for-mp

Revision:  01

Title:                  CAPWAP Control and Data Channel Separation for 
Multi-provider Scenario

Document date:       2015-05-25

Group:               Individual Submission

Pages:               9

URL:            
https://www.ietf.org/internet-drafts/draft-you-opsawg-capwap-separation-for-mp-01.txt

Status:         
https://datatracker.ietf.org/doc/draft-you-opsawg-capwap-separation-for-mp/

Htmlized:       
https://tools.ietf.org/html/draft-you-opsawg-capwap-separation-for-mp-01

Diff:           
https://www.ietf.org/rfcdiff?url2=draft-you-opsawg-capwap-separation-for-mp-01



Abstract:

   The CAPWAP control channel and data channel split architecture has

   some benefits, such as relieving the capacity pressure of the AC.

   However, the current documents are not specific to the multi-provider

   scenario.  This document discusses the third-party WLAN service

   provider scenario (i.e.  Virtual Network Operator, VNO), and proposes

   to extend CAPWAP for supporting this use case.


发件人: [email protected] [mailto:[email protected]]
发送时间: 2015年4月15日 21:18
收件人: Rajesh Pazhyannur (rpazhyan)" ;  Warren Kumari;  "[email protected]" ; 
Youjianjie
主题: Re:[OPSAWG] 答复: 答复: Another CAPWAP document


Hello all,

Speaking as the author of both drafts, I am thinking that 2nd will delivery 
multiple AR's information based on protocol.

We could reshape the document to not impact 1st one during the WG document 
period.

Best regards,

ZHANG Rong
------------------ Original ------------------
From: Youjianjie <[email protected]<mailto:[email protected]>>
Date: 2015年04月14日 11时36分
To: "Rajesh Pazhyannur (rpazhyan)" 
<[email protected]<mailto:[email protected]>>, Warren 
Kumari<[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Subject: [OPSAWG] 答复: 答复: Another CAPWAP document

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 protected]]

> 发送时间: 2015年4月14日 4:45

> 收件人: Youjianjie; Warren Kumari; [email protected]<mailto:[email protected]>

> 主题: 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" 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 protected]] 代表 Warren Kumari

> >> 发送时间: 2015年4月11日 1:09

> >> 收件人: [email protected]<mailto:[email protected]>

> >> 主题: [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 protected]<mailto:[email protected]>

> >> https://www.ietf.org/mailman/listinfo/opsawg

> >_______________________________________________

> >OPSAWG mailing list

> >[email protected]<mailto:[email protected]>

> >https://www.ietf.org/mailman/listinfo/opsawg

_______________________________________________

OPSAWG mailing list

[email protected]<mailto:[email protected]>

https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to