1. July 24, 2007IETF 69, L3VPN WG1 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

2. July 24, 2007IETF 69, L3VPN WG2 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)

3. July 24, 2007IETF 69, L3VPN WG3 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)

4. July 24, 2007IETF 69, L3VPN WG4 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 ;-)

5. July 24, 2007IETF 69, L3VPN WG5 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

6. July 24, 2007IETF 69, L3VPN WG6 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

7. July 24, 2007IETF 69, L3VPN WG7 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

8. July 24, 2007IETF 69, L3VPN WG8 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

9. July 24, 2007IETF 69, L3VPN WG9 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

10. July 24, 2007IETF 69, L3VPN WG10 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

11. July 24, 2007IETF 69, L3VPN WG11 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

12. July 24, 2007IETF 69, L3VPN WG12 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

13. July 24, 2007IETF 69, L3VPN WG13 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.)

14. July 24, 2007IETF 69, L3VPN WG14 Update on BGP MVPN Document draft-ietf-l3vpn-2547bis-mcast-bgp-03

15. July 24, 2007IETF 69, L3VPN WG15 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

16. July 24, 2007IETF 69, L3VPN WG16 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.

17. July 24, 2007IETF 69, L3VPN WG17 BGP MVPN Document Next 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