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

From: [email-masked]
Date: Thu, 1 Dec 2005 15:05:07 -0000

Luca,

Thanks, some more comments in-line...

Luca Martini <mailto:[email-masked]> wrote:
>> 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? 
>> 
> 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.

Agreed.

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

Hmmm.  Not sure I see how TE in the MPLS (server) layer automatically
provides plentiful bandwidth (and negates the need for TE) in the PW
layer as there may not be a 1:1 mapping between PWs & MPLS LSPs.

If you want to guarantee bandwidth at the PW layer then you need some
way to select a path with an appropriate level of spare bandwidth (which
may not be the SPF path) and to signal the bandwidth guarantee that you
require along that path (or reserve it using OSS) at the PW layer -
that's what I'd call TE.  Does your definition vary from mine?

[I make no assertion that MS-PW TE is a requirement, only that *if* it
is a requirement, then TE at the MPLS layer is not by itself sufficient
to fulfil such a requirement.]

Ben

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

---

From: Luca Martini <[email-masked]>
Date: Thu, 01 Dec 2005 11:41:59 -0700

> that's what I'd call TE.  Does your definition vary from mine?
Yes. That is exactly the point I was trying to make. You do need some 
way to signal the bandwidth requirements of a PW, however
traffic engineering requires a lot more then just signaling bandwidth. 
Traffic engineering requires a full picture of all available links and 
resources, a constrained SPF Function, and the ability to signal an 
explicit path/resources required.
Adding the ability to PW to request the bandwidth, from the MPLS network 
does not constitute traffic engineering of the PW layer.

Traffic engineering is about efficiently managing a set of scarce 
resources. If the resource we are using TE for is the link bandwidth, 
then we can easily request the popper resources from the MPLS network layer.
Adding a full traffic engineering function to the PW layer would allow 
us to manage S-PE resources like local interfaces , and memory.
However, is S-PE interface bandwidth, and memory a resource that we need 
to manage ?
Given current ethernet interface prices , and memory prices , I would 
think that it make more economical sense to manage the more expensive 
part of a network, like WAN links, and operational costs.

Luca

---

From: Jixiong Dong <[email-masked]>
Date: Fri, 02 Dec 2005 18:13:09 +0800

some comments see in-line

Best Regards,
Dong

----- Original Message ----- 
From: "Luca Martini" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 02, 2005 2:41 AM
Subject: Re: [PWE3] RSVP MS-PW ? HOW?

> does not constitute traffic engineering of the PW layer.
[Dong] Agree. We don't need the full traffic engineering functions in PW layer.
We only need to select the tunnel(s) that meet the requirements of PW
TE attributes because PW is carried on tunnel. That is to say, the functions 
of PW TE is signaling the PW TE attributes and select the suitable TE 
tunnel on the S-PEs. See the following figure:

T-PE1----(T1)------S-PE1---(T3)---------S-PE2---------------T-PE2
                               |                            |
                               |(T2)                      |
                               |                            |
                          S-PE3-----------------S-PE4
If we use dynamic signaling and dynamic routing, when pw signaling arrives S-PE1,
we have two choices, one is T3 and next hop is S-PE2, one is T2 and next hop is 
S-PE3. We must decice which tunnel can meet the requirements of PW TE. e.g.
PW.TE.bandwidth=2M, T3.TE.bandwidth=1M, T2.TE.bandwidth=10M, we must 
select T2(S-PE3) not T3(S-PE2). Note that the TE path is not the shortest path.
This function can't be implemented by the current tunnel TE functions(i.e., MPLS TE).
The essential reason is the PW is end-to-end(span-tunnel) PW, but the tunnel is 
based on pw segment.