Re: L3VPN on bidirectional RSVP-TE tunnel with virtual router

[Robert Raszuk <raszuk at cisco.com>]

> and more efficient method to meet the reqirement.<p><p>First,
> GRE/IPsec tunnel have no multiplexor,if you want to establish many
> tunnels between a pair of PEs, you must use different pairs of tunnel
> source and destination address.

Not true. In 2547 VPN label behind a GRE tunnel is the multiplexor and
works just fine.

> <p>Second, the efficiency of
> encapsulation and de-encapsulation process of GRE/IPsec is not
> desirable,especially in the case of fragmentation. 

That depends on your hardware and is just an implementation detail.

> <p>Third, although
> the diff-serv model using TOS bits of GRE IP header or  MPLS EXP
> field can meet the requirement of QoS, the diff-serv enabled RSVP-TE
> tunnel is more suitable for service providers to offer triply
> services and VPN services in a single MPLS/IP network because of its
> easiness for configuration and maintenance .

DS-TE does not give you anythinng if your network is not full TE
network, you have policing implemented on all ingress points as well as
you can account for other theraffic types then just unicast ipv4 (for
example multicast). AFAIK that set of requrements is rearly met in
production. Keep in mind that TE is a contorl plane only tool !

> <p><p>For MVPN, from the aspect of replication efficiency, deploying
> multicast in provider's network is prefered in the case of hub-spoke
> network structure, but the requirement for P devices is high, and the
> complexity and the amount of multicast states maintained for the data
> MDT like solutions can not be ignored.

Fair. Can you indicate the number of today's multicast states P routers
can support as well as the number of states which is required ? I agree
that SPs should have a way to bound the number of m-cast states in the P
routers but there are already many ways to achive that even today. For
example by seting proper threshold for MDT data trigger.

> Beside, PE is more powerful
> than P in today's provider networks, so I believe multicast
> relication in unicast tunnel is more acceptable for service
> providers.

IMHO it is a waist of bandwith. If one's vendor P routers have issues in
replication of MVPN groups for control/data MDT they equally may have
problems for distribution of internet multicast flows and therefor it
may be good idea not to use them as P routers.

> As routing protocols such as OSPF and PIM can be run over
> bidirectional RSVP-TE tunnel interfaces, so MVPN is easy to be
> implemented and multicast traffices travelling in TE tunnel can
> inherit all of the benifits of RSVP-TE tunnel, such as QoS and
> FRR.<p>

There is nothing to prevent one to put control/data MDTs into p2mp TE
LSPs today.

<p>Thanks for your response once again.<p>

You are welcome !

Cheers,
R.



<p>Best
> regards! <p> <p>Steven Joe<p>Huawei Technology Co.,Ltd.<p!
>> xuxh at hu
> awei.com<p><p><p><p><p><p>----- Original Message ----- <p>From:
> "Robert Raszuk" <raszuk at cisco.com><p>To: <freshguy at sohu.com>;
> <xuxh at huawei.com><p>Cc: <l3vpn at ietf.org><p>Sent: Saturday, October
> 01, 2005 3:28 AM<p>Subject: Re: L3VPN on bidirectional RSVP-TE tunnel
> with virtual router<p><p><p>> Hi,<p>> <p>>> <p>Virtual router<p>>>
> technology provides a easy and flexible procedure to implement
> L3VPN.<p>> <p>> That's a pretty brave statement. Let me just point
> out that there are at<p>> least of couple of alternatives to provide
> L3VPNs a bit wider deployed<p>> then VR's based L3VPNs.<p>> <p>>> But
> as GRE/IPsec tunnel has no properties such as TE, QoS and fast<p>>>
> convergence features, the L3VPN implemented on GRE/IPsec tunnel
> is<p>>> not popular with service providers. <p><p>> <p>> I am afraid
> that those are not the reasons for wider deployment of<p>> tunneling
> with MPLS then with GRE/IPSec :).<p>> <p>> Your observation is
> correct that if you require traffic to flow in both<p>> directions
> between VRs over unidirectional TE tunnels you may require a<p>> pair
> of those - I don't think a lot of people will argue with that.<p>>
> <p>> As far as QoS or convergence if you have correctly
> architected<p>> diff-serve in your network using TOS bits from GRE IP
> header or from<p>> MPLS EXP field should result in the same PHB.<p>>
> <p>>> In contrast to BGP/MPLS VPN defined in<p>>> [RFC2547bis],
> multicast is easier to be impl! emented and multicast<p>>> traffics
> can travel in RSVP-TE tunnel with such L3VPN.<p>> <p>> Would you care
> to elaborate on that point ? If possible could you list<p>> the data
> points and facts you base your opinion on ? Please include the<p>>
> comparison of replication efficiency and number of m-cast states in
> your<p>> response.<p><p>> <p>> R.<p>> <p>> <p>> <p>> <p>>> <p>RSVP-TE
> is very suitable<p>>> to provide MPLS VPN service with the
> requirement of high availability<p>>> and QoS assurance because it
> consists of many good features such as<p>>> TE, QoS and fast
> convergence. As RSVP-TE tunnel is unidirectio! nal, it< p>>> can not
> be used to implement L3VPN through virtual router technology<p>>> as
> GRE tunnel. <p><p><p>Through the binding of two unidirectional<p>>>
> RSVP-TE tunnels established between a pair of LSRs destined to
> each<p>>> other, a bidirectional RSVP-TE tunnel is formed. Like
> GRE/IPsec<p>>> tunnel, the bidirectional RSVP-TE tunnel can be used
> to establish<p>>> L3VPN with virtual router. In contrast to BGP/MPLS
> VPN defined in<p>>> [RFC2547bis], multicast is easier to be impl!
> emented and multicast<p>>> traffics can travel in RSVP-TE tunnel with
> such L3VPN. This L3VPN<p>>> fully inherits the property of RSVP-TE,
> such as TE, QoS and fast<p>>> convergence features. In addition, the
> bidirectional RSVP-TE tunnel<p>>> has many other purposes, such as
> interconnection of two separate<p>>> routing domains through a
> RSVP-TE tunnel and implementing LDP over<p>>> TE.<p> <p>The decision
> factors of RSVP-TE tunnel binding include<p>>> tunnel source address,
> tunnel destination address and binding key.<p>>> The reason for
> making binding key as one of the decision factors is<p>>> that a LSR
> can setup different RSVP-TE tunnels with the same pair of<p>>> tunnel
> source address and tunnel destination address, but these<p>>> tunnel
> interfaces must be configured with different binding keys.<p><p>>>
> <p>Any comment is welcomed!<p> <p>Best regards!<p> <p> <p>Steven<p>>>
> Joe<p>Huawei Technology Co.,Ltd.<p>xuxh at huawei.com<p><p>>