IS-IS WG - IETF 71 Summary Route with Detailed Reachability George Swallow, Clarence Filsfils,...

11
IS-IS WG - IETF 71 Summary Route with Detailed Reachability George Swallow, Clarence Filsfils, Stefano Previdi [email protected] [email protected] [email protected]

Transcript of IS-IS WG - IETF 71 Summary Route with Detailed Reachability George Swallow, Clarence Filsfils,...

Page 1: IS-IS WG - IETF 71 Summary Route with Detailed Reachability George Swallow, Clarence Filsfils, Stefano Previdi swallow@cisco.com cfilsfil@cisco.com sprevidi@cisco.com.

IS-IS WG - IETF 71

Summary Route with Detailed Reachability

George Swallow, Clarence Filsfils, Stefano [email protected] [email protected]

[email protected]

Page 2: IS-IS WG - IETF 71 Summary Route with Detailed Reachability George Swallow, Clarence Filsfils, Stefano Previdi swallow@cisco.com cfilsfil@cisco.com sprevidi@cisco.com.

2

Motivation

Scalability and convergence IGP convergence

SPT Calculation is quick FIB update is not so quick Would like to summarize routes in FIB

BGP Convergence Next hop tracking very useful Depends on reachability to /32 address

Currently IS-IS makes no distinction between having a route and having reachability

Want to have it both ways!

Page 3: IS-IS WG - IETF 71 Summary Route with Detailed Reachability George Swallow, Clarence Filsfils, Stefano Previdi swallow@cisco.com cfilsfil@cisco.com sprevidi@cisco.com.

3

L3VPN over L2TPv3

VPN packets are encapsulated in L2TPv3 For many VPNs, multiple next-hops are carried in BGP using a

Route Distinguisher (RD) Switch to new route occurs on BGP withdrawal or indication from

ISIS that the next-hop is not reachable (aka BGP NH tracking) To scale IS-IS, operators would like to summarize PE

loopbacks However summarizing hides detailed reachability, BGP

convergence then depends on BGP withdrawal

Area 0Area 1

ABR1PE110.10.1.1 10.10.0.1

Area 2PE210.10.2.2

10.10.0.2

Area 3

PE3ABR3 10.10.2.3

10.10.0.3

ABR2

Page 4: IS-IS WG - IETF 71 Summary Route with Detailed Reachability George Swallow, Clarence Filsfils, Stefano Previdi swallow@cisco.com cfilsfil@cisco.com sprevidi@cisco.com.

4

Separating Routing and Reachability

New routing advertisement - SRDR Summarized route Detailed reachability

Proposed format Use the Extended IP Reachability TLV Add a sub-TLV Bit vector of reachable hosts

Vector length = 2^(number of ignored bits)

Page 5: IS-IS WG - IETF 71 Summary Route with Detailed Reachability George Swallow, Clarence Filsfils, Stefano Previdi swallow@cisco.com cfilsfil@cisco.com sprevidi@cisco.com.

5

Example

Area 2 has 10.10.2.0/25 assigned as its address range The following addresses appear in ABR2’s database for

Area 2 10.10.2.1 - 10.10.2.27 10.10.2.46 10.10.2.74 - 10.10.2.87

then the bit mask encoding would advertise a summary route to 10.10.2.0/25 with an associated 128-bit mask like this:

0 1 2 301234567890123456789012345678901--------------------------------01111111111111111111111111110000000000000000001000000000000000000000000000111111111111110000000000000000000000000000000000000000

Page 6: IS-IS WG - IETF 71 Summary Route with Detailed Reachability George Swallow, Clarence Filsfils, Stefano Previdi swallow@cisco.com cfilsfil@cisco.com sprevidi@cisco.com.

6

Changes in draft-…-01

Added applicability section case study as motivation for sufficiency of bit-

map encoding Added text on partitioning

Page 7: IS-IS WG - IETF 71 Summary Route with Detailed Reachability George Swallow, Clarence Filsfils, Stefano Previdi swallow@cisco.com cfilsfil@cisco.com sprevidi@cisco.com.

7

Bit-Vector Characteristics

Limited to 1024 bits by TLV/sub-TLV encoding Fixed size

Good for memory mgmt Good for LSP fragmentation issues Cannot exceed allowable sub-TLV size

Not compact for sparse allocation Works well for IPv4 given the assumptions in

the following case study

Page 8: IS-IS WG - IETF 71 Summary Route with Detailed Reachability George Swallow, Clarence Filsfils, Stefano Previdi swallow@cisco.com cfilsfil@cisco.com sprevidi@cisco.com.

8

Bit-Vector Case Study

Assume up to 30k routers in network Break this into 75 domains

Average of 400 routers / domain Assume PE are numbered in blocks of /24

addresses Utilized 33% due to admin inefficiency

Requires 5 /24 per domain = 375 total Each /24 would need 32 bytes of bit-vector

~ 12k bytes total Much less than advertising the /32s

Page 9: IS-IS WG - IETF 71 Summary Route with Detailed Reachability George Swallow, Clarence Filsfils, Stefano Previdi swallow@cisco.com cfilsfil@cisco.com sprevidi@cisco.com.

9

Inconsistent Advertisements

“Should” only happen in two cases Race condition between L1L2 routers seeing a

host/router come up or down Area partition

Solution Monitor bit vector associated with any summary

address matching one that you are advertising Leak /32 for hosts seen by you but not by some

other L1L2 advertising this summary Appropriate hold-downs apply

Page 10: IS-IS WG - IETF 71 Summary Route with Detailed Reachability George Swallow, Clarence Filsfils, Stefano Previdi swallow@cisco.com cfilsfil@cisco.com sprevidi@cisco.com.

10

Detailed Reachabilty Encoding

These assumptions should carry over to IPv6 if provides allocate loopbacks from /120 addresses

Authors would like feedback on the assumptions from Service Providers

Page 11: IS-IS WG - IETF 71 Summary Route with Detailed Reachability George Swallow, Clarence Filsfils, Stefano Previdi swallow@cisco.com cfilsfil@cisco.com sprevidi@cisco.com.

11

Inconsistent Advertisements

L1

PE110.10.1.1

L1PE210.10.2.2

How do ABR1, ABR2 react to inconsistent advertisements from ABR3, AB4?

How does PE1 react to inconsistent advertisements from ABR1, ABR2

ABR1 & ABR2 adversize logical of bit-masks and leak any covered /32s

PEs select most specific address

L2 DomainABR1

ABR3

ABR4

ABR2