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

From: Robert Raszuk <[email-masked]>
Date: Fri, 30 Sep 2005 23:06:01 -0700

> 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@hu
> awei.com<p><p><p><p><p><p>----- Original Message ----- <p>From:
> "Robert Raszuk" <[email-masked]><p>To: <[email-masked]>;
> <[email-masked]><p>Cc: <[email-masked]><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>[email-masked]<p><p>>

---

From: [email-masked]
Date: Sat, 1 Oct 2005 09:25:04 +0100

Steven,

> <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
> easiness for configuration and maintenance.

I don't understand your logic here, you state that diffserv is adequate to meet QoS requirements, but then go on to say that diffserv TE is more suitable for triple play services because its easier to configure/maintain. How can diffserv TE be easier to configure/maintain than diffserv alone? Why is simplifying configuration/maintenance for triple play service more important than for other services?

Diffserv TE doesn't improve QoS, the forwarding behaviour in the data plane is exactly the same. Instead, diffserv TE allows a provider to reserve bandwidth (using backup TE tunnels) for higher priority traffic to guarantee that if a failure occurs, there will still be enough bandwidth for higher priority traffic. Depending on the amount of high priority traffic being carried and the amount of spare capacity in the network under normal load conditions (over provisioning), diffserv TE may or may not be the best solution. As the amount of higher priority traffic being carried increases, the more likely it is that diffserv TE will be beneficial, although diffserv alone with multiple ECMP paths may still be adequate. 

I would argue that diffserv TE is much more difficult to configure/maintain, not only do you need to configure diffserv, but you need to setup the RSVP-TE tunnels and engineer backup tunnels in such a way that when a failure occurs there is enough capacity in the network to continue to forward the higher priority traffic. You also need to configure policers and queue weights to police the bandwidth limits signalled using RSVP-TE, whilst taking failures scenarios into account.

To be clear, I'm not saying that diffserv TE isn't useful/important. My point is that its not easier to configure/maintain than diffserv alone and that it doesn't improve QoS. Instead, it offers the ability to guarantee bandwidth for higher priority traffic classes under failure conditions.

> Beside, PE is more powerful than P in today's provider networks,

A PE (edge) router is more powerful than a P (core) router with respect to what? If this simplistic statement were true then why do we have core routers at all, why not use edge routers in the core? Also, why are core routers in general much more expensive than edge routers then? Obviously your simplistic statement is incorrect, although it is true to say that edge routers and core routers are designed to meet different requirements and therefore are optimised to support different features/functions.

> so I believe multicast relication in unicast tunnel is more 
> acceptable for service providers.

Can you expand on your reasoning behind this? If replication at the edge based on unicast tunnels was acceptable, then why do you think vendors/providers spent time developing/deploying PIM/GRE IP VPN and RSVP-TE P2MP solutions?

Replication in the core may or may not be required depending on the network topology, where the traffic source is located, and on the bandwidth requirements of the multicast traffic being carried. However, in most cases where multicast traffic is being carried edge-to-edge across the core, such as in the VPN environment, I would say that replication in the core is essential. 

Regards,
Richard