Re: [Pce] WGLC for draft-ietf-pce-pcep-stateful-pce-gmpls-16
Hi all, As a contributor (it’s been a while!), I also support publication of this draft Thank you Ramon From: Pce On Behalf Of Gyan Mishra Sent: miércoles, 19 de enero de 2022 23:23 To: adr...@olddog.co.uk Cc: draft-ietf-pce-pcep-stateful-pce-gm...@ietf.org; pce@ietf.org; pce-chairs Subject: Re: [Pce] WGLC for draft-ietf-pce-pcep-stateful-pce-gmpls-16 I support publication of this draft. Looking at the Datatracker this draft has had a very long journey from 2012 and almost at the end of the tunnel. PCEP has also evolved as well with stateless PCE in 2017. This draft provides a PCEP extension extension for GMPLS networks with a stateful PCE capability bit for S and I flag, new LSP identifier XRO sub object, new B flag for SRP object for co-routed paths and new PCEP error codes. Extremely valuable specification for operators provisioning of OTN, and very good to see one implementation. Kind Regards Gyan On Wed, Jan 19, 2022 at 3:47 PM Adrian Farrel mailto:adr...@olddog.co.uk> > wrote: 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: SRP But not: However, note that you have 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: But not: However, note that you have 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
Re: [Pce] WGLC for draft-ietf-pce-pcep-stateful-pce-gmpls-16
I support publication of this draft. Looking at the Datatracker this draft has had a very long journey from 2012 and almost at the end of the tunnel. PCEP has also evolved as well with stateless PCE in 2017. This draft provides a PCEP extension extension for GMPLS networks with a stateful PCE capability bit for S and I flag, new LSP identifier XRO sub object, new B flag for SRP object for co-routed paths and new PCEP error codes. Extremely valuable specification for operators provisioning of OTN, and very good to see one implementation. Kind Regards Gyan On Wed, Jan 19, 2022 at 3:47 PM Adrian Farrel wrote: > 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: > > > > > > > > > > > > SRP > > > > But not: > > > > > > > > > > > > However, note that you have > > 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: > > > > > > > > But not: > > > > > > > > However, note that you have > > 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
Re: [Pce] WGLC for draft-ietf-pce-pcep-stateful-pce-gmpls-16
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: SRP But not: However, note that you have 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: But not: However, note that you have 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
