Hi Julien During this email, I'm wearing my "segment routing co-author" hat :-)
I agree that END-POINTS is not necessarily congruent with RSVP signalling addresses, but I don't agree with the part of the proposed amendment that says that this object should not be used for segment-routed LSPs. As you said, the intent of END-POINTS is to give the two points to be interconnected by the LSP. In segment routing, where there is no confusion with RSVP signalling addresses, it is useful for the PCC to have this object available. The PCC needs this information in order to use the LSP, and having to derive it from the ERO would be more difficult for implementers. I'd prefer not to say anything about the use of END-POINTS in segment routing in this draft. We can discuss its use in draft-ietf-pce-segment-routing. Is that OK? Best regards Jon -----Original Message----- From: Pce [mailto:[email protected]] On Behalf Of Julien Meuric Sent: 29 July 2016 10:16 To: [email protected] Cc: [email protected] Subject: [Pce] Shepherd's Review of draft-ietf-pce-pce-initiated-lsp-07 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 [email protected] https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
