Subject: Re:Multicast in BGP/MPLS VPN with pseudo wires technology

From: xuxiaohu 41208 <[email-masked]>
Date: Thu, 06 Oct 2005 11:40:51 +0800

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. 
Second, multicast is not required in P devices. It's easy to maintain such MVPN and it is good for protecting original investment.
Third, replication on PE can share the burden on P router 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. 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. The det
ails 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. 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.

Sincerely 

Steven Joe 

Huawei Technologies Co.,Ltd. 

Email: [email-masked] 

Subject: MVPN
From: xuxiaohu 41208 <[email-masked]>
To: [email-masked]
Date: Thu, 06 Oct 2005 11:35:53 +0800

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. 
Second, multicast is not required in P devices. It's easy to maintain such MVPN and it is good for protecting original investment.
Third, replication on PE can share the burden on P router 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. 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. The det

ails 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 MVPN. 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.

Sincerely 

Steven Joe 

Huawei Technologies Co.,Ltd. 

Email: [email-masked]

---

From: [email-masked]
Date: Thu, 6 Oct 2005 16:56:57 +0100

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: [email-masked] 
> [mailto:[email-masked]]On Behalf Of xuxiaohu 41208
> Sent: 06 October 2005 04:41
> To: [email-masked]; [email-masked]
> Subject: Re:Multicast in BGP/MPLS VPN with pseudo wires technology
> 
> 
> 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. 
> 
> 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: 
> 
> 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. 
> 
> 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

---

From: xuxiaohu 41208 <[email-masked]>
Date: Wed, 12 Oct 2005 10:06:09 +0800

Hi,Spener,

Thanks for your professional comments first:)
   
As you mentioned in your last email, draft-ietf-l3vpn-2547bis-mcast-00 exactly mentioned that MPLS can be used as unicast tunnel for ingress replication .The following detailed description of demultiplexor is included in section 6.1.1 and section 11.3 of the above draft:
************************************************************************
6.1.1. Auto-Discovery for Ingress Replication

   In order for a PE to use Unicast Tunnels to send a C-multicast data
   packet for a particular MVPN to a set of remote PEs, the remote PEs
   must be able to correctly decapsulate such packets and to assign each
   one to the proper MVPN. This requires that the encapsulation used for
   sending packets through the tunnel have demultiplexing information
   which the receiver can associate with a particular MVPN.

   Thus an ingress PE must not transmit C-multicast data through a
   particular kind of unicast tunnel to a particular remote PE unless it
   knows that the remote PE has supports that particular tunnel
   encapsulation, and unless there is some agreement between the two PEs
   as to what values of the demultiplexing information represent which
   MVPNs.  If a PE is capable of ingress replication for an MVPN, it
   announces this as part of the BGP based MVPN membership auto-
   discovery process, described in section 4. The following information
   elements need to be advertised by a PE:

      1. The ability to support ingress replication for a particular
         MVPN, using a particular encapsulation format (e.g., MPLS,
         MPLS-in-GRE).

      2. A mapping of demultiplexing values to MVPNs.

         If the encapsulation format is MPLS or MPLS-in-something, the
         demultiplexing values may be downstream-assigned MPLS labels.
         The encapsulation procedures are described further in section
         11.

11.3. Encapsulations for Unicasting PIM Control Messages

   When PIM control messages are unicast, rather than being sent on an
   MI-PMSI, the the receiving PE needs to determine the particular MVPN
   whose multicast routing information is being carried in the PIM
   message.  One method is to use a downstream-assigned MPLS label which
   the receiving PE has allocated for this specific purpose.  The label
   would be distributed via BGP.  This can be used with an MPLS, MPLS-
   in-GRE, or MPLS-in-IP encapsulation.

   A possible alternative to modify the PIM messages themselves so that
   they carry information which can be used to identify a particular
   MVPN, such as an RT.

   This area is still under consideration.
**************************************************************************
>From the above descriptions, we can not determine that a PE assigned different labels as demultiplexor for special MVPN to different PEs within the same MVPN. On the contrary, the label is only a demultiplextor for MVPN in egress PE and is unrelated to ingress PE. So the egress PE can not determine ingress PE from which the received packet is transmitted just from the demultiplextor label.

So the ingress PE's address should be carried in multicast data packets with MPLS-in-GRE or MPLS-in-IP encapsulation, or the TE tunnel with PHP off between PEs can also determine the ingress PE. 

The reason that MPLS-in-GRE or MPLS-in-IP encapsulation is not prefered in my method of implementing ingress replication is the encapsulation and decapsulation efficiency is low relatively. 

Regard
Steven Joe