[trill] directory cmt

[Erik Nordmark <[e-mail]>]

Some questions and comments on the draft from the perspective of one WG 
participant (i.e., without my chair hat).

Also, I hope this will stimulate some WG discussion and getting more 
folks to read and comment on the draft.

In the abstract (and repeated in the introduction) we have:
    Edge RBridges currently learn the mapping between MAC addresses and
    their egress RBridges by observing the data packets traversed
    through. When an ingress RBridge receives a data frame with its
    destination address (MAC&VLAN) unknown, the data frame is flooded
    within the VLAN across the TRILL campus.
The above text doesn't take into account the existence of ESADI. It 
makes sense to reword it to state that data-plane learning is mandatory 
and ESADI is optional, and that flooding occurs when ESADI is not used.

The following sentence (also in the abstract *and* intro) seems 
unrelated to the topic of the draft, since the draft doesn't talk about 
changing AF (and I don't see how a directory can change how AF works):
    When there are more than
    one RBridge ports connected to one bridged LAN, only one of them can
    be designated as the Appointed Forwarder port for
    forwarding/receiving native traffic to/from each VLAN, the other
    RBridge ports on that LAN have to be disabled for native traffic in
    that VLAN.

In section 5 you list the benefits, but the list doesn't include any 
benefits related to getting the ARP/ND information from the directory.
Shouldn't that be added? [But also see the last comment below]

In section 5 you have:
    [IP, MAC, attached RBridge nickname, {list of interested RBridges}]
I suspect VLAN (or FGL) should be added to the above list.
I think ESADI allows a <MAC,VLAN> or <IP,VLAN> be attached to more than 
one RBridge, which would imply that a table with the above structure 
would have multiple attached RBrudge nicknames.
Also, a host can definitely have multiple IPv4 and IPv6 addresses on the 
same network interface, resulting in multiple rows in the above table 
that only differs in the IP address.

It isn't clear to me if the "list of interested RBridges" is needed. It 
assumes that it is cost-effective to track everybody that might have 
cached the information and do selective update of those RBridges, as 
opposed to sending updates to any RBridge interested in that VLAN. In 
any case, the list of interested only applies to a pull model.


In Table 1 there are no IP addresses; I would assume that they would be 
pushed as well.

In section 5.3 there is a description of how RBridges cache the 
information from the directory, but there is no discussion of how that 
cached information would be updated should the destination (IP, MAC, 
VLAN) change. There should at least be a sentence saying that there 
needs to be a mechanism for the directory to invalidate or update cached 
information when that information is stale due to a change in the 
directory content.

Finally I was under the impression that the draft would reduce ARP/ND 
traffic by leveraging getting IP->MAC address bindings from the 
directory. But I don't see any text about this for push nor pull.
As currently specified the document doesn't reduce any ARP/ND traffic - 
it merely optionally uses ARP/ND packets to trigger directory lookups. 
Hence I'm a bit confused about the scope of the draft.

I was assuming that the draft would specify that an ingress rbridge 
would intercept ARP requests (and Neighbor Solicitations) and use the 
information from the directory (whether push or pull) to unicast the 
ARP/NS to the egress rbridge, thereby avoid flooding the ARP/ND to all 
the rbridges in the VLAN.

    Erik