Subject: RE: [Pce] Requirement for less-constrained path indraft-ietf-pce- comm-protocol-gen-reqs-00.txt

From: "Gray, Eric" <[email-masked]>
Date: Mon, 11 Jul 2005 15:04:01 -0400

JP,

	I assume from your reply that I understood correctly
what you are asking about, but let me check.  I believe you
are asking for one of two things: an information bearing NAK
used to narrow down the PCC choices for subsequent requests
or a menu-selection request followed by somewhat complicated 
PCE response handling.

	In the first case, the idea is to have the PCE return 
additional information about "less than requested" Path 
capabilities as opposed to simply returning a NAK for the 
unsatisfiable request.  In theory, this would reduce request-
response transactions if you make two or three assumptions:

	1)	The PCC will make subsequent requests for a Path
		that might also be unsatisfiable if its initial
		request fails, AND
	2)	The fail-back options are uniform through-out a 
		service and well understood prior to protocol 
		definition, implementation and deployment, 
		negotiable on a case-by-case basis within the 
		protocol, or both reasonably well understood in
		advance and negotiable in signaling;
	3)	It may also be necessary to assume that Path
		requests do not arrive from PCCs at a frequent
		enough rate to result in inconsistent behavior.

	If the fail-back approach is to request a Path with no
committed resources if initial requests fail for Paths with
committed resources, then subsequent requests will succeed (if
there is a route) and there would be no reduction in dialogue
with information about alternative Path availability - nor any 
particularly useful information to offer - in a NAK.  Therefore
we must assume that the second request would also require some
commitment of resources.

	If the PCC might wish to make a subsequent request, then 
the PCE needs to know what the sensitive parameters are and how
much tolerance there is in order to provide useful information 
in a NAK.  This would be complex.

	Finally, depending on the frequency with which the PCE is
bombarded with requests, it (the PCE) may be unable to satisfy
a second request as a result of resource commitments made after
the first response and before the second request.

	All that taken into account, I believe you are suggesting
the second alternative - requests with menu-selection options.
That is, "if you can't get me a Path that looks like this, then
I'll take one that looks like that; if you can't get me a path
that looks like that, ... then I'll take just any old path you 
can give me."

	I can well imagine that service providers may want this,
even given the complexity associated with defining a service 
around it, but that is not the only question we need to have 
answered. The other question is what are customers willing to 
give up to get it?

	There can be no question that this adds complexity to the
protocol. Is the PCE useless without it?  Is the PCE sufficiently
hampered without it that it's worth additional time to include it?
Is there no service provider out there that is interested in a 
less complex (and expensive) approach? 

	And - perhaps the most important question of all - is it 
necessary to include this capability in a first go round, or can 
we define extension and compatibility mechanisms that will allow 
us to include it in a subsequent iteration?

	These questions are among those that should be asked before 
we decide to accept this as a requirement...

--
Eric

--> -----Original Message-----
--> From: JP Vasseur [mailto:[email-masked]]
--> Sent: Monday, July 11, 2005 12:52 PM
--> To: Gray, Eric
--> Cc: 'Ash, Gerald R (Jerry), ALABS'; [email-masked]
--> Subject: Re: [Pce] Requirement for less-constrained path
--> indraft-ietf-pce- comm-protocol-gen-reqs-00.txt
--> 
--> 
--> Hi Eric,
--> 
--> On Jul 11, 2005, at 11:08 AM, Gray, Eric wrote:
--> 
--> > Jerry & JP,
--> >
--> >     I am not so sure that this should be a requirement.
--> >
--> >     Requiring the protocol to support finding alternate
--> > paths (by a near-arbitrary collections of fuzzy parameters)
--> >
--> 
--> Does not have to be arbitrary ;-) See the related section 
--> in the PCEP  
--> protocol ...
--> 
--> > is very likely to push both the process of coming up with
--> > any proposed solution that meets this requirement - and yet
--> > remains scalable - and the process of getting agreement for
--> > any such proposed solution.
--> 
--> Ah but this is the opposite goal: to increase the 
--> scalability. What  
--> would a PCC receiving a negative reply do unless resending 
--> additional  
--> path computation request(s) with different parameter(s) ? 
--> Thus having  
--> such capability would be quite useful but I'll let the Service  
--> Providers who will actually use that solution voice their 
--> opinion. In  
--> my previous email, I was just reflecting the outcome of some  
--> discussions that I had with several of them, thus asking 
--> whether such  
--> requirement had not be missed ?
--> 
--> JP.
--> 
--> >     I suggest that we might want to better understand the
--> > specific customer need - and what the customer is willing
--> > to sacrifice in other areas - before we include something
--> > like this as a requirement.
--> >
--> >     Short of getting that information, simply stating that
--> > this might be a preference - or a desirable goal - is about
--> > as strong as I would put it.
--> >
--> > --
--> > Eric
--> >
--> > --> -----Original Message-----
--> > --> From: [email-masked]
--> > --> [mailto:[email-masked]]On
--> > --> Behalf Of Ash, Gerald R (Jerry), ALABS
--> > --> Sent: Monday, July 11, 2005 7:27 AM
--> > --> To: JP Vasseur; [email-masked]
--> > --> Subject: RE: [Pce] Requirement for less-constrained path
--> > --> indraft-ietf-pce-comm-protocol-gen-reqs-00.txt
--> > -->
--> > -->
--> > --> Hi JP,
--> > -->
--> > --> > Quick question ... I do not see any requirement to get less-
--> > --> > constrained TE LSP path in
--> > --> > draft-ietf-pce-comm-protocol-gen-reqs-00.txt.
--> > --> > In most of the cases, when configuring a TE LSP 
--> with specific
--> > --> > attributes, one of the most challenging part consists of
--> > --> determining
--> > --> > the attributes values which will not result in the
--> > --> inability to find
--> > --> > a path in some circumstances (such as network element
--> > --> failures). The
--> > --> > typical case is the bandwidth. The first approach 
--> is to try to
--> > --> > compute the "closest" solutions. Another approach 
--> relies on the
--> > --> > configuration of multiple set of attributes:
--> > --> > 1) The preferred set of attributes
--> > --> > 2) One or more less-preferred set of attributes
--> > --> > 3) Un-constrained TE LSP
--> > --> >
--> > --> > When a PCE is used for TE LSP path computation, it looks
--> > --> to me that
--> > --> > it could be quite useful to be able to specify 
--> interest in less-
--> > --> > constrained path rather than potentially have to
--> > --> configure a set of
--> > --> > attributes (less optimal) which would result in several
--> > --> > rounds of PCC/
--> > --> > PCE communication.
--> > --> >
--> > --> > Isn't it a requirement that should be listed in
--> > --> draft-ietf-pce-comm-
--> > --> > protocol-gen-reqs-00.txt?
--> > -->
--> > --> Sounds OK to me.  It would help if you suggested some
--> > --> specific text to
--> > --> insert in the updated draft sent out last Thursday.
--> > -->
--> > --> Thanks,
--> > --> Jerry
--> > -->
--> > --> _______________________________________________
--> > --> Pce mailing list
--> > --> [email-masked]
--> > --> https://www1.ietf.org/mailman/listinfo/pce
--> > -->
--> >
--> 

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

---

From: JP Vasseur <[email-masked]>
Date: Mon, 11 Jul 2005 18:29:13 -0400

Hi Eric,

>         that might also be unsatisfiable if its initial

And this will likely to be the case ... There are of course various  
possible scenarios but consider the case of a PCE-based inter-area TE  
LSP path computation. What would you expect the PCC to do, should it  
receive a negative reply from the PCE ? Probably try to give up on  
some constraints so as to find a path and signal the TE LSP (you may  
also fall-back to IGP routing but give up on FRR in this case). Thus  
getting a less constrained path from the PCE could be of interested,  
effectively cutting down the communication protocol overhead and  
signalling delay. This is of course especially true if the PCC has to  
go through multiple rounds before getting a path.

>         advance and negotiable in signaling;

Quite realistic.

>         enough rate to result in inconsistent behavior.

I do not think so.

I'd like to stress the following fact: having such capability would  
actually drastically reduce the communication overhead compared to  
the co-located PCE scenario in case of path computation failure.

> particularly useful information to offer - in a NAK.

No, this is not correct. You may still want to know the shortest  
unconstrained path (consider the case of inter-domain for example).  
Furthermore, you do not need to go from "fully satisfied" to "No  
committed resources". If the PCC wants to get the shortest path for a  
TE LSP of X Mbits/s. Don't you think that it would be valuable to  
know the shortest path with the closest bandwidth value to the  
initial request (X) ?

>   Therefore

See above.

> in a NAK.  This would be complex.

You can either provide a boolean behavior to start with (Full  
satisfied to Unconstrained -> Still valuable) or provide the ability  
for the PCC to specify a hierarchical constraints relaxation policy.  
You usually do not have that many constraints, and SP do know their  
order of preference in term of constraints relaxation.

> the first response and before the second request.

It really depends of your PCE implementation. You can reduce that  
probability.

> around it,

Note that there are many such deployments already.

> but that is not the only question we need to have

This is a completely different question. In any case, if you do not  
have a path satisfying your constraints, you have to give up on  
something but this has nothing to do with the PCE-based path  
computation.

> us to include it in a subsequent iteration?

The discussion on protocol overhead, complexity and so on should  
follow once we discuss communication protocol. My question was  
related to the requirement for such capability ?

> we decide to accept this as a requirement...

Again, note that I did not ask to add this as a requirement. Just a  
question to the WG on whether this was a requirement.

JP.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 14 Jul 2005 17:26:06 +0100

I want to pitch in on this thread because I think i see where both JP and
Eric are coming from. JP's proposals have the potential to significantly
reduce the PCE processing and cut down number of PCC-PCE transactions, but
they also have the ability to massively increase the processing and the
size of the PCC-PCE transactions.

Thus we need to be quite careful in the specification of the protocol
requirements and the protocol itself. It is not OK for us to say that if
an individual PCC is irresponsible or stupid that is its problem, because
such an implementation would break the accessibility to the PCE for other
'normal' PCCs.

Unless there are "standard" constraint back-off functions it is hard to
conceive of a PCE guessing the correct back-off for the PCC that issued
the request. Note that the more "speculative paths" the PCE computes the
more CPU it uses. So we must keep good control on this. It is a
computational myth that it is possible to relax different constraints on a
single computational pass. In fact, the question "where did my computation
fail" is notoriously impossible to answer except with the response "in the
network".

Thus we should give full control to the PCC, and let the PCE choose to
supply less information if it thinks that the PCC is asking too much. This
control includes:

a. The ability to say "this or nothing"
b. The ability to say "tell me what constraints I might relax to get a
path"
c. The ability to say "give me n alternate paths with your choice of
relaxed constraints"
  (c. is like b but with the paths supplied, and it is important to
control the number)
d. A way to state which constraints may be relaxed absolutely (this is
easy)
e. A way to replace one constraint supplied by the PCC with another also
  supplied by the PCC
f. A way to specify an ordering for relaxation in recomputation attempts.

My feeling is that e might be satisfied in the protocol simply by listing
the same object multiple times. But f is very messy. As soon as I have a
few constraints and I am willing to relax each of them by degrees I have a
very complex relaxation problem to express.

This is a problem that it is very easy for the PCC to handle by issuing
successive requests, but very hard for the PCC to communicate to the PCE
in a single request.

So, I'd like to see some text from SPs on this subject before we add
anything to the requirements I-D.

Cheers,
Adrian

----- Original Message ----- 
From: "JP Vasseur" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, July 11, 2005 11:29 PM
Subject: Re: [Pce] Requirement for less-constrained path
indraft-ietf-pce-comm-protocol-gen-reqs-00.txt

---

From: JP Vasseur <[email-masked]>
Date: Thu, 14 Jul 2005 21:18:47 -0400

> size of the PCC-PCE transactions.

that said, it it pretty straightforward to see that the benefits  
undoubtedly outweigh the drawbacks. The request processing is  
definitely negligible compared to the communication overhead.  
Actually, it could be shown that the non support of such capability  
would have a drastic scalability impact on the solution especially  
upon resource contention.

> such an implementation would break the accessibility to the PCE for  

On this aspect, I do agree !

> more CPU it uses.

Speculative paths is definitely not an option considering the number  
of permutations ... we would unavoidably quickly fall into some NP- 
Complete issues ;-) ... This is why the suggestion is made to start  
some discussion on the hierarchical relaxation policy. Note that it  
does not have to be awfully complex ...

> So we must keep good control on this. It is a
> single computational pass.

Ah no ... there are several constraints for which constraint can be  
relaxed and closest match can be found in on-go.

That said, even if it were not the case, the solution would still be  
valuable to cut-down the communication overhead and amount of  
processing signaling be the PCE's scheduler.

> In fact, the question "where did my computation

Well not so sure ... Let's wait for the meeting in Paris to have an  
open discussion. I'd be happy to provide some ideas. Actually, one  
could point out that such constraint relaxation are used TODAY in  
operational networks (with CSPF).

> successive requests, but very hard for the PCC to communicate to  

I do not think that it is hard for the PCC to communicate to the PCE  
in a single request.

> anything to the requirements I-D.

I think that the DT is working on it.

Cheers,

JP.