Subject: RE : [Pce] WG feedback required on PCE Capability Discovery

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Thu, 28 Apr 2005 16:49:21 +0200

Hi Adrian

Thanks for this useful feedback

Please see inline for some comments

>-----Message d'origine-----
>De : Adrian Farrel [mailto:[email-masked]] 
>Envoyé : lundi 25 avril 2005 17:56
>À : LE ROUX Jean-Louis RD-CORE-LAN; [email-masked]
>Objet : Re: [Pce] WG feedback required on PCE Capability Discovery
>
>
>Hi JL,
>
>Well, it all depends on how much information, how many PCEs, 
>how many PCCs, and how often the information is re-distributed.
>
>If you use an IGP to achieve option 1 then you are requiring 
>that all routers in the network store the PCE capabilities 
>information so that they can flood it. So we must hope that 
>the product {number of PCEs}x{volume of capabilities 
>information} is not too large.

Fully agree

>
>If you are talking about a list of bit flags then option 1 is 
>probably cool. 

Yes actually most of PCE capabilities could be encoded in a simple list
of bit flags

>If the information is extensive you probably 
>need  option 3. If you don't yet know, I suggest you follow 
>option 1 with the knowledge that option 3 can be added. 

This sounds a good approach

>(Option 3 is not such a burden since it is a request/response 
>interaction and that is exactly what the PCE-PCC 
>communications protocol does best.)

Yes, but this may lead to multiple PCC-PCE crankbacks (ie a PCC may have to try various PCEs before to find the appropriate one)

>
>Note that the PCE-PCC comms draft currently says that items 
>like Policies must be advertised as part of the PCE 
>capabilities. These could be non-trivial and many in number.

Most of the policies (constraints, criterias...) can IMHO be encoded using flags...

>
>To pick you up on one point...
>
>> Note that this does not take into account discovery of PCE location, 
>> that can be done either statically or dynamically through 
>> functionality in the PCE discovery mechanism (here the PCE 
>> communication protocol cannot help).
>
>This is not true. You may wish to distinguish the two 
>functions and keep them in separate protocols, and this may be 
>a really good idea, but it is also possible to point at many 
>client/server protocols where the client discovers the servers 
>as part of the protocol operation.

Agree, there are protocols that include both location discovery and communication,
but strictly speaking if you start dissecting these protocols you often find two sub-protocols: A discovery sub-protocol and a communication sub-protocol with completely distinct functionalities...

Cheers,

JL

>
>Cheers,
>Adrian
>
>----- Original Message ----- 
>From: "LE ROUX Jean-Louis RD-CORE-LAN" 
><[email-masked]>
>To: <[email-masked]>
>Sent: Monday, April 18, 2005 10:02 AM
>Subject: [Pce] WG feedback required on PCE Capability Discovery
>
>
>Hi all,
>
>There has been several discussions within the PCE com Design 
>Team and among PCE discovery requirements co-authors, 
>regarding dynamic discovery of PCE capabilities.
>
>Once we agree that there is a need for dynamic PCE capability 
>discovery, then it appears that there are three options:
>
>Option 1: A single specific PCE discovery mechanism is used to 
>discover all PCE capabilities (as currently required in the 
>PCE discovery requirements I-D 
>http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-
>reqs-00.t
>xt).
>
>Option 2: All PCE capabilities are discovered through added 
>functionality in the PCE communication protocol 
>(http://www.ietf.org/internet-drafts/draft-ash-pce-comm-protoco
>l-gen-req
>s-00.txt).
>
>Option 3: Discovery of some generic PCE capabilities 
>(computation domain, scope...) is done by the PCE discovery 
>mechanism and discovery of detailed capabilities (e.g. type of 
>constraints supported...) relies on the PCE communication protocol.
>
>In 1) since PCC knows all PCE capabilities, it is the 
>reponsibility of the PCC to select the appropriate PCE for a 
>particular path computation. So, no capability-related request 
>parameters are needed in the communication protocol, since the 
>PCC alreay knows what is expected from the PCE.
>
>In 3) PCC knows certain basic capabilities, but for the 
>capabilities that it is unaware of, it may request specific 
>parameters in the communication protocol when a path 
>computation request is made to the PCE. If the PCE is not 
>capable of the requested paramters, then appropriate failure 
>is reported.
>
>Note that this does not take into account discovery of PCE 
>location, that can be done either statically or dynamically 
>through functionality in the PCE discovery mechanism (here the 
>PCE communication protocol cannot help). Note also that PCE 
>capabilities could of course be configured statically but this 
>is out of the scope of this discussion focused on dynamic 
>capability discovery.
>
>WG feedback on this topic would be highly desired.
>Please give us your comments and preferences regarding these 
>three options.
>
>JL
>
>
>
>
>
>
>---------------------------------------------------------------
>-----------
>------
>
>
>> _______________________________________________
>> 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: "Adrian Farrel" <[email-masked]>
Date: Fri, 29 Apr 2005 12:37:53 +0100

Hi JL,

Basic agreement.

Two small points.

>Yes, but this may lead to multiple PCC-PCE crankbacks (ie
> a PCC may have to try various PCEs before to find the
> appropriate one)

Yes and no.
Yes, the first time.
No subsequent times.
That is, we may assume that a PCC will retain the PCE capabilities
information regardless of how it is propagated. Certainly you wouldn't
suggest that a PCC that receieves this information through an IGP would
have a problem deciding whihc PCE to contact because it hasn't received an
update for 10 minutes!

>Most of the policies (constraints, criterias...) can IMHO be encoded

Well, OK.
But let's be really careful about the word Policy.
It has established meaning in other protocols and it sounds like this is
intended to be a different meaning.
An example of a Policy by my lights would be "PCCs from this domain are
not allowed to ask for paths of this type that cross that domain for this
priority traffic except on a Wednesday or when there is an R in the
month."

A

---

From: JP Vasseur <[email-masked]>
Date: Fri, 29 Apr 2005 12:16:51 -0400

Hi,

>> a PCC may have to try various PCEs before to find the

But ... the first time may lead to the impossibility to compute a path 
unless we extend signaling to support crankback. Furthermore, the cap 
may change ... and this may also lead to increase response time should 
the capability of the backup PCE be discovered upon reroute.

> priority traffic except on a Wednesday or when there is an R in the

Right.

In my opinion, unless the PCC cannot support dynamic discovery and/or 
the capability does require to exchange a large amount of information, 
it looks reasonable to rely on a single discovery mechanism.

Cheers,

JP.

---

From: Ina Minei <[email-masked]>
Date: Fri, 29 Apr 2005 10:50:17 -0700 (PDT)

JP, Adrian and all,

	It seems to me that the discussion on how the policies are
communicated is tightly coupled to what these policies are. From reading
section 6.2.3, the concept of policies was not clear to me. Following the
discussion on the list, I get the sense that different people have
different ideas what the policies should convey.

	I did notice that the draft states that "actual policies are out
of scope", but to be able to encode them, one must have a sense of what
they are.

	Can the authors expand on section 6.2.3 to shed some light on the
policies? In particular:
- what kind of functionality do the policies provide
- how dynamic they are (how often do they change)
- how fast must a policy change be propagated to the PCC
- what is the relationship between a policy and a capability
- should policies be advertised in the same way as capabilities are

			Thanks,

				Ina