Subject: [Pce] FW: Pce Digest, Vol 33, Issue 7

From: Young Lee <[email-masked]>
Date: Thu, 10 May 2007 15:11:21 -0500

Hi J-P, 

Thanks for your valuable comments and suggestions. I believe all of your
comments and concerns have been carefully looked at and clarified. Please
see inline for our response.

Best Regards,

Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, May 10, 2007 11:00 AM
To: [email-masked]
Subject: Pce Digest, Vol 33, Issue 7

Send Pce mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/pce
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Pce digest..."

Today's Topics:

   1. Comments on
      draft-lee-pce-global-concurrent-optimization-03.txt (JP Vasseur)
   2. Description of OpenWait state ([email-masked])

----------------------------------------------------------------------

Message: 1
Date: Wed, 9 May 2007 20:58:44 -0400
From: JP Vasseur <[email-masked]>
Subject: [Pce] Comments on
	draft-lee-pce-global-concurrent-optimization-03.txt
To: Young Lee <[email-masked]>,	LE ROUX Jean-Louis RD-CORE-LAN
	<[email-masked]>,	Eiji Oki
	<[email-masked]>,	Daniel King
<[email-masked]>,
	[email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Hi,

The authors requested the WG to adopt draft-lee-pce-global-concurrent- 
optimization-03.txt as a PCE WG document but before pooling the list,  
I'd like to make a few comments/requests:

This solution is indeed compliant with RFC4655 and as pointed out in  
the ID, PCEP already supports synchronized path computation requests  
through the use of the SVEC object.

1) The PCEP extensions defined in this document are quite reasonable  
and do not substantially overload the protocol itself. That being  
said, the exchange of a substantially large amount of data will  
unavoidably stress the machinery in a significant way. Scalability of  
solutions trying to achieve global optimization have been discussed  
in length so I won't propose to re-open a fairly old debate but it is  
well-understood that such solutions do not scale well and the major  
bottleneck is not just the path computation itself but the bulk of  
data that must be exchanged, synchronization issues, failures during  
reoptimization and so on. Thus I'd suggest to add some applicability  
section to this ID that would discuss the context in which such  
solution would apply (e.g. network with thousands of packet LSPs  
(hopefully not!), optical LSPs with a few hundreds of LSPs with multi- 
constraints optimization problems where bandwidth fragmentation is a  
real issue because of a limited number of discrete bandwidth values).

>> We can add applicability section to elaborate this request. We can
indicate that this mechanism applies specifically to GMPLS optical networks
with a few hundreds of LSPs. 

2)

    It is also envisioned that network operators might
    require a global concurrent path computation in the event of
    catastrophic network failures, where a set of TE LSPs need to be
    optimally rerouted in real-time.

I do not think that such model could be used for "real-time" rerouting.

>>  I agree with you. We can remove this statement. 

3)

    The main focus of this document is to highlight the PCC-PCE
    communication needs in support of a concurrent path computation
    application and to define protocol extensions to meet those needs.

You may want to stress the fact that in your ID the PCC is an NMS  
system and this is key. Indeed, one can define models where the PCCs  
are LSRs and the PCE is used to provide globally optimal  
solutions ... Such models suffers from drastic scalability and  
robustness issues.

>> The PCE GCO is primarily an NMS based solution. In section 3.3
(Application of PCE architecture) of the current draft clearly spells out
that GCO is NMS based solution.  With GCO, a PCC has to know all LSP
requests, hence this cannot be a LSR. 

4) Green field: not sure to buy this argument since as soon as the TE  
LSPs are set up, the network is no longer in this green field state

>>  OK.  The main use of GCO application is re-optimization of an existing
network. 

5)

    Note that sequential re-
    optimization of such TE LSPs is unlikely to produce substantial
    improvements in overall network optimization except in very sparsely
    utilized networks.

Well, that DEPENDS ! I could show you distributed algorithms where  
sequential reoptimization allows for a significant improvements. I  
would suggest to remove that statement.

>> Yes, it actually depends on the topology, the traffic matrix, the online
algorithm used, etc. We will delete this statement. 

6) A Multi-Session Indicator: I'm not exactly sure that we should  
overload the machinery even more w/o more experience on how such  
feature could actually help. May I suggest to potentially add it in a  
second phase?

>>  OK. We can move this feature to a second phase.  
 
7) A word of cautious here

          During a reoptimization it may be required to move a LSP
          several times so as to avoid traffic disruption.  The response
          message must allow indicating the path sequence for each
          request.

We all know that in some cases, traffic disruption may be avoided  
thanks to a multi-step rerouting approach where some TE LSP may be  
rerouted N times. This is another example where such model may have  
significant impact on the network and even when traffic disruption  
can be avoided, there is still an impact in term of control plane,  
traffic shift (=> jitter) although this can be another constraint  
taken in to account when computing the various rerouting steps. For  
example, would you want to add a paragraph listing the drawbacks of  
such approach (e.g. trade-off between optimization gain and network  
impact, ....) ?

>> We can add a paragraph to indicate the potential impact by this feature.
By the way the trade-off is not optimization vs. network impact. It is
traffic disruption vs. network impact. If we want to avoid traffic
disruption, we need this multiple rerouting, which is the price to pay at
the expense of network impact. 

8) Objective functions should be moved to PCEP, as discussed.

>>  Just for clarification, in Prague, it was agreed with Jerry and the
authors of the PCE-OF draft that all the objective functions listed in 4657
will be defined in the PCE-OF draft provided that PCE-OF draft would be
adopted as WG doc. It was also agreed that any new application driven
objective functions will be defined in the application draft via the OF code
point mechanism specified in PCE-OF draft. 

This includes the following Objective Functions from 4657: 

Extract from 4657 section 5.1.17: 

Also, the PCECP MUST support at least the following "synchronized"
   objective functions:

   - Minimize aggregate bandwidth consumption on all links
   - Maximize the residual bandwidth on the most loaded link
   - Minimize the cumulative cost of a set of diverse paths

in GCO we defined 3 OF

   1    Minimize the sum of all TE LSP costs (min cost)

   2     Maximize the residual bandwidth on the most loaded
         link

   3     Evenly allocate the network load to achieve the
         most uniform link utilization across all links*

 Actually function 2 is listed in 4657 and will have to be moved to the OF
draft. Other functions (1 and 3) are not listed in 4657 and should stay in
the GCO draft.

9) LSP ordering is always requested by the PCC but it might be  
desirable to have the PCE indicating whether ordering is in fact  
required or not. For example, the NMS could send a reoptimization  
request to which the PCE would reply with a ordered or non-ordered  
set of computed paths.

>> Yes, we can accommodate your request in the new version. 

Thanks.

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

End of Pce Digest, Vol 33, Issue 7
**********************************

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

---

From: JP Vasseur <[email-masked]>
Date: Thu, 10 May 2007 17:22:10 -0400

Hi,

On May 10, 2007, at 4:11 PM, Young Lee wrote:

> comments and concerns have been carefully looked at and clarified.

Thanks for addressing my comments - see in line,

> Please

OK Thanks.

>>>  I agree with you. We can remove this statement.

OK

> requests, hence this cannot be a LSR.

Well that could be done with PCC=LSR thanks to complex  
synchronization (which I'm NOT advocating of course)
hence my comment. Could you restate in the abstract/Introduction that  
in your proposal the PCC is indeed an NMS.

Thanks.

>>>  OK. We can move this feature to a second phase.

OK Thanks.

> the expense of network impact.

OK let me restate my comment here: the point I was trying to make is  
the following: even if the set of
TE LSPs can be reoptimized with no traffic loss for example, the need  
for multiple reroutes has a
cost in term of traffic impact (jitter, ...) + control plane stress.  
It may be worth mentioning that aspect
also, this is why I mentioned a trade-off between optimization versus  
network impact. Indeed, if you
can reoptimize the set of TE LSPs in order to reduce the max link  
utilization by 5% but this requires to
reroute two hundreds TE LSPs with on the average 4 reroutes per TE  
LSP, this may not be a good idea.

>
> 8) Objective functions should be moved to PCEP,

I typed too fast: I indeed meant to refer to the objective function  
draft, as agreed with Jerry since I was
pushing myself for not adding more to PCEP.

> as discussed.

Good thanks. I'll wait until you respin the ID and then will pool the  
list.

JP.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 11 May 2007 10:13:45 +0100

[Tidied up from Digest response thread]

<chair hat firmly OFF>

>>> The authors requested the WG to adopt draft-lee-pce-global-
>>> concurrent-optimization-03.txt as a PCE WG document but before
>>> pooling the list, >>> I'd like to make a few comments/requests:
>>>
>>> This solution is indeed compliant with RFC4655 and as pointed out in the 
>>> ID, PCEP already supports synchronized path computation requests through 
>>> the use of the SVEC object.
>>>
>>> 1) The PCEP extensions defined in this document are quite
>>> reasonable and do not substantially overload the protocol
>>> itself. That being said, the exchange of a substantially large
>>> amount of data will unavoidably stress the machinery in a significant 
>>> way. Scalability of solutions trying to achieve
>>> global optimization have been discussed in length so I won't propose to 
>>> re-open a fairly old debate but it is well-understood
>>> that such solutions do not scale well and the major bottleneck is not 
>>> just the path computation itself but the bulk of data
>>> that must be exchanged, synchronization issues, failures during
>>> reoptimization and so on.

Indeed, the path computation bottle-neck is clearly an algorithmic
issue that is out of scope here, and I know some would argue that
solutions exist that remove that bottle-neck.

I think that the other items listed would valuably be the subject of
health warnings in an applicability statement as JP suggests, but it
should be noted that this does not limit the applicability based on
the network size or the set of LSPs being reoptimized. Rather, it
limits the applicability to how the reoptimization is being used and
coordinated by a management plane.

The difference between a global reoptimization and a bulk re-route
are subtle. It may appear that for bulk re-route all existing
services have failed and so the worst case is that connectivity is
not restored, but in packet networks FRR may be in use, so bulk
re-route failures are significant. The applicability in *that* case
includes make-before-break to ensure no disruption to traffic.

But it is also commonly accepted that restoration or re-route after
failure has two problems. The first is system congestion which is
at least as bad as global concurrent reoptimization because each
LSP-to-be restored is the subject of a PCReq and a PCRep as well as
signaling. The second is that the sequential nature of the path
computations will almost inevitably lead to blocking.

So, while I agree that the gco draft should have a very thorough
applicability section that should highlight the potential problems,
I don't think that there should be an assumption of non-applicability
to specific networks or scenarios.

>>> Thus I'd suggest to add some applicability
>> indicate that this mechanism applies specifically to GMPLS optical 
>> networks with a few hundreds of LSPs.

I would be very concerned about that limitation.
It is great to hear that you have specific intention to apply this work
to optical networks, but I do not see anything in the I-D or what JP said
that forces us to constrain the applicability in this way.
By all means, cite optical networks with a limited number of nodes as a
good example of where you might use this technique, but otherwise, you
should structure the applicability section with regard to the potential
problems, not the dataplane technology.

>>>     catastrophic network failures, where a set of TE LSPs need to
>>>     be optimally rerouted in real-time.
>>>

Define "real-time".

The applicability to the problem space is clear. A well-known set of
LSP has been impacted by a network failure. Rather than compute new
paths on demand from the head-end LSPs with the consequent resource-
contention blocking problems, there may be considerable benefit in
computing the paths of the LSPs as a set. (Of course, this assumes
the availability of certain information, but an NMS might reasonably
have access to this and make the bulk computation request.)

Thus, if there is any modification to make, I suggest only deleting
"in real-time".

>>> system and this is key. Indeed, one can define models where the PCCs are 
>>> LSRs and the PCE is used to provide globally optimal
>> (Application of PCE architecture) of the current draft clearly  spells 
>> out that GCO is NMS based solution.  With GCO, a PCC has
>> to know all LSP requests, hence this cannot be a LSR.
>
> Well that could be done with PCC=LSR thanks to complex  synchronization 
> (which I'm NOT advocating of course)
> hence my comment. Could you restate in the abstract/Introduction that in 
> your proposal the PCC is indeed an NMS.

Why would the procedures not be applicable to a head-end LSR
requesting bulk reoptimization of the set of LSPs for which it acts
as ingress? (I.e. a subset of all LSPs in the system.)

We already accept that such an LSR should be allowed to issue
individual LSP reoptimization requests. And we already accept that
a PCReq may contain multiple computation requests that are 'linked'.

So, if JP's request is that an LSR should not issue an optimization
request for an LSP for which it is not the head-end, I can see the
point. Although I might want to rephrase this because the important
question is what use is made of the computation response - that is,
if the PCC is unable to make use of the computed path, there is no
value in performing the computation.

Clearly, NMS is a primary application of this work, but it is not
the only application. Another key use would be the VNT Manager
component discussed in the multi-layer PCE drafts.

>>> 4) Green field: not sure to buy this argument since as soon as
>>> the TE LSPs are set up, the network is no longer in this green
>>> field state
>>>

Well, I would be very worried if you deleted the green-field
applicability. But I do agree that it should be put lower down the
list (although I guess it comes first in the list because it comes
first in time). And it should be rephrased, because it is not
"reoptimization" since (as JP points out) you can't reoptimize LSPs
that don't exist, and once the LSPs do exist it is not a green field.

But noting that the draft is titled "PCE Global Concurrent
Optimization" not "PCE Global Concurrent Re-optimization" I have zero
problem with the existence of this section, and I believe that
network planners will want to make use of computation servers to plan
the LSPs that they will provision in their network. This might arise
either in the green field condition or when rolling out a new
customer on top of an existing network.

>>> improvements in overall network optimization
>>>     except in very sparsely utilized networks.
>>>

Actually, I think that the sequential algorithms that JP refers to
are actually *global* reoptimization. That is, they sequence through
the set of LSPs making optimization improvements. The fact that the
algorithms are distributed is neither here nor there.

> algorithm used, etc. We will delete this statement.

So rather than deleting the statement, I suggest qualifying it.
Of course, the potential for network-wide gains from reoptimization
of LSPs one-by-one is dependent on the network usage and size of the
LSPs being reoptimized. But the key point remains: if you only
compute the reoptimized path of one LSP at a time, and if you give
no consideration to the other LSPs in the network when you do it,
you run the risk of significant devaluation of the process.

This may be far more visible in networks with a low ratio of potential
LSPs per link (such as in an optical network), and far less visible in
packet networks with micro-flow LSPs.

[SNIP]

>>>           several times so as to avoid traffic disruption.  The 
>>> response message must allow indicating the path sequence
>>>           for each request.
>>
>> By the way the trade-off is not optimization vs. network impact. It
>> is traffic disruption vs. network impact. If we want to avoid traffic 
>> disruption, we need this multiple rerouting, which is the
>> price to pay at the expense of network impact.
>
> OK let me restate my comment here: the point I was trying to make is  the 
> following: even if the set of TE LSPs can be reoptimized with no
> traffic loss for example, the need for multiple reroutes has a
> cost in term of traffic impact (jitter, ...) + control plane stress.  It 
> may be worth mentioning that aspect also, this is why I mentioned
> a trade-off between optimization versus network impact. Indeed, if you can 
> reoptimize the set of TE LSPs in order to reduce the max link  utilization 
> by 5% but this requires to reroute two hundreds TE LSPs with on the 
> average 4 reroutes per TE LSP, this may not be a good idea.

Well, that would depend, wouldn't it? If the network is unable to place
any more LSPs, one might think that retrieving 5% was pretty cool :-)

But I *do* think that a paragraph warning about the risks of re-routing
LSPs is valuable. It is often assumed that make-before-break is hitless,
and it is not. As JP points out, even in packet networks where the re-
route can occur between packets, there may be a momentary jitter impact
at the point of switch-over. This applies to *all* reoptimization and
re-route activities including FRR.

So obviously there is a trade-off to be highlighted and put under
policy control. Maybe only some LSPs are subject to re-routing - others
need to preserve their QoS.

And clearly, multiple "shuffling" of LSPs to make space is going to
increase the impact on the network. This means both that there should
be cost-benefit analysis of the reoptimization, and that such
reoptimization is unlikely to be a continuous process.

> draft, as agreed with Jerry since I was pushing myself for not adding
> more to PCEP.

[SNIP]

JP, are you saying that all objective function definitions should go
into the one objective function I-D? Or should that I-D define the
functions that we have in hand, create the code point registry, and
leave the definition of new objective functions for future I-Ds?

But still, the requirements for the objective functions need to stay
in the gco draft. So it is just a question of where the objective
functions are described in detail.

[SNIP]

Thanks,
Adrian

---

From: JP Vasseur <[email-masked]>
Date: Fri, 11 May 2007 08:38:03 -0400

Hi Adrian,

> [Tidied up from Digest response thread]

For the matter of that discussion, same here.

>>>> This solution is indeed compliant with RFC4655 and as pointed  
>>>> out in the ID, PCEP already supports synchronized path  
>>>> computation requests through the use of the SVEC object.
>>>>
>>>> amount of data will unavoidably stress the machinery in a  
>>>> significant way. Scalability of solutions trying to achieve
>>>> global optimization have been discussed in length so I won't  
>>>> propose to re-open a fairly old debate but it is well-understood
>>>> that such solutions do not scale well and the major bottleneck  
>>>> is not just the path computation itself but the bulk of data

Well let's consider the example of a packet networks with 30,000 TE  
LSPs of which 15% are impact by a single
node failure (talking realistic number, as of today), considering  
that the 4,500 affected TE LSPs have say 50 different
head-ends. The question is now whether a centralized """""real- 
time""""" path computation system could reasonably
be used to handle such scenario as opposed to the well-known  
distributed path computation ? I do agree with you with
the blocking issue pointed out above (although there are techniques  
to reduce that blocking probability),
there are many other metrics to consider of course and I'm trying not  
to re-open the old debate here ;-)

But I think that it should be clearly spelled out somewhere that the  
algorithmic issue is not the only point of possible
contention.

>>> indicate that this mechanism applies specifically to GMPLS  
>>> optical networks with a few hundreds of LSPs.
>

I guess that we can agree on the fact that centralized system provide  
more qualitative output in term of path
quality but are typically fairly slow and not appropriate for "real  
time" processing. Now of course, we could argue
for ever on:
* More qualitative: by how much ?
* What do we mean by path quality or optimality ?
* What does "slow" mean ?
We could certainly find scenarios where the delta in term of  
optimality is fairly negligible and centralized systems
are extremely slow, and vice versa.
So my point was to not "promote" such system for "real-time" processing.

>>>>     communication needs in support of a concurrent path  
>>>> computation application and to define protocol extensions to
>>>>     meet those needs.
>>>>
>>>> system and this is key. Indeed, one can define models where the  
>>>> PCCs are LSRs and the PCE is used to provide globally optimal
>>> (Application of PCE architecture) of the current draft clearly   
>>> spells out that GCO is NMS based solution.  With GCO, a PCC has
>> hence my comment. Could you restate in the abstract/Introduction  
>> that in your proposal the PCC is indeed an NMS.
>

This is an important point, on which we may not 100% agree. If now  
one want to use this model
where each LSR is a PCC so as to globally optimize the path  
computation of a set of TE LSPs,
that clearly requires very significant synchronizations between the  
PCE and each of those PCCs
(which is not the base with synchronized path computation request  
such as diverse path computations
originated by a single LSR). In other words, consider the case where  
a PCC requires to resize one of
its TE LSPs and sends a request to the PCE, which in turn triggers  
the reroute of hundreds of TE LSPs
to satisfy that demand. See the number of synchronizations that this  
does require between the PCE and
all PCCs. And there are many other scenarios where such model could  
have limitations that the draft
should point out.

Are we agreeing ?

>>>  OK.  The main use of GCO application is re-optimization of an   
>>> existing network.
>

So it is a green field for a very short period of time.

>>>>     optimization of such TE LSPs is unlikely to produce  
>>>> substantial improvements in overall network optimization

We keep facing that terminology issue with the word "distributed"  
where this could apply to the
algorithm itself or the fact that path computations may be performed  
by different engine (e.g. case
where each LSR is its own PCE). I was referring to the "unlikely to  
produce substantial ..." statement.
Techniques exist that produce good results with sequential re- 
optimization, thus my suggestion to
delete that statement, or please refine it.

>
>> Yes, it actually depends on the topology, the traffic matrix, the   
>> online algorithm used, etc. We will delete this statement.
>

See it is always difficult to avoid "significant", ... That really  
depends. For example, dynamic preemption
schemes based on LSP size can be designed to get close to the results  
given by a global
CSPF applied by placing TE LSPs in decreasing sizes, which itself can  
be fairly close to some centralized
algorithms.

> packet networks with micro-flow LSPs.

Yes unless you use dynamic preemption to avoid blocking issue. You  
could also use head-end
driven dynamic splitters to reduce that ratio.

>>> is traffic disruption vs. network impact. If we want to avoid  
>>> traffic disruption, we need this multiple rerouting, which is the
>> OK let me restate my comment here: the point I was trying to make  
>> is  the following: even if the set of TE LSPs can be reoptimized  
>> with no
>> cost in term of traffic impact (jitter, ...) + control plane  
>> stress.  It may be worth mentioning that aspect also, this is why  
>> I mentioned
>> a trade-off between optimization versus network impact. Indeed, if  
>> you can reoptimize the set of TE LSPs in order to reduce the max  
>> link  utilization by 5% but this requires to reroute two hundreds  
>> TE LSPs with on the average 4 reroutes per TE LSP, this may not be  
>> a good idea.
>

Ah I was referring to a reoptimization case (not failure): " if you  
can reoptimize the set of
TE LSPs in order to reduce the max link  utilization by 5% ..."

> and it is not.

That was my point indeed.

> As JP points out, even in packet networks where the re-
> at the point of switch-over.

+  potential control plane stress !

> This applies to *all* reoptimization and
>> I typed too fast: I indeed meant to refer to the objective  
>> function draft, as agreed with Jerry since I was pushing myself  
>> for not adding
>> more to PCEP.
>
> [SNIP]
>
> into the one objective function I-D?

Just the 6 ones defined in RFC4657, not all.

> Or should that I-D define the

In sync,

Cheers.

JP.