Re: [Pce] WG Last Call for draft-ietf-pce-gmpls-pcep-extensions-09
Dear PCErs, The document has been updated to reflect your comments and has been posted. In addition we included the comments on IANA allocation received post LC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-gmpls-pcep-extensions-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-gmpls-pcep-extensions-10 Best Regards, Cyril On 21 July 2014 05:38, Julien Meuric julien.meu...@orange.com wrote: Hi all. This WG last call has ended. The authors are expected to address the received comments (thank you John for the feedback). Chairs' review will follow. Thanks, JP Julien Jul. 04, 2014 - Julien Meuric: Dear WG, Now that you all have some time dedicated to I-Ds, please consider this as part of your review list. This message ignites the WG LC on draft-ietf-pce-gmpls-pcep-extensions-09. Comments should be sent to the PCE mailing list by Friday July 18, 11:59 PM, HST. Regards, JP Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Last Call for draft-ietf-pce-gmpls-pcep-extensions-09
Protection InformationThis document (section Section 2.8) Comment: name not consistent, should be: PROTECTION-ATTRIBUTE according to the main text. == Section 5.7 5.8 == s/suboject /subobject ===Section 6== Even if there is additional security issue incurred in this draft, is it worthwhile to at least mention some issues already covered by other RFCs or just some pointers? -Original Message- From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick Sent: 2014年7月18日 22:22 To: draft-ietf-pce-gmpls-pcep-extensi...@tools.ietf.org Cc: pce@ietf.org Subject: Re: [Pce] WG Last Call for draft-ietf-pce-gmpls-pcep-extensions-09 I've reviewed this document for the WG last call. I think this document is in good shape. I only found nits - see below. Best regards Jon == Section 1.3 == Change A new object type are introduced for the BANDWIDTH object to Two new object types are introduced for the BANDWIDTH object == Section 2.2 == Final paragraph second sentence - I think you should change this to Otherwise, the PCE MAY use... to make it clear that the second sentence is not intended to contradict the first sentence. == Section 2.3 == Page 9, directly under Traffic Spec field encoding table - there is a stray comma that should be deleted - change is MUST specify... to it MUST specify... - change As specified i [RFC5440] to As specified in [RFC5440] - change BANDWIDTH object of with object type 1 to BANDWIDTH object of object type 1 == Section 2.4 == Page 11, directly under Traffic Spec field encoding table - there is a stray full stop (period) that should be deleted - change is MUST specify... to it MUST specify... == Section 2.5.1 == List of 5 items on page 12. Should the LABEL-REQUEST TLV also be in this list? == Section 2.6 == Change IP address subobject MUST be a link subobject. to If an IP address subobject is used, then the IP address given MUST be associated with a link. Change The procedure associated with this subobject is as follow to The procedure associated with this subobject is as follows. Change MUST allocate one label of from within the set of label values to MUST allocate one label from within the set of label values Change If the PCE does not assign labels a response with a NO-PATH and a NO-PATH-VECTOR-TLV with the bit .'No label resource in range' set. to If the PCE does not assign labels then it sends a response with a NO-PATH object, containing a NO-PATH-VECTOR-TLV with the bit 'No label resource in range' set. == Section 2.7 == Is your intention that the Label Subobject can also be used in the EXRS (RFC 5521 section 2.2?) I think it is worth adding a sentence saying so. For consistency with section 2.6 (and because I think the text in 2.6 is clearer) I think you should change this: XRO Label subobjects MUST follow the numbered or unnumbered interface subobjects to which they refer. Each subobject represent one label, several XRO Labels subobject MAY be present for each link. to this: The Label subobject MUST follow a subobject identifying a link, currently an IP address subobject (Type 1 or 2) or an interface id (type 4) subobject. If an IP address subobject is used, then the IP address given MUST be associated with a link. More than one label suboject MAY follow each link subobject. == Section 5.1 == The formatting used in this section is not consistent. Use consistent indentation column width. For BANDWIDTH object I think you mean 5-15: Unassigned For ENDPOINTS the reference should be to 2.5, not 2.3 == Section 5.5 == Value=q0 should be Value=10 -Original Message- From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric Sent: 04 July 2014 17:05 To: pce@ietf.org Subject: [Pce] WG Last Call for draft-ietf-pce-gmpls-pcep-extensions-09 Dear WG, Now that you all have some time dedicated to I-Ds, please consider this as part of your review list. This message ignites the WG LC on draft-ietf-pce-gmpls-pcep-extensions-09. Comments should be sent to the PCE mailing list by Friday July 18, 11:59 PM, HST. Regards, JP Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Last Call for draft-ietf-pce-gmpls-pcep-extensions-09
in request. s/Accepted endpoint type in END-POINTS object type Generalized Endpoint and allowed TLVs/Accepted endpoint type in Generalized Endpoint object type and allowed TLVs == Section 5.1 == As described in Section 2.3, Section 2.4 and Section 2.5.1 new Objects types are defined IANA… Comment: A period is missing before IANA. == Section 5.3 == 13 LSP Protection InformationThis document (section Section 2.8) Comment: name not consistent, should be: PROTECTION-ATTRIBUTE according to the main text. == Section 5.7 5.8 == s/suboject /subobject ===Section 6== Even if there is additional security issue incurred in this draft, is it worthwhile to at least mention some issues already covered by other RFCs or just some pointers? -Original Message- From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick Sent: 2014年7月18日 22:22 To: draft-ietf-pce-gmpls-pcep-extensi...@tools.ietf.org Cc: pce@ietf.org Subject: Re: [Pce] WG Last Call for draft-ietf-pce-gmpls-pcep-extensions-09 I've reviewed this document for the WG last call. I think this document is in good shape. I only found nits - see below. Best regards Jon == Section 1.3 == Change A new object type are introduced for the BANDWIDTH object to Two new object types are introduced for the BANDWIDTH object == Section 2.2 == Final paragraph second sentence - I think you should change this to Otherwise, the PCE MAY use... to make it clear that the second sentence is not intended to contradict the first sentence. == Section 2.3 == Page 9, directly under Traffic Spec field encoding table - there is a stray comma that should be deleted - change is MUST specify... to it MUST specify... - change As specified i [RFC5440] to As specified in [RFC5440] - change BANDWIDTH object of with object type 1 to BANDWIDTH object of object type 1 == Section 2.4 == Page 11, directly under Traffic Spec field encoding table - there is a stray full stop (period) that should be deleted - change is MUST specify... to it MUST specify... == Section 2.5.1 == List of 5 items on page 12. Should the LABEL-REQUEST TLV also be in this list? == Section 2.6 == Change IP address subobject MUST be a link subobject. to If an IP address subobject is used, then the IP address given MUST be associated with a link. Change The procedure associated with this subobject is as follow to The procedure associated with this subobject is as follows. Change MUST allocate one label of from within the set of label values to MUST allocate one label from within the set of label values Change If the PCE does not assign labels a response with a NO-PATH and a NO-PATH-VECTOR-TLV with the bit .'No label resource in range' set. to If the PCE does not assign labels then it sends a response with a NO-PATH object, containing a NO-PATH-VECTOR-TLV with the bit 'No label resource in range' set. == Section 2.7 == Is your intention that the Label Subobject can also be used in the EXRS (RFC 5521 section 2.2?) I think it is worth adding a sentence saying so. For consistency with section 2.6 (and because I think the text in 2.6 is clearer) I think you should change this: XRO Label subobjects MUST follow the numbered or unnumbered interface subobjects to which they refer. Each subobject represent one label, several XRO Labels subobject MAY be present for each link. to this: The Label subobject MUST follow a subobject identifying a link, currently an IP address subobject (Type 1 or 2) or an interface id (type 4) subobject. If an IP address subobject is used, then the IP address given MUST be associated with a link. More than one label suboject MAY follow each link subobject. == Section 5.1 == The formatting used in this section is not consistent. Use consistent indentation column width. For BANDWIDTH object I think you mean 5-15: Unassigned For ENDPOINTS the reference should be to 2.5, not 2.3 == Section 5.5 == Value=q0 should be Value=10 -Original Message- From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric Sent: 04 July 2014 17:05 To: pce@ietf.org Subject: [Pce] WG Last Call for draft-ietf-pce-gmpls-pcep-extensions-09 Dear WG, Now that you all have some time dedicated to I-Ds, please consider this as part of your review list. This message ignites the WG LC on draft-ietf-pce-gmpls-pcep-extensions-09. Comments should be sent to the PCE mailing list by Friday July 18, 11:59 PM, HST. Regards, JP Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Last Call for draft-ietf-pce-gmpls-pcep-extensions-09
H Jonathan, Thanks a lot for your review, please see inline. On 18 July 2014 10:22, Jonathan Hardwick jonathan.hardw...@metaswitch.com wrote: I've reviewed this document for the WG last call. I think this document is in good shape. I only found nits - see below. Best regards Jon == Section 1.3 == Change A new object type are introduced for the BANDWIDTH object to Two new object types are introduced for the BANDWIDTH object Agree == Section 2.2 == Final paragraph second sentence - I think you should change this to Otherwise, the PCE MAY use... to make it clear that the second sentence is not intended to contradict the first sentence. Agree == Section 2.3 == Page 9, directly under Traffic Spec field encoding table - there is a stray comma that should be deleted - change is MUST specify... to it MUST specify... - change As specified i [RFC5440] to As specified in [RFC5440] - change BANDWIDTH object of with object type 1 to BANDWIDTH object of object type 1 Agree == Section 2.4 == Page 11, directly under Traffic Spec field encoding table - there is a stray full stop (period) that should be deleted - change is MUST specify... to it MUST specify... Agree == Section 2.5.1 == List of 5 items on page 12. Should the LABEL-REQUEST TLV also be in this list? This is correct, the TLV will be added to the list == Section 2.6 == Change IP address subobject MUST be a link subobject. to If an IP address subobject is used, then the IP address given MUST be associated with a link. Agree Change The procedure associated with this subobject is as follow to The procedure associated with this subobject is as follows. Agree Change MUST allocate one label of from within the set of label values to MUST allocate one label from within the set of label values Agree Change If the PCE does not assign labels a response with a NO-PATH and a NO-PATH-VECTOR-TLV with the bit .'No label resource in range' set. to If the PCE does not assign labels then it sends a response with a NO-PATH object, containing a NO-PATH-VECTOR-TLV with the bit 'No label resource in range' set. Agree == Section 2.7 == Is your intention that the Label Subobject can also be used in the EXRS (RFC 5521 section 2.2?) I think it is worth adding a sentence saying so. This is correct For consistency with section 2.6 (and because I think the text in 2.6 is clearer) I think you should change this: XRO Label subobjects MUST follow the numbered or unnumbered interface subobjects to which they refer. Each subobject represent one label, several XRO Labels subobject MAY be present for each link. to this: The Label subobject MUST follow a subobject identifying a link, currently an IP address subobject (Type 1 or 2) or an interface id (type 4) subobject. If an IP address subobject is used, then the IP address given MUST be associated with a link. More than one label suboject MAY follow each link subobject. Agree == Section 5.1 == The formatting used in this section is not consistent. Use consistent indentation column width. For BANDWIDTH object I think you mean 5-15: Unassigned For ENDPOINTS the reference should be to 2.5, not 2.3 I agree, == Section 5.5 == Value=q0 should be Value=10 Agree -Original Message- From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric Sent: 04 July 2014 17:05 To: pce@ietf.org Subject: [Pce] WG Last Call for draft-ietf-pce-gmpls-pcep-extensions-09 Dear WG, Now that you all have some time dedicated to I-Ds, please consider this as part of your review list. This message ignites the WG LC on draft-ietf-pce-gmpls-pcep-extensions-09. Comments should be sent to the PCE mailing list by Friday July 18, 11:59 PM, HST. Regards, JP Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Last Call for draft-ietf-pce-gmpls-pcep-extensions-09
, so I will put contains the information, is it OK? == Section 3 == S/Bad Bandwidth Object type 3 or 4 not supported./ Object type 3 or 4 not supported Agree == Section 4.1 == s/Accepted LOAD-BALANCING object type 3 and 4 parameters in request./ Accepted LOAD-BALANCING object type 2 parameters in request. Agree s/Accepted endpoint type in END-POINTS object type Generalized Endpoint and allowed TLVs/Accepted endpoint type in Generalized Endpoint object type and allowed TLVs I would like to keep the END-POINTS object, what about Accepted endpoint type in object END-POINTS with object type Generalized Endpoint and allowed TLVs == Section 5.1 == As described in Section 2.3, Section 2.4 and Section 2.5.1 new Objects types are defined IANA… Comment: A period is missing before IANA. Agree == Section 5.3 == 13 LSP Protection InformationThis document (section Section 2.8) Comment: name not consistent, should be: PROTECTION-ATTRIBUTE according to the main text. Agree == Section 5.7 5.8 == s/suboject /subobject Agree ===Section 6== Even if there is additional security issue incurred in this draft, is it worthwhile to at least mention some issues already covered by other RFCs or just some pointers? OK, we will enhance this section . Thanks for your review. -Original Message- From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick Sent: 2014年7月18日 22:22 To: draft-ietf-pce-gmpls-pcep-extensi...@tools.ietf.org Cc: pce@ietf.org Subject: Re: [Pce] WG Last Call for draft-ietf-pce-gmpls-pcep-extensions-09 I've reviewed this document for the WG last call. I think this document is in good shape. I only found nits - see below. Best regards Jon == Section 1.3 == Change A new object type are introduced for the BANDWIDTH object to Two new object types are introduced for the BANDWIDTH object == Section 2.2 == Final paragraph second sentence - I think you should change this to Otherwise, the PCE MAY use... to make it clear that the second sentence is not intended to contradict the first sentence. == Section 2.3 == Page 9, directly under Traffic Spec field encoding table - there is a stray comma that should be deleted - change is MUST specify... to it MUST specify... - change As specified i [RFC5440] to As specified in [RFC5440] - change BANDWIDTH object of with object type 1 to BANDWIDTH object of object type 1 == Section 2.4 == Page 11, directly under Traffic Spec field encoding table - there is a stray full stop (period) that should be deleted - change is MUST specify... to it MUST specify... == Section 2.5.1 == List of 5 items on page 12. Should the LABEL-REQUEST TLV also be in this list? == Section 2.6 == Change IP address subobject MUST be a link subobject. to If an IP address subobject is used, then the IP address given MUST be associated with a link. Change The procedure associated with this subobject is as follow to The procedure associated with this subobject is as follows. Change MUST allocate one label of from within the set of label values to MUST allocate one label from within the set of label values Change If the PCE does not assign labels a response with a NO-PATH and a NO-PATH-VECTOR-TLV with the bit .'No label resource in range' set. to If the PCE does not assign labels then it sends a response with a NO-PATH object, containing a NO-PATH-VECTOR-TLV with the bit 'No label resource in range' set. == Section 2.7 == Is your intention that the Label Subobject can also be used in the EXRS (RFC 5521 section 2.2?) I think it is worth adding a sentence saying so. For consistency with section 2.6 (and because I think the text in 2.6 is clearer) I think you should change this: XRO Label subobjects MUST follow the numbered or unnumbered interface subobjects to which they refer. Each subobject represent one label, several XRO Labels subobject MAY be present for each link. to this: The Label subobject MUST follow a subobject identifying a link, currently an IP address subobject (Type 1 or 2) or an interface id (type 4) subobject. If an IP address subobject is used, then the IP address given MUST be associated with a link. More than one label suboject MAY follow each link subobject. == Section 5.1 == The formatting used in this section is not consistent. Use consistent indentation column width. For BANDWIDTH object I think you mean 5-15: Unassigned For ENDPOINTS the reference should be to 2.5, not 2.3 == Section 5.5 == Value=q0 should be Value=10 -Original Message- From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric Sent: 04 July 2014 17:05 To: pce@ietf.org Subject: [Pce] WG Last Call for draft-ietf-pce-gmpls-pcep-extensions-09 Dear WG, Now that you all have some time dedicated to I-Ds, please consider this as part of your review
