1 / 14

Multicast in BGP/MPLS VPN

This document discusses the implementation process of multicast in BGP/MPLS VPNs, including the discovery of MVPN membership, establishment of pseudo-wires, and transmission of multicast traffic.

vjames
Download Presentation

Multicast in BGP/MPLS VPN

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Multicast in BGP/MPLS VPN draft-xu-l3vpn-2547bis-mcast-01 Xiaohu Xu (xuxh@huawei.com) IETF 64th, Vancouver

  2. Content • Implementing process • Discovery of MVPN membership • Establishment of pseudo-wires • Transmission of multicast traffic • Mailing list • Summary IETF 64th Vancouver

  3. Discovery of MVPN membership • Auto-discovery with VPN-IPv4 address family • IPv4 address part of VPN-IPv4 address is specified as ''224.0.0.0'' , which means multicast is enabled for that VRF. • Auto-discovery with new address family • Contain IP address, RD and RT attributes IETF 64th Vancouver

  4. Establishment of pseudo-wires • Full-meshed PWs are established between PEs within the same MVPN via targeted LDP or BGP. That is to say, each egress would assign a distinct label to each possible ingress. • PW can be looked as virtual interface attached to a particular MVRF between each pair of PEs. • This is the main difference from draft-ietf-l3vpn-2547bis-mcast-00. IETF 64th Vancouver

  5. Transmission of multicast traffic • Both multicast control message and data traffic in a particular MVPN travel over the associated PW. • As multicast traffic is received over PW by egress PE, it can determine from which specific MVPN and from which ingress PE the traffic traveled. • It belongs to ingress replication methods. IETF 64th Vancouver

  6. Mailing list-Q1 • Does the egress PE need to identity the ingress PE of a VPN multicast packet which travels through a unicast MPLS tunnel. --Eric Rosen • If the unicast tunnels are used to instantiate an MI-PMSI, and PIM is run on the MI-PMSI so that the PIM control messages are being multicast, then I think the answer is no. • For the other control protocol regimes (unicast PIM or BGP), or if the unicat tunnels are not being used to instantiate an MI-PMSI, I think there may be cases where we do need to know the ingress PE. I think the procedures for switching from a sparse mode shared tree to a source tree may require this knowledge. IETF 64th Vancouver

  7. Mailing list-A1 • RPF checking is a very important mechanism for multicast processing( see RFC 2362 ). • During the switching procedure of SPT triggered by the change of IGP route, ingress PE should still be known for the purpose of RPF checking because the convergence of SPT is not fully synchronized. • Say nothing of PIM-DM deployed in MVPN. --Xiaohu Xu IETF 64th Vancouver

  8. Mailing list-Q2 • Need to know the input interface?-- Eric Rosen • When the packet is an IP packet, all the information you have is the <S, G> and the input interface. The packet carries no identifier of the tree on which it is traveling, this must be inferred from the <S,G> and the in put interface. • However, when the packet is an MPLS packet, it may be carrying a label which identifies a particular tree, In that case, you would not need to know the input interface in order to figure out the tree on which the packet is traveling. IETF 64th Vancouver

  9. Mailing list-A2 • But how to describe a tree? --Xiaohu Xu • The root and the instance are two necessary components. The root of the tree is just the ingress PE, the instance of the tree can be represented by MVPN instance, which is just the meaning of the inner label described in my draft. • As to describing the MPLS label as virtual interface, it's just for the purpose of understanding easily as the ordinary process of PIM is familiar to all of us. IETF 64th Vancouver

  10. Mailing list-Q3 • A combination of the inner and outer label with PHP disabled would tell the receiving PE from which PE and from which VPN the packets are transmitted. --Yakov Rekhter IETF 64th Vancouver

  11. Mailing list-A3 • In general, the top label which the ingress PE puts on the packet will not enable the egress to identify the ingress, because the top label may represent a mp2p tunnel or may be popped off before reaching the egress. -- Eric Rosen • Thanks a lot for Rosen’s professional viewpoint. --Xiaohu Xu IETF 64th Vancouver

  12. Mailing list-Q4 • What’s the benefit of using PWs over these existing alternatives. • MPLS • IP-in-IP • GRE –Richard Spencer IETF 64th Vancouver

  13. Mailing list-A4 • Regarding MPLS outer label as identifier of the ingress, it has been discussed in the above slide of Mailing list-A3. • Although the ingress PE's address could be carried in multicast data packets with MPLS-in-GRE or MPLS-in-IP encapsulation, additional overhead is introduced as there already exists LSP tunnel between PEs. It is more suitable in Non-MPLS networks. --Xiaohu Xu IETF 64th Vancouver

  14. Summary • It belongs to ingress replication methods. • As multicast packets are received over PW by egress PE, it can determine from which VPN and from which ingress PE these packets are transmitted just according to the inner label. This is the main difference from draft-ietf-l3vpn-2547bis-mcast-00. • No special requirement on the outer tunnel. IETF 64th Vancouver

More Related