Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms
RFC 8171

I would like to see some more information related to the overall operation of the network, including guidance on how/when to use different mechanisms and their location.  Specifically, I think this document should include more information in these cases:

[1] Server Learning and Advertisement of information in ESADI [RFC7357] using the Reachable MAC Addresses TLV [RFC6165].

I don't think it is explicit in the document, but I'm assuming that the Servers (for both Push and Pull) learn using the mechanisms in Section 4.8.1. (Learning End-Station Addresses) of RFC6325.  One of those mechanisms is to use ESADI...Section 2.5 (Additional Push Details) says:

   TRILL switches, whether or not they are a Push Directory server, MAY
   continue to advertise any locally learned MAC attachment information
   in ESADI [RFC7357] using the Reachable MAC Addresses TLV [RFC6165].
   However, if a Data Label is being served by complete Push Directory
   servers, advertising such locally learned MAC attachment generally
   SHOULD NOT be done as it would not add anything and would just waste
   bandwidth and ESADI link state space. An exception might be when a
   TRILL switch learns local MAC connectivity and that information
   appears to be missing from the directory mapping.

It seems to me that a switch advertising information in ESADI using the Reachable MAC Addresses TLV is independent of whether Push or Pull is being used on the network (or for a specific Data Label), so I think my questions/comments below apply to both.

I understand why using the information in the Reachable MAC Addresses TLV may be redundant, but as the text points out, there are cases where it may be a good thing.  I would like to see guidelines or suggestions on the use of "traditional" ESADI learning (RFC7357) in Section 4. (Directory Use Strategies and Push-Pull Hybrids).  This section already talks about what a TRILL switch may do if it doesn't have complete information, but it doesn't talk about what a Directory Server could do.

Related to the above, if ESADI [RFC7357] using the Reachable MAC Addresses TLV [RFC6165] does't really add anything to the Push Directory service, then it seems to me that they would be equivalent (the outcome is the same) -- when should one be used over the other?  Are there cases where the centralized service may not scale and is better to adopt a distributed strategy?  It seems to me than the options in Section 4. (Directory Use Strategies and Push-Pull Hybrids) may not be just between Pull and Push...


[2] Location and Priority of Push Directory Servers

Section 2.2 (Push Directory Servers) talks about PushDirPriority, but there are no guidelines as to how it should be set by an operator.  I suspect that a higher priority may want to be assigned to Directory Servers with a higher density of connected high-use stations...or maybe not, which is why I would like you to provide some guidance.


[3] Location and Number of Requests for Pull Directory Servers

Section 3.(Pull Model Directory Assistance Mechanisms) reads:

   If multiple data reachable TRILL switches indicate in the link state
   database that they are Pull Directory Servers for a particular Data
   Label, pull requests can be sent to any one or more of them but it is
   RECOMMENDED that pull requests be preferentially sent to the server
   or servers that are lowest cost from the requesting TRILL switch.

Are there guidelines related to the location (and number) of these servers?

When would a switch not send a request to the server(s) with the lowest cost?  IOW, why "RECOMMENDED" and not "MUST"?

How many servers should the request be sent to?  For the Push case, a default of 2 copies is specified -- should 2 requests be enough?  Are there cases where more are needed?

Since this document implies the creation of centralized databases of addressing information, I think it would help to call out in Section 6 the need to secure the directory contents themselves, not just against abuses of the push or pull services but in general against unauthorized access.

Also, I recall in prior evaluations of TRILL documents some discussion about how TRILL deals with ephemeral MAC addresses and my recollection is that they are likely prohibited by policy on TRILL networks. But if there is some interaction between ephemeral MAC addresses and the services described in this document that would be good for implementors to be aware of, those are probably worth mentioning.

In this text,

      It might learn that information from
      the directory or could query the directory if it does not know.

is "learning information from the directory" different from "querying the directory"? My apologies for not knowing TRILL well.

I found this text,

     A Push Directory also advertises whether or not it
     believes it has pushed complete mapping information for a Data Label.

to be odd ("directories believe things?"), and I'm wondering what that belief would be based on. If a Push Directory has pushed all the information it's currently storing, is that what's being described here? Or does this mean something else?

In section 2.3.1, there are several states that refer to "enough time for propagation" - for example,

   Active Completing <S4>:  Same behavior as the Active state except
      that the server responds differently to events. The purpose of
      this state is to be sure there has been enough time for directory
      information to propagate to subscribing edge TRILL switches before
      the Directory Server advertises that the information is complete.

Is it possible to provide a pointer or reference that describes how "enough time" is calculated? I'm not sure whether this is referring to PushDirTimer in Section 2.7 or something else.

It's a nit, but I think this text,

      TRILL switches, whether or not they are a Push Directory server, 

should be something like

      TRILL switches, whether or not they are Push Directory servers, 

- there's a numbering mismatch.

I think this text,

   Thus, there is commonly a
   small window during which the an RBridge using directory information
   might either (1) drop or unnecessarily flood a frame as having an
   unknown unicast destination or (2) encapsulate a frame to an edge
   RBridge where the end station is not longer connected when the frame
   arrives at that edge RBridge.

is garbled (somewhere around "during which the an RBridge").

In this text,

   Support of TRILL ES-IS is generally optional for both the TRILL
   switches and the end stations on a link but may be required to
   support certain features.

can you give any guidance to the reader on how to know whether TRILL ES-IS support is required for a feature?

- 2.6: I wondered why this was useful. Is it for cases where
the secondary push service is differently connected or is it
in case the primary goes down? Might be good to say.

- section 6: what security mechanism differences are there
between the push and pull cases? Why aren't those called out
here?  Forcing the reader to delve into the various other
security mechanism RFCs and figure this out themselves seems
less good.

- section 6: apologies if I asked this before (in which case I
forget the answer;-) but how fictional/real is the crypto
stuff with TRILL in terms of the likelihood of it being
actually used? I ask again, as if the crypto stuff is mostly
fictional, then I think you ought note that here, given the
attack surface that the directory function creates.