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

[xuxiaohu 41208 <xuxh at huawei.com>]

Hi, Thomas

Thanks a lot for your response.

TE tunnels established between a pair of  PEs destined to each other are unidirectional and disrelated. As packets are received over TE tunnel by egress LSR,  it can not be determined from which VPN and from which PE these packets are transimitted. PWs are bidirectional virtual link  between each pair of PEs and are bound to a particular VRF,  As packets are received over PW by egress LSR,  it can not be determined from which VPN and from w
hich ingress PE these packets are transimitted according to the VPN label info.  Of cource, bidirectional RSVP-TE tunnel  described in my previous email can also be used to realize the above goal.

    
----- Original Message ----- 
From: "Thomas D. Nadeau" <tnadeau at cisco.com>
To: "xuxiaohu 41208" <xuxh at huawei.com>
Cc: <l3vpn at ietf.org>; <cli at futurewei.com>; <sdawkins at futurewei.com>
Sent: Thursday, October 06, 2005 8:32 PM
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;

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

begin:vcard
n:;xuxiaohu
fn:xuxiaohu
version:2.1
email;internet:xuxh at huawei.com
end:vcard