The MPLS WG Archive

[richard.spencer@bt.com]

Steven,

Before asking for more comments from another WG, wouldn't it be better to first address the comments/questions raised by Robert Raszuk and myself on the L3VPN mailing list?

I think you will find that a significant number of people subscribe to both mailing lists, and that the L3VPN mailing list is more appropriate for your draft as it is focussed on L3VPNs.

To make things easier, I have summarised the comments that have been raised so far below.

Regards,
Richard

-------------------------------------------
>From Robert Raszuk:

> <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.

> 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.

----------------------------------------------
>From Richard Spencer:

> <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.

> -----Original Message-----
> From: mpls-bounces@lists.ietf.org 
> [mailto:mpls-bounces@lists.ietf.org]On Behalf Of xuxiaohu 41208
> Sent: 06 October 2005 08:29
> To: mpls@ietf.org
> Subject: [mpls] Bidirectional RSVP-TE tunnel
> 
> 
> Dear members of the mpls distribution list: 
> 
> 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. 
> 
> 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. 
> 
> 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 
> implemented 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. 
> 
> 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. 
> 
> 
> Any comment is welcomed! 
> 
> 
> Best regards! 
> 
> 
> 
> Steven Joe 
> 
> Huawei Technology Co.,Ltd. 
> 
> xuxh@huawei.com 
>  
>  
> 
> 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls