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

[Benjamin Kaduk <[e-mail]>]

Hi Dhruv,

On Tue, Sep 24, 2019 at 07:36:43PM +0530, Dhruv Dhody wrote:
> Hi Ben,
> 
> Thanks for your review.
> 
> On Thu, Sep 19, 2019 at 3:39 AM Benjamin Kaduk via Datatracker
> <[e-mail]> wrote:
> >
> > 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.
> >
> 
> How about we add normative text for this -
> 
>    [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. To indicates the support for
>    stateful H-PCE operations described in this document, a PCEP speaker
>    MUST include both TLVs in an Open message. It is RECOMMENDED that any
>    implementation that supports stateful operations [RFC8231] and H-PCE
>    [I-D.ietf-pce-hierarchy-extensions] would also implements the
>    stateful H-PCE operations as described in this document.
> 
> This would be true in most deployments/implementations of C-PCE and
> P-PCE that are also stateful!

This does remove the problematic normative requirement on implementations
of other documents, but I'm not sure if it does what's needed for the
interactions across documents.  Specifically, what will happen if two peers
both support/advertise stateful PCE and H-PCE but only one implements
stateful HPCE?  Will there be a clean error handling at runtime and
degredation to one or the other, or will there be messy errors?  If the
latter, then I don't think we can just have a RECOMMENDED relationship.

> >
> > ----------------------------------------------------------------------
> > 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).
> >
> 
> Suggested update -
> 
>    A Stateful Path Computation Element (PCE) maintains information on
>    the current network state received from the Path Computation Clients
>    (PCCs), including: computed Label Switched Path (LSPs), reserved
>    resources within the network, and pending path computation requests.
>    This information may then be considered when computing path for a new
>    traffic-engineered LSP or for any associated/dependent LSPs. The Path
>    computation response from a PCE is helpful for the PCC to gracefully
>    establish the computed LSP.

Looks better, thanks (nit: add "the" for "when computing the path for a new")

> 
> >    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"?
> >
> 
> Updated to -
> 
>    The end-to-end inter-domain path computation and setup is described
>    in [RFC6805].
> 
> > 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.
> 
> Updated based on Barry's suggested text -
> 
>    A stateful P-PCE has to be aware of the inter-domain LSPs for it to
>    consider them during path computation. For instance when a domain
>    diverse path is required from another LSP, the P-PCE needs to be
>    aware of the LSP.
> 
> >
> >    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.
> >
> 
> Changed to "and".
> 
> > 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.)
> >
> 
> This text is focused on what is described in RFC 6805, so added
> reference to that.
> 
> >    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?
> >
> 
> Updated
> 
> >    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?
> >
> 
> Yes / No
> Updated text.
> 
> >    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.
> >
> 
> It is RFC 8231, added - PLSP-ID (PCEP-specific identifier for the LSP,
> as per [RFC8231])
> 
> > 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?
> >
> 
> The request to other C-PCEs is "stateless" in nature and thus once
> they have computed path segments and provided the result to the P-PCE
> they loose the state and dont care which candidate was picked.

Ah, right, we did say that we are only stateful to the head-end C-PCE;
thanks for reminding me.

> > 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?
> >
> 
> Yes, we do not have different levels of authorization.
> 
> > As Roman mentions, we don't have a picture of what "full security" means
> > for child/parent communications.
> >
> 
> How about we update to "..full security (i.e. the highest security
> mechanism available for PCEP)"?

I'm not sure that we have defined an absolute ordering on PCEP security
mechanisms ... right now, I think this would mean TLS but we may not need
to prevent any future developments in the area.  I guess the right thing to
do here depends on how likely of a need there is for confidentiality
protection (and, relatedly, how widely implemented/deployed PCEPS is).

> >
> >    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.
> >
> 
> We decided to keep TCP-AO as it is still a good security feature even
> though not implemented. At the same time it could be use alongside
> TLS. The updated text as per Roman's comment -
> 
>    Thus it is RECOMMENDED to secure the PCEP session (between the P-PCE
>    and the C-PCE) using Transport Layer Security (TLS) [RFC8446] (per
>    the recommendations and best current practices in [RFC7525]) and/or
>    TCP Authentication Option (TCP-AO) [RFC5925]. The guidance for
>    implementing PCEP with TLS can be found in [RFC8253].
> 
> >    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.
> 
> We added this based on Stephen's comment to make sure that there is no
> issue of conflict because of peer identification parameters exposed
> via certificates. Maybe two peers using the same Speaker Entity
> Identifier in the certificate. I think the TLS establishment would
> fail but the advise still stands.
> 
> > 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?
> >
> 
> Yes, IMHO this is fine.
> 
> > 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.
> >
> 
> Updated to -
> 
>    Apart from the basic error handling described in this document, an
>    implementation could also use the enhanced error and notification
>    mechanism for stateful H-PCE operations as per [I-D.ietf-pce-
>    enhanced-errors]. Enhanced features such as error behavior
>    propagation, notification and error criticality level, are further
>    defined in [I-D.ietf-pce-enhanced-errors].

Thanks for all the updates!

-Ben

> > Section 9.2
> >
> > I think RFCs 5925, 7525, and 8253 should be normative, and RFC 7525 can
> > be cited as BCP 195.
> >
> >
> 
> Diff: https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-stateful-hpce-13&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-stateful-hpce-14.txt
> 
> Thanks!
> Dhruv