TRILL remaining issues

Radia PerlmanRadia.Perlman@sun.com

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?

93

4

117

10

14

2 5

6

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 2006 IETF TRILL WG 13

PT = TRILLIngress RBridge ID

Ingress RBridge IDEgress RBridge ID

Egress RBridge ID

Payload

PT = IPv4Original Source MAC

Original Source MACOriginal Destination MAC

Original Dest MAC

FCS

Reserved Hop Limit

I/G = Individual/Group

November 2006 IETF TRILL WG 14

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 seeA graph more lovely than a tree.

A graph to boost efficiencyWhile still configuration-free.

A network where RBridges canRoute 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.