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


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


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


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


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


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


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”


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.


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


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


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


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


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


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


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


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


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)


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


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”


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)


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


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

march 21, 2006l3vpn wg 1 mvpn update new version of “bgp encoding” draft –bgp update syntax...

Documents