Hi,
It's been a journey for this draft! July 2012 :-)
Glad that we are finally in a place to last call it, and excellent to
know there is an implementation.
Here is my review in support of the last call. You'll see that my minor
points are essentially editorial (i.e., not asking to change the
functional behaviour described in the document). There are also some
nits. With these issues fixed, I think the document is ready to
proceed.
Best,
Adrian
===
== Minor ==
6.
You need text in this section as...
This section uses Routing Backus-Naur Form (RBNF) [RFC5511] to
describe message formats.
But note that the comments below might do away with the RBNF!
---
6.1
It is really hard to tell what this document has changed over RFC 8231.
I don't think you should repeat what is already defined, and, as far as
I can tell, nothing in the RBNF has changed.
That means the section should read...
The format of the PCRpt message is unchanged from Section 6.1 of
[RFC8231]. However, some of the objects are extended for use with
this document as follows:
Then, I think you list and describe:
<intended-path>
<actual-attribute-list>
SRP
But not:
<actual-path>
<intended-attribute-list>
However, note that you have
<intended-attribute-list> is the attribute-list defined in
Section 6.5 of [RFC5440] and extended by PCEP extensions.
...which is meaningless!
---
Similarly in 6.2
The format of the PCUpd message is unchanged from Section 6.2 of
[RFC8231]. However, some of the objects are extended for use with
this document as follows:
Then, I think you list and describe:
<intended-path>
But not:
<intended-attribute-list>
However, note that you have
<intended-attribute-list> is the attribute-list defined in
Section 6.5 of [RFC5440] and extended by PCEP extensions.
...which is meaningless!
I wonder why there is no pointer to SRP in 7.2.3 from this section.
---
The same applies in 6.3, but the text about what has changed is
more complicated.
I think...
The format of the PCInitiate message is unchanged from Section 5.1 of
[RFC8281]. However, note the following:
o The END-POINTS object was been extended by [RFC8779] to include a
new object type called "Generalized Endpoint". A PCInitiate
message used to trigger a GMPLS LSP instantiation MUST use that
extension.
o A PCInitiate message sent by a PCE to a PCC to trigger a GMPLS LSP
instantiation MUST include the END-POINTS with Generalized Endpoint
object type (even though it is marked as optional in the message
definition.
o The END-POINTS object MUST contain a "label request" TLV per
[RFC8779]. The label request TLV is used to specify the switching
type, encoding type and G-PID of the LSP being instantiated by the
PCE.
o If unnumbered endpoint addresses are used for the LSP being
instantiated by the PCE, the unnumbered endpoint TLV [RFC8779]
MUST be use to specify the unnumbered endpoint addresses.
o The END-POINTS MAY contain other TLVs defined in [RFC8779].
---
There is a discrepancy between 5.1, 7.2.1, and 10.1. In 10.1, you
correctly ask IANA to allocate TBD1 and TBD2. In 5.1 you refer to
the new bits as TBD1 and TBD2, but in 7.2.1 you:
- Do not refer to TBD1 or TBD2
- Use a figure to specifically imply values for TBD1 and TBD2
I suggest that you:
- remove the figure
- mention TBD1 and TBD2 in the text
---
7.2.2
Will you ask IANA to maintain a registry for the Flags field?
---
7.2.2
You have
This sub-object is OPTIONAL in the exclude route object (XRO) and
can be present multiple times. When a stateful PCE receives a PCReq
message carrying this sub-object, it SHOULD search for the
identified LSP in its LSP-DB and then exclude from the new path
computation all resources used by the identified LSP.
Your use of "SHOULD" here implies that an implementation has a choice to
do something different. You need to say:
- what different thing MAY a PCE do?
- why might it make that choice?
(Or make this "MUST")
---
7.2.3 refers to TBD6, but 10.3 has TBD4
---
In 8.1 and 8.2 you have that the PCE SHOULD do things without specifying
what else it might do and why. You also have some cases of lower case
"should" which don't seem right.
---
8.3 has
If the PCC does not support the END-POINTS Object of type
Generalized Endpoint, the PCC MUST send a PCErr message with Error-
type = 3(Unknown Object), Error-value = 2(unknown object type).
I think this is not new behaviour so you need to point to the spec that
defines this with "...per [RFC5440]..."
== Nits ==
Throughout
Please be careful with "sub-object" and "subobject"
---
1.
s/and does not cover the GMPLS/and do not cover GMPLS/
---
1. Final paragraph
Introduce a new paragraph break before "This document focuses..."
---
1.
s/Protocol extensions is included/Protocol extensions are included/
---
3.
s/PCE, PCUpd message/PCE, a PCUpd message/
s/delegated to PCE/delegated to the PCE/
s/by the PCC to PCE/from the PCC to the PCE/
---
3.
Furthermore, the Initiation of PCEP are
Is that...
Furthermore, the Initiation of PCEP sessions are
...or...
Furthermore, the Initiation phase of PCEP is
...or...
Furthermore, the PCInitiate PCEP message is
...or...
Furthermore, the LSP Initiation function of PCEP is
---
3.
s/to initiate the LSP establishment/to initiate LSP establishment/
---
3.
OLD
Some of these Objects/TLVs
may require modifications to incorporate stateful PCE where
applicable
NEW
Where these Objects/TLVs
require modifications to incorporate stateful PCE, they are
described in this document.
END
---
4.
s/were covered in [RFC8231]/are covered in [RFC8231]/
s/provides extension for/provides extensions for/
s/capable to indicate/capable of indicating/
s/capabilities per TE/capabilities a per TE/
---
4.
OLD
Such information would be needed for
PCEP message.
NEW
Such information would need to be included
in various PCEP messages.
END
---
4.
s/some technologies path/some technologies, path/
s/Stateful PCEP message also/Stateful PCEP messages also/
---
5. Overview of PCEP Extensions for GMPLS Networks
I think this might be
5. Overview of Stateful PCEP Extensions for GMPLS Networks
---
5.1
s/introduced as flag/introduced as flags/
---
5.2
s/attributes include bandwidth/attributes including bandwidth/
s/modified LSP during/modified LSPs during/
---
5.4
s/stateful PCE mechanism/stateful PCE mechanisms/
---
6.1
s/current state of LSP/current state of an LSP/
---
7.2.1
The figure seems to have superfluous blank lines
---
7.2.2
Would be nice if this section was called
7.2.2. New LSP Exclusion Subobject in the XRO
---
7.2.2
The figure calls the field "Flag" but the text has "Flags"
---
7.2.2
Reserved: MUST be transmitted as zero and SHOULD be ignored on
receipt.
There is no reserved field shown in the figure.
From: Pce <[email protected]> On Behalf Of Dhruv Dhody
Sent: 18 January 2022 13:17
To: [email protected]
Cc: [email protected]; pce-chairs
<[email protected]>
Subject: [Pce] WGLC for draft-ietf-pce-pcep-stateful-pce-gmpls-16
Hi WG,
This email starts a 2-weeks working group last call for
draft-ietf-pce-pcep-stateful-pce-gmpls-16 [1]. Please indicate your support or
concern for this draft. If you are opposed to the progression of the draft to
RFC, please articulate your concern. If you support it, please indicate that
you have read the latest version and it is ready for publication in your
opinion. As always, review comments and nits are most welcome.
The WG LC will end on 1st Feb 2022.
A general reminder to the WG to be more vocal during the last-call/adoption and
help us unclog our queues :)
Thanks,
Dhruv & Julien
[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-stateful-pce-gmpls/
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
