[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 _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
