200 likes | 209 Views
BGP Update. John Scudder jgs@cisco.com October 24, 2000. Overview. New stuff Graceful Restart Cooperative Route Filtering, Prefix-ORF Extended Communities Route Refresh Tweaks, frobs, cleanup Revisions of base spec, Route Reflection, Confederations, Capabilities, MP-BGP. Base Spec.
E N D
BGP Update John Scudder jgs@cisco.com October 24, 2000
Overview • New stuff • Graceful Restart • Cooperative Route Filtering, Prefix-ORF • Extended Communities • Route Refresh • Tweaks, frobs, cleanup • Revisions of base spec, Route Reflection, Confederations, Capabilities, MP-BGP
Base Spec • draft-ietf-idr-bgp4-10.txt • Fix ambiguities about MED • Actually, this part is not so new • Otherwise, mostly editorial
Graceful Restart • draft-ramachandra-bgp-restart-03.txt • a.k.a. NSF • When BGP restarts, continue forwarding for some (short) period of time • Avoid route flap • Non-intrusive upgrades, less harmful failures • Some risk of transient blackholes/loops • But route flaps have their own risks
Graceful Restart Mechanism • Capability includes • flags (currently restarting or not, preserved FIB or not) • timer (time to wait for me to restart) • “End of RIB” message
Graceful Restart Mechanism • When BGP stops, neighbors don’t drop TCP session right away, wait for timer instead • When BGP restarts, neighbors don’t flush old routes immediately — wait to converge • Old routes are flushed after convergence (or after a timer expires)
Graceful Restart Example … and advertises its new RIB, replacing the marked routes. BGP comes back up and establishes new sessions with B and C. BGP halts on A. B and C’s RIBs and A’s FIB all mark routes for later deletion. Once B and C have sent all their routes, A runs best path, populates its FIB When A has finished advertising its RIB, any marked routes which weren’t replaced are flushed. B and C send their routes to A. A stores them in its RIB. Router A Router B RIB: (routes from A) (other routes) RIB: (new routes from A) (other routes) RIB: (routes from A) (other routes) RIB: (routes from B) RIB: RIB: (routes from B) (routes from C) RIB: (routes from B) (routes from C) Router C FIB: (routes from B) (routes from C) FIB: (routes from B) (routes from C) FIB: (new routes from B) (new routes from C) RIB: (routes from A) (other routes) RIB: (new routes from A) (other routes) RIB: (routes from A) (other routes)
Route Refresh • RFC 2918 • Allows a router to request neighbor to re-send its whole Adj-RIB-Out • Permits soft reconfig without storing filtered Adj-RIB-In • Benefits: save memory • Drawbacks: extra communication, CPU when inbound policy is changed
Cooperative Route Filtering • draft-chen-bgp-route-filter-01.txt,draft-chen-bgp-prefix-orf-00.txt • Lets router export its filtering policy to neighbor • Community and prefix policies are specified so far • Reduces communication and CPU on both ends
Cooperative Route Filtering Mechanism • Outbound Route Filters (ORFs) are sent along with Route Refresh • So far communities and prefix lists are specified, simple encoding • Each AFI/SAFI can have its own ORFs • Can change filters by sending new Route Refresh request • Peer can use ORFs to filter outbound routes
Refresh + ORF Example ORF Comm 2 ORF Comm 3 Router B Router A OPEN, Refresh, ORF = Comm 2 Comm 1 2 2 3 Pfx 10.0.1 10.0.2 10.0.3 10.0.4 Announce 10.0.2, 10.0.3 Refresh, ORF = Comm 3 w/d 10.0.2, 10.0.3, Announce 10.0.4
Extended Communities • draft-ramachandra-bgp-ext-communities-04.txt • 8-byte, more structured communities • 2 byte type, 6 byte value. Type determines format of value. • Value typically includes originator’s IP address or AS number • Defined types: route target, route origin, link bandwidth • Currently used for network-based VPNs
Route Reflection • RFC 2796 • Changes vs. RFC 1966 • Editorial cleanup • Deployment section with some points regarding MED, avoidance of loops • No fundamental changes
Confederations • draft-ietf-idr-bgp-confed-rfc1965bis-01.txt • Changes vs. RFC 1965 • Corrections to reflect reality — particularly reverse code points for CONFED_SEQ and CONFED_SET. • Editorial changes • Expanded deployment section with discussion of MED, routing loops • No fundamental changes
Deployment Guidelines • RR and clusters scale by hiding routes • This changes some BGP assumptions • To avoid trouble: • Avoid overlapping clusters/sub-ASes • Set IGP metrics to prefer intra-cluster (or sub-AS) paths
Why Avoid Overlapping Clusters? • Well-known problem (I hope!) • Avoid simply by making clusters/sub-ASes follow topology RR 2 B RR 1 A
1 RR 1 RR 2 4 5 10 A B C AS X AS Y MED 1 AS Y MED 2 Why Set IGP Metrics To Prefer Intra-Cluster Paths? A, IGP 5 C, IGP 10, MED 1 * * * * * B, IGP 4, MED 2 * * A, IGP 6 * C, IGP 11, MED 1 C, IGP 10, MED 1 B, IGP 5, MED 2
Why Set IGP Metrics To Prefer Intra-Cluster Paths? A, IGP 5 C, IGP 10, MED 1 * * B, IGP 4, MED 2 A, IGP 17 C, IGP 10, MED 1 12 RR 1 RR 2 4 5 10 A B C AS X AS Y MED 1 AS Y MED 2
Mailing List • IETF IDR Working Group mailing list — idr@merit.edu • For: • Discussion of BGP protocol itself • Discussion of operational needs, problems • Not: • “how do I build my network” • “vendor foo feature bar”