1 / 6

AS Migration

AS Migration. Wes George With major assistance from: Sandy Murphy and Shane Amante. The problem. BGP-speaking networks merge, acquire, split, reconfigure this usually requires routers to change ASNs Confederations not always a good solution

borka
Download Presentation

AS Migration

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. AS Migration Wes George With major assistance from: Sandy Murphy and Shane Amante

  2. The problem • BGP-speaking networks merge, acquire, split, reconfigure • this usually requires routers to change ASNs • Confederations not always a good solution • Difficult for operators to coordinate ASN changes with eBGP peers • Each router moved to new ASN must have all eBGP peers reconfigure remote-as simultaneously or BGP sessions won’t come up • doesn’t scale to thousands of PE routers with hundreds of sessions each • Mid-migration AS-Path lengthening creates undesirable traffic shifts

  3. The Solution • Vendors implemented BGP knobs that allow manipulation of ASN inside PE’s BGP • Local-AS to masquerade as old ASN to eBGP peers • Replace-AS to remove second ASN from AS_PATH to restore expected AS_PATH length • Looks like normal spec-compliant eBGP session external to the router • Requires no coordination/reconfiguration from eBGP peers • Remote-side migration can be asymmetric and long duration

  4. Why does SIDR need to care? • AS migration manipulates the current ASN and the AS_PATH across a management domain/trust boundary (SP <-> Customer/peer) • BGPSec Path Validation is designed to prevent intentional AS_PATH manipulations, even when they’re not malicious • AS Migration tools widely used by operators • draft-ga-idr-as-migration published to standardize the vendor knobs so it’s not a non-spec BGP hack anymore • Minor operational considerations to make it work with Origin Validation

  5. Requirements Assuming IDR adopts ga-idr-as-migration: • BGPSec MUST support AS-migration • SHOULD do it without reducing BGPSec’s protections • MUST NOT require any reconfiguration on the remote eBGP neighbor (CE) • MUST NOT lengthen AS Path during migration • MUST operate with existing trust boundaries • e.g. can’t expect remote side to accept pcount=055from untrusted/non-confed neighbor

  6. Draft updates (for pending -01) • Draft-george-sidr-as-migration needs more reviewers and comments (draft-ga-idr does too) • Currently discusses problem, no solutions/req’s • Are SIDR considerations (Section 3) accurate/complete? • Plan to add req’s from slide 5, clarifications based on Sandy’s review • Sandy’s possible solution (discussed @ AMS interim, can review now if necessary) • Right solution? • Add to this draft? • Add to protocol spec draft?

More Related