Subject: [rbridge] [Fwd: Submitting TRILL protocol for AD review]

From: Erik Nordmark <[email-masked]>
Date: Tue, 01 Dec 2009 00:50:03 -0800

-------- Original Message --------
Subject: Submitting TRILL protocol for AD review
Date: Mon, 30 Nov 2009 10:02:19 -0800
From: Erik Nordmark <[email-masked]>
To: Ralph Droms <[email-masked]>
CC: Donald Eastlake <[email-masked]>, Jari Arkko <[email-masked]>

Here is the PROTO writeup.

Let me know if you have any questions.

     Erik

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

I, Erik Nordmark, TRILL Working Group co-chair, is the Document
Shepherd. I have have personally reviewed version 14 of the document and
I believes it is ready for forwarding to the IESG for publication.
(The document is of quite high technical and editorial quality - better than
any document of this size that I recall reading as an AD.)

(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 unusually thorough review. There were two Working
Group Last calls, once on draft -10 and one on draft -13. (The biggest
technical change between -10 and -13 was to fix an MTU related problem
that was detected during testing of a software implementation of the
-10 draft by Jim Carlson.) The draft has been reviewed by the
active working group participants over an extended period of time. From
the nature of many of the questions and comments from the reviewers it is
clear that many of them are reviewing the document from the perspective of
an implementor wanting to ensure that things will work correctly and also
interoperate with other implementations. Such careful review bodes well
for future interoperability testing.

The WG last call was also explicitly sent to the IS-IS WG and the MTU
problem was resolved in consultation with participants in IS-IS.

In addition, as required by its Charter, the Working Group requested
that IEEE 802.1 review the draft. Their response included some
critical but non-specific comments on the draft. It also asserted that
TRILL is "incompatible" with 802.1 provider and provider backbone
bridging when it is just that TRILL does not supply these services. As
a result, the draft was clarified to emphasize that TRILL as described
in this base protocol document supplies only customer bridging
services, and does not supply provider or provider backbone services,
but that 802.1 provider or provider backbone bridges may be used to
interconnect parts of a TRILL campus.

Finally, the draft was thoroughly reviewed by two independent IETF
experts, Bernard Aboba and Dan Romascanu, as required by the TRILL
Charter. These expert comments have been resolved, resulting in the
bulk of the changes between version -13 and version -14.

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

I have no such concerns.

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

I do not have any specific concerns or issues with the document.

The only IPR disclosure related to this document is the original
disclosure by Sun Microsystems granting royalty free use of all Sun
IPR required to implement mandatory parts of the resulting standard on
a reciprocal bases as detailed here:
https://datatracker.ietf.org/ipr/439/

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

There is a solid consensus behind advancing this document.

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

There have been no threatened appeals (or actual appeals for that
matter).

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

I've run it through idnits. FWIW idnits confuses section numbers with IPv4
addresses and outputs:
tmp/draft-ietf-trill-rbridge-protocol-14.txt(3402): Found possible IPv4 address '4.6.1.2' in position 35; this doesn't match RFC3330's suggested 192.0.2.0/24 example address range, or the suggested 233.252.0.0/24 example multicast address range.
tmp/draft-ietf-trill-rbridge-protocol-14.txt(3441): Found possible IPv4 address '4.6.2.4' in position 63; this doesn't match RFC3330's suggested 192.0.2.0/24 example address range, or the suggested 233.252.0.0/24 example multicast address range.

No MIB doctor or other formal review criteria applies.

(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 are split, there are no downward references, and no
normative references are to works in progress.

(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 sections exists and, consistent with the rest
of the document, creates two new registries. No code points in
existing IANA registries are allocated. The new registries do not use Expert
Review.

This document also has an IEEE registration considerations section, as
two Ethertype allocations are required. In addition, the allocation of a
block of 16 multicast MAC addresses is required. The working group
consensus was that these multicast addresses should be allocated under
the IEEE standards OUI rather than the IANA OUI. The IEEE Registration
Authority routinely allocates code points without charge for other
standards development organizations.

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

There are no such sections in this document.

(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

The TRILL protocol provides optimal pair-wise forwarding without
configuration, safe forwarding even during periods of temporary loops,
and support for multipathing of both unicast and multicast traffic. It
achieves these goals using IS-IS routing and encapsulation of traffic
with a header that includes a hop count. Devices implementing TRILL
are called RBridges or Routing Bridges.

RBridges are compatible with previous IEEE 802.1 customer bridges as
well as IPv4 and IPv6 routers and end nodes. They are as invisible to
current IP routers as bridges are and, like routers, they terminate
the bridge spanning tree protocol. As customer devices, RBridges do
not supply provider or provider backbone bridging services but
provider or provider backbone bridges may be used to interconnect parts
of an RBridge campus.

The design supports customer VLANs and optimization of the
distribution of multi-destination frames based on VLAN and IP derived
multicast groups.  It also allows unicast forwarding tables at transit
RBridges to be sized according to the number of RBridges (rather than
the number of end nodes), which allows these forwarding tables to be
substantially smaller than in conventional customer bridges.
 
   Working Group Summary 

The working group process included two working group last calls (an
MTU problem was discovered by an implementor after the first WG last
call thus a second last call was done to make sure the MTU changes had
sufficient review) as well as the usual review by working group members.
In addition, the working group charter required special reviews by IEEE
802.1 and two reviews by independent IETF experts.  As the combined
result of all of these steps, the document received an unusually
thorough review.

   Document Quality 

The document is high quality due to the unusually thorough reviews it
has been subject to. An earlier version was implemented by Sun
Microsystems and the lessons learned were incorporated. Independent
IETF experts Dan Romascanu and Bernard Aboba did particularly thorough
reviews and their comments were resolved. Several implementations are
underway although not publicly announced.

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge