Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-service-aware-09

[Jonathan Hardwick <[e-mail]>]

Hi Dhruv

Thanks for responding so quickly.  I have inserted my replies below.

As promised, I have also attached my "language" mark-ups, where I decided to directly edit the XML file that you sent to me.  Please check that you are happy with these.  Most are simple things (inserting definite and indefinite articles was a very common one!) but in some cases I felt that a rewording for clarity was necessary.  All of my direct changes to the XML are editorial in nature i.e. do not affect the protocol.

Best regards
Jon


From: Dhruv Dhody [mailto:[e-mail]]
Sent: 23 June 2016 08:01
To: Jonathan Hardwick <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: Shepherd's review of draft-ietf-pce-pcep-service-aware-09

Hi Jon,

Thanks for being the shepherd and providing valuable comments.
I have attached the working copy of the document with diff.
See inline..


From: Pce [mailto:[e-mail]] On Behalf Of Jonathan Hardwick
Sent: 22 June 2016 22:10
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [Pce] Shepherd's review of draft-ietf-pce-pcep-service-aware-09

<snip>

How is (3) in this list different from (2)?
[Dhruv] We were trying to differentiate between constraints that are applied to E2E path (cumulative) - (2) and one that are applied to each link on the path - (3)

I think we can remove all these details from this section and simply state -

(2) A PCC must be able to specify any network performance constraint
    in a PCReq message to be applied during the path computation.

(3) A PCC must be able to specify any network performance information
    as an optimization criteria.

Remove (4)

What do you think?
[JEH] I think fine.  Although rather than "network performance information" could we have "network performance metrics"?

<snip>

4.1.4 You also need to give the Error-Value codes for the PCEP-ERROR message in both cases.
[Dhruv] fixed
[JEH] Thanks, but I have another concern: is "error-type 5 (policy violation)" appropriate for "not capable of service aware path computation"?  I would have thought error-type 4 (not supported object) would fit better.  I think "policy violation" is for cases where a service has been denied to a client for reasons of operator policy, not because of an implementation limitation.
[JEH] The same comment applies to 4.2.3.1.

<snip>

4.2.3 Why is a new object needed for unreserved bandwidth?  Isn't this just another type of METRIC?  E.g. "optimize unreserved bandwidth (using the given objective function)" or "use this value as the lower bound of the unreserved bandwidth" depending on the setting of the B bit.
[Dhruv] METRIC in its current usage and description fits to the cost associated with the E2E path (cumulative cost), whereas with Bandwidth Utilization (similar to BANDWIDTH object) is applied to each link on the path. Based on this we concluded to not use METRIC object.
[JEH] OK, I understand this now.
[JEH] New comment (sorry).  In this section you have some inconsistent capitalization of terms (Residual bandwidth, / Residual Bandwidth / Available bandwidth / Available Bandwidth / Maximum reservable bandwidth).  I suppose this is true in the rest of the document too (but I haven't checked).  Please could you standardize on a convention?

<snip>

[JEH] New comment on section 4.3.  It says:

"The new metric types specified
   in this document MAY continue to use the existing objective functions
   like Minimum Cost Path (MCP).  Path Delay and Path Delay Variation
   are well suited to use MCP as an optimization criteria.  For Path
   Loss following new OF is defined"

I can't reconcile the first sentence with the other two.  The first sentence implies that all current objective functions (including MCP) apply to all metric types in your draft.  The third sentence says that MCP is no good for the Path Loss metric and a new OF is needed instead.  I think you want to say that the MCP OF is applicable to the Path Delay and Path Delay Variation metrics, and that a new OF is needed for the Path Loss metric.  Is that right?

<snip>
Section 7 "Other Considerations"
Section 7.2 - I think this section should be expanded to explain the process.

"PCC can monitor the setup LSPs" - how does it monitor them?

"In case of drastic change" - the word "drastic" is open to interpretation.  Instead "If the bandwidth utilization percentage of any of the links in the path changes to a value less than that required when the path was set up, or otherwise less than an implementation-specific threshold, then..."

What about a stateful PCE proactively reoptimizing paths?  This should also be discussed.
[Dhruv] changed section to -
7.2.  Reoptimization Consideration

   [RFC6374] supports measurement of loss, delay, and related metrics
   over Label Switched Paths (LSPs).  PCC can utilize such measurement
   technique and in case of degradation of network performance
   parameters below the constraint when the path was setup or an
   implementation-specific threshold, it MAY ask PCE for reoptimization
   with R bit set in RP object as per [RFC5440].

   Based on the changes in the network performance parameters of the
   link in TED (as populated by IGP), PCC can identify the impacted LSP
   and MAY also issue a reoptimization request.  For example, PCC can
   monitor the link bandwidth utilization along the path by monitoring
   changes in the bandwidth utilization parameters of one or more links
   on the path in the TED.  If the bandwidth utilization percentage of
   any of the links in the path changes to a value less than that
   required when the path was set up, or otherwise less than an
   implementation-specific threshold, then issue an reoptimization
   request to a PCE.

   A stateful PCE can also determine which LSP should be re-optimized
   based on network events or trigger from external monitoring systems.
   For example, when a particular link deteriorates and its loss
   increases, this can trigger the stateful PCE to automatically
   determine which LSP are impacted and should be reoptimized.

[JEH] I think this is good to say, although I have suggested some minor rewording for clarity in the attachment.
[JEH] I think you need to define the term TED in your glossary.

<snip>

[JEH] I think the title of section 8.5 should be "New Error-Values".