[Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-hpce-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-pce-stateful-hpce-13: Discuss

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-stateful-hpce/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I think this should be pretty easy to resolve, though I'm not sure what
the right way to do so it.

Section 3 says:

   [I-D.ietf-pce-hierarchy-extensions] defines the H-PCE Capability TLV
   that is used in the Open message to advertise the H-PCE capability.
   [RFC8231] defines the Stateful PCE Capability TLV used in the Open
   message to indicate stateful support.  The presence of both TLVs in
   an Open message indicates the support for stateful H-PCE operations
   as described in this document.

There is no normative reference relationship (in either direction)
between draft-ietf-pce-hierarchy-extension and this document; I think
that the use of the capability TLV to imply both sets of functionality
implies some sort of normative relationship; we wouldn't want version
skew between documents to induce breaking changes.  In particular, an
implementation that already supports RFC 8231 and is implementing the
hierarchy extensions would need to know to look at this document *and
implement it*, or would unknowingly be noncompliant with this document
and fail to interoperate with a peer that is compliant with this
document.


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

Abstract

                         This information may then be considered when
   computing new traffic engineered LSPs, and for associated and
   dependent LSPs, received from Path Computation Clients (PCCs). [...]

nit: I'm not sure how to parse this sentence.  The best thing I can come
up with is that "when computing new traffic engineered LSPs" and "for
associated [...]" are two separate cases, which each could independently
consider the information in question.  The first one makes sense, but
for the second I'm left trying to parse "this information may then be
considered for associated and dependent LSPs, received from PCCs", and
it's not really clear what considering the PCE is going to do if it just
sits there with information from the LSP-DB and information from PCCs (and
not doing anything with the information).

   The Hierarchical Path Computation Element (H-PCE) architecture,
   provides an architecture to allow the optimum sequence of
   [...]

nit: no comma here.

Also, three paragraphs may be pushing the bounds of an abstract in RFC
style.

Section 1.1

   path based on the domain connectivity information.  A Child PCE
   (C-PCE) may be responsible for a single domain or multiple domains,
   it is used to compute the intra-domain path based on its domain
   topology information.

nit: comma splice

   This document presents general considerations for stateful PCEs, and
   not Stateless PCEs, in the hierarchical PCE architecture.  In
   particular, the behavior changes and additions to the existing
   stateful PCE mechanisms (including PCE-initiated LSP setup and active
   PCE usage) in the context of networks using the H-PCE architecture.

nit: should "active PCE usage" read "active stateful PCE usage"?

Section 1.2

   The inter-domain LSP could be set up using the end-to-end signaling
   as described in [RFC6805]. Additionally a per-domain stitched LSP

Should I be reading this "could be set up using" as "this document
describes how to set [the LSP] up using"?

Section 1.2.2

   Different signaling methods for inter-domain RSVP-TE signaling are
   identified in [RFC4726].  Contiguous LSPs are achieved using the

nit: are the two "signaling"s redundant?

   In case of a stateful P-PCE, the stateful P-PCE has to be aware of
   the inter-domain LSPs for it to consider them during path
   computation. For example, a domain diverse path from another LSP.

nit: this last sentence is a sentence fragment.

   In this document, for the Contiguous LSP, the above interactions are
   only between the ingress domain C-PCE and the P-PCE. The use of
   stateful operations for an inter-domain LSP between the
   transit/egress domain C-PCEs towards the P-PCE is out of scope of
   this document.

nit: I suggest rewording to avoid the ambiguity of "towards" as applying
to the inter-domain LSP vs. the use of stateful operations.

Section 3

   in the topology).  The P-PCE has no information about the content of
   the child domains.  Each child domain has at least one PCE capable of

nit: we could potentially reword this in light of the remarks made about
ACTN previously.

   computing paths across the domain.  These PCEs are known as C-PCEs
   and have a direct relationship with the P-PCE.  The P-PCE builds the

It might be good to forward-reference where we talk about this
relationship in more detail.  (And, er, have more detail about the
relationship than we currently do.)

   and have a direct relationship with the P-PCE.  The P-PCE builds the
   domain topology map either via direct configuration (allowing network
   policy to also be applied) or from learned information received from
   each C-PCE.

Policy cannot be applied to information learned at runtime?

   LSP State Report (EC-EP):  a child stateful PCE sends an LSP state
      report to a Parent Stateful PCE whenever the state of a LSP
      changes.

With respect to "whenever the state of a LSP changes", is there a
possibility of a state-change that is visible to the C-PCE but does not
affect anything that the P-PCE knows about?  Is the state report still
expected to be generated in such cases?

   object to identify the Ingress (PCC). The PLSP-ID used in the
   forwarded PCRpt by the C-PCE to P-PCE is same as the original one
   used by the PCC.

I couldn't quickly find an authoritative definition of what the PLSP-ID
is; I see some discussion in RFC 8231 for the LSP Object, but am not
sure if there is prior usage.

Section 3.1

   paths.  Each C-PCE computes a set of candidate path segments across
   its domain and sends the results to the P-PCE. The P-PCE uses this
   information to select path segments and concatenate them to derive
   the optimal end-to-end inter-domain path.  The end-to-end path is
   then sent to the C-PCE that received the initial path request, and
   this C-PCE passes the path on to the PCC that issued the original
   request.

This is basically the same language as in RFC 6805, so I don't really
expect changing it to be the right thing to do, but I'm confused about
how the P-PCE is getting "candidate" segments from the C-PCEs but only
has to tell the head-end which path got picked.  Are the other C-PCEs
supposed to find out which of the candidates got used somehow?

Section 3.2

   a PCUpd message.  For LSP delegated to the P-PCE via the child PCE,
   the P-PCE can use the same PCUpd message to request change to the C-
   PCE (the Ingress domain PCE), the PCE further propagates the update
   request to the PCC.

nit: comma splice

Section 4

I expect this to not be the case, but just to check: is there a
possibility for differing levels of authorization for different PCCs,
e.g., where PCC A is allowed to request LSPs within the domain and to
any other domain, but PCC B is not allowed to request LSPs to/through a
subset of domain peers, and PCC C is only allowed to request LSPs within
the local domain?

As Roman mentions, we don't have a picture of what "full security" means
for child/parent communications.

   Thus it is RECOMMENDED to secure the PCEP session (between the P-PCE
   and the C-PCE) using either Transport Layer Security (TLS) [RFC8253]
   per the recommendations and best current practices in [RFC7525] or
   TCP Authentication Option (TCP-AO) [RFC5925].

It's not entirely clear to me that we need to call out TCP-AO here.
Partially since, as Stephen noted in the secdir review, it doesn't seem
to be implemented/deployed much, but also since RFC 8231 does call out
that it recommends TLS for confidentiality protection, which TCP-AO does
not provide.  There don't seem to be specific threats enumerated there
that the confidentiality protects against, so I am not making a strong
recommendation to remove TCP-AO from this text, but I'd like to better
understand why it was added.

   In case of TLS, due care needs to be taken while exposing the
   parameters of the X.509 certificate, such as subjectAltName:otherName
   which is set to Speaker Entity Identifier [RFC8232] as per [RFC8253],
   to ensure uniqueness and avoid any mismatch.

I'm not entirely sure which "mismatch" we would be concerned about.
And just to check: there aren't expected to be any privacy-like
considerations for exposing the speaker entity identifier to a peer in a
different domain, right?

Section 5.7

I'm not sure how appropriate it is to fully delegate (e.g.) propagation
of errors to draft-ietf-pce-enhanced-errors (which is not even a
normative reference!) -- it seems important to describe some expectation
of the error handling either in this document or in a normative
reference thereof.

Section 9.2

I think RFCs 5925, 7525, and 8253 should be normative, and RFC 7525 can
be cited as BCP 195.