Re: [Gen-art] Gen-ART Last Call review of draft-ietf-opsawg-capwap-alt-tunnel-08

"Sri Gundavelli (sgundave)" <> Fri, 30 September 2016 22:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DBE87127735; Fri, 30 Sep 2016 15:17:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -16.837
X-Spam-Status: No, score=-16.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iGx0fdMTgsZB; Fri, 30 Sep 2016 15:17:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8277E1200DF; Fri, 30 Sep 2016 15:17:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=12316; q=dns/txt; s=iport; t=1475273821; x=1476483421; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pca+9oQdoclDQH/fjF83fXuzJPZ3zWzCTmk9PywGEbo=; b=gnla6eLfwStaOGSLUm9sZMehLJxzrZp4cX3v3uZ8AanYNPu3GT90N0H0 GEoyK1QUVCSBncpLQ01JVNhjk8nXOeYhsVQ0gQKPsZehgn2XAMhi/2NKZ xGV0yUMoosQ/Tkz7jb8nQXpbPRWiwGvhRxuQ4D/Cwyf7SJMq3rWn3Hrjr E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.31,423,1473120000"; d="scan'208";a="330172237"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Sep 2016 22:17:00 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u8UMH0uQ019204 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 30 Sep 2016 22:17:00 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 30 Sep 2016 17:16:59 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Fri, 30 Sep 2016 17:16:59 -0500
From: "Sri Gundavelli (sgundave)" <>
To: Paul Kyzivat <>, "" <>
Thread-Topic: Gen-ART Last Call review of draft-ietf-opsawg-capwap-alt-tunnel-08
Thread-Index: AQHSG2enUnaz1pDbw0WXnFGoHeeQAqCSeGEA
Date: Fri, 30 Sep 2016 22:16:59 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: General Area Review Team <>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-opsawg-capwap-alt-tunnel-08
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Sep 2016 22:17:04 -0000

Hi Paul,

Thanks for the review and the feedback.

I agree with your comment that we could have organized the document
better. Its many thing and bad starting point that put us here. I tried to
do that but was not ready to make so much changes. But, I will try again
to see if I can address your comment and resolve the issue to your


On 9/30/16, 3:11 PM, "Paul Kyzivat" <> wrote:

>I am the assigned Gen-ART reviewer for this draft. The General Area
>Review Team (Gen-ART) reviews all IETF documents being processed by the
>IESG for the IETF Chair. Please treat these comments just like any other
>last call comments. For more information, please see the FAQ at
>Document: draft-ietf-opsawg-capwap-alt-tunnel-08
>Reviewer: Paul Kyzivat
>Review Date: 2016-09-30
>IETF LC End Date: 2016-09-30
>IESG Telechat date: Not yet
>This draft is on the right track but has open issues, described in the
>General Impression: I was able to generally understand what this
>document is trying to do, and the details generally seem to be there.
>But I was unable to put all the pieces together to make the entire thing
>work. I think this is due to problems with the organization of the
>document and possibly some missing pieces of information. I feel this
>document needs some reorganization if it is to be understood by somebody
>new to it.
>Major: 5
>Minor: 9
>Nits:  0
>(NOTE: I had a lot of trouble classifying the level of the issues. I
>finally decided to classify the Major if there is insufficient
>information to do an implementation. But take these classifications with
>a grain of salt.)
>(1) MINOR: Normative language:
>This document clearly intends to use normative language - there are
>numerous occurrences of "MUST". However I also find a number of uses of
>"shall" (never upper case) that appear to me to be intended as normative
>(2) MINOR: Figure 4:
>This figure shows the WTP having two distinct Alternate Tunnels for
>SSID1. This seems to imply that data traffic to/from SSID1 be classified
>and routed to one or the other of these two tunnels. But I could find no
>discussion of any logic for doing this.
>(3) MAJOR: Section 3 (Protocol Considerations):
>This section has some organizational problems that make the document
>difficult to. This is hinted at by the very vague title.
>It defines three new CAPWAP message Elements, to be included in certain
>CAPWAP messages:
>- Supported Alternate Tunnel Encapsulations: is intended for inclusion
>in a CAPWAP Join Request from a WTP to an AC.
>- Alternate Tunnel Encapsulations: is intended for inclusion in an IEEE
>802.11 WLAN Configuration Request message from an AC to a WTP.
>- IEEE 802.11 WTP Alternate Tunnel Failure Indication: is intended for
>inclusion in a CAPWAP messages from a WTP to an AC. The message type(s)
>that should carry this were unclear to me, though probably evident to
>someone familiar with CAPWAP.
>An extensible set of Alternate Tunnel Encapsulation types is defined.
>These are referenced by both Supported Alternate Tunnel Encapsulations
>and Alternate Tunnel Encapsulations.
>Each of these requires specification of an Information Element used to
>configure it. The document defines only three of the these. (The
>definition of the others is deferred to future documents.) The
>definitions of these are also direct subsections of section 3, though
>they are a very different sort of thing than the earlier subsections.
>Of these three, two are quite simple and understandable. The third (GRE)
>appears to be very complex, with nested sub-elements. I was unable to
>fully decipher this. (More below.)
>(4) MINOR: Section 3.2 (Alternate Tunnel Encapsulations Type):
>Section 3.1 shows the Tunnel-Type being carried in an 8-bit field, while
>section 3.2 uses a 16-bit field. The actual values are defined in
>section 3.2 and include only values 0-6, with other values reserved for
>future use. The IANA Considerations section defines this as a 16-bit
>It might be wise to restrict this to 8-bits in the IANA considerations,
>and in section 3.2 reserve the first 8 bits of the type field, as in:
>        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
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |       0     |  Tunnel-Type  |  Info Element Length            |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |   Info Element
>        +-+-+-+-+-+-+-+-+-+
>While this section defines a new registry of tunnel types, and formats
>for descriptive information element about each, there seem to be no
>rules for defining new values.
>Also, I had trouble figuring out which portions of this document are
>defining Information Elements for use in this message, and which are
>defining something else. It would help if the description of each tunnel
>type in the list in this section had a cross reference to the section
>that defines the Information Element for that type. (But a more major
>reorganization would be better.)
>(5) MAJOR: Section 3.4 (CAPWAP based Alternate Tunnel):
>For the CAPWAP Transport Protocol Element the description mentions two
>possible values (UDP and UDP-Lite), but fails to state what encoding is
>used to designate them.
>(6) MAJOR: Section 3.6 (GRE based Alternate Tunnel):
>Based on section 3.2, I was expecting the definition of *one*
>information element format for GRE tunnels. But this section says "The
>information element*s* needed for supporting this mode are defined in
>Section 3.7 and Section 3.7.6." and proceeds to define more than one.
>And referencing both 3.7 and 3.7.6 seems at least odd. I suspect the
>reference to 3.7.6 is a mistake because there seems nothing special
>about it.
>(7) MAJOR: Section 3.7 (Alternate Tunnel Information Elements):
>It appears that sections 3.7.n define sub-elements of an overall GRE
>Information Element, but I find no definition of that overall element.
>(8) MINOR: Section 3.7.1 (Access Router Information Elements):
>This says: "The AR information may be IPv4 address, IPv6 address, or AR
>domain name." Then it has subsections defining IPv4 and IPv6 addresses.
>But I can find nothing that says how to specify a domain name.
>(9) MAJOR: Section (AR IPv4 List Element):
>This section seems to call for a constant value designating "AR IPv4
>Element Type" but I find no specification of what that value might be.
>(10) MAJOR: Section (AR IPv6 List Element):
>This section seems to call for a constant value designating "AR IPv6
>Element Type" but I find no specification of what that value might be.
>(11) MAJOR: Section 3.7.2 (IEEE 802.11 WLAN Configuration Response):
>I thought this section should be defining part of the Information
>Element for the Alternate Tunnel Encapsulation Type message element from
>the AC to the WTP. Yet this section says that it is intended to be sent
>from the WTP the the AC. This left me scratching my head as to what it
>is and where it goes.
>(12) MAJOR: Section 3.7.3 (Tunnel DTLS Policy Element):
>I don't understand where this element is intended to be inserted.
>The title of this section is "Tunnel DTLS Policy Element", but in figure
>13 the type field is called "Tunnel DTLS Element Type". Why are these
>different? Also, I find no defined numeric value for this field.
>(13) MAJOR: Section 3.7.4 (IEEE 802.11 Tagging Mode Policy Element):
>This references the 802.11 Tagging Mode Policy in RFC5416. But I was
>unable to decipher how that relates to the Alternate Tunnel
>Encapsulation Type message.
>(14) MINOR: Section 4 (IANA Considerations):
>This asks IANA to create a new registry of Alternate tunnel types. The
>only values in the registry for each type are the numeric value, a human
>friendly name, and a reference. The references are to the definitions of
>the underlying tunnel protocols.
>I understand, this isn't sufficient information to use these values. It
>is also necessary to know the format of the associated Information
>Element for each type. For *some* of the types that information is
>present in this document. For others that information is left for future
>definition, presumably in some new document.
>The registry needs to have a reference to a document specifying the
>format of the Information Element for the type.
>Also, it would be very helpful if there was a template for how to
>specify the Information Element for a type, and for this document to
>follow that format for the ones it defines.