From: "Susan Hares" <shares@ndzh.com>
To: "'Robert Raszuk'" <robert@raszuk.net>
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>
References: <CAMMESsxHXUB_jQk7E9FkeNef2C7DDcbiEvnROFdbEjAVtMqcFA@mail.gmail.com>
 <76CD132C3ADEF848BD84D028D243C927CD15601E@NKGEML515-MBX.china.huawei.com>
 <002101d56956$1c91d180$55b57480$@ndzh.com>
 <CAOj+MMGkihs4dUT3n86RpZDXfgH=rK1Cm4gL47QCk4Vx6ZtLQQ@mail.gmail.com>
In-Reply-To: <CAOj+MMGkihs4dUT3n86RpZDXfgH=rK1Cm4gL47QCk4Vx6ZtLQQ@mail.gmail.com>
Date: Thu, 12 Sep 2019 13:52:10 -0400
Message-ID: <00ff01d56992$cdeb4fb0$69c1ef10$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQJLQJSF5123l/3BN1uxfGjpfGIeQwKg4tJeAKuI7X8B2BHhSaYTgHQg
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/_OhWupyL0un0DjIzNis_Sofat58>
Subject: Re: [Idr] AD Review of draft-ietf-idr-rfc5575bis-17
Precedence: list

Robert:=20

Thank you for your input. =20

Sue=20

-----Original Message-----
From: Robert Raszuk [mailto:robert@raszuk.net]=20
Sent: Thursday, September 12, 2019 8:42 AM
To: Susan Hares
Cc: Dongjie (Jimmy); Alvaro Retana; draft-ietf-idr-rfc5575bis@ietf.org; =
idr-chairs@ietf.org; idr@ietf. org
Subject: Re: AD Review of draft-ietf-idr-rfc5575bis-17

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=20
> points at draft-ietf-idr-flow-spec-v6, that draft has been expired for =

> over a year!  What is the plan to move that work forward?  It looks=20
> 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=20
> check the third-party disclosure procedure and file related=20
> 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;=20
> 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=20
> clarifying and updating rfc5575!  Many of my comments (see below) are=20
> related to what I think is still missing clarity, or lack of it in=20
> some of the new text.
>
>
>
> Besides the specific comments, I have some larger issues that I want=20
> 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=20
> rfc5575 [2].  IMO, the changes between rfc5575 and this document are=20
> not that significant to assume that the declarations don't apply.  I=20
> also note that none of the original authors mentioned as "contributing =

> authors" (=C2=A715) replied to the IPR call during the WGLC.
>
>
>
> Jie: As Shepherd, can you please file a third-party disclosure [3]=20
> pointing at the rfc5575 disclosures?  Once that is done I will send a=20
> message to the WG to consider the information -- I don't expect any=20
> issues, 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=20
> points at draft-ietf-idr-flow-spec-v6, that draft has been expired for =

> over a year!  What is the plan to move that work forward?  It looks=20
> like there may already be implementations in place [4].
>
>
>
> We all know this question will come up during IESG Evaluation,=20
> specially in light of the IAB Statement on IPv6 [5] and the fact that=20
> 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=20
> document would be forthcoming.
>
>
>
> We should have a plan in place by the time this document makes it to=20
> the IESG Telechat.  It would have been ideal to publish both at the=20
> same time, but I'll settle for the ability to (at least) point at the=20
> WGLC (which has been brought up before [7]).
>
>
>
>
>
> (C) IANA Considerations
>
>
>
> (C1) traffic-rate-packets
>
>
>
> The instructions to IANA for the assignment of the=20
> traffic-rate-packets sub-type are not clear.  The existing assignments =

> and the requirement that "traffic actions are processed in ascending=20
> 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=20
> with that intent.  [See related comments in =C2=A77.2.]
>
>
>
> (C2) Experimental Use Ranges
>
>
>
> This document uses ranges from the "BGP Transitive Extended Community=20
> Types" registry which are reserved for Experimental Use.  While the=20
> history of this use is not clear, we should take the opportunity to=20
> clean the registry.  [See more in =C2=A712.3.]
>
>
>
>
>
> (D) Document organization
>
>
>
> This document kept most of the Introduction text, but then added=20
> related and, in some cases, overlapping and redundant text in =C2=A75 =
(not=20
> =C2=A75.1) and =C2=A79.  Please combine the information from =C2=A71 =
and =C2=A75, and the=20
> background from
> =C2=A79 into an updated Introduction.  =C2=A76 seems to belong right =
after the=20
> definition of the NLRI (=C2=A74), and before the next part of the=20
> specification
> (filtering) starts with =C2=A75.1, then =C2=A77...
>
>
>
> Most of the old text is about justification, some from the specific=20
> point of view of the then-authors.  Please reconsider whether that =
still applies.
>
>
>
>
>
> I will wait for the major issues/comments to be addressed before=20
> starting the IETF Last Call.
>
>
>
> Thanks!
>
>
>
> Alvaro.
>
>
>
>
>
> [1]=20
> 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]=20
> 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]=20
> 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=20
> rewritten while the Introduction was mostly left unchanged.  I assume=20
> this was done to reflect the changes in the document upfront...but it=20
> 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 =
used
>
> 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 =
community
>
> 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=20
> Flow Specification filter
>
>
>
> [minor] I think that this paragraph, or something like it, belongs in=20
> the Introduction (and not the Abstract), because it provides=20
> information that could benefit from references:
>
>
>
> - the two parts of the NLRI; BTW, the community is not even mentioned=20
> in the Introduction.
>
>
>
> - other drafts... The Introduction only mentions and provides a=20
> 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=20
> references to both RFCs.  There should be an Informative reference to =
both.
>
>
>
> [minor] Appendix A talks about the difference of this document with=20
> respect to rfc5575.  What about rfc7674?  It looks like any updates=20
> from
> rfc7674 have been incorporated in this document.  It would be very=20
> nice, even if just for completion, if there was an Appendix that=20
> 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 =
strict
>
> 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=20
> specification" to refer to the same thing...right?  Or are there=20
> 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=20
> set of authors, I would assume we can safely say that the=20
> concern/application goes 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=20
> 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=20
> 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 of
>
> 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,=20
> including hardware processing/storage, has changed.  Is this text =
still necessary?
> If so, then I would like to see explicit operational considerations on =

> what 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=20
> be properly programmed, the algorithms used are not performing as=20
> expected, or simply because it is rogue, are all vulnerabilities that=20
> 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=3D