IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging
draft-ietf-isis-ieee-aq-05

[Ballot comment]
I support Tim's discuss.

Also, is this draft going to be held by the RFC editor while the 802.1aq draft goes final?  The normative reference is to a DRAFT of the IEEE spec.

[Ballot discuss]
The security considerations state:
   
  If zero configuration methods are used to auto configure NNIs or
  UNIs there are intrinsic security concerns that should be mitigated
  with authentication procedures for the above cases. Such procedures
  are beyond the scope of this document.

While these procedures are beyond the scope of this document, it would be helpful to identify which procedures the authors have in mind (or note that such procedure have yet to be developed).

[Ballot comment]
From Richard Barnes secdir review:

This document defines a set of additional sub-TLVs for IS-IS that enable IS-IS nodes to communicate information related to the IEEE 802.1aq Shortest Path Bridging system.
The Security Considerations section of the document claims that these extensions do not create any additional security risks.

This may be the case, but I found it difficult to evaluate this claim given a basic knowledge of IS-IS and none of 802.1aq.  My high-level impression is that the negotiations conducted through the mechanism defined in this document have the ability to affect layer-2 routing in new ways, with the implication that malicious actors in the protocol have new ways to influence traffic patterns or deny service to users.

It would be helpful if the Security Considerations could explain why such manipulations are not possible using these extensions (which would seem to defeat the purpose of the extensions), or if they are, what assumptions need to be true in order for the protocol to operate properly.  Do all internal network elements need to behave as specified?  Only the SPB instances?

[Ballot comment]
I agree with Dan Romascanu's DISCUSS regarding lower-case conformance keywords -- they are confusing.

In Section 17, please expand "DOS" to "Denial of Service" and add a reference to RFC 4732.

[Ballot discuss]
1. The following convention is defined for the document in Section

>  The lower case forms "must", "must not", "shall", "shall not",
  "should", "should not" and "may" in this document are to be
  interpreted in the sense defined in [RFC2119], but are used where
  the normative behavior is defined in documents published by SDOs
  other than the IETF.

There are two problems here that attracted my attention:

- should really any form of "must" or "should" ,etc. that appears in this document be interpreted in the sense defined in [RFC2119]? This does not seem to be the intention, and I would prefer to make clear that this interpretation applies only in the sections that deal with the IEEE 802.1 documents.

- The keywords "recommended" and "optional" are missing from the list. Is this intentional? While I could not find any instances of "recommended" I did find a few instances of "optional" which I would think should be interpreted in the sense defined in [RFC2119] - for example in section 4.1

2. In the IANA considerations section:

> The MT-Capability TLV is the only TLV requiring a new sub-registry.
  Type value 144 (TBD) is requested, with a starting sub-TLV value of
  1, and managed by Standards Action. 
   
Is really Standards Action necessary? Why would not Expert Review be sufficient?

IANA has questions about the IANA Actions related to this document.

IANA understands that five separate actions are required to be completed
upon approval of this document.

First, the value 0xC1 has been assigned in the NLPIDs registry located at:

http://www.iana.org/assignments/nlpids/nlpids.xhtml

IANA understands that no further action is required regarding this.

Second, IANA understands that three new sub-TLVs are to be added to the
MT-Port-Capability TLV. IANA understands that these sub-TLVs are:

SPB-MCID
SPB-Digest
SPB-B-VID

IANA Question --> IANA is unable to locate the current registration for
the MT-Port-Capability TLV. Is this TLV being registered via a separate
document? If the registration is already in place, could the authors
provide a URL that points to it?

Third, a new TLV is to be registered in the TLV Codepoints Registry in
the IS-IS TLV Codepoints located at:

http://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml

as follows:

Value: TBD
Name: MT-Capability
IIH: n
LSP: y
SNP: n
Reference: [RFC-to-be]

Fourth, a new sub-TLV registry is to be created for the new TLV
codepoint created for MT-Capability. This sub-TLV registry will be
located at:

http://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml

The sub-TLV registry will have four initial assignments, as follows:

SPB-Inst
SPB-I-OALG
SPBM-SI
SPBV-ADDR

IANA Question --> What are the registration procedures for this new
sub-TLV registry?

Fifth, in the Sub-TLVs for TLV 22, 141, and 222 subregisty of the IS-IS
TLV Codepoints registry located at:

http://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml

two new sub-TLVs are t be registered as follows:

Type: TBD
Description: SPB-Metric
22: y
141: n
222: y
Reference: [RFC-to-be]

Type: TBD
Description: SPB-A-OALG
22: y
141: n
222: y
Reference: [RFC-to-be]

IANA understands that these are the only actions required to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

To: IETF-Announce 
From: The IESG
Reply-to: ietf@ietf.org
CC:
Subject: Last Call: draft-ietf-isis-ieee-aq (IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging) to Proposed Standard

The IESG has received a request from the IS-IS for IP Internets WG (isis)
to consider the following document:

- 'IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging '
    as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-01-18. Exceptionally,
comments may be sent to iesg@ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-isis-ieee-aq-03.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=20343&rfc_flag=0

Please note that this document makes normative reference to ISO/IEC 10589:2002

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?


David Ward


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?


The document has had lengthy review by the ISIS WG. There are no issues with the TLVs as currently defined.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?


No



(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

There are no specific concerns and no known IPR.


(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?


Strong consensus


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)


No


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the
Internet-Drafts Checklist

and
http://tools.ietf.org/tools/idnits/
). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?


The doc passes nits and it is believed all formal review criteria has been met.



(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].


The references appear correctly formatted.


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?


The IANA considerations appear correct


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Yes

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.


802.1aq Shortest Path Bridging (SPB) is being standardized by the
IEEE as the next step in the evolution of the various spanning tree
and registration protocols. 802.1aq allows for true shortest path
forwarding in a mesh network context utilizing multiple equal cost
paths. This permits it to support much larger layer 2 topologies,
with faster convergence, and vastly improved use of the mesh
topology. Combined with this is single point provisioning for
logical connectivity membership (E-LINE/E-LAN/E-TREE etc).

The control protocol for 802.1aq is IS-IS augmented with a
small number of TLVs while the encapsulating data paths are
respectively 802.1ad (Provider Bridges) and 802.1ah (Provider
Backbone Bridges). This memo documents those TLVs while
providing some overview.

Note that 802.1aq requires no state machine or other substantive
changes to. It is an intention that 802.1aq be simply a new
NLPID and set of TLVs.


Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?


There was nothing special in the review once this technology was split into it's own document.


Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?


There are known, multiple implementations and there has been public interoperability testing. An implementation report is forthcoming though not part of this draft.