Transcript BGP for Interdomain Service Routing (aka Context AFI) David Ward mailto:

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:
Presentation_ID
1: AFI
(IANA AFI values)
2: SAFI
(IANA SAFI values)
3: QoS
(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