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

[Dhruv Dhody <[e-mail]>]

Hi Jon,

Thank you fixing the grammatical issues with the document.
One change I would like to make is to the term "Fractional Percentage Link Loss" to just  "Fractional Link Loss".

I have attached a diff of the recent changes only.

See inline...


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

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]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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"?
[Dhruv2] I am worried that might be seen as excluding the bandwidth utilization related optimization criteria. I wanted to use a generic term and thus  "network performance information".

<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.
[Dhruv2] You are right, and I think we should have error for both the cases. I have done that now ->

   If the PCE understands but does not support the new METRIC type, and
   the P bit is set in the METRIC object header, then the PCE MUST send
   a PCErr message containing a PCEP-ERROR Object with Error-Type = 4
   (Not supported object) with Error-value = TBD11 (Unsupported network
   performance constraint).  The path computation request MUST then be
   cancelled.

   If the PCE understands the new METRIC type, but the local policy has
   been configured on the PCE to not allow network performance
   constraint, and the P bit is set in the METRIC object header, then
   the PCE MUST send a PCErr message containing a PCEP-ERROR Object with
   Error-Type = 5 (Policy violation) with Error-value = TBD12 (Not
   allowed network performance constraint).  The path computation
   request MUST then be cancelled.

<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?
[Dhruv2]  Done!
<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?
[Dhruv2] Yes, and I have reworded this.

The new metric types for
path delay and path delay variation can continue to use the existing
objective function - Minimum Cost Path (MCP) [RFC5541].  For path
  loss, the following new OF is defined.

<snip>
<snip>

[JEH] I think you need to define the term TED in your glossary.
[Dhruv2] Done.

<snip>

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

Thanks again!!

Regards,
Dhruv