Dissemination of Flow Specification Rules
draft-ietf-idr-flow-spec-09

I just corrected the RFC editor's note to reflect new email and address information for Robert Raszuk as follows:

  Please kindly change Robert Raszuk's email address to: raszuk@cisco.com

  And his address to:

    Robert Raszuk
    Cisco Systems
    170 West Tasman Drive
    San Jose, CA  95134
    USA

[Ballot comment]
1) I have let go off my IPv6 discuss, on the basis that Danny McPherson
has promised to write a document on this, and the RTG ADs agree that the
work belongs in the charter and should be done.

2) I would suggest that the document needs to talk more about in which
situations the use of flowspec is appropriate, e.g., dos prevention,
disabling specific attacks, etc. vs. any routing of flows in the core
of the internet. The additions to the text clear my discuss, explaining
the proper usage would do far more to convince the reader that this does
not cause a scalability problem than saying "its not been a problem and
we can build bigger routers", which the current text basically states.
(FWIW I believe that is a true statement, but nevertheless.)

[Ballot comment]
I would suggest that the document needs to talk more about in which
situations the use of flowspec is appropriate, e.g., dos prevention,
disabling specific attacks, etc. vs. any routing of flows in the core
of the internet. The additions to the text clear my discuss, explaining
the proper usage would do far more to convince the reader that this does
not cause a scalability problem than saying "its not been a problem and
we can build bigger routers", which the current text basically states.
(FWIW I believe that is a true statement, but nevertheless.)

[Ballot discuss]
Is there an IPv6 counterpart of this specification already in the works?
As has been discussed in previous cases, it is OK to produce different
documents for IPv4 and IPv6. However, generally speaking it is not OK
to ignore IPv4/IPv6 differences, security, internationalization, or
any issue like that in new IETF specifications. So completely ignoring
IPv6 would be inappropriate, and the chairs and ADs should ensure
that if there is work to do extensions, then all the required components
of such extensions are in the WG's program.

[Ballot discuss]
I have one concern about the changes to Section 5.1 in version -07.

All versions of this draft since 2004 have defined the ordering as
"memcmp the NLRI key byte strings". Version -07 changed the ordering
algorithm quite a bit.

I don't really care which algorithm is used, but they produce
different results in some situations. Since we have multiple interoperable
implementations, which algorithm do they use? And if they use the memcmp
variant, does changing the algorithm cause problems?

[Ballot comment]
Couple of minor nits:

- There are two places where it would be useful to clarify how the
6-bit DSCP value is stored in a byte: In Section 4, I'd suggest adding
something like "Values are encoded using a single byte, where the two
most significant bits are zero, and the six least significant bits
contain the DSCP value." for Type 11. In Section 7 ("traffic-marking"
community), I'd suggest changing the last sentence to something like
"This extended community is encoded as six bytes: the 6 least
significant bits of the final byte contain the DSCP value, and the
remaining 42 bits are zero."

(This means the bit layout of the value byte is different from the 2nd
byte of the IP header, where the DSCP values occupies the 6 most
significant bits.)

- Section 7, "redirect" community: how is this community encoded?  Six
unused/reserved bytes, or something else?

- Section 7, "traffic-rate" community: having a reference for the IEEE
floating point format wouldn't hurt.

[Ballot comment]
Health warnings and ACL configuration by management interfaces are not defined. This may be within the scope of future work in the OPS area - formalized by some form of SMI.

[Ballot comment]
It seems the WG has taken on work that it was not chartered to
do. Given that this is not a minor or insignificant work item, it
should have gone through the usual IETF consensus process required
for chartering new work.

However, it seems doing the rechartering now would only delay the
publication by a month or so, with no other change in the situation.
So I don't think we need to do that.

[Ballot discuss]
I am a bit concerned that information about the IPR disclosure was
posted to the IDR WG mailing list only yesterday (over 7 weeks after
the WG chairs were informed of the first disclosure), so
realistically, folks have not yet had time to digest it.

I have also one other concern: beyond a one-word mention in Section 2,
the spec is silent about its effect on number of BGP updates.  If the
specification would get widely deployed, and fine-grained filtering
rules would be produced by e.g. intrusion detection systems, it seems
the number of BGP messages flying around could dramatically increase
(putting strain on router control planes). Has the WG considered
this aspect? Should the document contain more text about this?


In addition, there are couple of places that probably need some
clarifications (probably the intent is correct, but the text isn't
exactly saying what was intended). All these are minor, and should
be easy to address.

Section 4 has couple of places where it probably should explicitly
specify how components are evaluated in corner cases:

- Types 4/5/6: should the text say something like "The component
  evaluates as FALSE if the packet is not TCP or UDP, or it is a
  fragment where the port number fields are not present"? If
  not, what the behavior should be?

- Types 7/8: same question -- "The component evaluates as FALSE
  if the packet is not an ICMPv4 packet, or it is a fragment where
  the Type (or Code) field is not present"?

- Type 9: same here -- "The component evaluates as FALSE if the packet
  is not a TCP packet, or it is a fragment where the flags are
  not present"?

Section 4, Type 9: the text says the bitmask is encoded using a single
byte -- but the space for flags in TCP header is 12 bits, not 8 (and
currently, 9 of the bits have been defined), so a byte is not enough.

Section 4, Type 11: to me it seems this component probably should
match just the 6-bit DSCP field, not the whole TOS field. Otherwise,
matching all packets with, say, DSCP 010110 (AF23) would require four
components (one for each possible combination of the two ECN bits,
since this is defined as normal operator, not bitmask operator).

Section 5.1: memcmp() compares two byte strings of equal length, so
it does define an ordering for byte strings of different lengths.

Section 7, "traffic-rate" community: the spec does not say what
the recipient should do with the first two octets? Ignore them?
Try to compare them against the 2 least significant bytes of the
AS number?

Section 7, "traffic-rate" community: having a reference for the
IEEE floating point format wouldn't hurt.

Sections 7 and 11: the bit numbering for "Traffic Action Fields" is
inconsistent with the main BGP spec (where, like in most IETF specs,
the most significant bit is 0). I'd suggest changing the numbering
and adding a bit diagram to Section 7 to make things clearer.

Section 8, last paragraph: there seems to be some extra text after the
description of "redirect" community -- perhaps an earlier version of
the draft also had a "traffic-marking" community?

[Ballot discuss]
(1) The IPR disclosure was not raised as an issue on the list until 2/11/09:

  http://www.ietf.org/mail-archive/web/idr/current/msg03606.html

There has been no response to date, but I believe more time should be allowed
for discussion.

(2) I would like to know if work is underway to define match criteria for other BGP
address families - specifically what about IPv6?

  This specification defines required protocol extensions to address
  most common applications of IPv4 unicast and VPNv4 unicast filtering.
  The same mechanism can be reused and new match criteria added to
  address similar filtering needs for other BGP address families (for
  example IPv6 unicast).  Authors believe that those would be best to
  be addressed in a separate document.

My issue is not with the scoping for this document, simply whether work
is underway or planned.

[Ballot discuss]
This document needs to talk about the increased use of more specifics,
where it is appropriate, what problems it might cause, and provide
recommendations on avoiding those problems. I found the following
statement inadequate:

  The choice of BGP as the carrier of this control information is also
  justifiable by the fact that the key issues in terms of complexity
  are problems which are common to unicast route distribution and have
  already been solved in the current environment.

For instance, is it appropriate to distribute flow-based information
in the global routing table, or just locally between a customer and
provider, or only for some specialized circumstances, such as DoS
attacks? People have worried about the increased size of routing
tables due to IPv6 for quite some time, but I think this extension,
if widely used, would be a far more practical concern. Note that
I believe it is a useful extension and should be standardized, just
that you should talk more about the implications and provide guidance
to avoid bad effects.

The following excerpt of the security considerations section appeared
to be saying that MTU problems are not a serious issue and greatly
confusing to the users:

  ... permit packets smaller than 900 or greater than 1000
  bytes to pass between a pair of addresses, but not packets whose
  length is in the range 900-1000.  The Internet has become
  sufficiently aware of firewalls that such behavior is less likely to
  be confusing than it was a few years ago ...

I agree that MTU problems are not surprising, but they are still very
confusing. And the 900-1000 hole issue would IMHO be also surprising.
Perhaps you want to rephrase the above to make it clear that significant
problems can arise from the misuse of these facilities. Your point that
other mechanisms, such as firewalls already create similar issues. But
the issues from both sources are still significant.

Is there an IPv6 counterpart of this specification already in the works?
As has been discussed in previous cases, it is OK to produce different
documents for IPv4 and IPv6. However, generally speaking it is not OK
to ignore IPv4/IPv6 differences, security, internationalization, or
any issue like that in new IETF specifications. So completely ignoring
IPv6 would be inappropriate, and the chairs and ADs should ensure
that if there is work to do extensions, then all the required components
of such extensions are in the WG's program.

I agree with the Discusses that suggested the document needs to go back
to the WG. In my own read of the recently submitted license it would be
OK to proceed with the doc, but it is good to get the WG to weigh in on
that.

[Ballot discuss]
This document needs to talk about the increased use of more specifics,
where it is appropriate, what problems it might cause, and provide
recommendations on avoiding those problems. I found the following
statement inadequate:

  The choice of BGP as the carrier of this control information is also
  justifiable by the fact that the key issues in terms of complexity
  are problems which are common to unicast route distribution and have
  already been solved in the current environment.

For instance, is it appropriate to distribute flow-based information
in the global routing table, or just locally between a customer and
provider, or only for some specialized circumstances, such as DoS
attacks? People have worried about the increased size of routing
tables due to IPv6 for quite some time, but I think this extension,
if widely used, would be a far more practical concern. Note that
I believe it is a useful extension and should be standardized, just
that you should talk more about the implications and provide guidance
to avoid bad effects.

The following excerpt of the security considerations section appeared
to be saying that MTU problems are not a serious issue and greatly
confusing to the users:

  ... permit packets smaller than 900 or greater than 1000
  bytes to pass between a pair of addresses, but not packets whose
  length is in the range 900-1000.  The Internet has become
  sufficiently aware of firewalls that such behavior is less likely to
  be confusing than it was a few years ago ...

I agree that MTU problems are not surprising, but they are still very
confusing. And the 900-1000 hole issue would IMHO be also surprising.
Perhaps you want to rephrase the above to make it clear that significant
problems can arise from the misuse of these facilities. Your point that
other mechanisms, such as firewalls already create similar issues. But
the issues from both sources are still significant.

I agree with the Discusses that suggested the document needs to go back
to the WG. In my own read of the recently submitted license it would be
OK to proceed with the doc, but it is good to get the WG to weigh in on
that.

[Ballot discuss]
This document needs to talk about the increased use of more specifics,
where it is appropriate, what problems it might cause, and provide
recommendations on avoiding those problems. I found the following
statement inadequate:

  The choice of BGP as the carrier of this control information is also
  justifiable by the fact that the key issues in terms of complexity
  are problems which are common to unicast route distribution and have
  already been solved in the current environment.

For instance, is it appropriate to distribute flow-based information
in the global routing table, or just locally between a customer and
provider, or only for some specialized circumstances, such as DoS
attacks?

The following excerpt of the security considerations section appeared
to be saying that MTU problems are not a serious issue and greatly
confusing to the users:

  ... permit packets smaller than 900 or greater than 1000
  bytes to pass between a pair of addresses, but not packets whose
  length is in the range 900-1000.  The Internet has become
  sufficiently aware of firewalls that such behavior is less likely to
  be confusing than it was a few years ago ...

I agree that MTU problems are not surprising, but they are still very
confusing. And the 900-1000 hole issue would IMHO be also surprising.
Perhaps you want to rephrase the above to make it clear that significant
problems can arise from the misuse of these facilities. Your point that
other mechanisms, such as firewalls already create similar issues. But
the issues from both sources are still significant.

I agree with the Discusses that suggested the document needs to go back
to the WG. In my own read of the recently submitted license it would be
OK to proceed with the doc, but it is good to get the WG to weigh in on
that.

[Ballot comment]
I support the DISCUSS from Lisa and the part of the DISCUSS by Lars concerning the document being out of scope the currently approved charter. As these two issues are critical in my opinion, I am refraining from casting a ballot until they are discussed and a proper solution is proposed for both.

[Ballot discuss]
I agree with Lars's DISCUSS about the WG charter -- it seems the WG
has taken on work that it was not chartered to do. Given that this
is not a minor or insignificant work item, skipping the usual
IETF consensus process required for chartering new work seems wrong.

I am also concerned that information about the IPR disclosure was
posted to the IDR WG mailing list only yesterday (over 7 weeks after
the WG chairs were informed of the first disclosure), so
realistically, folks have not yet had time to digest it.

I have also one other concern: beyond a one-word mention in Section 2,
the spec is silent about its effect on number of BGP updates.  If the
specification would get widely deployed, and fine-grained filtering
rules would be produced by e.g. intrusion detection systems, it seems
the number of BGP messages flying around could dramatically increase
(putting strain on router control planes). Has the WG considered
this aspect? Should the document contain more text about this?


In addition, there are couple of places that probably need some
clarifications (probably the intent is correct, but the text isn't
exactly saying what was intended). All these are minor, and should
be easy to address.

Section 4 has couple of places where it probably should explicitly
specify how components are evaluated in corner cases:

- Types 4/5/6: should the text say something like "The component
  evaluates as FALSE if the packet is not TCP or UDP, or it is a
  fragment where the port number fields are not present"? If
  not, what the behavior should be?

- Types 7/8: same question -- "The component evaluates as FALSE
  if the packet is not an ICMPv4 packet, or it is a fragment where
  the Type (or Code) field is not present"?

- Type 9: same here -- "The component evaluates as FALSE if the packet
  is not a TCP packet, or it is a fragment where the flags are
  not present"?

Section 4, Type 9: the text says the bitmask is encoded using a single
byte -- but the space for flags in TCP header is 12 bits, not 8 (and
currently, 9 of the bits have been defined), so a byte is not enough.

Section 4, Type 11: to me it seems this component probably should
match just the 6-bit DSCP field, not the whole TOS field. Otherwise,
matching all packets with, say, DSCP 010110 (AF23) would require four
components (one for each possible combination of the two ECN bits,
since this is defined as normal operator, not bitmask operator).

Section 5.1: memcmp() compares two byte strings of equal length, so
it does define an ordering for byte strings of different lengths.

Section 7, "traffic-rate" community: the spec does not say what
the recipient should do with the first two octets? Ignore them?
Try to compare them against the 2 least significant bytes of the
AS number?

Section 7, "traffic-rate" community: having a reference for the
IEEE floating point format wouldn't hurt.

Sections 7 and 11: the bit numbering for "Traffic Action Fields" is
inconsistent with the main BGP spec (where, like in most IETF specs,
the most significant bit is 0). I'd suggest changing the numbering
and adding a bit diagram to Section 7 to make things clearer.

Section 8, last paragraph: there seems to be some extra text after the
description of "redirect" community -- perhaps an earlier version of
the draft also had a "traffic-marking" community?

[Ballot discuss]
I thought this document was going to be removed from consideration
for this telechat.  The IPR that was disclosed and then replaced has
not been reviewed by the WG.

[Ballot comment]
Section 2., paragraph 2:
>    While forwarding information is, typically, dynamically signaled
>    across the network via routing protocols, there is no agreed upon
>    mechanism to dynamically signal flows across autonomous-systems.

  This is incorrect. RSVP has been used for this purpose for a long
  time. See RFC2210.


Section 4., paragraph 28:
>      Type 4 - Port
>          Encoding:
>          Defines a list of {operation, value} pairs that matches source
>          OR destination TCP/UDP ports.  This list is encoded using the
>          numeric operand format defined above.  Values are encoded as 1
>          or 2 byte quantities.

  SCTP and DCCP also use port numbers. Suggest to add them to the list
  above. (Same for source and destination ports below.)

[Ballot discuss]
DISCUSS: I may be missing something, but I don't see a work item for
  this technology on the IDR charter page. What I do see is "new items
  to be added to the charter must be approved by the IESG", and a work
  item that attempts to turn BGP into a dissemination mechanism for
  fine-grained traffic filtering specifications is definitely something
  we should have discussed much earlier. (The charter is also pretty
  clear that IDR was tasked to revise the BGP4 MIB before taking on any
  of the other listed work items, much less new work items that aren't
  on the charter.)


Section 4., paragraph 40:
>      Type 9 - TCP flags
>          Encoding:
>          Bitmask values are encoded using a single byte, using the bit
>          definitions specified in the TCP header format [RFC0793].

  DISCUSS: It is inappropriate for this mechanism to signal information
  about TCP header bits (or UDP, DCCP or SCTP header bits, for that
  matter). On an architectural level, it's a layering violation, but
  more importantly, on a practical level, it limits the evolvability of
  TCP if other protocols make incorrect assumptions about its header
  structure. For example, TCP has grown new control bits since RFC0793
  (see RFC3168), and is likely to grow yet more in the future.


Section 4., paragraph 48:
>      Type 11 - DSCP
>          Encoding:
>          Defines a list of {operation, value} pairs used to match the IP
>          TOS octet.

  DISCUSS: The DSCP bits are not equal to the TOS octet - DSCP is a
  six-bit value. Bits 6 and 7 of the former TOS octext are now the ECN
  bits. Is the intent to include them here (why)?

[Ballot discuss]
As pointed out in the Gen-ART Review by Brian Carpenter posted on
  24-Jan-2009, the IANA considerations ought to use the term "IETF
  Review" as it is defined in RFC 5226.  I expect an RFC Editor note
  is the most efficient way to resolve this concern.

IANA Last Call questions/comments:

- Are you asking for a registry for the Traffic-action
extended community "bits"? If so:
* What should be the name of this registry?
* What are the registration procedures? The IANA Considerations
currently list IETF Consensus, Standards Action, Early
Allocation, AND First Come First Served.

Action 1:

Upon approval of this document, IANA will make the following
changes in the "Subsequent Address Family Identifiers (SAFI)"
registry at
http://www.iana.org/assignments/safi-namespace

OLD:

Value Description Reference
------- ---------------------------------------------- ---------
133 Dissemination of flow specification rules
[draft-marques-idr-flow-spec]
134 Dissemination of flow specification rules
[draft-marques-idr-flow-spec]

NEW:

Value Description Reference
------- ---------------------------------------------- ---------
133 Dissemination of flow specification rules [RFC-idr-flow-spec-03]
134 Dissemination of flow specification rules [RFC-idr-flow-spec-03]


Action 2:

Upon approval of this document, IANA will make the following
assignments in the "BGP Extended Communities Type - Experimental
Use" registry at
http://www.iana.org/assignments/bgp-extended-communities

Type Value Name Reference
------------ --------------------------------------- ---------
0x8006 Flow spec traffic-rate [RFC-idr-flow-spec-03]
0x8007 Flow spec traffic-action [RFC-idr-flow-spec-03]
0x8008 Flow spec redirect [RFC-idr-flow-spec-03]


Action 3:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/TBD-TYPE

Registry Name: Flow Spec Component Type
Registration Procedures: Specification Required

Initial contents of this registry will be:

Type Description Reference
------ ----------------- -----------
0 Reserved [RFC-idr-flow-spec-03]
1 Destination Prefix [RFC-idr-flow-spec-03]
2 Source Prefix [RFC-idr-flow-spec-03]
3 IP Protocol [RFC-idr-flow-spec-03]
4 Port [RFC-idr-flow-spec-03]
5 Destination port [RFC-idr-flow-spec-03]
6 Source port [RFC-idr-flow-spec-03]
7 ICMP type [RFC-idr-flow-spec-03]
8 ICMP code [RFC-idr-flow-spec-03]
9 TCP flags [RFC-idr-flow-spec-03]
10 Packet length [RFC-idr-flow-spec-03]
11 DSCP [RFC-idr-flow-spec-03]
12 Fragment [RFC-idr-flow-spec-03]
13-127 Unassigned
128-255 Reserved for Private Use [RFC-idr-flow-spec-03]

Action 4 (see questions above):

Upon approval of this document, the IANA will create the following
registry at
http://www.iana.org/assignments/TBD-TA

Registry Name: Traffic Action Fields?
Registration Procedures: IETF Consensus, Standards Action, Early IANA
Allocation, or First Come First Served?

Initial contents of this registry will be:

Bit Description Reference
---- ----------- ---------
0 Terminal Action [RFC-idr-flow-spec-03]
1 Sample [RFC-idr-flow-spec-03]
2-47 Unassigned

We understand the above to be the only IANA Actions for this document.

Proto writeup by Yakov Rekhter:

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

  The Document Shepherd is myself (Yakov Rekhter). I believe that
  the 03 version is ready for forwarding to the IESG for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

  The document passed the IDR WG Last Call, although we received
  no comments on the document during the Last Call.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

  No.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues 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.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

  No concerns.

  (1.e)  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?

  There were no objections during the WG Last Call on the document.
  However, it seems that the consensus represents the strong concurrence
  of a few individuals, with others being silent.

  (1.f)  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
          entered into the ID Tracker.)

    No.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

    Yes.

  (1.h)  Has the document split its references into normative and
          informative?  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
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

  The document split its references. There are no normative
  references that are not ready for advancement.

  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

  The document contains IANA consideration section. To the best
  of my knowledge IANA consideration section is consistent with
  the body of the document. The document specifies reservations
  in the appropriate IANA registries. The registries are clearly
  identifiable. The document does create a new registry, and
  does all the necessary steps for this registry.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

  No sections of the document are written in a formal language.


  (1.k)  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
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

  This document defines a new 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.

  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
  traffic filtering in the context of a BGP/MPLS VPN service.

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

          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 document is a product of IDR WG. There were no comments
    on the document during the WG Last Call.

          Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type or other expert review,
            what was its course (briefly)?  In the case of a Media Type
            review, on what date was the request posted?

    There are two implementations of this specification.
    The implementation report is available (see
    draft-raszuk-idr-flow-spec-impl-00).