[Pce] Review of draft-ietf-pce-stateful-hpce

["Adrian Farrel" <[e-mail]>]

Hi,

Good afternoon. My name is Adrian and I'll be your Document Shepherd for
this journey.

As this draft is progressing through working group last call, I thought I
would do my review now and save a little time later.

These comments may seem a little negative, but I hope you can address them
with small changes.

Thanks,
Adrian

===

Abstract

s/deployment of Stateful PCE(s)/deployment of Stateful PCEs/

---

Section 1 para 1 needs a reference to 5440

---

1.
s/for stateful PCE(s) in/for stateful PCEs in the/

---

1.

   The initial section of the document focuses on end to end (E2E)
   inter-domain TE LSP. Section 3.3.1 describe the operations for the
   Per Domain LSP that could be stitched.

Maybe...

   Sections 3.1 and 3.2 focus on end to end (E2E) inter-domain TE LSPa.
   Section 3.3.1 describes the operations for stitching Per Domain LSPs.

---

I am not certain that you need to use upper case terms in this document.

I found "SHOULD" in sections 6 and 7.2, and "MAY" twice in seciton 3.1
and once in section 3.3.1. Also "RECOMMENDED" in section 6.

Is this really appropriate in a document that is describing an
approach, not specifying bits on the wire or implementation behavior?

That would allow you to dispose of section 1.1 and the two references.

---

Section 3

While the terms PE and CE are defined and used unambiguously, I suspect
that they will cause some confusion because they are such well known
terms in networking.

---

3.

   All PCE types herein (i.e., PE or CE) are assumed to be
   'stateful PCE'.

Is it not plausible to have a stateless C-PCE working with a stateful
P-PCE?

I think that the relationship of child to parent is similar to the
relationship of PCC to PCE, but when we talk about a stateful PCE we
don't also talk about a stateful PCC. So when you say that the C-PCE
must be stateful, you are necessarily talking about its relationship
with its PCCs.

If you are determined to limit the scope of this document to PCE
hierarchies where both the parent and child are stateful (you are
allowed to make this choice if that's what the WG wants) then you need
to make this clear in the Abstract and Introduction.

---

Am I confused about delegation?

You have...
   The P-PCE has no information about the content of
   the child domains.

Clearly the C-PCE will report the path of the LSP (segment) that crosses
the domain for which it is responsible, but how can the P-PCE make any
change to that LSP without visibility into the child domain?

But you go on to talk about delegation as if it could work: such as...

   LSP Control Delegation (CE-PE,PE-CE):  a C-PCE grants to the P-PCE
      the right to update LSP attributes on one or more LSPs

When you draw the similarity between PCC-PCE and C-PCE-P-PCE delegation
as...
   Note that this hierarchy is recursive and thus a Label Switching
   Router (LSR), as a PCC could delegate the control to a PCE, which may
   delegate to its parent, which may further delegate it to its parent
   (if it exist or needed). Similarly update operations could also be
   applied recursively.
... I think that you miss that the PCC and PCE can both see the TED, but
the C-PCE and P-PCE have very different visibility into the domain.

---

3.
Just clarity...

OLD
   [I-D.ietf-pce-hierarchy-extensions] defines the H-PCE capability TLV
   that should be used in the OPEN message to advertise the H-PCE
   capability. [RFC8231] defines the stateful PCE capability TLV. The
   presence of both TLVs represent the support for stateful H-PCE
   operations as described in this document.
NEW
   [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.
END

---

3.
I feel that this paragraph is confusing. I think the referenced draft
also needs some work on the terms stateful and synchronization, but we
can focus on the document at hand.

OLD
   [I-D.litkowski-pce-state-sync] describes the procedures to allow a
   stateful communication between PCEs for various use-cases. The
   procedures and extensions as described in Section 3 of
   [I-D.litkowski-pce-state-sync] are also applicable to Child and
   Parent PCE communication. The SPEAKER-IDENTITY-TLV (defined in
   [RFC8232]) is included in the LSP 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.
NEW
   [I-D.litkowski-pce-state-sync] describes the procedures to allow
   communication between stateful PCEs that serve the same domain.  The
   procedures and extensions as described in Section 3 of
   [I-D.litkowski-pce-state-sync] are also applicable to Child and
   Parent PCE communication.  The SPEAKER-IDENTITY-TLV (defined in
   [RFC8232]) is included in the LSP 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.
END

However, this has made [I-D.litkowski-pce-state-sync] a normative
reference. I suspect you don't want to go there. That will mean you
need to write the normative text here (which may be a bit more of a
rewrite) and simply add...
   Similar procedures are used in [I-D.litkowski-pce-state-sync] to
   synchronize state between stateful PCEs that serve the same domain.

Furthermore, the term "Ingress" in unclear. You probably do not mean
the ingress of the LSP, per se. You probably mean the ingress of the
LSP in the domain that the C-PCE serves. You also have the term "ingress
PCE" (in 3.1) which is such a useful term that you should probably call
it out with a definition.

---

3.1

s/applicable to PCEP session/applicable to a PCEP session/

---

3.1

OLD
   Taking the sample hierarchical domain topology example from [RFC6805]
   as the reference topology for the entirety of this document.
NEW
   We use the sample hierarchical domain topology example from [RFC6805]
   as the reference topology for the entirety of this document.  It is
   shown in Figure 1.
END

---

3.1, 3.2, 3.3, and 3.3.1

It is confusing to have steps 1 to 11 as per 6805 and then introduce new
steps 1 to 4 in 3.1. We need to:
- not confuse these with steps 1 to 4 of 6805
- understand where in the sequence the steps are preformed

Furthermore, "initial" steps 1 to 8 are introduced in 3.2. Are these in
place of steps 1 to 4 in 3.1 or in addition? And where in the sequence
are they performed? How do they relate to steps 1 to 8 of 6805. There
is some slightly better description in 3.2, but only steps 1 and 2 seem
to be truly "initial".

It all needs some more clarity.

By the time I got to 3.3.1 I really couldn't work out the steps at all.

---

3.2

OLD
   To update an LSP, a PCE send to the PCC, an LSP Update Request using
   a PCUpd message.
NEW
   To update an LSP, a PCE sends an LSP Update Request to the PCC using
   a PCUpd message.
END

---

3.3.  PCE Initiation Operation

Maybe...

3.3.  PCE Initiation of LSPs

---

4.1

How about this for a slightly tidier figure 2?


                                                 +----------+
                                                 | Parent   |
                                                /| PCE      |
                                               / +----------+
                                              /     /   Stateful
                                             /     /    P-PCE
                                            /     /
                                           /     /
                          Stateful+-----+ /     /
                          C-PCE   | PCE |/     /
                          Hi      | Hi  |     /
                                  +-----+    /
          +---+    +---+                    /     +---+    +---+
         + LSR +--+ LSR +........................+ LSR +--+ LSR +
         + H1  +  + H2  +                 /      + H3  +  + H4  +
          +---+    +---+\         +-----+/       /+---+    +---+
                         \        | PCE |       /
                          \       | Lo  |      /
                Stateful   \      +-----+     /
                C-PCE       \                /
                Lo           \+---+    +---+/
                             + LSR +--+ LSR +
                             + L1  +  + L2  +
                              +---+    +---+

---

4.1

You have...

   All procedures described in Section 3 are applicable to inter-layer
   path setup as well.

I wonder if you want to explain that the layers are considered as
separate domains.

---

4.2

OLD
   [RFC8453] describes framework for Abstraction and Control of TE
   Networks (ACTN), where each Provisioning Network Controller (PNC) is
   equivalent to C-PCE and P-PCE is the Multi-Domain Service Coordinator
   (MDSC).  The Per domain stitched LSP as per the Hierarchical PCE
   architecture described in Section 3.3.1 and Section 4.1 is well
   suited for ACTN.
NEW
   [RFC8453] describes a framework for the Abstraction and Control of TE
   Networks (ACTN), where each Provisioning Network Controller (PNC) is
   equivalent to a C-PCE, and the P-PCE is the Multi-Domain Service
   Coordinator (MDSC).  The Per Domain stitched LSP as per the
   Hierarchical PCE architecture described in Section 3.3.1 and Section
   4.1 is well suited for ACTN.
END

---

4.2

OLD
   In ACTN framework, Customer Network Controller (CNC) can request the
   MDSC to check if there is a possibility to meet Virtual Network (VN)
   requirements (before requesting for VN provision).  The H-PCE
   architecture as described in [RFC6805] can supports via the use of
   PCReq and PCRep messages between the P-PCE and C-PCEs.
NEW
   In the ACTN framework, a Customer Network Controller (CNC) can
   request the MDSC to check whether there is a possibility to meet
   Virtual Network (VN) requirements before requesting for the VN to be
   provisioned.  The H-PCE architecture as described in [RFC6805] can
   support this function using PCReq and PCRep messages between the
   P-PCE and C-PCEs.
END

---

5.1

I think you need to rephrase this section. I don't think there is any
clear meaning to an LSP being involved in H-PCE.

But some of this issue can't be resolved until you have worked out what
it is that a stateful H-PCE actually does. As previously noted, it would
not appear to have access to the per-domain TEDs, so what is it doing
with an LSP that is reported or delegated to it?

Given what 5.2 says, reporting LSPs (not for delegation, but simply
reporting them) seems entirely pointless!

---

I noticed that the Table of Contents doesn't match the actual sections
starting from Section 5. Possibly sections 4 and 5 were supposed to be
merged

---

6. says

   The LSP
   state in the PCRpt message SHOULD continue to use this.

Can you explain when a PCRpt might deviate from this "SHOULD"?

---

6.

   Thus securing the PCEP session (between the P-PCE and the C-PCE)
   using mechanism like TCP Authentication Option (TCP-AO) [RFC5925] or
   Transport Layer Security (TLS) [RFC8253] is RECOMMENDED.

What does 'like' mean? Is there anything specific you have in mind?

---

You have I-D.ietf-pce-pcep-yang in your references section, but no
actual reference to it.

---

A number of references need to be promoted to Normative consistent with
how you have used them in this document.

RFC 4655
RFC 5520
RFC 5925
RFC 8232
RFC 8253
I-D.litkowski-pce-state-sync
I-D.ietf-pce-hierarchy-extensions
I-D.dugeon-pce-stateful-interdomain