Skip to main content

Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering


(Deborah Brungard)

No Objection

(Barry Leiba)
(Ignas Bagdonas)
(Magnus Westerlund)


Note: This ballot was opened for revision 07 and is now closed.

Roman Danyliw
No Objection
Comment (2019-06-13 for -07) Sent
(1) I share Mirja’s concerns about the lack of review per the shepherd write-up .

(2) Section 5.  Per “The method may require several crankback …”, perhaps a reference to RFC4920 might be appropriate.

(3) Section 5.1.3.  What does “protection” mean in the context of “It may be necessary (for protection …) to computer a path that is partially or entirely diverse …”?
Éric Vyncke
No Objection
Comment (2019-06-12 for -07) Sent
Thank you all for the work put into this document. Beside the apparent lack of interest and review in the WG, I liked this document with its educational purpose.

A couple of nits below and one comment.


-- Section 3 --

3 issues are identified (multi-homing, domain confidentiality, destination location) and I can only identify one analyzed in details (in section 8) while the others are not. Is it on purpose? Or is they are, may I suggest to add references to the relevant sections in this section 3 ?

== NITS ==

-- Section 1.1 --


-- Section 1.2 --

Unsure how to parse "When a path has required the Path Computation Client (PCC) will send a request to the PCE", there seems that a comma or semi-colon is missing.
Deborah Brungard Former IESG member
Yes (for -07) Unknown

Alvaro Retana Former IESG member
No Objection
No Objection (2019-06-11 for -07) Sent
I agree with Mirja in that the information in this document can probably already be found in other documents...  I am balloting No Objection because that may be enough to provide some value.

There are no Normative References.  I believe that many of the references are required to be read to understand what this document talks about, and should be Normative.
Barry Leiba Former IESG member
No Objection
No Objection (for -07) Not sent

Benjamin Kaduk Former IESG member
No Objection
No Objection (2019-06-13 for -07) Not sent
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

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

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

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.
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -07) Not sent

Magnus Westerlund Former IESG member
No Objection
No Objection (for -07) Not sent

Suresh Krishnan Former IESG member
No Objection
No Objection (2019-06-13 for -07) Sent
I agree with Alvaro that lot of the references are really normative rather than informative. I also share Mirja's concerns about lack of review.
Mirja Kühlewind Former IESG member
Abstain (2019-06-05 for -07) Sent
I only had a quick read of this document, however, the actual value of archiving this document in the RFC series is not clear to me. This document rather seems to a be high-level summary of various other RFCs than an applicability statement.

Also the shepherd write-up indicates that there was very little review of this document which seems also concerning.