Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-inter-area-as-applicability-07: (with COMMENT)

[<[e-mail]>]

Thank you Benjamin for the detailed review. We have addressed all the NITs, a few further clarifications/thoughts on the other points you raised:

>> Section 1.5
>> RFCs 5088 and 5089 are for OSPV and IS-IS discovery mechanisms.  Aren't those inherently (in some sense) limited to a single IGP area, making it difficult to discover PCEs located in other ASes?

We modified the text to underline the single domain applicability for PCE capability discovery via IGP extensions. 

>> Section 4.2
>> Are there references available for the numbers claimed in this section? (They seem reasonable to me, but for archival purposes it can be helpful.)

I hunted high and low to find my original quote (via email), for domain sizing in Section 4.2., I failed. I remember the assertion was made by one of our operator conversations. We updated Section 4.2 text to read:

"Network operator feedback in the development of the document highlighted that node degree (the number of neighbors per node) typically ranges from 3 to 10 (4-5 is quite common). 

BR, Dan. 

-----Original Message-----
From: Benjamin Kaduk via Datatracker <[e-mail]> 
Sent: 13 June 2019 10:33
To: The IESG <[e-mail]>
Cc: [e-mail]; Jonathan Hardwick <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Benjamin Kaduk's No Objection on draft-ietf-pce-inter-area-as-applicability-07: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-pce-inter-area-as-applicability-07: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-inter-area-as-applicability/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This document claims to be an "applicability statement" but is being published as Informational.  Is the divergence from an RFC 2026 Applicability Statement intentional?

I share other AD's concerns about the lack of review indicated in the shepherd writeup, though to some extent the content seems obviously true.

Section 1

                                                                      A
   number of issues exist for routing in multi-domain networks, these
   include:

nit: this is a comma splice.

Section 1.1

Perhaps the first two paragraphs could indicate that the first paragraph is considering general usage, outside of this document, while the second paragraph restricts to just the current usage in this document.

Section 1.2

   architecture defined in [RFC4655]. When a path has required the Path
   Computation Client (PCC) will send a request to the PCE. The PCE

nit: "is required" (or "has been requested", I suppose)

Section 1.5

RFCs 5088 and 5089 are for OSPV and IS-IS discovery mechanisms.  Aren't those inherently (in some sense) limited to a single IGP area, making it difficult to discover PCEs located in other ASes?

Section 4.2

Are there references available for the numbers claimed in this section?
(They seem reasonable to me, but for archival purposes it can be
helpful.)

Section 4.5

   An operator may also need to avoid a path that uses specified nodes
   for administrative reasons, or if a specific connectivity
   service required to have a 1+1 protection capability, two
   completely disjoint paths must be established, Shared Risk Link
   Group (SRLG) information may be provided to ensure path diversity.

I think maybe the last comma is a comma splice?  The distribution of SRLG information does seem to be somewhat different from the requirements for various types of paths, at least.

Section 5.1.2

nit: "zero, one or more" seems equivalent to "zero or more"

Section 7.2

Please expand OSS.

Section 13

   PCEP security is defined [RFC5440].  [...]

(nit?) It seems that 5440 just says "use IPsec (or TCP-MD5), which is not exactly in-protocol "PCEP security" per se.

As the secdir reviewer notes, some additional guidance on what to do when crossing administrative boundaries is probably in order.