TRILL remaining issues Radia Perlman [email protected].
-
Upload
rachel-eaton -
Category
Documents
-
view
222 -
download
1
Transcript of TRILL remaining issues Radia Perlman [email protected].
TRILL remaining issues
Radia [email protected]
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.