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 11:08:15 -0400

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

	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 12:51:43 -0400

Hi Eric,

> paths (by a near-arbitrary collections of fuzzy parameters)

Does not have to be arbitrary ;-) See the related section in the PCEP  
protocol ...

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