I think what Zongpeng mean is: 1. Add "GRE" in section 3.2, in the line " This specification provides details for this elements for CAPWAP and PMIPv6." -->" This specification provides details for this elements for CAPWAP, PMIPv6 and GRE." Because GRE has already been discussed in this document, and there is no need to provide a specific document for GRE.
2. This document have section 3.6.6. to describe the "GRE Key Element", but no text to specify where to insert this block. So, he suggest a new section 3.6 to specify that the "GRE Key Element" information should just follow the "Access Router Information Element". Best, Tianran > -----Original Message----- > From: OPSAWG [mailto:[email protected]] On Behalf Of Duzongpeng > Sent: Tuesday, June 21, 2016 3:36 PM > To: Sri Gundavelli (sgundave); Warren Kumari; [email protected]; John > Kaippallimalil; Liu Dapeng; Mark Grayson (mgrayson) > Subject: Re: [OPSAWG] Start of 2nd WGLC for > draft-ietf-opsawg-capwap-alt-tunnel > > Hi, Sri > > Thank you for your reply. I can repeat the reason. > > In the current draft, section 3.2 > > o Info Element: This field contains tunnel specific configuration > parameters to enable the WTP to setup the alternate tunnel. This > specification provides details for this elements for **CAPWAP and > PMIPv6**. This specification reserves the tunnel type values for > the key tunnel types and defines the most common message elements. > We anticipate that message elements for the other protocols (like > L2TPv3, etc) will be defined in other specifications in the > future. > > And my suggestion is that GRE should also be provided. > Reason 1: GRE is a widely used and important tunnel type in WiFi network. > Reason 2: I used to join in the work of this draft. I think we have taken > this GRE type into consideration, but I do not know why it is missing now. > I mean that GRE type should not be considered in other drafts as L2TP or > IP-IP, and should be considered just as **CAPWAP and PMIPv6** Reason 3: > I know that we have that section "3.6.6. GRE Key Element". I think that > is just because we have taken this GRE type into consideration. But in current > draft, on one hand, it is declared that only **CAPWAP and PMIPv6**'s details > are provided; on the other hand, this section 3.6.6 provides details of > GRE. They conflicts. My suggestion is to add a new section 3.6, and change > the declaration to "This specification provides details for this elements > for **CAPWAP, PMIPv6, and GRE**" > > Hope no misunderstanding here. If any problem, please connect me. > Thanks. > > Best Regards > Zongpeng Du > > > -----Original Message----- > From: Sri Gundavelli (sgundave) [mailto:[email protected]] > Sent: Tuesday, June 21, 2016 12:15 PM > To: Duzongpeng; Warren Kumari; [email protected]; John Kaippallimalil; Liu > Dapeng; Mark Grayson (mgrayson) > Subject: Re: [OPSAWG] Start of 2nd WGLC for > draft-ietf-opsawg-capwap-alt-tunnel > > Hello Zongpeng, > > > We do have support for the following encapsulation types and we also have > a section for the GRE keys. The Access Router information element is already > there. So, I don¹t see why we need one more section. > > Can you clarify what is not clear from the below text ? > > ‹- > o Tunnel-Type: The tunnel type is specified by a 2 byte value. This > specification defines the values from zero (0) to five (5) as > given below. The remaining values are reserved for future use. > > * 0: CAPWAP. This refers to a CAPWAP data channel described in > [RFC5415][RFC5416]. > > Zhang, et al. Expires December 10, 2016 [Page > 12]Internet-Draft Alternate-- Tunnel June 2016 > > * 1: L2TP. This refers to tunnel encapsulation described in > [RFC2661]. > > * 2: L2TPv3. This refers to tunnel encapsulation described in > [RFC3931]. > > * 3: IP-in-IP. This refers to tunnel encapsulation described in > [RFC2003]. > > * 4: PMIPv6-UDP. This refers to the UDP tunneling encapsulation > described in [RFC5844]. > > * 5: GRE. This refers to GRE tunnel encapsulation as described > in [RFC2784]. > > * 6: GTPv1-U. This refers to GTPv1 user plane mode as described > in [TS29281]. > > ‹- > > > > ‹- > > 3.6.6. GRE Key Element > > If a WTP receives the GRE Key Element in the Alternate Tunnel > Encapsulation message element for GRE selection, the WTP must insert > the GRE Key to the encapsulation packet (see [RFC2890]). An AR > acting as decapsulating tunnel endpoint identifies packets belonging > to a traffic flow based on the Key value. > > The GRE Key Element field contains a four octet number defined in > [RFC2890]. > > Zhang, et al. Expires December 10, 2016 [Page > 19]Internet-Draft Alternate-- Tunnel June 2016 > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | GRE Key Element Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | GRE Key | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 15: GRE Key Element > > GRE Key: The Key field contains a four octet number which is inserted > by the WTP according to [RFC2890]. > > > > > > 3.6.1. Access Router Information Elements > > > Š > > > > > On 6/16/16, 5:33 AM, "OPSAWG on behalf of Duzongpeng" > <[email protected] on behalf of [email protected]> wrote: > > >Hi, > > > >Generally, I support the adoption of the draft. > > > >I have posted a suggestion about adding the GRE tunnel type for the > >draft. Will the author consider it? Thanks. > > > >http://www.ietf.org/mail-archive/web/opsawg/current/msg04165.html > > > >Best Regards > >Zongpeng Du > > > > > >-----Original Message----- > >From: OPSAWG [mailto:[email protected]] On Behalf Of Warren > >Kumari > >Sent: Thursday, June 16, 2016 2:04 AM > >To: [email protected]; John Kaippallimalil; Liu Dapeng; > >[email protected] > >Subject: [OPSAWG] Start of 2nd WGLC for > >draft-ietf-opsawg-capwap-alt-tunnel > > > >Dear OpsAWG WG, > > > >This begins a WGLC for draft-ietf-opsawg-capwap-alt-tunnel - this WGLC > >ends on June 29th. > > > >This is the second WGLC for this document - it initially successfully > >passed WGLC in August 2014 > >(https://www.ietf.org/mail-archive/web/opsawg/current/msg03522.html) > >and was handed to the IESG for publication in early September 2014. > > > >After it was sent to the IESG (in Feb 2015) a very similar draft > >appeared > >- draft-you-opsawg-capwap-separation-for-mp. We realized that two, very > >similar documents, with significant overlap would be confusing, and so > >we requested that draft-ietf-opsawg-capwap-alt-tunnel be returned to > >the WG and asked the authors to merge them into one document. There was > >some delays, but this has finally been completed. > > > >The WG is requested to review the document and provide (clear) feedback > >on if you believe it is ready for publication. If not, please provide > >suggestions for improvement / text. > > > >Please note: Even if you said it was great on the first WGLC, it is > >very useful to repeat this comment now! > > > >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] > >https://www.ietf.org/mailman/listinfo/opsawg > > > >_______________________________________________ > >OPSAWG mailing list > >[email protected] > >https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
