march 2007trill wg, ietf prague1 trill issue: multicast input link filtering radia perlman...

March 2007 TRILL WG, IETF Prague 1

TRILL issue:Multicast Input Link Filtering

Radia [email protected]


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


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


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 n2 state, i.e., for each of the links in that tree, the set of allowable ingress RBridges


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


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}


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


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)


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

march 2007trill wg, ietf prague1 trill issue: multicast input link filtering radia perlman...

Documents