Hi Julien, That would be great, thanks.
Cheers Jon -----Original Message----- From: Julien Meuric [mailto:[email protected]] Sent: 18 August 2016 10:00 To: Jonathan Hardwick <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [Pce] Shepherd's Review of draft-ietf-pce-pce-initiated-lsp-07 Hi Jon, Thank you for this "segment routing"-focused feedback. I fully agree with deferring detailed specification for segment routing to another document. The discussed I-D should just: - be clear on the RSVP-TE case, - cover a default case (i.e. non-RSVP), with a flexible definition. This would turn the latest sentence of my proposed paragraph below into: "For LSPs to be setup by other means, the END-POINTS object SHOULD/MAY be omitted; the exact behavior for other types of LSPs will be specified in further documents." Would that address your concern? Cheers, Julien Aug. 16, 2016 - [email protected]: > 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 > > 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
