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 receives them in a PCEP message (notwithstanding the fact that the session was not established as supporting a H-PCE relationship), the receiving PCE will ignore the H-PCE related parameters because they are all encoded in TLVs within standard PCEP objects. END --- In 3.3.1 you fixed up MBN nicely so that I can understand it. Thanks. Except that you have made the description work well for IGP areas/levels and not so well for ASes. In other words, you cope well with the situation where the domain boundary is on the node, but not well when it is on the link. That is, to which domain does the inter-AS link belong? I should think that both ASes might consider it belongs to them and your algorithm might not count it at all. Alternatively, both might think it doesn't blong to them and you might count it twice. Aren't you actually trying to minimise domain transitions (which is different from MTD)? Wouldn't it be easier to say so? This especially since the Metric in 3.4 counts domains. I could re-draft the description of MBN in line with this if that would help, but I don't want to do that if I have misunderstood your objective to "minimise the number of domain transitions". BTW s/D(Lpi) if/D(Lpi) is/ --- I can now parse 3.3.2 to answer my original questions ("How do you handle an H-PCE OF that conflicts with a regular OF?"), but I wish you had made it clearer. Probably no further action on this point, but I am grumbling 😊 --- Finally, I think it is a shame to drop the Implementation Status information from the draft at this stage (i.e., before the IESG can see it). But I don't insist it is added back. -----Original Message----- From: Dhruv Dhody <[email protected]> Sent: 06 December 2018 14:21 To: Daniel King <[email protected]>; Farrel Adrian <[email protected]> Cc: [email protected]; Dhruv Dhody <[email protected]> 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 <[email protected]> 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: [email protected] <[email protected]> > Sent: 05 December 2018 19:53 > To: Oscar de Dios <[email protected]>; Daniel King <[email protected]>; Fatai > Zhang <[email protected]>; Oscar Gonzalez de Dios <[email protected]>; > Quintin Zhao <[email protected]>; Ramon Casellas > <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
