Telechat Review of draft-ietf-opsawg-capwap-alt-tunnel-08
review-ietf-opsawg-capwap-alt-tunnel-08-genart-telechat-kyzivat-2016-10-21-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-opsawg-capwap-alt-tunnel-08-genart-telechat-kyzivat-2016-10-21

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 wait for direction from your document 
shepherd or AD before posting a new version of the draft. 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-10-21
IETF LC End Date: 2016-09-30
IESG Telechat date: 2016-10-27

Summary:

(Note: the document is unchanged since last call, so this is a repeat of 
my last-call review.)

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.