Hi Adrian, Thanks for your comments. I am the document shephered for this I-D, I will work with the authors and put out an update SOON :)
Regards, Dhruv On Mon, Sep 17, 2018 at 2:06 PM Adrian Farrel <[email protected]> wrote: > Authors, > > Thanks for this draft: it describes function for which there are clear > requirements. Section 9 is very helpful in assessing the practicality > of these protocol extensions. > > Apologies for not having reviewed this earlier in the cycle, it's not > something I have an implementation for. > > I have quite a catalogue of comments, but in view of the existing > implementations it would be acceptable for you to respond to some of > them with: "We could have done it like that, but what we have documented > has been proven to work and there are implementations." > > Thanks for the work. > > Adrian > > --- > > Per idnits, RFC 5226 has been replaced by RFC 8126 > > --- > > Abstract > > OLD > The Hierarchical Path Computation Element (H-PCE) architecture RFC > 6805, provides a mechanism to allow the optimum sequence of domains > to be selected, and the optimum end-to-end path to be derived through > the use of a hierarchical relationship between domains. > > This document defines the Path Computation Element Protocol (PCEP) > extensions for the purpose of implementing necessary Hierarchical PCE > procedures and protocol extensions. > NEW > 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. > END > > --- > > 1. > > OLD > The Path Computation Element communication Protocol (PCEP) provides > mechanisms for Path Computation Elements (PCEs) to perform path > computations in response to Path Computation Clients' (PCCs) > requests. > NEW > The Path Computation Element communication Protocol (PCEP) provides > a mechanism for Path Computation Elements (PCEs) and Path Computation > Clients (PCCs) to exchange requests for path computation and > responses that provide computed paths. > END > > --- > > 1.1 > > You might find RFC 7399 a useful reference in this section. > > --- > > 2. and sub-sections > > I don't think the use of 8174 language in these sections is necessary. > > --- > > 2.1.2 > > s/objective Function/Objective Function/ *2 > s/objective function/Objective Function/ *5 > > --- > > 2.1.2 has > > For inter-domain path computation, there is one new objective > Function which is defined in section 1.3.1 and 4.1 of [RFC6805]: > > o Minimize the number of domains crossed. A domain can be either an > Autonomous System (AS) or an Internal Gateway Protocol (IGP) area > depending on the type of multi-domain network hierarchical PCE is > applied to. > > Another objective Function to minimize the number of border nodes is > also defined in this document. > > So the first line must be wrong because the second paragraph defines a > second OF. But section 3.3 defines 3 new OFs (although it claims to only > define 2). > > I'll defer my discussion of the OFs themselves to section 3.3. > > --- > > 2.1.2 > > There may be a few too many words in this section since mainly it > describes how PCEP already carries OFs. Apart from the new OF codes and > the final paragraph, there doesn't seem to be any new requirement in > this section. > > Not saying this is a requirement to change the text, but it might be > nice to prune it a bit. > > --- > > 2.1.2 > > A parent PCE MUST be capable of ensuring homogeneity, across domains, > when applying OF codes for strict OF intra-domain requests. > > I am not completely sure what this means. You might be saying that the > OFs must be interpreted in the same way in each domain. Sounds good, but > how can a parent PCE ensure that? And why would a domain be trusted? > > --- > > 2.2 goes further than 6805 section 4.8.2. 6805 does not suggest that the > child PCE needs to make any indication in its Open message. > > Everything is good (including the section title!) except for the > inclusion of the following sentence. > > During the PCEP session establishment procedure, the child PCE needs > to be capable of indicating to the parent PCE whether it requests the > parent PCE capability or not. > > This seems peculiar and unnecessary as follows: > - If a PCE is capable of being a parent for a specific child it will > say so in its Open message to that child, and it will be willing to > receive H-PCE requests from that child. > - A child PCE can only send H-PCE requests to another PCE if that PCE > has indicated that it is a parent. > - Requesting another PCE to be a parent will not change its capabilities > or willingness. > - Requests sent by a parent PCE to another PCE are (should be) > indistinguishable from requests sent by any PCC to that PCE. So there > is no need to register any capabilities in this regard. > > (BTW - I'm seriously wishing you had called this the "Are you my mummy?" > function.) > > --- > > 2.3. Do you mean "PCE Domain Discovery" or "PCE Domain Identification"? > > The section does talk about identifiers, but not about discovery. > > --- > > 3. > > OLD > This section defines PCEP extensions to ([RFC5440]) so as to support > the H-PCE procedures. > NEW > This section defines extensions to PCEP [RFC5440] to support the > H-PCE procedures. > END > > --- > > 3.1.1 > > Per my comment on 2.2, I don't believe there is a need for the R-flag. > > Furthermore, if there's no need for the R-flag (assume it is removed) > then the I-flag would always be set when the TLV is present. So, if the > R-flag is removed, then the I-flag can be removed, too. > > --- > > 3.1.1 > > s/indicate that/indicates that/ > s/parent PCE receive/parent PCE receives/ > > --- > > 3.1.1 > > If such capability is not exchanged and the parent PCE receive a "H- > PCE path computation request", it MUST send a PCErr message with > Error-Type=TBD8 (H-PCE error) and Error-Value=1 (Parent PCE > Capability not advertised). > > This isn't how backward compatibility works. True that an H-PCE-capable > PCE that doesn't want to support H-PCE communications with a peer could > return this error, but a legacy PCE will not be able to return this new > error type (because it doesn't support H-PCE). > > Probably the way to handle this is: > - add a new section (towards the end) called "Backward Compatibility" > - point to that from 3.1.1 for "PCE's that don't support H-PCE > extensions as defined in this document" > > --- > > 3.1.2 > s/domain(s)/domains/ > > --- > > 3.2.2 > > Does the use of the Domain-id TLV in the RP object open us up to a new > error code if the destination is not actually in the indicated domain? > > --- > > 3.3.1 contains three new OFs, not two as the text says. > > You need to format the text so all of the bullets are consistent. > > "the H-PCE experiment" Maybe not an experiment? > > --- > > 3.3.1 MTD > > I think you should clarify the way domains are counted. Specifically, > it appears from your algorithm that domain re-entry does not increment > the count of domains. It is worth making this point explicitly. > > --- > > 3.3.1 MBN > > This is slightly hard to be clear about. > > AS1 : AS2 > : > A---B---C===D > | : > | : > E : > > Consider the path ABCE. C is an ASBR. C is on the path, but is not used > as a border node. Should it be counted? Your algorithm says so. > > Is the count of border nodes intended to minimise domains *and* minimise > (while still allowing) domain re-entry? > > --- > > 3.3.1 MCTD could usefully also have an "Objective" since it explains > things so much more clearly. > > Currently the description is ambiguous: > > o Description: Find a set of paths such that it passes through the > least number of common transit domains. > > This could mean "aim to common transit domains, but reduce the number" > or "aim to not have common transit domains." > > BTW s/least/fewest/ > > --- > > 3.3.2 describes how to include multiple OFs for an H-PCE computation. > This function is needed as the new OFs are supplementary to pre-existing > OFs. However, there are some issues: > > 1. The normal path OF could be in conflict with the H-PCE OF. > Consider the path OF asking for least cost (MCP) and the H-PCE OF > asking for fewest transit domains (MTD). Now consider... > ................ ....................... > : : : : > : src---A---B--------C---D---E---F---dst : > : | : : | : > :...........|... ..............|.......: > | | > ..|....................|... > : | | : > : X--------------------Y : > : : > :.........................: > > ABXYF is a lower cost path, but invokes an extra domain. How is this > resolved? > > 2. The structure of the OF object allows TLVs to be included to qualify > the OF (more example metrics). Now if you are allowing additional OFs > to be present in an OF-list TLV, there is a question about how you > carry additional TLVs for those TLVs (understanding that you may have > to tightly bind the additional TLVs to one OF and not to another). > > 3. As you note, 5541 indicates that only one OF can be present. This is > (presumably?) to avoid conflicting or contradictory OFs. Now that you > allow two OFs to be present you need to say something to stop the > presence of two competing (pre-existing) OFs. You could (probably?) > say that only H-PCE OFs may be present in one place, and only non-H- > PCE OFs in the other place. > > 4. Had you considered using multiple OF objects? > > --- > > 3.4 > > Does the domain count include the source and destination domains? Does > it count a domain twice if the domain is re-entered? > > --- > > 3.4 > > The two paragraphs about the B-flag, don't add anything beyond 5440, do > they? > > --- > > 3.5 > > s/proposes/defines/ > > --- > > 4.1 has > > When a specific child PCE sends a PCReq to a peer PCE that requires > parental activity and the peer PCE does not want to act as the parent > for it, the peer PCE should send a PCErr message to the child PCE and > specify the error-type=TBD (H-PCE error) and error-value=2 (parent > PCE capability cannot be provided) in the PCEP-ERROR object. > > while 7.7 has > > Error-value=2 Parent PCE > Capability not supported > > The name in 7.7 may be closer to the "does not want" idea in 4.1. > > --- > > 4.2. Procedure to obtain Domain Sequence > > s/obtain/Obtain/ > > It would be good to clarify whether the sequence of domains has been > verified to provide a path. The difference lies in whether the parent > PCE only looks at the domain interconnection, or consults the child > PCEs. > > --- > > 7.3 > > You need to specify the IANA allocation policy > > --- > > 7.9 > s/TBD13/TBD12/ > > --- > > 8. > Any reason why you mention TCP-AO without a reference to 5926 > > --- > > > > -----Original Message----- > > From: Pce [mailto:[email protected]] On Behalf Of Julien Meuric > > Sent: 06 September 2018 16:32 > > To: [email protected] > > Subject: [Pce] WG Last Call for draft-ietf-pce-hierarchy-extensions > > > > Hi all, > > > > This message initiates a 2-week WG last call for > > draft-ietf-pce-hierarchy-extensions-05. Please review and share your > > feedback on the PCE mailing list. This LC will end on Thursday > > September, 20. > > > > Regards, > > > > Jon & Julien > > > > _______________________________________________ > > Pce mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
