Re: [Pce] New Version Notification for draft-ietf-pce-hierarchy-extensions-07.txt
Hi Adrian, Thanks for your email, let me tackle a few Regards, Dhruv > -Original Message- > From: Adrian Farrel [mailto:adr...@olddog.co.uk] > Sent: 07 December 2018 00:18 > To: 'Dhruv Dhody' ; 'Daniel King' > > Cc: pce@ietf.org; Dhruv Dhody > Subject: RE: [Pce] New Version Notification for draft-ietf-pce-hierarchy- > extensions-07.txt > > Hi Dhruv, Authors, > > Thanks for -06 and -07 addressing comments, and -08 fixing the ToC. > > I have just been through the diffs comparing against my review comments. > You seem to addressed most of my concerns, but not quite all of them. You > also introduced a couple of new issues > > Thanks for the work, > Adrian > -- > Fairy tales from North Wales brought to you for Christmas > https://www.feedaread.com/profiles/8604/ > Available from your favourite online bookseller. > Or contact me to receive a signed copy by mail. > > === > > In 2.1.2 you now have " there is three new". s/is/are/ > > --- > > I don't think you have completely addressed my concerns in 2.2. In fact > you have changed the text to say... >A PCEP Speaker (Parent PCE or Child PCE or PCC) includes the "H-PCE >Capability" TLV, described in Section 3.1.1, in the OPEN Object to >advertise its support for PCEP extensions for H-PCE Capability. > But the very next paragraph says only that " it would assist network > operators if the child and parent PCEs could indicate their H-PCE > capabilities." In other words, you have created a conflict. Either it is > PCEs and PCCs that support this document MUST advertise that capability in > the Open message, or it is RECOMMENDED. > > Maybe, in the first line s/includes/can include/ > > Or maybe (having re-read 3.1.1) you intend to go beyond 6805 section 4.8.2 > and make the capabilities in the Open Message mandatory for H-PCE > pairings. It would help if you were clear about this such as... > OLD >A PCEP Speaker (Parent PCE or Child PCE or PCC) includes the "H-PCE >Capability" TLV, described in Section 3.1.1, in the OPEN Object to >advertise its support for PCEP extensions for H-PCE Capability. > >Parent and child PCE relationships are likely to be configured. >However, as mentioned in [RFC6805], it would assist network operators >if the child and parent PCEs could indicate their H-PCE capabilities. > NEW >A PCEP Speaker (Parent PCE or Child PCE) that supports and wishes >to use the procedures described in this document must advertise >the fact and negotiate its role with its PCEP peers. It does this using >the "H-PCE Capability" TLV, described in Section 3.1.1, in the OPEN >Object to advertise its support for PCEP extensions for H-PCE >Capability. > END > [[[Dhruv Dhody]]] I agree with your suggested wording, it is much clearer. > --- > > 3.1.1. is a lot better, thanks. > > You have... >The inclusion of this TLV in an OPEN object indicates that the H-PCE >extensions are supported by the PCEP speaker. The child PCE MUST >include this TLV and set the P flag. The parent PCE MUST include >this TLV and unset the P flag. The PCC MUST include this TLV to >indicate that it understands the H-PCE extensions with P flag unset. > > The first two sentences are good: the function allows two PCEs to work out > the direction of the relationship between them. > > However, I don't understand the final sentence. Why would a PCC need to > indicate that it understands the H-PCE extensions? Given that it: > - cannot be a parent PCE because it is not a PCE > - cannot be a child PCE because it is not a PCE ...why would it ever > indicate that it supports the H-PCE extensions? Actually, why would it > ever be implemented to support those extensions? Furthermore, by including > the TLV but not setting the P flag, it gives the impression that it is > willing to be a parent PCE. > [[[Dhruv Dhody]]] We want the PCC and child PCE to include this TLV in case they would like to use this PCEP extension, which includes various new information that can be encoded in PCReq from PCC towards the child PCE such as - RP object changes (section 3.2) and new OF codes and inclusion of TLV (section 3.3) etc. We would like this to be done on a PCEP session between PCC towards child PCE when we know that this child PCE understands the H-PCE extension as described in this document. The setting of P flag (parent PCE request bit) means that the PCEP speaker wants the peer to be a parent PCE, so in the case of PCC_Child-PCE both parties do not set the bit. Dan, maybe we should we spell this out more clearly? > I would replace this with, "A PCE MUST NOT include this TLV." > > You also, nicely, have >If both peers attempt to set the P flag then the session >establishment MUST fail, and the PCEP speaker MUST respond with PCErr >message using Error-Type 1: "PCEP Session Establishment Failure" as >per [RFC5440]. > Which catches one half of the 'race' condition. > I
Re: [Pce] New Version Notification for draft-ietf-pce-hierarchy-extensions-07.txt
Hi Dhruv, Authors, Thanks for -06 and -07 addressing comments, and -08 fixing the ToC. I have just been through the diffs comparing against my review comments. You seem to addressed most of my concerns, but not quite all of them. You also introduced a couple of new issues Thanks for the work, Adrian -- Fairy tales from North Wales brought to you for Christmas https://www.feedaread.com/profiles/8604/ Available from your favourite online bookseller. Or contact me to receive a signed copy by mail. === In 2.1.2 you now have " there is three new". s/is/are/ --- I don't think you have completely addressed my concerns in 2.2. In fact you have changed the text to say... A PCEP Speaker (Parent PCE or Child PCE or PCC) includes the "H-PCE Capability" TLV, described in Section 3.1.1, in the OPEN Object to advertise its support for PCEP extensions for H-PCE Capability. But the very next paragraph says only that " it would assist network operators if the child and parent PCEs could indicate their H-PCE capabilities." In other words, you have created a conflict. Either it is PCEs and PCCs that support this document MUST advertise that capability in the Open message, or it is RECOMMENDED. Maybe, in the first line s/includes/can include/ Or maybe (having re-read 3.1.1) you intend to go beyond 6805 section 4.8.2 and make the capabilities in the Open Message mandatory for H-PCE pairings. It would help if you were clear about this such as... OLD A PCEP Speaker (Parent PCE or Child PCE or PCC) includes the "H-PCE Capability" TLV, described in Section 3.1.1, in the OPEN Object to advertise its support for PCEP extensions for H-PCE Capability. Parent and child PCE relationships are likely to be configured. However, as mentioned in [RFC6805], it would assist network operators if the child and parent PCEs could indicate their H-PCE capabilities. NEW A PCEP Speaker (Parent PCE or Child PCE) that supports and wishes to use the procedures described in this document must advertise the fact and negotiate its role with its PCEP peers. It does this using the "H-PCE Capability" TLV, described in Section 3.1.1, in the OPEN Object to advertise its support for PCEP extensions for H-PCE Capability. END --- 3.1.1. is a lot better, thanks. You have... The inclusion of this TLV in an OPEN object indicates that the H-PCE extensions are supported by the PCEP speaker. The child PCE MUST include this TLV and set the P flag. The parent PCE MUST include this TLV and unset the P flag. The PCC MUST include this TLV to indicate that it understands the H-PCE extensions with P flag unset. The first two sentences are good: the function allows two PCEs to work out the direction of the relationship between them. However, I don't understand the final sentence. Why would a PCC need to indicate that it understands the H-PCE extensions? Given that it: - cannot be a parent PCE because it is not a PCE - cannot be a child PCE because it is not a PCE ...why would it ever indicate that it supports the H-PCE extensions? Actually, why would it ever be implemented to support those extensions? Furthermore, by including the TLV but not setting the P flag, it gives the impression that it is willing to be a parent PCE. I would replace this with, "A PCE MUST NOT include this TLV." You also, nicely, have If both peers attempt to set the P flag then the session establishment MUST fail, and the PCEP speaker MUST respond with PCErr message using Error-Type 1: "PCEP Session Establishment Failure" as per [RFC5440]. Which catches one half of the 'race' condition. I think you should add that, "If neither peer sets the P flag then the session establishment can proceed and the relationship between the PCEs continues as normal for cooperating PCEs." --- 3.1.1.1 is a bit week. You have two error conditions to handle: 1. What if the H-PCE-CAPABILITIES TLV is present in an Open Object and the receiver does not understand it? 2. What if H-PCE capabilities were not successfully negotiated, but some H-PCE feature is included in a later message? Both of these cases are certainly as you describe, but perhaps you need to be more explicit? Perhaps... OLD If the PCE does not understand an H-PCE path computation request as specified in this document, the PCE will ignore the H-PCE related parameters, and behave as per [RFC5440]. NEW Section 7.1 of [RFC5440] requires that "Unrecognized TLVs MUST be ignored." That means that a PCE that does not support this document but that receives an Open Message containing an Open Object that includes an H-PCE-CAPABILITIES TLV will ignore that TLV and will continue to attempt to establish a PCEP session. It will, however, not include the TLV in the Open message that it sends, so the H-PCE relationship will not be created. If a PCE does not support the extensions defined in this document but
[Pce] I-D Action: draft-ietf-pce-hierarchy-extensions-08.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE) Authors : Fatai Zhang Quintin Zhao Oscar Gonzalez de Dios Ramon Casellas Daniel King Filename: draft-ietf-pce-hierarchy-extensions-08.txt Pages : 27 Date: 2018-12-06 Abstract: The Hierarchical Path Computation Element (H-PCE) architecture is defined in RFC 6805. It provides a mechanism to derive an optimum end-to-end path in a multi-domain environment by using a hierarchical relationship between domains to select the optimum sequence of domains and optimum paths across those domains. This document defines extensions to the Path Computation Element Protocol (PCEP) to support Hierarchical PCE procedures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-hierarchy-extensions-08 https://datatracker.ietf.org/doc/html/draft-ietf-pce-hierarchy-extensions-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-hierarchy-extensions-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Spencer Dawkins' No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)
I think that for "bandwidth calendaring" we might reference 8413. I *think* "on-demand engineering" is simply the converse. That is, traffic engineering / path computation at the time of request for service delivery. That is "what we have always done" and might not qualify for a specific reference. But the authors will have a better view of what they meant Cheers, Adrian -- It's Christmas. Buy someone you love a book of fairy tales. https://www.feedaread.com/profiles/8604/ Available from your favourite online bookseller. Or contact me to receive a signed copy by mail. -Original Message- From: Pce On Behalf Of Spencer Dawkins Sent: 06 December 2018 04:38 To: The IESG Cc: pce@ietf.org; pce-cha...@ietf.org; draft-ietf-pce-segment-rout...@ietf.org Subject: [Pce] Spencer Dawkins' No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT) Spencer Dawkins has entered the following ballot position for draft-ietf-pce-segment-routing-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/ -- COMMENT: -- I can guess what This mechanism is useful in Software Defined Networking (SDN) applications, such as on-demand engineering, or bandwidth calendaring. means, but I'm guessing. Is there a reference for "on-demand engineering" or "bandwidth calendaring"? ___ 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] New Version Notification for draft-ietf-pce-hierarchy-extensions-07.txt
Doh! Indeedy, my script failed at the ToC generation! Will fix and upload a new version. BR, Dan. -Original Message- From: Dhruv Dhody Sent: 06 December 2018 14:21 To: Daniel King ; Farrel Adrian Cc: pce@ietf.org; Dhruv Dhody Subject: Re: [Pce] New Version Notification for draft-ietf-pce-hierarchy-extensions-07.txt Hi Daniel, Thanks for handling my comments, BTW page numbers are missing in the table of contents. Intrestingly that does not show up in id-nits [1] or mentioned in RFC style guide [2], but anyways page numbers in ToC are useful :) Hi Adrian, Are you happy with the resolution of your comments? Thanks! Dhruv [1] https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pce-hierarchy-extensions-07.txt [2] https://tools.ietf.org/html/rfc7322#section-4.7 On Thu, Dec 6, 2018 at 1:25 AM wrote: > > Dear PCE'rs, > > Please find a new version of draft-ietf-pce-hierarchy-extensions (07) > addressing comments from the most excellent Dhruv, our Document Shepherd. > > BR, Dan. > > -Original Message- > From: internet-dra...@ietf.org > Sent: 05 December 2018 19:53 > To: Oscar de Dios ; Daniel King ; Fatai > Zhang ; Oscar Gonzalez de Dios ; > Quintin Zhao ; Ramon Casellas > > Subject: New Version Notification for > draft-ietf-pce-hierarchy-extensions-07.txt > > > A new version of I-D, draft-ietf-pce-hierarchy-extensions-07.txt > has been successfully submitted by Daniel King and posted to the > IETF repository. > > Name: draft-ietf-pce-hierarchy-extensions > Revision: 07 > Title: Extensions to Path Computation Element Communication Protocol > (PCEP) for Hierarchical Path Computation Elements (PCE) > Document date: 2018-12-05 > Group: pce > Pages: 27 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-pce-hierarchy-extensions-07.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/ > Htmlized: > https://tools.ietf.org/html/draft-ietf-pce-hierarchy-extensions-07 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-pce-hierarchy-extensions > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-hierarchy-extensions-07 > > Abstract: >The Hierarchical Path Computation Element (H-PCE) architecture is >defined in RFC 6805. It provides a mechanism to derive an optimum >end-to-end path in a multi-domain environment by using a hierarchical >relationship between domains to select the optimum sequence of >domains and optimum paths across those domains. > >This document defines extensions to the Path Computation Element >Protocol (PCEP) to support Hierarchical PCE procedures. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > ___ > 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] New Version Notification for draft-ietf-pce-hierarchy-extensions-07.txt
Hi Daniel, Thanks for handling my comments, BTW page numbers are missing in the table of contents. Intrestingly that does not show up in id-nits [1] or mentioned in RFC style guide [2], but anyways page numbers in ToC are useful :) Hi Adrian, Are you happy with the resolution of your comments? Thanks! Dhruv [1] https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pce-hierarchy-extensions-07.txt [2] https://tools.ietf.org/html/rfc7322#section-4.7 On Thu, Dec 6, 2018 at 1:25 AM wrote: > > Dear PCE'rs, > > Please find a new version of draft-ietf-pce-hierarchy-extensions (07) > addressing comments from the most excellent Dhruv, our Document Shepherd. > > BR, Dan. > > -Original Message- > From: internet-dra...@ietf.org > Sent: 05 December 2018 19:53 > To: Oscar de Dios ; Daniel King ; Fatai > Zhang ; Oscar Gonzalez de Dios ; > Quintin Zhao ; Ramon Casellas > > Subject: New Version Notification for > draft-ietf-pce-hierarchy-extensions-07.txt > > > A new version of I-D, draft-ietf-pce-hierarchy-extensions-07.txt > has been successfully submitted by Daniel King and posted to the > IETF repository. > > Name: draft-ietf-pce-hierarchy-extensions > Revision: 07 > Title: Extensions to Path Computation Element Communication Protocol > (PCEP) for Hierarchical Path Computation Elements (PCE) > Document date: 2018-12-05 > Group: pce > Pages: 27 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-pce-hierarchy-extensions-07.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/ > Htmlized: > https://tools.ietf.org/html/draft-ietf-pce-hierarchy-extensions-07 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-pce-hierarchy-extensions > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-hierarchy-extensions-07 > > Abstract: >The Hierarchical Path Computation Element (H-PCE) architecture is >defined in RFC 6805. It provides a mechanism to derive an optimum >end-to-end path in a multi-domain environment by using a hierarchical >relationship between domains to select the optimum sequence of >domains and optimum paths across those domains. > >This document defines extensions to the Path Computation Element >Protocol (PCEP) to support Hierarchical PCE procedures. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > ___ > 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] Alvaro Retana's Discuss on draft-ietf-pce-segment-routing-14: (with DISCUSS and COMMENT)
Hi Alvaro Many thanks for these comments. I have read them, but need to have a discussion with my co-authors before I can answer them all. I hope to get back to you with a full reply early next week. Many thanks Jon -Original Message- From: Alvaro Retana Sent: Wednesday, 5 December, 2018 3:25 PM To: The IESG Cc: draft-ietf-pce-segment-rout...@ietf.org; Dhruv Dhody ; pce-cha...@ietf.org; pce@ietf.org Subject: Alvaro Retana's Discuss on draft-ietf-pce-segment-routing-14: (with DISCUSS and COMMENT) Alvaro Retana has entered the following ballot position for draft-ietf-pce-segment-routing-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/ -- DISCUSS: -- I am balloting DISCUSS because I think that there are some technical and clarity issues that makes understanding, and potentially implementing this document hard. I also want to discuss the "backwards compatibility" and the use of TLVs as sub-TLVs in PCEP as introduced in this document. (1) MSD Definition. The MSD may be learned from a variety of sources, including the SR-PCE-CAPABILITY sub-TLV defined in this document. It is important then for the MSD to be defined consistently everywhere. Please use the BMI-MSD definition from rfc8491. (2) Ability to signal the MSD per link, not just per node. Clearly the calculation of paths through specific links (using an Adjacency SID, for example) would require that information (if different/lower from what the node may support). Note that §6.1 seems to assume that the MSD will normally be advertised through different mechanisms, and it uses that to work around the fact that there's no link-specific information: "Furthermore, whenever a PCE learns the MSD for a link via different means, it MUST use that value for that link regardless of the MSD value exchanged in the SR-PCE-CAPABILITY sub-TLV." However, the text doesn't mandate the IGP/BGP-LS information to be available to the PCE. IOW, as written, the specification can't guarantee the proper calculation of paths that require the PCE to consider link MSDs. (3) Extensibility to advertise other MSD-Types. [This point is not DISCUSS-worthy, but I'm including it here since I'm already talking about the MSD.] rfc8491 (aka I-D.ietf-isis-segment-routing-msd) and I-D.ietf-ospf-segment-routing-msd encode the MSD advertisement as a pair: MSD-Type and MSD-Value, with the expectation that "new MSD-Types will be defined to signal additional capabilities, e.g., entropy labels, SIDs that can be imposed through recirculation, or SIDs associated with another data plane such as IPv6." IOW, the encoding is reusable with other dataplanes. I peeked into draft-negi-pce-segment-routing-ipv6 [*] and i don't see anything in there that couldn't be signaled using the SR-PCE-CAPABILITY sub-TLV defined here (+ the MSD_Value). I think this is important for consistency. [*] I realize that draft-negi-pce-segment-routing-ipv6 is not even a WG document, but it is the only potential reference I found to what a different dataplane might look line. (4) §6.2.2 (Interpreting the SR-ERO): o If the subobjects contain NAI only, then the PCC first converts each NAI into a SID index value by looking it up in its local database, and then proceeds as above. I believe that this step in the interpretation of the SR-ERO is not properly specified. Which "local database" are you referring to? §6.2.2.1 mentions the SR-DB (when talking about errors)...but the specification should be clear about which database and what the specific procedure is. For example, what is the specific process that the PCC needs to follow to convert a Node ID/IP address to the SID/MPLS label? What if the SR-DB doesn't contain an SID associated to the specific Node ID/IP address? How should the router react to that? This case is not covered in the Error Handling section (6.2.2.1) either. A pointer to the SR-DB (as defined in I-D.ietf-spring-segment-routing-policy) is not enough because it is composed of optional information (according to the description in §3 (Segment Routing Database)). This document should be specific about what information must be contained in the SR-DB for the conversion to be successful. The requirement of the information to be contained in the SR-DB makes I-D.ietf-spring-segment-routing-policy a Normative reference. (5) §7 (Backward Compatibility) "Some implementations, which are
