1. Multicast in BGP/MPLS VPN
draft-xu-l3vpn-2547bis-mcast-01
Xiaohu Xu
IETF 64th, Vancouver

2. Content Implementing process Mailing list Summary
Discovery of MVPN membership
Establishment of pseudo-wires
Transmission of multicast traffic
Mailing list
Summary
Nov 2005
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 '' '' , which means multicast is enabled for that VRF.
Auto-discovery with new address family
Contain IP address, RD and RT attributes
Nov 2005
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.
Nov 2005
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.
Nov 2005
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.
Nov 2005
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
Nov 2005
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.
Nov 2005
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.
Nov 2005
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
Nov 2005
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
Nov 2005
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
Nov 2005
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
Nov 2005
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.
Nov 2005
IETF 64th Vancouver