BGP for Interdomain Service Routing (aka Context AFI) David

BGP for Interdomain Service Routing (aka Context AFI) David Ward mailto:[email protected] Session Number Presentation ID

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

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 Presentation ID

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) Presentation ID 4

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 Presentation ID 5

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) Presentation ID 6

Some Existing Solutions Multisession to fix fate-sharing Add Path to fix implicit withdraw Presentation ID 7

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

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 Presentation ID 9

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) Presentation ID 10

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 Presentation ID 11

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 Presentation ID 12

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 Presentation ID 13

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

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 Presentation ID 15

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 Presentation ID 16

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 Presentation ID 17

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 Presentation ID 18