Re: [Pce] Moving draft-ietf-pce-hierarchy-extensions onto the standards track
Hi Jonathan, I think your proposal makes a lot of sense in light of multiple H-PCE implementations. I fully support this idea. Related to this draft, we have presented in Yokohama and Buenos Aires the use of H-PCE in stateful PCE environment https://tools.ietf.org/html/draft-dhodylee-pce-stateful-hpce-00 Would you suggest us how to proceed with this draft? I think we have sufficient interest on this work and have a few implementations underway. Thanks, Young (on behalf of other co-authors) From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick Sent: Tuesday, July 26, 2016 8:48 AM To: pce@ietf.org Cc: pce-cha...@ietf.org Subject: [Pce] Moving draft-ietf-pce-hierarchy-extensions onto the standards track Dear PCE WG At the recent IETF meeting, the authors of the above document requested that the document be moved from Experimental status onto the standards track. This is in consequence of there now being multiple implementations of the H-PCE protocol extensions, and H-PCE becoming important for new applications like ACTN. Please see the meeting slides for details. https://www.ietf.org/proceedings/96/slides/slides-96-pce-15.pdf https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/ Please send an email to the list if you have any comments or objections to doing this, by Friday 12 August. If you do not reply, we will treat it as "no objection". Many thanks Jon, JP and Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Shepherd's Review of draft-ietf-pce-pce-initiated-lsp-07
Hi Julien, That would be great, thanks. Cheers Jon -Original Message- From: Julien Meuric [mailto:julien.meu...@orange.com] Sent: 18 August 2016 10:00 To: Jonathan Hardwick Cc: pce@ietf.org; draft-ietf-pce-pce-initiated-...@ietf.org 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 - jonathan.hardw...@metaswitch.com: > 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:pce-boun...@ietf.org] 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//[]/ (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, wh
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 - jonathan.hardw...@metaswitch.com: 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:pce-boun...@ietf.org] 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//[]/ (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
