Multicast in BGP/MPLS VPN

1
Multicast in BGP/MPLS VPN

• draft-xu-l3vpn-2547bis-mcast-01
• Xiaohu Xu (xuxh_at_huawei.com)
• IETF 64th, Vancouver

2
Content

• Implementing process
• Discovery of MVPN membership
• Establishment of pseudo-wires
• Transmission of multicast traffic
• Mailing list
• Summary

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

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.

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.

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.

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

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 ltS, Ggt and the
  input interface. The packet carries no
  identifier of the tree on which it is
  traveling, this must be inferred from the ltS,Ggt
  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.

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.
• 
  

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

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 Rosens professional viewpoint.
• 
  --Xiaohu Xu

12
Mailing list-Q4

• Whats the benefit of using PWs over these
  existing alternatives.
• MPLS
• IP-in-IP
• GRE
• Richard
  Spencer

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

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.