1. Advertising ECMP Routes in BGP Joel Halpern Manav Bhatia Paul Jakma 65 th IETF – Dallas, TX

2. Requirements for an ECMP algorithm MUST be able to advertise individual BGP paths to other multipath capable peers. MUST preserve maximum path information and should be regular expression friendly Path length MUST be retained when advertising routes to non multipath capable peers

3. ECMP Capability Uses MULTIPLE_HOP Capability Defines a new bit in the bitmask of flags +-------+---+---+---+---+---+---+------+----+ | Bit: | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------+---+---+---+---+---+---+------+----+ | flag: | R | R | R | R | R | R | ECMP | AE | +-------+---+---+---+---+---+---+------+----+

4. How does this work within an AS? R1 R2 RR R3 10.0.0.0/8 AS_PATH: X Y Z NEXT_HOP: N1 10.0.0.0/8 AS_PATH: A B C NEXT_HOP: N2 10.0.0.0/8 AS_PATH: X Y Z NEXT_HOP: N1 10.0.0.0/8 AS_PATH: A B C MULTIPLE_HOP: N2 (BGP RIB) *>i 10.0.0.0/8 N2 A B C ? *>i 10.0.0.0/8 N1 X Y Z ? #sh ip route B 10.0.0.0 [170/0] via nexthop to the RR #sh ip route B 10.0.0.0 [170/0] via N1 Assuming that R3 can reach N1 and N2 independently and not via the RR AS 65530

5. Advertising to an EBGP/non Multipath capable IBGP peer R3 *>i 10.0.0.0/8 N2 A B C ? *>i 10.0.0.0/8 N1 X Y Z ? R4 10.0.0.0/8 ORIGIN: INCOMPLETE AS_PATH: {65530} [A X] [B Y] [C Z] AS 61000 AS 65530