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

From: Vivek Dubey-G20041 <[email-masked]>
Date: Wed, 20 Apr 2005 19:02:32 +0530

Option 1
--------
In case of single PCE discovery mechanism, all PCE capabilities (at that instant), are advertised. These are taken
into consideration by PCC, while selecting a particular PCE(out of many available) for a particular path computation request.

In case of change in PCE capability, incremental updates can happen.

Option 3
--------
Assuming base PCE capabilities are advertised during discovery.
For path computation request it is required by PCC to request all available PCEs for there "specific required" capabilities, than select one out of them and finally make a request.

Further "change" in PCE capability wont be available unless PCC makes a path computation request. So before making
any path request, PCC must get the last updated PCE capability. 

Considering above points "Option 1" is better choice.

Thanks
Vivek

LE ROUX Jean-Louis RD-CORE-LAN wrote:

> 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-protocol-gen-r
> eq
> 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

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

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Sat, 30 Apr 2005 14:11:09 -0500

Hi Ina,

> 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

The authors of
http://www.ietf.org/internet-drafts/draft-ash-pce-comm-protocol-gen-reqs
-00.txt have had much recent discussion about the requirements in
Section 6.2.3.  We agree that much of the second part of the discussion
RE 'encoding policies, etc.' should be removed.  The revised text is as
follows:

"6.2.3 Policy Support

   The communication protocol MUST allow for policies to accept/reject
   requests, and include the ability for a PCE to reject requests with
   sufficient detail to allow the PCC to determine the reason for
   rejection or failure.  For example, filtering could be required for
   intra-AS PCE path computation such that all requests are rejected
   that come from another AS.  However, specific policy details
   are left to application-specific communication protocol requirements.
   Furthermore, the communication protocol MUST allow for the
   notification of a policy violation.  Actual policies, configuration
   of policies, and applicability of policies are out of scope."

The -01 revision of the draft will be issued shortly.

Thanks,
Jerry