Path Computation Element Communication Protocol (PCEP) Extension for Flow Specification
draft-ietf-pce-pcep-flowspec-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-26
|
13 | Gunter Van de Velde | Request closed, assignment withdrawn: Jon Mitchell Last Call OPSDIR review |
2024-01-26
|
13 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2022-01-07
|
13 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-12-23
|
13 | (System) | RFC Editor state changed to AUTH48 |
2021-10-19
|
13 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-10-14
|
13 | (System) | RFC Editor state changed to EDIT from MISSREF |
2021-10-14
|
13 | Dhruv Dhody | New version available: draft-ietf-pce-pcep-flowspec-13.txt |
2021-10-14
|
13 | (System) | New version accepted (logged-in submitter: Dhruv Dhody) |
2021-10-14
|
13 | Dhruv Dhody | Uploaded new revision |
2021-10-04
|
12 | John Scudder | Shepherding AD changed to John Scudder |
2021-05-03
|
12 | Bernie Volz | Closed request for Telechat review by INTDIR with state 'Overtaken by Events' |
2020-11-10
|
12 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-11-10
|
12 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-11-10
|
12 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-11-09
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-11-02
|
12 | (System) | RFC Editor state changed to MISSREF |
2020-11-02
|
12 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-11-02
|
12 | (System) | Announcement was received by RFC Editor |
2020-11-02
|
12 | (System) | IANA Action state changed to In Progress |
2020-11-02
|
12 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-11-02
|
12 | Amy Vezza | IESG has approved the document |
2020-11-02
|
12 | Amy Vezza | Closed "Approve" ballot |
2020-11-02
|
12 | Amy Vezza | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-11-02
|
12 | Amy Vezza | Ballot writeup was changed |
2020-11-02
|
12 | Deborah Brungard | Ballot approval text was changed |
2020-10-30
|
12 | Dhruv Dhody | New version available: draft-ietf-pce-pcep-flowspec-12.txt |
2020-10-30
|
12 | (System) | New version accepted (logged-in submitter: Dhruv Dhody) |
2020-10-30
|
12 | Dhruv Dhody | Uploaded new revision |
2020-10-29
|
11 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my Discuss (and Comment) points! My sole comment on the -11 is that the Abstract is a bit long. |
2020-10-29
|
11 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2020-10-07
|
11 | Alvaro Retana | [Ballot comment] [Thanks for addressing my DISCUSS.] |
2020-10-07
|
11 | Alvaro Retana | [Ballot Position Update] Position for Alvaro Retana has been changed to No Objection from Discuss |
2020-10-05
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-10-05
|
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-10-05
|
11 | Adrian Farrel | New version available: draft-ietf-pce-pcep-flowspec-11.txt |
2020-10-05
|
11 | (System) | New version accepted (logged-in submitter: Adrian Farrel) |
2020-10-05
|
11 | Adrian Farrel | Uploaded new revision |
2020-09-28
|
10 | (System) | Removed unintended duplicate tsvart lc review |
2020-08-27
|
10 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-08-26
|
10 | Murray Kucherawy | [Ballot comment] I support two things: Ben's DISCUSS position, and the various kudos from others about a very well written document. For the sake of … [Ballot comment] I support two things: Ben's DISCUSS position, and the various kudos from others about a very well written document. For the sake of providing one bit of feedback not covered by others: Section 13.8 is probably unnecessary. |
2020-08-26
|
10 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2020-08-26
|
10 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-08-26
|
10 | Warren Kumari | [Ballot comment] I agree with Ben's DISCUSS position - I don't understand the tradeoff between the complexity of multiple objects and just a single, and … [Ballot comment] I agree with Ben's DISCUSS position - I don't understand the tradeoff between the complexity of multiple objects and just a single, and believe that more text is required / needed to help clarify. |
2020-08-26
|
10 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2020-08-26
|
10 | Alvaro Retana | [Ballot 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 … [Ballot 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. |
2020-08-26
|
10 | Alvaro Retana | [Ballot 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 … [Ballot 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 tunnel....The 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 implementation checks the Flow Specification TLVs against those recorded for the FS-ID of the Flow Specification being removed and finds a mismatch, the Flow Specification MUST still be removed and the implementation SHOULD record a local exception or log. Which "Flow Specification MUST still be removed"? The one previously advertised using the FS-ID, or the one specified in the TLVs, or both? [minor comments] (6) §1: "For convenience we term the description of a traffic flow using Flow Specification Components as a "Flow Specification" and it must be understood that this is not the same as the same term used in [I-D.ietf-idr-rfc5575bis] since no action is explicitly included in the encoding." rfc5575bis uses pretty much the same definition (from §3): A Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. A given IP packet is said to match the defined Flow Specification if it matches all the specified criteria. The actions are encoded separately. Note that the definition in §2 of FlowSpec, apparently from rfc5574bis, is not included there. (7) §5: "L bit...If the bit is set, only Flow Specifications that describe IPv4 or IPv6 destinations are meaningful in the Flow Filter TLV." If there is no meaningful information then what? I'm assuming that the object is just ignored... It might be nice to be explicit about that. Just a minor point. (8) §7: In the Multicast Flow Specification TLV, what does "(*, *)" match? Any source and any destination? What is source/group wildcarding? (9) §7.1: s/All L2 Flow Specification TLVs...(for example, in [I-D.ietf-idr-rfc5575bis] and [I-D.ietf-idr-flow-spec-v6])/All L2 Flow Specification TLVs...(for example, in [I-D.ietf-idr-flowspec-l2vpn]) [nits] s/flow specification/Flow Specification/g s/defines following new types -/defines the following new types: s/will be place/will be placed s/to to/to |
2020-08-26
|
10 | Alvaro Retana | [Ballot Position Update] New position, Discuss, has been recorded for Alvaro Retana |
2020-08-26
|
10 | Roman Danyliw | [Ballot comment] Thank you for an approachable document. Thank you to the SECDIR reviewer (Scott G. Kelly) ** Section 12. To refine what Ben Kaduk … [Ballot comment] Thank you for an approachable document. Thank you to the SECDIR reviewer (Scott G. Kelly) ** Section 12. To refine what Ben Kaduk noted about the applicability of [RFC6952], Section 2.5 seems to apply for me. ** Section 12. Per “Therefore, implementations or deployments concerned with protecting privacy MUST apply the mechanisms described in the documents referenced above.”, it might be helpful to explicitly call out the specific guidance to follow. I believe that it’s to use either IPSec per Section 10.4 – 6 of RFC5440 or TLS per RFC8523 to provide transport security properties. The legacy references to TCP-AO and TCP MD5 in those documents don’t help here. ** Section 12. Per “Although this is not directly a security issue per se, the confusion and unexpected forwarding behavior may be engineered or exploited by an attacker. Therefore, implementers and operators SHOULD pay careful attention to the Manageability Considerations described in Section 13.”, I completely agree. I would say it a bit more strongly that this complexity could be a security issue. I’m envisioning a situation where the complex forwarding behaviors might create gaps in the monitoring and inspection of particular traffic or provide a path that avoids expected mitigations. |
2020-08-26
|
10 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2020-08-25
|
10 | Benjamin Kaduk | [Ballot discuss] As with the others, I also found this document to be quite easy to read and well-structured; thank you! I just have a … [Ballot discuss] As with the others, I also found this document to be quite easy to read and well-structured; thank you! I just have a couple points I'd like to discuss, but I am not pressing for a specific resolution and expect to change to No Objection once the discussion has occurred (whatever the conclusion is). This is a Discuss because I want to have a discussion, not because I'm confident in the correctness of my position. But it seems like the ambiguity about when multiple flow specifications in single FLOWSPEC object are treated as logical AND to narrow a single flow specification versus treated as separate flow specifications per Section 8.4 could lead to confusion, and it would be simpler and have less risk to stick to the "one flow specification per FLOWSPEC object" model as discussed in the rest of the document. If the ability to define multiple flows within a single FLOWSPEC object is retained, I think we need more specific procedures for identifying when that is the case, quite possibly with a specific enumeration of cases. I also mention in the per-section comments several places where (IIUC) there seems to be a need to match the Speaker Entity Identifier TLV as well as the FS-ID value. It might even be an exhaustive list, but please do a pass to check. |
2020-08-25
|
10 | Benjamin Kaduk | [Ballot comment] 5575bis's validation procedures (§6) include things like "originator of the flow spec matches originator of best-match unicast route for the destination prefix in … [Ballot comment] 5575bis's validation procedures (§6) include things like "originator of the flow spec matches originator of best-match unicast route for the destination prefix in the flowspec". This doesn't seem to apply to PCEP, so presumably we are supposed to ignore such requirements. Is there a concrete list of which parts of the procedures are affected in this way? I agree with the TSV-ART reviewer that the Abstract and Introduction could likely be improved by a restructuring. In some places we call out that our usage of "Flow Specification" diverges from that of 5575bis, since we do not have an "action", whereas in other places we say that there is an implicit action of "forward all matching traffic onto the associated path". It might be better to try to stick to just one of these two worldviews. Abstract I did a little bit of a double-take at "may be unsolicited instructions", given my understanding that PCE-initiated LSPs are at a protocol level just requests to the PCC to initiate the path. Section 3.1 2. Decide what properties to assign to an LSP. This can include bandwidth reservations, priorities, and DSCP (i.e., MPLS Traffic Class field). This function is also determined by user configuration or response to predicted or observed traffic demands. nit: I think there's a missing word/words before "response", perhaps "as a response to" or "in response to". side note(?): I see that (4) refers to the "PCC" as signalling the LSP across the network, but (5) refers to the "head end" being told what traffic to put on the LSP. I can see how the respective functionalities are important for those functions, but I am not sure if the roles will ever be played by different entities (if they are always the same entity there may be some rhetorical value in using a consistent term for that single entity). Section 3.2 o Flow Specification information/state must be synchronized between PCEP peers so that, on recovery, the peers have the same understanding of which Flow Specifications apply. I don't remember seeing much specifically about recovery and state synchronization in this document; should we have a little more exposition (somewhere later on, perhaps §3.2.3) about how normal recovery mechanisms suffice to synchronize the flowspec state along with other LSP state? Section 3.2.1.1 The presence of the PCE FlowSpec Capability TLV in the OPEN Object in a PCE's OPEN message indicates that the PCE can distribute FlowSpecs to PCCs and can receive FlowSpecs in messages from PCCs. The presence of the PCE FlowSpec Capability TLV in the OPEN Object in a PCC's OPEN message indicates that the PCC supports the FlowSpec functionality described in this document. (nitty nit): is there a reason to not use the "supports the FlowSpec functionality described in this document" for both cases? If either one of a pair of PCEP peers does not indicate support of the functionality described in this document by not including the PCE FlowSpec Capability TLV in the OPEN Object in its OPEN message, then (I expect the RFC Editor to ask about the apparent double negative here if the text doesn't change before it gets to them.) Section 3.2.2 o PCRpt messages so that a PCC can report the traffic that the PCC plans to place on the path. (nit) I just want to confirm that "plans to place" is still correct, given that RFC 8231 defines PCRpt as "a PCEP message sent by a PCC to a PCE to report the current state of an LSP". 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. (nit): this sentence was hard for me to parse ("zero or one or one or ..." leaves the grouping of conditionals unclear). From subsequent text, I believe that the allowed possibilities are (one Flow Filter TLV and no L2 Flow Filter TLV), (no Flow Filter TLV and one L2 Flow Filter TLV), and (one Flow Filter TLV and one L2 Flow Filter TLV). If that's correct, I'd suggest rephrasing this more like "carries either or both of the Flow Filter TLV and the L2 Flow Filter TLV". Section 4 I'm a bit confused as to the usage of the two-octet "value" field that is apparently always set to 0, the same as the padding. I would perhaps have expected some kind of flags word if there was to be any non-trivial content in this capability TLV. Section 5 the PCEP object format defined in [RFC5440]. It is OPTIONAL in the PCReq, PCRep, PCErr, PCInitiate, PCRpt, and PCUpd messages and MAY be present zero, one, or more times. Each instance of the object specifies a traffic flow. (I know we've covered this before, and apologize for the noise, but I feel obligated to note that "zero, one, or more times" is equiavlent to "zero or more times" anyway.) The PCEP FLOWSPEC object carries a FlowSpec filter rule encoded in a TLV (as defined in Section 6). nit: not just a single TLV, per se, right? FS-ID (32-bits): A PCEP-specific identifier for the FlowSpec information. A PCE or PCC creates an FS-ID for each FlowSpec that it originates, and the value is unique within the scope of that PCE or PCC and is constant for the lifetime of a PCEP session. All subsequent PCEP messages can identify the FlowSpec using the FS-ID. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be used. It might be worth a reference to draft-gont-numeric-ids-sec-considerations (I'm AD sponsoring it) as guidance for how the FS-ID is generated. There does not seem to be a need even for monotonicity of assignment, so some of the random assignment schemes might be best. Section 6 Section 7. 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 tunnel. This tunnel is nit: I suggest rewording, as the current wording might be taken as implying that having both Flow Filter and L2 Flow Filter at the same time is forbidden; perhaps, "at most one Flow Filter TLV and one L2 Flow Filter TLV can be present". (I do see that the explicit list of options is given again a few sentences later.) Section 7 Though value 0 is currently reserved by the BGP specs, we are perhaps setting ourselves up for a conflict if it ever becomes "un-reserved" for BGP. Lumping it into the 1..255 range doesn't seem like it would introduce any problems, and would ameliorate this risk. (Doing this would have knock-on effects on text throughout the rest of the document.) Type values are chosen so that there can be commonality with Flow Specifications defined for use with BGP [I-D.ietf-idr-rfc5575bis]. We probably should reference draft-ietf-idr-flow-spec-v6 here as well, since our TLV can work with either IPv4 or IPv6, but the corresponding BGP registry is different. The content of the Value field in each TLV is specific to the type/ AFI and describes the parameters of the Flow Specification. The This suggests that any new allocations from the PCEP-only range should say what AFI(s) they are defined for, but no such guidance is provided in Section 10.3. Section 7.1 (Same comment about the value 0 as above.) All L2 Flow Specification TLVs with Types in the range 1 to 255 have Values defined for use in BGP (for example, in [I-D.ietf-idr-rfc5575bis] and [I-D.ietf-idr-flow-spec-v6]) and are set using the BGP encoding, but without the type octet (the relevant information is in the Type field of the TLV). The Value field is nit: this "all [...] in the range 1 to 255 have Values defined for use in BGP" makes it sound like they are all currently defined, which does not seem to be the case. Rewording to something like "L2 Flow Specification TLVs with Types in the range 1 to 255 have their Value interpreted as defined for use in BGP ([...]) and are set using the BGP encoding, but without the type octet" might help. Section 8.3 not the addition of a new flow as described in Section 8.4. The FS- ID field of the PCEP FLOWSPEC object is used to identify a specific Flow Specification. I'd suggest mentioning again that this is in conjunction with the Speaker Entity Identity TLV. When modifying a Flow Specification, all Flow Specification TLVs for the intended specification of the flow MUST be included in the PCEP FLOWSPEC object and the FS-ID MUST be retained from the previous description of the flow. (and likewise, if there is a requirement to preserve the Speaker Entity Identity TLV, though perhaps that's already required by RFC 8232.) Section 8.5 To remove a Flow Specification, a PCEP FLOWSPEC object is included with the FS-ID matching the one being removed, and the R bit set to (Presumably the Speaker Entity Identity TLV also has to match?) If the R bit is set and Flow Specification TLVs are present, an implementation MAY ignore them. If the implementation checks the Flow Specification TLVs against those recorded for the FS-ID of the Flow Specification being removed and finds a mismatch, the Flow Specification MUST still be removed and the implementation SHOULD record a local exception or log. Thank you for specifying the behavior in the event of a mismatch! Section 8.7 PCCs MUST apply the same ordering rules as defined in [I-D.ietf-idr-rfc5575bis]. (side note) I noted in my ballot comments on 5575bis that the ordering rules allow for situations where the priority of a rule with given semantic content can be different depending on how it is encoded, which seems risky to me. It would in principle be possible for this document to impose additional restrictions on how things are encoded to remove this potential disparity, though I do not actually expect us to want to do so (hence, this is just a side note). Furthermore, it is possible that Flow Specifications will be distributed by BGP as well as by PCEP as described in this document. In such cases implementations supporting both approaches MUST apply the prioritization and ordering rules as set out in [I-D.ietf-idr-rfc5575bis] regardless of which protocol distributed This MUST seems to just be saying the same thing as the previous paragraph? the Flow Specifications, however 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. [...] And this MAY seems to be contradicting the MUST, making it "no longer a MUST". An implementation that receives a PCEP message carrying a Flow Specification that it cannot resolve against other Flow Specifications already installed MUST respond with a PCErr message I'm not entirely sure I understand what "resolve against" means in this context -- if I had to guess, it would be something about having a unique interpretation that is not in conflict with existing rules, but I'm pretty hazy on what the details of that would entail. Section 9 We should probably say that is specified in RFC 5440. I also couldn't tell if there was a clear rule we are using for when to expand out sub-structures that we are not modifying vs. leaving them to the referenced document. Many are left out, but we do expand, e.g., in PCUpd/PCRpt. (I also note that we cover PCUpd and PCRpt in the reverse order to RFC 8231, not that it really matters for much of anything.) Section 12 modified or torn down. Such systems, therefore, apply security considerations as described in [RFC5440], [RFC6952], and [RFC8253]. In my reading, the security considerations of RFC 6952 are directed more at protocol designers than at operators; could you say a little more about what you expect the reader to take away from that reference? Also, I think that at least some of the security considerations from 5575bis are also relevant to our usage of the data structures. The description of Flow Specifications associated with paths set up or controlled by a PCE add a further detail that could be attacked without tearing down LSPs or SR paths, but causing traffic to be misrouted within the network. Therefore, the use of the security mechanisms for PCEP referenced above is important. I might consider mentioning that the BGP flowspec work can use the "same originator" check for flowspec destination address and longest-prefix match for routes to that address, which is unavailable in the PCEP scenario. On the other hand, the PCE is fairly trusted already, so maybe there is less need for such a check in the PCEP case. usually considered private customer information. Therefore, implementations or deployments concerned with protecting privacy MUST apply the mechanisms described in the documents referenced above. (A construction of the form "if you care about , you MUST " doesn't actually impose much of a normative requirement...) Although this is not directly a security issue per se, the confusion and unexpected forwarding behavior may be engineered or exploited by an attacker. Therefore, implementers and operators SHOULD pay careful attention to the Manageability Considerations described in Section 13. I appreciate that you mention this risk in this way; thanks! Section 13.1 which path. Unlike the behavior in a distributed routing system, it is not important that each head-end implementation applies the same rules to disambiguate overlapping Flow Specifications, but it is important that: Just to check my understanding: this is "important" in the sense of "important to the stability of the network"? Section 13.3 This section seems like it could be roughly summarized as "someone should please write some YANG". My personal preference would be to say this more along the lines of "YANG models describing the functionality in this document have not yet been written, but are desirable. Some relevant preexisting work is: [...]", but I can understand if your preferences are different (or there is precedent for this kind of formulation). Section 15.2 Since we depend on RFC 4364 for the format of the RD, that seems to make it a normative reference. (We also use RFC 7399 as the source for a couple of defined terms, but that doesn't seem like a big deal to me, personally.) I think technically you need RFC 8231 to implement the updated PCUpd message we define, which arguably makes it normative as well. (Likewise 8281 for PCInitiate.) We do, however, require RFC 8232 for the Speaker Entity Identifier TLV, which is required in the FLOWSPEC object, so it's clearly a normative reference. |
2020-08-25
|
10 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2020-08-25
|
10 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-08-24
|
10 | Martin Duke | [Ballot comment] I found this document clear to follow, so thanks. I’m somewhat concerned there are no implementations. Nits: Sec 5. Specify the error if … [Ballot comment] I found this document clear to follow, so thanks. I’m somewhat concerned there are no implementations. Nits: Sec 5. Specify the error if more than 1 TLV of any type is present. Sec 7. The text is incomplete for the (*, G) case. |
2020-08-24
|
10 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2020-08-22
|
10 | Erik Kline | [Ballot comment] [ section 2 ] * "a flag is provided to indicate that the sender of a PCEP message that includes a Flow … [Ballot comment] [ section 2 ] * "a flag is provided to indicate that the sender of a PCEP message that includes a Flow Specification is intended to be installed as a Longest Prefix Match route, or..." This didn't scan too well for me. It seems the subject is the sender as written, but perhaps the message itself is the thing that "is intended to be installed..."? Oh, perhaps this is what's meant: "a flag is provided to indicate that the sender of a PCEP message that includes a Flow Specification intends it to be installed as a Longest Prefix Match route or as a Flow Specification policy." [ section 5 ] * Is it well-known whether multibyte numeric fields are network endian or not? [ section 6 ] * "The TLVs follows" -> "The TLVs follow", I think [ section 7 ] * "carries one or more ... TLV" -> "...TLVs." * "defines following new types" -> "defines the following new types" * Purely out of curiosity, if either S=1 or G=1 can/should it be specified that the source/group addresses simply not be included (i.e. the bits indicate not only that the field is not examined but that it's not inclued)? [ section 7.1 ] * "carries one or more ... TLV" -> "...TLVs." [ section 8.4 ] * "will be place on a single tunnel" -> "will be placed into a single tunnel" perhaps? [ section 8.7 ] * Recommend splitting up the long sentence with ", however" -> ". However, ..." * "if the Flow Specification make" -> "if the Flow Specifications make"? * Maybe I've lost too much mental state between readings, but the final paragraph, as written, makes me wonder how a FlowSpec gets installed in the first place. I assume I'm missing something in my naive reading. =) |
2020-08-22
|
10 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2020-08-18
|
10 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. I found the text easy to read albeit sometimes it could be shortened (section … [Ballot comment] Thank you for the work put into this document. I found the text easy to read albeit sometimes it could be shortened (section 1 for example). But, I prefer clarity and ease of read to concise text. I have only one non-blocking comment in section 4: documenting what is the expected behavior when receiving a "Value" != 0 could be helpful (probably the usual 'ignored'). I hope that this helps to improve the document, Regards, -éric |
2020-08-18
|
10 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-08-15
|
10 | Éric Vyncke | Requested Telechat review by INTDIR |
2020-08-14
|
10 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-08-14
|
10 | Cindy Morgan | Placed on agenda for telechat - 2020-08-27 |
2020-08-14
|
10 | Deborah Brungard | IESG state changed to IESG Evaluation from Waiting for Writeup |
2020-08-14
|
10 | Deborah Brungard | Ballot has been issued |
2020-08-14
|
10 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2020-08-14
|
10 | Deborah Brungard | Created "Approve" ballot |
2020-08-14
|
10 | Deborah Brungard | Ballot writeup was changed |
2020-08-03
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-08-03
|
10 | Dhruv Dhody | New version available: draft-ietf-pce-pcep-flowspec-10.txt |
2020-08-03
|
10 | (System) | New version accepted (logged-in submitter: Dhruv Dhody) |
2020-08-03
|
10 | Dhruv Dhody | Uploaded new revision |
2020-07-10
|
09 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Scott Kelly. Submission of review completed at an earlier date. |
2020-07-06
|
09 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-07-05
|
09 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Scott Kelly. |
2020-07-03
|
09 | Joseph Touch | Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Joseph Touch. Sent review to list. |
2020-07-03
|
09 | Joseph Touch | Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Joseph Touch. Sent review to list. |
2020-07-03
|
09 | Roni Even | Request for Last Call review by GENART Completed: Ready. Reviewer: Roni Even. Sent review to list. |
2020-07-02
|
09 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2020-07-02
|
09 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-pce-pcep-flowspec-09. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-pce-pcep-flowspec-09. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are six actions which we must complete. In the PCEP Objects registry on the Path Computation Element Protocol (PCEP) Numbers registry page located at: https://www.iana.org/assignments/pcep/ a new registration will be made as follows: Object-Class | Value Name | Object-Type | Reference Value | | | -------------+-------------+------------------------+---------------- TBD3 | FLOWSPEC | 0: Reserved | [ RFC-to-be ] | | 1: Flow Specification | [ RFC-to-be ] Second, a new subregistry is to be created called the FLOWSPEC Object Flag Field to manage object flags for the PCEP Object created in the first IANA Action above. The subregistry is to be managed via Standard Action as defined in RFC8126. The initial contents of the new registry are: Bit | Description | Reference -----+--------------------+--------------- 0-5 | Unassigned | 6 | LPM (L bit) | [ RFC-to-be ] 7 | Remove (R bit) | [ RFC-to-be ] Third, in the PCEP TLV Type Indicators registry also on the Path Computation Element Protocol (PCEP) Numbers registry page located at: https://www.iana.org/assignments/pcep/ two, new registrations will be made as follows: Value | Description | Reference -----------------------+------------------------------+------------- [ TBD-at-Registration ]| PCE-FLOWSPEC-CAPABILITY TLV | [ RFC-to-be ] [ TBD-at-Registration ]| FLOW FILTER TLV | [ RFC-to-be ] Fourth, a new registry is to be created called the PCEP Flow Specification TLV Type Indicators registry. The new registry will be located on the Path Computation Element Protocol (PCEP) Numbers registry page located at: https://www.iana.org/assignments/pcep/ The assignment policy for the new registry is as follows: Range | Assignment policy ---------------+--------------------------------------------------- 0 | Reserved - must not be allocated. | 1 .. 255 | Reserved - must not be allocated. | Usage mirrors the BGP FlowSpec registry | [I-D.ietf-idr-rfc5575bis] and | [I-D.ietf-idr-flow-spec-v6]. | 256 .. 64506 | Specification Required | 64507 .. 65531 | First Come First Served | 65532 .. 65535 | Experimental There are initial registrations in the new registry in the Specification Required range 256-64506 as follows: Value | Meaning | Reference -----------------------+---------------------+--------------- [ TBD-at-Registration ]| Route Distinguisher | [ RFC-to-be ] [ TBD-at-Registration ]| IPv4 Multicast | [ RFC-to-be ] [ TBD-at-Registration ]| IPv6 Multicast | [ RFC-to-be ] Fifth, in the PCEP-ERROR Object Error Types and Values registry also on the Path Computation Element Protocol (PCEP) Numbers registry page located at: https://www.iana.org/assignments/pcep/ a new registration will be made in the registry as follows: Error-| Meaning | Error-value | Reference Type | | | ------+--------------------+----------------------------+------------- [.tbd]| FlowSpec error | 0: Unassigned |[ RFC-to-be ] | | 1: Unsupported FlowSpec |[ RFC-to-be ] | | 2: Malformed FlowSpec |[ RFC-to-be ] | | 3: Unresolvable Conflict |[ RFC-to-be ] | | 4: Unknown FlowSpec |[ RFC-to-be ] | | 5: Unsupported LPM Route |[ RFC-to-be ] | | 6-255: Unassigned |[ RFC-to-be ] Sixth, in the Path Computation Element (PCE) Capability Flags registry on the Open Shortest Path First v2 (OSPFv2) Parameters registry page located at: https://www.iana.org/assignments/ospfv2-parameters/ a single, new registration is to be made as follows: Bit: [ TBD-at-Registration ] Capability Description: FlowSpec Reference: [ RFC-to-be ] The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2020-07-02
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
2020-07-02
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
2020-06-26
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2020-06-26
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2020-06-25
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Scott Kelly |
2020-06-25
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Scott Kelly |
2020-06-23
|
09 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Joseph Touch |
2020-06-23
|
09 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Joseph Touch |
2020-06-22
|
09 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2020-06-22
|
09 | Cindy Morgan | The following Last Call announcement was sent out (ends 2020-07-06): From: The IESG To: IETF-Announce CC: pce-chairs@ietf.org, db3546@att.com, pce@ietf.org, draft-ietf-pce-pcep-flowspec@ietf.org, Julien … The following Last Call announcement was sent out (ends 2020-07-06): From: The IESG To: IETF-Announce CC: pce-chairs@ietf.org, db3546@att.com, pce@ietf.org, draft-ietf-pce-pcep-flowspec@ietf.org, Julien Meuric , julien.meuric@orange.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (PCEP Extension for Flow Specification) to Proposed Standard The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'PCEP Extension for Flow Specification' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-07-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 instructions 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 XXXX defines the Flow Specification and describes how Flow Specification Components are used to describe traffic flows. RFC XXXX 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. RFC Editor Note: Please replace XXXX in the Abstract with the RFC number assigned to draft-ietf-idr-rfc5575bis when it is published. Please remove this note. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-flowspec/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3840/ |
2020-06-22
|
09 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2020-06-22
|
09 | Deborah Brungard | Last call was requested |
2020-06-22
|
09 | Deborah Brungard | Ballot approval text was generated |
2020-06-22
|
09 | Deborah Brungard | Ballot writeup was generated |
2020-06-22
|
09 | Deborah Brungard | IESG state changed to Last Call Requested from Publication Requested |
2020-06-22
|
09 | Deborah Brungard | Last call announcement was changed |
2020-06-04
|
09 | Julien Meuric | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? -> Proposed Standard Why is this the proper type of RFC? -> It is a specification for a protocol extension. Is this type of RFC indicated in the title page header? -> ST is indicated. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Traffic flows may be categorized and described using "Flow Specifications". RFC 5575bis defines the Flow Specification and describes how Flow Specification Components are used to describe traffic flows. RFC 5575bis 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. Working Group Summary: A post-LC comment pointed out a new requirement that may have been addressed by this extension. The I-D was updated to cover that feature by adding a flag, which managed to bring consensus. Document Quality: Are there existing implementations of the protocol? -> As mentioned in the implementation section: "It is believed that two vendors are considering prototype implementations, but these plans are too vague to make any further assertions." Have a significant number of vendors indicated their plan to implement the specification? -> At least 2. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? -> Vishnu Pavan Beeram raised the comment that triggered the latest changes. If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? -> N/A In the case of a Media Type review, on what date was the request posted? -> N/A Personnel: Who is the Document Shepherd? -> Julien Meuric Who is the Responsible Area Director? -> Deborah Brungard (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. -> The document is well written and the technical specification specification is clear. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? -> No (the I-D has been reviewed by the RTG directorate) (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. -> No (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. -> N/A (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? -> Yes (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. -> Yes. The WG has been requested to share concerns when the IPR was disclosed, no comment was raised. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? -> As this document enhances feature consistency between PCEP and BGP, the agreement may even span beyond the PCE WG. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) -> No (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. -> N/A (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. -> N/A (13) Have all references within this document been identified as either normative or informative? -> Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? -> No (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. -> No (16) Will publication of this document change the status of any existing RFCs? -> No Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. -> N/A (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. -> OK Confirm that any referenced IANA registries have been clearly identified. -> OK Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). -> OK (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. -> N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. -> N/A (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? -> N/A |
2020-06-04
|
09 | Julien Meuric | Responsible AD changed to Deborah Brungard |
2020-06-04
|
09 | Julien Meuric | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2020-06-04
|
09 | Julien Meuric | IESG state changed to Publication Requested from I-D Exists |
2020-06-04
|
09 | Julien Meuric | IESG process started in state Publication Requested |
2020-06-04
|
09 | Julien Meuric | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? -> Proposed Standard Why is this the proper type of RFC? -> It is a specification for a protocol extension. Is this type of RFC indicated in the title page header? -> ST is indicated. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Traffic flows may be categorized and described using "Flow Specifications". RFC 5575bis defines the Flow Specification and describes how Flow Specification Components are used to describe traffic flows. RFC 5575bis 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. Working Group Summary: A post-LC comment pointed out a new requirement that may have been addressed by this extension. The I-D was updated to cover that feature by adding a flag, which managed to bring consensus. Document Quality: Are there existing implementations of the protocol? -> As mentioned in the implementation section: "It is believed that two vendors are considering prototype implementations, but these plans are too vague to make any further assertions." Have a significant number of vendors indicated their plan to implement the specification? -> At least 2. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? -> Vishnu Pavan Beeram raised the comment that triggered the latest changes. If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? -> N/A In the case of a Media Type review, on what date was the request posted? -> N/A Personnel: Who is the Document Shepherd? -> Julien Meuric Who is the Responsible Area Director? -> Deborah Brungard (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. -> The document is well written and the technical specification specification is clear. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? -> No (the I-D has been reviewed by the RTG directorate) (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. -> No (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. -> N/A (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? -> Yes (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. -> Yes. The WG has been requested to share concerns when the IPR was disclosed, no comment was raised. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? -> As this document enhances feature consistency between PCEP and BGP, the agreement may even span beyond the PCE WG. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) -> No (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. -> N/A (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. -> N/A (13) Have all references within this document been identified as either normative or informative? -> Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? -> No (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. -> No (16) Will publication of this document change the status of any existing RFCs? -> No Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. -> N/A (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. -> OK Confirm that any referenced IANA registries have been clearly identified. -> OK Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). -> OK (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. -> N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. -> N/A (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? -> N/A |
2020-06-04
|
09 | Julien Meuric | IPR poll thread: https://mailarchive.ietf.org/arch/msg/pce/ya0xd9MFjUERkAriiL7EPow9Dd0/ |
2020-06-04
|
09 | Julien Meuric | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? -> Proposed Standard Why is this the proper type of RFC? -> It is a specification for a protocol extension. Is this type of RFC indicated in the title page header? -> ST is indicated. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Traffic flows may be categorized and described using "Flow Specifications". RFC 5575bis defines the Flow Specification and describes how Flow Specification Components are used to describe traffic flows. RFC 5575bis 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. Working Group Summary: A post-LC comment pointed out a new requirement that may have been addressed by this extension. The I-D was updated to cover that feature by adding a flag, which managed to bring consensus. Document Quality: Are there existing implementations of the protocol? -> As mentioned in the implementation section: "It is believed that two vendors are considering prototype implementations, but these plans are too vague to make any further assertions." Have a significant number of vendors indicated their plan to implement the specification? -> At least 2. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? -> Vishnu Pavan Beeram raised the comment that triggered the latest changes. If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? -> N/A In the case of a Media Type review, on what date was the request posted? -> N/A Personnel: Who is the Document Shepherd? -> Julien Meuric Who is the Responsible Area Director? -> Deborah Brungard (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. -> The document is well written and the technical specification specification is clear. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? -> No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. -> No (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. -> N/A (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? -> Yes (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. -> Yes. The WG has been requested to share concerns when the IPR was disclosed, no comment was raised. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? -> As this document enhances feature consistency between PCEP and BGP, the agreement may even span beyond the PCE WG. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) -> No (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. -> N/A (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. -> N/A (13) Have all references within this document been identified as either normative or informative? -> Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? -> No (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. -> No (16) Will publication of this document change the status of any existing RFCs? -> No Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. -> N/A (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. -> OK Confirm that any referenced IANA registries have been clearly identified. -> OK Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). -> OK (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. -> N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. -> N/A (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? -> N/A |
2020-06-03
|
09 | Julien Meuric | Tag Other - see Comment Log cleared. |
2020-06-03
|
09 | Julien Meuric | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2020-06-01
|
09 | Adrian Farrel | New version available: draft-ietf-pce-pcep-flowspec-09.txt |
2020-06-01
|
09 | (System) | New version accepted (logged-in submitter: Adrian Farrel) |
2020-06-01
|
09 | Adrian Farrel | Uploaded new revision |
2020-03-04
|
08 | Adrian Farrel | New version available: draft-ietf-pce-pcep-flowspec-08.txt |
2020-03-04
|
08 | (System) | New version accepted (logged-in submitter: Adrian Farrel) |
2020-03-04
|
08 | Adrian Farrel | Uploaded new revision |
2020-01-05
|
07 | Adrian Farrel | New version available: draft-ietf-pce-pcep-flowspec-07.txt |
2020-01-05
|
07 | (System) | New version accepted (logged-in submitter: Adrian Farrel) |
2020-01-05
|
07 | Adrian Farrel | Uploaded new revision |
2019-11-05
|
06 | Julien Meuric | Pending discussion on IPR disclosure |
2019-11-05
|
06 | Julien Meuric | Tags Other - see Comment Log, Doc Shepherd Follow-up Underway set. |
2019-11-05
|
06 | Julien Meuric | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2019-11-02
|
06 | Adrian Farrel | New version available: draft-ietf-pce-pcep-flowspec-06.txt |
2019-11-02
|
06 | (System) | New version accepted (logged-in submitter: Adrian Farrel) |
2019-11-02
|
06 | Adrian Farrel | Uploaded new revision |
2019-11-01
|
Jenny Bui | Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-pce-pcep-flowspec | |
2019-10-22
|
05 | Acee Lindem | Request for Early review by RTGDIR Completed: Has Nits. Reviewer: Acee Lindem. |
2019-10-14
|
05 | Dhruv Dhody | Changed consensus to Yes from Unknown |
2019-10-14
|
05 | Dhruv Dhody | Intended Status changed to Proposed Standard from None |
2019-10-14
|
05 | Dhruv Dhody | Notification list changed to Julien Meuric <julien.meuric@orange.com> |
2019-10-14
|
05 | Dhruv Dhody | Document shepherd changed to Julien Meuric |
2019-10-14
|
05 | Dhruv Dhody | IETF WG state changed to In WG Last Call from WG Document |
2019-09-25
|
05 | Min Ye | Request for Early review by RTGDIR is assigned to Acee Lindem |
2019-09-25
|
05 | Min Ye | Request for Early review by RTGDIR is assigned to Acee Lindem |
2019-09-25
|
05 | Dhruv Dhody | Requested Early review by RTGDIR |
2019-08-15
|
05 | Adrian Farrel | New version available: draft-ietf-pce-pcep-flowspec-05.txt |
2019-08-15
|
05 | (System) | New version approved |
2019-08-15
|
05 | (System) | Request for posting confirmation emailed to previous authors: Adrian Farrel , Dhruv Dhody , Zhenbin Li |
2019-08-15
|
05 | Adrian Farrel | Uploaded new revision |
2019-08-07
|
04 | Adrian Farrel | New version available: draft-ietf-pce-pcep-flowspec-04.txt |
2019-08-07
|
04 | (System) | New version approved |
2019-08-07
|
04 | (System) | Request for posting confirmation emailed to previous authors: Adrian Farrel , Dhruv Dhody , Zhenbin Li |
2019-08-07
|
04 | Adrian Farrel | Uploaded new revision |
2019-02-15
|
03 | Dhruv Dhody | New version available: draft-ietf-pce-pcep-flowspec-03.txt |
2019-02-15
|
03 | (System) | New version approved |
2019-02-15
|
03 | (System) | Request for posting confirmation emailed to previous authors: Adrian Farrel , Dhruv Dhody , Zhenbin Li |
2019-02-15
|
03 | Dhruv Dhody | Uploaded new revision |
2018-10-16
|
02 | Dhruv Dhody | New version available: draft-ietf-pce-pcep-flowspec-02.txt |
2018-10-16
|
02 | (System) | New version approved |
2018-10-16
|
02 | (System) | Request for posting confirmation emailed to previous authors: pce-chairs@ietf.org, Dhruv Dhody , Zhenbin Li , Adrian Farrel |
2018-10-16
|
02 | Dhruv Dhody | Uploaded new revision |
2018-07-02
|
01 | Adrian Farrel | New version available: draft-ietf-pce-pcep-flowspec-01.txt |
2018-07-02
|
01 | (System) | Posted submission manually |
2018-03-18
|
00 | Jonathan Hardwick | This document now replaces draft-li-pce-pcep-flowspec instead of None |
2018-03-18
|
00 | Adrian Farrel | New version available: draft-ietf-pce-pcep-flowspec-00.txt |
2018-03-18
|
00 | (System) | WG -00 approved |
2018-03-18
|
00 | Adrian Farrel | Set submitter to "Adrian Farrel ", replaces to draft-li-pce-pcep-flowspec and sent approval email to group chairs: pce-chairs@ietf.org |
2018-03-18
|
00 | Adrian Farrel | Uploaded new revision |