TRILL remaining issues Radia Perlman

Perhaps not exhaustive list Shim header format –Both egress and ingress? –LIDs? –F-Tag? Multicast multipathing How many trees Optimizing IP multicast Bridge root change awareness?

Ingress for unicast Ingress RBridge not obviously needed for unicast Reasons for it –Policy (such as source address filter, or preferential treatment) –Ability to learn all or some of endnode locations from data rather than LSPs –Ability to know where to send things like BCNs

Egress for Multicast Not obviously needed for multicast Possible uses: –Ability to choose a different tree than the ingress RBridge –Possibly to avoid calculating as many trees

LIDs The LID is really a port number of the endnode on the egress RBridge Ingress RBridge learns (endnode, RBridge, LID), sticks RBridge and LID in packet Egress doesn't have to look up endnode---just forwards to the specified port

LIDS Cost: just room in header: no extra work for ingress RBridge Question: Have both ingress and egress LID? Only reason for ingress LID I think: to possibly learn from data packet

Multipathing Multicast If high volume of multicast, and it's all coming from one place, only links in that one tree are used Possible solutions: –F-Tag is a metric, and multiply the number of trees by n, the number of F-tag values, and configure n costs for each link –Choose an alternate Root for distribution of the multicast

Why would it matter to have per- source spanning tree? S X

How many trees? Trees needed for multicast or unknown destination Possibilities: –One bidirectional shared tree –Per-ingress tree –Per ingress * number of F-Tags –Some limit (demanded by wimpiest bridge)

Proposal Have RBridges announce, in their link state packet “I'd like to be a tree root” Calculate a tree for each of those, with a minimum of 1 Which should be default?

Another proposal: Get rid of outer header on pt-to-pt links! If there's just a pt-to-pt link between two RBridges, no reason for outer header But NIC wants to see something that looks like an Ethernet header So therefore, it might be nice to have the shim header look like an Ethernet header

How to do this Get rid of nicknames: use full MAC address of ingress and egress RBridges If we want to use the egress RBridge field to specify which tree, and to have a flag indicating this is a multicast packet, then use the “group” bit in the destination MAC address to signal that

November 2006IETF TRILL WG13 PT = TRILL Ingress RBridge ID Egress RBridge ID Payload PT = IPv4 Original Source MAC Original Destination MAC Original Dest MAC FCS Reserved Hop Limit I/G = Individual/Group

November 2006IETF TRILL WG14 We can only do that on pt-tp-pt links So to send over a shared link (including through a bridge), need an outer Ethernet header Cost: This makes our shim bigger But we save space on pt-to-pt links Issue: How can we be sure it's a pt-to-pt link with only one possible neighbor?

Bridge Root awareness If two bridged LANs merge because of a bridge coming up, you will have two Designated RBridges simultaneously Might create a temporary problem Observation: one of the RBridges will notice the spanning tree Root has changed on the LAN (unless there's no bridges and it's a repeater that came up)

Possible enhancements Designated RBridge stops forwarding to/from the link for some time after it hears the identity of the Root bridge has changed Designated RBridge announces in its LSPs the MAC address of the Root—only stop forwarding if the new Root ID is claimed by a different RBridge Things sort out as soon as IS-IS Hello is received on the link (by either RBridge)

Even more radical enhancement Have RBridges participate in the spanning tree (but still terminating a spanning tree at each port) Make the RBridge highest priority (lowest numerical priority) for being spanning tree Root Make the same tie-breaker for spanning tree Root as Designated election

Result Spanning tree algorithm not slowed down by pre-forwarding delay So no possibility of multiple Designated RBridges beyond time when there might be multiple spanning tree Roots

IP Multicast

Overview Learn whether there's an IP multicast router on the link (based on it sending a PIM msg) Send IGMP reports to all (and only to) links with IP multicast routers Designated RBridge annouces: –Whether there's an IP multicast router on its links –{groups} with multicast receivers attached

Overview, Cont'd IP Multicast data packet –Sent to all links with receivers –Sent to all links with IP multicast routers

Algorhyme, v2, by Ray Perlner I hope that we shall one day see A graph more lovely than a tree. A graph to boost efficiency While still configuration-free. A network where RBridges can Route packets to their target LAN. The paths they find, to our elation, Are least cost paths to destination! With packet hop counts we now see, The network need not be loop-free! RBridges work transparently. Without a common spanning tree.