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
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
