Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates
draft-ietf-trill-clear-correct-06

[Ballot comment]
Section 1.2 is a useful section to have at the top of the document.
I would have liked it more had it:

- listed each non-backward compatible feature (with a section
  reference) instead of saying "several"

- explained in summary how non-compatiblity is handle in
  general

[Ballot comment]
This is strictly a procedural point for the chair/shepherd; The authors may ignore this.

The ballot writeup makes me very grumpy and it makes me concerned that the chair/shepherd did not do their due diligence in passing this document to the IESG. The chair/shepherd being a former AD, I have to assume that this was just a sloppy writeup and not a real problem. But I would like to see a real writeup for the record. I did not make this a DISCUSS since I am sure this COMMENT will generate the right outcome.

The writeup template says for "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?
 
Your response was:

  There was consensus in the working group in favor of the document.

That's all you're going to say? Perhaps you'd like to add, "Unlike every other document which has gotten serious review in the IETF, this one generated no controversy at all and there were no points of contention. At the end of each face-to-face meeting, the entire WG held hands and sang songs together." :-) Seriously, we all assume there was consensus since you are submitting the document; you would not have submitted it otherwise. To make sure that due diligence was done, the answer the IESG is interested in is what the nature of the consensus was. At the very least say, "There was nothing particularly noteworthy about the consensus around this document. In the end, there was no roughness apparent for any part of the consensus." At least then we could see that you answered the question.

Then in the "Document Quality", it asks:

  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?

Your answer was:

  The document has been carefully reviewed in the WG and by the
  document shepherd.
  The document was forwarded to the IS-IS WG mailing list, which
  resulted in some additional improvements.

First of all, the document itself says that it is making non-backward-compatible changes to a protocol. I would *hope* that there is a fair bit of implementation of the new stuff already that would justify such changes. But you mention no existing implementations, nor any indication of vendors taking on such implementations, in your writeup. And as far as "reviewers that merit special mention", you call out "the WG and the document shepherd". If the WG and the document shepherd *hadn't* done thorough reviews, that would be worthy of mention; that they have done their jobs is not. (On the other hand, the IS-IS WG *is* worthy of mention.)

This document is outside of my area of expertise. The only serious review I do is look through the document for Applications impacts and look to the writeup to see that no procedural nonsense was missed. This writeup is a pretty serious miss. Please give at least some indication on the implementation question.

[Ballot comment]
Section 2.
There are two instances of "pseudo node". The ISO/IEC 10589 term is pseudonode.
(note this is correctly used in section 4)

Section 2.2 first line
s/A RBridge/An RBridge/

Section 10.1 para below bullet 2.

s/Two different encoding are providing above/Two different encodings are
provided above/  (I assume)

The instances of "encoding" look like they should  "encoding mechanisms" ?

[Ballot discuss]
The following points are derived from the RTG-DIR review by Mike Shand.

===
Section 2.1 states "Frames are not least cost routed through an
overloaded TRILL Switch if any other path is available..."

However, ISO/IEC precludes the routing of frames through an
overloaded router, even when no other path is available.
(see clause 7.2.8.1) [ note all references to ISO/IEC 10589 are to
the second edition ]

Please clarify in the text that there is no intention for TRILL to
deviate from the specified  ISO/IEC 10589 behaviour.

===

Section 2.3.1 seems relevant here, but I don't understand the
description. I must be missing something, since it would appear that
a data frame forwarded to RB2 MUST attempt to forward the frame to
ANY non-overloaded neighbor (other than the one it was received
from). However, surely that non overloaded neighbor might then have
RB2 as its next hop, and forward the frame back to RB2, which would
then be required to forward the frame possibly back to the original
RBridge from which it was received. Clearly this is not the desired
operation, so the text needs clarifying to make it clear what is
really supposed to happen.

===

Section 4 bullet 4

I THINK this is saying that the check must be made on any "new" LSP
even if the RBridge is in overload state, and cannot store the
received "new" LSP.  It may be clearer to explicitly say it must do
this even when overloaded.  The existing parenthetical remark
doesn't seem adequate.

===

The following issue was raised:
  Section 5 2nd para

  I don't understand the term "refragment LSPs".

  Is this saying that an RBridge may start with some value of
  originatingL1LSPBufferSize, and then be required to change to a
  lower value, thus necessitating that it re-generates all its LSPs
  which were previously larger than this new value?

In a subsequent discussion with the reviewer the a some clarification
was provided. Please add this clarification to the text.

===
Section 2.2 second para
"...and Bridge RB1 can similarly...."

Can is ambiguous. Is that MAY or MUST?

[Ballot comment]
Section 2.
There are two instances of "pseudo node". The ISO/IEC 10589 term is pseudonode.
(note this is correctly used in section 4)

Section 2.2 first line
s/A RBridge/An RBridge/

Section 10.1 para below bullet 2.

s/Two different encoding are providing above/Two different encodings are
provided above/  (I assume)

[Ballot comment]

- typo in abstract: s/provide/provides/ (same sentence is
correct in intro:-)

- 2nd para of section 5 is odd, it says its about the case
where nothing is known, but then says "if it is known that
other..." I'd say replacing the opening phrase with some
more specific might work, e.g. "If not all MTU information
is known for the entire campus..."

- 10.1: "...in the Down state out a port..." is an odd
phrase, maybe s/out/for/ or something?

- 10.1: What is a DRB?

- 10.2: I think this needs rephrasing/fixing: "Therefore, the DRB
SHOULD NOT appointed an RBridge in overload as Appointed Forwarder for
an VLAN unless there is no alternative." I'm not sure what it
means really.

IANA has reviewed draft-ietf-trill-clear-correct-03 and has the following comments:

IANA notes that some of the IANA Actions requested in this document are
dependent upon approval of another Internet-Draft (draft-eastlake-isis-rfc6326bis).

Upon approval of this document, IANA understands that there are three actions it
must complete.

First, in the TRILL Nicknames subregistry of the Transparent Interconnection of
Lots of Links (TRILL) Parameters registry located at:

http://www.iana.org/assignments/trill-parameters/trill-parameters.xml

A new TRILL Nickname will be registered as follows:

Name: [ TBD ]
Description: Overload Originated Multi-destination Frame (OOMF)
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested 0xFFC1 as the value for TBD.

Second, a registration is to be made in the TRILL Neighbor TLV NEIGHBOR RECORD
Flags which would be created upon completion of the IANA Actions requested in
draft-eastlake-isis-rfc6326bis. In particular, in the new TRILL Neighbor TLV
NEIGHBOR RECORD Flags, bit 1 would be allocated to indicate that the RBridge
sending the TRILL Hello volunteers to provide the OOMF forwarding service.

Note that IANA understands that this action will be completed upon the approval
of a different Internet-Draft, specifically: draft-eastlake-isis-rfc6326bis

Third, a registration is to be made in the TRILL-PORT-VER sub-TLV subregistry
created upon completion of the IANA Actions requested in
draft-eastlake-isis-rfc6326bis. Bit 0 will be allocated from the Capability
bits in the draft-eastlake-isis-rfc6326bis to indicate support of the VLANs
Appointed sub-TLV.

Note that IANA understands that this action will be completed upon the approval
of a different Internet-Draft, specifically: draft-eastlake-isis-rfc6326bis

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

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

[Ballot comment]
As this document incorporates errata reported against the other three RFCs, but leaves those three current (not Obsoleted), it would be nice to list the RFC-numbers+errata-numbers that are resolved by this document.  How hard would that be to add?

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (TRILL: Clarifications, Corrections, and Updates) to Proposed Standard


The IESG has received a request from the Transparent Interconnection of
Lots of Links WG (trill) to consider the following document:
- 'TRILL: Clarifications, Corrections, and Updates'
  as 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 2012-06-20. 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.

Abstract


  The IETF TRILL (TRansparent Interconnection of Lots of Links)
  protocol provides least cost pair-wise data forwarding without
  configuration in multi-hop networks with arbitrary topology, safe
  forwarding even during periods of temporary loops, and support for
  multipathing of both unicast and multicast traffic. TRILL
  accomplishes this by using IS-IS (Intermediate System to Intermediate
  System) link state routing and by encapsulating traffic using a
  header that includes a hop count. Since the TRILL base protocol was
  approved in March 2010, active development of TRILL has revealed a
  few errata in the original RFC 6325 and some cases that could use
  clarifications or updates.

  RFC 6327 and RFC 6439 provide clarifications and updates with respect
  to Adjacency and Appointed Forwarders. This document provide other
  known clarifications, corrections, and updates to RFC 6325, RFC 6327,
  and RFC 6439.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-trill-clear-correct/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-trill-clear-correct/ballot/


No IPR declarations have been submitted directly on this I-D.

TRILL: Clarifications, Corrections, and Updates
draft-ietf-trill-clear-correct-03

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Proposed Standard as indicated in the title page header. That is needed
since this document updates RFC 6325, RFC 6327, and RFC 6439 which are
proposed standards.

(2) 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

The IETF TRILL (TRansparent Interconnection of Lots of Links)
protocol provides least cost pair-wise data forwarding without
configuration in multi-hop networks with arbitrary topology, safe
forwarding even during periods of temporary loops, and support for
multipathing of both unicast and multicast traffic. TRILL
accomplishes this by using IS-IS (Intermediate System to Intermediate
System) link state routing and by encapsulating traffic using a
header that includes a hop count. Since the TRILL base protocol was
approved in March 2010, active development of TRILL has revealed a
few errata in the original RFC 6325 and some cases that could use
clarifications or updates.

RFC 6327 and RFC 6439 provide clarifications and updates with respect
to Adjacency and Appointed Forwarders. This document provide other
known clarifications, corrections, and updates to RFC 6325, RFC 6327,
and RFC 6439.

The clarifications, corrections, and updates cover many areas, but
the most
substantial ones are in the areas of:
- Overloaded and/or Unreachable RBridges
- Distribution Trees
- Nickname selection
- Maximum Transmission Unit

Note that one change in this document (section 3.4) is not backward
compatible with [RFC6325] but has nevertheless been adopted to reduce
distribution tree changes resulting from topology changes.

Working Group Summary

There was consensus in the working group in favor of the document.

Document Quality

The document has been carefully reviewed in the WG and by the document
shepherd.
The document was forwarded to the IS-IS WG mailing list, which
resulted in some additional improvements.

Personnel

Who is the Document Shepherd?

Erik Nordmark

Who is the Responsible Area Director?

Ralph Droms

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Reviewed the document.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The -00 version of the draft was forwarded to the IS-IS list
which resulted in comments from Mike Shand which were incorporated
in the draft.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures on this document.

(9) 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?

The document has been discussed in the WG first as an individual draft
and later as a WG draft with relatively broad participation. However,
only a few commented on the actual WG last call.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

While the abstract says "This document provide other
known clarifications, corrections, and updates to RFC 6325, RFC 6327,
RFC 6439." the id-nits tool generates comments to the effect that
the "abstract doesn't seem to directly say this". I suspect that is
because
the above "updates" text doesn't follow some unstated formatting
assumption
in the id-nits tool.

id-nits incorrectly generates a warning about a "non-RFC5735-compliant
IPv4 addresses" for the text "... Section
4.6.2.1"


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review criteria apply.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) 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 plan for their completion?

There is a normative reference to draft-eastlake-isis-rfc6326bis which
is the formal definition of the IS-IS code points and formats.
The plan is for that document to become an IS-IS WG draft and be reviewed
in the IS-IS WG. That process has already been initiated.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.

Verified that the three items in the IANA considerations section
match the text in the document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None. No part of this draft is in a formal language.

---