Subject: RE: [PWE3] RSVP MS-PW ? HOW?

From: [email-masked]
Date: Tue, 29 Nov 2005 11:43:57 -0000

Luca,

I don't want to enter into a RSVP-TE Vs LDP debate for MS-PWs (as I have
no opinion one way or the other).  However I would like to try and
understand the reasoning behind one of your comments better...

> In today's deployments RSVP-TE is used to setup MPLS tunnels
> that carry PWs.  These tunnels are sometimes dedicated to
> PWs, and are traffic engineered in the MPLS network along
> with other MPLS tunnels that may be used for other purposes.
> One of the main parameters used for TE is bandwidth
> utilization.  If we are proposing to traffic engineer the PW
> layer itself, then we would presumably be able to select a
> certain subset of statically pre-configured MPLS-TE tunnels
> to carry the PWs and reserve the utilized bandwidth once the
> PW is signaled.  Traffic engineering of PW would mean that
> S-PEs are selected based on available bandwidth to reach them.
> The question is why?  We already traffic engineered the MPLS
> tunnels across the MPLS network, why should be make this
> network an order of magnitude more complicated by traffic
> engineering PWs on top of already traffic engineered tunnels?

Your argument appears to be: why bother traffic engineering the client
(i.e. the MS-PW layer network) when we have already traffic engineered
the server (the IP/MPLS layer networks) and this is the argument that I
don't really follow or fully understand.

MS-PWs are a separate layer network to the MPLS (or IP) layer network(s)
that they run over.  So, a MS-PW link (between a U-PE and a S-PE or
between two S-PEs) is supported by a concatenation of MPLS (or IP)
links.  This is no different to any other client/server relationship
between any pair of layer network technologies.

So, following your logic I could argue, why bother traffic engineering
an MPLS network when you've already traffic engineered the SONET/SDH
network that it runs over?

It may well be the case that there is no (service provider)
requirement(s) to traffic engineer MS-PW layer networks, in which case
traffic engineering PWs is not a useful feature as you assert.  However,
I don't believe that having a traffic engineered server layer
automatically negates the need for traffic engineering in the client
layer.

Have I misunderstood your argument (or taken it out of context)?

Thanks
Ben

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Luca Martini <[email-masked]>
Date: Wed, 30 Nov 2005 16:54:24 -0700

Ben,

I was perhaps a little too brief in this comment. More thoughts below..

> network that it runs over?
In fact you usually do both... The SDH network traffic engineering cycle 
might be 30 days , while the client MPLS network  might be traffic 
engineered every 10 minutes .
Also the granularity is quite different between the two layers.

> automatically negates the need for traffic engineering in the client
I agree with your last statement. In fact I did not intend to say that.

In the case of the PW , I believe that a SP would want to traffic 
engineer the PW along with all other applications running on the MPLS 
network.
So if we traffic engineer the server layer ( MPLS LSPs ) then what is 
left in the client layer ?
in other words what resources are scarce on the S-PEs that we need to 
manage efficiently ? Certainly not bandwidth , as that is taken care of 
by the MPLS network.
This situation is very different from the SDH and MPLS/IP layers where 
we have significant differences in how we can manage the resource: 
bandwidth.

The only situation that would be interesting is the case where we have 
SP boundary S-PE connection to other SPs.
The equivalent problem in the IP world today is handled by people over 
telephone conversations. ( when a peering point congests the first thing 
is to try to move traffic to another peering point ).
I really doubt that in the case of PWs any automatic methodology will be 
acceptable, when there are too many non technical factors to consider in 
such a traffic engineering function.

Thanks.
Luca