BGP for Interdomain Service Routing (aka Context AFI)

1. BGP for Interdomain Service Routing (aka Context AFI) • David Ward • mailto:dward@cisco.com

2. A B B A D C D C E • Network-based IP VPNs • Many QoS-enabled islands • No interprovider QoS • The Internet • Richly interconnected providers • No QoS B A E D C Nirvana: Richly connected AND QoS-enabled VPNs, the Internet, & Nirvana

3. MIT CFP - Led by Dave Clark • Feedback from many customers was: • We need a multivendor, multiprovider forum • Don’t want to go to IETF yet - too many spoilers, academics • MIT CFP was an existing framework • http://cfp.mit.edu • Willing to host a group on interprovider QoS - first meeting October 2004 • http://cfp.mit.edu/qos/slides.html - agenda, slides & agreements from 1,2,3rd meetings (Oct 2005) • Currently working on a draft whitepaper that roughly follows the IDQ approach • Numerous service provider co-authors + Cisco + Juniper • Could become basis for an IETF submission - See MAVS • This is outcome of what is needed in routing

4. Basics of BGP functionality • What can BGP do? • Find routes which (purport to) support a given QoS e2e • What can’t BGP do? • Treat QoS as anything other than opaque • Signal dynamic path characteristics (e.g., instantaneous loss or delay)

5. BGP for Service (QoS) Routing • BGP well-suited to carrying multiple classes of routing information (MPBGP) • Could Consider QoS as a distinct class of routes • Service classes, metrics, etc are opaque — BGP simply signals reachability • Small number of classes = tractable problem

6. Recap - Other Issues • No means of carrying multiple routes for same NLRI • BGP multiplexes all routing information onto a single session • Undesirable fate-sharing between classes of routes • Not possible to prioritize different classes of routes (on Rx side anyway)

7. Some Existing Solutions • Multisession to fix fate-sharing • Add Path to fix implicit withdraw

8. Two Problems without Solutions • Signal peering point/service location • Announce reachability • Maintain SLAs and overcome “slowness” of repairing paths due to messaging overhead

9. Some Other Possible Solutions Discussed • Several options to distinguish multiple routes • New AFI/SAFI • Distinct session per QoS • Others • E.g. Agree upon and exchange QOS markings

10. Solution Requirements • Must have opaque semantics for QOS bits on either side of AS boundary • Want to announce a service NOT a packet marking • On Link across boundary may administratively configure marking • Want to be able to have distinct logical links for each QOS class OR multiplex QOS classes across one link • Want to have minimal changes to protocol for ease of deployment • NOT BGPv5 • No change to protocol HA semantics or features • Must be able to preserve existing MPBGP features and add service (class)

11. Recap of Solution set • Multi-session BGP - remove shared fate • Advertise Multiple Paths to same destination • In IDR WG - “add path” • Aggregate Withdraw - Faster recovery to maintain SLAs • Discussed today • Context AFI - Announce reachability to service (QOS, Voice, Video) • Discussed today

12. Proposal on Table: Context AF for BGP draft-djernaes-simple-context-update-00 Authors: Martin Djernaes, Chandra Appanna, David Ward • A method to advertise flexible descriptions of the destination tables and allow updates targeted to these (forwarding) tables • Allow this to be done without changing the actual update format • In such a way that existing features which rely on the afi/safi pair to describe the target table would be backward compatible

13. Context AF Exchanging new information • When a BGP speaker wants to exchange routes using a new context functionality the speaker must send the context capability to its peer • In the context capability it lists each context it wants to use with a • context identifier • context description length • context description

14. Context AF encoding • The description is a list of TLVs with the types being well known values. Description Types: 1: AFI (IANA AFI values) 2: SAFI (IANA SAFI values) 3: QoS (0-255)

15. Context AF exchange When the context capability have been exchanged all routing information will be exchanged using the CONTEXT AFI value (TBD) and the context identifier described in the context capability as the SAFI value for the CONTEXT AFI using the existing multi protocol extension functionalities

16. Context AF and features • Existing features, like graceful restart which address a target table using an afi/safi pair will use the CONTEXT AFI plus the context identifier pair • It will be possible to use these features together with new tables without having to modify the protocol for service topologies or QOS • Also enables QOS policies within a service topology • The ID itself is opaque and does not define local QOS config • Instead, defines a SERVICE

17. What’s left? • Need to signal anything beyond reachability (and AS hop count)? • BGP not particularly good for very dynamic data • BGP not to propagate link attribute info • Do we want to exchange RDs or is redistribution configuration enough? • History teaches that global BGP route selection metrics are difficult to agree on - don’t add more • On the other hand, BGP is pretty good at carrying around bags of “data” the protocol doesn’t care about • CAC and service thresholding (e.g.auto-bandwidth) are not for BGP • See RSVP, SIP or other signaling protocols

18. Summary: What does this proposal provide? Exchanges QOS (service) information Enabling service differentiation Follows current BGP configuration, policies and management Uses backwards compatible technique - Easy deployment Allows for fast convergence per service Announcing multiple paths per prefix/service Withdraw all prefixes in a AF/SAF/topo/QOS in one message Doesn’t interfere with deployed features or availability mechanisms Allows for any service separation design: VR, TE