TRILL Routing Requirements in Support of RBridges
draft-ietf-trill-routing-reqs-02

[Ballot comment]
The issue with this document is that it does not correctly or adequately specify the requirements to be built into the IGP(s). The overall point of the document is this sentence from Sect 3:

"
From the perspective of simply extending existing routing protocols,
  IS-IS is a more appropriate choice than OSPF because it is easy in
  IS-IS to define new TLVs for use in carrying a new information type.
"

I suggest that since the rest of the doc is describing vague concept of requirements for routing protocols and vague statements about bridging, we merge the information into the architecture document and do not progress this document.

[Ballot discuss]
Working with these folks I know that extensions and desired functionality in the protocols (e.g. ISIS) is rapidly changing. I am uncomfortable accepting this doc until the thrash reduces and the functional requirements are correctly captured in this doc.

[Ballot discuss]
Working with these folks I know that extensions and desired functionality in the protocols (e.g. ISIS) is rapidly changing. I am uncomfortable accepting this doc until the thrash reduces and the functional requirements are correctly captured in this doc.

[Ballot discuss]
Security Considerations

The security considerations begin with "The goal is not to add additional security issues over what would be present with traditional bridges and routers."  This section does not clearly identify the security issues present with traditional bridges and routers.  (I interpret the subsequent text as considerations to avoid adding additional security issues.)  A reference to an appropriate specification is needed.

The final paragraph in the security considerations is tantalizing but is not specific enough for readers.  Please provide examples or a reference!

References

I am okay with the sole normative reference, but a number of protocols/specifications are mentioned and deserve an informative reference.  OSPF, IS-IS, and IEEE 802 specifications come to mind; there may be others.

[Ballot comment]
1. Basic acronyms should be expanded at first occurence, starting with TRILL, STP, RSTP, etc.

2. IEEE standards should be referred when talking about IEEE 802.1 protocols like STP, RSTP

3. Section 1 s/restart only after STP/RSTP is complete/restart only after STP/RSTP computation and convergence is complete

4. Section 1 - 'we hope to gain the benefits of both technologies' - 'hope' sounds bad in a requirements documents, I would suggest to better use something like 'aim'

[Ballot discuss]
1. The document has a lot of references and impact to IEEE 802.1 bridging. There is however no information in the PROTO write-up about the document having been discussed and reviewed with IEEE 802.1. I would like to know if this happened and suggest to have this information included in the write-up and mentioned in the Protocol Quality section of the announcement.

2. The Abstract makes a dull mention that 'The design allows for zero configuration of switches within an RBridge domain ...'. This seems to be over-exagerated if we refer to further information that is included in Section 1.2 where the requirement is for (near) zero configuration and only 'for a sub-set of all possible deployment scenarios by making realistic restrictions on deployment'. I would suggest that these statements are coordinated.

3. There is not information or requirement about how a transition between a current network built our of a hierarcy of IEEE 802.1 bridged newroks and routers will make the transition to a TRILL network. Is network redesign necessary. Can Rbridges be mixed in existing networks, or shoudl they be located in separate domains? Can existing bridges or routers be upgraded to become RBridges? Can RBridges act as standard IEEE 802.1 bridges or routers and have TRILL activated without interrupting network operation?

4. Section 3 mentions the usage of a well-known Ethernet/802 multicast address as a potential distinguishing mechanism for TRILL Link State Routing Protocol. IEEE 802 multicast addresses are very scarce resources administered by IEEE 802 and I would recommend that a determination is made at this phase whether such an address is needed, otherwise this option may not be feasible at all.

5. There are no manageability requirements in the document. How are Rbridges supposed to be managed? IEEE 802.1 bridges use quite a sophisticated set of MIB modules for management, including for configuration by SNMP. Will a network of Rbridges be managed in a similar manner, or differently?

[Ballot discuss]
1) Security

Rbridges must be selective about the parties with whom they form routing adjacencies. (You wouldn't want to form a routing adjacency with a layer 1 adjacent device that is in somebody else's network.)

To this end, each interface may be configured with a switch that determines whether the routing protocol runs on that interface. Another approach would be to authenticate routing messages.

2) Could you say a little about how broadcast works in an rbridged network. If a router broadcasts a layer 3 datagram over an rbridged network with an interesting topology, who receives the datagram?

[Ballot discuss]
This document proposes that ARP and ND could be optimized by the
rbridge.  Presumably that means that an rbridge can respond to ND
messages and avoid forwarding them.  For ARP, that sort of makes
sense; ARP is not a very extensible protocol.  However for ND, how
would an rbridge handle extensions to ND?  How would this interact
with Secure ND and other future work?  What steps must we take to make
sure that optimizations of this type do not negatively impact our
ability to extend IPV6 etc.  Please describe the discussions with the
IPV6 community that lead to this requirement to confirm that these
issues have adequately been considered.

[Ballot comment]
Please explain "STP/RSTP" the first time it appears, which is before
  one gets to the terminology section.

  In section 4.1, the document says "Ethernet/802.1 link."  Elsewhere,
  "Ethernet/802" is used to talk about a aspects of a LAN or MAC.  It is
  inot clear to me what is meant here.

  s/r-bridge/RBridge/

  s/802/IEEE 802/ (in many places)

[Ballot discuss]
Why does a requirements document contain a Conclusions section?

  The document abstract should tell the reader the definition of TRILL.
  TRILL appears in the document title after all.

[Ballot comment]
Section 9.1., paragraph 1:
>    [TARCH]  "TRILL RBridge Architecture", Gray, E. Editor - Work in
>            Progress.

  Which document is this referring to - draft-ietf-trill-rbridge-arch?

PROTO Write-up

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

Donald Eastlake 3rd.
Yes.

  (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 working group is quite active in reviewing documents and this document had WG consensus and passed WG Last Call. No specific review by non-WG members occurred.

Working Group Last Call:
Initiation:
http://www.postel.org/pipermail/rbridge/2006-October/001458.html
Conclusion:
http://www.postel.org/pipermail/rbridge/2006-November/001776.html

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

This high level document has a normative reference to the Rbridge architecture document which is not at the same state of maturity.
However, as discussed with the Responsible AD, a request to publish is being made at this time. Per the TRILL charter we need this document to be able to formally select the routing protocol to use, which formally needs to precede a routing group WG doing their extensions. It is also believed that foreseeable changes to the architecture document are unlikely to require changes to this less detailed document.

The following royalty free reciprocal type IPR disclosure relates to all work in the TRILL WG including this document:
https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=439
There has been no discussion of IPR for this document in the working group that I can recall

  (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 broad 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
          http://www.ietf.org/ID-Checklist.html 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?

There are no nits but one warning that the document does not have an "intended status" section and one warning that the normative reference "might" be a downref (which it is not).

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

Yes, references are split. "The Architecture of an RBridge Solution to TRILL"
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt
by the same author is a normative reference not yet ready for advancement but not a downward reference. See answer 1.d above.

  (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 [RFC2434].  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?

Yes. No IANA actions.

  (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. There are no such sections.

  (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

RBridges provide the ability to have an entire domain, with multiple physical links, look to IP like a single subnet. The design allows for zero configuration of switches within an RBridge domain, optimal pair-wise routing, safe forwarding even during periods of temporary loops, and potential additional advantages as well.  The design also supports VLANs, allows forwarding tables to be based on destinations within the RBridge domain (rather than station destinations, allowing internal forwarding tables to be smaller than in conventional bridge systems).

The intent is to re-use one or more existing routing protocols to accomplish these goals.

This document lays out the background and specific requirements of potential routing protocols to be considered for use in this design. In particular, this document defines what is needed to accommodate this design using IS-IS (or OSPF) as a basis for RBridge protocols.

          Working Group Summary

This document has working group consensus.

          Document Quality

This document is of good quality.

          Personnel

The Document Shepherd for this document is Donald Eastlake 3rd. The Responsible Area Director is Mark Townsley.

  (end)