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

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?

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.

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?

  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.

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.

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.