1. March 2007TRILL WG, IETF Prague1 TRILL issue: Multicast Input Link Filtering Radia Perlman Radia.Perlman@sun.com

2. March 2007TRILL WG, IETF Prague2 TRILL Multicast Trees are now Bidirectional Ingress R1 might choose a multicast distribution other than the one rooted at R1, because: –R1 might want to do multicast multipathing, i.e., not sending all multicast it initiates on the same distribution tree –Configuration to cut down on the number of trees necessary to calculate might mean there is no tree rooted at R1

3. March 2007TRILL WG, IETF Prague3 For multicast safety, input link check is highly desirable If multicast distribution is unidirectional from the source S, you can do “RFP” check (reverse path forwarding) – only accept traffic from S from the one interface you'd use to forward traffic to S But with bidirectional tree, traffic ingress from R1 can arrive from multiple ports

4. March 2007TRILL WG, IETF Prague4 But it is still possible to do input link filtering R3 has enough information to know which link traffic with ingress=R1, on tree=R2, should arrive from Input filtering, theoretically then, could mean that you'd need n 2 state, i.e., for each of the links in that tree, the set of allowable ingress RBridges

5. March 2007TRILL WG, IETF Prague5 But suppose we could know in advance which RBridges will choose which trees? There's no reason for any RBridge to choose a lot of different trees If R1 is choosing a tree other than itself for multipathing, it will probably be configured with 2, maybe 3 possible trees to choose If R1 is choosing a tree other than itself because R1 was configured to decline being a root, then R1 would only choose 1, maybe 2 trees

6. March 2007TRILL WG, IETF Prague6 Have IS-IS announce which trees will be selected Have R1, in the core instance of IS-IS, announce which trees it will choose Nit: Not nickname, but ID – so no confusion So R1 announces –I want/don't want to be a tree root –The trees I will select are {set of RBridge IDs}

7. March 2007TRILL WG, IETF Prague7 Why this cuts down on input filtering state R3 receives a multicast packet with shim indicating tree=R2, ingress=R1 Based on core instance of IS-IS, the set of RBridges that claim they will choose tree=R2 is {R1, R2, R6, R85} Let's say R3 has 5 links in tree R2 For each of those links, R3 marks the subset of {R1, R2, R6, R85} that should arrive there Each of {R1, R2, R6, R85} must appear on exactly one link in the input filtering list

8. March 2007TRILL WG, IETF Prague8 Notes If average number of trees each RBridge says it will select is 2, and there are k trees, amount of state for input filtering is 2*k “link” is actually “adjacency” in IS-IS lingo, as in, (port, neighbor)

9. March 2007TRILL WG, IETF Prague9 Conclusions, stuff to add to specifications In IS-IS core instance LSP, announce “these are the RBridges I will choose as tree roots” Explain how, and mandate using input link filtering, in protocol document