MIME-Version: 1.0
References: <CAMMESsxHXUB_jQk7E9FkeNef2C7DDcbiEvnROFdbEjAVtMqcFA@mail.gmail.com>
 <76CD132C3ADEF848BD84D028D243C927CD15601E@NKGEML515-MBX.china.huawei.com>
 <002101d56956$1c91d180$55b57480$@ndzh.com>
In-Reply-To: <002101d56956$1c91d180$55b57480$@ndzh.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 12 Sep 2019 14:41:48 +0200
Message-ID: <CAOj+MMGkihs4dUT3n86RpZDXfgH=rK1Cm4gL47QCk4Vx6ZtLQQ@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Cc: "Dongjie (Jimmy)" <jie.dong@huawei.com>,
 Alvaro Retana <aretana.ietf@gmail.com>, 
 draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, 
 "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001548c805925a770f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/p7zEbsrMfUPA8eU01RwqYIDblY8>
Subject: Re: [Idr] AD Review of draft-ietf-idr-rfc5575bis-17
Precedence: list

--0000000000001548c805925a770f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Sue,

As WG participant I would like to point out that making all specs to
support both v4 and v6 may be a bit short sighted.

At some point in the future (and in some cases already today for example
access points and modems)  only IPv6 is supported - no IPv4. So if we
continue to mandate that all specs must contain and support both address
families it makes it very hard to any modern equipment IPv6 only vendor to
declare support for given RFC.

So IMO it is in best interest of any IETF spec to split IPv4 from IPv6 into
different documents. The push to add IPv6 into all drafts/rfcs perhaps was
a good move initially to a bit force IPv6 extensions, but I do not think it
is good idea long term. Also note that there are some solutions only
proposed to be used over IPv6 networks.

So here specifically with IPv6 we are talking of completely different match
criteria (IPv6 fixed and extension headers) have completely different
format and functionality then IPv4, both use different AFI/SAFIs etc ... so
here you would essentially artificially squeeze two documents into one. I
am not sure if this

Thx,
R.





On Thu, Sep 12, 2019 at 12:38 PM Susan Hares <shares@ndzh.com> wrote:

> Alvaro:
>
>
>
> <WG chair hat on>
>
>
>
> Question:
>
> I understand why this document only focuses on IPv4.  While the text
> points at draft-ietf-idr-flow-spec-v6, that draft has been expired for ov=
er
> a year!  What is the plan to move that work forward?  It looks like there
> may already be implementations in place [4].
>
>
>
> Answer:
>
> The direction from the WG was to limit the draft to RFC5575 fixes.
>
> If you feel strongly, this can be queried to the WG again.
>
>
>
> <WG chair off>
>
> <author hat on>
>
> If WG agrees, this could be added to the draft.
>
> </author hat off>
>
>
>
> Sue Hares
>
>
>
>
>
> *From:* Dongjie (Jimmy) [mailto:jie.dong@huawei.com]
> *Sent:* Thursday, September 12, 2019 5:14 AM
> *To:* Alvaro Retana; draft-ietf-idr-rfc5575bis@ietf.org
> *Cc:* idr-chairs@ietf.org; idr@ietf. org
> *Subject:* RE: AD Review of draft-ietf-idr-rfc5575bis-17
>
>
>
> Hi Alvaro,
>
>
>
> Thanks pointing out the IPR issue with this -bis document. I will check
> the third-party disclosure procedure and file related disclosures later
> today.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Alvaro Retana [mailto:aretana.ietf@gmail.com]
> *Sent:* Wednesday, September 11, 2019 12:09 AM
> *To:* draft-ietf-idr-rfc5575bis@ietf.org
> *Cc:* Dongjie (Jimmy) <jie.dong@huawei.com>; idr-chairs@ietf.org;
> idr@ietf. org <idr@ietf.org>
> *Subject:* AD Review of draft-ietf-idr-rfc5575bis-17
>
>
>
> Dear authors:
>
>
>
> I just finished reading this document.  Thank you for the work in
> clarifying and updating rfc5575!  Many of my comments (see below) are
> related to what I think is still missing clarity, or lack of it in some o=
f
> the new text.
>
>
>
> Besides the specific comments, I have some larger issues that I want to
> detail here.  The first 2 are directed at the Shepherd and Chairs.
>
>
>
> (A) IPR
>
>
>
> The Shepherd report, the datatracker and the WGLC thread [1] all point at
> no existing IPR.  However, several declarations do exist...for rfc5575
> [2].  IMO, the changes between rfc5575 and this document are not that
> significant to assume that the declarations don't apply.  I also note tha=
t
> none of the original authors mentioned as "contributing authors" (=C2=A71=
5)
> replied to the IPR call during the WGLC.
>
>
>
> Jie: As Shepherd, can you please file a third-party disclosure [3]
> pointing at the rfc5575 disclosures?  Once that is done I will send a
> message to the WG to consider the information -- I don't expect any issue=
s,
> but it has to be done. I'll need you to also update the Shepherd writeup.
> Thanks!
>
>
>
>
>
> (B) Support for IPv6
>
>
>
> I understand why this document only focuses on IPv4.  While the text
> points at draft-ietf-idr-flow-spec-v6, that draft has been expired for ov=
er
> a year!  What is the plan to move that work forward?  It looks like there
> may already be implementations in place [4].
>
>
>
> We all know this question will come up during IESG Evaluation, specially
> in light of the IAB Statement on IPv6 [5] and the fact that there was a
> related DISCUSS when rfc5575 was first processed [6] -- at that time
> (2009!) the objection was cleared with the promise that an IPv6 document
> would be forthcoming.
>
>
>
> We should have a plan in place by the time this document makes it to the
> IESG Telechat.  It would have been ideal to publish both at the same time=
,
> but I'll settle for the ability to (at least) point at the WGLC (which ha=
s
> been brought up before [7]).
>
>
>
>
>
> (C) IANA Considerations
>
>
>
> (C1) traffic-rate-packets
>
>
>
> The instructions to IANA for the assignment of the traffic-rate-packets
> sub-type are not clear.  The existing assignments and the requirement tha=
t
> "traffic actions are processed in ascending order of the sub-type" (=C2=
=A77)
> seem to imply that a specific order for this new action may be intended.
> Unless explicitly instructed, IANA may not assign a value that aligns wit=
h
> that intent.  [See related comments in =C2=A77.2.]
>
>
>
> (C2) Experimental Use Ranges
>
>
>
> This document uses ranges from the "BGP Transitive Extended Community
> Types" registry which are reserved for Experimental Use.  While the histo=
ry
> of this use is not clear, we should take the opportunity to clean the
> registry.  [See more in =C2=A712.3.]
>
>
>
>
>
> (D) Document organization
>
>
>
> This document kept most of the Introduction text, but then added related
> and, in some cases, overlapping and redundant text in =C2=A75 (not =C2=A7=
5.1) and
> =C2=A79.  Please combine the information from =C2=A71 and =C2=A75, and th=
e background from
> =C2=A79 into an updated Introduction.  =C2=A76 seems to belong right afte=
r the
> definition of the NLRI (=C2=A74), and before the next part of the specifi=
cation
> (filtering) starts with =C2=A75.1, then =C2=A77...
>
>
>
> Most of the old text is about justification, some from the specific point
> of view of the then-authors.  Please reconsider whether that still applie=
s.
>
>
>
>
>
> I will wait for the major issues/comments to be addressed before starting
> the IETF Last Call.
>
>
>
> Thanks!
>
>
>
> Alvaro.
>
>
>
>
>
> [1] https://mailarchive.ietf.org/arch/msg/idr/0WQW0pdqq1ae31GYZ7-dk3_Wqv8
>
> [2] https://datatracker.ietf.org/ipr/search/?rfc=3D5575&submit=3Drfc
>
> [3] https://datatracker.ietf.org/ipr/new-third-party/
>
> [4] https://mailarchive.ietf.org/arch/msg/idr/VH0mYVgT39ueJapb0axMgfgcAN8
>
> [5] https://www.iab.org/2016/11/07/iab-statement-on-ipv6/
>
> [6] https://datatracker.ietf.org/doc/rfc5575/history/
>
> [7] https://mailarchive.ietf.org/arch/msg/idr/0J6gWHgBx33u8WpTa0B73mI6rIM
>
>
>
>
>
>
>
> [Line numbers from idnits.]
>
>
>
> ...
>
> 17  Abstract
>
>
>
> [nit] It is interesting to me that the Abstract was significantly
> rewritten while the Introduction was mostly left unchanged.  I assume thi=
s
> was done to reflect the changes in the document upfront...but it then
> results in, what I think, is an Abstract that is too long, and an
> incomplete Introduction.
>
>
>
> 19    This document defines a Border Gateway Protocol Network Layer
>
> 20    Reachability Information (BGP NLRI) encoding format that can be use=
d
>
> 21    to distribute traffic Flow Specifications.  This allows the routing
>
> 22    system to propagate information regarding more specific components
> of
>
> 23    the traffic aggregate defined by an IP destination prefix.
>
>
>
> 25    It specifies IPv4 traffic Flow Specifications via a BGP NLRI which
>
> 26    carries traffic Flow Specification filter, and an Extended communit=
y
>
> 27    value which encodes actions a routing system can take if the packet
>
> 28    matches the traffic flow filters.  The flow filters and the actions
>
> 29    are processed in a fixed order.  Other drafts specify IPv6, MPLS
>
> 30    addresses, L2VPN addresses, and NV03 encapsulation of IP addresses.
>
>
>
> [nit] s/carries traffic Flow Specification filter/carries a traffic Flow
> Specification filter
>
>
>
> [minor] I think that this paragraph, or something like it, belongs in the
> Introduction (and not the Abstract), because it provides information that
> could benefit from references:
>
>
>
> - the two parts of the NLRI; BTW, the community is not even mentioned in
> the Introduction.
>
>
>
> - other drafts... The Introduction only mentions and provides a reference
> to the IPv6 work.
>
>
>
> 32    This document obsoletes RFC5575 and RFC7674 to correct unclear
>
> 33    specifications in the flow filters.
>
>
>
> [major] Please add a similar statement in the Introduction, with
> references to both RFCs.  There should be an Informative reference to bot=
h.
>
>
>
> [minor] Appendix A talks about the difference of this document with
> respect to rfc5575.  What about rfc7674?  It looks like any updates from
> rfc7674 have been incorporated in this document.  It would be very nice,
> even if just for completion, if there was an Appendix that talked about
> rfc7674 -- I even think that a sub-section of Appendix A would be enough.
>
>
>
> 35    Applications which use the bgp Flow Specification are: 1)
> application
>
> 36    which automate inter-domain coordination of traffic filtering, such
>
> 37    as what is required in order to mitigate (distributed) denial-of-
>
> 38    service attacks; 2) applications which control traffic filtering in
>
> 39    the context of a BGP/MPLS VPN service, and 3) applications with
>
> 40    centralized control of traffic in a SDN or NFV context.  Some
>
> 41    deployments of these three applications can be handled by the stric=
t
>
> 42    ordering of the BGP NLRI traffic flow filters, and the strict
> actions
>
> 43    encoded in the extended community Flow Specification actions.
>
>
>
> [minor] Please move this paragraph to the Introduction.
>
>
>
> [nit] s/extended community/Extended Community/g
>
>
>
>
>
> ...
>
> 133       1.  Introduction
>
> ...
>
> 149         This document defines a general procedure to encode flow
>
> 150         specification rules for aggregated traffic flows so that they
> can be
>
> 151         distributed as a BGP [RFC4271] NLRI.  Additionally, we define
> the
>
> 152         required mechanisms to utilize this definition to the problem
> of
>
> 153         immediate concern to the authors: intra- and inter-provider
>
> 154         distribution of traffic filtering rules to filter
> (distributed)
>
> 155         denial-of-service (DoS) attacks.
>
>
>
> [minor] The document uses "Flow Specification" and "flow specification" t=
o
> refer to the same thing...right?  Or are there differences due to the
> capitalization?  Please be consistent.
>
>
>
> [style nit] Using "we" is not the best for a consensus document.  s/we
> define/it defines
>
>
>
> [nit] "problem of immediate concern to the authors"  Only the authors?
> This piece of text was also present in rfc5575 -- having a different set =
of
> authors, I would assume we can safely say that the concern/application go=
es
> beyond the authors...right?  Please reword.
>
>
>
> [minor] Given that this is a bis, is the motivation still the same?  I
> think in part it is, but in part there may be other drivers.  Just asking=
...
>
>
>
> [minor] This seems to be a good place to move the text from the Abstract
> that describes applications...
>
>
>
> ...
>
> 164         A Flow Specification received from an external autonomous
> system will
>
> 165         need to be validated against unicast routing before being
> accepted.
>
> 166         If the aggregate traffic flow defined by the unicast
> destination
>
> 167         prefix is forwarded to a given BGP peer, then the local
> system can
>
> 168         install more specific flow rules that may result in different
>
> 169         forwarding behavior, as requested by this system.
>
>
>
> [major] "A Flow Specification received from an external autonomous system
> will need to be validated against unicast routing before being accepted."
>  What about if received internally?
>
>
>
> 171         The key technology components required to address the class o=
f
>
> 172         problems targeted by this document are:
>
>
>
> 174         1.  Efficient point-to-multipoint distribution of control
> plane
>
> 175             information.
>
>
>
> 177         2.  Inter-domain capabilities and routing policy support.
>
>
>
> 179         3.  Tight integration with unicast routing, for verification
>
> 180             purposes.
>
>
>
> 182         Items 1 and 2 have already been addressed using BGP for other
> types
>
> 183         of control plane information.  Close integration with BGP
> also makes
>
> 184         it feasible to specify a mechanism to automatically verify
> flow
>
> 185         information against unicast routing.  These factors are
> behind the
>
> 186         choice of BGP as the carrier of Flow Specification
> information.
>
>
>
> [nit] I don't think that we need to keep justifying...  Just a nit...
>
>
>
> 188         As with previous extensions to BGP, this specification makes
> it
>
> 189         possible to add additional information to Internet routers.
> These
>
> 190         are limited in terms of the maximum number of data elements
> they can
>
> 191         hold as well as the number of events they are able to process
> in a
>
> 192         given unit of time.  The authors believe that, as with
> previous
>
> 193         extensions, service providers will be careful to keep
> information
>
> 194         levels below the maximum capacity of their devices.
>
>
>
> 196         Experience with previous BGP extensions has also shown that
> the
>
> 197         maximum capacity of BGP speakers has been gradually increased
>
> 198         according to expected loads.  For example Internet unicast
> routing as
>
> 199         well as other BGP applications increased their maximum
> capacity as
>
> 200         they gain popularity.
>
>
>
> [minor] This is the same text from 10 years ago.  Many things, including
> hardware processing/storage, has changed.  Is this text still necessary?
> If so, then I would like to see explicit operational considerations on wh=
at
> an operator should look for when being "careful".
>
>
>
>
>
> ...
>
> 214         In current deployments, the information distributed by the
> flow-spec
>
> 215         extension is originated both manually as well as
> automatically.  The
>
> 216         latter by systems that are able to detect malicious flows.
> When
>
> 217         automated systems are used, care should be taken to ensure
> their
>
> 218         correctness as well as to limit the number and advertisement
> rate of
>
> 219         flow routes.
>
>
>
> [major] An automated system that is not "correct", because it may not be
> properly programmed, the algorithms used are not performing as expected, =
or
> simply because it is rogue, are all vulnerabilities that should be called
> out in the Security Considerations section.
>
>
>
> 221         This specification defines required protocol extensions to
> address
>
> 222         most common applications of IPv4 unicast and VPNv4 unicast
> filtering.
>
> 223         The same mechanism can be reused and new match criteria added
> to
>
> 224         address similar filtering needs for other BGP address
> families such
>
> 225         as IPv6 families [I-D.ietf-idr-flow-spec-v6],
>
>
>
> [nit] s/[I-D.ietf-idr-flow-spec-v6],/[I-D.ietf-idr-flow-spec-v6].
>
>
>
>
>
> 227       2.  Definitions of Terms Used in This Memo
>
> ...
>
> 233         Loc-RIB -   Local RIB.
>
>
>
> [major] This simple definition doesn't match the one in =C2=A71.1/rfc4271=
.
>
>
>
>
>
> ..
>
> 247       3.  Flow Specifications
>
> ...
>
> 266         BGP itself treats the NLRI as an key to an entry in its
> databases.
>
> 267         Entries that are placed in the Loc-RIB are then associated
> with a
>
> 268         given set of semantics, which is application dependent.  This
> is
>
> 269         consistent with existing BGP applications.  For instance, IP
> unicast
>
> 270         routing (AFI=3D1, SAFI=3D1) and IP multicast reverse-path
> information
>
> 271         (AFI=3D1, SAFI=3D2) are handled by BGP without any particular
> semantics
>
> 272         being associated with them until installed in the Loc-RIB.
>
>
>
> [nit] s/an key/a key
>
>
>
> 274         Standard BGP policy mechanisms, such as UPDATE filtering by
> NLRI
>
> 275         prefix as well as community matching and manipulation, MUST
> apply to
>
> 276         the Flow Specification defined NLRI-type, especially in an
> inter-
>
> 277         domain environment.  Network operators can also control
> propagation
>
> 278         of such routing updates by enabling or disabling the exchange
> of a
>
> 279         particular (AFI, SAFI) pair on a given BGP peering session.
>
>
>
> [major] The point of NLRIs all being treated the same is made above, to
> reinforce the default BGP behavior...and this paragraph tries to bring ho=
me
> the point by Normatively enforcing it (MUST).  However, because the
> behavior is what BGP specifies by default, then this document cannot be
> Normative in it (unless it specified an exception).  s/MUST/must
>
>
>
> 281       4.  Dissemination of IPv4 FLow Specification Information
>
> ...
>
> 287         This NLRI information is encoded using MP_REACH_NLRI and
>
> 288         MP_UNREACH_NLRI attributes as defined in [RFC4760].  Whenever
> the
>
> 289         corresponding application does not require Next-Hop
> information, this
>
> 290         shall be encoded as a 0-octet length Next Hop in the
> MP_REACH_NLRI
>
> 291         attribute and ignored on receipt.
>
>
>
> [minor] s/Next-Hop/Next Hop       rfc4760 uses "Next Hop"
>
>
>
> [nit] "...shall be encoded as a 0-octet length Next Hop in the
> MP_REACH_NLRI attribute and ignored on receipt."  What is ignored?  The
> Next Hop?  If it doesn't exist (length =3D 0), then it can't be ignored..=
.
> Perhaps delete " and ignored on receipt".
>
>
>
> ...
>
> 297             +------------------------------+
>
> 298             |    length (0xnn or 0xfn nn)  |
>
> 299             +------------------------------+
>
> 300             |    NLRI value  (variable)    |
>
> 301             +------------------------------+
>
>
>
> [minor] s/0xfn nn/0xfnnn
>
>
>
>
>
> ...
>
> 312       4.1.  Length Encoding
>
>
>
> 314         o  If the NLRI length value is smaller than 240 (0xf0 hex),
> the
>
> 315            length field can be encoded as a single octet.
>
>
>
> [nit] s/240/240 octets
>
>
>
> 317         o  Otherwise, it is encoded as an extended-length 2-octet
> value in
>
> 318            which the most significant nibble of the first byte is all
> ones.
>
>
>
> 320         In figure 1 above, values less-than 240 are encoded using two
> hex
>
> 321         digits (0xnn).  Values above 239 are encoded using 3 hex
> digits
>
> 322         (0xfnnn).  The highest value that can be represented with thi=
s
>
> 323         encoding is 4095.  The value 241 is encoded as 0xf0f1.
>
>
>
> [nit] It may make more sense to show the encoding for 240.
>
>
>
>
>
> 325       4.2.  NLRI Value Encoding
>
> ...
>
> 332         The encoding of each of the NLRI components begins with a
> type field
>
> 333         (1 octet) followed by a variable length parameter.  Section
> 4.2.1 to
>
> 334         Section 4.2.12 define component types and parameter encodings
> for the
>
> 335         IPv4 IP layer and transport layer headers.  IPv6 NLRI
> component types
>
> 336         are described in [I-D.ietf-idr-flow-spec-v6].
>
>
>
> [minor] "followed by a variable length parameter"   Only the first two
> types have a variable length parameter...
>
>
>
> 338         Flow Specification components must follow strict type
> ordering by
>
> 339         increasing numerical order.  A given component type may
> (exactly
>
> 340         once) or may not be present in the specification.  If
> present, it
>
> 341         MUST precede any component of higher numeric type value.
>
>
>
> [major] What should happen if a component appears more than once?
>
>
>
> [major] What should happen if the order is not maintained?
>
>
>
> 343         All combinations of component types within a single NLRI are
> allowed,
>
> 344         even if the combination makes no sense from a semantical
> perspective.
>
> 345         If a given component type within a prefix in unknown, the
> prefix in
>
> 346         question cannot be used for traffic filtering purposes by the
>
> 347         receiver.  Since a Flow Specification has the semantics of a
> logical
>
> 348         AND of all components, if a component is FALSE, by definition
> it
>
> 349         cannot be applied.  However, for the purposes of BGP route
>
> 350         propagation, this prefix should still be transmitted since
> BGP route
>
> 351         distribution is independent on NLRI semantics.
>
>
>
> [nit] s/prefix in unknown/prefix is unknown
>
>
>
> [nit] s/independent on NLRI/independent of NLRI
>
>
>
> [major] "...for the purposes of BGP route propagation, this prefix should
> still be transmitted since BGP route distribution is independent on NLRI
> semantics."  I think this is a vulnerability: a (large) set of meaningles=
s
> Flow Specifications may be injected in the routing system...
>
>
>
> [major] Also, propagating these unknown components may result in a router
> down the line, which understands them, reacting.  While the reaction
> shouldn't result in reset adjacencies, it may result in inconsistent
> forwarding or other unexpected outcomes...
>
>
>
> [major] This treatment of unknown extensions is in conflict with the text
> in =C2=A711.  See my comments there.
>
>
>
>
>
> 353       4.2.1.  Type 1 - Destination Prefix
>
>
>
> 355            Encoding: <type (1 octet), prefix length (1 octet), prefix=
>
>
>
>
> 357            Defines: the destination prefix to match.  Prefixes are
> encoded as
>
> 358            in BGP UPDATE messages, a length in bits is followed by
> enough
>
> 359            octets to contain the prefix information.
>
>
>
> [nit] s/Defines: the destination prefix/Defines the destination prefix
>
>
>
> [major] rfc4271: "The Prefix field contains an IP address prefix, followe=
d
> by the minimum number of trailing bits needed to make the end of the fiel=
d
> fall on an octet boundary."   The text above makes it sound as if the
> prefix field may not end in an octet boundary, which is what rfc4271
> specifies.
>
>
>
> NEW (suggestion)>
>
>    Defines the destination prefix to match.  The length and prefix fields
> are
>
>    encoded as in BGP UPDATE messages [rfc4271].
>
>
>
>
>
> 361       4.2.2.  Type 2 - Source Prefix
>
>
>
> 363            Encoding: <type (1 octet), prefix-length (1 octet), prefix=
>
>
>
>
> 365            Defines the source prefix to match.
>
>
>
> [minor] "... The length and prefix fields are encoded as in BGP UPDATE
> messages [rfc4271]."
>
>
>
>
>
> 367       4.2.3.  Type 3 - IP Protocol
>
>
>
> 369            Encoding:<type (1 octet), [op, value]+>
>
>
>
> 371            Contains a set of {operator, value} pairs that are used to
> match
>
> 372            the IP protocol value byte in IP packets.
>
>
>
> [minor] Include a reference to the protocol numbers.
>
>
>
> [major] Are all protocol numbers valid?  I guess that in theory anything
> is -- what should a receiver do with Flow Specifications that cover
> protocols that are not supported?  I'm wondering if sending Flow
> Specifications for every protocol under the sun is a vulnerability --
> knowing that only a few will ever be present in the Internet.  Is there a=
ny
> guidance that you can provide in =C2=A714 (or a separate Operational
> Considerations section)?  I also point this out because the rest of the
> types focus on TCP/UDP...what about other transport layer protocols?
>
>
>
> [major] Related question: even for "valid" protocols, should all be
> accepted from eBGP peers?  I think that it is probably ok...asking for
> completeness.
>
>
>
> 374            The operator byte is encoded as:
>
>
>
> 376           0   1   2   3   4   5   6   7
>
> 377         +---+---+---+---+---+---+---+---+
>
> 378         | e | a |  len  | 0 |lt |gt |eq |
>
> 379         +---+---+---+---+---+---+---+---+
>
>
>
> 381              Numeric operator
>
>
>
> [nit] Center the figure...
>
>
>
> [clarity] Please describe the operators independent of one of the Types.
> As defined, it looks like they only apply to one type...it is much later
> that the reader realizes that there is a reason for the "complexity".
> Along the same lines, I think that the "set of {operator, value} pairs"
> phrase could use some more text to explain that the operator is the whole
> octet, with a corresponding value...
>
>
>
> 383            e - end-of-list bit.  Set in the last {op, value} pair in
> the
>
> 384            list.
>
>
>
> [major] What action should be taken if a received flow spec has this bit
> not set anywhere, or is set somewhere other than the last pair?
>
>
>
> 386            a - AND bit.  If unset, the previous term is logically
> ORed with
>
> 387            the current one.  If set, the operation is a logical AND.
> In the
>
> 388            first operator byte of a sequence it SHOULD be encoded as
> unset
>
> 389            and and MUST be treated as always unset on decoding.  The
> AND
>
> 390            operator has higher priority than OR for the purposes of
>
> 391            evaluating logical expressions.
>
>
>
> 393            len - length of the value field for this operator given as
> (1 <<
>
> 394            len).  This encodes 1 (00) - 8 (11) bytes.  Type 3 flow
> component
>
> 395            values SHOULD be encoded as single byte (len =3D 00).
>
>
>
> [major] Please expand on the meaning of "1 << len".
>
>
>
>
>
> ...
>
> 406         The bits lt, gt, and eq can be combined to produce common
> relational
>
> 407         operators such as "less or equal", "greater or equal", and
> "not equal
>
> 408         to".
>
>
>
> [minor] "...as shown in Table 1."
>
>
>
> 410                  +----+----+----+----------------------------------+
>
> 411                  | lt | gt | eq | Resulting operation              |
>
> 412                  +----+----+----+----------------------------------+
>
> 413                  | 0  | 0  | 0  | false (independent of the value) |
>
> 414                  | 0  | 0  | 1  | =3D=3D (equal)                     =
  |
>
> 415                  | 0  | 1  | 0  | > (greater than)                 |
>
> 416                  | 0  | 1  | 1  | >=3D (greater than or equal)       =
|
>
> 417                  | 1  | 0  | 0  | < (less than)                    |
>
> 418                  | 1  | 0  | 1  | <=3D (less than or equal)          =
|
>
> 419                  | 1  | 1  | 0  | !=3D (not equal value)             =
|
>
> 420                  | 1  | 1  | 1  | true (independent of the value)  |
>
> 421                  +----+----+----+----------------------------------+
>
>
>
> 423                      Table 1: Comparison operation combinations
>
>
>
> 425       4.2.4.  Type 4 - Port
>
>
>
> 427            Encoding:<type (1 octet), [op, value]+>
>
>
>
> 429            Defines a list of {operator, value} pairs that matches
> source OR
>
> 430            destination TCP/UDP ports.  This list is encoded using the
> numeric
>
> 431            operator format defined in Section 4.2.3.  Values SHOULD b=
e
>
> 432            encoded as 1- or 2-byte quantities.
>
>
>
> [minor] A reference to TCP/UDP header/ports would be nice.
>
>
>
> [major] "matches source OR destination TCP/UDP ports"  Which one?  Both?
> Either?  How does the receiver know which one?
>
>
>
> [minor] What is the interaction/relationship between this type and Types =
5
> and 6?  The text in =C2=A74.2 allows for all 3 types to be present, and h=
ave an
> influence in the action taken...they seem redundant.
>
>
>
>
>
> 434            Port, source port, and destination port components
> evaluate to
>
> 435            FALSE if the IP protocol field of the packet has a value
> other
>
> 436            than TCP or UDP, if the packet is fragmented and this is
> not the
>
> 437            first fragment, or if the system in unable to locate the
> transport
>
> 438            header.  Different implementations may or may not be able
> to
>
> 439            decode the transport header in the presence of IP options
> or
>
> 440            Encapsulating Security Payload (ESP) NULL [RFC4303]
> encryption.
>
>
>
> [minor] "Port, source port, and destination port components..."  This
> section only talks about the port; please duplicate this text in the othe=
r
> sections, or put a reference to it there, or put a forward reference here=
...
>
>
>
> [major] "...evaluate to FALSE if the IP protocol field of the packet has =
a
> value other than TCP or UDP, if the packet is fragmented and this is not
> the first fragment, or if the system in unable to locate the transport
> header."  This sentence seems to mix the applicability of the Flow
> Specification (FALSE is first introduced in =C2=A74.2 to describe the eff=
ect of
> a component on the rule), and the application to a specific packet.  Plea=
se
> separate the two aspects. I do have some specific questions/comments.
>
>
>
> (1) The text starts by talking about the "protocol field of the packet"
> (not the protocol value in the Type 3 parameter)...  I assume that a Flow
> Specification would only apply to a packet if the protocol matches the Ty=
pe
> 3 parameter...but the statement seems to say that it wouldn't apply
> regardless of the Type 3 (see my question there about valid protocols)...=
or
> maybe even if a Type 3 is not present...
>
>
>
> (2) "...evaluate to FALSE...if the packet is fragmented and this is not
> the first fragment..."  Type 12 specifically includes values for other
> cases.  How is the interaction expected?
>
>
>
>
>
> ...
>
> 460       4.2.7.  Type 7 - ICMP type
>
>
>
> 462            Encoding:<type (1 octet), [op, value]+>
>
>
>
> 464            Defines a list of {operator, value} pairs used to match
> the type
>
> 465            field of an ICMP packet.  This list is encoded using the
> numeric
>
> 466            operator format defined in Section 4.2.3.  Values SHOULD b=
e
>
> 467            encoded using a single byte.
>
>
>
> [minor] A reference to ICMP would be nice.
>
>
>
> 469            The ICMP type specifiers evaluate to FALSE whenever the
> protocol
>
> 470            value is not ICMP.
>
>
>
> 472       4.2.8.  Type 8 - ICMP code
>
>
>
> 474            Encoding:<type (1 octet), [op, value]+>
>
>
>
> 476            Defines a list of {operator, value} pairs used to match
> the code
>
> 477            field of an ICMP packet.  This list is encoded using the
> numeric
>
> 478            operator format defined in Section 4.2.3.  Values SHOULD b=
e
>
> 479            encoded using a single byte.
>
>
>
> 481            The ICMP code specifiers evaluate to FALSE whenever the
> protocol
>
> 482            value is not ICMP.
>
>
>
> [minor] I guess that it should also evaluate FALSE if the ICMP code is no=
t
> relevant for the Type.  ??
>
>
>
> 484       4.2.9.  Type 9 - TCP flags
>
>
>
> 486            Encoding:<type (1 octet), [op, bitmask]+>
>
>
>
> [minor] The operator (described below) is called "bitmask", which is a
> little confusing with the bitmask itself...
>
>
>
> 488            Bitmask values can be encoded as a 1- or 2-byte bitmask.
> When a
>
> 489            single byte is specified, it matches byte 13 of the TCP
> header
>
> 490            [RFC0793], which contains bits 8 though 15 of the 4th
> 32-bit word.
>
> 491            When a 2-byte encoding is used, it matches bytes 12 and 13
> of the
>
> 492            TCP header with the data offset field having a "don't
> care" value.
>
>
>
> [minor] Identifying the right octets is more important than counting the
> number of bytes...  The interesting bytes are identified above as "bytes =
12
> and 13"; however, work from the Transport Area talks about "bytes 13 and
> 14": https://tools.ietf.org/html/rfc3168#section-6.1  It would be nice if
> this was aligned or if any ambiguity could be avoided.
>
>
>
> [minor] "...with the data offset field having a "don't care" value."  Wha=
t
> does that mean?  To me, it sounds as if the bitmask values can't be used =
to
> match on the offset...is that the right interpretation?  Some clarity wou=
ld
> avoid guessing.
>
>
>
> 494            This component evaluates to FALSE for packets that are not
> TCP
>
> 495            packets.
>
>
>
> [major] As mentioned before, this sentence also seems to mix/confuse the
> applicability of the component (whether it can be used at all) and the
> application of it to match a specific packet.  In this case, the text see=
ms
> to simply say that a Flow Specification which uses Type 9 can only be use=
d
> to match TCP packets...
>
>
>
> [major] Should the Flow Specification evaluate to FALSE if this Type is
> used *and* Type 3 doesn't include TCP *only* in it's description?
>
>
>
> 497            This type uses the bitmask operator format, which differs
> from the
>
> 498            numeric operator format in the lower nibble.
>
>
>
> [minor] As with the numeric operator, I think it would be clearer if it
> was introduced before the types.
>
>
>
> 500          0   1   2   3   4   5   6   7
>
> 501         +---+---+---+---+---+---+---+---+
>
> 502         | e | a |  len  | 0 | 0 |not| m |
>
> 503         +---+---+---+---+---+---+---+---+
>
>
>
> 505            Bitmask operator
>
>
>
> [nit] Center the figure...
>
>
>
> 507         e, a, len - Most significant nibble:  (end-of-list bit, AND
> bit, and
>
> 508            length field), as defined for in the numeric operator
> format in
>
> 509            Section 4.2.3.
>
>
>
> [] See the questions about the e bit above.
>
>
>
>
>
> ...
>
> 542       4.2.12.  Type 12 - Fragment
>
>
>
> 544            Encoding:<type (1 octet), [op, bitmask]+>
>
>
>
> 546            Uses bitmask operator format defined in Section 4.2.9.
>
>
>
> [major] No, it doesn't.  The new one is defined below.
>
>
>
> [clarity] Again, please introduce the operators before the types.  In thi=
s
> case, this operator seems to also carry the bitmask name, which can be
> confusing with the one introduced in =C2=A74.2.9 and the name of the valu=
e
> field...
>
>
>
> 548            0   1   2   3   4   5   6   7
>
> 549          +---+---+---+---+---+---+---+---+
>
> 550          | 0 | 0 | 0 | 0 |LF |FF |IsF|DF |
>
> 551          +---+---+---+---+---+---+---+---+
>
>
>
> [nit] Center the figure...
>
>
>
> [nit] Please add Figure numbers.
>
>
>
> 553            Bitmask values:
>
>
>
> 555               Bit 7 - Don't fragment (DF)
>
>
>
> 557               Bit 6 - Is a fragment (IsF)
>
>
>
> 559               Bit 5 - First fragment (FF)
>
>
>
> 561               Bit 4 - Last fragment (LF)
>
>
>
> 563               Bit 0-3 - SHOULD be set to 0 on NLRI encoding, and MUST
> be
>
> 564               ignored during decoding
>
>
>
> [major] The operation is not specified.  Is this also an
> (operator,bitmask) pair, or just 8 bits indicating the values?  Can
> multiple bits be set at the same time?  What fields in the IP header do
> these map to?
>
>
>
> 566       4.3.  Examples of Encodings
>
>
>
> 568         An example of a Flow Specification encoding for: "all packets
> to
>
> 569         10.0.1/24 and TCP port 25".
>
>
>
> [nit] For clarity, include the whole subnet: s/ 10.0.1/24 / 10.0.1.0/24
>
>
>
> [major] Use IP addresses from the documentation pool [rfc5737] in all
> examples.
>
>
>
> 571            +------------------+----------+----------+
>
> 572            | destination      | proto    | port     |
>
> 573            +------------------+----------+----------+
>
> 574            | 0x01 18 0a 00 01 | 03 81 06 | 04 81 19 |
>
> 575            +------------------+----------+----------+
>
>
>
> [minor] It would be nice if the examples show the the whole Flow-spec
> NLRI, and not just the NLRI value.  Also, it would be great if one of the
> examples required more than 240 bytes.
>
>
>
> 577         Decode for protocol:
>
>
>
> [minor] Please show the decodes for all the fields.
>
>
>
> 579            +-------+----------+------------------------------+
>
> 580            | Value |          |                              |
>
> 581            +-------+----------+------------------------------+
>
> 582            |  0x03 | type     |                              |
>
> 583            |  0x81 | operator | end-of-list, value size=3D1, =3D |
>
> 584            |  0x06 | value    |                              |
>
> 585            +-------+----------+------------------------------+
>
>
>
> [minor] For completion, indicate that Protocol 6 is TCP.
>
>
>
> 587         An example of a Flow Specification encoding for: "all packets
> to
>
> 588         10.1.1/24 from 192/8 and port {range [137, 139] or 8080}".
>
>
>
> [] Ah...NETBIOS...
>
>
>
> [nit] It might be a good idea to number the examples...
>
>
>
>
>
> ...
>
> 612       5.  Traffic Filtering
>
>
>
> 614         Traffic filtering policies have been traditionally considered
> to be
>
> 615         relatively static.  Limitations of the static mechanisms
> caused this
>
> 616         mechanism to be designed for the three new applications of
> traffic
>
> 617         filtering (prevention of traffic-based, denial-of-service
> (DOS)
>
> 618         attacks, traffic filtering in the context of BGP/MPLS VPN
> service,
>
> 619         and centralized traffic control for SDN/NFV networks) require=
s
>
> 620         coordination among service providers and/or coordination
> among the AS
>
> 621         within a service provider.  Section 9 has details on the
> limitation
>
> 622         of previous mechanisms and why BGP Flow Specification
> provides a
>
> 623         solution for to prevent DOS and aid BGP/MPLS VPN filtering
> rules.
>
>
>
> [minor] This sentence, without the parenthesis, doesn't seem to make
> sense: "Limitations of the static mechanisms caused this mechanism to be
> designed for the three new applications of traffic filtering requires
> coordination among service providers and/or coordination among the AS
> within a service provider."
>
>
>
> [nit] s/solution for to prevent/solution to prevent
>
>
>
> 625         This Flow Specification NLRI defined above to convey
> information
>
> 626         about traffic filtering rules for traffic that should be
> discarded or
>
> 627         handled in manner specified by a set of pre-defined actions
> (which
>
> 628         are defined in BGP Extended Communities).  This mechanism is
>
> 629         primarily designed to allow an upstream autonomous system to
> perform
>
> 630         inbound filtering in their ingress routers of traffic that a
> given
>
> 631         downstream AS wishes to drop.
>
>
>
> [nit] s/This Flow Specification NLRI/The Flow Specification NLRI
>
>
>
>
>
> ...
>
> 645         Distribution of the IPv4 Flow Specification is described in
>
> 646         Section 6, and distibution of BGP/MPLS traffic Flow
> Specification is
>
> 647         described in Section 8.  The traffic filtering actions are
> described
>
> 648         in Section 7.
>
>
>
> [minor] Section 6 talks about validation, not distribution.
>
>
>
> [nit] s/distibution/distribution
>
>
>
>
>
> 650       5.1.  Ordering of Traffic Filtering Rules
>
>
>
> 652         With traffic filtering rules, more than one rule may match a
>
> 653         particular traffic flow.  Thus, it is necessary to define the
> order
>
> 654         at which rules get matched and applied to a particular
> traffic flow.
>
> 655         This ordering function must be such that it must not depend
> on the
>
> 656         arrival order of the Flow Specification's rules and must be
>
> 657         consistent in the network.
>
>
>
> [clarification] Are "traffic filtering rules" the same thing as "traffic
> filtering actions", or are they more like "Flow Specification's rules"?
> You also mention (below) "Flow Specification rules" in the context of
> ordering, so my guess is that "traffic filtering rules" and "Flow
> Specification rules" are equivalent...are they?   In my opinion, there ar=
e
> too many ways to refer to the same, or very similar things.  Please take
> advantage of =C2=A72 to help the reader, or at least simplify the termino=
logy.
>
>
>
> 659         The relative order of two Flow Specification rules is
> determined by
>
> 660         comparing their respective components.  The algorithm starts
> by
>
> 661         comparing the left-most components of the rules.  If the type=
s
>
> 662         differ, the rule with lowest numeric type value has higher
> precedence
>
> 663         (and thus will match before) than the rule that doesn't
> contain that
>
> 664         component type.  If the component types are the same, then a
> type-
>
> 665         specific comparison is performed (see below) if the types are
> equal
>
> 666         the algorithm continues with the next component.
>
>
>
> [minor] To be clear: the comparison is done between the component types
> defined in =C2=A74.2...and "left-most" means "first"...
>
>
>
> 668         For IP prefix values (IP destination or source prefix): If th=
e
>
> 669         prefixes overlap, the one with the longer prefix-length has
> higher
>
> 670         precedence.  If they do not overlap the one with the lowest
> IP value
>
> 671         has higher precedence.
>
>
>
> [minor] I need you to be more specific when talking about "overlap".
> Clearly 10.1.0.0/16 and 10.1.1.0/24 overlap, then the higher precedence
> would be for the /24, right?  Do 130.0.0.0/16 and 150.1.1.0/24 overlap
> (they have the first 3 bits in common)?  rfc5575 talks about a "common
> prefix", which is not completely clear either, but it could mean at least
> what is covered by the shortest mask (which would be my guess)...
>
>
>
> [minor] "prefix-length" is used here, but "prefix length" is used in
> =C2=A74.2.1.  Please be consistent.
>
>
>
> [minor] The "-" confused me a little.  By "For IP prefix values...the
> longer prefix-length" do you mean the value of the prefix length, or the
> length of the prefix field?  rfc5575 talks about "more specific", which m=
ay
> be easier to understand in this case...
>
>
>
> 673         For all other component types, unless otherwise specified, th=
e
>
> 674         comparison is performed by comparing the component data as a
> binary
>
> 675         string using the memcmp() function as defined by the ISO C
> standard.
>
> 676         For strings with equal lengths the lowest string (memcmp) has
> higher
>
> 677         precedence.  For strings of different lengths, the common
> prefix is
>
> 678         compared.  If the common prefix is not equal the string with
> the
>
> 679         lowest prefix has higher precedence.  If the common prefix is
> equal,
>
> 680         the longest string is considered to have higher precedence
> than the
>
> 681         shorter one.
>
>
>
> [major] Please add a Normative reference for "the memcmp() function as
> defined by the ISO C standard".
>
>
>
> [minor] What is the "common prefix"?  Is it the bits that correspond to
> the shorter length?  In this case I think that using "prefix" may be
> confusing.
>
>
>
> [minor] If my interpretation is correct, given a common set of rules, the
> longer the Flow Specification the most preferred, right?  Using one of th=
e
> examples in =C2=A74.3, "all packets to 10.1.1/24 from 192/8 and port {ran=
ge
> [137, 139] or 8080}" would be preferred over "all packets to 10.1.1/24 fr=
om
> 192/8 and port range [137, 139]"...because when comparing the common pref=
ix
> for the port, the second rule would have the e bit set, resulting in a
> higher prefix, right?
>
>
>
> [major] I would like to see some discussion about the management of Flow
> Specifications and their advertisement order from an operational point of
> view.  In the case above, if an operator uses the first rule (only), but
> later decides to allow web traffic and the system advertises the second
> rule, it won't take effect until the first one is withdrawn.  This type o=
f
> operational consideration is not explained in this document.
>
>
>
> 683         The code below shows a Python3 implementation of the
> comparison
>
> 684         algorithm.  The full code was tested with Python 3.6.3 and
> can be
>
> 685         obtained at https://github.com/stoffi92/flowspec-cmp [1].
>
>
>
> [minor] I would prefer to see the code in an Appendix.
>
>
>
> [major] We need to include template text about the licensing in the Code
> Component below.  Please take a look at the IETF Trust Legal Provisions a=
nd
> add the appropriate text:
> https://trustee.ietf.org/license-info/IETF-TLP-5.pdf
>
>
>
> 687         <CODE BEGINS>
>
> 688         import itertools
>
> 689         import ipaddress
>
>
>
> 691         def flow_rule_cmp(a, b):
>
> 692             for comp_a, comp_b in itertools.zip_longest(a.components,
>
> 693                                                    b.components):
>
> 694                 # If a component type does not exist in one rule
>
> 695                 # this rule has lower precedence
>
> 696                 if not comp_a:
>
> 697                     return B_HAS_PRECEDENCE
>
> 698                 if not comp_b:
>
> 699                     return A_HAS_PRECEDENCE
>
>
>
> [] What if the component is not in either?  The lines above look like the
> wrong outcome could be obtained.  Disclaimer: I don't know Python...
>
>
>
>
>
> ...
>
> 742       6.  Validation Procedure
>
> ...
>
> 757         The concept can be extended, in the case of Flow
> Specification NLRI,
>
> 758         to allow other validation procedures.
>
>
>
> [nit] s/of Flow Specification NLRI/of the Flow Specification NLRI
>
>
>
> 760         A Flow Specification NLRI must be validated such that it is
>
> 761         considered feasible if and only if all of the below is true:
>
>
>
> [major] There is no Normative language above, but I think there is a
> contradiction of sorts with the new text below ("Rule a) MAY be
> relaxed...").  The introductory text to the rules is "must be...considere=
d
> feasible if and only if all of the below is true", which sounds very stri=
ct
> and specific...but then the Normative exception comes in ("MAY be
> relaxed...rules b) and c)...MUST be disregarded") saying that it doesn't
> matter.  Please reword...perhaps something like: "If a destination is
> present...a Flow Specification MUST be validated this way...otherwise..."
>
>
>
> 763            a) A destination prefix component is embedded in the Flow
>
> 764            Specification.
>
>
>
> 766            b) The originator of the Flow Specification matches the
> originator
>
> 767            of the best-match unicast route for the destination prefix
>
> 768            embedded in the Flow Specification.
>
>
>
> [major] What is the "best-match unicast route"?  Please be specific.
>
>
>
> 770            c) There are no more specific unicast routes, when
> compared with
>
> 771            the flow destination prefix, that has been received from a
>
> 772            different neighboring AS than the best-match unicast
> route, which
>
> 773            has been determined in rule b).
>
>
>
> 775         Rule a) MAY be relaxed by configuration, permitting Flow
>
> 776         Specifications that include no destination prefix component.
> If such
>
> 777         is the case, rules b) and c) are moot and MUST be disregarded=
.
>
>
>
> [major] This action opens the door to all sorts of things.  I note that
> the Security Considerations section simply mentions it without going into
> more details.
>
>
>
> 779         By originator of a BGP route, we mean either the BGP
> originator path
>
> 780         attribute, as used by route reflection, or the transport
> address of
>
> 781         the BGP peer, if this path attribute is not present.
>
>
>
> [major] s/BGP originator path attribute, as used by route
> reflection/address of the originator in the ORIGINATOR_ID Attribute
> [RFC4456]   The reference to rfc4456 should be Normative.
>
>
>
> [minor] rfc4271 doesn't talk about a "transport addresses".  Instead, it
> talks about the "source IP address".  I know it is the same thing, but
> please be consistent.
>
>
>
> 783         BGP implementations MUST also enforce that the AS_PATH
> attribute of a
>
> 784         route received via the External Border Gateway Protocol (eBGP=
)
>
> 785         contains the neighboring AS in the left-most position of the
> AS_PATH
>
> 786         attribute.  While this rule is optional in the BGP
> specification, it
>
> 787         becomes necessary to enforce it for security reasons.
>
>
>
> [major] Is this requirement only for the Flow Specification AFI/SAFI
> pairs, or for all address families (IPv4 in the case of this document)?
> Why?
>
>
>
> [major] [Assuming that the answer to the last question is: "Yes, for all
> AFs"...] Should all the border routers in the AS enforce the first ASN, o=
r
> is the requirement only for routers receiving Flow Specifications?
>
>
>
> [major] In the case of receiving Flow Specifications from a neighbor in a=
n
> IXP, it may not be possible to enforce the rule above if a "transparent
> ASN" is being used.  Please include some text/guidance about that type of
> case.  Include it either here or in the Security Considerations.
>
>
>
> [nit] The mention of security above makes me want to see related
> considerations in =C2=A713/14.
>
>
>
> 789         The best-match unicast route may change over the time
> independently
>
> 790         of the Flow Specification NLRI.  Therefore, a revalidation of
> the
>
> 791         Flow Specification NLRI MUST be performed whenever unicast
> routes
>
> 792         change.  Revalidation is defined as retesting that clause a
> and
>
> 793         clause b above are true.
>
>
>
> [major] What about the case where a destination prefix is not included?
> Besides enforcing the first AS, there isn't any verification specified.
> What are the consideration about using that option?
>
>
>
> 795         Explanation:
>
>
>
> 797         The underlying concept is that the neighboring AS that
> advertises the
>
> 798         best unicast route for a destination is allowed to advertise
> flow-
>
> 799         spec information that conveys a more or equally specific
> destination
>
> 800         prefix.  Thus, as long as there are no more specific unicast
> routes,
>
> 801         received from a different neighboring AS, which would be
> affected by
>
> 802         that filtering rule.
>
>
>
> 804         The neighboring AS is the immediate destination of the traffi=
c
>
> 805         described by the Flow Specification.  If it requests these
> flows to
>
> 806         be dropped, that request can be honored without concern that
> it
>
> 807         represents a denial of service in itself.  Supposedly, the
> traffic is
>
> 808         being dropped by the downstream autonomous system, and there
> is no
>
> 809         added value in carrying the traffic to it.
>
>
>
> [major] A rogue router may request the traffic to be dropped.  While the
> local AS is simply reacting to the neighbor's request, the action can sti=
ll
> result in a DoS.  I would like to see rogue router scenarios reflected in
> the Security Considerations.
>
>
>
> [major] All this section seems to assume that flows are controlled
> (dropped/redirected) between ASes...but the actions can also be triggered
> from inside an AS.  What are the considerations in that case?  Why isn't
> iBGP explicitly considered?
>
>
>
>
>
> 811       7.  Traffic Filtering Actions
>
> ...
>
> 820         Implementations SHOULD provide mechanisms that map an
> arbitrary BGP
>
> 821         community value (normal or extended) to filtering actions tha=
t
>
> 822         require different mappings in different systems in the
> network.  For
>
> 823         instance, providing packets with a worse-than-best-effort,
> per-hop
>
> 824         behavior is a functionality that is likely to be implemented
>
> 825         differently in different systems and for which no standard
> behavior
>
> 826         is currently known.  Rather than attempting to define it
> here, this
>
> 827         can be accomplished by mapping a user-defined community value
> to
>
> 828         platform-/network-specific behavior via user configuration.
>
>
>
> [major] While this paragraph sounds technically correct, I think it
> doesn't belong in this document because it (randomly) talks about a
> different, yet tangentially related, topic.  Also, it basically says
> "SHOULD provide a mechanism to take arbitrary actions...which are not
> defined here", so it is not complete from a Normative point of view.  I
> would prefer if we took this paragraph out.
>
>
>
> 830         The default action for a traffic filtering Flow Specification
> is to
>
> 831         accept IP traffic that matches that particular rule.
>
>
>
> 833         This document defines the following extended communities
> values shown
>
> 834         in Table 2 in the form 0x8xnn where nn indicates the sub-type=
.
>
> 835         Encodings for these extended communities are described below.
>
>
>
> [minor] The "0x8xnn" format doesn't explain what x indicates.  Perhaps it
> would be better for the format to match the IANA section and include, for
> example, 0xttss for type and sub-type...with the corresponding change in
> Table 2.
>
>
>
> 837
> +-----------+----------------------+--------------------------------+
>
> 838         | community | action               | encoding
>       |
>
> 839
> +-----------+----------------------+--------------------------------+
>
> 840         | 0x8006    | traffic-rate-bytes   | 2-byte ASN, 4-byte float
>       |
>
> 841         | TBD       | traffic-rate-packets | 2-byte ASN, 4-byte float
>       |
>
> 842         | 0x8007    | traffic-action       | bitmask
>        |
>
> 843         | 0x8008    | rt-redirect AS-2byte | 2-octet AS, 4-octet
> value      |
>
> 844         | 0x8108    | rt-redirect IPv4     | 4-octet IPv4 addres,
> 2-octet   |
>
> 845         |           |                      | value
>        |
>
> 846         | 0x8208    | rt-redirect AS-4byte | 4-octet AS, 2-octet
> value      |
>
> 847         | 0x8009    | traffic-marking      | DSCP value
>       |
>
> 848
> +-----------+----------------------+--------------------------------+
>
>
>
> 850                     Table 2: Traffic Action Extended Communities
>
>
>
> [minor] The Table contains terms that have not been defined...  It would
> be ideal if the Table contained a forward reference to the section where
> each action is discussed....or at least a general statement about the
> details in the upcoming sub-sections...
>
>
>
> 852         Some traffic action communities may interfere with each other=
.
>
> 853         Section 7.6 of this specification provides general
> considerations on
>
> 854         such traffic action interference.  Any additional definition
> of a
>
> 855         traffic actions specified by additional standards documents
> or vendor
>
> 856         documents MUST specify if the traffic action interacts with a=
n
>
> 857         existing traffic actions, and provide error handling per
> [RFC7606].
>
>
>
> [nit] s/definition of a traffic actions/definition of traffic actions
>
>
>
> [major] "Any additional definition of a traffic actions specified by
> additional standards documents or vendor documents MUST specify..."  We
> really can't mandate what vendor documents say.   s/additional definition
> of a traffic actions specified by additional standards documents or vendo=
r
> documents MUST specify/additional definition of a traffic action MUST
> specify
>
>
>
> [major] "MUST specify if the traffic action interacts with an existing
> traffic actions"  I think you meant something like: "MUST specify the
> action to take if..."
>
>
>
> [major] "Any additional definition of a traffic actions...MUST...provide
> error handling per [RFC7606]."  rfc7606 already indicates what to do abou=
t
> a malformed Extended Community attribute, which is how other actions woul=
d
> presumably be specified.   rfc7606 only mandates error specifications for
> new attributes.  What are your expectations here?
>
>
>
> 859         Multiple traffic actions may be present for a single NLRI.
> The
>
> 860         traffic actions are processed in ascending order of the
> sub-type
>
> 861         found in the BGP Extended Communities.  If not all of them
> can be
>
> 862         processed the filter SHALL NOT be applied at all (for
> example: if for
>
> 863         a given flow there are the action communities
> rate-limit-bytes and
>
> 864         traffic-marking attached, and the plattform does not support
> one of
>
> 865         them also the other shall not be applied for that flow).
>
>
>
> [minor] This paragraph is related to =C2=A77.6 (Considerations on Traffic
> Action Interference).  Consider putting all the related information
> together.
>
>
>
> [major] "traffic actions are processed in ascending order of the sub-type=
"
>  Several of the communities have the same sub-type; if more than one is
> present, which one should be processed first?
>
>
>
> [major] What should a receiver do if multiple of the same community (type
> and sub-type) are included in the UPDATE?  Would that be also considered
> interference?
>
>
>
> [major] What does "processed" mean?  Let me explain... The example is
> about not being able to support an action.  What about not being able to
> apply the action because, for example, the next hop is not reachable?
> Would that qualify as not being able to "process" the action?  If other
> redirect traffic rules are included (with perhaps an alternate next hop),
> would the answer be different?
>
>
>
> [nit] Make the example a sentence on it's own: eliminate the parenthesis.
>
>
>
> [minor] s/rate-limit-bytes/traffic-rate-bytes (0x8006)
>
>
>
> [minor] s/traffic-marking/traffic-marking (0x8009)
>
>
>
> [nit] s/plattform/platform
>
>
>
> [major] "If not all of them can be processed the filter SHALL NOT be
> applied..."  Should they be forwarded?  Is this an example of "interferin=
g
> flow actions" (=C2=A77.6)?
>
>
>
> 867         All traffic actions are specified as transitive BGP Extended
>
> 868         Communities.
>
>
>
> 870       7.1.  Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06
>
> ...
>
> 888         Interferes with: No other BGP Flow Specification traffic
> action in
>
> 889         this document.
>
>
>
> [minor] The definition of interference (=C2=A77.6) uses "more than one
> conflicting traffic-rate action" as part of it.  So it seems that
> traffic-rate-bytes and traffic-rate-packets may interfere with each other=
.
>
>
>
> 891       7.2.  Traffic Rate in Packets (traffic-rate-packets) sub-type
> TBD
>
>
>
> [major] Because the "traffic actions are processed in ascending order of
> the sub-type" (=C2=A77), what is the intent for this action?  How should =
IANA
> assign it?  I assume that the intent might be to process it instead of
> traffic-rate-bytes (assuming only one might be present)...  Please be cle=
ar
> in the instructions to IANA (in =C2=A712.3).  Note that Table 7 requests =
the
> assignment from the "Generic Transitive Experimental Use Extended Communi=
ty
> Sub-Types" registry, which seems to limit the assignment choices.  Having
> said all that, I would have assumed that this action would be a variation
> of the 0x06 sub-type, but with a different type...
>
>
>
>
>
> ...
>
> 901         Interferes with: No other BGP Flow Specification traffic
> action in
>
> 902         this document.
>
>
>
> [minor] The definition of interference (=C2=A77.6) uses "more than one
> conflicting traffic-rate action" as part of it.  So it seems that
> traffic-rate-bytes and traffic-rate-packets may interfere with each other=
.
>
>
>
> 904       7.3.  Traffic-action (traffic-action) sub-type 0x07
>
>
>
> 906         The traffic-action extended community consists of 6 bytes of
> which
>
> 907         only the 2 least significant bits of the 6th byte (from left
> to
>
> 908         right) are currently defined.
>
>
>
> 910              40  41  42  43  44  45  46  47
>
> 911             +---+---+---+---+---+---+---+---+
>
> 912             |        reserved       | S | T |
>
> 913             +---+---+---+---+---+---+---+---+
>
>
>
> [minor] s/reserved/Traffic Action Fields   It would be nice if the Figure
> showed that all the bits (not just the ones in the last octet) are part o=
f
> the same field.
>
>
>
> [nit] Please add a Figure number.
>
>
>
> 915         where S and T are defined as:
>
>
>
> 917         o  T: Terminal Action (bit 47): When this bit is set, the
> traffic
>
> 918            filtering engine will apply any subsequent filtering rules
> (as
>
> 919            defined by the ordering procedure).  If not set, the
> evaluation of
>
> 920            the traffic filter stops when this rule is applied.
>
>
>
> [minor] According to the processing order and the values from Table 2, no=
t
> setting the bit would effectively cause only the traffic-rate-bytes
> (0x8006) to ever be applied.  Is that the correct interpretation?
>
>
>
> [minor] If the T bit is not set, can a router drop the communities that
> are not going to be applied...or should they all be propagated?
>
>
>
> [major] Clearly, a rogue router could unset the bit before propagating...
>
>
>
> 922         o  S: Sample (bit 46): Enables traffic sampling and logging
> for this
>
> 923            Flow Specification.
>
>
>
> [major] If the bit is not set, would sampling/logging be disabled?  IOW,
> is this an on/off switch, or is just the on action valid?
>
>
>
> 925         o  reserved: should always be set to 0 by the originator and
> not be
>
> 926            evaluated by the receiving BGP speaker.
>
>
>
> [major] There is a registry for these bits.  s/reserved/Traffic Action
> Fields
>
>
>
>
>
> ...
>
> 934         Interferes with: No other BGP Flow Specification traffic
> action in
>
> 935         this document.
>
>
>
> [minor] Based on the definition in =C2=A77.6, I would have thought that t=
his
> action, with the T bit unset, would interfere with other actions that wil=
l
> now not be applied.
>
>
>
>
>
> 937       7.4.  RT Redirect (rt-redirect) sub-type 0x08
>
> ...
>
> 948         It should be noted that the low-order nibble of the
> Redirect's Type
>
> 949         field corresponds to the Route Target Extended Community
> format field
>
> 950         (Type).  (See Sections 3.1, 3.2, and 4 of [RFC4360] plus
> Section 2 of
>
> 951         [RFC5668].)  The low-order octet (Sub-Type) of the Redirect
> Extended
>
> 952         Community remains 0x08 for all three encodings of the BGP
> Extended
>
> 953         Communities (AS 2-byte, AS 4-byte, and IPv4 address).
>
>
>
> [nit] I think that this whole paragraph is not needed...and it actually
> may confuse people.  I recommend deleting it.
>
>
>
> 955         Interferes with: All other redirect functions.
>
>
>
> [minor] What other redirect functions?  The only ones defined are in this
> section.
>
>
>
>
>
> 957       7.5.  Traffic Marking (traffic-marking) sub-type 0x09
>
>
>
> 959         The traffic marking extended community instructs a system to
> modify
>
> 960         the DSCP bits of a transiting IP packet to the corresponding
> value.
>
> 961         This extended community is encoded as a sequence of 5 zero
> bytes
>
> 962         followed by the DSCP value encoded in the 6 least significant
> bits of
>
> 963         6th byte.
>
>
>
> [major] What action (if any) should a receiver take if the "5 zero bytes"
> are not (all) set to 0?  Maybe include something like: "MUST be ignored
> when received...".
>
>
>
> 965         Interferes with: No other BGP Flow Specification traffic
> action in
>
> 966         this document.
>
>
>
> 968       7.6.  Considerations on Traffic Action Interference
>
>
>
> 970         Since traffic actions are represented as BGP extended
> community
>
> 971         values, traffic actions may interfere with each other (ie.
> there may
>
> 972         be more than one conflicting traffic-rate action associated
> with a
>
> 973         single flow-filter).  Traffic action interference has no
> impact on
>
> 974         BGP propagation of flow filters (all communities are
> propagated
>
> 975         according to policies).
>
>
>
> [nit] s/ie./e.g.   I'm assuming it is an example and not the only case.
>
>
>
> [minor] Is "Traffic action interference" only the case when actions
> describe conflicting actions?  For example, different traffic rates.
> Specifically, are actions that can't be applied (as described on =C2=A77)=
, also
> considered as interference?
>
>
>
> 977         If a flow filter associated with interfering flow actions is
> selected
>
> 978         for packet forwarding, it is a implementation decision which
> of the
>
> 979         interfering traffic actions are selected.  Implementors of
> this
>
> 980         specification SHOULD document the behaviour of their
> implementation
>
> 981         in such cases.
>
>
>
> [major] IOW, deployment of a set of "interfering flow actions" could
> result in inconsistent behavior in the network.  Could a rogue BGP speake=
r
> advertise (or even add/delete) actions to a Flow Specification and cause
> unexpected results?  I guess that depending on what the action is, there
> could be a significant effect.  I think this is a vulnerability that shou=
ld
> be called out explicitly.  Thinking a little bit more...there are two
> vulnerabilities: (1) add/delete in the normal case (even with consistent
> behavior), and (2) add/delete to exploit a specific behavior of a node in
> the network.
>
>
>
> 983         If required, operators are encouraged to make use of the BGP
> policy
>
> 984         framework supported by their implementation in order to
> achieve a
>
> 985         predictable behaviour (ie. match - replace - delete
> communities on
>
> 986         administrative boundaries).
>
>
>
> [minor] "If required..."  When it is not required?  IOW, I think that
> those two words are not needed.
>
>
>
>
>
> 988       8.  Dissemination of Traffic Filtering in BGP/MPLS VPN Networks
>
>
>
> 990         Provider-based Layer 3 VPN networks, such as the ones using a
> BGP/
>
> 991         MPLS IP VPN [RFC4364] control plane, may have different
> traffic
>
> 992         filtering requirements than Internet service providers.  But
> also
>
> 993         Internet service providers may use those VPNs for scenarios
> like
>
> 994         having the Internet routing table in a VRF, resulting in the
> same
>
> 995         traffic filtering requirements as defined for the global
> routing
>
> 996         table environment within this document.  This document
> proposes an
>
> 997         additional BGP NLRI type (AFI=3D1, SAFI=3D134) value, which c=
an
> be used
>
> 998         to propagate traffic filtering information in a BGP/MPLS VPN
>
> 999         environment.
>
>
>
> [nit] s/proposes/defines (or maybe specifies)
>
>
>
> 1001       The NLRI format for this address family consists of a
> fixed-length
>
> 1002       Route Distinguisher field (8 bytes) followed by a Flow
> Specification,
>
> 1003       following the encoding defined above in Section 4.2 of this
> document.
>
> 1004       The NLRI length field shall include both the 8 bytes of the
> Route
>
> 1005       Distinguisher as well as the subsequent Flow Specification.
>
>
>
> [minor] s/Flow Specification, following the encoding defined above in
> Section 4.2 of this document./Flow Specification (Section 4.2).
>
>
>
>
>
> ...
>
> 1017       Propagation of this NLRI is controlled by matching Route Targe=
t
>
> 1018       extended communities associated with the BGP path
> advertisement with
>
> 1019       the VRF import policy, using the same mechanism as described
> in "BGP/
>
> 1020       MPLS IP VPNs" [RFC4364].
>
>
>
> [nit] s/"BGP/MPLS IP VPNs"/BGP/MPLS IP VPNs
>
>
>
> 1022       Flow Specification rules received via this NLRI apply only to
> traffic
>
> 1023       that belongs to the VRF(s) in which it is imported.  By
> default,
>
> 1024       traffic received from a remote PE is switched via an MPLS
> forwarding
>
> 1025       decision and is not subject to filtering.
>
>
>
> 1027       Contrary to the behavior specified for the non-VPN NLRI, flow
> rules
>
> 1028       are accepted by default, when received from remote PE routers.
>
>
>
> [major] The only other mention of "flow rule" is in the Introduction when
> referring to the validation of external Flow Specifications, which seems =
to
> then map to =C2=A76...but the next sub-section says that those procedures
> apply.  What am I missing?
>
>
>
>
>
> 1030     8.1.  Validation Procedures for BGP/MPLS VPNs
>
>
>
> 1032       The validation procedures are the same as for IPv4.
>
>
>
> 1034     8.2.  Traffic Actions Rules
>
>
>
> 1036       The traffic action rules are the same as for IPv4.
>
>
>
> [nit] These 2 sub-sections could simply be covered by a couple of
> sentences...
>
>
>
>
>
> 1038     9.  Limitations of Previous Traffic Filtering Efforts
>
>
>
> [major] This section reads like a justification...  I think it would be a
> better fit as a subsection of the Introduction.
>
>
>
> 1040     9.1.  Limitations in Previous DDoS Traffic Filtering Efforts
>
> ...
>
> 1052       Several techniques are currently used to control traffic
> filtering of
>
> 1053       DoS attacks.  Among those, one of the most common is to inject
>
> 1054       unicast route advertisements corresponding to a destination
> prefix
>
> 1055       being attacked (commonly known as remote triggered blackhole
> RTBH).
>
> 1056       One variant of this technique marks such route advertisements
> with a
>
> 1057       community that gets translated into a discard Next-Hop by the
>
> 1058       receiving router.  Other variants attract traffic to a
> particular
>
> 1059       node that serves as a deterministic drop point.
>
>
>
> [minor] Please add Informative references to rfc3882, rfc5635, rfc7999...
>
>
>
>
>
> ...
>
> 1103     10.  Traffic Monitoring
>
>
>
> 1105       Traffic filtering applications require monitoring and traffic
>
> 1106       statistics facilities.  While this is an
> implementation-specific
>
> 1107       choice, implementations SHOULD provide:
>
>
>
> 1109       o  A mechanism to log the packet header of filtered traffic.
>
>
>
> 1111       o  A mechanism to count the number of matches for a given flow
>
> 1112          specification rule.
>
>
>
> [minor] Is there any relationship between this section and the S bit in
> =C2=A77.3?
>
>
>
>
>
> 1114     11.  Error-Handling and Future NLRI Extensions
>
>
>
> [major] Suggestion: this section should be limited to describing what a
> malformed traffic action extended community is, and then simply point to
> rfc7606, which already covers the rest.  See more comments below.
>
>
>
> [nit] The two topics covered here seem unrelated...
>
>
>
> 1116       In case BGP encounters an error in a Flow Specification UPDATE
>
> 1117       message it SHOULD treat this message as Treat-as-withdraw
> according
>
> 1118       to [RFC7606] Section 2.
>
>
>
> [major] The SHOULD above with the communities-related errors described
> below are in conflict with rfc7606, which says this: "An UPDATE message
> with a malformed Extended Community attribute SHALL be handled using the
> approach of "treat-as-withdraw"."
>
>
>
> 1120       Possible reasons for an error are (for more reasons see also
>
> 1121       [RFC7606]):
>
>
>
> 1123       o  Incorrect implementation of this specification - the
> encoding/
>
> 1124          decoding of the NLRI or traffic action extended-communities
> do not
>
> 1125          comply with this specification.
>
>
>
> [major] Related to the NLRI, rfc7606 says that "in order to use the
> approach of "treat-as-withdraw", the entire NLRI field and/or the
> MP_REACH_NLRI and MP_UNREACH_NLRI attributes need to be successfully
> parsed...  If this is not possible...that the "session reset" approach (o=
r
> the "AFI/SAFI disable" approach) MUST be followed."
>
>
>
> [major] For the Extended Communities...  The "incorrect implementation"
> basically means that the encoding is wrong, right?  But is the part about
> "comply with this specification" necessary?  Other traffic action extende=
d
> communities (defined elsewhere) might be received.  I would rather if the
> text above talked about malformed (to match the language in rfc7606)
> traffic action extended communities in general (not just the ones in this
> specification).
>
>
>
> 1127       o  Unknown Flow Specification extensions - The sending party
> has
>
> 1128          implemented a Flow Specification NLRI extension unknown to
> the
>
> 1129          receiving party.
>
>
>
> [major] This treatment of unknown extensions is in conflict with the text
> in =C2=A74.2: "If a given component type within a prefix in unknown, the =
prefix
> in question cannot be used for traffic filtering purposes by the
> receiver... However, for the purposes of BGP route propagation, this pref=
ix
> should still be transmitted since BGP route distribution is independent o=
n
> NLRI semantics."  IOW, "treat-as-withdraw" is not compatible with
> forwarding UPDATES.
>
>
>
> 1131       In order to facilitate future extensions of the Flow
> Specification
>
> 1132       NLRI, such extensions SHOULD specify a way to encode a
> "always-true"
>
> 1133       match condition within the newly introduced components.  This
> match
>
> 1134       condition can be used to propagate (and apply) certain filters
> only
>
> 1135       if a specific extension is known to the implemenation.
>
>
>
> [nit] s/a "always-true"/an "always-true"
>
>
>
> [minor] What does "always-true" mean?
>
>
>
> [major] How come this document doesn't follow the advice about the
> "always-true" match condition?
>
>
>
> [nit] s/implemenation/implementation
>
>
>
>
>
> ...
>
> 1141     12.1.  AFI/SAFI Definitions
>
>
>
> 1143       IANA maintains a registry entitled "SAFI Values".  For the
> purpose of
>
> 1144       this work, IANA updated the registry and allocated two
> additional
>
> 1145       SAFIs:
>
>
>
> [nit] Even though the text will probably end up as written, it doesn't as=
k
> IANA for anything: it assumes that the work is done.  I would prefer it i=
f
> the text was worded as a request.  It may not be an issue for IANA, so
> there's no need to change anything, unless they say so.
>
>
>
> 1147
> +-------+------------------------------------------+----------------+
>
> 1148       | Value | Name                                     | Reference
>      |
>
> 1149
> +-------+------------------------------------------+----------------+
>
> 1150       | 133   | IPv4 dissemination of Flow Specification | [this
>      |
>
> 1151       |       | rules                                    | document]
>      |
>
> 1152       | 134   | VPNv4 dissemination of Flow              | [this
>      |
>
> 1153       |       | Specification rules                      | document]
>      |
>
> 1154
> +-------+------------------------------------------+----------------+
>
>
>
> [major] It's not clear to me (because there's no explicit request) if the
> intent is to add this document as a reference, or to replace the one to
> rfc5575.  I would like you to be explicit.
>
>
>
> 1156                          Table 3: Registry: SAFI Values
>
>
>
> 1158     12.2.  Flow Component Definitions
>
> ...
>
> 1184       In order to manage the limited number space and accommodate
> several
>
> 1185       usages, the following policies defined by [RFC8126] used:
>
>
>
> [nit] s/[RFC8126] used/[RFC8126] are used
>
>
>
> 1187                 +--------------+-------------------------------+
>
> 1188                 | Range        | Policy                        |
>
> 1189                 +--------------+-------------------------------+
>
> 1190                 | 0            | Invalid value                 |
>
> 1191                 | [1 .. 12]    | Defined by this specification |
>
> 1192                 | [13 .. 127]  | Specification required        |
>
> 1193                 | [128 .. 255] | First Come First Served       |
>
> 1194                 +--------------+-------------------------------+
>
>
>
> [major] 0 is not really a range...and it's Invalid, so it shouldn't be
> part of the Table detailing the registration policies.  BTW, I couldn't
> find the text where 0 is declared Invalid -- please add some text to =C2=
=A74.2.
> Move 0 to Table 4.
>
>
>
> [minor] Besides the fact that "Defined by this specification" is not a
> Policy, this table doesn't change anything in the current registry; it is
> not needed.
>
>
>
> 1196                    Table 5: Flow Spec Component Types Policies
>
>
>
> 1198       The specification of a particular "Flow Spec Component Type"
> must
>
> 1199       clearly identify what the criteria used to match packets
> forwarded by
>
> 1200       the router is.  This criteria should be meaningful across
> router hops
>
> 1201       and not depend on values that change hop-by-hop such as TTL or
> Layer
>
> 1202       2 encapsulation.
>
>
>
> [minor] This paragraph doesn't belong in the IANA section.  It seems to b=
e
> laying out the groundwork for new components...so it belongs somewhere
> else.  Should any of the language be Normative?
>
>
>
>
>
> 1204     12.3.  Extended Community Flow Specification Actions
>
>
>
> 1206       The Extended Community Flow Specification Action types defined
> in
>
> 1207       this document consist of two parts:
>
>
>
> 1209          Type (BGP Transitive Extended Community Type)
>
>
>
> 1211          Sub-Type
>
>
>
> 1213       For the type-part, IANA maintains a registry entitled "BGP
> Transitive
>
> 1214       Extended Community Types".  For the purpose of this work
> (Section 7),
>
> 1215       IANA updated the registry to contain the values listed below:
>
>
>
> [major] The range is defined in the registry as "0x80-0x8f      Reserved
> for Experimental Use".  According to rfc8126, "IANA does not record
> assignments from registries or ranges with this policy".
>
>
>
> I don't know why 0x80 was the first value chosen; it looks like it was
> first used in draft-marques-idr-flow-spec-01 (2004), while the
> corresponding Extended Communities draft
> (draft-ietf-idr-bgp-ext-communities-07) already indicated that the range
> was for Experimental Use.  I guess just lack of sync...  But then I also
> don't understand how/why IANA ended up with the information in the
> Registry...maybe because the sub-types are not for Experimental Use --
> hmmm, which sounds contradictory to me.
>
>
>
> The reason/history doesn't matter anymore, but the current use does.  The
> mechanism described in this document is clearly not experimental.  Given
> that changing the Type values is not an option because of the deployed
> base, etc.., then I think we should clean up the Registry and move
> 0x80-0x82 from the Experimental Use range to the FCFS range.  This change
> would mean an Update to rfc7153.
>
>
>
> To simplify the process, the Update can be done in this document.
> However, I think that there's some confusion with these types apparently
> being associated only with Flow Specifications, when they are labeled as
> Generic.  IOW, ideally the issue would be corrected independently...
>
>
>
>
>
> 1217
> +-------+-----------------------------------------------+-----------+
>
> 1218       | Type  | Name                                          |
> Reference |
>
> 1219       | Value |                                               |
>       |
>
> 1220
> +-------+-----------------------------------------------+-----------+
>
> 1221       | 0x80  | Generic Transitive Experimental Use Extended  |
> [RFC7153] |
>
> 1222       |       | Community (Sub-Types are defined in the       |
>       |
>
> 1223       |       | "Generic Transitive Experimental Use Extended |
>       |
>
> 1224       |       | Community Sub-Types" registry)                |
>       |
>
> 1225       | 0x81  | Generic Transitive Experimental Use Extended  |
> [this     |
>
> 1226       |       | Community Part 2 (Sub-Types are defined in    |
> document] |
>
> 1227       |       | the "Generic Transitive Experimental Use      | [See
>      |
>
> 1228       |       | Extended Community Part 2 Sub-Types"          |
> Note-1]   |
>
> 1229       |       | Registry)                                     |
>       |
>
> 1230       | 0x82  | Generic Transitive Experimental Use Extended  |
> [this     |
>
> 1231       |       | Community Part 3 (Sub-Types are defined in    |
> document] |
>
> 1232       |       | the "Generic Transitive Experimental Use      | [See
>      |
>
> 1233       |       | Extended Community Part 3 Sub-Types"          |
> Note-1]   |
>
> 1234       |       | Registry)                                     |
>       |
>
> 1235
> +-------+-----------------------------------------------+-----------+
>
>
>
> 1237          Table 6: Registry: Generic Transitive Experimental Use
> Extended
>
> 1238                                  Community Types
>
>
>
> [major] In line with Updating the registry and the intent, the names of
> the Types/Registries should not include the word "experimental" to avoid
> any further confusion.
>
>
>
> 1240       Note-1: This document obsoletes RFC7674.
>
>
>
> [minor] Putting the reference to this note in the Table seems to be askin=
g
> IANA to add a note there too...which I would think is not the case.  This
> goes back to the intent of whether the reference to this document should
> replace what is there or simply be added.
>
>
>
>
>
> ...
>
> 1292       The "traffic-action" extended community (Section 7.3) defined
> in this
>
> 1293       document has 46 unused bits, which can be used to convey
> additional
>
> 1294       meaning.  IANA created and maintains a new registry entitled:
>
> 1295       "Traffic Action Fields".  These values should be assigned via
> IETF
>
> 1296       Review rules only.  The following traffic-action fields have
> been
>
> 1297       allocated:
>
>
>
> [major] It needs to be mentioned somewhere that the reference for the
> whole registry (not just the values below) should be moved to this docume=
nt.
>
>
>
>
>
> ...
>
> 1308     13.  Security Considerations
>
>
>
> 1310       Inter-provider routing is based on a web of trust.  Neighborin=
g
>
> 1311       autonomous systems are trusted to advertise valid reachability
>
> 1312       information.  If this trust model is violated, a neighboring
>
> 1313       autonomous system may cause a denial-of-service attack by
> advertising
>
> 1314       reachability information for a given prefix for which it does
> not
>
> 1315       provide service.
>
>
>
> [major] References to Origin Validation (rfc6811) and BGPSec (rfc8205)
> should be mentioned as possible mitigation...with maybe a comment about t=
he
> current deployment status.
>
>
>
> 1317       As long as traffic filtering rules are restricted to match the
>
> 1318       corresponding unicast routing paths for the relevant prefixes,
> the
>
> 1319       security characteristics of this proposal are equivalent to th=
e
>
> 1320       existing security properties of BGP unicast routing.  However,
> this
>
> 1321       document also specifies traffic filtering actions that may nee=
d
>
> 1322       custom additional verification on the receiver side.  See
> Section 14.
>
>
>
> [major] In general, Flow Specifications have a one-AS-hop propagation
> model, right?  This means that the security properties are different
> because (1) unicast routing propagates multiple hops, and (2) the intent =
of
> the "Route Origin ASN" (rfc6811) is not reflected in the request to
> rate-limit, or even drop (!) traffic to a destination.  Yes, it is all
> based on trust...but different.  For example, Origin Validation wouldn't =
be
> available for Flow Specifications.
>
>
>
> 1324       Where it is not the case, this would open the door to further
> denial-
>
> 1325       of-service attacks.
>
>
>
> [major] Like what?  What are possible mitigations?  Just saying that the
> door is open is not enough.
>
>
>
>
>
> ...
>
> 1337     14.  Operational Security Considerations
>
>
>
> [minor] If you ask me, this section should be rolled into the last one: I
> think all the considerations (in both sections) are really operational...
>
>
>
> 1339       While the general verification of the traffic filter NLRI is
>
> 1340       specified in this document (Section 6) the traffic filtering
> actions
>
> 1341       received by a third party may need custom verification or
> filtering.
>
> 1342       In particular all non traffic-rate actions may allow a third
> party to
>
> 1343       modify packet forwarding properties and potentially gain
> access to
>
> 1344       other routing-tables/VPNs or undesired queues.  This can be
> avoided
>
> 1345       by proper filtering of action communities at network borders
> and by
>
> 1346       mapping user-defined communities (see Section 7) to expose
> certain
>
> 1347       forwarding properties to third parties.
>
>
>
> [minor] I didn't get this last part...  I understand filtering, but didn'=
t
> quite understand how the mapping of communities would help.
>
>
>
> 1349       Since verfication of the traffic filtering NLRI is tied to the
>
> 1350       announcement of the best unicast route, a unfiltered address
> space
>
> 1351       hijack (e.g. advertisement of a more specific route) may cause
> this
>
> 1352       verification to fail and consequently prevent Flow
> Specification
>
> 1353       filters from being accepted by a peer.
>
>
>
> [nit] s/verfication/verification
>
>
>
> [nit] s/a unfiltered/an unfiltered
>
>
>
> [minor] Again, mention Origin Validation as possible mitigation.
>
>
>
> 1355     15.  Original authors
>
>
>
> 1357       Barry Greene, Pedro Marques, Jared Mauch, Danny McPherson, and
>
> 1358       Nischal Sheth were authors on RFC5575, and therefore are
> contributing
>
> 1359       authors on this document.
>
>
>
> [minor] To be in line with rfc7322, this section should be renamed to
> "Contributors".
>
>
>
>
>
> 1361     16.  Acknowledgements
>
> ...
>
> 1370       A packet rate flowspec action was also discribed in a flowspec
>
> 1371       extention draft and the authors like to thank Wesley Eddy,
> Justin
>
> 1372       Dailey and Gilbert Clark for their work.
>
>
>
> [nit] This is the first time that "flowspec" is used.  Not a bad
> thing...just an observation that we went through the whole document witho=
ut
> using the colloquial name flowspec.
>
>
>
> [nit] s/discribed/described
>
>
>
> [nit] s/extention/extension
>
>
>
> 1374       Additional the authors would like to thank Alexander Mayrhofer=
,
>
> 1375       Nicolas Fevrier, Job Snijders, Jeffrey Haas and Adam Chappell
> for
>
> 1376       their comments and review.
>
>
>
> [nit] s/Additional/Additionally,
>
>
>
>
>
> 1378     17.  References
>
>
>
> 1380     17.1.  Normative References
>
>
>
> 1382       [IEEE.754.1985]
>
> 1383                  IEEE, "Standard for Binary Floating-Point
> Arithmetic",
>
> 1384                  IEEE 754-1985, August 1985.
>
>
>
> [minor] IEEE has revised this spec twice, the most current revision was
> published earlier this year.  Should the reference to the 1985 version be
> kept?  Is there a reason not to point generically to IEEE 754, instead of
> to a specific version?
>
>
>
>
>
> ...
>
> 1419       [RFC5668]  Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS
>
> 1420                  Specific BGP Extended Community", RFC 5668,
>
> 1421                  DOI 10.17487/RFC5668, October 2009,
>
> 1422                  <https://www.rfc-editor.org/info/rfc5668>.
>
>
>
> [minor] I don't think this needs to be a Normative reference.
>
>
>
>
>
> ...
>
> 1458     Appendix A.  Comparison with RFC 5575
>
> ...
>
> 1464          Section 1 introduces the Flow Specification NLRI.  In
> RFC5575 this
>
> 1465          NLRI was defined as an opaque-key in BGPs database.  This
>
> 1466          specification has removed all references to a opaque-key
> property.
>
> 1467          BGP is able understand the NLRI encoding.  This change also
>
> 1468          resulted in a new section regarding error-handling and
>
> 1469          extensibility (Section 11).
>
>
>
> [nit] s/able understand/able to understand
>
>
>
>
>

--0000000000001548c805925a770f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Sue,<div><br></div><div>As WG participant I would like =
to point out that making all specs to support both v4 and v6 may be a bit s=
hort sighted.=C2=A0</div><div><br></div><div>At some=C2=A0point in the futu=
re (and in some cases already today for example access points and modems)=
=C2=A0 only IPv6 is supported - no IPv4. So if we continue to mandate that =
all specs must contain and support both address families it makes it very h=
ard to any modern equipment IPv6 only vendor to declare support for given R=
FC.=C2=A0</div><div><br></div><div>So IMO it is in best interest of any IET=
F spec to split IPv4 from IPv6 into different documents. The push to add IP=
v6 into all drafts/rfcs perhaps was a good move initially to a bit force IP=
v6 extensions, but I do not think it is good idea long term. Also note that=
 there are some solutions only proposed to be used over IPv6 networks.=C2=
=A0</div><div><br></div><div>So here specifically with IPv6 we are talking =
of completely different match criteria (IPv6 fixed and extension headers) h=
ave completely different format and functionality then IPv4, both use diffe=
rent AFI/SAFIs etc ... so here you would essentially artificially squeeze t=
wo documents into one. I am not sure if this=C2=A0</div><div><br></div><div=
>Thx,</div><div>R.</div><div><br></div><div><br></div><div><br></div><div><=
br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma=
il_attr">On Thu, Sep 12, 2019 at 12:38 PM Susan Hares &lt;<a href=3D"mailto=
:shares@ndzh.com">shares@ndzh.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div lang=3D"EN-US"><div class=3D"gmail-m_=
-2404559829259103405WordSection1"><p class=3D"MsoNormal"><span style=3D"fon=
t-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Alvaro: <u=
></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11pt=
;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u>=C2=A0<u></u><=
/span></p><p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:=
Calibri,sans-serif;color:rgb(31,73,125)">&lt;WG chair hat on&gt; <u></u><u>=
</u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-fa=
mily:Calibri,sans-serif;color:rgb(31,73,125)"><u></u>=C2=A0<u></u></span></=
p><p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:Calibri,=
sans-serif;color:rgb(31,73,125)">Question: <u></u><u></u></span></p><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif">I understand why this document only focuses on IPv4.=C2=A0 While the t=
ext points at draft-ietf-idr-flow-spec-v6, that draft has been expired for =
over a year!=C2=A0 What is the plan to move that work forward?=C2=A0 It loo=
ks like there may already be implementations in place [4].<u></u><u></u></s=
pan></p><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif"><u></u>=C2=A0<u></u></span></p><p class=3D"MsoNormal"><=
span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">Answer: <u><=
/u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:10pt;f=
ont-family:Helvetica,sans-serif">The direction from the WG was to limit the=
 draft to RFC5575 fixes.=C2=A0=C2=A0 <u></u><u></u></span></p><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">I=
f you feel strongly, this can be queried to the WG again. =C2=A0<u></u><u><=
/u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fam=
ily:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">&lt;WG=
 chair off&gt; <u></u><u></u></span></p><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">&lt;author hat on&gt; =
<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif">If WG agrees, this could be added to t=
he draft. <u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">&lt;/author hat off&gt; <u><=
/u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:10pt;f=
ont-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p><p class=3D=
"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"=
>Sue Hares <u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"f=
ont-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u>=
=C2=A0<u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11p=
t;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u>=C2=A0<u></u>=
</span></p><div><div style=3D"border-right:none;border-bottom:none;border-l=
eft:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0in 0in"><p clas=
s=3D"MsoNormal"><b><span style=3D"font-size:10pt;font-family:Tahoma,sans-se=
rif">From:</span></b><span style=3D"font-size:10pt;font-family:Tahoma,sans-=
serif"> Dongjie (Jimmy) [mailto:<a href=3D"mailto:jie.dong@huawei.com" targ=
et=3D"_blank">jie.dong@huawei.com</a>] <br><b>Sent:</b> Thursday, September=
 12, 2019 5:14 AM<br><b>To:</b> Alvaro Retana; <a href=3D"mailto:draft-ietf=
-idr-rfc5575bis@ietf.org" target=3D"_blank">draft-ietf-idr-rfc5575bis@ietf.=
org</a><br><b>Cc:</b> <a href=3D"mailto:idr-chairs@ietf.org" target=3D"_bla=
nk">idr-chairs@ietf.org</a>; idr@ietf. org<br><b>Subject:</b> RE: AD Review=
 of draft-ietf-idr-rfc5575bis-17<u></u><u></u></span></p></div></div><p cla=
ss=3D"MsoNormal"><u></u>=C2=A0<u></u></p><p class=3D"MsoNormal"><span style=
=3D"font-size:10.5pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">H=
i Alvaro, <u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10.5pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u>=
=C2=A0<u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:10.=
5pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Thanks pointing ou=
t the IPR issue with this -bis document. I will check the third-party discl=
osure procedure and file related disclosures later today.<u></u><u></u></sp=
an></p><p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:C=
alibri,sans-serif;color:rgb(31,73,125)"><u></u>=C2=A0<u></u></span></p><p c=
lass=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Calibri,sans=
-serif;color:rgb(31,73,125)">Best regards,<u></u><u></u></span></p><p class=
=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Calibri,sans-ser=
if;color:rgb(31,73,125)">Jie<u></u><u></u></span></p><p class=3D"MsoNormal"=
><span style=3D"font-size:10.5pt;font-family:Calibri,sans-serif;color:rgb(3=
1,73,125)"><u></u>=C2=A0<u></u></span></p><div style=3D"border-top:none;bor=
der-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0in =
0in 0in 4pt"><div><div style=3D"border-right:none;border-bottom:none;border=
-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in"><p cl=
ass=3D"MsoNormal"><b><span style=3D"font-size:11pt;font-family:Calibri,sans=
-serif">From:</span></b><span style=3D"font-size:11pt;font-family:Calibri,s=
ans-serif"> Alvaro Retana [mailto:<a href=3D"mailto:aretana.ietf@gmail.com"=
 target=3D"_blank">aretana.ietf@gmail.com</a>] <br><b>Sent:</b> Wednesday, =
September 11, 2019 12:09 AM<br><b>To:</b> <a href=3D"mailto:draft-ietf-idr-=
rfc5575bis@ietf.org" target=3D"_blank">draft-ietf-idr-rfc5575bis@ietf.org</=
a><br><b>Cc:</b> Dongjie (Jimmy) &lt;<a href=3D"mailto:jie.dong@huawei.com"=
 target=3D"_blank">jie.dong@huawei.com</a>&gt;; <a href=3D"mailto:idr-chair=
s@ietf.org" target=3D"_blank">idr-chairs@ietf.org</a>; idr@ietf. org &lt;<a=
 href=3D"mailto:idr@ietf.org" target=3D"_blank">idr@ietf.org</a>&gt;<br><b>=
Subject:</b> AD Review of draft-ietf-idr-rfc5575bis-17<u></u><u></u></span>=
</p></div></div><p class=3D"MsoNormal"><span><u></u>=C2=A0<u></u></span></p=
><div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif">Dear authors:<u></u><u></u></span></p></div><div><p =
class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,san=
s-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><=
span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">I just finis=
hed reading this document.=C2=A0 Thank you for the work in clarifying and u=
pdating rfc5575!=C2=A0 Many of my comments (see below) are related to what =
I think is still missing clarity, or lack of it in some of the new text.<u>=
</u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font=
-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">Besides the specific comments, I have some larger i=
ssues that I want to detail here.=C2=A0 The first 2 are directed at the She=
pherd and Chairs.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"=
><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=
=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif">(A) IPR<u></u><u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">The Shepherd report, the datatracker and the WGLC thread [1] all point =
at no existing IPR.=C2=A0 However, several declarations do exist...for rfc5=
575 [2].=C2=A0 IMO, the changes between rfc5575 and this document are not t=
hat significant to assume that the declarations don&#39;t apply.=C2=A0 I al=
so note that none of the original authors mentioned as &quot;contributing a=
uthors&quot; (=C2=A715) replied to the IPR call during the WGLC.<u></u><u><=
/u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><=
div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvet=
ica,sans-serif">Jie: As Shepherd, can you please file a third-party disclos=
ure [3] pointing at the rfc5575 disclosures?=C2=A0 Once that is done I will=
 send a message to the WG to consider the information -- I don&#39;t expect=
 any issues, but it has to be done. I&#39;ll need you to also update the Sh=
epherd writeup.=C2=A0 Thanks!<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u><=
/u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif">(B) Support for IPv6<u></u><u></u></sp=
an></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font=
-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p =
class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,san=
s-serif">I understand why this document only focuses on IPv4.=C2=A0 While t=
he text points at draft-ietf-idr-flow-spec-v6, that draft has been expired =
for over a year!=C2=A0 What is the plan to move that work forward?=C2=A0 It=
 looks like there may already be implementations in place [4].<u></u><u></u=
></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt=
;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><di=
v><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetic=
a,sans-serif">We all know this question will come up during IESG Evaluation=
, specially in light of the IAB Statement on IPv6 [5] and the fact that the=
re was a related DISCUSS when rfc5575 was first processed [6] -- at that ti=
me (2009!) the objection was cleared with the promise that an IPv6 document=
 would be forthcoming.<u></u><u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></=
u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif">We should have a plan in p=
lace by the time this document makes it to the IESG Telechat.=C2=A0 It woul=
d have been ideal to publish both at the same time, but I&#39;ll settle for=
 the ability to (at least) point at the WGLC (which has been brought up bef=
ore [7]).<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span s=
tyle=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></=
u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10p=
t;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif">(C) IANA Considerations<u></u><u></u></span></p></div><div><=
p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,s=
ans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"=
><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">(C1) traff=
ic-rate-packets<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><=
span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=
=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif">The instructions to IANA for th=
e assignment of the traffic-rate-packets sub-type are not clear.=C2=A0 The =
existing assignments and the requirement that &quot;traffic actions are pro=
cessed in ascending order of the sub-type&quot; (=C2=A77) seem to imply tha=
t a specific order for this new action may be intended.=C2=A0 Unless explic=
itly instructed, IANA may not assign a value that aligns with that intent. =
=C2=A0[See related comments in =C2=A77.2.]<u></u><u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">(C2) E=
xperimental Use Ranges<u></u><u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></=
u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif">This document uses ranges =
from the &quot;BGP Transitive Extended Community Types&quot; registry which=
 are reserved for Experimental Use.=C2=A0 While the history of this use is =
not clear, we should take the opportunity to clean the registry. =C2=A0[See=
 more in =C2=A712.3.]<u></u><u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u=
>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"f=
ont-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif">(D) Document organization<u></u><u></u></span></=
p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fami=
ly:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">This document kept most of the Introduction text, but then added relate=
d and, in some cases, overlapping and redundant text in =C2=A75 (not =C2=A7=
5.1) and =C2=A79.=C2=A0 Please combine the information from =C2=A71 and =C2=
=A75, and the background from =C2=A79 into an updated Introduction. =C2=A0=
=C2=A76 seems to belong right after the definition of the NLRI (=C2=A74), a=
nd before the next part of the specification (filtering) starts with =C2=A7=
5.1, then =C2=A77...<u></u><u></u></span></p></div><div><p class=3D"MsoNorm=
al"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=
=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">Most of the old text is abou=
t justification, some from the specific point of view of the then-authors.=
=C2=A0 Please reconsider whether that still applies.<u></u><u></u></span></=
p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fami=
ly:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif">I will wait for t=
he major issues/comments to be addressed before starting the IETF Last Call=
.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span=
></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-f=
amily:Helvetica,sans-serif">Thanks!<u></u><u></u></span></p></div><div><p c=
lass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans=
-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><s=
pan style=3D"font-size:10pt;font-family:Helvetica,sans-serif">Alvaro.<u></u=
><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-si=
ze:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
[1] <a href=3D"https://mailarchive.ietf.org/arch/msg/idr/0WQW0pdqq1ae31GYZ7=
-dk3_Wqv8" target=3D"_blank">https://mailarchive.ietf.org/arch/msg/idr/0WQW=
0pdqq1ae31GYZ7-dk3_Wqv8</a><u></u><u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
[2] <a href=3D"https://datatracker.ietf.org/ipr/search/?rfc=3D5575&amp;subm=
it=3Drfc" target=3D"_blank">https://datatracker.ietf.org/ipr/search/?rfc=3D=
5575&amp;submit=3Drfc</a><u></u><u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[3=
] <a href=3D"https://datatracker.ietf.org/ipr/new-third-party/" target=3D"_=
blank">https://datatracker.ietf.org/ipr/new-third-party/</a><u></u><u></u><=
/span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;f=
ont-family:Helvetica,sans-serif">[4] <a href=3D"https://mailarchive.ietf.or=
g/arch/msg/idr/VH0mYVgT39ueJapb0axMgfgcAN8" target=3D"_blank">https://maila=
rchive.ietf.org/arch/msg/idr/VH0mYVgT39ueJapb0axMgfgcAN8</a><u></u><u></u><=
/span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;f=
ont-family:Helvetica,sans-serif">[5] <a href=3D"https://www.iab.org/2016/11=
/07/iab-statement-on-ipv6/" target=3D"_blank">https://www.iab.org/2016/11/0=
7/iab-statement-on-ipv6/</a><u></u><u></u></span></p></div><div><p class=3D=
"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"=
>[6] <a href=3D"https://datatracker.ietf.org/doc/rfc5575/history/" target=
=3D"_blank">https://datatracker.ietf.org/doc/rfc5575/history/</a><u></u><u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif">[7] <a href=3D"https://mailarchive.ie=
tf.org/arch/msg/idr/0J6gWHgBx33u8WpTa0B73mI6rIM" target=3D"_blank">https://=
mailarchive.ietf.org/arch/msg/idr/0J6gWHgBx33u8WpTa0B73mI6rIM</a><u></u><u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u><=
/u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D=
"font-size:10pt;font-family:Helvetica,sans-serif">[Line numbers from idnits=
.]<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D=
"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></spa=
n></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-=
family:Helvetica,sans-serif">...<u></u><u></u></span></p></div><div><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif">17<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0 </=
span>Abstract<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><sp=
an style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<=
u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size=
:10pt;font-family:Helvetica,sans-serif">[nit] It is interesting to me that =
the Abstract was significantly rewritten while the Introduction was mostly =
left unchanged.=C2=A0 I assume this was done to reflect the changes in the =
document upfront...but it then results in, what I think, is an Abstract tha=
t is too long, and an incomplete Introduction.<u></u><u></u></span></p></di=
v><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Hel=
vetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">19=
<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0 </span>=
=C2=A0 This document defines a Border Gateway Protocol Network Layer<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif">20<span class=3D"gmail-m_-24045598=
29259103405apple-tab-span">=C2=A0 </span>=C2=A0 Reachability Information (B=
GP NLRI) encoding format that can be used<u></u><u></u></span></p></div><di=
v><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetic=
a,sans-serif">21<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0 </span>=C2=A0 to distribute traffic Flow Specifications.=C2=A0 This =
allows the routing<u></u><u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">22<span c=
lass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0 </span>=C2=A0 sy=
stem to propagate information regarding more specific components of<u></u><=
u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size=
:10pt;font-family:Helvetica,sans-serif">23<span class=3D"gmail-m_-240455982=
9259103405apple-tab-span">=C2=A0 </span>=C2=A0 the traffic aggregate define=
d by an IP destination prefix.<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif">25<span class=3D"=
gmail-m_-2404559829259103405apple-tab-span">=C2=A0 </span>=C2=A0 It specifi=
es IPv4 traffic Flow Specifications via a BGP NLRI which<u></u><u></u></spa=
n></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-=
family:Helvetica,sans-serif">26<span class=3D"gmail-m_-2404559829259103405a=
pple-tab-span">=C2=A0 </span>=C2=A0 carries traffic Flow Specification filt=
er, and an Extended community<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">27<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0 </s=
pan>=C2=A0 value which encodes actions a routing system can take if the pac=
ket<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">28<span class=3D"gmail=
-m_-2404559829259103405apple-tab-span">=C2=A0 </span>=C2=A0 matches the tra=
ffic flow filters.=C2=A0 The flow filters and the actions<u></u><u></u></sp=
an></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font=
-family:Helvetica,sans-serif">29<span class=3D"gmail-m_-2404559829259103405=
apple-tab-span">=C2=A0 </span>=C2=A0 are processed in a fixed order.=C2=A0 =
Other drafts specify IPv6, MPLS<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">30<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0 </s=
pan>=C2=A0 addresses, L2VPN addresses, and NV03 encapsulation of IP address=
es.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">[nit] s/carries traffic Flow Specification =
filter/carries a traffic Flow Specification filter<u></u><u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">[minor] I think that this paragraph, or something like it, belongs in t=
he Introduction (and not the Abstract), because it provides information tha=
t could benefit from references:<u></u><u></u></span></p></div><div><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif">- the two parts =
of the NLRI; BTW, the community is not even mentioned in the Introduction.<=
u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span><=
/p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fam=
ily:Helvetica,sans-serif">- other drafts... The Introduction only mentions =
and provides a reference to the IPv6 work.<u></u><u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">32<spa=
n class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0 </span>=C2=A0=
 This document obsoletes RFC5575 and RFC7674 to correct unclear<u></u><u></=
u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10p=
t;font-family:Helvetica,sans-serif">33<span class=3D"gmail-m_-2404559829259=
103405apple-tab-span">=C2=A0 </span>=C2=A0 specifications in the flow filte=
rs.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">[major] Please add a similar statement in t=
he Introduction, with references to both RFCs.=C2=A0 There should be an Inf=
ormative reference to both.<u></u><u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
<u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span styl=
e=3D"font-size:10pt;font-family:Helvetica,sans-serif">[minor] Appendix A ta=
lks about the difference of this document with respect to rfc5575.=C2=A0 Wh=
at about rfc7674?=C2=A0 It looks like any updates from rfc7674 have been in=
corporated in this document.=C2=A0 It would be very nice, even if just for =
completion, if there was an Appendix that talked about rfc7674 -- I even th=
ink that a sub-section of Appendix A would be enough.<u></u><u></u></span><=
/p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fam=
ily:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif">35<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0 </=
span>=C2=A0 Applications which use the bgp Flow Specification are: 1) appli=
cation<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span styl=
e=3D"font-size:10pt;font-family:Helvetica,sans-serif">36<span class=3D"gmai=
l-m_-2404559829259103405apple-tab-span">=C2=A0 </span>=C2=A0 which automate=
 inter-domain coordination of traffic filtering, such<u></u><u></u></span><=
/p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fam=
ily:Helvetica,sans-serif">37<span class=3D"gmail-m_-2404559829259103405appl=
e-tab-span">=C2=A0 </span>=C2=A0 as what is required in order to mitigate (=
distributed) denial-of-<u></u><u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">38<s=
pan class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0 </span>=C2=
=A0 service attacks; 2) applications which control traffic filtering in<u><=
/u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif">39<span class=3D"gmail-m_-24045=
59829259103405apple-tab-span">=C2=A0 </span>=C2=A0 the context of a BGP/MPL=
S VPN service, and 3) applications with<u></u><u></u></span></p></div><div>=
<p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,=
sans-serif">40<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0 </span>=C2=A0 centralized control of traffic in a SDN or NFV context=
.=C2=A0 Some<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><spa=
n style=3D"font-size:10pt;font-family:Helvetica,sans-serif">41<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0 </span>=C2=A0 deploy=
ments of these three applications can be handled by the strict<u></u><u></u=
></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt=
;font-family:Helvetica,sans-serif">42<span class=3D"gmail-m_-24045598292591=
03405apple-tab-span">=C2=A0 </span>=C2=A0 ordering of the BGP NLRI traffic =
flow filters, and the strict actions<u></u><u></u></span></p></div><div><p =
class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,san=
s-serif">43<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0 </span>=C2=A0 encoded in the extended community Flow Specification acti=
ons.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">[minor] Please move this paragraph to the I=
ntroduction.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><spa=
n style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u=
></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:=
10pt;font-family:Helvetica,sans-serif">[nit] s/extended community/Extended =
Community/g<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif">...<u></u><u></u></span></p></div><div><p class=3D"MsoNorm=
al"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">133<spa=
n class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>1.=C2=A0 Introduction<u></u><u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif">...<u></u><u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">149<=
span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 This document defines a general procedu=
re to encode flow<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"=
><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">150<span c=
lass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 specification rules for aggregated traffic fl=
ows so that they can be<u></u><u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">151<=
span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 distributed as a BGP [RFC4271] NLRI.=C2=
=A0 Additionally, we define the<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">152<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 required mechanisms to utilize th=
is definition to the problem of<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">153<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 immediate concern to the authors:=
 intra- and inter-provider<u></u><u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1=
54<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 distribution of traffic filtering ru=
les to filter (distributed)<u></u><u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
155<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 denial-of-service (DoS) attacks.<u><=
/u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif">[minor] The document uses &quot;Flow Specification&q=
uot; and &quot;flow specification&quot; to refer to the same thing...right?=
=C2=A0 Or are there differences due to the capitalization?=C2=A0 Please be =
consistent.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif">[style nit] Using &quot;we&quot; is n=
ot the best for a consensus document. =C2=A0s/we define/it defines<u></u><u=
></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:=
10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div=
><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helv=
etica,sans-serif">[nit] &quot;problem of immediate concern to the authors&q=
uot; =C2=A0Only the authors?=C2=A0 This piece of text was also present in r=
fc5575 -- having a different set of authors, I would assume we can safely s=
ay that the concern/application goes beyond the authors...right?=C2=A0 Plea=
se reword.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u><=
/u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif">[minor] Given that this is a bis, is t=
he motivation still the same?=C2=A0 I think in part it is, but in part ther=
e may be other drivers.=C2=A0 Just asking...<u></u><u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[min=
or] This seems to be a good place to move the text from the Abstract that d=
escribes applications...<u></u><u></u></span></p></div><div><p class=3D"Mso=
Normal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u>=
</u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">...<u></u><u></u></spa=
n></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-=
family:Helvetica,sans-serif">164<span class=3D"gmail-m_-2404559829259103405=
apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 A Flow S=
pecification received from an external autonomous system will<u></u><u></u>=
</span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;=
font-family:Helvetica,sans-serif">165<span class=3D"gmail-m_-24045598292591=
03405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 nee=
d to be validated against unicast routing before being accepted.<u></u><u><=
/u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif">166<span class=3D"gmail-m_-24045598292=
59103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =
If the aggregate traffic flow defined by the unicast destination<u></u><u><=
/u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif">167<span class=3D"gmail-m_-24045598292=
59103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =
prefix is forwarded to a given BGP peer, then the local system can<u></u><u=
></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:=
10pt;font-family:Helvetica,sans-serif">168<span class=3D"gmail-m_-240455982=
9259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 install more specific flow rules that may result in different<u></u><u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif">169<span class=3D"gmail-m_-2404559829=
259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0=
 forwarding behavior, as requested by this system.<u></u><u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">[major] &quot;A Flow Specification received from an external autonomous=
 system will need to be validated against unicast routing before being acce=
pted.&quot; =C2=A0What about if received internally?<u></u><u></u></span></=
p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fami=
ly:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">171<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 The key technology components req=
uired to address the class of<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">172<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 problems targeted by this documen=
t are:<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span styl=
e=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u><=
/span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;f=
ont-family:Helvetica,sans-serif">174<span class=3D"gmail-m_-240455982925910=
3405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 1.=
=C2=A0 Efficient point-to-multipoint distribution of control plane<u></u><u=
></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:=
10pt;font-family:Helvetica,sans-serif">175<span class=3D"gmail-m_-240455982=
9259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 =C2=A0 =C2=A0 information.<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif">177<span class=3D=
"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 </span>=C2=A0 2.=C2=A0 Inter-domain capabilities and routing policy =
support.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span st=
yle=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u=
></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt=
;font-family:Helvetica,sans-serif">179<span class=3D"gmail-m_-2404559829259=
103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 3.=
=C2=A0 Tight integration with unicast routing, for verification<u></u><u></=
u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10p=
t;font-family:Helvetica,sans-serif">180<span class=3D"gmail-m_-240455982925=
9103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =
=C2=A0 =C2=A0 purposes.<u></u><u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u><=
/u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D=
"font-size:10pt;font-family:Helvetica,sans-serif">182<span class=3D"gmail-m=
_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
/span>=C2=A0 Items 1 and 2 have already been addressed using BGP for other =
types<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">183<span class=3D"gmai=
l-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 of control plane information.=C2=A0 Close integration wit=
h BGP also makes<u></u><u></u></span></p></div><div><p class=3D"MsoNormal">=
<span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">184<span cl=
ass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 it feasible to specify a mechanism to automatica=
lly verify flow<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><=
span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">185<span cla=
ss=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 information against unicast routing.=C2=A0 These=
 factors are behind the<u></u><u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">186<=
span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 choice of BGP as the carrier of Flow Sp=
ecification information.<u></u><u></u></span></p></div><div><p class=3D"Mso=
Normal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u>=
</u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">[nit] I don&#39;t thin=
k that we need to keep justifying...=C2=A0 Just a nit...<u></u><u></u></spa=
n></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-=
family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p c=
lass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans=
-serif">188<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 As with previous extensions=
 to BGP, this specification makes it<u></u><u></u></span></p></div><div><p =
class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,san=
s-serif">189<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 possible to add additional =
information to Internet routers.=C2=A0 These<u></u><u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif">190<span class=3D"gmail-m_-2404559829259103405apple-tab-sp=
an">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 are limited in terms=
 of the maximum number of data elements they can<u></u><u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif">191<span class=3D"gmail-m_-2404559829259103405apple-ta=
b-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 hold as well as =
the number of events they are able to process in a<u></u><u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif">192<span class=3D"gmail-m_-2404559829259103405apple-=
tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 given unit of =
time.=C2=A0 The authors believe that, as with previous<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif">193<span class=3D"gmail-m_-2404559829259103405ap=
ple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 extensions=
, service providers will be careful to keep information<u></u><u></u></span=
></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-f=
amily:Helvetica,sans-serif">194<span class=3D"gmail-m_-2404559829259103405a=
pple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 levels be=
low the maximum capacity of their devices.<u></u><u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">196<sp=
an class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Experience with previous BGP extensions ha=
s also shown that the<u></u><u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">197<sp=
an class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 maximum capacity of BGP speakers has been =
gradually increased<u></u><u></u></span></p></div><div><p class=3D"MsoNorma=
l"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">198<span=
 class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 according to expected loads.=C2=A0 For exampl=
e Internet unicast routing as<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">199<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 well as other BGP applications in=
creased their maximum capacity as<u></u><u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif">200<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 they gain popularity.<u></u><u=
></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:=
10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div=
><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helv=
etica,sans-serif">[minor] This is the same text from 10 years ago.=C2=A0 Ma=
ny things, including hardware processing/storage, has changed.=C2=A0 Is thi=
s text still necessary?=C2=A0 If so, then I would like to see explicit oper=
ational considerations on what an operator should look for when being &quot=
;careful&quot;.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><=
span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=
=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif">...<u></u><u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">2=
14<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 In current deployments, the informat=
ion distributed by the flow-spec<u></u><u></u></span></p></div><div><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif">215<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 extension is originated both m=
anually as well as automatically.=C2=A0 The<u></u><u></u></span></p></div><=
div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvet=
ica,sans-serif">216<span class=3D"gmail-m_-2404559829259103405apple-tab-spa=
n">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 latter by systems tha=
t are able to detect malicious flows.=C2=A0 When<u></u><u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif">217<span class=3D"gmail-m_-2404559829259103405apple-ta=
b-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 automated system=
s are used, care should be taken to ensure their<u></u><u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif">218<span class=3D"gmail-m_-2404559829259103405apple-ta=
b-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 correctness as w=
ell as to limit the number and advertisement rate of<u></u><u></u></span></=
p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fami=
ly:Helvetica,sans-serif">219<span class=3D"gmail-m_-2404559829259103405appl=
e-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 flow routes.=
<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"f=
ont-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif">[major] An automated system that is not &quot;co=
rrect&quot;, because it may not be properly programmed, the algorithms used=
 are not performing as expected, or simply because it is rogue, are all vul=
nerabilities that should be called out in the Security Considerations secti=
on.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">221<span class=3D"gmail-m_-2404559829259103=
405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 This =
specification defines required protocol extensions to address<u></u><u></u>=
</span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;=
font-family:Helvetica,sans-serif">222<span class=3D"gmail-m_-24045598292591=
03405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 mos=
t common applications of IPv4 unicast and VPNv4 unicast filtering.<u></u><u=
></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:=
10pt;font-family:Helvetica,sans-serif">223<span class=3D"gmail-m_-240455982=
9259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 The same mechanism can be reused and new match criteria added to<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif">224<span class=3D"gmail-m_-2404559=
829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 address similar filtering needs for other BGP address families such<u><=
/u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif">225<span class=3D"gmail-m_-2404=
559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 as IPv6 families [I-D.ietf-idr-flow-spec-v6],<u></u><u></u></span></=
p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fami=
ly:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">[nit] s/[I-D.ietf-idr-flow-spec-v6],/[I-D.ietf-idr-flow-spec-v6].<u></u=
><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-si=
ze:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
227<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>2.=C2=A0 Definitions of Terms Used in This =
Memo<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">...<u></u><u></u></spa=
n></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-=
family:Helvetica,sans-serif">233<span class=3D"gmail-m_-2404559829259103405=
apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Loc-RIB =
- =C2=A0 Local RIB.<u></u><u></u></span></p></div><div><p class=3D"MsoNorma=
l"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=
=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">[major] This simple definiti=
on doesn&#39;t match the one in =C2=A71.1/rfc4271.<u></u><u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif">..<u></u><u></u><=
/span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;f=
ont-family:Helvetica,sans-serif">247<span class=3D"gmail-m_-240455982925910=
3405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>3.=C2=A0 Fl=
ow Specifications<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"=
><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">...<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif">266<span class=3D"gmail-m_-2404559=
829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 BGP itself treats the NLRI as an key to an entry in its databases.<u></=
u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-s=
ize:10pt;font-family:Helvetica,sans-serif">267<span class=3D"gmail-m_-24045=
59829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 Entries that are placed in the Loc-RIB are then associated with a<u>=
</u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font=
-size:10pt;font-family:Helvetica,sans-serif">268<span class=3D"gmail-m_-240=
4559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span=
>=C2=A0 given set of semantics, which is application dependent.=C2=A0 This =
is<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D=
"font-size:10pt;font-family:Helvetica,sans-serif">269<span class=3D"gmail-m=
_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
/span>=C2=A0 consistent with existing BGP applications.=C2=A0 For instance,=
 IP unicast<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif">270<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 routing (AFI=3D1, SAFI=3D1) and IP multicast revers=
e-path information<u></u><u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">271<span =
class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 (AFI=3D1, SAFI=3D2) are handled by BGP withou=
t any particular semantics<u></u><u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">2=
72<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 being associated with them until ins=
talled in the Loc-RIB.<u></u><u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></=
u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif">[nit] s/an key/a key<u></u=
><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-si=
ze:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif">274<span class=3D"gmail-m_-2404559829259103405apple-ta=
b-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Standard BGP pol=
icy mechanisms, such as UPDATE filtering by NLRI<u></u><u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif">275<span class=3D"gmail-m_-2404559829259103405apple-ta=
b-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 prefix as well a=
s community matching and manipulation, MUST apply to<u></u><u></u></span></=
p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fami=
ly:Helvetica,sans-serif">276<span class=3D"gmail-m_-2404559829259103405appl=
e-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 the Flow Spe=
cification defined NLRI-type, especially in an inter-<u></u><u></u></span><=
/p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fam=
ily:Helvetica,sans-serif">277<span class=3D"gmail-m_-2404559829259103405app=
le-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 domain envi=
ronment.=C2=A0 Network operators can also control propagation<u></u><u></u>=
</span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;=
font-family:Helvetica,sans-serif">278<span class=3D"gmail-m_-24045598292591=
03405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 of =
such routing updates by enabling or disabling the exchange of a<u></u><u></=
u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10p=
t;font-family:Helvetica,sans-serif">279<span class=3D"gmail-m_-240455982925=
9103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 p=
articular (AFI, SAFI) pair on a given BGP peering session.<u></u><u></u></s=
pan></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fon=
t-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p=
 class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sa=
ns-serif">[major] The point of NLRIs all being treated the same is made abo=
ve, to reinforce the default BGP behavior...and this paragraph tries to bri=
ng home the point by Normatively enforcing it (MUST).=C2=A0 However, becaus=
e the behavior is what BGP specifies by default, then this document cannot =
be Normative in it (unless it specified an exception). =C2=A0s/MUST/must<u>=
</u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font=
-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">281<span class=3D"gmail-m_-2404559829259103405apple=
-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>4.=C2=A0 Disseminati=
on of IPv4 FLow Specification Information<u></u><u></u></span></p></div><di=
v><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetic=
a,sans-serif">...<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"=
><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">287<span c=
lass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 This NLRI information is encoded using MP_REA=
CH_NLRI and<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif">288<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 MP_UNREACH_NLRI attributes as defined in [RFC4760].=
=C2=A0 Whenever the<u></u><u></u></span></p></div><div><p class=3D"MsoNorma=
l"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">289<span=
 class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 corresponding application does not require Ne=
xt-Hop information, this<u></u><u></u></span></p></div><div><p class=3D"Mso=
Normal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">290=
<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 shall be encoded as a 0-octet length Ne=
xt Hop in the MP_REACH_NLRI<u></u><u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
291<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 attribute and ignored on receipt.<u>=
</u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font=
-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">[minor] s/Next-Hop/Next Hop =C2=A0 =C2=A0 =C2=A0 rf=
c4760 uses &quot;Next Hop&quot;<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[nit] &quot;...sh=
all be encoded as a 0-octet length Next Hop in the MP_REACH_NLRI attribute =
and ignored on receipt.&quot; =C2=A0What is ignored?=C2=A0 The Next Hop?=C2=
=A0 If it doesn&#39;t exist (length =3D 0), then it can&#39;t be ignored...=
=C2=A0 Perhaps delete &quot; and ignored on receipt&quot;.<u></u><u></u></s=
pan></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fon=
t-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p=
 class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sa=
ns-serif">...<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><sp=
an style=3D"font-size:10pt;font-family:Helvetica,sans-serif">297<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 +------------------------------+<u></=
u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-s=
ize:10pt;font-family:Helvetica,sans-serif">298<span class=3D"gmail-m_-24045=
59829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0length (0xnn or 0xfn nn) =C2=A0|<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif">299<span class=3D"gmail-m_-2404559=
829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 =C2=A0 =C2=A0 +------------------------------+<u></u><u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif">300<span class=3D"gmail-m_-2404559829259103405apple-=
tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =
| =C2=A0 =C2=A0NLRI value =C2=A0(variable) =C2=A0 =C2=A0|<u></u><u></u></sp=
an></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font=
-family:Helvetica,sans-serif">301<span class=3D"gmail-m_-240455982925910340=
5apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =
=C2=A0 +------------------------------+<u></u><u></u></span></p></div><div>=
<p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,=
sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[minor] s=
/0xfn nn/0xfnnn<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><=
span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=
=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif">...<u></u><u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">3=
12<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>4.1.=C2=A0 Length Encoding<u></u><u></u></s=
pan></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fon=
t-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p=
 class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sa=
ns-serif">314<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 o =C2=A0If the NLRI length =
value is smaller than 240 (0xf0 hex), the<u></u><u></u></span></p></div><di=
v><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetic=
a,sans-serif">315<span class=3D"gmail-m_-2404559829259103405apple-tab-span"=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0length fie=
ld can be encoded as a single octet.<u></u><u></u></span></p></div><div><p =
class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,san=
s-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><=
span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[nit] s/240/=
240 octets<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u><=
/u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif">317<span class=3D"gmail-m_-24045598292=
59103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =
o =C2=A0Otherwise, it is encoded as an extended-length 2-octet value in<u><=
/u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif">318<span class=3D"gmail-m_-2404=
559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 =C2=A0 =C2=A0which the most significant nibble of the first byte is =
all ones.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span s=
tyle=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></=
u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10p=
t;font-family:Helvetica,sans-serif">320<span class=3D"gmail-m_-240455982925=
9103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 I=
n figure 1 above, values less-than 240 are encoded using two hex<u></u><u><=
/u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif">321<span class=3D"gmail-m_-24045598292=
59103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =
digits (0xnn).=C2=A0 Values above 239 are encoded using 3 hex digits<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif">322<span class=3D"gmail-m_-2404559=
829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 (0xfnnn).=C2=A0 The highest value that can be represented with this<u><=
/u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif">323<span class=3D"gmail-m_-2404=
559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 encoding is 4095.=C2=A0 The value 241 is encoded as 0xf0f1.<u></u><u=
></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:=
10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div=
><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helv=
etica,sans-serif">[nit] It may make more sense to show the encoding for 240=
.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span=
></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-f=
amily:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p cl=
ass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-=
serif">325<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>4.2.=C2=A0 NLRI Value Encoding<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif">...<u></u><u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif">332<span class=3D"gmail-m_-2404559829259103405apple-tab-sp=
an">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 The encoding of each=
 of the NLRI components begins with a type field<u></u><u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif">333<span class=3D"gmail-m_-2404559829259103405apple-ta=
b-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 (1 octet) follow=
ed by a variable length parameter.=C2=A0 Section 4.2.1 to<u></u><u></u></sp=
an></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font=
-family:Helvetica,sans-serif">334<span class=3D"gmail-m_-240455982925910340=
5apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Section=
 4.2.12 define component types and parameter encodings for the<u></u><u></u=
></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt=
;font-family:Helvetica,sans-serif">335<span class=3D"gmail-m_-2404559829259=
103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 IP=
v4 IP layer and transport layer headers.=C2=A0 IPv6 NLRI component types<u>=
</u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font=
-size:10pt;font-family:Helvetica,sans-serif">336<span class=3D"gmail-m_-240=
4559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span=
>=C2=A0 are described in [I-D.ietf-idr-flow-spec-v6].<u></u><u></u></span><=
/p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fam=
ily:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif">[minor] &quot;followed by a variable length parameter&quot; =C2=A0 Onl=
y the first two types have a variable length parameter...<u></u><u></u></sp=
an></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font=
-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p =
class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,san=
s-serif">338<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Flow Specification componen=
ts must follow strict type ordering by<u></u><u></u></span></p></div><div><=
p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,s=
ans-serif">339<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 increasing numerical ord=
er.=C2=A0 A given component type may (exactly<u></u><u></u></span></p></div=
><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helv=
etica,sans-serif">340<span class=3D"gmail-m_-2404559829259103405apple-tab-s=
pan">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 once) or may not be=
 present in the specification.=C2=A0 If present, it<u></u><u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">341<span class=3D"gmail-m_-2404559829259103405apple=
-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 MUST precede =
any component of higher numeric type value.<u></u><u></u></span></p></div><=
div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvet=
ica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[majo=
r] What should happen if a component appears more than once?<u></u><u></u><=
/span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;f=
ont-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div>=
<p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,=
sans-serif">[major] What should happen if the order is not maintained?<u></=
u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-s=
ize:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p><=
/div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:=
Helvetica,sans-serif">343<span class=3D"gmail-m_-2404559829259103405apple-t=
ab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 All combination=
s of component types within a single NLRI are allowed,<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif">344<span class=3D"gmail-m_-2404559829259103405ap=
ple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 even if th=
e combination makes no sense from a semantical perspective.<u></u><u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">345<span class=3D"gmail-m_-2404559829259103=
405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 If a =
given component type within a prefix in unknown, the prefix in<u></u><u></u=
></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt=
;font-family:Helvetica,sans-serif">346<span class=3D"gmail-m_-2404559829259=
103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 qu=
estion cannot be used for traffic filtering purposes by the<u></u><u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">347<span class=3D"gmail-m_-2404559829259103=
405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 recei=
ver.=C2=A0 Since a Flow Specification has the semantics of a logical<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif">348<span class=3D"gmail-m_-2404559=
829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 AND of all components, if a component is FALSE, by definition it<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif">349<span class=3D"gmail-m_-2404559=
829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 cannot be applied.=C2=A0 However, for the purposes of BGP route<u></u><=
u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size=
:10pt;font-family:Helvetica,sans-serif">350<span class=3D"gmail-m_-24045598=
29259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 propagation, this prefix should still be transmitted since BGP route<u>=
</u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font=
-size:10pt;font-family:Helvetica,sans-serif">351<span class=3D"gmail-m_-240=
4559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span=
>=C2=A0 distribution is independent on NLRI semantics.<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif">[nit] s/prefix in unknown/prefix is unknown<u></u><u></u></span></p><=
/div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:=
Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D=
"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"=
>[nit] s/independent on NLRI/independent of NLRI<u></u><u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
[major] &quot;...for the purposes of BGP route propagation, this prefix sho=
uld still be transmitted since BGP route distribution is independent on NLR=
I semantics.&quot; =C2=A0I think this is a vulnerability: a (large) set of =
meaningless Flow Specifications may be injected in the routing system...<u>=
</u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font=
-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">[major] Also, propagating these unknown components =
may result in a router down the line, which understands them, reacting.=C2=
=A0 While the reaction shouldn&#39;t result in reset adjacencies, it may re=
sult in inconsistent forwarding or other unexpected outcomes...<u></u><u></=
u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10p=
t;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif">[major] This treatment of unknown extensions is in conflict =
with the text in =C2=A711.=C2=A0 See my comments there.<u></u><u></u></span=
></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-f=
amily:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p cl=
ass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-=
serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><sp=
an style=3D"font-size:10pt;font-family:Helvetica,sans-serif">353<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>4.2.1.=C2=A0 Type 1 - Destination Prefix<u></u><u></u></sp=
an></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font=
-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p =
class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,san=
s-serif">355<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0Encoding: &lt;=
type (1 octet), prefix length (1 octet), prefix&gt;<u></u><u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">357<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0Defines: the destina=
tion prefix to match.=C2=A0 Prefixes are encoded as<u></u><u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">358<span class=3D"gmail-m_-2404559829259103405apple=
-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0=
in BGP UPDATE messages, a length in bits is followed by enough<u></u><u></u=
></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt=
;font-family:Helvetica,sans-serif">359<span class=3D"gmail-m_-2404559829259=
103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =
=C2=A0 =C2=A0octets to contain the prefix information.<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif">[nit] s/Defines: the destination prefix/Defines the destination prefi=
x<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span=
></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-f=
amily:Helvetica,sans-serif">[major] rfc4271: &quot;The Prefix field contain=
s an IP address prefix, followed by the minimum number of trailing bits nee=
ded to make the end of the field fall on an octet boundary.&quot; =C2=A0 Th=
e text above makes it sound as if the prefix field may not end in an octet =
boundary, which is what rfc4271 specifies.<u></u><u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">NEW (s=
uggestion)&gt;<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><s=
pan style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=C2=A0 =C2=A0=
Defines the destination prefix to match.=C2=A0 The length and prefix fields=
 are<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">=C2=A0 =C2=A0encoded a=
s in BGP UPDATE messages [rfc4271].<u></u><u></u></span></p></div><div><p c=
lass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans=
-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><s=
pan style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif">361<span class=3D"gmail-m_-2404559=
829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>4.2=
.2.=C2=A0 Type 2 - Source Prefix<u></u><u></u></span></p></div><div><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif">363<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0Encoding: &lt;type (1 octet), prefix-l=
ength (1 octet), prefix&gt;<u></u><u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
<u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span styl=
e=3D"font-size:10pt;font-family:Helvetica,sans-serif">365<span class=3D"gma=
il-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 =C2=A0 =C2=A0Defines the source prefix to match.<u></u><u=
></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:=
10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div=
><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helv=
etica,sans-serif">[minor] &quot;... The length and prefix fields are encode=
d as in BGP UPDATE messages [rfc4271].&quot;<u></u><u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u><=
/u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D=
"font-size:10pt;font-family:Helvetica,sans-serif">367<span class=3D"gmail-m=
_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
/span>4.2.3.=C2=A0 Type 3 - IP Protocol<u></u><u></u></span></p></div><div>=
<p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,=
sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">369<span =
class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0Encoding:&lt;type (1 octet), [op=
, value]+&gt;<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><sp=
an style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<=
u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size=
:10pt;font-family:Helvetica,sans-serif">371<span class=3D"gmail-m_-24045598=
29259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 =C2=A0 =C2=A0Contains a set of {operator, value} pairs that are used to=
 match<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span styl=
e=3D"font-size:10pt;font-family:Helvetica,sans-serif">372<span class=3D"gma=
il-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 =C2=A0 =C2=A0the IP protocol value byte in IP packets.<u>=
</u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font=
-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">[minor] Include a reference to the protocol numbers=
.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span=
></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-f=
amily:Helvetica,sans-serif">[major] Are all protocol numbers valid?=C2=A0 I=
 guess that in theory anything is -- what should a receiver do with Flow Sp=
ecifications that cover protocols that are not supported?=C2=A0 I&#39;m won=
dering if sending Flow Specifications for every protocol under the sun is a=
 vulnerability -- knowing that only a few will ever be present in the Inter=
net.=C2=A0 Is there any guidance that you can provide in =C2=A714 (or a sep=
arate Operational Considerations section)?=C2=A0 I also point this out beca=
use the rest of the types focus on TCP/UDP...what about other transport lay=
er protocols?<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><sp=
an style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<=
u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size=
:10pt;font-family:Helvetica,sans-serif">[major] Related question: even for =
&quot;valid&quot; protocols, should all be accepted from eBGP peers?=C2=A0 =
I think that it is probably ok...asking for completeness.<u></u><u></u></sp=
an></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font=
-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p =
class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,san=
s-serif">374<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0The operator b=
yte is encoded as:<u></u><u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=
=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">376<span class=3D"gmail-m_-2=
404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </sp=
an>=C2=A0 =C2=A0 0 =C2=A0 1 =C2=A0 2 =C2=A0 3 =C2=A0 4 =C2=A0 5 =C2=A0 6 =
=C2=A0 7<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span st=
yle=3D"font-size:10pt;font-family:Helvetica,sans-serif">377<span class=3D"g=
mail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 </span>=C2=A0 +---+---+---+---+---+---+---+---+<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif">378<span class=3D"gmail-m_-2404559829259103405ap=
ple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | e | a | =
=C2=A0len =C2=A0| 0 |lt |gt |eq |<u></u><u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif">379<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 +---+---+---+---+---+---+---+-=
--+<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">381<span class=3D"gmail-m_-2404559829259103=
405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0Numeric operator<u></u><u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><spa=
n style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[nit] Center th=
e figure...<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif">[clarity] Please describe the operato=
rs independent of one of the Types.=C2=A0 As defined, it looks like they on=
ly apply to one type...it is much later that the reader realizes that there=
 is a reason for the &quot;complexity&quot;.=C2=A0 Along the same lines, I =
think that the &quot;set of {operator, value} pairs&quot; phrase could use =
some more text to explain that the operator is the whole octet, with a corr=
esponding value...<u></u><u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=
=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">383<span class=3D"gmail-m_-2=
404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </sp=
an>=C2=A0 =C2=A0 =C2=A0e - end-of-list bit.=C2=A0 Set in the last {op, valu=
e} pair in the<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><s=
pan style=3D"font-size:10pt;font-family:Helvetica,sans-serif">384<span clas=
s=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0list.<u></u><u></u></span></p></div=
><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helv=
etica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"Mso=
Normal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[ma=
jor] What action should be taken if a received flow spec has this bit not s=
et anywhere, or is set somewhere other than the last pair?<u></u><u></u></s=
pan></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fon=
t-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p=
 class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sa=
ns-serif">386<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0a - AND bit.=
=C2=A0 If unset, the previous term is logically ORed with<u></u><u></u></sp=
an></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font=
-family:Helvetica,sans-serif">387<span class=3D"gmail-m_-240455982925910340=
5apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =
=C2=A0the current one.=C2=A0 If set, the operation is a logical AND.=C2=A0 =
In the<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span styl=
e=3D"font-size:10pt;font-family:Helvetica,sans-serif">388<span class=3D"gma=
il-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 =C2=A0 =C2=A0first operator byte of a sequence it SHOULD =
be encoded as unset<u></u><u></u></span></p></div><div><p class=3D"MsoNorma=
l"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">389<span=
 class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0and and MUST be treated as alway=
s unset on decoding.=C2=A0 The AND<u></u><u></u></span></p></div><div><p cl=
ass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-=
serif">390<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0operator has high=
er priority than OR for the purposes of<u></u><u></u></span></p></div><div>=
<p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,=
sans-serif">391<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0evaluating =
logical expressions.<u></u><u></u></span></p></div><div><p class=3D"MsoNorm=
al"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=
=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">393<span class=3D"gmail-m_-2=
404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </sp=
an>=C2=A0 =C2=A0 =C2=A0len - length of the value field for this operator gi=
ven as (1 &lt;&lt;<u></u><u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">394<span =
class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0len).=C2=A0 This encodes 1 (00) =
- 8 (11) bytes.=C2=A0 Type 3 flow component<u></u><u></u></span></p></div><=
div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvet=
ica,sans-serif">395<span class=3D"gmail-m_-2404559829259103405apple-tab-spa=
n">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0values S=
HOULD be encoded as single byte (len =3D 00).<u></u><u></u></span></p></div=
><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helv=
etica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"Mso=
Normal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[ma=
jor] Please expand on the meaning of &quot;1 &lt;&lt; len&quot;.<u></u><u><=
/u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><=
div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvet=
ica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">...<u=
></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fon=
t-size:10pt;font-family:Helvetica,sans-serif">406<span class=3D"gmail-m_-24=
04559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </spa=
n>=C2=A0 The bits lt, gt, and eq can be combined to produce common relation=
al<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D=
"font-size:10pt;font-family:Helvetica,sans-serif">407<span class=3D"gmail-m=
_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
/span>=C2=A0 operators such as &quot;less or equal&quot;, &quot;greater or =
equal&quot;, and &quot;not equal<u></u><u></u></span></p></div><div><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif">408<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 to&quot;.<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif">[minor] &quot;...as shown in Table 1.&quot;<u></u><u></u></span></p><=
/div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:=
Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D=
"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"=
>410<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-=
---+----+----+----------------------------------+<u></u><u></u></span></p><=
/div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:=
Helvetica,sans-serif">411<span class=3D"gmail-m_-2404559829259103405apple-t=
ab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0| lt | gt | eq | Resulting operation =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<u></u><u></u></span></p></div><div><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif">412<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0+----+----+----+----------------------------------+<u></u><u></u></sp=
an></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font=
-family:Helvetica,sans-serif">413<span class=3D"gmail-m_-240455982925910340=
5apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0| 0 =C2=A0| 0 =C2=A0| 0 =C2=A0| false (independe=
nt of the value) |<u></u><u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">414<span =
class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 0 =C2=A0|=
 0 =C2=A0| 1 =C2=A0| =3D=3D (equal) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<u></u><u></u></span></p></div><div=
><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica=
,sans-serif">415<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0| 0 =C2=A0| 1 =C2=A0| 0 =C2=A0| &gt; (greater than) =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<u></u><u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif">416<span class=3D"gmail-m_-2404559829259103405apple-tab-sp=
an">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0| 0 =C2=A0| 1 =C2=A0| 1 =C2=A0| &gt;=3D (greater than or equa=
l) =C2=A0 =C2=A0 =C2=A0 |<u></u><u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">41=
7<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 1 =
=C2=A0| 0 =C2=A0| 0 =C2=A0| &lt; (less than) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<u></u><u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif">418<span class=3D"gmail-m_-2404559829259103405apple-tab-span=
">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0| 1 =C2=A0| 0 =C2=A0| 1 =C2=A0| &lt;=3D (less than or equal) =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<u></u><u></u></span></p></div><div><p c=
lass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans=
-serif">419<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0| 1 =C2=A0| 1 =C2=A0| 0 =C2=A0| !=3D (not equal value) =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">420<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0| 1 =C2=A0| 1 =C2=A0| 1 =C2=A0| true (independent of the value) =C2=A0|<=
u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">421<span class=3D"gmail-m_-2=
404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </sp=
an>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+----+----+----+---------------=
-------------------+<u></u><u></u></span></p></div><div><p class=3D"MsoNorm=
al"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=
=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">423<span class=3D"gmail-m_-2=
404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </sp=
an>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Table 1: Comparis=
on operation combinations<u></u><u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u=
></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">425<span class=3D"gmai=
l-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>4.2.4.=C2=A0 Type 4 - Port<u></u><u></u></span></p></div><div><p=
 class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sa=
ns-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal">=
<span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">427<span cl=
ass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0Encoding:&lt;type (1 octet), [op, v=
alue]+&gt;<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u><=
/u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif">429<span class=3D"gmail-m_-24045598292=
59103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =
=C2=A0 =C2=A0Defines a list of {operator, value} pairs that matches source =
OR<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D=
"font-size:10pt;font-family:Helvetica,sans-serif">430<span class=3D"gmail-m=
_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
/span>=C2=A0 =C2=A0 =C2=A0destination TCP/UDP ports.=C2=A0 This list is enc=
oded using the numeric<u></u><u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">431<s=
pan class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0operator format defined in Se=
ction 4.2.3.=C2=A0 Values SHOULD be<u></u><u></u></span></p></div><div><p c=
lass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans=
-serif">432<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0encoded as 1- =
or 2-byte quantities.<u></u><u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u=
>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"f=
ont-size:10pt;font-family:Helvetica,sans-serif">[minor] A reference to TCP/=
UDP header/ports would be nice.<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[major] &quot;mat=
ches source OR destination TCP/UDP ports&quot; =C2=A0Which one?=C2=A0 Both?=
=C2=A0 Either?=C2=A0 How does the receiver know which one?<u></u><u></u></s=
pan></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fon=
t-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p=
 class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sa=
ns-serif">[minor] What is the interaction/relationship between this type an=
d Types 5 and 6?=C2=A0 The text in =C2=A74.2 allows for all 3 types to be p=
resent, and have an influence in the action taken...they seem redundant.<u>=
</u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font=
-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">434<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0Port, source port, a=
nd destination port components evaluate to<u></u><u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif">435<span class=3D"gmail-m_-2404559829259103405apple-tab-span=
">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0FALSE if =
the IP protocol field of the packet has a value other<u></u><u></u></span><=
/p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fam=
ily:Helvetica,sans-serif">436<span class=3D"gmail-m_-2404559829259103405app=
le-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=
=A0than TCP or UDP, if the packet is fragmented and this is not the<u></u><=
u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size=
:10pt;font-family:Helvetica,sans-serif">437<span class=3D"gmail-m_-24045598=
29259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 =C2=A0 =C2=A0first fragment, or if the system in unable to locate the t=
ransport<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span st=
yle=3D"font-size:10pt;font-family:Helvetica,sans-serif">438<span class=3D"g=
mail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0header.=C2=A0 Different implementations m=
ay or may not be able to<u></u><u></u></span></p></div><div><p class=3D"Mso=
Normal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">439=
<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0decode the transport heade=
r in the presence of IP options or<u></u><u></u></span></p></div><div><p cl=
ass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-=
serif">440<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0Encapsulating Sec=
urity Payload (ESP) NULL [RFC4303] encryption.<u></u><u></u></span></p></di=
v><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Hel=
vetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[m=
inor] &quot;Port, source port, and destination port components...&quot; =C2=
=A0This section only talks about the port; please duplicate this text in th=
e other sections, or put a reference to it there, or put a forward referenc=
e here...<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span s=
tyle=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></=
u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10p=
t;font-family:Helvetica,sans-serif">[major] &quot;...evaluate to FALSE if t=
he IP protocol field of the packet has a value other than TCP or UDP, if th=
e packet is fragmented and this is not the first fragment, or if the system=
 in unable to locate the transport header.&quot; =C2=A0This sentence seems =
to mix the applicability of the Flow Specification (FALSE is first introduc=
ed in =C2=A74.2 to describe the effect of a component on the rule), and the=
 application to a specific packet.=C2=A0 Please separate the two aspects. I=
 do have some specific questions/comments.<u></u><u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">(1) Th=
e text starts by talking about the &quot;protocol field of the packet&quot;=
 (not the protocol value in the Type 3 parameter)...=C2=A0 I assume that a =
Flow Specification would only apply to a packet if the protocol matches the=
 Type 3 parameter...but the statement seems to say that it wouldn&#39;t app=
ly regardless of the Type 3 (see my question there about valid protocols)..=
.or maybe even if a Type 3 is not present...<u></u><u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">(2) =
&quot;...evaluate to FALSE...if the packet is fragmented and this is not th=
e first fragment...&quot; =C2=A0Type 12 specifically includes values for ot=
her cases.=C2=A0 How is the interaction expected?<u></u><u></u></span></p><=
/div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:=
Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D=
"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"=
><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span sty=
le=3D"font-size:10pt;font-family:Helvetica,sans-serif">...<u></u><u></u></s=
pan></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fon=
t-family:Helvetica,sans-serif">460<span class=3D"gmail-m_-24045598292591034=
05apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>4.2.7.=C2=A0 =
Type 7 - ICMP type<u></u><u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=
=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">462<span class=3D"gmail-m_-2=
404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </sp=
an>=C2=A0 =C2=A0 =C2=A0Encoding:&lt;type (1 octet), [op, value]+&gt;<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif">464<span class=3D"gmail-m_-2404559829259103405apple-tab=
-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0Defi=
nes a list of {operator, value} pairs used to match the type<u></u><u></u><=
/span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;f=
ont-family:Helvetica,sans-serif">465<span class=3D"gmail-m_-240455982925910=
3405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=
=A0 =C2=A0field of an ICMP packet.=C2=A0 This list is encoded using the num=
eric<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">466<span class=3D"gmai=
l-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 =C2=A0 =C2=A0operator format defined in Section 4.2.3.=C2=
=A0 Values SHOULD be<u></u><u></u></span></p></div><div><p class=3D"MsoNorm=
al"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">467<spa=
n class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0encoded using a single byte.<=
u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span><=
/p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fam=
ily:Helvetica,sans-serif">[minor] A reference to ICMP would be nice.<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif">469<span class=3D"gmail-m_-2404559829259103405apple-tab=
-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0The =
ICMP type specifiers evaluate to FALSE whenever the protocol<u></u><u></u><=
/span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;f=
ont-family:Helvetica,sans-serif">470<span class=3D"gmail-m_-240455982925910=
3405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=
=A0 =C2=A0value is not ICMP.<u></u><u></u></span></p></div><div><p class=3D=
"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"=
><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span sty=
le=3D"font-size:10pt;font-family:Helvetica,sans-serif">472<span class=3D"gm=
ail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>4.2.8.=C2=A0 Type 8 - ICMP code<u></u><u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">474<sp=
an class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0Encoding:&lt;type (1 octet), =
[op, value]+&gt;<u></u><u></u></span></p></div><div><p class=3D"MsoNormal">=
<span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=
=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif">476<span class=3D"gmail-m_-2404=
559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 =C2=A0 =C2=A0Defines a list of {operator, value} pairs used to match=
 the code<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span s=
tyle=3D"font-size:10pt;font-family:Helvetica,sans-serif">477<span class=3D"=
gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0field of an ICMP packet.=C2=A0 This list =
is encoded using the numeric<u></u><u></u></span></p></div><div><p class=3D=
"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"=
>478<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0operator format defined=
 in Section 4.2.3.=C2=A0 Values SHOULD be<u></u><u></u></span></p></div><di=
v><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetic=
a,sans-serif">479<span class=3D"gmail-m_-2404559829259103405apple-tab-span"=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0encoded us=
ing a single byte.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=
=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">481<span class=3D"gmail-m_-2=
404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </sp=
an>=C2=A0 =C2=A0 =C2=A0The ICMP code specifiers evaluate to FALSE whenever =
the protocol<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><spa=
n style=3D"font-size:10pt;font-family:Helvetica,sans-serif">482<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0value is not ICMP.<u></u><u></u></span=
></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-f=
amily:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p cl=
ass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-=
serif">[minor] I guess that it should also evaluate FALSE if the ICMP code =
is not relevant for the Type. =C2=A0??<u></u><u></u></span></p></div><div><=
p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,s=
ans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"=
><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">484<span c=
lass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>4.2.9.=C2=A0 Type 9 - TCP flags<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif">486<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0Encoding:&lt;type=
 (1 octet), [op, bitmask]+&gt;<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[minor] The opera=
tor (described below) is called &quot;bitmask&quot;, which is a little conf=
using with the bitmask itself...<u></u><u></u></span></p></div><div><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif">488<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0Bitmask values can be encoded as a 1- =
or 2-byte bitmask.=C2=A0 When a<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">489<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0single byte is speci=
fied, it matches byte 13 of the TCP header<u></u><u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif">490<span class=3D"gmail-m_-2404559829259103405apple-tab-span=
">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0[RFC0793]=
, which contains bits 8 though 15 of the 4th 32-bit word.<u></u><u></u></sp=
an></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font=
-family:Helvetica,sans-serif">491<span class=3D"gmail-m_-240455982925910340=
5apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =
=C2=A0When a 2-byte encoding is used, it matches bytes 12 and 13 of the<u><=
/u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif">492<span class=3D"gmail-m_-2404=
559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 =C2=A0 =C2=A0TCP header with the data offset field having a &quot;do=
n&#39;t care&quot; value.<u></u><u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u=
></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">[minor] Identifying th=
e right octets is more important than counting the number of bytes...=C2=A0=
 The interesting bytes are identified above as &quot;bytes 12 and 13&quot;;=
 however, work from the Transport Area talks about &quot;bytes 13 and 14&qu=
ot;: <a href=3D"https://tools.ietf.org/html/rfc3168#section-6.1" target=3D"=
_blank">https://tools.ietf.org/html/rfc3168#section-6.1</a> =C2=A0It would =
be nice if this was aligned or if any ambiguity could be avoided.<u></u><u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif">[minor] &quot;...with the data offset field having a &quot=
;don&#39;t care&quot; value.&quot; =C2=A0What does that mean?=C2=A0 To me, =
it sounds as if the bitmask values can&#39;t be used to match on the offset=
...is that the right interpretation?=C2=A0 Some clarity would avoid guessin=
g.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D=
"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></spa=
n></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-=
family:Helvetica,sans-serif">494<span class=3D"gmail-m_-2404559829259103405=
apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =
=C2=A0This component evaluates to FALSE for packets that are not TCP<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif">495<span class=3D"gmail-m_-2404559=
829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 =C2=A0 =C2=A0packets.<u></u><u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u=
></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">[major] As mentioned b=
efore, this sentence also seems to mix/confuse the applicability of the com=
ponent (whether it can be used at all) and the application of it to match a=
 specific packet.=C2=A0 In this case, the text seems to simply say that a F=
low Specification which uses Type 9 can only be used to match TCP packets..=
.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span=
></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-f=
amily:Helvetica,sans-serif">[major] Should the Flow Specification evaluate =
to FALSE if this Type is used *and* Type 3 doesn&#39;t include TCP *only* i=
n it&#39;s description?<u></u><u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u><=
/u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D=
"font-size:10pt;font-family:Helvetica,sans-serif">497<span class=3D"gmail-m=
_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
/span>=C2=A0 =C2=A0 =C2=A0This type uses the bitmask operator format, which=
 differs from the<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"=
><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">498<span c=
lass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0numeric operator format in the l=
ower nibble.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><spa=
n style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u=
></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:=
10pt;font-family:Helvetica,sans-serif">[minor] As with the numeric operator=
, I think it would be clearer if it was introduced before the types.<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif">500<span class=3D"gmail-m_-2404559829259103405apple-tab=
-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A00 =C2=A0 1 =
=C2=A0 2 =C2=A0 3 =C2=A0 4 =C2=A0 5 =C2=A0 6 =C2=A0 7<u></u><u></u></span><=
/p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fam=
ily:Helvetica,sans-serif">501<span class=3D"gmail-m_-2404559829259103405app=
le-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 +---+---+--=
-+---+---+---+---+---+<u></u><u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">502<s=
pan class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | e | a | =C2=A0len =C2=A0| 0 | 0 |not| m =
|<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif">503<span class=3D"gmail-m_=
-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </=
span>=C2=A0 +---+---+---+---+---+---+---+---+<u></u><u></u></span></p></div=
><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helv=
etica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"Mso=
Normal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">505=
<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0Bitmask operator<u></u><u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif">[nit] Center the figure...<u></u><u></u></span></p></div><=
div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvet=
ica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">507<s=
pan class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 e, a, len - Most significant nibble: =C2=
=A0(end-of-list bit, AND bit, and<u></u><u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif">508<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0length field), as=
 defined for in the numeric operator format in<u></u><u></u></span></p></di=
v><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Hel=
vetica,sans-serif">509<span class=3D"gmail-m_-2404559829259103405apple-tab-=
span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0Secti=
on 4.2.3.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span s=
tyle=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></=
u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10p=
t;font-family:Helvetica,sans-serif">[] See the questions about the e bit ab=
ove.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><=
p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,s=
ans-serif">...<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><s=
pan style=3D"font-size:10pt;font-family:Helvetica,sans-serif">542<span clas=
s=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>4.2.12.=C2=A0 Type 12 - Fragment<u></u><u></u></span></=
p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fami=
ly:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">544<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0Encoding:&lt;type (1=
 octet), [op, bitmask]+&gt;<u></u><u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
<u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span styl=
e=3D"font-size:10pt;font-family:Helvetica,sans-serif">546<span class=3D"gma=
il-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 =C2=A0 =C2=A0Uses bitmask operator format defined in Sect=
ion 4.2.9.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u><=
/u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif">[major] No, it doesn&#39;t.=C2=A0 The =
new one is defined below.<u></u><u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u=
></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">[clarity] Again, pleas=
e introduce the operators before the types.=C2=A0 In this case, this operat=
or seems to also carry the bitmask name, which can be confusing with the on=
e introduced in =C2=A74.2.9 and the name of the value field...<u></u><u></u=
></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt=
;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><di=
v><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetic=
a,sans-serif">548<span class=3D"gmail-m_-2404559829259103405apple-tab-span"=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A00 =C2=A0 1=
 =C2=A0 2 =C2=A0 3 =C2=A0 4 =C2=A0 5 =C2=A0 6 =C2=A0 7<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif">549<span class=3D"gmail-m_-2404559829259103405ap=
ple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0+---=
+---+---+---+---+---+---+---+<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">550<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0| 0 | 0 | 0 | 0 |LF |FF |Is=
F|DF |<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span styl=
e=3D"font-size:10pt;font-family:Helvetica,sans-serif">551<span class=3D"gma=
il-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 =C2=A0+---+---+---+---+---+---+---+---+<u></u><u></u></sp=
an></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font=
-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p =
class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,san=
s-serif">[nit] Center the figure...<u></u><u></u></span></p></div><div><p c=
lass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans=
-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><s=
pan style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[nit] Please =
add Figure numbers.<u></u><u></u></span></p></div><div><p class=3D"MsoNorma=
l"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=
=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">553<span class=3D"gmail-m_-2=
404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </sp=
an>=C2=A0 =C2=A0 =C2=A0Bitmask values:<u></u><u></u></span></p></div><div><=
p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,s=
ans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"=
><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">555<span c=
lass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bit 7 - Don&#39;t fragme=
nt (DF)<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span sty=
le=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u>=
</span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;=
font-family:Helvetica,sans-serif">557<span class=3D"gmail-m_-24045598292591=
03405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Bit 6 - Is a fragment (IsF)<u></u><u></u></span></p></div=
><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helv=
etica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"Mso=
Normal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">559=
<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bit 5 - First frag=
ment (FF)<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span s=
tyle=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></=
u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10p=
t;font-family:Helvetica,sans-serif">561<span class=3D"gmail-m_-240455982925=
9103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 Bit 4 - Last fragment (LF)<u></u><u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">5=
63<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bit 0-3 - SHOUL=
D be set to 0 on NLRI encoding, and MUST be<u></u><u></u></span></p></div><=
div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvet=
ica,sans-serif">564<span class=3D"gmail-m_-2404559829259103405apple-tab-spa=
n">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
ignored during decoding<u></u><u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u><=
/u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D=
"font-size:10pt;font-family:Helvetica,sans-serif">[major] The operation is =
not specified.=C2=A0 Is this also an (operator,bitmask) pair, or just 8 bit=
s indicating the values?=C2=A0 Can multiple bits be set at the same time?=
=C2=A0 What fields in the IP header do these map to?<u></u><u></u></span></=
p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fami=
ly:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">566<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>4.3.=C2=A0 Examples of Encodings<u></u><=
u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size=
:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></di=
v><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Hel=
vetica,sans-serif">568<span class=3D"gmail-m_-2404559829259103405apple-tab-=
span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 An example of a Fl=
ow Specification encoding for: &quot;all packets to<u></u><u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">569<span class=3D"gmail-m_-2404559829259103405apple=
-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 10.0.1/24 and=
 TCP port 25&quot;.<u></u><u></u></span></p></div><div><p class=3D"MsoNorma=
l"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=
=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">[nit] For clarity, include t=
he whole subnet: s/ 10.0.1/24 / <a href=3D"http://10.0.1.0/24" target=3D"_b=
lank">10.0.1.0/24</a><u></u><u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u=
>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"f=
ont-size:10pt;font-family:Helvetica,sans-serif">[major] Use IP addresses fr=
om the documentation pool [rfc5737] in all examples.<u></u><u></u></span></=
p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fami=
ly:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">571<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0+------------------+=
----------+----------+<u></u><u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">572<s=
pan class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0| destination =C2=A0 =C2=A0 =
=C2=A0| proto =C2=A0 =C2=A0| port =C2=A0 =C2=A0 |<u></u><u></u></span></p><=
/div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:=
Helvetica,sans-serif">573<span class=3D"gmail-m_-2404559829259103405apple-t=
ab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0+-=
-----------------+----------+----------+<u></u><u></u></span></p></div><div=
><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica=
,sans-serif">574<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0| 0x01 18 0=
a 00 01 | 03 81 06 | 04 81 19 |<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">575<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0+------------------+=
----------+----------+<u></u><u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></=
u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif">[minor] It would be nice i=
f the examples show the the whole Flow-spec NLRI, and not just the NLRI val=
ue.=C2=A0 Also, it would be great if one of the examples required more than=
 240 bytes.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif">577<span class=3D"gmail-m_-2404559829=
259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0=
 Decode for protocol:<u></u><u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u=
>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"f=
ont-size:10pt;font-family:Helvetica,sans-serif">[minor] Please show the dec=
odes for all the fields.<u></u><u></u></span></p></div><div><p class=3D"Mso=
Normal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u>=
</u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">579<span class=3D"gmai=
l-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 =C2=A0 =C2=A0+-------+----------+------------------------=
------+<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span sty=
le=3D"font-size:10pt;font-family:Helvetica,sans-serif">580<span class=3D"gm=
ail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 =C2=A0 =C2=A0| Value | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<u></u><u></u></span></p></div><div><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif">581<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0+-------+--------=
--+------------------------------+<u></u><u></u></span></p></div><div><p cl=
ass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-=
serif">582<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0| =C2=A00x03 | ty=
pe =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<u></u><u></u></span></p><=
/div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:=
Helvetica,sans-serif">583<span class=3D"gmail-m_-2404559829259103405apple-t=
ab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0| =
=C2=A00x81 | operator | end-of-list, value size=3D1, =3D |<u></u><u></u></s=
pan></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fon=
t-family:Helvetica,sans-serif">584<span class=3D"gmail-m_-24045598292591034=
05apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0=
 =C2=A0| =C2=A00x06 | value =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<=
u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">585<span class=3D"gmail-m_-2=
404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </sp=
an>=C2=A0 =C2=A0 =C2=A0+-------+----------+------------------------------+<=
u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span><=
/p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fam=
ily:Helvetica,sans-serif">[minor] For completion, indicate that Protocol 6 =
is TCP.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span sty=
le=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u>=
</span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;=
font-family:Helvetica,sans-serif">587<span class=3D"gmail-m_-24045598292591=
03405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 An =
example of a Flow Specification encoding for: &quot;all packets to<u></u><u=
></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:=
10pt;font-family:Helvetica,sans-serif">588<span class=3D"gmail-m_-240455982=
9259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 10.1.1/24 from 192/8 and port {range [137, 139] or 8080}&quot;.<u></u><=
u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size=
:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></di=
v><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Hel=
vetica,sans-serif">[] Ah...NETBIOS...<u></u><u></u></span></p></div><div><p=
 class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sa=
ns-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal">=
<span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[nit] It mi=
ght be a good idea to number the examples...<u></u><u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u><=
/u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D=
"font-size:10pt;font-family:Helvetica,sans-serif">...<u></u><u></u></span><=
/p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fam=
ily:Helvetica,sans-serif">612<span class=3D"gmail-m_-2404559829259103405app=
le-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>5.=C2=A0 Traffic F=
iltering<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span st=
yle=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u=
></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt=
;font-family:Helvetica,sans-serif">614<span class=3D"gmail-m_-2404559829259=
103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Tr=
affic filtering policies have been traditionally considered to be<u></u><u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif">615<span class=3D"gmail-m_-2404559829=
259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0=
 relatively static.=C2=A0 Limitations of the static mechanisms caused this<=
u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">616<span class=3D"gmail-m_-2=
404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </sp=
an>=C2=A0 mechanism to be designed for the three new applications of traffi=
c<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif">617<span class=3D"gmail-m_=
-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </=
span>=C2=A0 filtering (prevention of traffic-based, denial-of-service (DOS)=
<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"f=
ont-size:10pt;font-family:Helvetica,sans-serif">618<span class=3D"gmail-m_-=
2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </s=
pan>=C2=A0 attacks, traffic filtering in the context of BGP/MPLS VPN servic=
e,<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D=
"font-size:10pt;font-family:Helvetica,sans-serif">619<span class=3D"gmail-m=
_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
/span>=C2=A0 and centralized traffic control for SDN/NFV networks) requires=
<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"f=
ont-size:10pt;font-family:Helvetica,sans-serif">620<span class=3D"gmail-m_-=
2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </s=
pan>=C2=A0 coordination among service providers and/or coordination among t=
he AS<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">621<span class=3D"gmai=
l-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 within a service provider.=C2=A0 Section 9 has details on=
 the limitation<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><=
span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">622<span cla=
ss=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 of previous mechanisms and why BGP Flow Specific=
ation provides a<u></u><u></u></span></p></div><div><p class=3D"MsoNormal">=
<span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">623<span cl=
ass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 solution for to prevent DOS and aid BGP/MPLS VPN=
 filtering rules.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"=
><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=
=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif">[minor] This sentence, without =
the parenthesis, doesn&#39;t seem to make sense: &quot;Limitations of the s=
tatic mechanisms caused this mechanism to be designed for the three new app=
lications of traffic filtering requires coordination among service provider=
s and/or coordination among the AS within a service provider.&quot;<u></u><=
u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size=
:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></di=
v><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Hel=
vetica,sans-serif">[nit] s/solution for to prevent/solution to prevent<u></=
u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-s=
ize:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p><=
/div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:=
Helvetica,sans-serif">625<span class=3D"gmail-m_-2404559829259103405apple-t=
ab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 This Flow Speci=
fication NLRI defined above to convey information<u></u><u></u></span></p><=
/div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:=
Helvetica,sans-serif">626<span class=3D"gmail-m_-2404559829259103405apple-t=
ab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 about traffic f=
iltering rules for traffic that should be discarded or<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif">627<span class=3D"gmail-m_-2404559829259103405ap=
ple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 handled in=
 manner specified by a set of pre-defined actions (which<u></u><u></u></spa=
n></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-=
family:Helvetica,sans-serif">628<span class=3D"gmail-m_-2404559829259103405=
apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 are defi=
ned in BGP Extended Communities).=C2=A0 This mechanism is<u></u><u></u></sp=
an></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font=
-family:Helvetica,sans-serif">629<span class=3D"gmail-m_-240455982925910340=
5apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 primari=
ly designed to allow an upstream autonomous system to perform<u></u><u></u>=
</span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;=
font-family:Helvetica,sans-serif">630<span class=3D"gmail-m_-24045598292591=
03405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 inb=
ound filtering in their ingress routers of traffic that a given<u></u><u></=
u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10p=
t;font-family:Helvetica,sans-serif">631<span class=3D"gmail-m_-240455982925=
9103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 d=
ownstream AS wishes to drop.<u></u><u></u></span></p></div><div><p class=3D=
"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"=
><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span sty=
le=3D"font-size:10pt;font-family:Helvetica,sans-serif">[nit] s/This Flow Sp=
ecification NLRI/The Flow Specification NLRI<u></u><u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u><=
/u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D=
"font-size:10pt;font-family:Helvetica,sans-serif">...<u></u><u></u></span><=
/p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fam=
ily:Helvetica,sans-serif">645<span class=3D"gmail-m_-2404559829259103405app=
le-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Distributio=
n of the IPv4 Flow Specification is described in<u></u><u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif">646<span class=3D"gmail-m_-2404559829259103405apple-ta=
b-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Section 6, and d=
istibution of BGP/MPLS traffic Flow Specification is<u></u><u></u></span></=
p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fami=
ly:Helvetica,sans-serif">647<span class=3D"gmail-m_-2404559829259103405appl=
e-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 described in=
 Section 8.=C2=A0 The traffic filtering actions are described<u></u><u></u>=
</span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;=
font-family:Helvetica,sans-serif">648<span class=3D"gmail-m_-24045598292591=
03405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 in =
Section 7.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u><=
/u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif">[minor] Section 6 talks about validati=
on, not distribution.<u></u><u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u=
>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"f=
ont-size:10pt;font-family:Helvetica,sans-serif">[nit] s/distibution/distrib=
ution<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><=
p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,s=
ans-serif">650<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>5.1.=C2=A0 Ordering of Traffic =
Filtering Rules<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><=
span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=
=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif">652<span class=3D"gmail-m_-2404=
559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 With traffic filtering rules, more than one rule may match a<u></u><=
u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size=
:10pt;font-family:Helvetica,sans-serif">653<span class=3D"gmail-m_-24045598=
29259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 particular traffic flow.=C2=A0 Thus, it is necessary to define the orde=
r<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif">654<span class=3D"gmail-m_=
-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </=
span>=C2=A0 at which rules get matched and applied to a particular traffic =
flow.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">655<span class=3D"gmai=
l-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 This ordering function must be such that it must not depe=
nd on the<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span s=
tyle=3D"font-size:10pt;font-family:Helvetica,sans-serif">656<span class=3D"=
gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 </span>=C2=A0 arrival order of the Flow Specification&#39;s rules an=
d must be<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span s=
tyle=3D"font-size:10pt;font-family:Helvetica,sans-serif">657<span class=3D"=
gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 </span>=C2=A0 consistent in the network.<u></u><u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[=
clarification] Are &quot;traffic filtering rules&quot; the same thing as &q=
uot;traffic filtering actions&quot;, or are they more like &quot;Flow Speci=
fication&#39;s rules&quot;? =C2=A0 You also mention (below) &quot;Flow Spec=
ification rules&quot; in the context of ordering, so my guess is that &quot=
;traffic filtering rules&quot; and &quot;Flow Specification rules&quot; are=
 equivalent...are they? =C2=A0 In my opinion, there are too many ways to re=
fer to the same, or very similar things.=C2=A0 Please take advantage of =C2=
=A72 to help the reader, or at least simplify the terminology.<u></u><u></u=
></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt=
;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><di=
v><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetic=
a,sans-serif">659<span class=3D"gmail-m_-2404559829259103405apple-tab-span"=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 The relative order of t=
wo Flow Specification rules is determined by<u></u><u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif">660<span class=3D"gmail-m_-2404559829259103405apple-tab-sp=
an">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 comparing their resp=
ective components.=C2=A0 The algorithm starts by<u></u><u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif">661<span class=3D"gmail-m_-2404559829259103405apple-ta=
b-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 comparing the le=
ft-most components of the rules.=C2=A0 If the types<u></u><u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">662<span class=3D"gmail-m_-2404559829259103405apple=
-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 differ, the r=
ule with lowest numeric type value has higher precedence<u></u><u></u></spa=
n></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-=
family:Helvetica,sans-serif">663<span class=3D"gmail-m_-2404559829259103405=
apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 (and thu=
s will match before) than the rule that doesn&#39;t contain that<u></u><u><=
/u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif">664<span class=3D"gmail-m_-24045598292=
59103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =
component type.=C2=A0 If the component types are the same, then a type-<u><=
/u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif">665<span class=3D"gmail-m_-2404=
559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 specific comparison is performed (see below) if the types are equal<=
u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">666<span class=3D"gmail-m_-2=
404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </sp=
an>=C2=A0 the algorithm continues with the next component.<u></u><u></u></s=
pan></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fon=
t-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p=
 class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sa=
ns-serif">[minor] To be clear: the comparison is done between the component=
 types defined in =C2=A74.2...and &quot;left-most&quot; means &quot;first&q=
uot;...<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span sty=
le=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u>=
</span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;=
font-family:Helvetica,sans-serif">668<span class=3D"gmail-m_-24045598292591=
03405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 For=
 IP prefix values (IP destination or source prefix): If the<u></u><u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">669<span class=3D"gmail-m_-2404559829259103=
405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 prefi=
xes overlap, the one with the longer prefix-length has higher<u></u><u></u>=
</span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;=
font-family:Helvetica,sans-serif">670<span class=3D"gmail-m_-24045598292591=
03405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 pre=
cedence.=C2=A0 If they do not overlap the one with the lowest IP value<u></=
u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-s=
ize:10pt;font-family:Helvetica,sans-serif">671<span class=3D"gmail-m_-24045=
59829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 has higher precedence.<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[minor] I need yo=
u to be more specific when talking about &quot;overlap&quot;.=C2=A0 Clearly=
 <a href=3D"http://10.1.0.0/16" target=3D"_blank">10.1.0.0/16</a> and <a hr=
ef=3D"http://10.1.1.0/24" target=3D"_blank">10.1.1.0/24</a> overlap, then t=
he higher precedence would be for the /24, right?=C2=A0 Do <a href=3D"http:=
//130.0.0.0/16" target=3D"_blank">130.0.0.0/16</a> and <a href=3D"http://15=
0.1.1.0/24" target=3D"_blank">150.1.1.0/24</a> overlap (they have the first=
 3 bits in common)? =C2=A0rfc5575 talks about a &quot;common prefix&quot;, =
which is not completely clear either, but it could mean at least what is co=
vered by the shortest mask (which would be my guess)...<u></u><u></u></span=
></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-f=
amily:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p cl=
ass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-=
serif">[minor] &quot;prefix-length&quot; is used here, but &quot;prefix len=
gth&quot; is used in =C2=A74.2.1.=C2=A0 Please be consistent.<u></u><u></u>=
</span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;=
font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div=
><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica=
,sans-serif">[minor] The &quot;-&quot; confused me a little.=C2=A0 By &quot=
;For IP prefix values...the longer prefix-length&quot; do you mean the valu=
e of the prefix length, or the length of the prefix field? =C2=A0rfc5575 ta=
lks about &quot;more specific&quot;, which may be easier to understand in t=
his case...<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif">673<span class=3D"gmail-m_-2404559829=
259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0=
 For all other component types, unless otherwise specified, the<u></u><u></=
u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10p=
t;font-family:Helvetica,sans-serif">674<span class=3D"gmail-m_-240455982925=
9103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 c=
omparison is performed by comparing the component data as a binary<u></u><u=
></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:=
10pt;font-family:Helvetica,sans-serif">675<span class=3D"gmail-m_-240455982=
9259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 string using the memcmp() function as defined by the ISO C standard.<u>=
</u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font=
-size:10pt;font-family:Helvetica,sans-serif">676<span class=3D"gmail-m_-240=
4559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span=
>=C2=A0 For strings with equal lengths the lowest string (memcmp) has highe=
r<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif">677<span class=3D"gmail-m_=
-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </=
span>=C2=A0 precedence.=C2=A0 For strings of different lengths, the common =
prefix is<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span s=
tyle=3D"font-size:10pt;font-family:Helvetica,sans-serif">678<span class=3D"=
gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 </span>=C2=A0 compared.=C2=A0 If the common prefix is not equal the =
string with the<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><=
span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">679<span cla=
ss=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 lowest prefix has higher precedence.=C2=A0 If th=
e common prefix is equal,<u></u><u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">68=
0<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 the longest string is considered to hav=
e higher precedence than the<u></u><u></u></span></p></div><div><p class=3D=
"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"=
>681<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 shorter one.<u></u><u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">[major] Please add a Normative reference for &quot;the memcmp() functio=
n as defined by the ISO C standard&quot;.<u></u><u></u></span></p></div><di=
v><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetic=
a,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNorm=
al"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[minor]=
 What is the &quot;common prefix&quot;?=C2=A0 Is it the bits that correspon=
d to the shorter length?=C2=A0 In this case I think that using &quot;prefix=
&quot; may be confusing.<u></u><u></u></span></p></div><div><p class=3D"Mso=
Normal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u>=
</u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">[minor] If my interpre=
tation is correct, given a common set of rules, the longer the Flow Specifi=
cation the most preferred, right?=C2=A0 Using one of the examples in =C2=A7=
4.3, &quot;all packets to 10.1.1/24 from 192/8 and port {range [137, 139] o=
r 8080}&quot; would be preferred over &quot;all packets to 10.1.1/24 from 1=
92/8 and port range [137, 139]&quot;...because when comparing the common pr=
efix for the port, the second rule would have the e bit set, resulting in a=
 higher prefix, right?<u></u><u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></=
u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif">[major] I would like to se=
e some discussion about the management of Flow Specifications and their adv=
ertisement order from an operational point of view.=C2=A0 In the case above=
, if an operator uses the first rule (only), but later decides to allow web=
 traffic and the system advertises the second rule, it won&#39;t take effec=
t until the first one is withdrawn.=C2=A0 This type of operational consider=
ation is not explained in this document.<u></u><u></u></span></p></div><div=
><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica=
,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNorma=
l"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">683<span=
 class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 The code below shows a Python3 implementation=
 of the comparison<u></u><u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">684<span =
class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 algorithm.=C2=A0 The full code was tested wit=
h Python 3.6.3 and can be<u></u><u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">68=
5<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 obtained at <a href=3D"https://github.c=
om/stoffi92/flowspec-cmp" target=3D"_blank">https://github.com/stoffi92/flo=
wspec-cmp</a> [1].<u></u><u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=
=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">[minor] I would prefer to se=
e the code in an Appendix.<u></u><u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><=
u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">[major] We need to inc=
lude template text about the licensing in the Code Component below.=C2=A0 P=
lease take a look at the IETF Trust Legal Provisions and add the appropriat=
e text: <a href=3D"https://trustee.ietf.org/license-info/IETF-TLP-5.pdf" ta=
rget=3D"_blank">https://trustee.ietf.org/license-info/IETF-TLP-5.pdf</a><u>=
</u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font=
-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">687<span class=3D"gmail-m_-2404559829259103405apple=
-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 &lt;CODE BEGI=
NS&gt;<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span styl=
e=3D"font-size:10pt;font-family:Helvetica,sans-serif">688<span class=3D"gma=
il-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 import itertools<u></u><u></u></span></p></div><div><p cl=
ass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-=
serif">689<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 import ipaddress<u></u><u></u>=
</span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;=
font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div=
><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica=
,sans-serif">691<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 def flow_rule_cmp(a, b):=
<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"f=
ont-size:10pt;font-family:Helvetica,sans-serif">692<span class=3D"gmail-m_-=
2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </s=
pan>=C2=A0 =C2=A0 =C2=A0 for comp_a, comp_b in itertools.zip_longest(a.comp=
onents,<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span sty=
le=3D"font-size:10pt;font-family:Helvetica,sans-serif">693<span class=3D"gm=
ail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0b.components):<u></u><u></u></span></p></div><div><=
p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,s=
ans-serif">694<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 # If a component type does not exist in one rule<u></u><u></u></span></=
p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fami=
ly:Helvetica,sans-serif">695<span class=3D"gmail-m_-2404559829259103405appl=
e-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 # this rule has lower precedence<u></u><u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif">696<span class=3D"gmail-m_-2404559829259103405apple-=
tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 if not comp_a:<u></u><u></u></span></p></div><div><p class=3D=
"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"=
>697<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 return B_HAS_PRECEDENCE<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">698<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if no=
t comp_b:<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span s=
tyle=3D"font-size:10pt;font-family:Helvetica,sans-serif">699<span class=3D"=
gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return A_HAS=
_PRECEDENCE<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif">[] What if the component is not in ei=
ther?=C2=A0 The lines above look like the wrong outcome could be obtained.=
=C2=A0 Disclaimer: I don&#39;t know Python...<u></u><u></u></span></p></div=
><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helv=
etica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"Mso=
Normal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u>=
</u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">...<u></u><u></u></spa=
n></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-=
family:Helvetica,sans-serif">742<span class=3D"gmail-m_-2404559829259103405=
apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>6.=C2=A0 Valida=
tion Procedure<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><s=
pan style=3D"font-size:10pt;font-family:Helvetica,sans-serif">...<u></u><u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif">757<span class=3D"gmail-m_-2404559829=
259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0=
 The concept can be extended, in the case of Flow Specification NLRI,<u></u=
><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-si=
ze:10pt;font-family:Helvetica,sans-serif">758<span class=3D"gmail-m_-240455=
9829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 to allow other validation procedures.<u></u><u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[nit=
] s/of Flow Specification NLRI/of the Flow Specification NLRI<u></u><u></u>=
</span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;=
font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div=
><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica=
,sans-serif">760<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 A Flow Specification NLR=
I must be validated such that it is<u></u><u></u></span></p></div><div><p c=
lass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans=
-serif">761<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 considered feasible if and =
only if all of the below is true:<u></u><u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><spa=
n style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[major] There i=
s no Normative language above, but I think there is a contradiction of sort=
s with the new text below (&quot;Rule a) MAY be relaxed...&quot;).=C2=A0 Th=
e introductory text to the rules is &quot;must be...considered feasible if =
and only if all of the below is true&quot;, which sounds very strict and sp=
ecific...but then the Normative exception comes in (&quot;MAY be relaxed...=
rules b) and c)...MUST be disregarded&quot;) saying that it doesn&#39;t mat=
ter.=C2=A0 Please reword...perhaps something like: &quot;If a destination i=
s present...a Flow Specification MUST be validated this way...otherwise...&=
quot;<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">763<span class=3D"gmail-m_-2404559829259103=
405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=
=A0 =C2=A0a) A destination prefix component is embedded in the Flow<u></u><=
u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size=
:10pt;font-family:Helvetica,sans-serif">764<span class=3D"gmail-m_-24045598=
29259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 =C2=A0 =C2=A0Specification.<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif">766<span class=3D=
"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0b) The originator of the Flow Specificati=
on matches the originator<u></u><u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">76=
7<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0of the best-match unicast =
route for the destination prefix<u></u><u></u></span></p></div><div><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif">768<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0embedded in the F=
low Specification.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=
=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">[major] What is the &quot;be=
st-match unicast route&quot;?=C2=A0 Please be specific.<u></u><u></u></span=
></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-f=
amily:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p cl=
ass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-=
serif">770<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0c) There are no m=
ore specific unicast routes, when compared with<u></u><u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif">771<span class=3D"gmail-m_-2404559829259103405apple-tab=
-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0the =
flow destination prefix, that has been received from a<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif">772<span class=3D"gmail-m_-2404559829259103405ap=
ple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=
=A0different neighboring AS than the best-match unicast route, which<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif">773<span class=3D"gmail-m_-2404559=
829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 =C2=A0 =C2=A0has been determined in rule b).<u></u><u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
775<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Rule a) MAY be relaxed by configurat=
ion, permitting Flow<u></u><u></u></span></p></div><div><p class=3D"MsoNorm=
al"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">776<spa=
n class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Specifications that include no destination=
 prefix component.=C2=A0 If such<u></u><u></u></span></p></div><div><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif">777<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 is the case, rules b) and c) a=
re moot and MUST be disregarded.<u></u><u></u></span></p></div><div><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[major] This act=
ion opens the door to all sorts of things.=C2=A0 I note that the Security C=
onsiderations section simply mentions it without going into more details.<u=
></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fon=
t-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></=
p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fami=
ly:Helvetica,sans-serif">779<span class=3D"gmail-m_-2404559829259103405appl=
e-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 By originato=
r of a BGP route, we mean either the BGP originator path<u></u><u></u></spa=
n></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-=
family:Helvetica,sans-serif">780<span class=3D"gmail-m_-2404559829259103405=
apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 attribut=
e, as used by route reflection, or the transport address of<u></u><u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">781<span class=3D"gmail-m_-2404559829259103=
405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 the B=
GP peer, if this path attribute is not present.<u></u><u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[=
major] s/BGP originator path attribute, as used by route reflection/address=
 of the originator in the ORIGINATOR_ID Attribute [RFC4456] =C2=A0 The refe=
rence to rfc4456 should be Normative.<u></u><u></u></span></p></div><div><p=
 class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sa=
ns-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal">=
<span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[minor] rfc=
4271 doesn&#39;t talk about a &quot;transport addresses&quot;.=C2=A0 Instea=
d, it talks about the &quot;source IP address&quot;.=C2=A0 I know it is the=
 same thing, but please be consistent.<u></u><u></u></span></p></div><div><=
p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,s=
ans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"=
><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">783<span c=
lass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 BGP implementations MUST also enforce that th=
e AS_PATH attribute of a<u></u><u></u></span></p></div><div><p class=3D"Mso=
Normal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">784=
<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 route received via the External Border =
Gateway Protocol (eBGP)<u></u><u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">785<=
span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 contains the neighboring AS in the left=
-most position of the AS_PATH<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">786<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 attribute.=C2=A0 While this rule =
is optional in the BGP specification, it<u></u><u></u></span></p></div><div=
><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica=
,sans-serif">787<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 becomes necessary to enf=
orce it for security reasons.<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[major] Is this r=
equirement only for the Flow Specification AFI/SAFI pairs, or for all addre=
ss families (IPv4 in the case of this document)?=C2=A0 Why?<u></u><u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><=
p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,s=
ans-serif">[major] [Assuming that the answer to the last question is: &quot=
;Yes, for all AFs&quot;...] Should all the border routers in the AS enforce=
 the first ASN, or is the requirement only for routers receiving Flow Speci=
fications?<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u><=
/u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif">[major] In the case of receiving Flow =
Specifications from a neighbor in an IXP, it may not be possible to enforce=
 the rule above if a &quot;transparent ASN&quot; is being used.=C2=A0 Pleas=
e include some text/guidance about that type of case.=C2=A0 Include it eith=
er here or in the Security Considerations.<u></u><u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[nit] =
The mention of security above makes me want to see related considerations i=
n =C2=A713/14.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><s=
pan style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif">789<span class=3D"gmail-m_-2404559=
829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 The best-match unicast route may change over the time independently<u><=
/u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif">790<span class=3D"gmail-m_-2404=
559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 of the Flow Specification NLRI.=C2=A0 Therefore, a revalidation of t=
he<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D=
"font-size:10pt;font-family:Helvetica,sans-serif">791<span class=3D"gmail-m=
_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
/span>=C2=A0 Flow Specification NLRI MUST be performed whenever unicast rou=
tes<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">792<span class=3D"gmai=
l-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 change.=C2=A0 Revalidation is defined as retesting that c=
lause a and<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif">793<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 clause b above are true.<u></u><u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
[major] What about the case where a destination prefix is not included?=C2=
=A0 Besides enforcing the first AS, there isn&#39;t any verification specif=
ied.=C2=A0 What are the consideration about using that option?<u></u><u></u=
></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt=
;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><di=
v><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetic=
a,sans-serif">795<span class=3D"gmail-m_-2404559829259103405apple-tab-span"=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Explanation:<u></u><u><=
/u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><=
div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvet=
ica,sans-serif">797<span class=3D"gmail-m_-2404559829259103405apple-tab-spa=
n">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 The underlying concep=
t is that the neighboring AS that advertises the<u></u><u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif">798<span class=3D"gmail-m_-2404559829259103405apple-ta=
b-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 best unicast rou=
te for a destination is allowed to advertise flow-<u></u><u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif">799<span class=3D"gmail-m_-2404559829259103405apple-=
tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 spec informati=
on that conveys a more or equally specific destination<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif">800<span class=3D"gmail-m_-2404559829259103405ap=
ple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 prefix.=C2=
=A0 Thus, as long as there are no more specific unicast routes,<u></u><u></=
u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10p=
t;font-family:Helvetica,sans-serif">801<span class=3D"gmail-m_-240455982925=
9103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 r=
eceived from a different neighboring AS, which would be affected by<u></u><=
u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size=
:10pt;font-family:Helvetica,sans-serif">802<span class=3D"gmail-m_-24045598=
29259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 that filtering rule.<u></u><u></u></span></p></div><div><p class=3D"Mso=
Normal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u>=
</u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">804<span class=3D"gmai=
l-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 The neighboring AS is the immediate destination of the tr=
affic<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">805<span class=3D"gmai=
l-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 described by the Flow Specification.=C2=A0 If it requests=
 these flows to<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><=
span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">806<span cla=
ss=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 be dropped, that request can be honored without =
concern that it<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><=
span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">807<span cla=
ss=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 represents a denial of service in itself.=C2=A0 =
Supposedly, the traffic is<u></u><u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">8=
08<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 being dropped by the downstream auto=
nomous system, and there is no<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">809<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 added value in carrying the traff=
ic to it.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span s=
tyle=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></=
u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10p=
t;font-family:Helvetica,sans-serif">[major] A rogue router may request the =
traffic to be dropped.=C2=A0 While the local AS is simply reacting to the n=
eighbor&#39;s request, the action can still result in a DoS.=C2=A0 I would =
like to see rogue router scenarios reflected in the Security Considerations=
.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span=
></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-f=
amily:Helvetica,sans-serif">[major] All this section seems to assume that f=
lows are controlled (dropped/redirected) between ASes...but the actions can=
 also be triggered from inside an AS.=C2=A0 What are the considerations in =
that case?=C2=A0 Why isn&#39;t iBGP explicitly considered?<u></u><u></u></s=
pan></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fon=
t-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p=
 class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sa=
ns-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal">=
<span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">811<span cl=
ass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>7.=C2=A0 Traffic Filtering Actions<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif">...<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">820<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Implementations SHOULD provide me=
chanisms that map an arbitrary BGP<u></u><u></u></span></p></div><div><p cl=
ass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-=
serif">821<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 community value (normal or ext=
ended) to filtering actions that<u></u><u></u></span></p></div><div><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif">822<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 require different mappings in =
different systems in the network.=C2=A0 For<u></u><u></u></span></p></div><=
div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvet=
ica,sans-serif">823<span class=3D"gmail-m_-2404559829259103405apple-tab-spa=
n">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 instance, providing p=
ackets with a worse-than-best-effort, per-hop<u></u><u></u></span></p></div=
><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helv=
etica,sans-serif">824<span class=3D"gmail-m_-2404559829259103405apple-tab-s=
pan">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 behavior is a funct=
ionality that is likely to be implemented<u></u><u></u></span></p></div><di=
v><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetic=
a,sans-serif">825<span class=3D"gmail-m_-2404559829259103405apple-tab-span"=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 differently in differen=
t systems and for which no standard behavior<u></u><u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif">826<span class=3D"gmail-m_-2404559829259103405apple-tab-sp=
an">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 is currently known.=
=C2=A0 Rather than attempting to define it here, this<u></u><u></u></span><=
/p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fam=
ily:Helvetica,sans-serif">827<span class=3D"gmail-m_-2404559829259103405app=
le-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 can be acco=
mplished by mapping a user-defined community value to<u></u><u></u></span><=
/p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fam=
ily:Helvetica,sans-serif">828<span class=3D"gmail-m_-2404559829259103405app=
le-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 platform-/n=
etwork-specific behavior via user configuration.<u></u><u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
[major] While this paragraph sounds technically correct, I think it doesn&#=
39;t belong in this document because it (randomly) talks about a different,=
 yet tangentially related, topic.=C2=A0 Also, it basically says &quot;SHOUL=
D provide a mechanism to take arbitrary actions...which are not defined her=
e&quot;, so it is not complete from a Normative point of view.=C2=A0 I woul=
d prefer if we took this paragraph out.<u></u><u></u></span></p></div><div>=
<p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,=
sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">830<span =
class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 The default action for a traffic filtering Fl=
ow Specification is to<u></u><u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">831<s=
pan class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 accept IP traffic that matches that partic=
ular rule.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u><=
/u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif">833<span class=3D"gmail-m_-24045598292=
59103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =
This document defines the following extended communities values shown<u></u=
><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-si=
ze:10pt;font-family:Helvetica,sans-serif">834<span class=3D"gmail-m_-240455=
9829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 in Table 2 in the form 0x8xnn where nn indicates the sub-type.<u></u=
><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-si=
ze:10pt;font-family:Helvetica,sans-serif">835<span class=3D"gmail-m_-240455=
9829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 Encodings for these extended communities are described below.<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif">[minor] The &quot;0x8xnn&quot; format doesn&#39;t expla=
in what x indicates.=C2=A0 Perhaps it would be better for the format to mat=
ch the IANA section and include, for example, 0xttss for type and sub-type.=
..with the corresponding change in Table 2.<u></u><u></u></span></p></div><=
div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvet=
ica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">837<s=
pan class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 +-----------+----------------------+------=
--------------------------+<u></u><u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
838<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | community | action =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | encoding =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<u></u><u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif">839<span class=3D"gmail-m_-2404559829259103405apple-=
tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 +-----------+-=
---------------------+--------------------------------+<u></u><u></u></span=
></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-f=
amily:Helvetica,sans-serif">840<span class=3D"gmail-m_-2404559829259103405a=
pple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | 0x8006 =
=C2=A0 =C2=A0| traffic-rate-bytes =C2=A0 | 2-byte ASN, 4-byte float =C2=A0 =
=C2=A0 =C2=A0 |<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><=
span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">841<span cla=
ss=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 | TBD =C2=A0 =C2=A0 =C2=A0 | traffic-rate-packet=
s | 2-byte ASN, 4-byte float =C2=A0 =C2=A0 =C2=A0 |<u></u><u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">842<span class=3D"gmail-m_-2404559829259103405apple=
-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | 0x8007 =C2=
=A0 =C2=A0| traffic-action =C2=A0 =C2=A0 =C2=A0 | bitmask =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<u></u><=
u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size=
:10pt;font-family:Helvetica,sans-serif">843<span class=3D"gmail-m_-24045598=
29259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 | 0x8008 =C2=A0 =C2=A0| rt-redirect AS-2byte | 2-octet AS, 4-octet valu=
e =C2=A0 =C2=A0 =C2=A0|<u></u><u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">844<=
span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | 0x8108 =C2=A0 =C2=A0| rt-redirect IPv=
4 =C2=A0 =C2=A0 | 4-octet IPv4 addres, 2-octet =C2=A0 |<u></u><u></u></span=
></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-f=
amily:Helvetica,sans-serif">845<span class=3D"gmail-m_-2404559829259103405a=
pple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| value =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<u></u><u></u></spa=
n></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-=
family:Helvetica,sans-serif">846<span class=3D"gmail-m_-2404559829259103405=
apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | 0x8208=
 =C2=A0 =C2=A0| rt-redirect AS-4byte | 4-octet AS, 2-octet value =C2=A0 =C2=
=A0 =C2=A0|<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif">847<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 | 0x8009 =C2=A0 =C2=A0| traffic-marking =C2=A0 =C2=
=A0 =C2=A0| DSCP value =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 |<u></u><u></u></span></p></div><div><p class=3D"MsoNorma=
l"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">848<span=
 class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 +-----------+----------------------+---------=
-----------------------+<u></u><u></u></span></p></div><div><p class=3D"Mso=
Normal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u>=
</u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">850<span class=3D"gmai=
l-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Table 2: Traffi=
c Action Extended Communities<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[minor] The Table=
 contains terms that have not been defined...=C2=A0 It would be ideal if th=
e Table contained a forward reference to the section where each action is d=
iscussed....or at least a general statement about the details in the upcomi=
ng sub-sections...<u></u><u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=
=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">852<span class=3D"gmail-m_-2=
404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </sp=
an>=C2=A0 Some traffic action communities may interfere with each other.<u>=
</u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font=
-size:10pt;font-family:Helvetica,sans-serif">853<span class=3D"gmail-m_-240=
4559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span=
>=C2=A0 Section 7.6 of this specification provides general considerations o=
n<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif">854<span class=3D"gmail-m_=
-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </=
span>=C2=A0 such traffic action interference.=C2=A0 Any additional definiti=
on of a<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span sty=
le=3D"font-size:10pt;font-family:Helvetica,sans-serif">855<span class=3D"gm=
ail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 traffic actions specified by additional standards documen=
ts or vendor<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><spa=
n style=3D"font-size:10pt;font-family:Helvetica,sans-serif">856<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 documents MUST specify if the traffic action intera=
cts with an<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif">857<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 existing traffic actions, and provide error handlin=
g per [RFC7606].<u></u><u></u></span></p></div><div><p class=3D"MsoNormal">=
<span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=
=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif">[nit] s/definition of a traffic=
 actions/definition of traffic actions<u></u><u></u></span></p></div><div><=
p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,s=
ans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"=
><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[major] &q=
uot;Any additional definition of a traffic actions specified by additional =
standards documents or vendor documents MUST specify...&quot; =C2=A0We real=
ly can&#39;t mandate what vendor documents say. =C2=A0 s/additional definit=
ion of a traffic actions specified by additional standards documents or ven=
dor documents MUST specify/additional definition of a traffic action MUST s=
pecify<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span styl=
e=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u><=
/span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;f=
ont-family:Helvetica,sans-serif">[major] &quot;MUST specify if the traffic =
action interacts with an existing traffic actions&quot; =C2=A0I think you m=
eant something like: &quot;MUST specify the action to take if...&quot;<u></=
u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-s=
ize:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p><=
/div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:=
Helvetica,sans-serif">[major] &quot;Any additional definition of a traffic =
actions...MUST...provide error handling per [RFC7606].&quot; =C2=A0rfc7606 =
already indicates what to do about a malformed Extended Community attribute=
, which is how other actions would presumably be specified. =C2=A0 rfc7606 =
only mandates error specifications for new attributes.=C2=A0 What are your =
expectations here?<u></u><u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=
=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">859<span class=3D"gmail-m_-2=
404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </sp=
an>=C2=A0 Multiple traffic actions may be present for a single NLRI.=C2=A0 =
The<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">860<span class=3D"gmai=
l-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 traffic actions are processed in ascending order of the s=
ub-type<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span sty=
le=3D"font-size:10pt;font-family:Helvetica,sans-serif">861<span class=3D"gm=
ail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 found in the BGP Extended Communities.=C2=A0 If not all o=
f them can be<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><sp=
an style=3D"font-size:10pt;font-family:Helvetica,sans-serif">862<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 processed the filter SHALL NOT be applied at all (f=
or example: if for<u></u><u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">863<span =
class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 a given flow there are the action communities=
 rate-limit-bytes and<u></u><u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">864<sp=
an class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 traffic-marking attached, and the plattfor=
m does not support one of<u></u><u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">86=
5<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 them also the other shall not be applie=
d for that flow).<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"=
><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=
=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif">[minor] This paragraph is relat=
ed to =C2=A77.6 (Considerations on Traffic Action Interference).=C2=A0 Cons=
ider putting all the related information together.<u></u><u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">[major] &quot;traffic actions are processed in ascending order of the s=
ub-type&quot; =C2=A0Several of the communities have the same sub-type; if m=
ore than one is present, which one should be processed first?<u></u><u></u>=
</span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;=
font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div=
><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica=
,sans-serif">[major] What should a receiver do if multiple of the same comm=
unity (type and sub-type) are included in the UPDATE?=C2=A0 Would that be a=
lso considered interference?<u></u><u></u></span></p></div><div><p class=3D=
"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"=
><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span sty=
le=3D"font-size:10pt;font-family:Helvetica,sans-serif">[major] What does &q=
uot;processed&quot; mean?=C2=A0 Let me explain... The example is about not =
being able to support an action.=C2=A0 What about not being able to apply t=
he action because, for example, the next hop is not reachable?=C2=A0 Would =
that qualify as not being able to &quot;process&quot; the action?=C2=A0 If =
other redirect traffic rules are included (with perhaps an alternate next h=
op), would the answer be different?<u></u><u></u></span></p></div><div><p c=
lass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans=
-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><s=
pan style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[nit] Make th=
e example a sentence on it&#39;s own: eliminate the parenthesis.<u></u><u><=
/u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><=
div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvet=
ica,sans-serif">[minor] s/rate-limit-bytes/traffic-rate-bytes (0x8006)<u></=
u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-s=
ize:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p><=
/div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:=
Helvetica,sans-serif">[minor] s/traffic-marking/traffic-marking (0x8009)<u>=
</u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font=
-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">[nit] s/plattform/platform<u></u><u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">[major] &quot;If not all of them can be processed the filter SHALL NOT =
be applied...&quot; =C2=A0Should they be forwarded?=C2=A0 Is this an exampl=
e of &quot;interfering flow actions&quot; (=C2=A77.6)?<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif">867<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 All traffic actions are specif=
ied as transitive BGP Extended<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">868<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Communities.<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif">870<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>7.1.=C2=A0 Traffic Rate in Bytes (tra=
ffic-rate-bytes) sub-type 0x06<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">...<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span sty=
le=3D"font-size:10pt;font-family:Helvetica,sans-serif">888<span class=3D"gm=
ail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 Interferes with: No other BGP Flow Specification traffic =
action in<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span s=
tyle=3D"font-size:10pt;font-family:Helvetica,sans-serif">889<span class=3D"=
gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 </span>=C2=A0 this document.<u></u><u></u></span></p></div><div><p c=
lass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans=
-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><s=
pan style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[minor] The d=
efinition of interference (=C2=A77.6) uses &quot;more than one conflicting =
traffic-rate action&quot; as part of it.=C2=A0 So it seems that traffic-rat=
e-bytes and traffic-rate-packets may interfere with each other.<u></u><u></=
u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10p=
t;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif">891<span class=3D"gmail-m_-2404559829259103405apple-tab-span=
">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>7.2.=C2=A0 Traffic Rate in Pa=
ckets (traffic-rate-packets) sub-type TBD<u></u><u></u></span></p></div><di=
v><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetic=
a,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNorm=
al"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[major]=
 Because the &quot;traffic actions are processed in ascending order of the =
sub-type&quot; (=C2=A77), what is the intent for this action?=C2=A0 How sho=
uld IANA assign it?=C2=A0 I assume that the intent might be to process it i=
nstead of traffic-rate-bytes (assuming only one might be present)...=C2=A0 =
Please be clear in the instructions to IANA (in =C2=A712.3).=C2=A0 Note tha=
t Table 7 requests the assignment from the &quot;Generic Transitive Experim=
ental Use Extended Community Sub-Types&quot; registry, which seems to limit=
 the assignment choices.=C2=A0 Having said all that, I would have assumed t=
hat this action would be a variation of the 0x06 sub-type, but with a diffe=
rent type...<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><spa=
n style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u=
></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:=
10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div=
><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helv=
etica,sans-serif">...<u></u><u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">901<sp=
an class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Interferes with: No other BGP Flow Specifi=
cation traffic action in<u></u><u></u></span></p></div><div><p class=3D"Mso=
Normal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">902=
<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 this document.<u></u><u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">[minor] The definition of interference (=C2=A77.6) uses &quot;more than=
 one conflicting traffic-rate action&quot; as part of it.=C2=A0 So it seems=
 that traffic-rate-bytes and traffic-rate-packets may interfere with each o=
ther.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">904<span class=3D"gmail-m_-2404559829259103=
405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>7.3.=C2=A0 T=
raffic-action (traffic-action) sub-type 0x07<u></u><u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">906<=
span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 The traffic-action extended community c=
onsists of 6 bytes of which<u></u><u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
907<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 only the 2 least significant bits of=
 the 6th byte (from left to<u></u><u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
908<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 right) are currently defined.<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif">910<span class=3D"gmail-m_-2404559829259103405apple-tab=
-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=
=A040 =C2=A041 =C2=A042 =C2=A043 =C2=A044 =C2=A045 =C2=A046 =C2=A047<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif">911<span class=3D"gmail-m_-2404559=
829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 =C2=A0 =C2=A0 +---+---+---+---+---+---+---+---+<u></u><u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">912<span class=3D"gmail-m_-2404559829259103405apple=
-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0=
 | =C2=A0 =C2=A0 =C2=A0 =C2=A0reserved =C2=A0 =C2=A0 =C2=A0 | S | T |<u></u=
><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-si=
ze:10pt;font-family:Helvetica,sans-serif">913<span class=3D"gmail-m_-240455=
9829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 =C2=A0 =C2=A0 +---+---+---+---+---+---+---+---+<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif">[minor] s/reserved/Traffic Action Fields =C2=A0 It would be nice if t=
he Figure showed that all the bits (not just the ones in the last octet) ar=
e part of the same field.<u></u><u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u=
></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">[nit] Please add a Fig=
ure number.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif">915<span class=3D"gmail-m_-2404559829=
259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0=
 where S and T are defined as:<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif">917<span class=3D=
"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 </span>=C2=A0 o =C2=A0T: Terminal Action (bit 47): When this bit is =
set, the traffic<u></u><u></u></span></p></div><div><p class=3D"MsoNormal">=
<span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">918<span cl=
ass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0filtering engine will apply any sub=
sequent filtering rules (as<u></u><u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
919<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0defined by the ordering=
 procedure).=C2=A0 If not set, the evaluation of<u></u><u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif">920<span class=3D"gmail-m_-2404559829259103405apple-ta=
b-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0the=
 traffic filter stops when this rule is applied.<u></u><u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
[minor] According to the processing order and the values from Table 2, not =
setting the bit would effectively cause only the traffic-rate-bytes (0x8006=
) to ever be applied.=C2=A0 Is that the correct interpretation?<u></u><u></=
u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10p=
t;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif">[minor] If the T bit is not set, can a router drop the commu=
nities that are not going to be applied...or should they all be propagated?=
<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"f=
ont-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif">[major] Clearly, a rogue router could unset the =
bit before propagating...<u></u><u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u=
></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">922<span class=3D"gmai=
l-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 o =C2=A0S: Sample (bit 46): Enables traffic sampling and =
logging for this<u></u><u></u></span></p></div><div><p class=3D"MsoNormal">=
<span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">923<span cl=
ass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0Flow Specification.<u></u><u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><=
p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,s=
ans-serif">[major] If the bit is not set, would sampling/logging be disable=
d?=C2=A0 IOW, is this an on/off switch, or is just the on action valid?<u><=
/u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif">925<span class=3D"gmail-m_-2404559829259103405apple-=
tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 o =C2=A0reserv=
ed: should always be set to 0 by the originator and not be<u></u><u></u></s=
pan></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fon=
t-family:Helvetica,sans-serif">926<span class=3D"gmail-m_-24045598292591034=
05apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0=
 =C2=A0evaluated by the receiving BGP speaker.<u></u><u></u></span></p></di=
v><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Hel=
vetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[m=
ajor] There is a registry for these bits. =C2=A0s/reserved/Traffic Action F=
ields<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><=
p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,s=
ans-serif">...<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><s=
pan style=3D"font-size:10pt;font-family:Helvetica,sans-serif">934<span clas=
s=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 Interferes with: No other BGP Flow Specification=
 traffic action in<u></u><u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">935<span =
class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 this document.<u></u><u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[min=
or] Based on the definition in =C2=A77.6, I would have thought that this ac=
tion, with the T bit unset, would interfere with other actions that will no=
w not be applied.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"=
><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=
=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif">937<span class=3D"gmail-m_-2404559829259103405apple-=
tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>7.4.=C2=A0 RT Redirec=
t (rt-redirect) sub-type 0x08<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">...<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span sty=
le=3D"font-size:10pt;font-family:Helvetica,sans-serif">948<span class=3D"gm=
ail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 It should be noted that the low-order nibble of the Redir=
ect&#39;s Type<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><s=
pan style=3D"font-size:10pt;font-family:Helvetica,sans-serif">949<span clas=
s=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 field corresponds to the Route Target Extended C=
ommunity format field<u></u><u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">950<sp=
an class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 (Type). =C2=A0(See Sections 3.1, 3.2, and =
4 of [RFC4360] plus Section 2 of<u></u><u></u></span></p></div><div><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif">951<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 [RFC5668].) =C2=A0The low-orde=
r octet (Sub-Type) of the Redirect Extended<u></u><u></u></span></p></div><=
div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvet=
ica,sans-serif">952<span class=3D"gmail-m_-2404559829259103405apple-tab-spa=
n">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Community remains 0x0=
8 for all three encodings of the BGP Extended<u></u><u></u></span></p></div=
><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helv=
etica,sans-serif">953<span class=3D"gmail-m_-2404559829259103405apple-tab-s=
pan">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Communities (AS 2-b=
yte, AS 4-byte, and IPv4 address).<u></u><u></u></span></p></div><div><p cl=
ass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-=
serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><sp=
an style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[nit] I think =
that this whole paragraph is not needed...and it actually may confuse peopl=
e.=C2=A0 I recommend deleting it.<u></u><u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><spa=
n style=3D"font-size:10pt;font-family:Helvetica,sans-serif">955<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 Interferes with: All other redirect functions.<u></=
u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-s=
ize:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p><=
/div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:=
Helvetica,sans-serif">[minor] What other redirect functions?=C2=A0 The only=
 ones defined are in this section.<u></u><u></u></span></p></div><div><p cl=
ass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-=
serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><sp=
an style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<=
u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size=
:10pt;font-family:Helvetica,sans-serif">957<span class=3D"gmail-m_-24045598=
29259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>7.5.=
=C2=A0 Traffic Marking (traffic-marking) sub-type 0x09<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif">959<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 The traffic marking extended c=
ommunity instructs a system to modify<u></u><u></u></span></p></div><div><p=
 class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sa=
ns-serif">960<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 the DSCP bits of a transiti=
ng IP packet to the corresponding value.<u></u><u></u></span></p></div><div=
><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica=
,sans-serif">961<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 This extended community =
is encoded as a sequence of 5 zero bytes<u></u><u></u></span></p></div><div=
><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica=
,sans-serif">962<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 followed by the DSCP val=
ue encoded in the 6 least significant bits of<u></u><u></u></span></p></div=
><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helv=
etica,sans-serif">963<span class=3D"gmail-m_-2404559829259103405apple-tab-s=
pan">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 6th byte.<u></u><u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif">[major] What action (if any) should a receiver take if the=
 &quot;5 zero bytes&quot; are not (all) set to 0?=C2=A0 Maybe include somet=
hing like: &quot;MUST be ignored when received...&quot;.<u></u><u></u></spa=
n></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-=
family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p c=
lass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans=
-serif">965<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Interferes with: No other B=
GP Flow Specification traffic action in<u></u><u></u></span></p></div><div>=
<p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,=
sans-serif">966<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 this document.<u></u><u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif">968<span class=3D"gmail-m_-2404559829259103405apple-tab-sp=
an">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>7.6.=C2=A0 Considerations o=
n Traffic Action Interference<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif">970<span class=3D=
"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 </span>=C2=A0 Since traffic actions are represented as BGP extended =
community<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span s=
tyle=3D"font-size:10pt;font-family:Helvetica,sans-serif">971<span class=3D"=
gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 </span>=C2=A0 values, traffic actions may interfere with each other =
(ie. there may<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><s=
pan style=3D"font-size:10pt;font-family:Helvetica,sans-serif">972<span clas=
s=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 be more than one conflicting traffic-rate action=
 associated with a<u></u><u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">973<span =
class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 single flow-filter).=C2=A0 Traffic action int=
erference has no impact on<u></u><u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">9=
74<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 BGP propagation of flow filters (all=
 communities are propagated<u></u><u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
975<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 according to policies).<u></u><u></u=
></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt=
;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><di=
v><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetic=
a,sans-serif">[nit] s/ie./e.g. =C2=A0 I&#39;m assuming it is an example and=
 not the only case.<u></u><u></u></span></p></div><div><p class=3D"MsoNorma=
l"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=
=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">[minor] Is &quot;Traffic act=
ion interference&quot; only the case when actions describe conflicting acti=
ons?=C2=A0 For example, different traffic rates.=C2=A0 Specifically, are ac=
tions that can&#39;t be applied (as described on =C2=A77), also considered =
as interference?<u></u><u></u></span></p></div><div><p class=3D"MsoNormal">=
<span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=
=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif">977<span class=3D"gmail-m_-2404=
559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 If a flow filter associated with interfering flow actions is selecte=
d<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif">978<span class=3D"gmail-m_=
-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </=
span>=C2=A0 for packet forwarding, it is a implementation decision which of=
 the<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">979<span class=3D"gmai=
l-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 interfering traffic actions are selected.=C2=A0 Implement=
ors of this<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif">980<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 specification SHOULD document the behaviour of thei=
r implementation<u></u><u></u></span></p></div><div><p class=3D"MsoNormal">=
<span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">981<span cl=
ass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 in such cases.<u></u><u></u></span></p></div><di=
v><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetic=
a,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNorm=
al"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[major]=
 IOW, deployment of a set of &quot;interfering flow actions&quot; could res=
ult in inconsistent behavior in the network.=C2=A0 Could a rogue BGP speake=
r advertise (or even add/delete) actions to a Flow Specification and cause =
unexpected results?=C2=A0 I guess that depending on what the action is, the=
re could be a significant effect.=C2=A0 I think this is a vulnerability tha=
t should be called out explicitly.=C2=A0 Thinking a little bit more...there=
 are two vulnerabilities: (1) add/delete in the normal case (even with cons=
istent behavior), and (2) add/delete to exploit a specific behavior of a no=
de in the network.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=
=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">983<span class=3D"gmail-m_-2=
404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </sp=
an>=C2=A0 If required, operators are encouraged to make use of the BGP poli=
cy<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D=
"font-size:10pt;font-family:Helvetica,sans-serif">984<span class=3D"gmail-m=
_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
/span>=C2=A0 framework supported by their implementation in order to achiev=
e a<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">985<span class=3D"gmai=
l-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 predictable behaviour (ie. match - replace - delete commu=
nities on<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span s=
tyle=3D"font-size:10pt;font-family:Helvetica,sans-serif">986<span class=3D"=
gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 </span>=C2=A0 administrative boundaries).<u></u><u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
[minor] &quot;If required...&quot; =C2=A0When it is not required?=C2=A0 IOW=
, I think that those two words are not needed.<u></u><u></u></span></p></di=
v><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Hel=
vetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u=
></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">988<span class=3D"gmai=
l-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>8.=C2=A0 Dissemination of Traffic Filtering in BGP/MPLS VPN Netw=
orks<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">990<span class=3D"gmail-m_-2404559829259103=
405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Provi=
der-based Layer 3 VPN networks, such as the ones using a BGP/<u></u><u></u>=
</span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;=
font-family:Helvetica,sans-serif">991<span class=3D"gmail-m_-24045598292591=
03405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 MPL=
S IP VPN [RFC4364] control plane, may have different traffic<u></u><u></u><=
/span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;f=
ont-family:Helvetica,sans-serif">992<span class=3D"gmail-m_-240455982925910=
3405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 filt=
ering requirements than Internet service providers.=C2=A0 But also<u></u><u=
></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:=
10pt;font-family:Helvetica,sans-serif">993<span class=3D"gmail-m_-240455982=
9259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 Internet service providers may use those VPNs for scenarios like<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif">994<span class=3D"gmail-m_-2404559=
829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 having the Internet routing table in a VRF, resulting in the same<u></u=
><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-si=
ze:10pt;font-family:Helvetica,sans-serif">995<span class=3D"gmail-m_-240455=
9829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 traffic filtering requirements as defined for the global routing<u><=
/u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif">996<span class=3D"gmail-m_-2404=
559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 table environment within this document.=C2=A0 This document proposes=
 an<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">997<span class=3D"gmai=
l-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 additional BGP NLRI type (AFI=3D1, SAFI=3D134) value, whi=
ch can be used<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><s=
pan style=3D"font-size:10pt;font-family:Helvetica,sans-serif">998<span clas=
s=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 to propagate traffic filtering information in a =
BGP/MPLS VPN<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><spa=
n style=3D"font-size:10pt;font-family:Helvetica,sans-serif">999<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 environment.<u></u><u></u></span></p></div><div><p =
class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,san=
s-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><=
span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[nit] s/prop=
oses/defines (or maybe specifies)<u></u><u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><spa=
n style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1001<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </=
span>=C2=A0 The NLRI format for this address family consists of a fixed-len=
gth<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">1002<span class=3D"gma=
il-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 Route Distinguisher field (8 bytes) followed by a Flow Specification=
,<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif">1003<span class=3D"gmail-m=
_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0=
 following the encoding defined above in Section 4.2 of this document.<u></=
u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-s=
ize:10pt;font-family:Helvetica,sans-serif">1004<span class=3D"gmail-m_-2404=
559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 The N=
LRI length field shall include both the 8 bytes of the Route<u></u><u></u><=
/span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;f=
ont-family:Helvetica,sans-serif">1005<span class=3D"gmail-m_-24045598292591=
03405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Distinguisher a=
s well as the subsequent Flow Specification.<u></u><u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[min=
or] s/Flow Specification, following the encoding defined above in Section 4=
.2 of this document./Flow Specification (Section 4.2).<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><spa=
n style=3D"font-size:10pt;font-family:Helvetica,sans-serif">...<u></u><u></=
u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10p=
t;font-family:Helvetica,sans-serif">1017<span class=3D"gmail-m_-24045598292=
59103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Propagation =
of this NLRI is controlled by matching Route Target<u></u><u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">1018<span class=3D"gmail-m_-2404559829259103405appl=
e-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 extended communities ass=
ociated with the BGP path advertisement with<u></u><u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif">1019<span class=3D"gmail-m_-2404559829259103405apple-tab-s=
pan">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 the VRF import policy, using th=
e same mechanism as described in &quot;BGP/<u></u><u></u></span></p></div><=
div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvet=
ica,sans-serif">1020<span class=3D"gmail-m_-2404559829259103405apple-tab-sp=
an">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 MPLS IP VPNs&quot; [RFC4364].<u>=
</u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font=
-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">[nit] s/&quot;BGP/MPLS IP VPNs&quot;/BGP/MPLS IP VP=
Ns<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D=
"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></spa=
n></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-=
family:Helvetica,sans-serif">1022<span class=3D"gmail-m_-240455982925910340=
5apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Flow Specification =
rules received via this NLRI apply only to traffic<u></u><u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif">1023<span class=3D"gmail-m_-2404559829259103405apple=
-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 that belongs to the VRF(s=
) in which it is imported.=C2=A0 By default,<u></u><u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif">1024<span class=3D"gmail-m_-2404559829259103405apple-tab-s=
pan">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 traffic received from a remote =
PE is switched via an MPLS forwarding<u></u><u></u></span></p></div><div><p=
 class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sa=
ns-serif">1025<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 decision and is not subject to filte=
ring.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">1027<span class=3D"gmail-m_-240455982925910=
3405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Contrary to the =
behavior specified for the non-VPN NLRI, flow rules<u></u><u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">1028<span class=3D"gmail-m_-2404559829259103405appl=
e-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 are accepted by default,=
 when received from remote PE routers.<u></u><u></u></span></p></div><div><=
p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,s=
ans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"=
><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[major] Th=
e only other mention of &quot;flow rule&quot; is in the Introduction when r=
eferring to the validation of external Flow Specifications, which seems to =
then map to =C2=A76...but the next sub-section says that those procedures a=
pply.=C2=A0 What am I missing?<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u><=
/u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif">1030<span class=3D"gmail-m_-2404559829=
259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>8.1.=C2=A0 Validat=
ion Procedures for BGP/MPLS VPNs<u></u><u></u></span></p></div><div><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1032<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </=
span>=C2=A0 The validation procedures are the same as for IPv4.<u></u><u></=
u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10p=
t;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif">1034<span class=3D"gmail-m_-2404559829259103405apple-tab-spa=
n">=C2=A0=C2=A0=C2=A0=C2=A0 </span>8.2.=C2=A0 Traffic Actions Rules<u></u><=
u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size=
:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></di=
v><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Hel=
vetica,sans-serif">1036<span class=3D"gmail-m_-2404559829259103405apple-tab=
-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 The traffic action rules are =
the same as for IPv4.<u></u><u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u=
>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"f=
ont-size:10pt;font-family:Helvetica,sans-serif">[nit] These 2 sub-sections =
could simply be covered by a couple of sentences...<u></u><u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1038<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </=
span>9.=C2=A0 Limitations of Previous Traffic Filtering Efforts<u></u><u></=
u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10p=
t;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif">[major] This section reads like a justification...=C2=A0 I t=
hink it would be a better fit as a subsection of the Introduction.<u></u><u=
></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:=
10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div=
><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helv=
etica,sans-serif">1040<span class=3D"gmail-m_-2404559829259103405apple-tab-=
span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>9.1.=C2=A0 Limitations in Previous DD=
oS Traffic Filtering Efforts<u></u><u></u></span></p></div><div><p class=3D=
"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"=
>...<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">1052<span class=3D"gma=
il-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 Several techniques are currently used to control traffic filtering o=
f<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif">1053<span class=3D"gmail-m=
_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0=
 DoS attacks.=C2=A0 Among those, one of the most common is to inject<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif">1054<span class=3D"gmail-m_-240455=
9829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 unicast=
 route advertisements corresponding to a destination prefix<u></u><u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">1055<span class=3D"gmail-m_-240455982925910=
3405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 being attacked (=
commonly known as remote triggered blackhole RTBH).<u></u><u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">1056<span class=3D"gmail-m_-2404559829259103405appl=
e-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 One variant of this tech=
nique marks such route advertisements with a<u></u><u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif">1057<span class=3D"gmail-m_-2404559829259103405apple-tab-s=
pan">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 community that gets translated =
into a discard Next-Hop by the<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">1058<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 receiving router.=C2=A0 Other variants att=
ract traffic to a particular<u></u><u></u></span></p></div><div><p class=3D=
"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"=
>1059<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 node that serves as a deterministic drop poin=
t.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D=
"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></spa=
n></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-=
family:Helvetica,sans-serif">[minor] Please add Informative references to r=
fc3882, rfc5635, rfc7999...<u></u><u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
<u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span styl=
e=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u><=
/span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;f=
ont-family:Helvetica,sans-serif">...<u></u><u></u></span></p></div><div><p =
class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,san=
s-serif">1103<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>10.=C2=A0 Traffic Monitoring<u></u><u></u></sp=
an></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font=
-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p =
class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,san=
s-serif">1105<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Traffic filtering applications require =
monitoring and traffic<u></u><u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1106<=
span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 statistics facilities.=C2=A0 While this is an imple=
mentation-specific<u></u><u></u></span></p></div><div><p class=3D"MsoNormal=
"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1107<span=
 class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 choice, implementations SHOULD provide:<u></u><u></u></sp=
an></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font=
-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p =
class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,san=
s-serif">1109<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 o =C2=A0A mechanism to log the packet h=
eader of filtered traffic.<u></u><u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><=
u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">1111<span class=3D"gma=
il-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 o =C2=A0A mechanism to count the number of matches for a given flow<=
u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">1112<span class=3D"gmail-m_-=
2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =
=C2=A0 =C2=A0specification rule.<u></u><u></u></span></p></div><div><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[minor] Is there=
 any relationship between this section and the S bit in =C2=A77.3?<u></u><u=
></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:=
10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div=
><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helv=
etica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"Mso=
Normal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">111=
4<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>11.=C2=A0 Error-Handling and Future NLRI Extensions<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif">[major] Suggestion: this section should be limited to d=
escribing what a malformed traffic action extended community is, and then s=
imply point to rfc7606, which already covers the rest.=C2=A0 See more comme=
nts below.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u><=
/u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif">[nit] The two topics covered here seem=
 unrelated...<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><sp=
an style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<=
u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size=
:10pt;font-family:Helvetica,sans-serif">1116<span class=3D"gmail-m_-2404559=
829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 In case =
BGP encounters an error in a Flow Specification UPDATE<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif">1117<span class=3D"gmail-m_-2404559829259103405a=
pple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 message it SHOULD tre=
at this message as Treat-as-withdraw according<u></u><u></u></span></p></di=
v><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Hel=
vetica,sans-serif">1118<span class=3D"gmail-m_-2404559829259103405apple-tab=
-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 to [RFC7606] Section 2.<u></u=
><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-si=
ze:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif">[major] The SHOULD above with the communities-related =
errors described below are in conflict with rfc7606, which says this: &quot=
;An UPDATE message with a malformed Extended Community attribute SHALL be h=
andled using the approach of &quot;treat-as-withdraw&quot;.&quot;<u></u><u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif">1120<span class=3D"gmail-m_-2404559829259103405apple-tab-s=
pan">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Possible reasons for an error a=
re (for more reasons see also<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">1121<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 [RFC7606]):<u></u><u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1123=
<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 o =C2=A0Incorrect implementation of this specificat=
ion - the encoding/<u></u><u></u></span></p></div><div><p class=3D"MsoNorma=
l"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1124<spa=
n class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=
=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0decoding of the NLRI or traffic action ex=
tended-communities do not<u></u><u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">11=
25<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0comply with this specification.<u><=
/u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif">[major] Related to the NLRI, rfc7606 says that &quot=
;in order to use the approach of &quot;treat-as-withdraw&quot;, the entire =
NLRI field and/or the MP_REACH_NLRI and MP_UNREACH_NLRI attributes need to =
be successfully parsed...=C2=A0 If this is not possible...that the &quot;se=
ssion reset&quot; approach (or the &quot;AFI/SAFI disable&quot; approach) M=
UST be followed.&quot;<u></u><u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></=
u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif">[major] For the Extended C=
ommunities...=C2=A0 The &quot;incorrect implementation&quot; basically mean=
s that the encoding is wrong, right?=C2=A0 But is the part about &quot;comp=
ly with this specification&quot; necessary?=C2=A0 Other traffic action exte=
nded communities (defined elsewhere) might be received.=C2=A0 I would rathe=
r if the text above talked about malformed (to match the language in rfc760=
6) traffic action extended communities in general (not just the ones in thi=
s specification).<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"=
><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=
=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif">1127<span class=3D"gmail-m_-240=
4559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 o =
=C2=A0Unknown Flow Specification extensions - The sending party has<u></u><=
u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size=
:10pt;font-family:Helvetica,sans-serif">1128<span class=3D"gmail-m_-2404559=
829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =
=C2=A0implemented a Flow Specification NLRI extension unknown to the<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif">1129<span class=3D"gmail-m_-240455=
9829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =
=C2=A0receiving party.<u></u><u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></=
u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif">[major] This treatment of =
unknown extensions is in conflict with the text in =C2=A74.2: &quot;If a gi=
ven component type within a prefix in unknown, the prefix in question canno=
t be used for traffic filtering purposes by the receiver... However, for th=
e purposes of BGP route propagation, this prefix should still be transmitte=
d since BGP route distribution is independent on NLRI semantics.&quot; =C2=
=A0IOW, &quot;treat-as-withdraw&quot; is not compatible with forwarding UPD=
ATES.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">1131<span class=3D"gmail-m_-240455982925910=
3405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 In order to faci=
litate future extensions of the Flow Specification<u></u><u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif">1132<span class=3D"gmail-m_-2404559829259103405apple=
-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 NLRI, such extensions SHO=
ULD specify a way to encode a &quot;always-true&quot;<u></u><u></u></span><=
/p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fam=
ily:Helvetica,sans-serif">1133<span class=3D"gmail-m_-2404559829259103405ap=
ple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 match condition within=
 the newly introduced components.=C2=A0 This match<u></u><u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif">1134<span class=3D"gmail-m_-2404559829259103405apple=
-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 condition can be used to =
propagate (and apply) certain filters only<u></u><u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif">1135<span class=3D"gmail-m_-2404559829259103405apple-tab-spa=
n">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 if a specific extension is known =
to the implemenation.<u></u><u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u=
>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"f=
ont-size:10pt;font-family:Helvetica,sans-serif">[nit] s/a &quot;always-true=
&quot;/an &quot;always-true&quot;<u></u><u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><spa=
n style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[minor] What do=
es &quot;always-true&quot; mean?<u></u><u></u></span></p></div><div><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[major] How come=
 this document doesn&#39;t follow the advice about the &quot;always-true&qu=
ot; match condition?<u></u><u></u></span></p></div><div><p class=3D"MsoNorm=
al"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=
=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">[nit] s/implemenation/implem=
entation<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span st=
yle=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u=
></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt=
;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><di=
v><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetic=
a,sans-serif">...<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"=
><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1141<span =
class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>12.1.=C2=A0 AFI/SAFI Definitions<u></u><u></u></span></p></div><=
div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvet=
ica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1143<=
span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 IANA maintains a registry entitled &quot;SAFI Value=
s&quot;.=C2=A0 For the purpose of<u></u><u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif">1144<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 this work, IANA updated the registry and a=
llocated two additional<u></u><u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1145=
<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 SAFIs:<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[nit] Even though=
 the text will probably end up as written, it doesn&#39;t ask IANA for anyt=
hing: it assumes that the work is done.=C2=A0 I would prefer it if the text=
 was worded as a request.=C2=A0 It may not be an issue for IANA, so there&#=
39;s no need to change anything, unless they say so.<u></u><u></u></span></=
p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fami=
ly:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">1147<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 +-------+---------------------------------=
---------+----------------+<u></u><u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
1148<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 | Value | Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 | Reference =C2=A0 =C2=A0 =C2=A0|<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif">1149<span class=3D"gmail-m_-2404559829259103405a=
pple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 +-------+------------=
------------------------------+----------------+<u></u><u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif">1150<span class=3D"gmail-m_-2404559829259103405apple-t=
ab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | 133 =C2=A0 | IPv4 dissemi=
nation of Flow Specification | [this =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<u>=
</u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font=
-size:10pt;font-family:Helvetica,sans-serif">1151<span class=3D"gmail-m_-24=
04559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | =
=C2=A0 =C2=A0 =C2=A0 | rules =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0| document] =C2=A0 =C2=A0 =C2=A0|<u></u><u></u></span></p></div><div>=
<p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,=
sans-serif">1152<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | 134 =C2=A0 | VPNv4 dissemination o=
f Flow =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| [this =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0|<u></u><u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">11=
53<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 | =C2=A0 =C2=A0 =C2=A0 | Specification rules =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =
document] =C2=A0 =C2=A0 =C2=A0|<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">1154<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 +-------+---------------------------------=
---------+----------------+<u></u><u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
<u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span styl=
e=3D"font-size:10pt;font-family:Helvetica,sans-serif">[major] It&#39;s not =
clear to me (because there&#39;s no explicit request) if the intent is to a=
dd this document as a reference, or to replace the one to rfc5575.=C2=A0 I =
would like you to be explicit.<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1156<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </=
span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Table 3: Registry: SAFI Values<u></u><u></u></span></p></div><div><p =
class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,san=
s-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><=
span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1158<span cl=
ass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
 </span>12.2.=C2=A0 Flow Component Definitions<u></u><u></u></span></p></di=
v><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Hel=
vetica,sans-serif">...<u></u><u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1184<=
span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 In order to manage the limited number space and acc=
ommodate several<u></u><u></u></span></p></div><div><p class=3D"MsoNormal">=
<span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1185<span c=
lass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 usages, the following policies defined by [RFC8126] used:=
<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"f=
ont-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif">[nit] s/[RFC8126] used/[RFC8126] are used<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif">1187<span class=3D"gmail-m_-2404559829259103405apple-ta=
b-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 +--------------+-------------------------------+<u></u><u></u></span=
></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-f=
amily:Helvetica,sans-serif">1188<span class=3D"gmail-m_-2404559829259103405=
apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 | Range =C2=A0 =C2=A0 =C2=A0 =C2=A0| Policy =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<u></=
u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-s=
ize:10pt;font-family:Helvetica,sans-serif">1189<span class=3D"gmail-m_-2404=
559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------------+---------------------------=
----+<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">1190<span class=3D"gma=
il-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0| Invalid value =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 |<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><spa=
n style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1191<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </=
span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | [1 .. 12] =C2=A0 =C2=A0| D=
efined by this specification |<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">1192<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | [13 .=
. 127] =C2=A0| Specification required =C2=A0 =C2=A0 =C2=A0 =C2=A0|<u></u><u=
></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:=
10pt;font-family:Helvetica,sans-serif">1193<span class=3D"gmail-m_-24045598=
29259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 | [128 .. 255] | First Come First Served =C2=A0=
 =C2=A0 =C2=A0 |<u></u><u></u></span></p></div><div><p class=3D"MsoNormal">=
<span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1194<span c=
lass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------------+------=
-------------------------+<u></u><u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><=
u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">[major] 0 is not reall=
y a range...and it&#39;s Invalid, so it shouldn&#39;t be part of the Table =
detailing the registration policies.=C2=A0 BTW, I couldn&#39;t find the tex=
t where 0 is declared Invalid -- please add some text to =C2=A74.2.=C2=A0 M=
ove 0 to Table 4.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"=
><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=
=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-=
size:10pt;font-family:Helvetica,sans-serif">[minor] Besides the fact that &=
quot;Defined by this specification&quot; is not a Policy, this table doesn&=
#39;t change anything in the current registry; it is not needed.<u></u><u><=
/u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10=
pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><=
div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvet=
ica,sans-serif">1196<span class=3D"gmail-m_-2404559829259103405apple-tab-sp=
an">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Table 5: Flow Spec Component Types Policies<u></u><u></u><=
/span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;f=
ont-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div>=
<p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,=
sans-serif">1198<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 The specification of a particular &q=
uot;Flow Spec Component Type&quot; must<u></u><u></u></span></p></div><div>=
<p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,=
sans-serif">1199<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 clearly identify what the criteria u=
sed to match packets forwarded by<u></u><u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif">1200<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 the router is.=C2=A0 This criteria should =
be meaningful across router hops<u></u><u></u></span></p></div><div><p clas=
s=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-se=
rif">1201<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 and not depend on values that change hop-b=
y-hop such as TTL or Layer<u></u><u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1=
202<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 2 encapsulation.<u></u><u></u></span></p></div><=
div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvet=
ica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[mino=
r] This paragraph doesn&#39;t belong in the IANA section.=C2=A0 It seems to=
 be laying out the groundwork for new components...so it belongs somewhere =
else.=C2=A0 Should any of the language be Normative?<u></u><u></u></span></=
p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fami=
ly:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1204<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </=
span>12.3.=C2=A0 Extended Community Flow Specification Actions<u></u><u></u=
></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt=
;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><di=
v><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetic=
a,sans-serif">1206<span class=3D"gmail-m_-2404559829259103405apple-tab-span=
">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 The Extended Community Flow Specif=
ication Action types defined in<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">1207<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 this document consist of two parts:<u></u>=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif">1209<span class=3D"gmail-m_-2404559829259103405apple-ta=
b-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0Type (BGP Trans=
itive Extended Community Type)<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1211<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </=
span>=C2=A0 =C2=A0 =C2=A0Sub-Type<u></u><u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><spa=
n style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1213<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </=
span>=C2=A0 For the type-part, IANA maintains a registry entitled &quot;BGP=
 Transitive<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1214<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </=
span>=C2=A0 Extended Community Types&quot;.=C2=A0 For the purpose of this w=
ork (Section 7),<u></u><u></u></span></p></div><div><p class=3D"MsoNormal">=
<span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1215<span c=
lass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 IANA updated the registry to contain the values listed be=
low:<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">[major] The range is defined in the registr=
y as &quot;0x80-0x8f <span class=3D"gmail-m_-2404559829259103405apple-tab-s=
pan">=C2=A0=C2=A0=C2=A0=C2=A0 </span>Reserved for Experimental Use&quot;.=
=C2=A0 According to rfc8126, &quot;IANA does not record assignments from re=
gistries or ranges with this policy&quot;.<u></u><u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">I don&=
#39;t know why 0x80 was the first value chosen; it looks like it was first =
used in draft-marques-idr-flow-spec-01 (2004), while the corresponding Exte=
nded Communities draft (draft-ietf-idr-bgp-ext-communities-07) already indi=
cated that the range was for Experimental Use.=C2=A0 I guess just lack of s=
ync...=C2=A0 But then I also don&#39;t understand how/why IANA ended up wit=
h the information in the Registry...maybe because the sub-types are not for=
 Experimental Use -- hmmm, which sounds contradictory to me.<u></u><u></u><=
/span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;f=
ont-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div>=
<p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,=
sans-serif">The reason/history doesn&#39;t matter anymore, but the current =
use does.=C2=A0 The mechanism described in this document is clearly not exp=
erimental.=C2=A0 Given that changing the Type values is not an option becau=
se of the deployed base, etc.., then I think we should clean up the Registr=
y and move 0x80-0x82 from the Experimental Use range to the FCFS range.=C2=
=A0 This change would mean an Update to rfc7153.<u></u><u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
To simplify the process, the Update can be done in this document.=C2=A0 How=
ever, I think that there&#39;s some confusion with these types apparently b=
eing associated only with Flow Specifications, when they are labeled as Gen=
eric.=C2=A0 IOW, ideally the issue would be corrected independently...<u></=
u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-s=
ize:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p><=
/div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:=
Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D=
"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"=
>1217<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=
=A0=C2=A0=C2=A0 </span>=C2=A0 +-------+------------------------------------=
-----------+-----------+<u></u><u></u></span></p></div><div><p class=3D"Mso=
Normal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">121=
8<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 | Type =C2=A0| Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Reference |<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif">1219<span class=3D"gmail-m_-2404559829259103405a=
pple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | Value | =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<u></u><u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif">1220<span class=3D"gmail-m_-2404559829259103405apple-tab-spa=
n">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 +-------+------------------------=
-----------------------+-----------+<u></u><u></u></span></p></div><div><p =
class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,san=
s-serif">1221<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | 0x80 =C2=A0| Generic Transitive Exper=
imental Use Extended =C2=A0| [RFC7153] |<u></u><u></u></span></p></div><div=
><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica=
,sans-serif">1222<span class=3D"gmail-m_-2404559829259103405apple-tab-span"=
>=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | =C2=A0 =C2=A0 =C2=A0 | Community =
(Sub-Types are defined in the =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 |<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><=
span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1223<span cl=
ass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
 </span>=C2=A0 | =C2=A0 =C2=A0 =C2=A0 | &quot;Generic Transitive Experiment=
al Use Extended | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif">1224<span class=3D"gmail-m_-2404559829259103405a=
pple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | =C2=A0 =C2=A0 =C2=
=A0 | Community Sub-Types&quot; registry) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<u></u><u></u=
></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt=
;font-family:Helvetica,sans-serif">1225<span class=3D"gmail-m_-240455982925=
9103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | 0x81 =C2=A0=
| Generic Transitive Experimental Use Extended =C2=A0| [this =C2=A0 =C2=A0 =
|<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif">1226<span class=3D"gmail-m=
_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0=
 | =C2=A0 =C2=A0 =C2=A0 | Community Part 2 (Sub-Types are defined in =C2=A0=
 =C2=A0| document] |<u></u><u></u></span></p></div><div><p class=3D"MsoNorm=
al"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1227<sp=
an class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=
=C2=A0 </span>=C2=A0 | =C2=A0 =C2=A0 =C2=A0 | the &quot;Generic Transitive =
Experimental Use =C2=A0 =C2=A0 =C2=A0| [See =C2=A0 =C2=A0 =C2=A0|<u></u><u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif">1228<span class=3D"gmail-m_-240455982=
9259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | =C2=A0 =
=C2=A0 =C2=A0 | Extended Community Part 2 Sub-Types&quot; =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0| Note-1] =C2=A0 |<u></u><u></u></span></p></div><div><p c=
lass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans=
-serif">1229<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | =C2=A0 =C2=A0 =C2=A0 | Registry) =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 |<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><spa=
n style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1230<span class=
=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </=
span>=C2=A0 | 0x82 =C2=A0| Generic Transitive Experimental Use Extended =C2=
=A0| [this =C2=A0 =C2=A0 |<u></u><u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1=
231<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 | =C2=A0 =C2=A0 =C2=A0 | Community Part 3 (Sub-T=
ypes are defined in =C2=A0 =C2=A0| document] |<u></u><u></u></span></p></di=
v><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Hel=
vetica,sans-serif">1232<span class=3D"gmail-m_-2404559829259103405apple-tab=
-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | =C2=A0 =C2=A0 =C2=A0 | the =
&quot;Generic Transitive Experimental Use =C2=A0 =C2=A0 =C2=A0| [See =C2=A0=
 =C2=A0 =C2=A0|<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><=
span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1233<span cl=
ass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0=
 </span>=C2=A0 | =C2=A0 =C2=A0 =C2=A0 | Extended Community Part 3 Sub-Types=
&quot; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Note-1] =C2=A0 |<u></u><u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">1234<span class=3D"gmail-m_-240455982925910=
3405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 | =C2=A0 =C2=A0 =
=C2=A0 | Registry) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<u></u><u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif">1235<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 +-------+---------------------------------=
--------------+-----------+<u></u><u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
<u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span styl=
e=3D"font-size:10pt;font-family:Helvetica,sans-serif">1237<span class=3D"gm=
ail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 =C2=A0 =C2=A0Table 6: Registry: Generic Transitive Experimental Use =
Extended<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span st=
yle=3D"font-size:10pt;font-family:Helvetica,sans-serif">1238<span class=3D"=
gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Community Types<u></u><u></u></span></p></di=
v><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Hel=
vetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[m=
ajor] In line with Updating the registry and the intent, the names of the T=
ypes/Registries should not include the word &quot;experimental&quot; to avo=
id any further confusion.<u></u><u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u=
></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">1240<span class=3D"gma=
il-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 Note-1: This document obsoletes RFC7674.<u></u><u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[=
minor] Putting the reference to this note in the Table seems to be asking I=
ANA to add a note there too...which I would think is not the case.=C2=A0 Th=
is goes back to the intent of whether the reference to this document should=
 replace what is there or simply be added.<u></u><u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u=
>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"f=
ont-size:10pt;font-family:Helvetica,sans-serif">...<u></u><u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">1292<span class=3D"gmail-m_-2404559829259103405appl=
e-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 The &quot;traffic-action=
&quot; extended community (Section 7.3) defined in this<u></u><u></u></span=
></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-f=
amily:Helvetica,sans-serif">1293<span class=3D"gmail-m_-2404559829259103405=
apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 document has 46 unus=
ed bits, which can be used to convey additional<u></u><u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif">1294<span class=3D"gmail-m_-2404559829259103405apple-ta=
b-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 meaning.=C2=A0 IANA created =
and maintains a new registry entitled:<u></u><u></u></span></p></div><div><=
p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,s=
ans-serif">1295<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 &quot;Traffic Action Fields&quot;.=
=C2=A0 These values should be assigned via IETF<u></u><u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif">1296<span class=3D"gmail-m_-2404559829259103405apple-ta=
b-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Review rules only.=C2=A0 The=
 following traffic-action fields have been<u></u><u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif">1297<span class=3D"gmail-m_-2404559829259103405apple-tab-spa=
n">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 allocated:<u></u><u></u></span></=
p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fami=
ly:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">[major] It needs to be mentioned somewhere that the reference for the w=
hole registry (not just the values below) should be moved to this document.=
<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"f=
ont-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif">...<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span s=
tyle=3D"font-size:10pt;font-family:Helvetica,sans-serif">1308<span class=3D=
"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </spa=
n>13.=C2=A0 Security Considerations<u></u><u></u></span></p></div><div><p c=
lass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans=
-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><s=
pan style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1310<span cla=
ss=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 =
</span>=C2=A0 Inter-provider routing is based on a web of trust.=C2=A0 Neig=
hboring<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span sty=
le=3D"font-size:10pt;font-family:Helvetica,sans-serif">1311<span class=3D"g=
mail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 autonomous systems are trusted to advertise valid reachability<u></u=
><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-si=
ze:10pt;font-family:Helvetica,sans-serif">1312<span class=3D"gmail-m_-24045=
59829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 inform=
ation.=C2=A0 If this trust model is violated, a neighboring<u></u><u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">1313<span class=3D"gmail-m_-240455982925910=
3405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 autonomous syste=
m may cause a denial-of-service attack by advertising<u></u><u></u></span><=
/p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fam=
ily:Helvetica,sans-serif">1314<span class=3D"gmail-m_-2404559829259103405ap=
ple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 reachability informati=
on for a given prefix for which it does not<u></u><u></u></span></p></div><=
div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvet=
ica,sans-serif">1315<span class=3D"gmail-m_-2404559829259103405apple-tab-sp=
an">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 provide service.<u></u><u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><=
p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,s=
ans-serif">[major] References to Origin Validation (rfc6811) and BGPSec (rf=
c8205) should be mentioned as possible mitigation...with maybe a comment ab=
out the current deployment status.<u></u><u></u></span></p></div><div><p cl=
ass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-=
serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><sp=
an style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1317<span clas=
s=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 <=
/span>=C2=A0 As long as traffic filtering rules are restricted to match the=
<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"f=
ont-size:10pt;font-family:Helvetica,sans-serif">1318<span class=3D"gmail-m_=
-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =
corresponding unicast routing paths for the relevant prefixes, the<u></u><u=
></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:=
10pt;font-family:Helvetica,sans-serif">1319<span class=3D"gmail-m_-24045598=
29259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 security =
characteristics of this proposal are equivalent to the<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif">1320<span class=3D"gmail-m_-2404559829259103405a=
pple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 existing security pro=
perties of BGP unicast routing.=C2=A0 However, this<u></u><u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">1321<span class=3D"gmail-m_-2404559829259103405appl=
e-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 document also specifies =
traffic filtering actions that may need<u></u><u></u></span></p></div><div>=
<p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,=
sans-serif">1322<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 custom additional verification on th=
e receiver side.=C2=A0 See Section 14.<u></u><u></u></span></p></div><div><=
p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,s=
ans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"=
><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[major] In=
 general, Flow Specifications have a one-AS-hop propagation model, right?=
=C2=A0 This means that the security properties are different because (1) un=
icast routing propagates multiple hops, and (2) the intent of the &quot;Rou=
te Origin ASN&quot; (rfc6811) is not reflected in the request to rate-limit=
, or even drop (!) traffic to a destination.=C2=A0 Yes, it is all based on =
trust...but different.=C2=A0 For example, Origin Validation wouldn&#39;t be=
 available for Flow Specifications.<u></u><u></u></span></p></div><div><p c=
lass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans=
-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><s=
pan style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1324<span cla=
ss=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 =
</span>=C2=A0 Where it is not the case, this would open the door to further=
 denial-<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span st=
yle=3D"font-size:10pt;font-family:Helvetica,sans-serif">1325<span class=3D"=
gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span=
>=C2=A0 of-service attacks.<u></u><u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
<u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span styl=
e=3D"font-size:10pt;font-family:Helvetica,sans-serif">[major] Like what?=C2=
=A0 What are possible mitigations?=C2=A0 Just saying that the door is open =
is not enough.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><s=
pan style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0=
<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-siz=
e:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif">...<u></u><u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1337=
<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>14.=C2=A0 Operational Security Considerations<u></u><u></u=
></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt=
;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><di=
v><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetic=
a,sans-serif">[minor] If you ask me, this section should be rolled into the=
 last one: I think all the considerations (in both sections) are really ope=
rational...<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif">1339<span class=3D"gmail-m_-240455982=
9259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 While the =
general verification of the traffic filter NLRI is<u></u><u></u></span></p>=
</div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif">1340<span class=3D"gmail-m_-2404559829259103405apple=
-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 specified in this documen=
t (Section 6) the traffic filtering actions<u></u><u></u></span></p></div><=
div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvet=
ica,sans-serif">1341<span class=3D"gmail-m_-2404559829259103405apple-tab-sp=
an">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 received by a third party may ne=
ed custom verification or filtering.<u></u><u></u></span></p></div><div><p =
class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,san=
s-serif">1342<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 In particular all non traffic-rate acti=
ons may allow a third party to<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">1343<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 modify packet forwarding properties and po=
tentially gain access to<u></u><u></u></span></p></div><div><p class=3D"Mso=
Normal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">134=
4<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 other routing-tables/VPNs or undesired queues.=C2=
=A0 This can be avoided<u></u><u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1345=
<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 by proper filtering of action communities at networ=
k borders and by<u></u><u></u></span></p></div><div><p class=3D"MsoNormal">=
<span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1346<span c=
lass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 mapping user-defined communities (see Section 7) to expos=
e certain<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span s=
tyle=3D"font-size:10pt;font-family:Helvetica,sans-serif">1347<span class=3D=
"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </spa=
n>=C2=A0 forwarding properties to third parties.<u></u><u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"=
MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">=
[minor] I didn&#39;t get this last part...=C2=A0 I understand filtering, bu=
t didn&#39;t quite understand how the mapping of communities would help.<u>=
</u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font=
-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p=
></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-famil=
y:Helvetica,sans-serif">1349<span class=3D"gmail-m_-2404559829259103405appl=
e-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Since verfication of the=
 traffic filtering NLRI is tied to the<u></u><u></u></span></p></div><div><=
p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,s=
ans-serif">1350<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 announcement of the best unicast rou=
te, a unfiltered address space<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if">1351<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 hijack (e.g. advertisement of a more speci=
fic route) may cause this<u></u><u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">13=
52<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 verification to fail and consequently prevent Fl=
ow Specification<u></u><u></u></span></p></div><div><p class=3D"MsoNormal">=
<span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1353<span c=
lass=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=
=A0 </span>=C2=A0 filters from being accepted by a peer.<u></u><u></u></spa=
n></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-=
family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p c=
lass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans=
-serif">[nit] s/verfication/verification<u></u><u></u></span></p></div><div=
><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica=
,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNorma=
l"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[nit] s/=
a unfiltered/an unfiltered<u></u><u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><=
u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">[minor] Again, mention=
 Origin Validation as possible mitigation.<u></u><u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNor=
mal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1355<s=
pan class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=
=C2=A0 </span>15.=C2=A0 Original authors<u></u><u></u></span></p></div><div=
><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica=
,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNorma=
l"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1357<spa=
n class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=
=C2=A0 </span>=C2=A0 Barry Greene, Pedro Marques, Jared Mauch, Danny McPher=
son, and<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span st=
yle=3D"font-size:10pt;font-family:Helvetica,sans-serif">1358<span class=3D"=
gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span=
>=C2=A0 Nischal Sheth were authors on RFC5575, and therefore are contributi=
ng<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D=
"font-size:10pt;font-family:Helvetica,sans-serif">1359<span class=3D"gmail-=
m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=
=A0 authors on this document.<u></u><u></u></span></p></div><div><p class=
=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-ser=
if"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span =
style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[minor] To be in =
line with rfc7322, this section should be renamed to &quot;Contributors&quo=
t;.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><=
p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,s=
ans-serif">1361<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>16.=C2=A0 Acknowledgements<u></u><u></u></s=
pan></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fon=
t-family:Helvetica,sans-serif">...<u></u><u></u></span></p></div><div><p cl=
ass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-=
serif">1370<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 A packet rate flowspec action was also =
discribed in a flowspec<u></u><u></u></span></p></div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1371=
<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 extention draft and the authors like to thank Wesle=
y Eddy, Justin<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><s=
pan style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1372<span cla=
ss=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 =
</span>=C2=A0 Dailey and Gilbert Clark for their work.<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif">[nit] This is the first time that &quot;flowspec&quot; is used.=C2=A0=
 Not a bad thing...just an observation that we went through the whole docum=
ent without using the colloquial name flowspec.<u></u><u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[=
nit] s/discribed/described<u></u><u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><=
u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">[nit] s/extention/exte=
nsion<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">1374<span class=3D"gmail-m_-240455982925910=
3405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Additional the a=
uthors would like to thank Alexander Mayrhofer,<u></u><u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif">1375<span class=3D"gmail-m_-2404559829259103405apple-ta=
b-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 Nicolas Fevrier, Job Snijder=
s, Jeffrey Haas and Adam Chappell for<u></u><u></u></span></p></div><div><p=
 class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sa=
ns-serif">1376<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=
=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 their comments and review.<u></u><u>=
</u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
0pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div>=
<div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helve=
tica,sans-serif">[nit] s/Additional/Additionally,<u></u><u></u></span></p><=
/div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:=
Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D=
"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"=
><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span sty=
le=3D"font-size:10pt;font-family:Helvetica,sans-serif">1378<span class=3D"g=
mail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
17.=C2=A0 References<u></u><u></u></span></p></div><div><p class=3D"MsoNorm=
al"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=
=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"fo=
nt-size:10pt;font-family:Helvetica,sans-serif">1380<span class=3D"gmail-m_-=
2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>17.1.=C2=
=A0 Normative References<u></u><u></u></span></p></div><div><p class=3D"Mso=
Normal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u>=
</u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif">1382<span class=3D"gma=
il-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=
=C2=A0 [IEEE.754.1985]<u></u><u></u></span></p></div><div><p class=3D"MsoNo=
rmal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1383<=
span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=
=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IEEE, &quo=
t;Standard for Binary Floating-Point Arithmetic&quot;,<u></u><u></u></span>=
</p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-fa=
mily:Helvetica,sans-serif">1384<span class=3D"gmail-m_-2404559829259103405a=
pple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0IEEE 754-1985, August 1985.<u></u><u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">[=
minor] IEEE has revised this spec twice, the most current revision was publ=
ished earlier this year.=C2=A0 Should the reference to the 1985 version be =
kept?=C2=A0 Is there a reason not to point generically to IEEE 754, instead=
 of to a specific version?<u></u><u></u></span></p></div><div><p class=3D"M=
soNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif"><=
u></u>=C2=A0<u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif">...<u></u><u></u></span></p></div><div><p c=
lass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans=
-serif">1419<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 [RFC5668] =C2=A0Rekhter, Y., Sangli, S.=
, and D. Tappan, &quot;4-Octet AS<u></u><u></u></span></p></div><div><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-s=
erif">1420<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=
=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0S=
pecific BGP Extended Community&quot;, RFC 5668,<u></u><u></u></span></p></d=
iv><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:He=
lvetica,sans-serif">1421<span class=3D"gmail-m_-2404559829259103405apple-ta=
b-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0DOI 10.17487/RFC5668, October 2009,<u></u><u></u></span></p></=
div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:H=
elvetica,sans-serif">1422<span class=3D"gmail-m_-2404559829259103405apple-t=
ab-span">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0&lt;<a href=3D"https://www.rfc-editor.org/info/rfc5668" targe=
t=3D"_blank">https://www.rfc-editor.org/info/rfc5668</a>&gt;.<u></u><u></u>=
</span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;=
font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div=
><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica=
,sans-serif">[minor] I don&#39;t think this needs to be a Normative referen=
ce.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></=
span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;fo=
nt-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div><div><=
p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,s=
ans-serif">...<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><s=
pan style=3D"font-size:10pt;font-family:Helvetica,sans-serif">1458<span cla=
ss=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=C2=A0=C2=A0 =
</span>Appendix A.=C2=A0 Comparison with RFC 5575<u></u><u></u></span></p><=
/div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:=
Helvetica,sans-serif">...<u></u><u></u></span></p></div><div><p class=3D"Ms=
oNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">14=
64<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=A0=C2=A0=
=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0Section 1 introduces the Flow Speci=
fication NLRI.=C2=A0 In RFC5575 this<u></u><u></u></span></p></div><div><p =
class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,san=
s-serif">1465<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0NLRI was defined as an opa=
que-key in BGPs database.=C2=A0 This<u></u><u></u></span></p></div><div><p =
class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,san=
s-serif">1466<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0specification has removed =
all references to a opaque-key property.<u></u><u></u></span></p></div><div=
><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica=
,sans-serif">1467<span class=3D"gmail-m_-2404559829259103405apple-tab-span"=
>=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0BGP is able understand=
 the NLRI encoding.=C2=A0 This change also<u></u><u></u></span></p></div><d=
iv><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helveti=
ca,sans-serif">1468<span class=3D"gmail-m_-2404559829259103405apple-tab-spa=
n">=C2=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0resulted in a new se=
ction regarding error-handling and<u></u><u></u></span></p></div><div><p cl=
ass=3D"MsoNormal"><span style=3D"font-size:10pt;font-family:Helvetica,sans-=
serif">1469<span class=3D"gmail-m_-2404559829259103405apple-tab-span">=C2=
=A0=C2=A0=C2=A0=C2=A0 </span>=C2=A0 =C2=A0 =C2=A0extensibility (Section 11)=
.<u></u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"=
font-size:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span=
></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-f=
amily:Helvetica,sans-serif">[nit] s/able understand/able to understand<u></=
u><u></u></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-s=
ize:10pt;font-family:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p><=
/div></div><p class=3D"MsoNormal"><span style=3D"font-size:10pt;font-family=
:Helvetica,sans-serif"><u></u>=C2=A0<u></u></span></p></div></div></div></b=
lockquote></div>

--0000000000001548c805925a770f--