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

From: xuxiaohu 41208 <[email-masked]>
Date: Thu, 06 Oct 2005 11:16:43 +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: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 6 Oct 2005 08:32:43 -0400

> 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;

     Can you explain why this is different from the already
deployed approach where TE tunnels are established between
PEs?

> 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;

     I am interested to hear from operators whether they think
of this approach in the context of operational issues.

     --Tom

> 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.
> Second, multicast is not required in P devices. It's easy to  
> maintain such MVPN and it is good for protecting original investment.
> 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
> 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.
>
> 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
>

---

From: Eric Rosen <[email-masked]>
Date: Sun, 23 Oct 2005 22:58:17 -0400

I don't think this draft describes a "new" method of doing MVPN, and I don't
think it really has anything to do with pseudowires either.  It does however
draw attention  to an issue  that arises if  multicast is done using  a PMSI
which is instantiated as a set of unicast MPLS tunnels.

The draft presupposes that support for this scenario will require the egress
PE to be able to determine, for such each packet received via a unicast MPLS
tunnel, the identity of its ingress PE.  In general, the top label which the
inpress 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.  So  the draft  suggests that  each egress
assign a distinct  label to each possible ingress, and  that the ingress put
this label on the packet below the top label.  

Whether this  is a real issue  depends on whether  its presupposition holds:
does the  egress PE  need to be  able to  identity the ingress  PE of  a VPN
multicast packet which travels through a unicast MPLS tunnel?

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.  

So I think this may be a valid issue.  However, before looking at solutions,
I think we  need further clarification as to precisely what  we need to know
about the data packets  (e.g., do we really need to know  the ingress, or do
we just need to know whether  the packet is traveling the shared tree?), and
what we will do differently depending on where the packets are from.