IEEE 802.1aq Atlanta

1
IEEE 802.1aq Shortest Path Bridging Equal Cost
Tree (ECT) Framework Proposal Peter
Ashwood-Smithincorporating graphics by Guoli
Yin incorporating MCID input from Nigel
BraggECT 3..16 from Mick Seaman (per d2-1)
1
2
Presentation Structure

• 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

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 gt 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.

3
4

• 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
  SysIID
• Winner can be tuned by adjusting BridgePriority

Min1
join
fork
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. S
PF tree shown fromeach member using Low
PathIDalgorithm. Symmetry highlighted Between
35 and 40.
N
5
6

• Tie-Breaking 15 additional algorithms allow ECT
• There are 15 additional algorithms defined,
  allows ECT diversity.
• Each starts by running a 11 permutation on the
  BridgeIDs 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 1s 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 nibble in
  8 byte mask uses same value.
• 00 ff 88 77 44 33 cc bb 22 11 66 55 aa 99
  dd ee

6
7
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
Alg9
Low PathID (alg1)
1 xor 0 11 xor FF FE 1 xor 22
23 2 xor 0 22 xor FF FD 2 xor 22
20 3 xor 0 33 xor FF FC 3 xor 22 21
High Path ID(alg 2)
D
KEY
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 If Diameter D and avgadjacency A
there are O((A-1)D) paths. What other
approaches canwe take to maximize diversity?
8
9

• There seem to be numerous different classes of
  ECT algorithm with different properties.
• Minimum/Max of some nodal identifier over paths.
• 11 Permutations of that identifier to spread min
  around.
• Operator can explicitly set identifiers to tweak
  spreading.
• Minimum/Max of some link identifier over paths.
• 11 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).

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 specbut
• 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.

10
11
The proposal full text submitted to Don Fedyk
ECT-ALGORITHM OUI24 INDEX8 OUI
00-80-C2, INDEX 0-16 defined by 802.1aq. 0STP,
1LowPathID etc. ISID ? ECT-ALGORITHM So we
expand from 8 bit Algorithm to 32 bits in SPB
Instance sub TLV. HELLO ? lt ECT-ALGORITHM,
ECT-VID, USE-FLAG gt Hello protocol carries
algorithm identifier and VID used and indication
of its current usage state for clean
migration. LSP ? lt ECT-ALGORITHM, ECT-VID,
DATA-VID, USE-FLAG gt 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.
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 ltECT-ALGORITHMgt,
  ltECT-VIDgt 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.

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
  dont 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

13