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

["Thomas D. Nadeau" <tnadeau at cisco.com>]

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

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