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

From: [email-masked]
Date: Sat, 1 Oct 2005 00:19:29 +0800 (CST)

Dear members of the l3vpn distribution list:<p> <p>Virtual router technology provides a easy and flexible procedure to implement L3VPN. 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> <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>[email-masked]<p>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 30 Sep 2005 12:28:14 -0700

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>[email-masked]<p>