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

["Sri Gundavelli (sgundave)" <[e-mail]>]

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


Regards
Sri




On 9/30/16, 3:11 PM, "Paul Kyzivat" <[e-mail]> 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
><​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
>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
>
>Summary:
>
>This draft is on the right track but has open issues, described in the
>review.
>
>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.
>
>Issues:
>
>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
>statements.
>
>(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
>value.
>
>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 3.7.1.1 (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 3.7.1.2 (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.
>