[trill] Benjamin Kaduk's practice ballot (No Objection) on draft-ietf-trill-directory-assisted-encap-10 (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

[incoming AD ramping up on document review; please treat as No
Objection with COMMENT]


RBridge is not defined in the document and it looks like only
"RBridge Channel" is marked as "well-known" in
https://www.rfc-editor.org/materials/abbrev.expansion.txt (but not
"RBridge" itself); perhaps I am misreading that page.


The qualitative differences in behavior between the cases where the
directory is known to (not) be complete seem worth mentioning in the
Introduction.  Maybe something like:

    When the directory is known to be complete, additional efficiency
    gains are possible: TRILL-ENs can drop packets for which there is no
    valid destination, and RBridges that know that all attached end
    nodes pre-encapsulate packets, unencapsulated packets can be dropped
    as well.

or does that exclude the MAC address ingress filtering that the
RBridge can perform?


I would have benefitted from a legend for Figure 1.  At first I was
confused as to the difference between the 'T' nodes and the
vSwitches (and thus whether the vSwitches were outside the TRILL
Domain).


I'm not sure I understand the possible consequences of the TRILL-EN
spoofing the ingress nickname as that of the AF while still being
able to send it to/through any RBridge on its local link.  Is the
ingress nickname only used for return routing, in which case it
seems like the consequence is just that the AF just gets some extra
load, or are there other uses of it?  (This seems related to
Alvaro's DISCUSS.)


Section 5.1:

   For a large Data Center with hundreds of thousands of virtualized
   servers, setting the TRILL boundary at the servers' virtual switches
   will create a TRILL domain with hundreds of thousands of RBridge
   nodes, which has issues of TRILL Nickname exhaustion and challenges
   to IS-IS. On the other hand, setting the TRILL boundary at
   aggregation switches that have many virtualized servers attached can
   limit the number of RBridge nodes in a TRILL domain, but introduces
   the issue of very large MAC&VLAN <-> Edge RBridge mapping tables to
   be maintained by RBridge edge nodes.

I could use a little more text on how the large MAC&VLAN <-> Edge
RBridge mapping issue is avoided.


Security considerations:

OLD:
   The mechanism described in this document requires TRILL-ENs to be
   aware of the MAC address(es) of the TRILL edge RBridge(s) to which
   the TRILL-EN is attached and the egress RBridge nickname from which
   the destination of the packets is reachable. 

Do they need to know as a prerequisite, or do they learn this
information during the course of operation?  Maybe

NEW:
   The mechanism described in this document involve TRILL-ENs
   learning the MAC address(es) of the TRILL edge RBridge(s) to which
   the TRILL-EN is attached and the egress RBridge nickname from which
   the destination of the packets is reachable. 

Though it seems like this is just a subset of directory access,
which itself involves a lot of information about the TRILL topology.
Maybe it's better to phrase things in terms of that directory access
itself?

-Benjamin