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

[richard.spencer at bt.com]

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
> services and VPN services in a single MPLS/IP network because of its
> 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