July 24, 2007IETF 69, L3VPN WG1 Progress on Arch Doc draft-ietf-l3vpn-mcast-2547bis-mcast-05 Areas...

July 24, 2007 IETF 69, L3VPN WG 1

Progress on Arch Doc

• draft-ietf-l3vpn-mcast-2547bis-mcast-05

• Areas of new work:– Clarification of upstream multicast hop

determination– Upstream-Assigned PE Labels– Use of MP2MP LSPs as P-tunnels– Support for BIDIR-PIM usage by customers


Upstream Multicast Hop Determination

• Procedures for determining Upstream Multicast Hop (UMH) in P-network:– clarified and consolidated– distinguished from PIM “RPF determination”– simple load balancing procedure specified as an

“optional default”• if S1 and S2 are both reachable equally well via PE1 and

PE2, can force all PEs to treat PE1 as ingress for S1 and PE2 as ingress for S2

• other load balancing procedures allowed

– accommodate use of multicast-specific topology for UMH determination (SAFI 2, 129, OSPF MTR)


SFS vs. Discard

• SFS (Single Forwarder Selection): ensure that no packet enters the backbone more than once (modulo convergence time issues)

• Discard: egress PE discards packets that enter the backbone at other than the expected place (requires that the packet’s encaps enables identification of the ingress)

• Both are desirable, in general:– SFS alone doesn’t prevent all duplicates– Discard alone prevents duplicates but can waste

backbone resources • SFS not sufficient for BIDIR support (more later)


SFS vs. Discard vs. S-PMSI

• Possible to run with only S-PMSIs– Eliminates need for SFS– If S-PMSIs not aggregated, or if they only

aggregate congruent flows, then discard is not necessary to avoid duplicates to customers.

• except in some Sparse Mode cases ;-)


Upstream-Assigned “PE Labels”

• PE label identifies a particular PE:– under specified conditions, root PE of an LSP P-tunnel assigns a

label that identifies either itself or other PE belonging to the LSP– distributed by BGP (precise mechanism still to be determined)– unique in scope of particular LSP: PE label follows LSP label

• Uses of PE label:– When using MP2MP LSP as P-tunnel carrying SM or SSM

traffic, allows transmitter to be identified, facilitating Discard procedure

– When any LSP is carrying BIDIR traffic, allows “Designated Forwarder (DF)” to be identified (more later)

– “PE label” can also be used to identify ASBR that transmits onto a MP2MP intra-AS segment of inter-AS tunnel


C-Bidir Support

• In BIDIR-PIM, each G has a Rendezvous Point Address (RPA) serving as root of distribution C-tree (RPA not necessarily address of any box)

• On a bidirectional tree, packets can go towards the root (upstream) as well as away from the root (downstream)– Possibility of loops that can’t exist on unidirectional

trees– If a multicast packet loops 255 times on a bidir tree,

each receiver gets 255 copies of the packet!• The risk occurs on any multi-access medium,

such as a LAN or an MVPN PMSI


C-Bidir Loop Prevention

• BIDIR-PIM handles this with elaborate DF election. In MVPN context, this would mean one PE becomes DF.

• Example of proper flows on next slide


Example• Let PE1 be DF• Packet from R1 to PE3• From PE3 over bb to:

• PE4 to R2• PE1 to RPA• PE2 drops

• R3 gets packet along path R1—PE3—PE1—RPA—PE2—R3

• PE2 does not send to bb

RPA|

--------------------| |

PE1 PE2------R3| |

------------------------------| VPN Backbone |------------------------------

| |PE3 PE4

| |R1 R2


Observations

• Multiaccess link creates cycle in tree

• If backbone is modeled as multiaccess link, cycles can be created

• In example, if PE1 and PE2 both transmit to backbone, we don’t just duplicate the packets, we TTL-icate them

• DF election is one way to break cycle; we will present other ways


Rejected Alternative to DF Election

• Use single forwarder selection procedure to force all PEs to choose same DF (for a given C-RPA)

• Convergence not guaranteed to happen fast enough to eliminate TTL-ication of data traffic


First Alternative to DF Election

• Use special address for RPA:– Make it look to each PE as if RPA is reachable via the

backbone– RPA not at any customer site (outsourced)

• Then the root of the Bidir tree is the backbone itself

• Loops are not possible because the backbone does not create a cycle

• Simple, but not transparent to existing customer multicast infrastructure


Second Alternative to DF Election

• Instead of removing cycle from tree, just make sure that no packet traverses a cycle

• A packet’s ingress PE must:– Choose a PE to be DF (may use SFS procedure)– Identify the chosen PE in the P-tunnel encaps

• When egress PE receives packet from P-tunnel:– Drop the packet if the egress disagrees with the

ingress about who the DF is– Otherwise handle normally

• Now different DF choices will not cause looping


Identifying the Chosen DF

• Option 1: Use PE Label as second label– Can be used in any sort of P-tunnel with an

identifiable root node to assign the labels: PIM-SSM tree, P2MP LSP, MP2MP LSP

• Option 2: – Each PE that acts as DF serves as the root of a

MP2MP LSP– To identify a PE as a particular packet’s DF, transmit

it on the MP2MP LSP rooted at the DF. (Remember that on MP2MP LSP, leaf nodes can transmit.)


Update on BGP MVPN Document

• draft-ietf-l3vpn-2547bis-mcast-bgp-03


Enhancements to the previous version (1)

• Non-Congruent Unicast and Multicast Connectivity– Specify encoding of NLRI in case of SAFI 129

• RR processing of next-hop of BGP MVPN routes– Clarify that BGP RRs should set up next hop

to self when re-advertising C-multicast routes.– Clarify that BGP RRs MUST NOT modify the

next hop when re-advertising inter-AS auto-discovery route


Enhancements to the previous version (2)

• When is the PMSI Tunnel Attribute carried in intra/inter AS AD routes ?– Clarify that intra-AS and interAS AD routes

carry the PMSI Tunnel attribute if and only if an I-PMSI is used for the MVPN.


BGP MVPN DocumentNext Steps

• The document is fairly stable– We have official IANA assignments for the

code points

• There is at least one implementation• Potential enhancements in the next

revision– Potential extensions required to support the

areas of new work being addressed by the architecture document

July 24, 2007IETF 69, L3VPN WG1 Progress on Arch Doc draft-ietf-l3vpn-mcast-2547bis-mcast-05 Areas...

Documents

Transcript of July 24, 2007IETF 69, L3VPN WG1 Progress on Arch Doc draft-ietf-l3vpn-mcast-2547bis-mcast-05 Areas...