Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering
draft-ietf-pce-inter-area-as-applicability-08

[Ballot 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.

[Ballot comment]
(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 …”?

[Ballot comment]
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.

[Ballot comment]
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.

== COMMENTS ==

-- 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 --

s/Antonymous/Autonomous/

-- 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.

[Ballot comment]
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.

[Ballot comment]
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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-pce-inter-area-as-applicability-07, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-05-30):

From: The IESG
To: IETF-Announce
CC: db3546@att.com, Jonathan Hardwick , pce@ietf.org, pce-chairs@ietf.org, jonathan.hardwick@metaswitch.com, draft-ietf-pce-inter-area-as-applicability@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Applicability of the Path Computation Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic Engineering) to Informational RFC


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'Applicability of the Path Computation
Element to Inter-Area and Inter-
  AS MPLS and GMPLS Traffic Engineering'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-05-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The Path Computation Element (PCE) may be used for computing services
  that traverse multi-area and multi-AS Multiprotocol Label Switching
  (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks.

  This document examines the applicability of the PCE architecture,
  protocols, and protocol extensions for computing multi-area and
  multi-AS paths in MPLS and GMPLS networks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-inter-area-as-applicability/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pce-inter-area-as-applicability/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the proper
    type of RFC? Is this type of RFC indicated in the title page header?

Informational. This is proper as the document is an applicability statement.
Yes, it is in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
    Please provide such a Document Announcement Write-Up. Recent examples can
    be found in the "Action" announcements for approved documents. The approval
    announcement contains the following sections:

Technical Summary:

    This document discusses the applicability of the PCE architecture to
    various inter-domain use cases.

Working Group Summary:

    The document's progress through the working group was smooth.

Document Quality:

    The document is an applicability statement; there are several
    implementations of the PCE features that it discusses.

Personnel:

    Jon Hardwick is the document shepherd.
    Deborah Brungard is the responsible AD.

(3) Briefly describe the review of this document that was performed by the
    Document Shepherd. If this version of the document is not ready for
    publication, please explain why the document is being forwarded to the
    IESG.

    I reviewed the document twice.  Once in 2017, and once again recently.
    My first review found a large number of issues with clarity and document
    structure.  These had all been addressed to my satisfaction by the time of
    my second review.

(4) Does the document Shepherd have any concerns about the depth or breadth of
    the reviews that have been performed?

    Apart from myself, I do not remember seeing any other reviews of this
    document on the PCE mailing list, although as the document has been around
    for a very long time, there may have been reviews in its early days that I
    did not see.  Despite this, whenever the PCE working group was asked, the
    WG found this document to cover an important subject and supported its
    publication as RFC.

(5) Do portions of the document need review from a particular or from broader
    perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML,
    or internationalization? If so, describe the review that took place.

    No applicable.

(6) Describe any specific concerns or issues that the Document Shepherd has
    with this document that the Responsible Area Director and/or the IESG
    should be aware of? For example, perhaps he or she is uncomfortable with
    certain parts of the document, or has concerns whether there really is a
    need for it. In any event, if the WG has discussed those issues and has
    indicated that it still wishes to advance the document, detail those
    concerns here.

    I am comfortable with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures
    required for full conformance with the provisions of BCP 78 and BCP 79 have
    already been filed. If not, explain why?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If so,
    summarize any WG discussion and conclusion regarding the IPR disclosures.

    No.

(9) How solid is the WG consensus behind this document? Does it represent the
    strong concurrence of a few individuals, with others being silent, or does
    the WG as a whole understand and agree with it?

    Although the WGLC for this document provoked few replies, there was nobody
    who disagreed with its publication.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

    No.

(11) Identify any ID nits the Document Shepherd has found in this document.
    (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
    Boilerplate checks are not enough; this check needs to be thorough.

    There are a couple of nits due to the fact that the document was last
    updated in 2018.  These should disappear next time the document is
    refreshed.

(12) Describe how the document meets any required formal review criteria, such
    as the MIB Doctor, media type, and URI type reviews.

    Not applicable.

(13) Have all references within this document been identified as either
    normative or informative?

    Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state?

    No.

(15) Are there downward normative references references (see RFC 3967)?

    No.

(16) Will publication of this document change the status of any existing RFCs?

    No.

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of the
    document. Confirm that all protocol extensions that the document makes are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that newly created IANA registries include a detailed specification of the
    initial contents for the registry, that allocations procedures for future
    registrations are defined, and a reasonable name for the new registry has
    been suggested (see RFC 5226).

    The document makes no request of IANA.

(18) List any new IANA registries that require Expert Review for future
    allocations.

    Not applicable.

(19) Describe reviews and automated checks performed by the Document Shepherd
    to validate sections of the document written in a formal language, such as
    XML code, BNF rules, MIB definitions, etc.

    Not applicable.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the proper
    type of RFC? Is this type of RFC indicated in the title page header?

Informational. This is proper as the document is an applicability statement.
Yes, it is in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
    Please provide such a Document Announcement Write-Up. Recent examples can
    be found in the "Action" announcements for approved documents. The approval
    announcement contains the following sections:

Technical Summary:

    This document discusses the applicability of the PCE architecture to
    various inter-domain use cases.

Working Group Summary:

    The document's progress through the working group was smooth.

Document Quality:

    The document is an applicability statement; there are several
    implementations of the PCE features that it discusses.

Personnel:

    Jon Hardwick is the document shepherd.
    Deborah Brungard is the responsible AD.

(3) Briefly describe the review of this document that was performed by the
    Document Shepherd. If this version of the document is not ready for
    publication, please explain why the document is being forwarded to the
    IESG.

    I reviewed the document twice.  Once in 2017, and once again recently.
    My first review found a large number of issues with clarity and document
    structure.  These had all been addressed to my satisfaction by the time of
    my second review.

(4) Does the document Shepherd have any concerns about the depth or breadth of
    the reviews that have been performed?

    Apart from myself, I do not remember seeing any other reviews of this
    document on the PCE mailing list, although as the document has been around
    for a very long time, there may have been reviews in its early days that I
    did not see.  Despite this, whenever the PCE working group was asked, the
    WG found this document to cover an important subject and supported its
    publication as RFC.

(5) Do portions of the document need review from a particular or from broader
    perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML,
    or internationalization? If so, describe the review that took place.

    No applicable.

(6) Describe any specific concerns or issues that the Document Shepherd has
    with this document that the Responsible Area Director and/or the IESG
    should be aware of? For example, perhaps he or she is uncomfortable with
    certain parts of the document, or has concerns whether there really is a
    need for it. In any event, if the WG has discussed those issues and has
    indicated that it still wishes to advance the document, detail those
    concerns here.

    I am comfortable with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures
    required for full conformance with the provisions of BCP 78 and BCP 79 have
    already been filed. If not, explain why?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If so,
    summarize any WG discussion and conclusion regarding the IPR disclosures.

    No.

(9) How solid is the WG consensus behind this document? Does it represent the
    strong concurrence of a few individuals, with others being silent, or does
    the WG as a whole understand and agree with it?

    Although the WGLC for this document provoked few replies, there was nobody
    who disagreed with its publication.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

    No.

(11) Identify any ID nits the Document Shepherd has found in this document.
    (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
    Boilerplate checks are not enough; this check needs to be thorough.

    There are a couple of nits due to the fact that the document was last
    updated in 2018.  These should disappear next time the document is
    refreshed.

(12) Describe how the document meets any required formal review criteria, such
    as the MIB Doctor, media type, and URI type reviews.

    Not applicable.

(13) Have all references within this document been identified as either
    normative or informative?

    Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state?

    No.

(15) Are there downward normative references references (see RFC 3967)?

    No.

(16) Will publication of this document change the status of any existing RFCs?

    No.

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of the
    document. Confirm that all protocol extensions that the document makes are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that newly created IANA registries include a detailed specification of the
    initial contents for the registry, that allocations procedures for future
    registrations are defined, and a reasonable name for the new registry has
    been suggested (see RFC 5226).

    The document makes no request of IANA.

(18) List any new IANA registries that require Expert Review for future
    allocations.

    Not applicable.

(19) Describe reviews and automated checks performed by the Document Shepherd
    to validate sections of the document written in a formal language, such as
    XML code, BNF rules, MIB definitions, etc.

    Not applicable.

Request for posting confirmation emailed to previous authors: Oscar de Dios , Dhruv Dhody , Quintin Zhao , Olivier Dugeon , Daniel King , pce-chairs@ietf.org, Julien Meuric