Dissemination of Flow Specification Rules
draft-ietf-idr-rfc5575bis-27

Received changes through RFC Editor sync (created alias RFC 8955, changed abstract to 'This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.

It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification.

This document obsoletes both RFC 5575 and RFC 7674.', changed pages to 36, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2020-12-31, changed IESG state to RFC Published, created obsoletes relation between draft-ietf-idr-rfc5575bis and RFC 5575, created obsoletes relation between draft-ietf-idr-rfc5575bis and RFC 7674)

[Ballot comment]
[Clearing discuss, for Alvaro to close on the final details].

Hi,

I also had a few minor comments on this document:

4.1.  Length Encoding

  o  If the NLRI length is smaller than 240 (0xf0 hex) octets, the
      length field can be encoded as a single octet.

  o  Otherwise, it is encoded as an extended-length 2-octet value in
      which the most significant nibble of the first octet is all ones.

This describes the first nibble in binary, and then later it is shown in hex.  It might be more clear to write ... in which the most significant nibble has the hex value 0xf.

  In Figure 1 above, values less-than 240 are encoded using two hex
  digits (0xnn).  Values above 239 are encoded using 3 hex digits
  (0xfnnn).  The highest value that can be represented with this
  encoding is 4095.  For example the length value of 239 is encoded as
  0xef (single octet) while 240 is encoded as 0xf0f0 (2-octet).


4.2.  NLRI Value Encoding

  Components MUST follow strict type ordering by increasing numerical
  order.  A given component type may (exactly once) or may not be
  present in the Flow Specification.  If present, it MUST precede any
  component of higher numeric type value.

I wasn't sure, but wondering whether "may (exactly once) or may not be" should be "MAY (exactly once) be"?


5.1.  Ordering of Flow Specifications

  For all other component types, unless otherwise specified, the
  comparison is performed by comparing the component data as a binary
  string using the memcmp() function as defined by [ISO_IEC_9899].  For
  strings with equal lengths the lowest string (memcmp) has higher
  precedence.  For strings of different lengths, the common prefix is
  compared.  If the common prefix is not equal the string with the
  lowest prefix has higher precedence.  If the common prefix is equal,
  the longest string is considered to have higher precedence than the
  shorter one.

I think that the intended comparison here is clear, but I was wondering whether this text should flag endian concerns at all.  E.g. if the component data has been stored in memory and any numeric values have had endian conversion performed on them then a naive memcmp() could give a different answer.

Previous discuss comment:
I don't know if this is a valid discuss point, so happy to be educated that it is always written this way and I'll remove my discuss ...

I note that in 5 places this document has text that states the equivalent to "SHOULD be set to 0 on encoding, and MUST be ignored during decoding." (example given below).

Doesn't this make extending this in future more risky because if new meaning are given to these bits then there could be senders already transmitting non 0 values which a receiver might then misinterpret?

Hence, I was surprised that the constraints did not also include a MUST on the encoding side (i.e. be strict in what you send ...), i.e. "MUST be set to 0 on encoding, and MUST be ignored during decoding."

Example:
  The extended is encoded as follows:

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  reserved    |  reserved    |  reserved    |  reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  reserved    | r.|    DSCP  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 6: Traffic Marking Extended Community Encoding

  o  DSCP: new DSCP value for the transiting IP packet.

  o  reserved, r.: SHOULD be set to 0 on encoding, and MUST be ignored
      during decoding.

[Ballot comment]
Thank you for the work put into this document. The document is clear, easy to read (I appreciated the given examples).

After discussion with the responsible AD, Alvaro Retana, and the IDR WG chairs, I am clearing my DISCUSS (kept below for archival purpose) based on the promise that the IPv6 companion document will be 'expedite processed' by the WG chairs, document shepherd, and responsible AD + request for prompt processing by the RFC Editor. The final goal is to have this document and its IPv6 companion published roughly at the same time. (I still wonder why making two documents though ;-) ).

Thanks to all for quickly updating the list of IPv6 implementations, that opened the gate for publication.

-éric

-- below is no more current as the DISCUSS is cleared --

Why having two different documents ? One for IPv4 (with the core elements of the protocol) and one for IPv6 (with only the IPv6 specifics)... I am more than surprized to say the least... hence my DISCUSS...

This blocking DISCUSS can easily be fixed: e.g., with a RFC Editor note to make a cluster of this document and draft-ietf-idr-flow-spec-v6 so that they are published together with adjacent RFC numbers. Merging the two documents would be preferred but I understand that this is more work (albeit a missed opportunity).

Please find below a couple on non-blocking COMMENTs.

I hope that this helps to improve the document,

Regards,

-éricI also second Erik K.'s comment on non-TCP/UDP ports.

[Ballot discuss]
Thank you for the work put into this document. The document is clear, easy to read (I appreciated the given examples).

Alas, due to overload of work, I had only a quick browse through the document with specific focus points and found nothing EXCEPT why having two different documents ? One for IPv4 (with the core elements of the protocol) and one for IPv6 (with only the IPv6 specifics)... I am more than surprized to say the least... hence my DISCUSS...

This blocking DISCUSS can easily be fixed: e.g., with a RFC Editor note to make a cluster of this document and draft-ietf-idr-flow-spec-v6 so that they are published together with adjacent RFC numbers. Merging the two documents would be preferred but I understand that this is more work (albeit a missed opportunity).

Please find below a couple on non-blocking COMMENTs.

I hope that this helps to improve the document,

Regards,

-éric

[Ballot discuss]
Thank you for the work put into this document. The document is clear, easy to read (I appreciated the given examples). Alas, due to overload of work, I had only a quick browse through the document with specific focus points and found nothing EXCEPT why having two different documents ? One for IPv4 and one for IPv6... I am more than surprized... hence my DISCUSS...

This blocking DISCUSS can easily be fixed: e.g., with a RFC Editor note to make a cluster of this document and draft-ietf-idr-flow-spec-v6 so that they are published together with adjacent RFC numbers.

Please find below a couple on non-blocking COMMENTs.

I hope that this helps to improve the document,

Regards,

-éric

[Ballot comment]
Hi,

I also had a few minor comments on this document:

4.1.  Length Encoding

  o  If the NLRI length is smaller than 240 (0xf0 hex) octets, the
      length field can be encoded as a single octet.

  o  Otherwise, it is encoded as an extended-length 2-octet value in
      which the most significant nibble of the first octet is all ones.

This describes the first nibble in binary, and then later it is shown in hex.  It might be more clear to write ... in which the most significant nibble has the hex value 0xf.

  In Figure 1 above, values less-than 240 are encoded using two hex
  digits (0xnn).  Values above 239 are encoded using 3 hex digits
  (0xfnnn).  The highest value that can be represented with this
  encoding is 4095.  For example the length value of 239 is encoded as
  0xef (single octet) while 240 is encoded as 0xf0f0 (2-octet).


4.2.  NLRI Value Encoding

  Components MUST follow strict type ordering by increasing numerical
  order.  A given component type may (exactly once) or may not be
  present in the Flow Specification.  If present, it MUST precede any
  component of higher numeric type value.

I wasn't sure, but wondering whether "may (exactly once) or may not be" should be "MAY (exactly once) be"?


5.1.  Ordering of Flow Specifications

  For all other component types, unless otherwise specified, the
  comparison is performed by comparing the component data as a binary
  string using the memcmp() function as defined by [ISO_IEC_9899].  For
  strings with equal lengths the lowest string (memcmp) has higher
  precedence.  For strings of different lengths, the common prefix is
  compared.  If the common prefix is not equal the string with the
  lowest prefix has higher precedence.  If the common prefix is equal,
  the longest string is considered to have higher precedence than the
  shorter one.

I think that the intended comparison here is clear, but I was wondering whether this text should flag endian concerns at all.  E.g. if the component data has been stored in memory and any numeric values have had endian conversion performed on them then a naive memcmp() could give a different answer.

[Ballot discuss]
I don't know if this is a valid discuss point, so happy to be educated that it is always written this way and I'll remove my discuss ...

I note that in 5 places this document has text that states the equivalent to "SHOULD be set to 0 on encoding, and MUST be ignored during decoding." (example given below).

Doesn't this make extending this in future more risky because if new meaning are given to these bits then there could be senders already transmitting non 0 values which a receiver might then misinterpret?

Hence, I was surprised that the constraints did not also include a MUST on the encoding side (i.e. be strict in what you send ...), i.e. "MUST be set to 0 on encoding, and MUST be ignored during decoding."

Example:
  The extended is encoded as follows:

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  reserved    |  reserved    |  reserved    |  reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  reserved    | r.|    DSCP  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 6: Traffic Marking Extended Community Encoding

  o  DSCP: new DSCP value for the transiting IP packet.

  o  reserved, r.: SHOULD be set to 0 on encoding, and MUST be ignored
      during decoding.

[Ballot comment]
Hi,

I also had a few minor comments on this document:

4.1.  Length Encoding

  o  If the NLRI length is smaller than 240 (0xf0 hex) octets, the
      length field can be encoded as a single octet.

  o  Otherwise, it is encoded as an extended-length 2-octet value in
      which the most significant nibble of the first octet is all ones.

This describes the first nibble in binary, and then later it is shown in hex.  It might be more clear to write ... in which the most significant nibble has the hex value 0xf.

  In Figure 1 above, values less-than 240 are encoded using two hex
  digits (0xnn).  Values above 239 are encoded using 3 hex digits
  (0xfnnn).  The highest value that can be represented with this
  encoding is 4095.  For example the length value of 239 is encoded as
  0xef (single octet) while 240 is encoded as 0xf0f0 (2-octet).


4.2.  NLRI Value Encoding

  Components MUST follow strict type ordering by increasing numerical
  order.  A given component type may (exactly once) or may not be
  present in the Flow Specification.  If present, it MUST precede any
  component of higher numeric type value.

I wasn't sure, but wondering whether "may (exactly once) or may not be" should be "MAY (exactly once) be"?

5.1.  Ordering of Flow Specifications

  For all other component types, unless otherwise specified, the
  comparison is performed by comparing the component data as a binary
  string using the memcmp() function as defined by [ISO_IEC_9899].  For
  strings with equal lengths the lowest string (memcmp) has higher
  precedence.  For strings of different lengths, the common prefix is
  compared.  If the common prefix is not equal the string with the
  lowest prefix has higher precedence.  If the common prefix is equal,
  the longest string is considered to have higher precedence than the
  shorter one.

I think that the intended comparison here is clear, but I was wondering whether this text should flag endian concerns at all.  E.g. if the component data has been stored in memory and any numeric values have had endian conversion performed on them then a naive memcmp() could give a different answer.

[Ballot comment]
[cleared Discuss, as I was indeed misunderstanding things]

The Abstract is perhaps pushing the length limits appropriate for an
Abstract (vs. Introduction).

Abstract

  Additionally, it defines two applications of that encoding format:
  one that can be used to automate inter-domain coordination of traffic
  filtering, such as what is required in order to mitigate
  (distributed) denial-of-service attacks, and a second application to

This makes me think of the DOTS WG (but it's far from clear that we should
reference it in this text).

Section 1

  This document obsoletes "Dissemination of Flow Specification Rules"
  [RFC5575], the differences can be found in Appendix B.  This document

nit: comma splice

  A Flow Specification received from an external autonomous system will
  need to be validated against unicast routing before being accepted
  (Section 6).  The Flow Specification received from an internal BGP
  peer within the same autonomous system [RFC4271] is assumed to have
  been validated prior to transmission within the internal BGP (iBGP)
  mesh of an autonomous system.  If the aggregate traffic flow defined

(Just to check, there's no particular harm in also validating iBGP
flowspecs, just the extra computation burden of doing so, right?)

  systems that are able to detect malicious traffic flows.  When
  automated systems are used, care should be taken to ensure their
  correctness as well as the limitations of the systems that receive
  and process the advertised Flow Specifications (see also Section 12).

This seems to discuss making sure that the recipients of automated
information handle it robustly; is it also worth some considerations on
robustness of generating such automated information (something akin to a
circuit breaker that would shut off the source if it started producing
nonsensical output)?
Also, nit: I think I parse this as "care should be taken to ensure [...] the
limitations of the systems that receive and process [flowspecs]", which
doesn't quite seem like what was intended.

Section 4

  The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as
  one or more 2-tuples of the form .  It consists
  of a 1- or 2-octet length field followed by a variable-length NLRI
  value.  The length is expressed in octets.

RFC 4760 only shows the one-octet length form; is there a good reference for
the 2-octet length?  (Or is it "new" with 5575?)

Section 4.2

I think we should say something about how multi-byte values are encoded,
especially given that we implicitly allow for different encodings of a given
value (e.g., IP protocol could have padding, and small port numbers don't
need to be encoded in 2 bytes).  Even just making it more explicit that
multiple encodings are allowed (and what the semantics are for any such
"padding") would be worthwhile.  Is there a maximum encoded length for
anything other than the constraints of the 2-bit 'len' field?
Interestingly, for DCSP we are much more strict -- why is the strictness
needed there but not in general?  Is this just to faithfully reproduce RFC
5575, as implied by the discussion in Appendix B?
(I would make this a DISCUSS point if I didn't think that we're acting as if
we're required to preserve the RFC 5575 behavior.)

  A NLRI value not encoded as specified in Section 4.2 is considered

This *is* Section 4.2; perhaps "specified here" or "specified below"?

Section 4.2.1.1, 4.2.1.2

While I don't anticipate needing a future extension to numeric_op, having
the '0' field only be "SHOULD be set to 0" (vs. "MUST") seems to hamper any
future extensibility efforts.
(Similarly for the "Traffic-action" field in Section 7.3, and
"Traffic-marking" from Section 7.5.)

Section 4.2.2.3

  This component uses the Numeric Operator (numeric_op) described in
  Section 4.2.1.1.  Type 3 component values SHOULD be encoded as single
  octet (numeric_op len=00).

Is it well-defined how I would encode the value if I ignored the SHOULD?
I, for one, am not sure what I would do...

Section 4.2.2.4, etc.

(I agree with my esteemed colleagues that hardcoding TCP and UDP as
"the only protocols with ports" is unnecessary.)

  system is unable to locate the transport header.  Different
  implementations may or may not be able to decode the transport header
  in the presence of IP options or Encapsulating Security Payload (ESP)
  NULL [RFC4303] encryption.

If an implementation cannot decode the transport header does it treat all
such packets as matching or not matching?

Section 4.2.2.7

  In case of the presence of the ICMP type (code) component only ICMP
  packets can match the entire Flow Specification.  The ICMP type

I'm not sure why the parenthetical is needed given that there's a separate
NRLI type for "ICMP code".

Section 5.1

  component type.  If the component types are the same, then a type-
  specific comparison is performed (see below) if the types are equal
  the algorithm continues with the next component.

nit: there seems to be some missing punctuation or conjunction here.

  For all other component types, unless otherwise specified, the
  comparison is performed by comparing the component data as a binary
  string using the memcmp() function as defined by [ISO_IEC_9899].  For
  strings with equal lengths the lowest string (memcmp) has higher
  precedence.  For strings of different lengths, the common prefix is
  compared.  If the common prefix is not equal the string with the
  lowest prefix has higher precedence.  If the common prefix is equal,
  the longest string is considered to have higher precedence than the
  shorter one.

It is surprising to me that the comparison operator can return "not-equal"
for different encodings of a quantity that have the same semantic value
(viz my previous note about encoding flexibility).  That said, this
procedure is well-defined and BGP speakers are not going to be re-encoding
the NRLI values as they propagate, so I don't see an interop problem.

Section 6

  By default a Flow Specification NLRI MUST be validated such that it
  is considered feasible if and only if all of the below is true:

Perhaps "in the absence of explicit configuration otherwise," to more
closely parallel the other case?

  BGP implementations MUST also enforce that the AS_PATH attribute of a
  route received via the External Border Gateway Protocol (eBGP)
  contains the neighboring AS in the left-most position of the AS_PATH
  attribute.  While this rule is optional in the BGP specification, it
  becomes necessary to enforce it for security reasons.

nit: missing word (e.g., "necessary to enforce it here" or "necessary to
enforce it in processing flow specifications").

  The best-match unicast route may change over the time independently
  of the Flow Specification NLRI.  Therefore, a revalidation of the
  Flow Specification NLRI MUST be performed whenever unicast routes
  change.  Revalidation is defined as retesting that clause a and
  clause b above are true.

IMPORTANT: Why does clause c not need to be retested?

  The neighboring AS is the immediate destination of the traffic
  described by the Flow Specification.  If it requests these flows to
  be dropped, that request can be honored without concern that it
  represents a denial of service in itself.  Supposedly, the traffic is
  being dropped by the downstream autonomous system, and there is no
  added value in carrying the traffic to it.

(This presumes that there is some integrity protection applied to the
received data, which might be worth making more explicit.)
Also, nit: I'd suggest s/Supposedly,/The reasoning is that this is as if/

Section 7

Please be consistent about "ASN" vs. "AS" in Table 2.

Should the "traffic-action" and "traffic-marking" actions list the encoded
length for the reader's convenience?

Section 7.1

  The remaining 4 octets carry the maximum rate information in IEEE
  floating point [IEEE.754.1985] format, units being bytes per second.

Thank you for being clear about the units!

Section 7.2

Is there anything to say about what time interval a non-integer packet rate
should be evaluated over?

Section 7.3

  o  T: Terminal Action (bit 47): When this bit is set, the traffic
      filtering engine will evaluate any subsequent Flow Specifications
      (as defined by the ordering procedure Section 5.1).  If not set,
      the evaluation of the traffic filters stops when this Flow
      Specification is evaluated.

Just to check I'm reading this right: when the "terminal action" bit is set
to one, it is *not* the terminal action, and the action *is* the terminal
action when the "terminal action" bit is set to zero?  That sounds
backwards to my intuition (and maybe others'?).

Section 7.4

  Interferes with: No other BGP Flow Specification Traffic Filtering
  Action in this document.

Do the different possible 'type's for this 'sub-type' interfere with each
other?

Section 7.6

  Implementations should provide mechanisms that map an arbitrary BGP
  community value (normal or extended) to Traffic Filtering Actions
  that require different mappings in different systems in the network.

nit(?): to my eye this reads better as "on different systems" (vs. "in").

  For instance, providing packets with a worse-than-best-effort, per-
  hop behavior is a functionality that is likely to be implemented

nit: no comma after worst-than-best-effort.

Section 7.7

  other (e.g. there may be more than one conflicting traffic-rate-bytes
  Traffic Filtering Action associated with a single Flow
  Specification).  Traffic Filtering Action interference has no impact

Maybe we should revise the earlier text about "Interferes with: No other
[...]" to be explicit that it *does* self-interfere.

  behaviour (ie. match - replace - delete communities on administrative
  boundaries).  See also Section 12.

nit: could this parenthetical be expanded a little bit more?  I feel like
it's expected to be common knowledge among the main readership and so the
current wording just serves as a trigger for this "well-known" (but not to
me) concept, as opposed to standing on its own.

Section 8

[side note: I'd love for us to eventually stop using "VPN" for things that
don't encrypt the data passing over them.  This doesn't seem like the right
place to start, though.]

Section 9

Should either/both of these mechanisms be on or off by default?

Section 12

I'd consider mentioning again that some of the NRLI components won't work
properly on fragmented traffic and that unexpected fragmentation can cause
DoS.  (This is particularly relevant for IPv4, as opposed to IPv6, where
fragmentation can occur anywhere on the path.)

Is it worth saying anything about how the RT-redirect actions can direct
traffic to an entity not expecting it (and, as such, potentially DoS them)?

It also struck me as noteworthy that we're letting DSCP values creep out of
a single administrative scope -- the filtering of inbound DSCP markings
should probably be consistent with the traffic markings advertised to that
peer.  (There is perhaps also some "information leakage" as to what
semantics are assigned to given DSCP values within the network in question,
but I find it hard to get too worked up about that, especially since the
inter-AS relationship is inherently pretty trusted.)

  As long as Flow Specifications are restricted to match the
  corresponding unicast routing paths for the relevant prefixes
  (Section 6), the security characteristics of this proposal are

[There's an implicit "and both are received over trustworthy channels" in
here.  Perhaps it's okay to remain implicit, given how well-known BGP's
security properties are...]

  Where the above mechanisms are not in place, this could open the door
  to further denial-of-service attacks such as unwanted traffic
  filtering, remarking or redirection.

nit(?): I might just say "In particular, relaxing the validation procedure
could [...]".

  additional filtering.  For example, the use of [RFC6811] to enhance
  filtering within an AS confederation.

nit: incomplete sentence.

  Inter-provider routing is based on a web of trust.  Neighboring
  autonomous systems are trusted to advertise valid reachability
  information.  If this trust model is violated, a neighboring
  autonomous system may cause a denial-of-service attack by advertising
  reachability information for a given prefix for which it does not

I guess it's also a well-known attack that malicious neighbor could also
draw traffic to itself for snooping purposes without actually dropping the
traffic.  But I'm not sure if there are any flowspec-specific considerations
relating to that scenario.

  provide service (unfiltered address space hijack).  Since validation
  of the Flow Specification is tied to the announcement of the best
  unicast route, this may also cause this validation to fail and
  consequently prevent Flow Specifications from being accepted by a
  peer.  Possible mitigations are [RFC6811] and [RFC8205].

nit: there's a lot of pronouns ("this") in here; it might be worth
disambiguating a couple.

  Flow Specification BGP speakers (e.g. automated DDoS controllers) not
  properly programmed, algorithms that are not performing as expected,
  or simply rogue systems may announce unintended Flow Specifications,
  send updates at a high rate or generate a high number of Flow
  Specifications.  This may stress the receiving systems, exceed their
  maximum capacity or may lead to unwanted Traffic Filtering Actions
  being applied to flows.

Is there any relevant guidance to give to receiving systems?

Appendix A

I don't know that just this one function is useful without some description
of what format of input it requires.  For example, if a.components and/or
b.components have elements that evaluate to "false", the first two checks
could return incorrect results (the perhaps-more-obvious case where both
comp_a and comp_b are None cannot happen due to the nature of zip_longest).

Appendix B

      Section 7 defines all Traffic Filtering Action Extended
      communities as transitive extended communities.  [RFC5575] defined
      the traffic-rate action to be non-transitive and did not define
      the transitivity of the other Traffic Filtering Action communities
      at all.

I assume the consequences of changing a community from non-transitive to
transitive are well-known (but not to me) and that any operational
considerations for mixed deployments are already stated somewhere prominent
to someone working with BGP.  (Where is that?)

      Section 7.7 contains general considerations on interfering traffic
      actions.  Section 7.3 also cross-references this section.

nit(?): the last "this section" refers to 7.7, not the location of the text
I'm quoting from (Appendix B).  I misread it the first time.

[Ballot discuss]
There might be a minor internal inconsistency to tidy up (or I might be
misunderstanding things).  Section 8 states that:

  Contrary to the behavior specified for the non-VPN NLRI, Flow
  Specifications are accepted by default, when received from remote PE
  routers.

As far as I can tell, this is referring to the text in Section 6 where (for
the non-VPN case) "By default a Flow Specification NLRI MUST be validated
such that it is considered feasible if and only if all of the below is true
[...]".  But immediately following what I quote above is a statement that
"the validation proceure (section 6) [...] [is] the same as for IPv4", which
seems to be in conflict with this statement ("contrary to" vs. "the same
as").

[Ballot comment]
The Abstract is perhaps pushing the length limits appropriate for an
Abstract (vs. Introduction).

Abstract

  Additionally, it defines two applications of that encoding format:
  one that can be used to automate inter-domain coordination of traffic
  filtering, such as what is required in order to mitigate
  (distributed) denial-of-service attacks, and a second application to

This makes me think of the DOTS WG (but it's far from clear that we should
reference it in this text).

Section 1

  This document obsoletes "Dissemination of Flow Specification Rules"
  [RFC5575], the differences can be found in Appendix B.  This document

nit: comma splice

  A Flow Specification received from an external autonomous system will
  need to be validated against unicast routing before being accepted
  (Section 6).  The Flow Specification received from an internal BGP
  peer within the same autonomous system [RFC4271] is assumed to have
  been validated prior to transmission within the internal BGP (iBGP)
  mesh of an autonomous system.  If the aggregate traffic flow defined

(Just to check, there's no particular harm in also validating iBGP
flowspecs, just the extra computation burden of doing so, right?)

  systems that are able to detect malicious traffic flows.  When
  automated systems are used, care should be taken to ensure their
  correctness as well as the limitations of the systems that receive
  and process the advertised Flow Specifications (see also Section 12).

This seems to discuss making sure that the recipients of automated
information handle it robustly; is it also worth some considerations on
robustness of generating such automated information (something akin to a
circuit breaker that would shut off the source if it started producing
nonsensical output)?
Also, nit: I think I parse this as "care should be taken to ensure [...] the
limitations of the systems that receive and process [flowspecs]", which
doesn't quite seem like what was intended.

Section 4

  The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as
  one or more 2-tuples of the form .  It consists
  of a 1- or 2-octet length field followed by a variable-length NLRI
  value.  The length is expressed in octets.

RFC 4760 only shows the one-octet length form; is there a good reference for
the 2-octet length?  (Or is it "new" with 5575?)

Section 4.2

I think we should say something about how multi-byte values are encoded,
especially given that we implicitly allow for different encodings of a given
value (e.g., IP protocol could have padding, and small port numbers don't
need to be encoded in 2 bytes).  Even just making it more explicit that
multiple encodings are allowed (and what the semantics are for any such
"padding") would be worthwhile.  Is there a maximum encoded length for
anything other than the constraints of the 2-bit 'len' field?
Interestingly, for DCSP we are much more strict -- why is the strictness
needed there but not in general?  Is this just to faithfully reproduce RFC
5575, as implied by the discussion in Appendix B?
(I would make this a DISCUSS point if I didn't think that we're acting as if
we're required to preserve the RFC 5575 behavior.)

  A NLRI value not encoded as specified in Section 4.2 is considered

This *is* Section 4.2; perhaps "specified here" or "specified below"?

Section 4.2.1.1, 4.2.1.2

While I don't anticipate needing a future extension to numeric_op, having
the '0' field only be "SHOULD be set to 0" (vs. "MUST") seems to hamper any
future extensibility efforts.
(Similarly for the "Traffic-action" field in Section 7.3, and
"Traffic-marking" from Section 7.5.)

Section 4.2.2.3

  This component uses the Numeric Operator (numeric_op) described in
  Section 4.2.1.1.  Type 3 component values SHOULD be encoded as single
  octet (numeric_op len=00).

Is it well-defined how I would encode the value if I ignored the SHOULD?
I, for one, am not sure what I would do...

Section 4.2.2.4, etc.

(I agree with my esteemed colleagues that hardcoding TCP and UDP as
"the only protocols with ports" is unnecessary.)

  system is unable to locate the transport header.  Different
  implementations may or may not be able to decode the transport header
  in the presence of IP options or Encapsulating Security Payload (ESP)
  NULL [RFC4303] encryption.

If an implementation cannot decode the transport header does it treat all
such packets as matching or not matching?

Section 4.2.2.7

  In case of the presence of the ICMP type (code) component only ICMP
  packets can match the entire Flow Specification.  The ICMP type

I'm not sure why the parenthetical is needed given that there's a separate
NRLI type for "ICMP code".

Section 5.1

  component type.  If the component types are the same, then a type-
  specific comparison is performed (see below) if the types are equal
  the algorithm continues with the next component.

nit: there seems to be some missing punctuation or conjunction here.

  For all other component types, unless otherwise specified, the
  comparison is performed by comparing the component data as a binary
  string using the memcmp() function as defined by [ISO_IEC_9899].  For
  strings with equal lengths the lowest string (memcmp) has higher
  precedence.  For strings of different lengths, the common prefix is
  compared.  If the common prefix is not equal the string with the
  lowest prefix has higher precedence.  If the common prefix is equal,
  the longest string is considered to have higher precedence than the
  shorter one.

It is surprising to me that the comparison operator can return "not-equal"
for different encodings of a quantity that have the same semantic value
(viz my previous note about encoding flexibility).  That said, this
procedure is well-defined and BGP speakers are not going to be re-encoding
the NRLI values as they propagate, so I don't see an interop problem.

Section 6

  By default a Flow Specification NLRI MUST be validated such that it
  is considered feasible if and only if all of the below is true:

Perhaps "in the absence of explicit configuration otherwise," to more
closely parallel the other case?

  BGP implementations MUST also enforce that the AS_PATH attribute of a
  route received via the External Border Gateway Protocol (eBGP)
  contains the neighboring AS in the left-most position of the AS_PATH
  attribute.  While this rule is optional in the BGP specification, it
  becomes necessary to enforce it for security reasons.

nit: missing word (e.g., "necessary to enforce it here" or "necessary to
enforce it in processing flow specifications").

  The best-match unicast route may change over the time independently
  of the Flow Specification NLRI.  Therefore, a revalidation of the
  Flow Specification NLRI MUST be performed whenever unicast routes
  change.  Revalidation is defined as retesting that clause a and
  clause b above are true.

IMPORTANT: Why does clause c not need to be retested?

  The neighboring AS is the immediate destination of the traffic
  described by the Flow Specification.  If it requests these flows to
  be dropped, that request can be honored without concern that it
  represents a denial of service in itself.  Supposedly, the traffic is
  being dropped by the downstream autonomous system, and there is no
  added value in carrying the traffic to it.

(This presumes that there is some integrity protection applied to the
received data, which might be worth making more explicit.)
Also, nit: I'd suggest s/Supposedly,/The reasoning is that this is as if/

Section 7

Please be consistent about "ASN" vs. "AS" in Table 2.

Should the "traffic-action" and "traffic-marking" actions list the encoded
length for the reader's convenience?

Section 7.1

  The remaining 4 octets carry the maximum rate information in IEEE
  floating point [IEEE.754.1985] format, units being bytes per second.

Thank you for being clear about the units!

Section 7.2

Is there anything to say about what time interval a non-integer packet rate
should be evaluated over?

Section 7.3

  o  T: Terminal Action (bit 47): When this bit is set, the traffic
      filtering engine will evaluate any subsequent Flow Specifications
      (as defined by the ordering procedure Section 5.1).  If not set,
      the evaluation of the traffic filters stops when this Flow
      Specification is evaluated.

Just to check I'm reading this right: when the "terminal action" bit is set
to one, it is *not* the terminal action, and the action *is* the terminal
action when the "terminal action" bit is set to zero?  That sounds
backwards to my intuition (and maybe others'?).

Section 7.4

  Interferes with: No other BGP Flow Specification Traffic Filtering
  Action in this document.

Do the different possible 'type's for this 'sub-type' interfere with each
other?

Section 7.6

  Implementations should provide mechanisms that map an arbitrary BGP
  community value (normal or extended) to Traffic Filtering Actions
  that require different mappings in different systems in the network.

nit(?): to my eye this reads better as "on different systems" (vs. "in").

  For instance, providing packets with a worse-than-best-effort, per-
  hop behavior is a functionality that is likely to be implemented

nit: no comma after worst-than-best-effort.

Section 7.7

  other (e.g. there may be more than one conflicting traffic-rate-bytes
  Traffic Filtering Action associated with a single Flow
  Specification).  Traffic Filtering Action interference has no impact

Maybe we should revise the earlier text about "Interferes with: No other
[...]" to be explicit that it *does* self-interfere.

  behaviour (ie. match - replace - delete communities on administrative
  boundaries).  See also Section 12.

nit: could this parenthetical be expanded a little bit more?  I feel like
it's expected to be common knowledge among the main readership and so the
current wording just serves as a trigger for this "well-known" (but not to
me) concept, as opposed to standing on its own.

Section 8

[side note: I'd love for us to eventually stop using "VPN" for things that
don't encrypt the data passing over them.  This doesn't seem like the right
place to start, though.]

Section 9

Should either/both of these mechanisms be on or off by default?

Section 12

I'd consider mentioning again that some of the NRLI components won't work
properly on fragmented traffic and that unexpected fragmentation can cause
DoS.  (This is particularly relevant for IPv4, as opposed to IPv6, where
fragmentation can occur anywhere on the path.)

Is it worth saying anything about how the RT-redirect actions can direct
traffic to an entity not expecting it (and, as such, potentially DoS them)?

It also struck me as noteworthy that we're letting DSCP values creep out of
a single administrative scope -- the filtering of inbound DSCP markings
should probably be consistent with the traffic markings advertised to that
peer.  (There is perhaps also some "information leakage" as to what
semantics are assigned to given DSCP values within the network in question,
but I find it hard to get too worked up about that, especially since the
inter-AS relationship is inherently pretty trusted.)

  As long as Flow Specifications are restricted to match the
  corresponding unicast routing paths for the relevant prefixes
  (Section 6), the security characteristics of this proposal are

[There's an implicit "and both are received over trustworthy channels" in
here.  Perhaps it's okay to remain implicit, given how well-known BGP's
security properties are...]

  Where the above mechanisms are not in place, this could open the door
  to further denial-of-service attacks such as unwanted traffic
  filtering, remarking or redirection.

nit(?): I might just say "In particular, relaxing the validation procedure
could [...]".

  additional filtering.  For example, the use of [RFC6811] to enhance
  filtering within an AS confederation.

nit: incomplete sentence.

  Inter-provider routing is based on a web of trust.  Neighboring
  autonomous systems are trusted to advertise valid reachability
  information.  If this trust model is violated, a neighboring
  autonomous system may cause a denial-of-service attack by advertising
  reachability information for a given prefix for which it does not

I guess it's also a well-known attack that malicious neighbor could also
draw traffic to itself for snooping purposes without actually dropping the
traffic.  But I'm not sure if there are any flowspec-specific considerations
relating to that scenario.

  provide service (unfiltered address space hijack).  Since validation
  of the Flow Specification is tied to the announcement of the best
  unicast route, this may also cause this validation to fail and
  consequently prevent Flow Specifications from being accepted by a
  peer.  Possible mitigations are [RFC6811] and [RFC8205].

nit: there's a lot of pronouns ("this") in here; it might be worth
disambiguating a couple.

  Flow Specification BGP speakers (e.g. automated DDoS controllers) not
  properly programmed, algorithms that are not performing as expected,
  or simply rogue systems may announce unintended Flow Specifications,
  send updates at a high rate or generate a high number of Flow
  Specifications.  This may stress the receiving systems, exceed their
  maximum capacity or may lead to unwanted Traffic Filtering Actions
  being applied to flows.

Is there any relevant guidance to give to receiving systems?

Appendix A

I don't know that just this one function is useful without some description
of what format of input it requires.  For example, if a.components and/or
b.components have elements that evaluate to "false", the first two checks
could return incorrect results (the perhaps-more-obvious case where both
comp_a and comp_b are None cannot happen due to the nature of zip_longest).

Appendix B

      Section 7 defines all Traffic Filtering Action Extended
      communities as transitive extended communities.  [RFC5575] defined
      the traffic-rate action to be non-transitive and did not define
      the transitivity of the other Traffic Filtering Action communities
      at all.

I assume the consequences of changing a community from non-transitive to
transitive are well-known (but not to me) and that any operational
considerations for mixed deployments are already stated somewhere prominent
to someone working with BGP.  (Where is that?)

      Section 7.7 contains general considerations on interfering traffic
      actions.  Section 7.3 also cross-references this section.

nit(?): the last "this section" refers to 7.7, not the location of the text
I'm quoting from (Appendix B).  I misread it the first time.

[Ballot comment]
Thank you, this is a useful document.

I have two minor comments:
“ Modern IP routers contain both the capability to forward traffic according to IP prefixes ...”
For some reason the “according to IP prefixes” scans oddly to me - the rest of the actions are also (largely) “according to ip prefixes” - this is more of a nit / preference, but I think it would be better to just drop that phrase.

“ This      specification has removed all references to a opaque-key property.      BGP is able to understand the NLRI encoding.”
2 nits:
1: a opaque-key -> an opaque-key (or the opaque-key)
2: BGP is able to... seems a bit odd - BGP is just a protocol, it doesn’t really understand *anything*. I think that a better option would be best “BGP implementations are”. Again this is just a nit, feel free to address it or not...

[Ballot discuss]
Apologies as this may be a really silly question, but isn't it possible for traffic-rate-bytes and traffic-rate-packets to interfere with each other? That is, if by mistake a flow specification shows up containing both actions and they contradict each other (e.g., 0 bytes but 1M packets), how is that situation supposed to be handled?

[Ballot comment]
All of this is editorial:

— Abstract —

  Other applications (ie. centralized control of traffic in a SDN or
  NFV context) are also possible.

I don’t think you mean “i.e.” here, but “e.g.”  I would avoid the Latin (for exactly this reason: many people don’t understand it and misuse it) and say, “Other applications, such as centralized control of traffic in an SDN or NFV context, are also possible.”

— Section 1 —

  Modern IP routers contain both the capability to forward traffic
  according to IP prefixes as well as to classify, shape, rate limit,
  filter, or redirect packets based on administratively defined

The two things that come after “both” have to be parallel, and they’re not.  This will read better without the word “both”, like this:

NEW
  Modern IP routers have the capabilities to forward traffic
  according to IP prefixes and to classify, shape, rate limit,
  filter, or redirect packets based on administratively defined
END

  Section 4 of this document defines a general procedure to encode Flow
  Specification for aggregated traffic flows so that they can be
  distributed as a BGP [RFC4271] NLRI.

I think this has to say “Flow Specifications”, plural, yes?  That matches “they”.

  automated systems are used, care should be taken to ensure their
  correctness as well as the limitations of the systems that receive
  and process the advertised Flow Specifications

How does “as well as the limitations...” fit into the sentence?  There seems to be something missing here.

— Section 3 —

  prefix as well as community matching and manipulation, must apply to
  the Flow Specification defined NLRI-type

I can’t tell whether “Flow Specification defined” is meant to be a compound modifier for “NLRI-type” (in which case the former needs hyphens and the latter does not), or this is meant to describe a defined NLRI tyoe called “Flow Specification”.  I think you mean the latter.  Can you re-word this or re-punctuate it to make it clear?

— Section 5 —

  In order to achieve this goal, this document specifies two
  application specific NLRI identifiers that provide traffic filters,
  and a set of actions encoding in BGP Extended Communities.  The two
  application specific NLRI identifiers are:

Both instances of “application-specific” should be hyphenated.

— Section 6 —

  By default a Flow Specification NLRI MUST be validated such that it
  is considered feasible if and only if all of the below is true:

Make it “are true”.

      c) There are no more specific unicast routes

Hyphenate “more-specific” to distinguish it from “there are no more (specific unicast routes)”.

  By originator of a BGP route, we mean either the address of the

But nothing else says “originator of a BGP route”.  (b) does say “originator of the best-match unicast route”... is that what you mean here?  Can you make this match up so it’s clearer?

On thinking more about this text, I think maybe putting quotation marks around “originator” in the quoted sentence is all that’s needed.

  Specification information that conveys a more or equally specific
  destination prefix.

This needs awkward hyphenation ti be correct.  I suggest avoiding that by saying, “Specification information that conveys a destination prefix that is more or equally specific.”

  Thus, as long as there are no more specific
  unicast routes, received from a different neighboring AS, which would
  be affected by that Flow Specification.

As above, hyphenate “more-specific”.  And then fix the sentence, as it doesn’t appear to be a complete sentence.

— Section 7 —

  treated as interfering Traffic filtering actions (see below).

Please capitalize “Filtering Actions”, to be consistent.

  Some Traffic Filtering Actions may interfere with each other even
  contradict.

Make it “may interfere with or even contradict each other.”

— Section 7.7 —

  behaviour (ie. match - replace - delete communities on administrative
  boundaries).

I can’t understand what’s in the parentheses, nor even whether “i.e.” is correct or it should be “e.g.”.

— Section 9 —

  statistics facilities.  While this is an implementation specific

Hyphenate “implementation-specific”.

— Section 12 —

  This may stress the receiving systems, exceed their
  maximum capacity or may lead to unwanted Traffic Filtering Actions
  being applied to flows.

Change “capacity or may lead” to “capacity, or lead” — the “may” is already there at the start of the sentence, and the Oxford comma helps readability here.

[Ballot comment]
Thanks for this approachable update.  One item of feedback:

Appendix A.  This python code is referenced in Section 5.1.  Is it intended to be normative?  If not, then please say so.  If it is, I’d recommend include the full snippet of flowspec-cmp code in the document in addition to making the github reference.  Likewise, please provide a reference for Python 3.

[Ballot comment]
[ sections 4.{1,3} ]
Thank you for the clarifying examples at the boundary.

[ sections 4.2.2.{4,5,6} ]
What about non-{TCP,UDP} protocols with ports?  Should operators be able to
express a flow spec for SCTP traffic (e.g. within a 3GPP network context)?

There's no mention of any such support in 5575, so I'll presume this sort of
thing is left to another document (whether or not that document exists).

[ section 5.1 ]
My reading of this is that sorting between 2 different specifications each
with source and destinations prefixes must always be examined by destination
prefix first (because of the component ordering restriction in section 4.2).

Is this correct?

[ section 7 ]
"may interfere with each other even contradict"    -->
"may interfere with each other or even contradict" ?

[ section 11.2 ]
"by a an 8-bit" --> "by an 8-bit" ?

[Ballot comment]
I hope all routing documents are this easy to follow.  All I have are minor nits:

Section 1:
* "... manually as well as automatically.  The latter by systems that ..." -- change ". The" to ", the", because the second half of this isn't a sentence by itself.  Just join them.

Section 7.2:
The "TBD" here feels like it's dangling.  I realize it's dealt with in the IANA considerations, which is Section 11.3, but I had to jump around to make sure.  I imagine I'm more accustomed to an RFC Editor note or some such when I run into these.  You might consider saying in Section 11.3 that this is the thing described in Section 7.2, or vice versa.

Appendix A:
Should the copyright date be updated?

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 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard.
It defines protocol extensions and procedures for BGP flowspec.
Yes the type is indicated in the title page header.

(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

  This document defines a Border Gateway Protocol Network Layer
  Reachability Information (BGP NLRI) encoding format that can be used
  to distribute traffic Flow Specifications.  This allows the routing
  system to propagate information regarding more specific components of
  the traffic aggregate defined by an IP destination prefix.

  It also specifies BGP Extended Community encoding formats, that can
  be used to propagate Traffic Filtering Actions along with the Flow
  Specification NLRI.  Those Traffic Filtering Actions encode actions a
  routing system can take if the packet matches the Flow Specification.

  Additionally, it defines two applications of that encoding format:
  one that can be used to automate inter-domain coordination of traffic
  filtering, such as what is required in order to mitigate
  (distributed) denial-of-service attacks, and a second application to
  provide traffic filtering in the context of a BGP/MPLS VPN service.
  Other applications (ie. centralized control of traffic in a SDN or
  NFV context) are also possible.  Other documents may specify Flow
  Specification extensions.

  The information is carried via BGP, thereby reusing protocol
  algorithms, operational experience, and administrative processes such
  as inter-provider peering agreements.

  This document obsoletes both RFC5575 and RFC7674.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

This draft includes numerous editorial changes which clarifies the unclear specifications in RFC5575. There were questions/discussion about the precedence order and combination of numeric operators, which have been resolved. There were also some discussions about the validation of flowspec components, which has been resolved as well. A later discussion is about whether and how existing implementations are complied with the suggested behavior in this -bis document. There were several options under consideration, and consensus was reached on the option chosen in the current version .

After WGLC had completed and shortly after the document was submitted for publication, an implementor brought forward a remaining bug in the specification. The chair (John) thought it seriously enough to bring the document back to the WG for further consideration. The bug was fixed and a subsequent WGLC held to cover the change. The relevant mailing list thread is at https://mailarchive.ietf.org/arch/msg/idr/VTuYf23Qzw5Z22EwBt8AFsj-H1g.


Document Quality

  Are there existing implementations of the protocol?

Implementation report can be found at https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementations


Personnel

Document Shepherd: Jie Dong
Responsible Area Director: Alvaro Retana


(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 shepherd performed the review on:
1) Nits
2) Technical review 
3) Implementation report
4) IPR check

The document shepherd think the document is ready for publication.


(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.

Nothing beyond the normal checks.


(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.

None.


(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.

Robert Raszuk: no IPR
https://mailarchive.ietf.org/arch/msg/idr/YVhw3HWx5eGLkdr3VVhLUSB3LNU

Danny McPherson: no IPR
https://mailarchive.ietf.org/arch/msg/idr/fXrk2lOLkpBUEjhKPqncDoJvSkI3

Christoph Loibl: no IPR
https://mailarchive.ietf.org/arch/msg/idr/hDB-43QPMuUAjmPvgQCMGKQ4uXg

Martin Bacher: no IPR
https://mailarchive.ietf.org/arch/msg/idr/kXELcKcnqRTYGXvz3L4iS5x80L8

Susan Hares: no IPR
https://mailarchive.ietf.org/arch/msg/idr/7q0m8Ggj9uFYXmK60dvT6z2Nkl0

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are IPRs which were declared on RFC 5575, and should be inherited by this -bis document. While in the datatracker, they are not linked to this document automatically.
Although a disclosure hasn’t been made to this document (yet), the WG was made aware of the relevant disclosures, which were also called out in IETF Last Call.

https://datatracker.ietf.org/ipr/1088/
https://datatracker.ietf.org/ipr/1106/

(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? 

Solid consensus according to the review and discussion on the list.

(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.)

None.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

According to the ID nits check, there are 8 comments, which should be OK:
https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-rfc5575bis-20.txt


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not relevant for MIB Doctor, Media type, or URI.

(13) Have all references within this document been identified as
either normative or informative?

All references have been identified as either normative or informative.


(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 references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

None.

(16) Will publication of this document change the status of any
existing RFCs? 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.

RFC 5575 and RFC 7674 will be obsoleted by this document.

They are listed on the title page header, and in the abstract.

(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.
Confirm that any referenced IANA registries have been clearly
identified. 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 5226).

IANA has allocated the SAFI values 133, 134 for RFC5575, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Flow Spec Component Types" for RFC5575, the reference needs to be updated to this document, and the policies for this registry needs to be updated according to this document:
    0                    Reserved
    [1 .. 12]          Defined by this specification
    [13 .. 127]    Specification required
    [128 .. 255]  First Come First Served


IANA has allocated the following code points from the "BGP Transitive Extended Community Types" registry for RFC 7674, the reference needs to be updated to this document.
0x81  Generic Transitive Experimental Use Extended Community Part 2
0x82  Generic Transitive Experimental Use Extended Community Part 3

IANA has allocated the following code points from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry for RFC 5575, the reference of these code points needs to be updated to this document.
0x06  Flow spec traffic-rate-bytes
0x07  Flow spec traffic-action (Use of the "Value" field is defined in the "Traffic Action Fields" registry)
0x08  Flow spec redirect AS-2octet format
0x09  Flow spec traffic-remarking 

IANA is requested to allocate a new code point for “Flow spec traffic-rate-packets” from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 2 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 3 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Traffic Action Fields" for RFC 5575, the reference needs to be updated to this document.

(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.

None.

(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, etc.

No review of automated checks required.

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 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard.
It defines protocol extensions and procedures for BGP flowspec.
Yes the type is indicated in the title page header.

(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

  This document defines a Border Gateway Protocol Network Layer
  Reachability Information (BGP NLRI) encoding format that can be used
  to distribute traffic Flow Specifications.  This allows the routing
  system to propagate information regarding more specific components of
  the traffic aggregate defined by an IP destination prefix.

  It also specifies BGP Extended Community encoding formats, that can
  be used to propagate Traffic Filtering Actions along with the Flow
  Specification NLRI.  Those Traffic Filtering Actions encode actions a
  routing system can take if the packet matches the Flow Specification.

  Additionally, it defines two applications of that encoding format:
  one that can be used to automate inter-domain coordination of traffic
  filtering, such as what is required in order to mitigate
  (distributed) denial-of-service attacks, and a second application to
  provide traffic filtering in the context of a BGP/MPLS VPN service.
  Other applications (ie. centralized control of traffic in a SDN or
  NFV context) are also possible.  Other documents may specify Flow
  Specification extensions.

  The information is carried via BGP, thereby reusing protocol
  algorithms, operational experience, and administrative processes such
  as inter-provider peering agreements.

  This document obsoletes both RFC5575 and RFC7674.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

This draft includes numerous editorial changes which clarifies the unclear specifications in RFC5575. There were questions/discussion about the precedence order and combination of numeric operators, which have been resolved. There were also some discussions about the validation of flowspec components, which has been resolved as well. A later discussion is about whether and how existing implementations are complied with the suggested behavior in this -bis document. There were several options under consideration, and consensus was reached on the option chosen in the current version .

After WGLC had completed and shortly after the document was submitted for publication, an implementor brought forward a remaining bug in the specification. The chair (John) thought it seriously enough to bring the document back to the WG for further consideration. The bug was fixed and a subsequent WGLC held to cover the change. The relevant mailing list thread is at https://mailarchive.ietf.org/arch/msg/idr/VTuYf23Qzw5Z22EwBt8AFsj-H1g.


Document Quality

  Are there existing implementations of the protocol?

Implementation report can be found at https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementations


Personnel

Document Shepherd: Jie Dong
Responsible Area Director: Alvaro Retana


(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 shepherd performed the review on:
1) Nits
2) Technical review 
3) Implementation report
4) IPR check

The document shepherd think the document is ready for publication.


(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.

Nothing beyond the normal checks.


(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.

None.


(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.

Robert Raszuk: no IPR
https://mailarchive.ietf.org/arch/msg/idr/YVhw3HWx5eGLkdr3VVhLUSB3LNU

Danny McPherson: no IPR
https://mailarchive.ietf.org/arch/msg/idr/fXrk2lOLkpBUEjhKPqncDoJvSkI3

Christoph Loibl: no IPR
https://mailarchive.ietf.org/arch/msg/idr/hDB-43QPMuUAjmPvgQCMGKQ4uXg

Martin Bacher: no IPR
https://mailarchive.ietf.org/arch/msg/idr/kXELcKcnqRTYGXvz3L4iS5x80L8

Susan Hares: no IPR
https://mailarchive.ietf.org/arch/msg/idr/7q0m8Ggj9uFYXmK60dvT6z2Nkl0

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are IPRs which were declared on RFC 5575, and should be inherited by this -bis document. While in the datatracker, they are not linked to this document automatically.

https://datatracker.ietf.org/ipr/1088/
https://datatracker.ietf.org/ipr/1106/

(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? 

Solid consensus according to the review and discussion on the list.

(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.)

None.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

According to the ID nits check, there are 8 comments, which should be OK:
https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-rfc5575bis-20.txt


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not relevant for MIB Doctor, Media type, or URI.

(13) Have all references within this document been identified as
either normative or informative?

All references have been identified as either normative or informative.


(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 references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

None.

(16) Will publication of this document change the status of any
existing RFCs? 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.

RFC 5575 and RFC 7674 will be obsoleted by this document.

They are listed on the title page header, and in the abstract.

(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.
Confirm that any referenced IANA registries have been clearly
identified. 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 5226).

IANA has allocated the SAFI values 133, 134 for RFC5575, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Flow Spec Component Types" for RFC5575, the reference needs to be updated to this document, and the policies for this registry needs to be updated according to this document:
    0                    Reserved
    [1 .. 12]          Defined by this specification
    [13 .. 127]    Specification required
    [128 .. 255]  First Come First Served


IANA has allocated the following code points from the "BGP Transitive Extended Community Types" registry for RFC 7674, the reference needs to be updated to this document.
0x81  Generic Transitive Experimental Use Extended Community Part 2
0x82  Generic Transitive Experimental Use Extended Community Part 3

IANA has allocated the following code points from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry for RFC 5575, the reference of these code points needs to be updated to this document.
0x06  Flow spec traffic-rate-bytes
0x07  Flow spec traffic-action (Use of the "Value" field is defined in the "Traffic Action Fields" registry)
0x08  Flow spec redirect AS-2octet format
0x09  Flow spec traffic-remarking 

IANA is requested to allocate a new code point for “Flow spec traffic-rate-packets” from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 2 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 3 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Traffic Action Fields" for RFC 5575, the reference needs to be updated to this document.

(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.

None.

(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, etc.

No review of automated checks required.

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 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard.
It defines protocol extensions and procedures for BGP flowspec.
Yes the type is indicated in the title page header.

(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

  This document defines a Border Gateway Protocol Network Layer
  Reachability Information (BGP NLRI) encoding format that can be used
  to distribute traffic Flow Specifications.  This allows the routing
  system to propagate information regarding more specific components of
  the traffic aggregate defined by an IP destination prefix.

  It also specifies BGP Extended Community encoding formats, that can
  be used to propagate Traffic Filtering Actions along with the Flow
  Specification NLRI.  Those Traffic Filtering Actions encode actions a
  routing system can take if the packet matches the Flow Specification.

  Additionally, it defines two applications of that encoding format:
  one that can be used to automate inter-domain coordination of traffic
  filtering, such as what is required in order to mitigate
  (distributed) denial-of-service attacks, and a second application to
  provide traffic filtering in the context of a BGP/MPLS VPN service.
  Other applications (ie. centralized control of traffic in a SDN or
  NFV context) are also possible.  Other documents may specify Flow
  Specification extensions.

  The information is carried via BGP, thereby reusing protocol
  algorithms, operational experience, and administrative processes such
  as inter-provider peering agreements.

  This document obsoletes both RFC5575 and RFC7674.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

This draft includes numerous editorial changes which clarifies the unclear specifications in RFC5575. There were questions/discussion about the precedence order and combination of numeric operators, which have been resolved. There were also some discussions about the validation of flowspec components, which has been resolved as well. A later discussion is about whether and how existing implementations are complied with the suggested behavior in this -bis document. There were several options under consideration, and consensus was reached on the option chosen in the current version .

After WGLC had completed and shortly after the document was submitted for publication, an implementor brought forward a remaining bug in the specification. The chair (John) thought it seriously enough to bring the document back to the WG for further consideration. The bug was fixed and a subsequent WGLC held to cover the change. The relevant mailing list thread is at https://mailarchive.ietf.org/arch/msg/idr/VTuYf23Qzw5Z22EwBt8AFsj-H1g.


Document Quality

  Are there existing implementations of the protocol?

Implementation report can be found at https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementations


Personnel

Document Shepherd: Jie Dong
Responsible Area Director: Alvaro Retana


(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 shepherd performed the review on:
1) Nits
2) Technical review 
3) Implementation report
4) IPR check

The document shepherd think the document is ready for publication.


(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.

Nothing beyond the normal checks.


(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.

None.


(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.

Robert Raszuk: no IPR
https://mailarchive.ietf.org/arch/msg/idr/YVhw3HWx5eGLkdr3VVhLUSB3LNU

Danny McPherson: no IPR
https://mailarchive.ietf.org/arch/msg/idr/fXrk2lOLkpBUEjhKPqncDoJvSkI3

Christoph Loibl: no IPR
https://mailarchive.ietf.org/arch/msg/idr/hDB-43QPMuUAjmPvgQCMGKQ4uXg

Martin Bacher: no IPR
https://mailarchive.ietf.org/arch/msg/idr/kXELcKcnqRTYGXvz3L4iS5x80L8

Susan Hares: no IPR
https://mailarchive.ietf.org/arch/msg/idr/7q0m8Ggj9uFYXmK60dvT6z2Nkl0

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are IPRs which were declared on RFC 5575, and should be inherited by this -bis document. While in the datatracker, they are not linked to this document automatically.

https://datatracker.ietf.org/ipr/1088/
https://datatracker.ietf.org/ipr/1106/

(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? 

Solid consensus according to the review and discussion on the list.

(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.)

None.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

According to the ID nits check, there are 8 comments, which should be OK:
https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-rfc5575bis-20.txt


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not relevant for MIB Doctor, Media type, or URI.

(13) Have all references within this document been identified as
either normative or informative?

All references have been identified as either normative or informative.


(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 references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

None.

(16) Will publication of this document change the status of any
existing RFCs? 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.

RFC 5575 and RFC 7674 will be obsoleted by this document.

They are listed on the title page header, and in the abstract.

(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.
Confirm that any referenced IANA registries have been clearly
identified. 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 5226).

IANA has allocated the SAFI values 133, 134 for RFC5575, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Flow Spec Component Types" for RFC5575, the reference needs to be updated to this document, and the policies for this registry needs to be updated according to this document:
    0                    Reserved
    [1 .. 12]          Defined by this specification
    [13 .. 127]    Specification required
    [128 .. 255]  First Come First Served


IANA has allocated the following code points from the "BGP Transitive Extended Community Types" registry for RFC 7674, the reference needs to be updated to this document.
0x81  Generic Transitive Experimental Use Extended Community Part 2
0x82  Generic Transitive Experimental Use Extended Community Part 3

IANA has allocated the following code points from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry for RFC 5575, the reference of these code points needs to be updated to this document.
0x06  Flow spec traffic-rate-bytes
0x07  Flow spec traffic-action (Use of the "Value" field is defined in the "Traffic Action Fields" registry)
0x08  Flow spec redirect AS-2octet format
0x09  Flow spec traffic-remarking 

IANA is requested to allocate a new code point for “Flow spec traffic-rate-packets” from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 2 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 3 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Traffic Action Fields" for RFC 5575, the reference needs to be updated to this document.

(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.

None.

(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, etc.

No review of automated checks required.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-idr-rfc5575bis-20. 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 seven actions which we must complete.

First, in the SAFI Values Registry on the Subsequent Address Family Identifiers (SAFI) Parameters registry page located at:

https://www.iana.org/assignments/safi-namespace/

The reference for value 133 is to be changed from [RFC5575] to [ RFC-to-be ]. The reference for value 134 is to be changed from [RFC5575] to [ RFC-to-be ]. IANA finds no other instances of [RFC7674] or [RFC5575] in that registry.

Second, in the Flow Spec Component Types registry located at:

https://www.iana.org/assignments/flow-spec/

the reference for the registry will be changed from [RFC5575] to [ RFC-to-be ]. In addition, the reference for every registration in the registry will be changed from [RFC5575] to [ RFC-to-be ].

In addition, the registry will have its registration procedures changed from:

0-127: Specification Required
128-255: First Come First Served

to the following procedures:

0: Reserved
1 - 127: Specification Required
128 - 255: First Come, First Served

As defined by [RFC8126].

Third, in the BGP Transitive Extended Community Types registry on the Border Gateway Protocol (BGP) Extended Communities registry page located at:

https://www.iana.org/assignments/bgp-extended-communities/

values 0x81 and 0x82 are to be marked obsolete and have their reference changed to [ RFC-to-be ].

Fourth, in the Generic Transitive Experimental Use Extended Community Sub-Types registry, also on the Border Gateway Protocol (BGP) Extended Communities registry page located at:

https://www.iana.org/assignments/bgp-extended-communities/

the registrations for Sub-type values 0x06, 0x07, 0x08 and 0x09 will have their reference changed to [ RFC-to-be ]. IANA finds no other instances of [RFC7674] or [RFC5575] in that registry.

In addition, a new registration will be made in this registry as follows:

Sub-Type Value: [ TBD-at-Registration ]
Name: Flow spec traffic-rate-packets
Reference: [ RFC-to-be ]

Fifth, in the Generic Transitive Experimental Use Extended Community Part 2 Sub-Types, also on the Border Gateway Protocol (BGP) Extended Communities registry page located at:

https://www.iana.org/assignments/bgp-extended-communities/

the reference for the registry will be changed from [RFC7674] to [ RFC-to-be ].

and,

the registration for Sub-type value 0x08 will be changed from [RFC7674] to [ RFC-to-be ]. IANA finds no other instances of [RFC7674] or [RFC5575] in that registry.

Sixth, in the Generic Transitive Experimental Use Extended Community Part 3 Sub-Types, also on the Border Gateway Protocol (BGP) Extended Communities registry page located at:

https://www.iana.org/assignments/bgp-extended-communities/

the reference for the registry will be changed from [RFC7674] to [ RFC-to-be ].

and,

the registration for Sub-type value 0x08 will be changed from [RFC7674] to [ RFC-to-be ]. IANA finds no other instances of [RFC7674] or [RFC5575] in that registry.

Seventh, in the Traffic Action Fields registry, also on the Border Gateway Protocol (BGP) Extended Communities registry page located at:

https://www.iana.org/assignments/bgp-extended-communities/

the reference for the registry will be changed from [RFC7674] to [ RFC-to-be ].

and,

The registrations for bit 47 and 46 will have their reference changed from [RFC5575] to [ RFC-to-be ]. IANA finds no other instances of [RFC7674] or [RFC5575] in that registry.

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

The following Last Call announcement was sent out (ends 2020-04-08):

From: The IESG
To: IETF-Announce
CC: idr@ietf.org, aretana.ietf@gmail.com, idr-chairs@ietf.org, Jie Dong , draft-ietf-idr-rfc5575bis@ietf.org, jie.dong@huawei.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Dissemination of Flow Specification Rules) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'Dissemination of Flow Specification Rules'
  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-04-08. 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


  This document defines a Border Gateway Protocol Network Layer
  Reachability Information (BGP NLRI) encoding format that can be used
  to distribute traffic Flow Specifications.  This allows the routing
  system to propagate information regarding more specific components of
  the traffic aggregate defined by an IP destination prefix.

  It also specifies BGP Extended Community encoding formats, that can
  be used to propagate Traffic Filtering Actions along with the Flow
  Specification NLRI.  Those Traffic Filtering Actions encode actions a
  routing system can take if the packet matches the Flow Specification.

  Additionally, it defines two applications of that encoding format:
  one that can be used to automate inter-domain coordination of traffic
  filtering, such as what is required in order to mitigate
  (distributed) denial-of-service attacks, and a second application to
  provide traffic filtering in the context of a BGP/MPLS VPN service.
  Other applications (ie. centralized control of traffic in a SDN or
  NFV context) are also possible.  Other documents may specify Flow
  Specification extensions.

  The information is carried via BGP, thereby reusing protocol
  algorithms, operational experience, and administrative processes such
  as inter-provider peering agreements.

  This document obsoletes both RFC5575 and RFC7674.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/1088/
  https://datatracker.ietf.org/ipr/1106/

There is an IPR declaration related to rfc5575 which is not reflected for this document; the WG is aware of it.  We're working with the Secretariat to resolve the issue before starting the IETF Last Call.

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 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard.
It defines protocol extensions and procedures for BGP flowspec.
Yes the type is indicated in the title page header.

(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

  This document defines a Border Gateway Protocol Network Layer
  Reachability Information (BGP NLRI) encoding format that can be used
  to distribute traffic Flow Specifications.  This allows the routing
  system to propagate information regarding more specific components of
  the traffic aggregate defined by an IP destination prefix.

  It specifies IPv4 traffic Flow Specifications via a BGP NLRI which
  carries traffic Flow Specification filter, and an Extended community
  value which encodes actions a routing system can take if the packet
  matches the traffic flow filters.  The flow filters and the actions
  are processed in a fixed order.  Other drafts specify IPv6, MPLS
  addresses, L2VPN addresses, and NV03 encapsulation of IP addresses.

  This document obsoletes RFC5575 and RFC7674 to correct unclear
  specifications in the flow filters and to provide rules for actions
  which interfere (e.g. redirection of traffic and flow filtering).

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

This draft clarifies the unclear specifications in RFC5575 and provide the clear rules for actions which interfere with each other. There were questions/discussion about the precedence order and combination of numeric operators, which have been resolved. There were also some discussions about the validation of flowspec components, which has been resolved as well. Recent discussion is about whether and how existing implementations are complied with the suggested behavior in this -bis document. There were several options under consideration, and consensus was reached on the option chosen in the current version .

After WGLC had completed and shortly after the document was submitted for publication, an implementor brought forward a remaining bug in the specification. The chair (John) thought it seriously enough to bring the document back to the WG for further consideration. The bug was fixed and a subsequent WGLC held to cover the change. The relevant mailing list thread is at https://mailarchive.ietf.org/arch/msg/idr/VTuYf23Qzw5Z22EwBt8AFsj-H1g.

Document Quality

  Are there existing implementations of the protocol?

Implementation report can be found at https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementations

Personnel

Document Shepherd: Jie Dong
Responsible Area Director: Alvaro Retana

(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 shepherd performed the review on:
1) Nits
2) Technical review 
3) Implementation report
4) IPR check

The document shepherd think the document is ready for publication.


(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.

Nothing beyond the normal checks.


(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.

None.


(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.

Robert Raszuk: no IPR
https://mailarchive.ietf.org/arch/msg/idr/YVhw3HWx5eGLkdr3VVhLUSB3LNU

Danny McPherson: no IPR
https://mailarchive.ietf.org/arch/msg/idr/fXrk2lOLkpBUEjhKPqncDoJvSkI3

Christoph Loibl: no IPR
https://mailarchive.ietf.org/arch/msg/idr/hDB-43QPMuUAjmPvgQCMGKQ4uXg

Martin Bacher: no IPR
https://mailarchive.ietf.org/arch/msg/idr/kXELcKcnqRTYGXvz3L4iS5x80L8

Susan Hares: no IPR
https://mailarchive.ietf.org/arch/msg/idr/7q0m8Ggj9uFYXmK60dvT6z2Nkl0

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosure.

(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? 

Solid consensus according to the review and discussion on the list.

(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.)

None.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

According to the ID nits check, there is one warning and several comments, which could be OK:
https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-rfc5575bis-13.txt


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not relevant for MIB Doctor, Media type, or URI.

(13) Have all references within this document been identified as
either normative or informative?

All references have been identified as either normative or informative.


(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 references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

None.

(16) Will publication of this document change the status of any
existing RFCs? 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.

RFC 5575 and RFC 7674 will be obsoleted by this document.

They are listed on the title page header, and in the abstract.

(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.
Confirm that any referenced IANA registries have been clearly
identified. 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 5226).

IANA has allocated the SAFI values 133, 134 for RFC5575, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Flow Spec Component Types" for RFC5575, the reference needs to be updated to this document.

IANA has allocated the following code points from the "BGP Transitive Extended Community Types" registry for RFC 7674, the reference needs to be updated to this document.
0x81  Generic Transitive Experimental Use Extended Community Part 2
0x82  Generic Transitive Experimental Use Extended Community Part 3

IANA has allocated the following code points from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry for RFC 5575, the reference of these code points needs to be updated to this document.
0x06  Flow spec traffic-rate-bytes
0x07  Flow spec traffic-action (Use of the "Value" field is defined in the "Traffic Action Fields" registry)
0x08  Flow spec redirect AS-2byte format
0x09  Flow spec traffic-remarking 

IANA is requested to allocate a new code point for “Flow spec traffic-rate-packets” from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 2 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 3 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Traffic Action Fields" for RFC 5575, the reference needs to be updated to this document.

(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.

None.

(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, etc.

No review of automated checks required.

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 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard.
It defines protocol extensions and procedures for BGP flowspec.
Yes the type is indicated in the title page header.

(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

  This document defines a Border Gateway Protocol Network Layer
  Reachability Information (BGP NLRI) encoding format that can be used
  to distribute traffic Flow Specifications.  This allows the routing
  system to propagate information regarding more specific components of
  the traffic aggregate defined by an IP destination prefix.

  It specifies IPv4 traffic Flow Specifications via a BGP NLRI which
  carries traffic Flow Specification filter, and an Extended community
  value which encodes actions a routing system can take if the packet
  matches the traffic flow filters.  The flow filters and the actions
  are processed in a fixed order.  Other drafts specify IPv6, MPLS
  addresses, L2VPN addresses, and NV03 encapsulation of IP addresses.

  This document obsoletes RFC5575 and RFC7674 to correct unclear
  specifications in the flow filters and to provide rules for actions
  which interfere (e.g. redirection of traffic and flow filtering).

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

This draft clarifies the unclear specifications in RFC5575 and provide the clear rules for actions which interfere with each other. There were questions/discussion about the precedence order and combination of numeric operators, which have been resolved. There were also some discussions about the validation of flowspec components, which has been resolved as well. Recent discussion is about whether and how existing implementations are complied with the suggested behavior in this -bis document. There were several options under consideration, and consensus was reached on the option chosen in the current version .

After WGLC had completed and shortly after the document was submitted for publication, an implementor brought forward a remaining bug in the specification. The chair (John) thought it seriously enough to bring the document back to the WG for further consideration. The bug was fixed and a subsequent WGLC held to cover the change. The relevant mailing list thread is at https://mailarchive.ietf.org/arch/msg/idr/VTuYf23Qzw5Z22EwBt8AFsj-H1g.

Document Quality

  Are there existing implementations of the protocol?

Implementation report can be found at https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementations

Personnel

Document Shepherd: Jie Dong
Responsible Area Director: Alvaro Retana

(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 shepherd performed the review on:
1) Nits
2) Technical review 
3) Implementation report
4) IPR check

The document shepherd think the document is ready for publication.


(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.

Nothing beyond the normal checks.


(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.

None.


(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.

Robert Raszuk: no IPR
https://mailarchive.ietf.org/arch/msg/idr/YVhw3HWx5eGLkdr3VVhLUSB3LNU

Danny McPherson: no IPR
https://mailarchive.ietf.org/arch/msg/idr/fXrk2lOLkpBUEjhKPqncDoJvSkI3

Christoph Loibl: no IPR
https://mailarchive.ietf.org/arch/msg/idr/hDB-43QPMuUAjmPvgQCMGKQ4uXg

Martin Bacher: no IPR
https://mailarchive.ietf.org/arch/msg/idr/kXELcKcnqRTYGXvz3L4iS5x80L8

Susan Hares: no IPR
https://mailarchive.ietf.org/arch/msg/idr/7q0m8Ggj9uFYXmK60dvT6z2Nkl0

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosure.

(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? 

Solid consensus according to the review and discussion on the list.

(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.)

None.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

According to the ID nits check, there is one warning and several comments, which could be OK:
https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-rfc5575bis-13.txt


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not relevant for MIB Doctor, Media type, or URI.

(13) Have all references within this document been identified as
either normative or informative?

All references have been identified as either normative or informative.


(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 references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

None.

(16) Will publication of this document change the status of any
existing RFCs? 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.

RFC 5575 and RFC 7674 will be obsoleted by this document.

They are listed on the title page header, and in the abstract.

(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.
Confirm that any referenced IANA registries have been clearly
identified. 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 5226).

IANA has allocated the SAFI values 133, 134 for RFC5575, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Flow Spec Component Types" for RFC5575, the reference needs to be updated to this document.

IANA has allocated the following code points from the "BGP Transitive Extended Community Types" registry for RFC 7674, the reference needs to be updated to this document.
0x81  Generic Transitive Experimental Use Extended Community Part 2
0x82  Generic Transitive Experimental Use Extended Community Part 3

IANA has allocated the following code points from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry for RFC 5575, the reference of these code points needs to be updated to this document.
0x06  Flow spec traffic-rate-bytes
0x07  Flow spec traffic-action (Use of the "Value" field is defined in the "Traffic Action Fields" registry)
0x08  Flow spec redirect AS-2byte format
0x09  Flow spec traffic-remarking 

IANA is requested to allocate a new code point for “Flow spec traffic-rate-packets” from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 2 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 3 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Traffic Action Fields" for RFC 5575, the reference needs to be updated to this document.

(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.

None.

(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, etc.

No review of automated checks required.

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 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard.
It defines protocol extensions and procedures for BGP flowspec.
Yes the type is indicated in the title page header.

(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

  This document defines a Border Gateway Protocol Network Layer
  Reachability Information (BGP NLRI) encoding format that can be used
  to distribute traffic Flow Specifications.  This allows the routing
  system to propagate information regarding more specific components of
  the traffic aggregate defined by an IP destination prefix.

  It specifies IPv4 traffic Flow Specifications via a BGP NLRI which
  carries traffic Flow Specification filter, and an Extended community
  value which encodes actions a routing system can take if the packet
  matches the traffic flow filters.  The flow filters and the actions
  are processed in a fixed order.  Other drafts specify IPv6, MPLS
  addresses, L2VPN addresses, and NV03 encapsulation of IP addresses.

  This document obsoletes RFC5575 and RFC7674 to correct unclear
  specifications in the flow filters and to provide rules for actions
  which interfere (e.g. redirection of traffic and flow filtering).

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

This draft clarifies the unclear specifications in RFC5575 and provide the clear rules for actions which interfere with each other. There were questions/discussion about the precedence order and combination of numeric operators, which have been resolved. There were also some discussions about the validation of flowspec components, which has been resolved as well. Recent discussion is about whether and how existing implementations are complied with the suggested behavior in this -bis document. There were several options under consideration, and consensus was reached on the option chosen in the current version .
 

Document Quality

  Are there existing implementations of the protocol?

Implementation report can be found at https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementations

Personnel

Document Shepherd: Jie Dong
Responsible Area Director: Alvaro Retana

(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 shepherd performed the review on:
1) Nits
2) Technical review 
3) Implementation report
4) IPR check

The document shepherd think the document is ready for publication.


(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.

Nothing beyond the normal checks.


(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.

None.


(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.

Robert Raszuk: no IPR
https://mailarchive.ietf.org/arch/msg/idr/YVhw3HWx5eGLkdr3VVhLUSB3LNU

Danny McPherson: no IPR
https://mailarchive.ietf.org/arch/msg/idr/fXrk2lOLkpBUEjhKPqncDoJvSkI3

Christoph Loibl: no IPR
https://mailarchive.ietf.org/arch/msg/idr/hDB-43QPMuUAjmPvgQCMGKQ4uXg

Martin Bacher: no IPR
https://mailarchive.ietf.org/arch/msg/idr/kXELcKcnqRTYGXvz3L4iS5x80L8

Susan Hares: no IPR
https://mailarchive.ietf.org/arch/msg/idr/7q0m8Ggj9uFYXmK60dvT6z2Nkl0

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosure.

(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? 

Solid consensus according to the review and discussion on the list.

(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.)

None.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

According to the ID nits check, there is one warning and several comments, which could be OK:
https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-rfc5575bis-13.txt


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not relevant for MIB Doctor, Media type, or URI.

(13) Have all references within this document been identified as
either normative or informative?

All references have been identified as either normative or informative.


(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 references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

None.

(16) Will publication of this document change the status of any
existing RFCs? 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.

RFC 5575 and RFC 7674 will be obsoleted by this document.

They are listed on the title page header, and in the abstract.

(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.
Confirm that any referenced IANA registries have been clearly
identified. 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 5226).

IANA has allocated the SAFI values 133, 134 for RFC5575, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Flow Spec Component Types" for RFC5575, the reference needs to be updated to this document.

IANA has allocated the following code points from the "BGP Transitive Extended Community Types" registry for RFC 7674, the reference needs to be updated to this document.
0x81  Generic Transitive Experimental Use Extended Community Part 2
0x82  Generic Transitive Experimental Use Extended Community Part 3

IANA has allocated the following code points from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry for RFC 5575, the reference of these code points needs to be updated to this document.
0x06  Flow spec traffic-rate-bytes
0x07  Flow spec traffic-action (Use of the "Value" field is defined in the "Traffic Action Fields" registry)
0x08  Flow spec redirect AS-2byte format
0x09  Flow spec traffic-remarking 

IANA is requested to allocate a new code point for “Flow spec traffic-rate-packets” from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 2 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 3 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Traffic Action Fields" for RFC 5575, the reference needs to be updated to this document.

(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.

None.

(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, etc.

No review of automated checks required.

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 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard.
It defines protocol extensions and procedures for BGP flowspec.
Yes the type is indicated in the title page header.

(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

  This document defines a Border Gateway Protocol Network Layer
  Reachability Information (BGP NLRI) encoding format that can be used
  to distribute traffic Flow Specifications.  This allows the routing
  system to propagate information regarding more specific components of
  the traffic aggregate defined by an IP destination prefix.

  It specifies IPv4 traffic Flow Specifications via a BGP NLRI which
  carries traffic Flow Specification filter, and an Extended community
  value which encodes actions a routing system can take if the packet
  matches the traffic flow filters.  The flow filters and the actions
  are processed in a fixed order.  Other drafts specify IPv6, MPLS
  addresses, L2VPN addresses, and NV03 encapsulation of IP addresses.

  This document obsoletes RFC5575 and RFC7674 to correct unclear
  specifications in the flow filters and to provide rules for actions
  which interfere (e.g. redirection of traffic and flow filtering).

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

This draft clarifies the unclear specifications in RFC5575 and provide the clear rules for actions which interfere with each other. There were questions/discussion about the precedence order and combination of numeric operators, which have been resolved. There were also some discussions about the validation of flowspec components, which has been resolved as well. Recent discussion is about whether and how existing implementations are complied with the suggested behavior in this -bis document. There were several options under consideration, and consensus was reached on the option chosen in the current version .
 

Document Quality

  Are there existing implementations of the protocol?

Implementation report can be found at https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementations

Personnel

Document Shepherd: Jie Dong
Responsible Area Director: Alvaro Retana

(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 shepherd performed the review on:
1) Nits
2) Technical review 
3) Implementation report
4) IPR check

The document shepherd think the document is ready for publication.


(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.

Nothing beyond the normal checks.


(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.

None.


(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.

Robert Raszuk: no IPR
https://mailarchive.ietf.org/arch/msg/idr/YVhw3HWx5eGLkdr3VVhLUSB3LNU

Danny McPherson: no IPR
https://mailarchive.ietf.org/arch/msg/idr/fXrk2lOLkpBUEjhKPqncDoJvSkI3

Christoph Loibl: no IPR
https://mailarchive.ietf.org/arch/msg/idr/hDB-43QPMuUAjmPvgQCMGKQ4uXg

Martin Bacher: no IPR
https://mailarchive.ietf.org/arch/msg/idr/kXELcKcnqRTYGXvz3L4iS5x80L8

Susan Hares: no IPR
https://mailarchive.ietf.org/arch/msg/idr/7q0m8Ggj9uFYXmK60dvT6z2Nkl0

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosure.

(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? 

Solid consensus according to the review and discussion on the list.

(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.)

None.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

According to the ID nits check, there is one warning and several comments, which could be OK:
https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-rfc5575bis-13.txt


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not relevant for MIB Doctor, Media type, or URI.

(13) Have all references within this document been identified as
either normative or informative?

All references have been identified as either normative or informative.


(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 references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

None.

(16) Will publication of this document change the status of any
existing RFCs? 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.

RFC 5575 and RFC 7674 will be obsoleted by this document.

They are listed on the title page header, and in the abstract.

(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.
Confirm that any referenced IANA registries have been clearly
identified. 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 5226).

IANA has allocated the SAFI values 133, 134 for RFC5575, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Flow Spec Component Types" for RFC5575, the reference needs to be updated to this document.

IANA has allocated the following code points from the "BGP Transitive Extended Community Types" registry for RFC 7674, the reference needs to be updated to this document.
0x81  Generic Transitive Experimental Use Extended Community Part 2
0x82  Generic Transitive Experimental Use Extended Community Part 3

IANA has allocated the following code points from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry for RFC 5575, the reference of these code points needs to be updated to this document.
0x06  Flow spec traffic-rate-bytes
0x07  Flow spec traffic-action (Use of the "Value" field is defined in the "Traffic Action Fields" registry)
0x08  Flow spec redirect AS-2byte format
0x09  Flow spec traffic-remarking 

IANA is requested to allocate a new code point for “Flow spec traffic-rate-packets” from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 2 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 3 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Traffic Action Fields" for RFC 5575, the reference needs to be updated to this document.

(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.

None.

(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, etc.

No review of automated checks required.

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 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard.
It defines protocol extensions and procedures for BGP flowspec.
Yes the type is indicated in the title page header.

(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

  This document defines a Border Gateway Protocol Network Layer
  Reachability Information (BGP NLRI) encoding format that can be used
  to distribute traffic Flow Specifications.  This allows the routing
  system to propagate information regarding more specific components of
  the traffic aggregate defined by an IP destination prefix.

  It specifies IPv4 traffic Flow Specifications via a BGP NLRI which
  carries traffic Flow Specification filter, and an Extended community
  value which encodes actions a routing system can take if the packet
  matches the traffic flow filters.  The flow filters and the actions
  are processed in a fixed order.  Other drafts specify IPv6, MPLS
  addresses, L2VPN addresses, and NV03 encapsulation of IP addresses.

  This document obsoletes RFC5575 and RFC7674 to correct unclear
  specifications in the flow filters and to provide rules for actions
  which interfere (e.g. redirection of traffic and flow filtering).

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

This draft clarifies the unclear specifications in RFC5575 and provide the clear rules for actions which interfere with each other. There were questions/discussion about the precedence order and combination of numeric operators, which have been resolved. There were also some discussions about the validation of flowspec components, which has been resolved as well. Recent discussion is about whether and how existing implementations are complied with the suggested behavior in this -bis document. There were several options under consideration, and consensus was reached on the option chosen in the current version .
 

Document Quality

  Are there existing implementations of the protocol?

Implementation report can be found at https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementations

Personnel

Document Shepherd: Jie Dong
Responsible Area Director: Alvaro Retana

(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 shepherd performed the review on:
1) Nits
2) Technical review 
3) Implementation report (None so far)
4) IPR check

The document shepherd think the document is ready for publication.


(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.

Nothing beyond the normal checks.


(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.

None.


(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.

Robert Raszuk: no IPR
https://mailarchive.ietf.org/arch/msg/idr/YVhw3HWx5eGLkdr3VVhLUSB3LNU

Danny McPherson: no IPR
https://mailarchive.ietf.org/arch/msg/idr/fXrk2lOLkpBUEjhKPqncDoJvSkI3

Christoph Loibl: no IPR
https://mailarchive.ietf.org/arch/msg/idr/hDB-43QPMuUAjmPvgQCMGKQ4uXg

Martin Bacher: no IPR
https://mailarchive.ietf.org/arch/msg/idr/kXELcKcnqRTYGXvz3L4iS5x80L8

Susan Hares: no IPR
https://mailarchive.ietf.org/arch/msg/idr/7q0m8Ggj9uFYXmK60dvT6z2Nkl0

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosure.

(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? 

Solid consensus according to the review and discussion on the list.

(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.)

None.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

According to the ID nits check, there is one warning and several comments, which could be OK:
https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-rfc5575bis-13.txt


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not relevant for MIB Doctor, Media type, or URI.

(13) Have all references within this document been identified as
either normative or informative?

All references have been identified as either normative or informative.


(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 references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

None.

(16) Will publication of this document change the status of any
existing RFCs? 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.

RFC 5575 and RFC 7674 will be obsoleted by this document.

They are listed on the title page header, and in the abstract.

(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.
Confirm that any referenced IANA registries have been clearly
identified. 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 5226).

IANA has allocated the SAFI values 133, 134 for RFC5575, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Flow Spec Component Types" for RFC5575, the reference needs to be updated to this document.

IANA has allocated the following code points from the "BGP Transitive Extended Community Types" registry for RFC 7674, the reference needs to be updated to this document.
0x81  Generic Transitive Experimental Use Extended Community Part 2
0x82  Generic Transitive Experimental Use Extended Community Part 3

IANA has allocated the following code points from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry for RFC 5575, the reference of these code points needs to be updated to this document.
0x06  Flow spec traffic-rate-bytes
0x07  Flow spec traffic-action (Use of the "Value" field is defined in the "Traffic Action Fields" registry)
0x08  Flow spec redirect AS-2byte format
0x09  Flow spec traffic-remarking 

IANA is requested to allocate a new code point for “Flow spec traffic-rate-packets” from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 2 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 3 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Traffic Action Fields" for RFC 5575, the reference needs to be updated to this document.

(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.

None.

(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, etc.

No review of automated checks required.

Per https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementations there are currently two sections of the draft as yet unimplemented, section 7.2 "Traffic Rate in Packets" and section 11 "Error-Handling and Future NLRI Extensions". Holding until those are implemented or the WG has consensus to waive.

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 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard.
It defines protocol extensions and procedures for BGP flowspec.
Yes the type is indicated in the title page header.

(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

  This document defines a Border Gateway Protocol Network Layer
  Reachability Information (BGP NLRI) encoding format that can be used
  to distribute traffic Flow Specifications.  This allows the routing
  system to propagate information regarding more specific components of
  the traffic aggregate defined by an IP destination prefix.

  It specifies IPv4 traffic Flow Specifications via a BGP NLRI which
  carries traffic Flow Specification filter, and an Extended community
  value which encodes actions a routing system can take if the packet
  matches the traffic flow filters.  The flow filters and the actions
  are processed in a fixed order.  Other drafts specify IPv6, MPLS
  addresses, L2VPN addresses, and NV03 encapsulation of IP addresses.

  This document obsoletes RFC5575 and RFC7674 to correct unclear
  specifications in the flow filters and to provide rules for actions
  which interfere (e.g. redirection of traffic and flow filtering).

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

This draft clarifies the unclear specifications in RFC5575 and provide the clear rules for actions which interfere with each other. There were questions/discussion about the precedence order and combination of numeric operators, which have been resolved. There were also some discussions about the validation of flowspec components, which has been resolved as well. Recent discussion is about whether and how existing implementations are complied with the suggested behavior in this -bis document. There were several options under consideration, and consensus was reached on the option chosen in the current version .
 

Document Quality

  Are there existing implementations of the protocol?

RFC 5575 has been widely implemented.
Depends on the solution chosen for the interfering actions, This document may require some modification to the existing RFC 5575 implementation. Currently there is no implementation report of this document, it is expected that the implement report (if any) will be provided on idr wiki page.

Personnel

Document Shepherd: Jie Dong
Responsible Area Director: Alvaro Retana

(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 shepherd performed the review on:
1) Nits
2) Technical review 
3) Implementation report (None so far)
4) IPR check

The document shepherd think the document is ready for publication.


(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.

Nothing beyond the normal checks.


(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.

None.


(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.

Robert Raszuk: no IPR
https://mailarchive.ietf.org/arch/msg/idr/YVhw3HWx5eGLkdr3VVhLUSB3LNU

Danny McPherson: no IPR
https://mailarchive.ietf.org/arch/msg/idr/fXrk2lOLkpBUEjhKPqncDoJvSkI3

Christoph Loibl: no IPR
https://mailarchive.ietf.org/arch/msg/idr/hDB-43QPMuUAjmPvgQCMGKQ4uXg

Martin Bacher: no IPR
https://mailarchive.ietf.org/arch/msg/idr/kXELcKcnqRTYGXvz3L4iS5x80L8

Susan Hares: no IPR
https://mailarchive.ietf.org/arch/msg/idr/7q0m8Ggj9uFYXmK60dvT6z2Nkl0

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosure.

(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? 

Solid consensus according to the review and discussion on the list.

(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.)

None.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

According to the ID nits check, there is one warning and several comments, which could be OK:
https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-rfc5575bis-13.txt


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not relevant for MIB Doctor, Media type, or URI.

(13) Have all references within this document been identified as
either normative or informative?

All references have been identified as either normative or informative.


(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 references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

None.

(16) Will publication of this document change the status of any
existing RFCs? 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.

RFC 5575 and RFC 7674 will be obsoleted by this document.

They are listed on the title page header, and in the abstract.

(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.
Confirm that any referenced IANA registries have been clearly
identified. 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 5226).

IANA has allocated the SAFI values 133, 134 for RFC5575, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Flow Spec Component Types" for RFC5575, the reference needs to be updated to this document.

IANA has allocated the following code points from the "BGP Transitive Extended Community Types" registry for RFC 7674, the reference needs to be updated to this document.
0x81  Generic Transitive Experimental Use Extended Community Part 2
0x82  Generic Transitive Experimental Use Extended Community Part 3

IANA has allocated the following code points from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry for RFC 5575, the reference of these code points needs to be updated to this document.
0x06  Flow spec traffic-rate-bytes
0x07  Flow spec traffic-action (Use of the "Value" field is defined in the "Traffic Action Fields" registry)
0x08  Flow spec redirect AS-2byte format
0x09  Flow spec traffic-remarking 

IANA is requested to allocate a new code point for “Flow spec traffic-rate-packets” from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 2 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 3 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Traffic Action Fields" for RFC 5575, the reference needs to be updated to this document.

(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.

None.

(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, etc.

No review of automated checks required.

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 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard.
It defines protocol extensions and procedures for BGP flowspec.
Yes the type is indicated in the title page header.

(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

  This document defines a Border Gateway Protocol Network Layer
  Reachability Information (BGP NLRI) encoding format that can be used
  to distribute traffic Flow Specifications.  This allows the routing
  system to propagate information regarding more specific components of
  the traffic aggregate defined by an IP destination prefix.

  It specifies IPv4 traffic Flow Specifications via a BGP NLRI which
  carries traffic Flow Specification filter, and an Extended community
  value which encodes actions a routing system can take if the packet
  matches the traffic flow filters.  The flow filters and the actions
  are processed in a fixed order.  Other drafts specify IPv6, MPLS
  addresses, L2VPN addresses, and NV03 encapsulation of IP addresses.

  This document obsoletes RFC5575 and RFC7674 to correct unclear
  specifications in the flow filters and to provide rules for actions
  which interfere (e.g. redirection of traffic and flow filtering).

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

This draft clarifies the unclear specifications in RFC5575 and provide the clear rules for actions which interfere with each other. There were questions/discussion about the precedence order and combination of numeric operators, which have been resolved. There were also some discussions about the validation of flowspec components, which has been resolved as well. Recent discussion is about whether and how existing implementations are complied with the suggested behavior in this -bis document. Currently there are several options under consideration, hopefully this will be solved in next revision.
 

Document Quality

  Are there existing implementations of the protocol?

RFC 5575 has been widely implemented.
Depends on the solution chosen for the interfering actions, This document may require some modification to the existing RFC 5575 implementation. Currently there is no implementation report of this document, it is expected that authors will provide the implement report on idr wiki page.

Personnel

Document Shepherd: Jie Dong
Responsible Area Director: Alvaro Retana

(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 shepherd performed the review on:
1) Nits
2) Technical review 
3) Implementation report (None so far)
4) IPR check

The document shepherd think after the issue on the interfering actions is solved, the document is ready for publication.


(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.

Nothing beyond the normal checks.


(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.

None.


(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.

Robert Raszuk: no IPR
https://mailarchive.ietf.org/arch/msg/idr/YVhw3HWx5eGLkdr3VVhLUSB3LNU

Danny McPherson: no IPR
https://mailarchive.ietf.org/arch/msg/idr/fXrk2lOLkpBUEjhKPqncDoJvSkI3

Christoph Loibl: no IPR
https://mailarchive.ietf.org/arch/msg/idr/hDB-43QPMuUAjmPvgQCMGKQ4uXg

Martin Bacher: no IPR
https://mailarchive.ietf.org/arch/msg/idr/kXELcKcnqRTYGXvz3L4iS5x80L8

Susan Hares: no IPR
https://mailarchive.ietf.org/arch/msg/idr/7q0m8Ggj9uFYXmK60dvT6z2Nkl0

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosure.

(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? 

Solid consensus according to the review and discussion on the list.

(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.)

None.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

According to the ID nits check, there is one warning and several comments, which could be OK:
https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-rfc5575bis-11.txt


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not relevant for MIB Doctor, Media type, or URI.

(13) Have all references within this document been identified as
either normative or informative?

All references have been identified as either normative or informative.


(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 references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

None.

(16) Will publication of this document change the status of any
existing RFCs? 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.

RFC 5575 and RFC 7674 will be obsoleted by this document.

They are listed on the title page header, and in the abstract.

(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.
Confirm that any referenced IANA registries have been clearly
identified. 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 5226).

IANA has allocated the SAFI values 133, 134 for RFC5575, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Flow Spec Component Types" for RFC5575, the reference needs to be updated to this document.

IANA has allocated the following code points from the "BGP Transitive Extended Community Types" registry for RFC 7674, the reference needs to be updated to this document.
0x81  Generic Transitive Experimental Use Extended Community Part 2
0x82  Generic Transitive Experimental Use Extended Community Part 3

IANA has allocated the following code points from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry for RFC 5575, the reference of these code points needs to be updated to this document.
0x06  Flow spec traffic-rate-bytes
0x07  Flow spec traffic-action (Use of the "Value" field is defined in the "Traffic Action Fields" registry)
0x08  Flow spec redirect AS-2byte format
0x09  Flow spec traffic-remarking 

IANA is requested to allocate a new code point for “Flow spec traffic-rate-packets” from the “Generic Transitive Experimental Use Extended Community Sub-Types” registry.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 2 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains the registry entitled “Generic Transitive Experimental Use Extended Community Part 3 Sub-Types” for RFC7674, the reference needs to be updated to this document.

IANA has created and maintains a registry entitled "Traffic Action Fields" for RFC 5575, the reference needs to be updated to this document.

(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.

None.

(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, etc.

No review of automated checks required.