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

[Robert Raszuk <raszuk at cisco.com>]

Hi,

> <p>Virtual router
> technology provides a easy and flexible procedure to implement L3VPN.

That's a pretty brave statement. Let me just point out that there are at
least of couple of alternatives to provide L3VPNs a bit wider deployed
then VR's based L3VPNs.

> But as GRE/IPsec tunnel has no properties such as TE, QoS and fast
> convergence features, the L3VPN implemented on GRE/IPsec tunnel is
> not popular with service providers. <p>

I am afraid that those are not the reasons for wider deployment of
tunneling with MPLS then with GRE/IPSec :).

Your observation is correct that if you require traffic to flow in both
directions between VRs over unidirectional TE tunnels you may require a
pair of those - I don't think a lot of people will argue with that.

As far as QoS or convergence if you have correctly architected
diff-serve in your network using TOS bits from GRE IP header or from
MPLS EXP field should result in the same PHB.

> In contrast to BGP/MPLS VPN defined in
> [RFC2547bis], multicast is easier to be impl! emented and multicast
> traffics can travel in RSVP-TE tunnel with such L3VPN.

Would you care to elaborate on that point ? If possible could you list
the data points and facts you base your opinion on ? Please include the
comparison of replication efficiency and number of m-cast states in your
response.<p>

R.




> <p>RSVP-TE is very suitable
> to provide MPLS VPN service with the requirement of high availability
> and QoS assurance because it consists of many good features such as
> TE, QoS and fast convergence. As RSVP-TE tunnel is unidirectional, it
> can not be used to implement L3VPN through virtual router technology
> as GRE tunnel. <p><p><p>Through the binding of two unidirectional
> RSVP-TE tunnels established between a pair of LSRs destined to each
> other, a bidirectional RSVP-TE tunnel is formed. Like GRE/IPsec
> tunnel, the bidirectional RSVP-TE tunnel can be used to establish
> L3VPN with virtual router. In contrast to BGP/MPLS VPN defined in
> [RFC2547bis], multicast is easier to be impl! emented and multicast
> traffics can travel in RSVP-TE tunnel with such L3VPN. This L3VPN
> fully inherits the property of RSVP-TE, such as TE, QoS and fast
> convergence features. In addition, the bidirectional RSVP-TE tunnel
> has many other purposes, such as interconnection of two separate
> routing domains through a RSVP-TE tunnel and implementing LDP over
> TE.<p> <p>The decision factors of RSVP-TE tunnel binding include
> tunnel source address, tunnel destination address and binding key.
> The reason for making binding key as one of the decision factors is
> that a LSR can setup different RSVP-TE tunnels with the same pair of
> tunnel source address and tunnel destination address, but these
> tunnel interfaces must be configured with different binding keys.<p>
> <p>Any comment is welcomed!<p> <p>Best regards!<p> <p> <p>Steven
> Joe<p>Huawei Technology Co.,Ltd.<p>xuxh at huawei.com<p>