RE: Multicast in BGP/MPLS VPN with pseudo wires technology

[richard.spencer at bt.com]

Steven,

If your solution is based on using a full mesh of P2P PWs, then your solution is dependant on ingress replication, which is already described in draft-ietf-l3vpn-2547bis-mcast-00. The current tunnelling options for ingress replication are:

- MPLS
- IP-in-IP
- GRE

Please can you explain what you think the benefits of using PWs are over these existing alternatives, particularly as the multicast traffic is IP (and PWs have primarily been developed to carry L1/L2 traffic).

Please see below inline for further comments/questions:

> -----Original Message-----
> From: l3vpn-bounces at ietf.org 
> [mailto:l3vpn-bounces at ietf.org]On Behalf Of xuxiaohu 41208
> Sent: 06 October 2005 04:41
> To: l3vpn at ietf.org; l3vpn at ietf.org
> Subject: Re:Multicast in BGP/MPLS VPN with pseudo wires technology
> 
> 
> Dear members of the l3vpn distribution list: 
> 
> I want to introduce a new method of implementing MVPN in 
> 2547bis VPN with pseudo wires technology, any comment from 
> you will be expected. 
> 
> The basic procedures are as follows: first, discover all the 
> PEs which is attached to a particular MVPN via BGP;second, 
> Full-meshed pseudo wires (PW) are established among the above 
> PEs, and these PWs are bound to a particular MVRF related to 
> the above MVPN;lastly, multicast control messages and 
> multicast data traffices can be transmitted through those PWs. 
> 
> The main advantages of this method is as follows: 
> First,it is independant with multicast routing protocols and 
> any kind of current multicast routing protocols, including 
> PIM-SM, PIM-SSM and PIM-DM can run over such MVPN.

I assume you are referring to customer/provider multicast protocol independence. If so, this is true of existing multicast solutions regardless of the type of multicast tunnels used, this has nothing to do with PWs.

> Second, multicast is not required in P devices. It's easy to 
> maintain such MVPN and it is good for protecting original investment.

This is true of any multicast solution that relies on ingress replication, again this has nothing to do with PWs.

> Third, replication on PE can share the burden on P router

Isn't this the same as the your second advantage? Anyway, again this is true of any multicast solution that relies on ingress replication, again this has nothing to do with PWs.

> which is a hub in hub-spoke network topology.
> 
> The main differnece with 
> draft-ietf-l3vpn-2547bis-mcast-00.txt (May 2005) lies in the 
> demultiplexor. The description about demultiplexor in 
> draft-ietf-l3vpn-2547bis-mcast-00.txt is as follows: 
> 
> ################################## 
> 
> If multicast control information is to be unicast, rather 
> 
> than sent on an MI-PMSI, then a demultiplexor value must 
> 
> be carried by the control messages in order to identify 
> 
> the particular MVPN to which the control message belongs. 
> 
> The form of this demultiplexor is not yet agreed upon, 
> 
> but one possibility is a downstream-assigned MPLS label. 
> 
> If this procedure is adopted, this label would be carried 
> 
> in the BGP update message. The PE originating the BGP 
> 
> update message would specify the label which it expects 
> 
> to see on received control packets for the specified MVPN. 
> 
> ################################## 
> 
> 
> In the above description, a demultiplexor is used to 
> distinguish different MVPN streams of traffic carried over a 
> tunnel. But in my implemention of MVPN, the demultiplexor not 
> only says to which specific MVPN a packet belongs, but also 
> identifies the ingress PE.

I assume here you are talking about demultiplexing multicast data packets, not control packets (even though the text you refer to talks about a demultiplexer for unicasting multicast control packets). If so, the multicast data packet demultiplexer label for unicast tunnels also identifies the ingress PE. As per section 6.4.1:

"When ingress replication is used, the MVPN to which the received C-multicast data packet belongs can be determined by the MPLS label that was allocated by the egress. This label is distributed by the egress.  This also determines the RPF interface for the C-multicast data packet."

> For this reason, there is no need to carry ingress PE’s address 
> in multicast traffic with a special encapsulation such as GRE 
> for the purpose of RPF checking and other uses.

In the case of GRE encapsulation, please can you explain why you think carrying the ingress PE's source address in the P-IP header is an issue? 

> The details about encapsulation are speciafied in section 11 of the 
> draft mentioned above. 
>
> That is to say,in my implemention of MVPN, each PE will 
> assign a unique label to every one of the other PEs within 
> the above MVPN, and those unique labels are associated to a 
> particular MVRF related to the above M VPN.

This is true of any P2P tunnel LSP, the P2P nature of the signalling means that a PE will receive a different label from each PE. Again, this has nothing to do with PWs.

> These PWs can be looked as virtual interfaces between each
> pair of the above PEs, which are bound to a particular MVRF. 
> 
> These PWs mentioned above could be established via BGP or 
> targeted LDP . 
> 
> Of course, BGP is still can be used to carry PIM C-instance 
> control message after the PWs are eatablished between each 
> pair of PEs within the same MVPN. That is to say, PIM 
> C-instance control messages can be carried in BGP updates and 
> multicast traffics can travel over PWs.

Based on the information you have provided so far, your solution does not provide any advantages over ingress replication with MPLS unicast tunnels as already described in the draft.

Regards,
Richard

> Sincerely 
> 
> Steven Joe 
> 
> Huawei Technologies Co.,Ltd. 
> 
> Email: xuxh at huawei.com 
>