Re: [Idr] AD Review of draft-ietf-idr-rfc5575bis-17

"Susan Hares" <shares@ndzh.com> Thu, 12 September 2019 17:52 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA3B12020A; Thu, 12 Sep 2019 10:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.948
X-Spam-Level:
X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyX7peHnOWhU; Thu, 12 Sep 2019 10:52:27 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76457120178; Thu, 12 Sep 2019 10:52:27 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=97.112.17.31;
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
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJLQJSF5123l/3BN1uxfGjpfGIeQwKg4tJeAKuI7X8B2BHhSaYTgHQg
Content-Language: en-us
X-Antivirus: AVG (VPS 190911-2, 09/11/2019), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/_OhWupyL0un0DjIzNis_Sofat58>
Subject: Re: [Idr] AD Review of draft-ietf-idr-rfc5575bis-17
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Sep 2019 17:52:31 -0000

Robert: 

Thank you for your input.  

Sue 

-----Original Message-----
From: Robert Raszuk [mailto:robert@raszuk.net] 
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 
> 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 
> 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 of 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 that none of the original authors mentioned as "contributing 
> authors" (§15) 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 
> 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 
> 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 
> 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 has 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 that "traffic actions are processed in ascending 
> order of the sub-type" (§7) 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 
> with that intent.  [See related comments in §7.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 
> history of this use is not clear, we should take the opportunity to 
> clean the registry.  [See more in §12.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 §5 (not 
> §5.1) and §9.  Please combine the information from §1 and §5, and the 
> background from
> §9 into an updated Introduction.  §6 seems to belong right after the 
> definition of the NLRI (§4), and before the next part of the 
> specification
> (filtering) starts with §5.1, then §7...
>
>
>
> Most of the old text is about justification, some from the specific 
> 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 
> 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=5575&submit=rfc
>
> [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 
> this 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 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 
> 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 both.
>
>
>
> [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 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 
> specification" to 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 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 
> 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 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, 
> 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 
> 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 §1.1/rfc4271=