Dear authors of draft-ietf-pce-pce-initiated-lsp,
Please find below my shepherd's review of the aforementioned I-D.
_Summary_
The document does not need much work to move forward. As discussed with
Ina during the IETF week, a few items deserve to be highlighted:
- the choice of zero as wildcard PLSP-ID to remove all LSPs initiated by
a PCE is unsafe;
- the use of the END-POINTS object is misaligned with RFC 5440's
definition and not suited to SR.
_Detailed Comments_
------
Header
---
- Like with draft-ietf-pce-stateful-pce, adding "Individual Contributor"
after Ed's name helps getting rid of the odd empty line.
------
Abstract
---
- s/provide stateful control/provide active control/
------
Section 1.
---
- s/Path Computation Element Protocol PCEP/Path Computation Element
communication Protocol (PCEP)/
------
Section 3.
---
- s/provides stateful control/provides active control/
- s/is one of a software-driven/is a software-driven/
- s/is one of dynamically/is dynamically/
- s/is that of demand/is demand/
- s/Operation overview/Operation Overview/
- s/PCE provisioned/PCE-provisioned/
- s/it also generates/it MUST also generate/
- s/PCC also sets/PCC MUST also set/
- s/PCE may update/PCE MAY update/
- s/PCC initiated LSPs/PCC-initiated LSPs/
------
Section 4.
---
- s/PCE provisioned/PCE-provisioned/
------
Section 5.
---
- s/LSP instantiation and deletion/LSP Instantiation and Deletion/
- OLD:
A Path Computation LSP Initiate Message (also referred to as PCInitiate
message) is a PCEP message...
NEW:
A Path Computation LSP Initiate Message is referred to as PCInitiate
message: it is a PCEP message...
- s/and may contain/and MAY contain/
- OLD :
If the SRP object is missing, the PCC MUST send a PCErr with error-type
6 (Mandatory Object missing) and error-value=10 (SRP Object missing)
(per [I-D.ietf-pce-stateful-pce]. If the LSP object is missing, the PCC
MUST send a PCErr with error-type 6 (Mandatory Object missing) and
error-value=8 (LSP Object missing) (per [I-D.ietf-pce-stateful-pce]).
NEW:
Missing SRP and LSP objects in PCInitiate MUST trigger the same PCErr
procedures as specified in [I-D.ietf-pce-stateful-pce] for PCUpd.
- s/<END-POINTS>/[<END-POINTS>]/ (see discussion below)
- s/5.3. LSP instantiation/5.3. LSP Instantiation/
- s/LSP Initiate Message/PCInitiate message/
- s/results in a PCErr/MUST result in a PCErr/
- The use of the END-POINTS objects has puzzled me for multiple reasons:
* RFC 5440 defines the object as a pair of IDs allowing to identify
the two points to be interconnected by the ERO to be filled in, whereas
the draft uses it to push the IDs of the signaling ends;
* The signaling source ID to be used should rather be up to the PCC,
the requirement on pushing it from the PCE is not obvious;
* The ERO may include some IDs that could be used as default
source/destination IDs, which also makes the need for a destination ID
less obvious;
* To address these, I see 3 options:
1- Giving up the use of a specific object and fully rely on the ERO;
2- Defining new "SignalingRemoteID" types (possibly within the
END-POINTS object class) to (optionally) convey the info;
3- Rephrase the text to turn the unwanted "redefinition" of the
END-POINTS object into a wording more consistent with RFC 5440, e.g.:
OLD:
The END-POINTS Object is mandatory for an instantiation request of an
RSVP-signaled LSP. It contains the source and destination addresses
for provisioning the LSP. If the END-POINTS Object is missing, the
PCC MUST send a PCErr message with Error-type=6 (Mandatory Object
missing) and Error-value=3 (END-POINTS Object missing).
NEW:
For an instantiation request of an RSVP-signaled LSP, the destination
address may be needed. The PCC may determine it from a provided object
(e.g., ERO) or a local decision. Alternatively, the END-POINTS object
MAY be included to explicitly convey the destination addresses to be
used in the RSVP-TE signaling. The source address may be either
specified or left up to the PCC decision using the 0.0.0.0 value. For
LSPs to be setup by other means (e.g., Segment Routing), the END-POINTS
object SHOULD be omitted.
* In case you go for option 2, you still need to be more explicit on
the non-RSVP case; i.e., the new text should say: "The <OBJECT_NAME> MAY
be included for instantiation request of an RSVP-TE-signaled LSP, and
SHOULD be omitted otherwise."
- s/echo the SRP-id-number/echo the SRP-ID-number/
- The 2nd paragraph on page 11 ("On succesful completion...") duplicates
the 2nd one on page 10 ("The PCE MAY include...") and should be dropped
(or at least the 2nd half of it).
- s/succesful completion/successful completion/
- s/5.3.1. The Create flag/5.3.1. The Create Flag/
- On Figure 3, the "O" would be better in the middle of the 3-bit field.
- Once defined, the phrases "Create flag"/"C Flag"/"C-flag" are
alternatively used, please pick one and use it everywhere (I personally
like "C-flag" but "R flag" seems common in the I-D). Note that
flag-phrases should be consistent beyond C.
- s/the PCE who initiated/the PCE which initiated/
- s/5.4. LSP deletion/5.4. LSP Deletion/
- "A PLSP-ID of zero removes all LSPs...": a broken implementation is
very likely to use 0 as a default, any value but 0 would be safer;
please pick another one.
- s/value 1 ([I-D.ietf-pce-stateful-pce
<https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-07#ref-I-D.ietf-pce-stateful-pce>])/value
1 as per [I-D.ietf-pce-stateful-pce
<https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-07#ref-I-D.ietf-pce-stateful-pce>])/
- s/The R flag [...] SHOULD be set./The R flag [...] MUST be set./ [or
with "R-flag" ?]
------
Section 6.
---
- s/LSP delegation and cleanup/LSP Delegation and Cleanup/
- s/must have the delegation bit/MUST have the delegation bit/
- OLD:
Receipt of a
PCInitiate message with a non-zero PLSP-ID normally results in the
generation of a PCErr. If the LSP is an orphan, the PCC MUST NOT
generate an error and MUST redelegate the LSP to the PCE.
NEW:
On receipt of PCInitiate message with a PLSP-ID pointing to an
orphan LSP, the PCC MUST redelegate that LSP to the PCE. Any
other non-zero PLSP-ID MUST result in the generation of a PCErr.
------
Section 7.
---
- s/7. Implementation status/7. Implementation Status/
------
Section 8.
---
- s/8. IANA considerations/8. IANA Considerations/
------
Section 11.
---
- The reference to draft-ietf-pce-stateful-sync-optimizations is not
required to understand this document and should thus be moved to the
informative section.
- Ditto for RFC 5226 (guidelines for authors, not mandatory to readers).
------
Cheers,
Julien
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
