BGP for Interdomain Service Routing (aka Context AFI)

1
BGP for Interdomain Service Routing (aka Context
AFI)

• David Ward
• mailtodward_at_cisco.com

2
VPNs, the Internet, Nirvana
3
MIT CFP - Led by Dave Clark

• Feedback from many customers was
• We need a multivendor, multiprovider forum
• Dont 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 cant 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
Whats 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 - dont add
  more
• On the other hand, BGP is pretty good at carrying
  around bags of data the protocol doesnt 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
• Doesnt interfere with deployed features or
  availability mechanisms
• Allows for any service separation design VR, TE