[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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. 
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: xuxh at huawei.com 
--- Begin Message ---
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: xuxh at huawei.com

--- End Message ---