IEEE 802.1aq Shortest Path Bridging Equal Cost Tree (ECT) Framework Proposal

1. IEEE 802.1aq Shortest Path Bridging Equal Cost Tree (ECT) Framework Proposal Peter Ashwood-Smithincorporating graphics by:Guoli Yinincorporating MCID input from:Nigel BraggECT 3..16 from: Mick Seaman (per –d2-1) IEEE 802.1aq Atlanta 1

2. There are strict requirements on ECT algorithms compatible with SPB : we summarise these Nonetheless, a number of different algorithms have been identified and successfully prototyped : we give a couple of examples So what is the best way to preserve rigour and allow future algorithm innovation ? Define an extensible Framework (compatible with previous work). and populate it initially with currently known and validated algorithms Presentation Structure IEEE 802.1aq Atlanta 2

3. Algorithm requirements review: • Shortest paths computed by SPB must be symmetric and downstream congruent. • Symmetry required for: • Learning in the case of SPPV • Ingress checking (SA lookup miss => discard) for SPPM • Downstream congruence required for: • Hop by hop destination-based (DA/VID) forwarding, every hop agrees on same ‘rest of path’, so state scales O(N) vs. O(N2) • Equal cost shortest paths computed by SPB must be resolved by a technique which is independent both of the direction of computation and the location in the topology of the computing node. IEEE 802.1aq Atlanta 3

4. 1 3 6 5 2 4 Min=2 • Tie-Breaking – base algorithm • When only one shortest path there is no issue. • When two equal min sum of link metric paths exist must deterministically pick 1. • Basic tie breaker is called LowPathID : • a lexicographically ordered list of the BridgeIds forming the Path • LowPathId will pick path with the minimum BridgeId between fork/join points. • LowPathId is trivial to implement in Dijkstra, just backtrack when join occurs: • Track min BridgeId on each path until they converge (fork point). • LowPathId is the path with the min of the two mins between fork/join. • BridgeId = BridgePriority concatenated with SysID • Winner can be tuned by adjusting BridgePriority Min=1 fork join IEEE 802.1aq Atlanta 4

5. HOW DOES IT WORK IN PRACTICE? Animated GIF, run interactive to view. Low PathIDAs applied to a 7member E-LANISID 100 all members supportboth transmit/receive. SPF tree shown fromeach member :using Low PathIDalgorithm. Symmetry highlighted Between 35 and 40. N IEEE 802.1aq Atlanta 5

6. Tie-Breaking – 15 additional algorithms allow ECT • There are 15 additional algorithms defined, allows ECT diversity. • Each starts by running a 1:1 permutation on the BridgeID’s with XOR against known (network-global) masks. • The LowPathID algorithm #1 is run after XOR with mask 0x0 (no change). • For example, algorithm #2 will invert all the bytes in the BridgeID. • We have been calling this ‘highPathId’ so uses all 1’s as its mask. • Each of the other 14 algorithms uses a different bit mask to XOR the BridgeIDinto a new unique permutation. • We implement all 16 by XOR-ing with the mask and finding min of min. • The masks are as follows (in hex), each byte in 8 byte mask uses same value. • 00 ff 88 77 44 33 cc bb 22 11 66 55 aa 99 dd ee IEEE 802.1aq Atlanta 6

7. N = min {BridgeID XOR MASK[i]} #N = Bridge ID EXAMPLE ECT diversity for Algorithms 1,2 and 9 #S BridgeIDINPUT #1 #2 #3 XOR-MASKsRESULT 0 | FF | 221 | FE | 23 0 | FF | 222 | FD | 20 0 | FF | 223 | FC | 21 Alg=9 Low PathID (alg=1) #1 xor 0 = 1#1 xor FF = FE #1 xor 22 = 23 #2 xor 0 = 2#2 xor FF = FD #2 xor 22 = 20 #3 xor 0 = 3#3 xor FF = FC #3 xor 22 = 21 High Path ID(alg = 2) #D KEY IEEE 802.1aq Atlanta 7

8. Animated GIF, run interactiveto view. HOW DOES IT WORK IN PRACTICE? • 8 X ECT • 66 nodes Metro style • 8 x ECT • 36 node DS-style/fat • HUGE improvement over • Low/high PathID (x 2 ECT). • But routes get missed because:I made 2 ‘tweak’s to priorities toget this result. • If Diameter = D and avgadjacency = A there are: • O((A-1)D) paths. • What other approaches canwe take to maximize diversity? IEEE 802.1aq Atlanta 8

9. There seem to be numerous different classes of ECT algorithm with different properties. • Minimum/Max of some nodal identifier over paths. • 1:1 Permutations of that identifier to spread min around. • Operator can explicitly set identifiers to tweak spreading. • Minimum/Max of some link identifier over paths. • 1:1 Permutations of that link identifier to spread min around. • Operator can override link id to tweak spreading. • Minimum/Max of a sum of a secondary metric. • Hash produces the secondary metric. • User can override the secondary metric to tweak spreading. • Algorithms which consider previous ECT algorithms path usage to increase diversity. (Requires serial run instead of parallel). IEEE 802.1aq Atlanta 9

10. Since there seems to be a rich area of research to look into new ECT algorithms and with proper ECT diversity a form of traffic engineering emerges. • So we propose: • Fix the 16 ECT algorithms as defined in –d2-1 and advance the spec…but • Include a framework that allows new ECT algorithms to be implemented. • Framework to include hello/LSA policies & TLVs for safe migration. • Framework includes concept of Opaque ECT-DATA on a node or link basis forfuture ECT algorithms. • Vendors/Researchers and future standards work can build into this framework without changes to IETF ISIS work or even IEEE 802.1aq. • Vendors could sell proprietary ECT behaviors or publish informational. • Other standards bodies can add custom behaviors, Data Center etc. IEEE 802.1aq Atlanta 10

11. The proposal – full text submitted to Don Fedyk • ECT-ALGORITHM ::= OUI:24 || INDEX:8 • OUI = 00-80-C2, INDEX 0-16 defined by 802.1aq. 0=STP, 1=LowPathID etc. • ISID  ECT-VID  ECT-ALGORITHM • So we expand from 8 bit Algorithm to 32 bits in SPB Instance sub TLV. • HELLO  { < ECT-ALGORITHM, ECT-VID, USE-FLAG > } * • Hello protocol carries algorithm identifier and VID used and indication of its current usage state for clean migration. • LSP  { < ECT-ALGORITHM, ECT-VID, DATA-VID, USE-FLAG > }* • Announces support for given algorithm and the VID to use. SPBM ECT-VID • and DATA-VID are the same and are just the B-VID. Otherwise SPBV then • ECT-VID is Base-VID and DATA-VID is the SPVID. • LSP OPAQUE-NODE-ECT-TLV || ECT-ALGORITHM … ECT-DATALSP  OPAQUE-LINK-ECT-TLV || ECT-ALGORITHM … ECT-DATA • Allows future expansion. IEEE 802.1aq Atlanta 11

12. ECT MIGRATION • USE-FLAGs should be advertised when ISIDs reference an ECT-ALGORITHM. • Hellos should set USE-FLAG if they are locally referencing or remotely seeing references to the ECT-ALGORITHM. • Adjacency permitted if { <ECT-ALGORITHM>, <ECT-VID> } * match. • If mismatch for a given ECT-ALGORITHM the adjacency is allowed only ifUSE-FLAG not set on at least one end. • this allows a new ECT-ALGORITHM to be introduced gradually whilst the network continues running the current production algorithm • Must not locally use an ECT-ALGORITHM unless all adjacencies agreeon ECT-VID. • This should permit a new ECT-ALGORITHM to be turned on, advertisedand then migrated to. • It also permits movement away from an ECT-ALGORITHM and then thedeprecation of that ECT-ALGORITHM network wide once no longer in use. IEEE 802.1aq Atlanta 12

13. MCID – migration issues (SPB only) • It may not be possible to accurately populate the VID space a priori. • and since we do not want to take down an adjacency just because we are adding a new un anticipated VID • We propose to allow an AUX-MCID to be advertised. • An adjacency is not rejected if the primary MCIDs don’t match as longas there is a match of the AUX-MCID with the primary MCID. • i.e. either the primary OR the auxiliary MCID of one bridge must match the primary MCID of the other to keep the adjacency up. • This allows configuration of one end of a link followed by out of sync configuration of the other end without loss of adjacency. • Responsibility for ensuring that primary and auxiliary MCIDs represent compatible super/sub-sets of VIDs lies with the network administrator • but in-service upgrade of this sort is not for the amateur anyway IEEE 802.1aq Atlanta 13