BGP Flow specification Update David Lambert [email protected].
March 21, 2006L3VPN WG 1 MVPN Update New version of “bgp encoding” draft –BGP update syntax...
-
Upload
elfreda-grant -
Category
Documents
-
view
220 -
download
0
Transcript of March 21, 2006L3VPN WG 1 MVPN Update New version of “bgp encoding” draft –BGP update syntax...
March 21, 2006L3VPN WG 1
MVPN Update
• New version of “bgp encoding” draft– BGP update syntax and semantics reworked to reflect
current thinking– Inter-AS proposal fleshed out in detail
• Arch. draft not yet updated, to be done “shortly”• This presentation will discuss:
• Changes from last rev• Selected interesting topics• Remaining open issues
March 21, 2006L3VPN WG 2
BGP Attributes for Unicast VPN-IPv4 Routes
• Extended communities to identify:– AS of origin– VRF of origin (including PE of origin)
• These are used for “RPF Lookup” when PE received C-Join from a CE– Root IPv4 address looked up in VRF– Get source AS for inter-AS trees (later)– Get address of upstream PE
March 21, 2006L3VPN WG 3
MCAST-VPN Address Family
• One AF, but multiple route types• C-Multicast (C-M) Routes convey customer
multicast routes (from within a VPN)• Auto-Discovery (A/D) Routes convey information
to set up MVPN infrastructure in the backbone:– Find other PEs and /or ASes of a given MVPN– Bind MVPN to default PMSI (I-PMSI)– Bind individual streams to S-PMSI– Bind PMSI to tunnel– A few other uses having to do with P-tunnel setup
and/or binding of multicast streams to P-tunnels
March 21, 2006L3VPN WG 4
Intra-AS A/D Routes for Auto-Discovery
• NLRI:– RD of originating VRF– IP address of originating router
• Attributes:– RTs controlling route distribution– PMSI tunnel attribute, identifying default I-PMSI mechanism
• Enough info to set up “receiver-initiated join” type tunnels• Other tunnel types may require additional BGP-based
protocol based on “leaf a/d routes”– For aggregate trees, upstream-assigned MPLS label specified
• N.B.: Two intra-AS A/D routes are never comparable
March 21, 2006L3VPN WG 5
Other Uses of Intra-AS A/D Routes
• Bind <S,G> to an S-PMSI– Include <S,G> in the NLRI– Without <S,G> binding applies to entire
MVPN
• Active Source Advertisement (for “PE as RP” schemes)– Include <S,G> in NLRI– Omit PMSI Tunnel Attribute
March 21, 2006L3VPN WG 6
C-M Routes
• Types:– Source tree join– Shared tree join– Prune source off shared tree
• Route type is part of NLRI– Different route types never comparable
• Claim:– with these route types, all PIM operations can
be represented by BGP updates or withdraws
March 21, 2006L3VPN WG 7
C-M Routes
• NLRI:– “Reverse” RD
• RD from the VPN-IPv4 address of the root of this C-tree• Slightly different procedure used for inter-AS
– /32 Source (omitted in shared tree joins)– /32 Group
• Attributes:– RTs to control route distribution– Route Import target, identifying a particular PE as the
“upstream PE”
March 21, 2006L3VPN WG 8
No “Originating PE” in C-M Routes
• Different PEs joining same C-tree generate comparable routes
• RRs and ASBRs install and redistribute just one such • Upstream PE or ASBR sees 1 “join” per C-tree, need not
do “explicit tracking” of receiving PEs (unless needed for P-tunnel type)
• RR is leveraged to allow PEs get effect of join suppression, without need to do join caching and prune override
• Control plane allows NBMA procedures which have some aspects of PIM LAN procedures and some aspects of PIM P2P procedures.
March 21, 2006L3VPN WG 9
Inter-AS
• Inter-AS Tunnel rooted at the source AS– Other ASs are nodes on this inter-AS tunnel
• Inter-AS Tunnel comprises “segments”– AS-AS tunnel segments that connect ASs together on
the inter-AS tunnel– Intra-AS tunnel segment used by an AS to deliver
traffic to PEs/ASBRs within an AS on the inter-AS tunnel
• Distinct from intra-AS trees
• A PE/ASBR receives traffic on a single intra-AS segment or AS-AS segment of the inter-AS tunnel
March 21, 2006L3VPN WG 10
Inter-AS MVPN Auto-Discovery
• Inter-AS Auto-discovery routes – granularity of <Source AS, MVPN>– advertised by ASBRs– Aggregate intra-AS Auto-discovery information with
granularity of <PE, MVPN>– AS specific RD– All ASBRs within an AS configured with same
AS specific RD• Propagation of Inter-AS Auto-discovery routes
from the source AS to other ASs leads to the creation of the inter-AS tunnel
March 21, 2006L3VPN WG 11
Inter-AS Tunnel Creation
• Inter-AS tunnels constructed by stitching tunnel segments– intra-AS tunnel segments stitched with AS-AS tunnel
segments– Independent P-Tunneling technology per AS
• MVPN that is present in N ASes would result in N inter-AS P-tunnels (one per AS, not one per PE)– To improve scalability multiple intra-AS tunnel
segments within an AS could be aggregated into a single intra-AS P-tunnel using upstream labels
March 21, 2006L3VPN WG 12
Inter-AS Tunnel Creation:Intra-AS Segment
• No intra-AS segment in source AS• In other ASes, intra-AS segment is triggered
when an ASBR receives an <AS, MVPN> A/D route from an EBGP neighbor– ASBR readvertises this route in IBGP
• Also carries the intra-AS tunnel segment if the ASBR does not need to know the leaves ELSE
• Intra-AS Tunnel segment is advertised after learning the leaves
– Other PEs/ASBRs are free to pick different upstream ASBRs
• Join the respective intra-AS tunnel segment• Originate leaf AD routes if the upstream ASBR needs to
learn the leaves
March 21, 2006L3VPN WG 13
Inter-AS Tunnel Creation:AS-AS Segment
• Interconnect adjacent ASBRs on the Inter-AS Tunnel
• When an ASBR receives an <AS, MVPN> route from an EBGP peer it sends back a leaf A/D route– Carries a downstream assigned MPLS label– Tunnel segment identifier set to ingress
replication
March 21, 2006L3VPN WG 14
Inter-AS C-M Routing Exchange
• MVPN PE-PE C-M Routing Exchange– Aggregation of MVPN Routing Information
• Granularity of <AS, C-S/C-RP, C-G>
• Inter-AS MVPN C-M Routing Info is propagated by egress PE towards the source AS and the source PE– Propagates using the reverse path of the inter-AS auto-
discovery routes, i.e. <source AS, MVPN> route• No flooding
– No Receiver (S, G) state in the ASBR forwarding plane
March 21, 2006L3VPN WG 15
Inter-AS…
• Control plane exchange between ASes only at ASBRs or RRs
• Use RT Constrain to limit distribution of auto-discovery routes and C-M routes
• Support of all three options for inter-AS unicast
March 21, 2006L3VPN WG 16
Topics: “Shared Tree” State
• join(*,G) and prune(S,G,R)– PIM sends single message saying “I want to
join (*,G), but not for sources S1, S2, S3”– BGP handles these as 4 separate routes (not
necessarily 4 separate updates)– The BGP-to-PIM state machine has some
massaging to do:• For a given G, PIM needs to react to the complete
set of BGP join(*,G) and prune(S,G,R) states• Not 1-1 corresp. between PIM & BGP messages
March 21, 2006L3VPN WG 17
What Replaces PIM Asserts
• If C-S multi-homed to several PEs in same AS, force all PEs to choose same upstream PE for given C-S– absolutely required for segments of inter-AS tree– presupposes different RD at each PE– selection not based on BGP-installed route
• Discard data on C-S tree if received on tunnel from “wrong” upstream PE and/or tunnel
• If a PE receives from both (C-*,C-G) and (C-S,C-G), need more:– Force all PEs to join C-S tree (using “leaf” a/d routes)
March 21, 2006L3VPN WG 18
C-Protocols that use Flooding
• BSR and other flooding-based protocols– Require default MI-PMSI– treat as data sent over default MI-PMSI– do not try to absorb into BGP control plane
March 21, 2006L3VPN WG 19
PEs, RPs, and MSDP
• Goal:– Enable removal of PIM-SM complexity in backbone
• No shared trees among sites• No switching from shared trees, no pruning sources from shared
trees, etc.• Less control plane overhead, less state• More stable traffic pattern in backbone
– But don’t require each PE to be an RP
• Proposal:– PE runs MSDP with local RPs– PEs use BGP to advertise active sources
• Intermediate between “fully transparent” and “outsource your RPs”
March 21, 2006L3VPN WG 20
Dampening C-M Routes• PE multicast routing rate of change is not directly
proportional to terminal behavior: – After the first (S,G) Join, subsequent Joins for same (S,G) do
not cause backbone signaling
• PE multicast routing rate of change depends on application
• Still, PEs may have to support a high rate of C-M route changes, causing PE-PE protocol load
• C-M route dampening is a possible solution– Principle: waiting before propagating a C-M routing change– Timers may increase with a backoff algorithm– May it hurt latency ? Only in some cases (see next slide)
March 21, 2006L3VPN WG 21
Dampening C-M Routes
• Dampening C-M ''prunes''– Won't increase leave-latency perceived by
the CE or end user– Can be done aggressively
• Dampening C-M “joins” only hurts the “first join” in the MVPN
• Where to dampen?– on the receiver-side PE, before propagating– on a route reflector
March 21, 2006L3VPN WG 22
Future Work
• Carrier’s Carrier• Details for support of Bidir C-trees
– DF forwarder election
• Use of MP2MP LSPs as P-tunnels for intra-AS tunnels and intra-AS segments of inter-AS tunnels
• BGP on the CE-PE link for multicast routes?– not transparent, but no worse than for unicast