Skip to main content

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