Subject: [trill] directory cmt

From: Erik Nordmark <[email-masked]>
Date: Wed, 14 Nov 2012 15:42:18 -0800

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

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 14 Nov 2012 16:03:15 -0800

[Resent with a better subject to make it easier to correlated emails to 
internet-drafts. Please respond to this email.]

In section 5 you have:

    Erik

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 15 Nov 2012 20:49:09 +0000

Erik, 

Thanks for the comments. 
Replies and answers are inserted below:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Erik Nordmark
> Sent: Wednesday, November 14, 2012 5:42 PM
> To: Tina TSOU; Donald Eastlake
> Cc: [email-masked]
> Subject: [trill] directory cmt
> 
> 

[Linda] Flooding still occurs for unknown DA even when ESADI is used. Just that the chance for unknown DA is less when ESADI is used. 

>     RBridge ports on that LAN have to be disabled for native traffic in

[Linda] The description was intended for the feasibility of AF port being removed when data frames are pre-encapsulated by directory assisted smart end nodes. It was later suggested to separate Smart Node pre-encapsulation to a separate draft. I will clean this part. 

> Shouldn't that be added? [But also see the last comment below]

[Linda] will add. 

> I suspect VLAN (or FGL) should be added to the above list.

[Linda] will add. 

> would have multiple attached RBrudge nicknames.

[Linda] good catch. Will add.

> that only differs in the IP address.
[Linda] When a host has multiple IP addresses, there would be multiple entries in the table. Those different IP Addresses are viewed as different targets by remote notes, what needs to be said here?  

If those addresses are in different VLANs, then there will be multiple VLAN ids. 

> any case, the list of interested only applies to a pull model.

[Linda] they should be applicable to Push model too because directory only need to push them to interested RBridges instead of all. 

> In Table 1 there are no IP addresses; I would assume that they would be

[Linda] Yes. 

> information when that information is stale due to a change in the

[Linda] The detailed mechanism draft has the description of "aging timer" for entries being pulled or pushed. 

> Hence I'm a bit confused about the scope of the draft.

[Linda] Yes. 

> the rbridges in the VLAN.

[Linda] this is described in the detailed mechanism. I can add this description in the framework too if it is beneficial. ( but I don't want to repeat too much information in both drafts). 

> 
>     Erik
> 
> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill