Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)
Shuping: Hi! The changes look good to me. Thanks! Alvaro. On February 26, 2021 at 5:10:41 AM, Pengshuping (Peng Shuping) ( pengshup...@huawei.com) wrote: Thank you for your comments! Please find the diff and the responses in line below. Thank you! ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-association-bidir-12: (with COMMENT)
Rakesh: Hi! This new text works for me. Thanks! Alvaro. On February 19, 2021 at 4:39:48 PM, Rakesh Gandhi (rgandhi) ( rgan...@cisco.com) wrote: Thank you Alvaro for the review comments. We have added a Section 3.5 - Operational Considerations in the new revision to address the comment. URL: https://www.ietf.org/archive/id/draft-ietf-pce-association-bidir-13.txt Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-bidir-13 Please advise your feedback on this. Thanks, Rakesh *From: *Pce on behalf of Alvaro Retana via Datatracker *Date: *Tuesday, February 16, 2021 at 8:37 AM *To: *The IESG *Cc: *draft-ietf-pce-association-bi...@ietf.org < draft-ietf-pce-association-bi...@ietf.org>, pce@ietf.org , pce-cha...@ietf.org *Subject: *[Pce] Alvaro Retana's No Objection on draft-ietf-pce-association-bidir-12: (with COMMENT) Alvaro Retana has entered the following ballot position for draft-ietf-pce-association-bidir-12: 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-association-bidir/ -- COMMENT: -- This document defines extensions that can be used in different modes of operation (§3.4). However, there is no operational guidance related to the advantages/disadvantages or considerations of using each of them. Are there cases (beyond implementation support) when one mode could be preferred? If all modes are supported, how should an operator choose? I believe that the specification is incomplete without this type of guidance, but I am not making this point a DISCUSS hoping that it will be easy for the authors to address. ___ 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] Alvaro Retana's No Objection on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)
Alvaro Retana has entered the following ballot position for draft-ietf-pce-pcep-extension-for-pce-controller-12: 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-pcep-extension-for-pce-controller/ -- COMMENT: -- (0) The fact that the procedures (§5) are presented before introducing the messages/objects (§6-7) makes reading this document harder and more complex than it has to be. Consider changing the order or at least adding forward references in §5. (1) §5.2: Is there a reason for the messages from rfc8231 to be in parenthesis? (2) §5.4: The PCECC-CAPABILITY sub-TLV SHOULD NOT be used without the corresponding Path Setup Type being listed in the PATH-SETUP-TYPE- CAPABILITY TLV. If it is present without the corresponding Path Setup Type listed in the PATH-SETUP-TYPE-CAPABILITY TLV, it MUST be ignored. When is it ok to use the PCECC-CAPABILITY sub-TLV without the corresponding PST? If the result is that it will be ignored, then I don't understand why the use of both is not required. (3) §5.5.1/§5.5.4: "ingress MAY further choose to deploy a data plane check mechanism and report the status back to the PCE" Is this (checking and reporting) specified somewhere? Because you're using normative language, please add a reference. A similar statement is made in §5.5.7: "ingress PCC MAY choose to apply any OAM mechanism to check the status of LSP in the Data plane and MAY further send its status in a PCRpt message to the PCE". (4) §5.5.3: s/central controller instructions...is done/central controller instructions...are done (5) §5.5.8: "The PCC SHOULD allocate the Label and SHOULD report to the PCE using the PCRpt message." When is it ok for the PCC to not allocate and/or report? IOW, why are these actions only recommended and not required? Note that the very next paragraph requires the behavior. (6) §7.3/§7.3.1: In the out-label case, "it is mandatory to encode the next-hop information". Should this information point at a directly connected IP address/interface, or can it point at a remote next-hop (which may be resolved through a routing protocol)? What if the expected conditions are not met? ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Alvaro Retana's No Objection on draft-ietf-pce-association-bidir-12: (with COMMENT)
Alvaro Retana has entered the following ballot position for draft-ietf-pce-association-bidir-12: 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-association-bidir/ -- COMMENT: -- This document defines extensions that can be used in different modes of operation (§3.4). However, there is no operational guidance related to the advantages/disadvantages or considerations of using each of them. Are there cases (beyond implementation support) when one mode could be preferred? If all modes are supported, how should an operator choose? I believe that the specification is incomplete without this type of guidance, but I am not making this point a DISCUSS hoping that it will be easy for the authors to address. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] FW: I-D Action: draft-ietf-pce-pcep-flowspec-11.txt
Hi Adrian! I looked at the diffs and I’m happy with the changes. I’m clearing. Thanks! Alvaro. On October 5, 2020 at 10:35:22 AM, Adrian Farrel (adr...@olddog.co.uk) wrote: Alvaro and Ben, Very sorry for delaying this progress so much and possibly causing your cache not only to be flushed, but the archive tapes sent to the fire-vault in Utah. The last issue you had remaining was that 5575bis has removed the possibility of multiple Flow Specification components of the same type being present in one flow specification. We have aligned with this with two changes: - Added text to Section 7 saying: As described in [I-D.ietf-idr-rfc5575bis] where it says "A given component type MAY (exactly once) be present in the Flow Specification," a Flow Filter TLV MUST NOT contain more than one Flow Specification TLV of the same type: an implementation that receives a PCEP message with a Flow Filter TLV that contains more than one Flow Specification TLV of the same type MUST respond with a PCErr message with error-type TBD8 (FlowSpec Error), error-value 2 (Malformed FlowSpec) and MUST NOT install the Flow Specification. - Section 8.4 has been rewritten to mainly say "use separate Flow Specification Objects for separate flow specifications" This -11 revision picks up all other outstanding comments and nits. Best, Adrian -Original Message- From: I-D-Announce On Behalf Of internet-dra...@ietf.org Sent: 05 October 2020 15:27 To: i-d-annou...@ietf.org Cc: pce@ietf.org Subject: I-D Action: draft-ietf-pce-pcep-flowspec-11.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 : PCEP Extension for Flow Specification Authors : Dhruv Dhody Adrian Farrel Zhenbin Li Filename : draft-ietf-pce-pcep-flowspec-11.txt Pages : 37 Date : 2020-10-05 Abstract: The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering network. These paths may be supplied in response to requests for computation, or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path. Traffic flows may be categorized and described using "Flow Specifications". RFC defines the Flow Specification and describes how Flow Specification Components are used to describe traffic flows. RFC also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. This document specifies a set of extensions to PCEP to support dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. The extensions defined in this document include the creation, update, and withdrawal of Flow Specifications via PCEP, and can be applied to tunnels initiated by the PCE or to tunnels where control is delegated to the PCE by the PCC. Furthermore, a PCC requesting a new path can include Flow Specifications in the request to indicate the purpose of the tunnel allowing the PCE to factor this into the path computation. RFC Editor Note: Please replace in the Abstract with the RFC number assigned to draft-ietf-idr-rfc5575bis when it is published. Please remove this note. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-flowspec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-pcep-flowspec-11 https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-flowspec-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-flowspec-11 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/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-pcep-flowspec-10: (with DISCUSS and COMMENT)
Hi! Adrian mentioned this in a separate message…just repeating it here to close the loop with everyone. rfc5575bis allows only one component of a given type to be included in the description of the FlowSpec…which means that there is no need for AND/OR operations between them. There’s no change needed in rfc5575bis…but this document needs to be cleaned up to remove the ability of multiple components of the same type. Thanks! Alvaro. On August 26, 2020 at 5:53:54 PM, Benjamin Kaduk (ka...@mit.edu) wrote: On Wed, Aug 26, 2020 at 10:48:41PM +0100, Adrian Farrel wrote: > > Responding to just the Discuss portion due to time constraints before the > > telechat... > > Understood > > Top posting: > > This really feels like a problem for 5575bis. I'm beginning to think we > overstepped by even mentioning it in this document. I wanted to draw out the > risks and confusions (almost to say "don't do that") without trampling on > existing practice or messing with BGP. This is (clearly?) not the document > to tell people how to manage their BGP FlowSpecs, yet we wanted to inherit > as much as possible from BGP, yet we don't want people to damage themselves, > yet the scissors are sharp and they enjoy running. > > You paragraph of suggestions of pointers of how/when to do AND and OR is a > reasonable starting point. But surely it is something that belongs in > 5575bis? I suspect you are right... Alvaro, what do you think? -Ben ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Alvaro Retana's Discuss on draft-ietf-pce-pcep-flowspec-10: (with DISCUSS)
On August 27, 2020 at 6:30:41 AM, Adrian Farrel wrote: Adrian: Hi! > I think there are three points we can work on to add to the document: > 1. PCEP-installed FlowSpecs MUST NOT be redistributed to other routers > using BGP. Just to be clear, redistributing PCEP FS was never the intent. Are there cases where PCEP information is redistributed into a routing protocol? If not, then I don't think this first point is necessary. > 2. PCEP-installed FlowSpecs are intended to be installed only at the > head-end of the LSP to which they direct traffic. It is acceptable (and > potentially desirable) that other routers have FlowSpecs that match the > same traffic but direct it onto different routes or to different LSPs. ok > 3. Note that changes to the wider routing system (such as the distribution > and installation of BGP FlowSpecs, or fluctuations in the IGP link state > database) might mean that traffic matching the PCEP FlowSpec never reaches > the head end of the LSP at which the PCEP FlowSpec is installed. This may > or may not be desirable according to the operator's traffic engineering and > routing policies, but it is not an effect that this document seeks to > address. That is what I'm looking for: a mention of the potential... Thanks! Alvaro. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Alvaro Retana's Discuss on draft-ietf-pce-pcep-flowspec-10: (with DISCUSS)
On August 26, 2020 at 5:25:20 PM, Adrian Farrel wrote: Adrian: Hi! ... > > The concern I have is that in BGP's distribution model FlowSpecs are > > forwarded to other BGP speakers...which may not also be PCCs. If PCEP > > takes precedence, and the actions are different, then there might be > > nodes that take the BGP-defined action when not intended to...potentially > > resulting in unexpected forwarding or rate-limiting of the traffic. > > > > Clearly, this issue is related to the different distribution models for > > the information. If the operator took care of using BGP to distribute > > FlowSpecs to only the PCCs, then this issue wouldn't exist. I would like > > to see some text that provides guidance when using both distribution > > mechanisms. > > This is a worthy Discuss! > > My understanding of the way that BGP FlowSpecs work is that it is not > required that they be identical at different BGP routers. Indeed, part of > the point is that different flows are treated differently at different > routers. Right. That is not my concern; I wasn't clear enough. As you know, there are multiple ways of setting up distribution of FlowSpec in BGP. One way is to have point-to-point BGP sessions from a central box to specific routers where the actions are to be applied -- limiting the distribution to just those BGP speakers. In this case, the FlowSpecs/Actions will likely be different (as you describe). I'm not concerned about that case. Let me try again. rfc5575bis says this: From an operational perspective, the utilization of BGP as the carrier for this information allows a network service provider to reuse both internal route distribution infrastructure (e.g., route reflector or confederation design) and existing external relationships (e.g., inter-domain BGP sessions to a customer network). By reusing the "internal route distribution infrastructure", the FlowSpecs are advertised, for example, from the originator to a route reflector to its clients -- and maybe even further (consider a hierarchical RR deployment). Note that this type of distribution is "normal" BGP, not specific to FlowSpec. In this case, the FlowSpecs are the same everywhere -- there may not be traffic that matches, but they are the same (modulo local policy). Assume distribution through a RR, and locating the LSP headend at the RR (= PCC). If traffic comes into the network through the clients, it will first be matched against the BGP FlowSpec...even if PCEP has precedence over BGP at the RR/PCC. IOW, the traffic would first be subject to the action advertised by BGP before the PCC can act on it. Is this explanation clearer? Note that in some cases this type of setup may be what the operator wants: maybe the intent is to rate limit (some of) the traffic (at the client using BGP) and then let the headend put it in a specific LSP (using PCEP). I think this document doesn't cover the potential downside of using different distribution models. It might not be evident to everyone that the BGP information may be propagated further. Thanks! Alvaro. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Alvaro Retana's Discuss on draft-ietf-pce-pcep-flowspec-10: (with DISCUSS and COMMENT)
Alvaro Retana has entered the following ballot position for draft-ietf-pce-pcep-flowspec-10: 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-pcep-flowspec/ -- DISCUSS: -- §8.7: "it is possible that Flow Specifications will be distributed by BGP as well as by PCEP as described in this document...implementations MAY provide a configuration control to allow one protocol to take precedence over the other as this may be particularly useful if the Flow Specification make identical matches on traffic but have different actions." I understand the need to allow one protocol to take precedence over the other. The concern I have is that in BGP's distribution model FlowSpecs are forwarded to other BGP speakers...which may not also be PCCs. If PCEP takes precedence, and the actions are different, then there might be nodes that take the BGP-defined action when not intended to...potentially resulting in unexpected forwarding or rate-limiting of the traffic. Clearly, this issue is related to the different distribution models for the information. If the operator took care of using BGP to distribute FlowSpecs to only the PCCs, then this issue wouldn't exist. I would like to see some text that provides guidance when using both distribution mechanisms. -- COMMENT: -- [major comments] (1) What is the number/type of Flow Filter TLVs that can be included in the PCEP FLOWSPEC option? Is it up to one of each, or just one or the other? These text snippets seem to not be aligned: §3.2.2: "The PCEP FLOWSPEC object carries zero or one Flow Filter TLV or one L2 Flow Filter TLV or both Flow Filter TLV as well as L2 Flow Filter TLV, which describes a traffic flow." §6: "Only one Flow Filter TLV or L2 Flow Filter TLV can be present and represents the complete definition of a Flow Specification for traffic to be placed on the tunnelThe set of Flow Specification TLVs in a single instance of a Flow Filter TLV and L2 Flow Filter TLV are combined to indicate the specific Flow Specification. Note that the PCEP FLOWSPEC object can include just one Flow Filter TLV, just one L2 Flow Filter TLV, or one of each TLV." §7.1: "when both Flow Filter TLV and L2 Flow Filter TLV are present, they are combined to produce a more detailed specification of a flow" That first sentence from §6 indicates one or the other, but the other text talks about the possibility of both. If they are combined, how is that done? (2) Entity Identifier §5: The Speaker Entity Identifier TLV can be optionally included in the OPEN [rfc8232]...and it is required in the FLOWSPEC object. Should there be a relationship between the two? If the TLV is included in both objects, then I would expect the identifier to match. What should the receiver do if they don't match? Related... Should a receiver check that the same identifier is included in all FLOWSPEC objects? What if they're not? (3) §5: "All subsequent PCEP messages can identify the FlowSpec using the FS-ID." [This point is related to Ben's DISCUSS.] The description of the use of the Speaker Entity Identifier TLV says that it is "used in conjunction with FS-ID to uniquely identify the FlowSpec information." I take this to mean that the FS-ID *and* the identifier in the TVL are used in the identification. Is that correct? The text in §5 also talks about using only the FS-ID: "the Flow Specification identified with a FS-ID does not exist". And §8.3 emphasizes it again: "FS-ID field of the PCEP FLOWSPEC object is used to identify a specific Flow Specification". If only the FS-ID is needed, what is the Speaker Entity Identifier used for? (4) §8.4: "it is possible to to define these within a single PCEP FLOWSPEC object: for example, two Destination IPv4 Prefix TLVs could be included to indicate that packets matching either prefix are acceptable." Two Destination Prefix TLVs would be equivalent to two Type 1 components in a BGP FS, but that is not allowed by rfc5575bis. This document follows the same rules as in rfc5575bis -- is this an exception that I missed? It may just be a bad example... (5) §8.5: If the R bit is set and Flow Specification TLVs are present, an implementation MAY ignore them. If the
Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT)
On July 22, 2020 at 12:25:00 AM, Dhruv Dhody wrote: Dhruv: Hi! ... > > > (2) §4.1: "a PCE MUST synchronize to other PCEs within the > > > network...Which way is used to achieve this is out of scope for this > > > document." If the synchronization mechanism is out of scope, how can > > > an implementation be compliant with this specification? IOW, if > > > there's nothing to normatively refer to, then normative language > > > shouldn't be used, or a mechanism should be mandated. In either case, > > > because synchronization between the PCEs seems important for this > > > specification, I would like to also see a discussion about the specific > > > effects on LSP scheduling instead of the generic pointer to rfc7399. > > > > > > [HC]: The description related seems too broad. We have rephrased > > > the related text to focus on the state of a scheduled LSP > > > crossing multiple domains from an ingress domain to an egress domain. > > ... > > > > > > As mentioned separately...I think that changing the scenario is not a > > good idea at this point. It also leaves the single domain case > > unaddressed. > > > > > > I suggested making these changes in section 4.1 - > > In case of multiple PCEs within a single domain, the PCE would need > to synchronize their scheduling information with other PCEs > within the domain. This could be achieved by proprietary database > synchronization techniques or via a possible PCEP extension > [I-D.litkowski-pce-state-sync]. The technique used to synchronize > SLSP-DB is out of scope for this document. > > Also, update section 4.3 with - > > o The stateful PCE MUST update its local scheduled LSP-DB and > scheduled TED with the scheduled LSP and synchronize the > scheduling information with other PCEs in the domain. Those changes are ok. If no normative reference will be included, then I would still like to see a discussion about the effects of not synchronizing, in this specific case. The text in rfc7399 is general. > > > §4.3 says that the "stateful PCE...shall send a PCRpt message with the > > > scheduled LSP to other PCEs...to achieve...synchronization." Even > > > though normative language is not used, the intent seems to > > > specifically point at using PCRpt messages for synchronization... > > > > > > Besides the confusing use of language, rfc8231 defines PCRpt as a > > > "message sent by a PCC to a PCE to report the current state of an LSP", > > > but I didn't see where the use if defined between PCEs -- maybe I > > > missed it. §6.1 does reinforce that the "Path Computation State Report > > > (PCRpt) is a PCEP message sent by a PCC to a PCE to report the status > > > of one or more LSPs as per [RFC8231]This message is also used to > > > synchronize the scheduled LSPs to other PCE as described in [RFC8231]". > > > But this last point is what I can't find in rfc8231. > > > > > > [HC]: We have updated/cleaned the text related. > > > The Path Computation State Report (PCRpt) is a PCEP message sent by > > > a PCC to a PCE as per [RFC8231]. A PCE can act as a PCC to send a PCRpt > > > message to another PCE. > > > > The "as described in [RFC8231]" text is still not accurate -- that > > document doesn't talk about using the PCRpt message between PCEs. > > > > I don't think that the "PCE can act as a PCC" part is well defined. > > Is it specified somewhere else? > > > > In this case, the right reference is draft-litkowski-pce-state-sync to > synchronize between PCEs using PCRpt/PCUpd. This goes back to the initial point: should draft-litkowski-pce-state-sync be the normative reference? If not, then I think it is best to leave the details out. > My suggestion would be to change the text in Section 6.1 (version -19) > OLD: > This message is also used > to synchronize the scheduled LSPs to other PCE as described in > [RFC8231] > NEW: > This message could also be used > to synchronize the scheduled LSPs to other PCE as described in > [I-D.litkowski-pce-state-sync]. > END > > I can even live with removing the text completely. If removing it, since the suggestion above is not leave sync completely out of scope, then remove all other talk about PCRpt... > BTW, just for information - PCE acting as PCC and using PCReq message > towards other PCEs goes back to RFC 5441. RFC 8751 has a child PCE > acting as PCC and sending PCRpt messages to parent PCE. But that has > no bearing on the fate of the above text. No it doesn't. But if there is a reference to include... In the end, my interest here is for the specification to be complete. If sync is out of scope then leave it out -- and better discuss the effects of not properly sync'ing. If it can be specified here (or normatively pointed at), then please do it. :-) Thanks! Alvaro. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT)
On July 13, 2020 at 3:29:13 PM, Huaimo Chen wrote: Huaimo: Hi! ... > -- > COMMENT: > -- > I think that this document still needs work before publication. I consider > the first 3 points below to be close to DISCUSS-worthy. > > (1) In general, it feels like an editorial pass is needed to tighten up the > language used as specification in this document. There are several places > where the language feels loose -- as an example (from §4.4): ... > [HC]: We have updated the document according to rfc2119 as you suggested. Thanks for addressing this one instance. As I mentioned, there are other similar instances that would benefit from similar tightening up -- please reread through the document with an eye for "loose language". I trust that you will do the right thing. > (2) §4.1: "a PCE MUST synchronize to other PCEs within the network...Which > way is used to achieve this is out of scope for this document." If the > synchronization mechanism is out of scope, how can an implementation be > compliant with this specification? IOW, if there's nothing to normatively > refer to, then normative language shouldn't be used, or a mechanism should > be mandated. In either case, because synchronization between the PCEs seems > important for this specification, I would like to also see a discussion > about the specific effects on LSP scheduling instead of the generic pointer > to rfc7399. > > [HC]: The description related seems too broad. We have rephrased > the related text to focus on the state of a scheduled LSP > crossing multiple domains from an ingress domain to an egress domain. ... As mentioned separately...I think that changing the scenario is not a good idea at this point. It also leaves the single domain case unaddressed. > §4.3 says that the "stateful PCE...shall send a PCRpt message with the > scheduled LSP to other PCEs...to achieve...synchronization." Even though > normative language is not used, the intent seems to specifically point at > using PCRpt messages for synchronization... > > Besides the confusing use of language, rfc8231 defines PCRpt as a "message > sent by a PCC to a PCE to report the current state of an LSP", but I didn't > see where the use if defined between PCEs -- maybe I missed it. §6.1 does > reinforce that the "Path Computation State Report (PCRpt) is a PCEP message > sent by a PCC to a PCE to report the status of one or more LSPs as per > [RFC8231]This message is also used to synchronize the scheduled LSPs to > other PCE as described in [RFC8231]". But this last point is what I can't > find in rfc8231. > > [HC]: We have updated/cleaned the text related. > The Path Computation State Report (PCRpt) is a PCEP message sent by > a PCC to a PCE as per [RFC8231]. A PCE can act as a PCC to send a PCRpt > message to another PCE. The "as described in [RFC8231]" text is still not accurate -- that document doesn't talk about using the PCRpt message between PCEs. I don't think that the "PCE can act as a PCC" part is well defined. Is it specified somewhere else? > (3) This whole document is about scheduling LSPs, which would seem to require > time synchronization. However, I found only one mention: "It is necessary to > synchronize the clocks of the PCEs and PCCs when relative time is used." > Should this sentence use normative language? Is there a recommended way to > achieve time synchronization? This seems to be an important manageability > consideration that impacts network operations. > > [HC]: Yes. We have changed it to use normative language, and > recommended Network Time Protocol [RFC5905] for time synchronization. The reference should be Normative. Thanks! Alvaro. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT)
Alvaro Retana has entered the following ballot position for draft-ietf-pce-stateful-pce-lsp-scheduling-19: 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-stateful-pce-lsp-scheduling/ -- COMMENT: -- I think that this document still needs work before publication. I consider the first 3 points below to be close to DISCUSS-worthy. (1) In general, it feels like an editorial pass is needed to tighten up the language used as specification in this document. There are several places where the language feels loose -- as an example (from §4.4): In PCC-Initiated case, the PCC can send a PCRpt message for the scheduled LSP with updated parameters as well as scheduled information included in the SCHED-LSP-ATTRIBUTE TLV (see Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2) carried in the LSP Object. The PCE would take the updated resources and schedule into considerations and update the new path for the scheduled LSP to the PCC as well as synchronize to other PCEs in the network. In case path cannot be set based on new requirements, the previous LSP will not be impacted and the same should be conveyed by the use of empty ERO in the PCEP messages. "the PCC can send" Does it have to? If the information is not sent, then the PCE will not be able to calculate the path, so something stronger than "can" seems to be needed. "PCE would take" Does this mean that it is optional? I can imagine how the PCE may have local policies affecting the action...but I shouldn't have to imagine anything. "should be conveyed" Again, do you have to? Are there cases when it is ok not to do it? Not everything needs rfc2119 key words, but in some cases they would help. In this case, I can see a couple of variations possible. rfc2119> ...the PCC MUST send...the PCE SHOULD take...MUST be conveyed... non-rfc2119> ...the PCC sends...the PCE takes...is conveyed... (2) §4.1: "a PCE MUST synchronize to other PCEs within the network...Which way is used to achieve this is out of scope for this document." If the synchronization mechanism is out of scope, how can an implementation be compliant with this specification? IOW, if there's nothing to normatively refer to, then normative language shouldn't be used, or a mechanism should be mandated. In either case, because synchronization between the PCEs seems important for this specification, I would like to also see a discussion about the specific effects on LSP scheduling instead of the generic pointer to rfc7399. §4.3 says that the "stateful PCE...shall send a PCRpt message with the scheduled LSP to other PCEs...to achieve...synchronization." Even though normative language is not used, the intent seems to specifically point at using PCRpt messages for synchronization... Besides the confusing use of language, rfc8231 defines PCRpt as a "message sent by a PCC to a PCE to report the current state of an LSP", but I didn't see where the use if defined between PCEs -- maybe I missed it. §6.1 does reinforce that the "Path Computation State Report (PCRpt) is a PCEP message sent by a PCC to a PCE to report the status of one or more LSPs as per [RFC8231]This message is also used to synchronize the scheduled LSPs to other PCE as described in [RFC8231]". But this last point is what I can't find in rfc8231. (3) This whole document is about scheduling LSPs, which would seem to require time synchronization. However, I found only one mention: "It is necessary to synchronize the clocks of the PCEs and PCCs when relative time is used." Should this sentence use normative language? Is there a recommended way to achieve time synchronization? This seems to be an important manageability consideration that impacts network operations. (4) rfc8413 should be a Normative reference because it "provides a framework that describes and discusses the problem, and defines an appropriate architecture for the scheduled reservation of TE resources", which is the basis for the extensions defined in this document. (5) §2.1: Some of the terminology terms have 2 references -- that caught my attention. For example, the definition of TED points at both rfc5440 and rfc8231. rfc5440 has a definition, but rfc8231 points at rfc4655. Luckily, the definitions in rfc5440 and rfc4655 are the same...but the added indirection th
Re: [Pce] Alvaro Retana's Comments on draft-ietf-pce-stateful-flags-00: (with DISCUSS and COMMENT)
On January 21, 2020 at 10:47:36 PM, Adrian Farrel wrote: Adrian: Hi! > You are right that there is an existing security issue, and that by not > publishing this document we perpetuate that issue. As the current Security > section says " by defining the expected behavior of implementations, this > document may improve the stability of networks and thus reduce the attack > surface." > > We could expand that text to explain the ways in which the stability might be > improved and the attack surface reduced. I.e., we could talk more about how > networks might be unstable without this "fix" and we could outline the > current attack surfaces. Is that what you're looking for? Yes, that would be good. Thanks!! Alvaro. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Alvaro Retana's Discuss on draft-ietf-pce-stateful-flags-00: (with DISCUSS and COMMENT)
On January 21, 2020 at 10:43:16 PM, Adrian Farrel wrote: Adrian: Hi! > Thanks for this Discuss. I think you found a hole in > draft-ietf-pce-lsp-control-request. No, I think I found another hole in rfc8231. ;-) > It doesn't look like a big hole because if you tried to apply both the C and > the R flag, presumably the R flag would get executed making the C flag > irrelevant. But I agree that the clarity of how to handle "conflicting" flags > is missing. That's the point, "presumably" is not enough. > Now we have to work out how to handle it. > > The options seem to be: > 1. Set a rule, as you suggest, that documents that define new flags MUST > define how to handle the case when the new flags contradict or clash with > existing flags. Fix draft-ietf-pce-lsp-control-request according to that rule. > 2. Fix draft-ietf-pce-lsp-control-request to clarify how the C flag interacts > with other existing flags (specifically the R flag) > 3. Define the processing of messages with "conflicting" flags > > 1.requires a specification and a modification to > draft-ietf-pce-lsp-control-request > 2. requires a modification to draft-ietf-pce-lsp-control-request > 3. requires a specification (that updates 8231) > > I agree that this document could be the home for the specification in 1 or 3. > But it could also be argued (especially for 3) that a new document with some > thought and WG consensus on this new point is required. While the title of > this document certainly puts that work in scope, I don't see that we > necessarily have to hold back the simple clarification in this document in > order to work on the other (perfectly valid) point. I suggested option 1 because I have a hard time imagining how to set up rules for unknown flags... Of course, the WG may know what those unknown (to me) flags might be, but if that was the case I would have expected something more nuanced than "MUST ignore the flag" in this document. IOW, the case would have already beed discussed. I think that option 2 is shortsighted because it only covers the interaction of the 2 existing flags...and we will end up having this same discussion when/if a third flag is defined. > I would also say that documents that apply 2119 language to future documents > are not necessarily successful. That is, constraining the authors of future > documents is notoriously (but not impossibly) hard. I suggested something along the lines of "MUST discuss how they interact with existing flags", but I'm perfectly fine with "are expected to discuss...". The main request (not a constraint!) is to ask future specifications to consider the interaction -- and to remind future authors/WG members/etc of the need. > That makes me think that options 2 or 3 are best. Option 2 does not require a > modification to this document, but does require pulling > draft-ietf-pce-lsp-control-request back to fix it. Option 3 does not > necessarily require a change to this document *if* a new document is written, > and does not require pulling draft-ietf-pce-lsp-control-request back. > > This is a worthy Discuss! But I don't know how to resolve it as a document > author. I am making assumptions above -- about the WG not knowing what may come next to be able specify anything longer than a single line, but I may be wrong. I would then want the Chairs/AD to consult the WG. Thanks! Alvaro. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Alvaro Retana's Discuss on draft-ietf-pce-stateful-flags-00: (with DISCUSS and COMMENT)
Alvaro Retana has entered the following ballot position for draft-ietf-pce-stateful-flags-00: 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-stateful-flags/ -- DISCUSS: -- The acknowledgement to the authors of I-D.ietf-pce-lsp-control-request prompted me to go take a look at that document and refresh my mind on the fact that it defines a new flag called LSP-Control Request Flag (C). I find it hard to resolve in my mind when it would make sense for the R (LSP REMOVE from rfc8281) and C flags to be set at the same time. I couldn't find in rfc8231/rfc8281/I-D.ietf-pce-lsp-control-request or this document any discussion about the ability (or not) to set more than one Flag at a time. In line with it's title, I would like to see this document include rules about processing of multiple flags. I know that it is not possible to set out rules for the interaction of yet-to-be-defined flags, but at least adding text to the effect of "documents defining additional flags MUST discuss how they interact with existing flags" would go a long way. I am balloting DISCUSS because even though this document is not introducing new issues, the combination of what is defined in rfc8231/rfc8281/I-D.ietf-pce-lsp-control-request does...and a document titled "Updated Rules for Processing Stateful PCE Request Parameters Flags" is then the optimal place to address them. [Aside: If this DISCUSS is resolved as suggested above, then I-D.ietf-pce-lsp-control-request, which is on the RFC EDitor's queue, will have to be updated.] -- COMMENT: -- (1) Compatibility The compatibility issue described at the end of §4 could result in all types of unforeseen errors or more serious issues; even considering just the one flag defined in rfc8281: the R flag = LSP REMOVE. One of the incompatibility results could be for an rfc8231-only implementation to set the R flag (it has unknown functionality to the sender), and then for an rfc8281 implementation to receive the object and remove the LSP. Not only could this result in operational issues by removing an LSP that shouldn't have been removed, but this action could also be considered a denial of service. This is not a new issue created by this document, but given that the latent compatibility issues are presented, then a more robust discussion is needed -- I would like to see it in the Security Considerations, but using the Compatibility Considerations section works for me too. To be clear on my expectation. The current text sounds tentative and even alarming: (paraphrasing) there's an issue that cannot be solved unless we start over! It would be nice to then add some text that talks about the potential effects: taking an unintended action, opening the door for an attacker, etc. (2) Going back to the specification: Flags (32 bits): This document does not define any flags. Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt. Implementations that do not understand any particular flag MUST ignore the flag. Aren't the two Normative sentences redundant? The most likely reason for a receiver to not understand a flag is for it to not have it implemented, which is the same as it considering it not assigned. Are there cases that I'm missing which require both statements? Perhaps s/Unassigned/Unknown and remove the second sentence. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-association-diversity-12: (with COMMENT)
Thanks for addressing my comments! Alvaro. On December 19, 2019 at 11:14:40 AM, Mahend Negi (mahend.i...@gmail.com) wrote: Hi Alvaro, Thanks for the detailed review, all the comments are addressed in the new version. New version: https://tools.ietf.org/html/draft-ietf-pce-association-diversity-13 https://datatracker.ietf.org/doc/html/draft-ietf-pce-association-diversity-13 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-diversity-13 Regards, Mahendra On Tue, Oct 29, 2019 at 1:56 AM Alvaro Retana via Datatracker < nore...@ietf.org> wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-pce-association-diversity-12: 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-association-diversity/ > > > > -- > COMMENT: > -- > > (1) §5.1: I-D.ietf-pce-association-group is not explicit about the > "capability > exchange mentioned in this piece of text: > > This capability exchange for the Disjointness >Association Type (TBD1) MUST be done before using the disjointness >association. Thus the PCEP speaker MUST include the Disjointness >Association Type in the ASSOC-Type-List TLV before using the Disjoint >Association Group (DAG) in PCEP messages. > > It seems to me that the exchange implies sending and receiving the > Assoc-type, > but then the second sentence implies sending to be enough. What is the > expected behavior? Please reword. > > (2) §5.2 says, while defining the T flag, says that "if disjoint paths > cannot > be found, PCE SHOULD return no path", but §5.6 reads: > >When the T flag is set (Strict disjointness requested), if >disjointness cannot be ensured for one or more LSPs, the PCE MUST >reply to a Path Computation Request (PCReq) with a Path Computation >Reply (PCRep) message containing a NO-PATH object. > > There is a conflict between the SHOULD and the MUST. > > (3) TBD1 is used with 3 different names: "Disjoint Association Type (DAT)", > "Disjointness Association Type" and "Disjoint-group Association". Please > be > consistent. > > (4) [nits] > > s/DISJOINTNESS-CONFIGURATION-TLVSection 5.2/DISJOINTNESS-CONFIGURATION-TLV > (Section 5.2) > > s/SHOULD NOT try to add/SHOULD NOT add > > s/with example inA Section 5.5/with an example in Section 5.5 > > s/by Section 5.5either/by either > > s/Setting P flag/Setting the P flag > > s/case of network event/case of a network event > > > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Alvaro Retana's No Objection on draft-ietf-pce-association-diversity-12: (with COMMENT)
Alvaro Retana has entered the following ballot position for draft-ietf-pce-association-diversity-12: 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-association-diversity/ -- COMMENT: -- (1) §5.1: I-D.ietf-pce-association-group is not explicit about the "capability exchange mentioned in this piece of text: This capability exchange for the Disjointness Association Type (TBD1) MUST be done before using the disjointness association. Thus the PCEP speaker MUST include the Disjointness Association Type in the ASSOC-Type-List TLV before using the Disjoint Association Group (DAG) in PCEP messages. It seems to me that the exchange implies sending and receiving the Assoc-type, but then the second sentence implies sending to be enough. What is the expected behavior? Please reword. (2) §5.2 says, while defining the T flag, says that "if disjoint paths cannot be found, PCE SHOULD return no path", but §5.6 reads: When the T flag is set (Strict disjointness requested), if disjointness cannot be ensured for one or more LSPs, the PCE MUST reply to a Path Computation Request (PCReq) with a Path Computation Reply (PCRep) message containing a NO-PATH object. There is a conflict between the SHOULD and the MUST. (3) TBD1 is used with 3 different names: "Disjoint Association Type (DAT)", "Disjointness Association Type" and "Disjoint-group Association". Please be consistent. (4) [nits] s/DISJOINTNESS-CONFIGURATION-TLVSection 5.2/DISJOINTNESS-CONFIGURATION-TLV (Section 5.2) s/SHOULD NOT try to add/SHOULD NOT add s/with example inA Section 5.5/with an example in Section 5.5 s/by Section 5.5either/by either s/Setting P flag/Setting the P flag s/case of network event/case of a network event ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-lsp-control-request-09: (with COMMENT)
On September 30, 2019 at 7:29:19 AM, Dhruv Dhody (dhruv.i...@gmail.com) wrote: Dhruv: Hi! > -- > COMMENT: > -- > > I have a substantive comment and then some nits/editorial notes. > > (1) It seems to me that any PCE can request control of an LSP. Even if the > sessions are authenticated and encrypted, how does the PCC determine if it's ok > for the requesting PCE to ask for control? §8.1 says that an "implementation > SHOULD allow the operator to configure the policy based on which it honors the > request to control the LSPs". If the implementation doesn't allow the > configuration of policy, then it is possible for a rogue PCE to ask for control > of an LSP, and for the PCC to grant it. Why is the ability to configure this > policy not REQUIRED? I believe this case should be explicitly called out as a > vulnerability. > Thanks for pointing this out. Since RFC 8231 uses SHOULD wrt policy, I would consider not changing that. We can highlight that the PCC is the ultimate arbiter on if the delegation should be made and to which PCE. Even after delegation, the PCC can take back control anytime. But at the same time blindly accepting control request could be a problem! I propose this text in Security section - A PCC is the ultimate arbiter of delegation. As per [RFC8231], a local policy at PCC is used to influence the delegation. A PCC can also revoke the delegation at any time. A PCC MUST NOT blindly trust the control requests and SHOULD take local policy and other factors into consideration before honoring the request. Two points: (1) How is “MUST NOT blindly trust” normatively enforceable? Even if it was, the mechanism to take off the blindfolds is the policy… (2) Even if policy is configured, a rogue PCE can still take control of the LSP; for example, the policy was misconfigured, or simply because the PCE has been compromised. In all these cases the problem is not so much that a PCE took control, but the actions that it can take with the LSP: change its characteristics, reroute it, shut it down, etc… Thanks! Alvaro. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Alvaro Retana's No Objection on draft-ietf-pce-lsp-control-request-09: (with COMMENT)
Alvaro Retana has entered the following ballot position for draft-ietf-pce-lsp-control-request-09: 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-lsp-control-request/ -- COMMENT: -- I have a substantive comment and then some nits/editorial notes. (1) It seems to me that any PCE can request control of an LSP. Even if the sessions are authenticated and encrypted, how does the PCC determine if it's ok for the requesting PCE to ask for control? §8.1 says that an "implementation SHOULD allow the operator to configure the policy based on which it honors the request to control the LSPs". If the implementation doesn't allow the configuration of policy, then it is possible for a rogue PCE to ask for control of an LSP, and for the PCC to grant it. Why is the ability to configure this policy not REQUIRED? I believe this case should be explicitly called out as a vulnerability. (2) Abstract: s/A Path Computation Client (PCC) has set up LSPs/A Path Computation Client (PCC) that has set up LSPs (3) §1: s/which PCE to delegate the orphaned LSP/which PCE to delegate the orphaned LSP to (4) §1: s/a simple extension, by using this a PCE can/a simple extension, by using it a PCE can (5) In §3 the new C Flag is called the "LSP-Control Request Flag", but §7.1 only uses "LSP-Control". Please be consistent; the more descriptive name is probably better. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Alvaro Retana's No Objection on draft-ietf-pce-association-group-09: (with COMMENT)
Alvaro Retana has entered the following ballot position for draft-ietf-pce-association-group-09: 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-association-group/ -- COMMENT: -- (1) s/before hand/beforehand/g (2) §5: "Start-Assoc-ID...The values 0 and 0x MUST NOT be used." What should the receiver do if they are? (3) §5: "Range...it MUST be such that (Start-Assoc-ID + Range) do not cross the association identifier range of 0x." What should the receiver do if it does? (4) s/is OPTIONAL and MAY/MAY/g OPTIONAL = MAY (5) §9.2: "An implementation SHOULD allow...Further implementation SHOULD allow... To serve this purpose, the PCEP YANG module [I-D.ietf-pce-pcep-yang] includes association groups." If I-D.ietf-pce-pcep-yang is the mechanism that addresses these Normative statements, then it should be a Normative reference. I think that it is not necessary to point at I-D.ietf-pce-pcep-yang in this document. (6) RFC8126 should be a Normative reference. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Alvaro Retana's No Objection on draft-ietf-pce-hierarchy-extensions-10: (with COMMENT)
Alvaro Retana has entered the following ballot position for draft-ietf-pce-hierarchy-extensions-10: 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-hierarchy-extensions/ -- COMMENT: -- (1) rfc6805 should be a Normative reference; the contents reflect its importance in the definition of the extensions, and this text in the Introduction confirms it: This document defines the PCEP extensions for the purpose of implementing Hierarchical PCE procedures, which are described in [RFC6805]. [I am not balloting this point as a DISCUSS because I believe it is easy to resolve and trust the Responsible AD.] (2) The Shepherd's writeup mentions the existence of "commercial as well as open source implementations" -- these are documented in Appendix A. What code points are used in those implementation? Is the code deployed (in production)? I'm asking because all the code points (except the ones defined in this document, of course) have not been assigned by IANA...and have to wonder about potential collision (or even squatting). [I realize the Authors may not have an answer available...it would be very nice if someone (Authors/Shepherd/Chair/AD/anyone) would check. There might be nothing to worry about; better safe than sorry.] (3) §3.2.2: It is not clear to me whether the Domain Type is a bit field (one per type), or if there are 256 possible types. Please clarify. (4) Related to the last point... §7.3 doesn't list which range is unassigned...nor whether the value 0 (assuming it is not a bit field) is available to assignment or not. (5) Please add a reference for PCEP-LS? (6) [nit] s/achild/a child (7) [nit] §3.2.1.1: The first paragraph is missing the closing ". ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Alvaro Retana's Yes on draft-ietf-pce-segment-routing-16: (with COMMENT)
Alvaro Retana has entered the following ballot position for draft-ietf-pce-segment-routing-16: Yes 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: -- Thank you for addressing my DISCUSS points! ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Alvaro Retana's No Objection on draft-ietf-pce-wson-rwa-ext-11: (with COMMENT)
Alvaro Retana has entered the following ballot position for draft-ietf-pce-wson-rwa-ext-11: 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-wson-rwa-ext/ -- COMMENT: -- I share Benjamin's concerns about the clarity of this document, and support his DISCUSS. I have added some related comments below (not overlapping with his, of Mirja's). (1) §4.2 (Wavelength Selection TLV): "The encoding of this TLV is specified as the Wavelength Selection Sub-TLV in Section 4.2.2 of [RFC7689]." It should be made clear that this document is requesting a new TLV-type code to be assigned (§8.2) for this TLV. IOW, rfc7689 just describes the value part of the TLV... (2) §4.3: s/MUST be able to specify a restriction/MUST specify a restriction I assume you really want the restriction signaled, and not just the ability to do it... (3) §4.3: "the PCE MUST have mechanisms to know the tunability restrictions" How can this be Normatively enforced? It seems to be that the MUST is out of place. s/MUST/must (4) §4.3: "the PCC MUST be able to apply additional constraints" This sounds like a requirement, which is immediately satisfied by the definition of the Wavelength Restriction Constraint TLV...so I think the MUST is out of place. s/MUST/must (5) §4.3.2: s/wavelength restriction TLV/Wavelength Restriction Constraint TLV (6) I think that these references should be Normative: rfc5440, rfc8253. ___ 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)
On January 18, 2019 at 11:45:52 AM, Jonathan Hardwick ( jonathan.hardw...@metaswitch.com) wrote: Jon: Hi! Sorry for the empty message I sent before this one… I'm sorry that it has taken longer than I thought to reply to your comments! Please find our replies below. I will post an updated version of the document as soon as I can. I have some comments below. Thanks! Alvaro. -- DISCUSS: -- (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. [Jon] In many deployments we anticipate that link MSDs are homogeneous. In those cases, link state routing might not distribute per-link MSDs (e.g. routers might not even support RFC 8491). In such cases, the per-node MSD on the PCEP session is sufficient. All the draft says is that MSD information available from link state routing, if any, must take priority over that defined on the PCEP session. I don't see a problem with that. Please include the description of the assumptions in the document. (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. [Jon] You are right, this should be more explicit. How about this. NEW If the subobjects contain NAI only, the PCC first converts each NAI into a SID index value and then proceeds as above. To convert an NAI to a SID index, the PCC looks for a fully-specified prefix or adjacency matching the fields in the NAI. If the PCC finds a matching prefix/adjacency, and the matching prefix/adjacency has a SID associated with it, then the PCC uses that SID. If the PCC cannot find a matching prefix/adjacency, or if the matching prefix/adjacency has no SID associated with it, the PCC behaves as specified in section 6.2.2.1. END NEW This sounds fine. 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. [Jon] This is specified in 6.2.2.1. First bullet - if the prefix is found in the SR-DB but has no SID, send error TBD3. Second bullet - if the NAI is not found in the SR-DB, send error TBD4. 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. [Jon] Hopefully the new text proposed above will do that. The requirement of the information to be contained in the SR-DB makes I-D.ietf-spring-segment-routing-policy a Normative reference. [Jon] Rather than add an extra normative dependency, we would prefer to remove the dependency on the definition of the SR-DB and instead explicitly define in our document what information is to searched. That’s fine with me too. (5) §7 (Backward Compatibility) "Some implementations, which are compliant with an earlier version of this specification..." I understand that there may be implementations that are non-compliant with this specification out in the field. However, why is this document making accommodations for them? Not only are these implementations not compliant with this document, but are also non compliant with rfc8408, which implies the use of a new sub-TLV per PST. I didn't find a discussion on the mailing list related to this issue. Specifying alternate behavior to accommodate non-compliant implementations is not the best way to define new functionality. If the support for those old implementations was an
Re: [Pce] Alvaro Retana's Discuss on draft-ietf-pce-segment-routing-14: (with DISCUSS and COMMENT)
On January 18, 2019 at 11:45:52 AM, Jonathan Hardwick ( jonathan.hardw...@metaswitch.com) wrote: Jon: Hi! I'm sorry that it has taken longer than I thought to reply to your comments! Please find our replies below. I will post an updated version of the document as soon as I can. Many thanks Jon -- 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. [Jon] Happy to change this. This draft actually pre-dates RFC 8491, but now the definition has moved there, we can point to it. (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. [Jon] In many deployments we anticipate that link MSDs are homogeneous. In those cases, link state routing might not distribute per-link MSDs (e.g. routers might not even support RFC 8491). In such cases, the per-node MSD on the PCEP session is sufficient. All the draft says is that MSD information available from link state routing, if any, must take priority over that defined on the PCEP session. I don't see a problem with that. (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. [Jon] This document (and the SR-PCE-CAPABILITY) is scoped to MPLS only. I believe that draft-negi defines its own SRV6-PCE-CAPABILITY TLV and I don't see any reference to MSD in it, but if a new MSD type is needed for other dataplane types, I think it's expected that a new SR capability TLV will be defined to convey it. I don't expect to generalize the SR-PCE-CAPABILITY TLV. Note that the MSD in the SR-PCE-CAPABILITY is a BMI-MSD. Although RFC 8491 defines a generic MSD container, the MSD in this document is specifically a BMI-MSD. (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. [Jon] You are right, this should be more explicit. How about this. NEW If the subobjects contain NAI only, the PCC first converts each NAI into a SID index value and then proceeds as above. To convert an NAI to a SID index, the PCC looks for a fully-specified prefix or adjacency matching the fields in the NAI. If the PCC finds a matching prefix/adjacency, and the matching prefix/adjacency has a SID associated with it, then the PCC uses that SID. If the PCC cannot find a matching prefix/adjacency, or if the matching prefix/adjacency has no SID associated with it, the PCC behaves as
[Pce] 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 compliant with an earlier version of this specification..." I understand that there may be implementations that are non-compliant with this specification out in the field. However, why is this document making accommodations for them? Not only are these implementations not compliant with this document, but are also non compliant with rfc8408, which implies the use of a new sub-TLV per PST. I didn't find a discussion on the mailing list related to this issue. Specifying alternate behavior to accommodate
[Pce] Alvaro Retana's No Objection on draft-ietf-pce-lsp-setup-type-09: (with COMMENT)
Alvaro Retana has entered the following ballot position for draft-ietf-pce-lsp-setup-type-09: 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-lsp-setup-type/ -- COMMENT: -- (1) The Length field in S3 has no units. I'm sure people can guess it is in bytes, from the rest of the description, but it should be explicit. (2) The Reserved fields "MUST be set to zero". What happens if they're not? Typically they are also ignored by the receiver... (3) S3: "Each sub-TLV MUST obey the rules for TLV formatting defined in ([RFC5440]). That is, each sub-TLV MUST be padded to a four byte alignment, and the length field of each sub-TLV MUST NOT include the padding bytes." The first sentence is ok. The second one tries to paraphrase what rfc5440 says -- but rfc5440 doesn't say that, it doesn't even use Normative language! This is the text from rfc5440: The Length field defines the length of the value portion in bytes. The TLV is padded to 4-bytes alignment; padding is not included in the Length field (so a 3-byte value would have a length of 3, but the total size of the TLV would be 8 bytes). (3a) The text in this document shouldn't use Normative language to describe what rfc5440 says and specifies. (3b) Note that the text from rfc5440 (specifically the part about "padding is not included in the Length field") is not aligned with the description of the Length field in this document: "The TLV Length field MUST be equal to the size of the appended sub-TLVs plus the size of the PST list (rounded up to the nearest multiple of four) plus four bytes." Rounding up includes the padding. (4) S6: "Each document that introduces a new path setup type to PCEP must include a manageability section." Why is a Normative "MUST" not used? (5) rfc6123 is a Historic document. Maybe a reference to rfc5706 is more appropriate (even in addition to rfc6123). ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] [Technical Errata Reported] RFC4674 (5192)
Loa: Hi! What do you mean “remove an incoming mail”? If you’re asking about avoiding this type of report, the message gets generated by the RFC Editor’s system, so they would have to look at some type of access control there. I’m not sure how access to the system is controlled. If you’re asking about preventing someone from posting directly to the list (pce, for example), then the list administrator can do that (block, permit, etc.). Alvaro. On November 30, 2017 at 9:36:14 PM, Loa Andersson (l...@pi.nu) wrote: Second, what are the procedures to remove an incoming mail to an IETF mailing list, we been there before and it has not been this easy. Alvaro, Can you check on this? ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Alvaro Retana's No Objection on draft-ietf-pce-rfc6006bis-03: (with COMMENT)
Alvaro Retana has entered the following ballot position for
draft-ietf-pce-rfc6006bis-03: 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-rfc6006bis/
--
COMMENT:
--
I don't object the publication of this document.
However, I want to call attention to the latest IPR declaration [1] which seems
to have resulted in a very, very, very late claim against this document *and*
rfc6006. Not only was the declaration done recently, but I don't think the WG
was explicitly made aware of it. I did look at the archive and this is what I
found:
- WG Chair asked the authors to update the system to reflect that the IPR
claimed against rfc6006 also applies to this document [2]
- a new IPR statement [1] was filed, which updated the previous one [3]
The problem is that the most recent statement [1] points to a patent ("US
12/404100") which is different from the one in the original statement [3] ("US
12/708048"). I take this update to mean that there is more IP than originally
claimed -- resulting in a very, very, very late statement. Note that it came
in after the WGLC concluded and just a couple of days before the document was
submitted to the IESG for Publication.
I'll let the WG chairs and the responsible AD take appropriate actions.
[1] https://datatracker.ietf.org/ipr/2983/
[2]
https://mailarchive.ietf.org/arch/msg/pce/4rxUbSO16PU22ThiMHBf66M73yA/?qid=222caa9caf467838c3c40466e1de7e7e
[3] https://datatracker.ietf.org/ipr/1686/
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
[Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-app-07: (with COMMENT)
Alvaro Retana has entered the following ballot position for draft-ietf-pce-stateful-pce-app-07: 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-stateful-pce-app/ -- COMMENT: -- This document mostly presents application scenarios, which (by reference) serve as motivation for draft-ietf-pce-stateful-pce. However, there are a couple of places (in Section 4) where the operation defined in draft-ietf-pce-stateful-pce is used as part of the considerations. For example (from 4.1): Stateless and stateful PCEs can co-exist in the same network and be in charge of path computation of different types. To solve the problem of distinguishing between the two types of PCEs, either discovery or configuration may be used. The capability negotiation in [I-D.ietf-pce-stateful-pce] ensures correct operation when the PCE address is configured on the PCC. I see a circular dependency between this document and draft-ietf-pce-stateful-pce, where the considerations here are expected to motivate the extensions, but the specific extensions are used to discuss “generic issues with stateful PCE deployments”. Given that draft-ietf-pce-stateful-pce is a Normative Reference, I would rather see this document come back for IESG Evaluation with/after draft-ietf-pce-stateful-pce. Note that draft-ietf-pce-stateful-pce is still (AFAICT) under consideration in the WG. I am not making this comment a DISCUSS because I don’t think that it raises to the appropriate level (as only some parts of the document seem to have the dependency), and we’ll have to wait for draft-ietf-pce-stateful-pce to be processed before publication anyway. However, I think that the application scenarios and motivation for future extensions should be able to be described without referring to the extensions themselves — I would then like the authors, Shepherd and the responsible AD to consider whether it is possible for this document to stand on its own, or whether we need to process it with the extensions draft. Given that draft-ietf-pce-stateful-pce is still in the WG, I think it is important for us to talk about it as this point. I noted in the Shepherd’s writeup that this document used to be “originally included in the base stateful PCE protocol specification” (which I assume is draft-ietf-pce-stateful-pce). To be clear: I am not opposing the publication of this document (even though the content could have been part of draft-ietf-pce-stateful-pce), I just think that in the current form it should be processed/published *with* draft-ietf-pce-stateful-pce. [Mechanisms from I-D.ietf-pce-stateful-sync-optimizations and I-D.ietf-pce-pce-initiated-lsp are also mentioned in similar ways, and those drafts are also in process in the WG. I’m focusing on draft-ietf-pce-stateful-pce above just to make the point.] ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Alvaro Retana's No Objection on draft-ietf-pce-iro-update-06: (with COMMENT)
Alvaro Retana has entered the following ballot position for draft-ietf-pce-iro-update-06: 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-iro-update/ -- COMMENT: -- 1. WG Consensus The Abstract talks about this document resulting from an "informal survey". The Shepherd writeup also mentions the survey and how it was "not unanimous". However, while the survey itself is mentioned in the document (10 times in 6 pages!), there is no reference, and more importantly nothing is mentioned about WG consensus. What I'm getting to here is the following: regardless of what the survey says (or not), this document is on the Standards Track so I expect the update to be the result of WG consensus. If the survey is not even referenced (which is fine with me), then the document should forget about it and simply point at the updates. In other words, the survey, like discussion on the mailing list, seems to have been used as a tool to reach consensus — no need to repeatedly mention the tool. I don't think this point raises to the level of a DISCUSS because it should be an editorial change. Even though the archives don't provide much in terms of discussion around this document (or draft-dhody-pce-iro-survey), I have to assume that it reached this point because there is in fact consensus on the update. 2. Non conforming implementations Section 3. (Other Considerations). Given that other interpretations of rfc5440 were possible, I think that the considerations in this section are operational, so renaming may be a good idea. I would expect that because this is a Standards Track document that people will eventually conform to it, so I think that the "RECOMMEND" at the bottom is not needed. [I think that's the only rfc2119 key word.] 3. Section 2.1. (Update to RFC 5440): a. Where should the new statements be added? I'm assuming after the first paragraph. B. "An abstract node could be a simple abstract node…" Is there a better way to define "abstract node" than by using it in the definition? Maybe just point to rfc3209. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
