1 / 15

IS-IS WG - IETF 70

Summary Route with Detailed Reachability George Swallow, Clarence Filsfils, Stefano Previdi swallow@cisco.com cfilsfil@cisco.com sprevidi@cisco.com. IS-IS WG - IETF 70. Agenda. Motivation Solution Sketch Open Issues Encoding technique Inconsistent advertisements. Motivation.

rasha
Download Presentation

IS-IS WG - IETF 70

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Summary Route with Detailed ReachabilityGeorge Swallow, Clarence Filsfils, Stefano Previdiswallow@cisco.com cfilsfil@cisco.com sprevidi@cisco.com IS-IS WG - IETF 70

  2. Agenda Motivation Solution Sketch Open Issues Encoding technique Inconsistent advertisements

  3. Motivation • Scalability and convergence • IGP convergence • BGP Convergence • Example: L3VPN over L2TPv3 • Other Uses • PIM • RSVP-TE mesh

  4. Some Brief Notes on IGP Convergence • Testbed • CRS1 • 2500 ISIS prefixes • Tier 1 ISP Topology • Time measured by traffic loss Prefix Number • Time for ISIS LSP generation, SPF recalculation is very quick • Substantial time is required for update of structures on linecards for individual prefixes • Time shown is IP, for MPLS LFIB needs updating too

  5. L3VPN over L2TPv3 Area 2 10.10.2.2 PE2 ABR1 ABR3 ABR2 PE1 PE3 10.10.0.1 10.10.1.1 Area 0 Area 3 Area 1 10.10.0.2 10.10.0.3 10.10.2.3 • 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

  6. Reachability and Routing • Currently IS-IS makes no distinction between having a route and having reachability • We call a route to an IP prefix “IP reachability” • As we move toward sophisticated control planes and highly efficient forwarding planes, a tension has developed

  7. Changing Economics and Priorities • Early 90s • Expensive memory • Slow processors • Applications tolerant of slow convergence • Summarization considered good for dataplane and control plane • Today • Memory much cheaper • Processors much faster • Applications demand fast convergence • For convergence fewer routes means faster convergence in the dataplane (primarily FIB update time) • But BGP next-hop tracking needs the reachability information • Needs of the control and data planes have diverged!

  8. Separating Routing and Reachability • New routing advertisement - SRDR • Summarized route • Detailed reachability • Straw-man format • Use the Extended IP Reachability TLV • Add a sub-TLV • Bit vector of reachable hosts Vector length = 2^(number of ignored bits)

  9. 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 3 01234567890123456789012345678901 -------------------------------- 01111111111111111111111111110000 00000000000000100000000000000000 00000000001111111111111100000000 00000000000000000000000000000000

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

  11. Bit-Vector Case Study • Assume up to 20k routers in network • Break this into 50 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 = 250 total • Each /24 would need 32 bytes of bit-vector • ~ 8k bytes total

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

  13. Open Issues • Encoding • Encoding scheme not cast in concrete • One variation would be to have a new TLV instead of a sub-TLV of the Extended IP reachability TLV which would eliminate the /22 limitation on summarized addresses • Inconsistent advertisements

  14. Inconsistent Advertisements L1 10.10.2.2 PE2 ABR1 ABR3 ABR4 ABR2 PE1 L2 Domain L1 10.10.1.1 • How do ABR1, ABR2 react to inconsistent advertisements from ABR3, AB4? • How does PE1 react to inconsistent advertisements from ABR1, ABR2 • If no ECMP, then just relay the selected route’s information

  15. Inconsistent Advertisements • “Should” only happen in two cases • Race condition between L1L2 routers seeing a host/router come up or down • Area partition • Authors discussed several options • Leaking /32 of addresses one L1L2 router advertises vs the other L1L2 routers • Partition repair via L2 tunnel • Analysis is not complete at this time

More Related