Transparent Interconnection of Lots of Links (TRILL) Distributed Layer 3 Gateway
draft-ietf-trill-irb-14

Just a couple of nits:

- Please expand TRILL in the abstract.

- Figure 1: I see what ToR means, but what about AGG and COR? (I can guess, but a definition would be helpful.)

Here is Scott Bradners' OPS directorate review:
I performed an OPS-DIR review of draft-ietf-trill-irb-13.txt.

Summary: the technical specification seems ready to be published but
management considerations are not mentioned.

I found the document to be a confusing read, likely because it is not easy to
explain the forwarding behavior but I expect that the document is clear
enough to implement from.

What I did not find was any discussion of management - maybe that is
covered in the MIB or OAM documents listed in the TRILL charter.
If so, it might be good to reference the right documents.  If not, then it
would be good to have some suggestions about what to instrument for management.

Balloting no objection based on the interaction with Donald Eastlake, assuming some text will be provided: 
The configuration information is visible in the link state database. A
reference to the appropriate OAM documents could be added.

Regards, Benoit

Scott Bradner performed the opsdir review.

In reading the draft and security considerations, I had the same concern as Stephen's second point.  Are there any security issues if the session is not encrypted?  I see the concern for sensitive data and that is good, but are any exploits possible if the session is not encrypted (like on the tenantID as Stephen asked).

Two minor comments:

1) There are only few SHOULDs and MUSTs in this whole document 
   and where they are used it is often not very clear what the action 
   is that should follow and how it should be implemented 
  (e.g. "The network operator MUST ensure the consistency of the 
   tenant ID on each edge RBridge for each routing domain."). 
  And maybe there are actually more case where normative 
  language should be used? 
  Please double-check the use of normative langauge in this document!

 2) A similar question on the following part:
  „If a tenant is deleted on an edge RBridge RB1, RB1 SHOULD re-
   advertise the local tenant Data Label, tenant gateway MAC, and
   related IP prefixes information of the rest tenants to other edge
   RBridges. […] Therefore the transient routes consistency won't 
  cause issues other than wasting some network bandwidth.“
  Wasting network resources actually can be an issue. 
  So why is this not an MUST?

- section 5: The tenant ID is sometimes described as "globally
unique" and sometimes (in 5.2) as "throughout the campus." The
latter seems likely correct to me. (As an aside, is this document
the first to introduce that concept to TRILL?)

- section 8: If IS-IS security is not actually used, (is that the
current deployment reality btw?) and if I can guess a tenant ID then
what new mischief can happen? If there is some, then perhaps you
ought recommend that tenant ID's be randomly selected within the
campus? (I see you use "1" in the example, which is pretty easy to
guess:-) I think one could argue that that (and maybe more) ought be
covered in section 8, if the current deployment reality is that no
crypto is actually used to protect most IS-IS traffic. Is it?

Thanks for addressing the issues in my DISCUSS and COMMENTs.