Early Review of draft-ietf-idr-flowspec-interfaceset-02
review-ietf-idr-flowspec-interfaceset-02-rtgdir-early-huston-2017-02-26-00

Hi,

I have been assigned the QA reviewer for this draft. there appears to be no
formal template for this review, but the general guidelines at
https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa state:

  "When reviewing a draft at WG Adoption, the QA Reviewer should determine
  whether the draft is readable, understandable, makes sense and is a good
  start for a WG draft. Any issues the QA Reviewer finds are written down, sent
  to the mailing list and discussed for future versions"

So here are mo responses to these questions fter reviewing this draft:

** Is the draft readable?

yes

** Is the draft understandable?

yes, provided the reader takes to time to familiarise themselves with the BGP
flowspec structure and operation in the first place. At least I think it is
understandable - if the authors believe that I have misinterpreted the intent
of this draft then that may be a very clear signal that it was less
understandable than I thought!

** Does it make sense?

Here’s where I have a few issues that I found in reviewing this draft.

The diagram in figures 1 and 2 appear to overuse the term “PE” - it appears
that this may or may not be a MPLS PE router, as in the context of this draft
it appears that they are simply EBGP speakers. It would be helpful to clarify
this.

This brings on a second comment that the document is not overly clear about the
scope of intended application - the ability to declare filter rules per
interface appears to assume a detailed level of device configuration that would
only normally be accessible to a network management - so that the intended
scope of this form of flowspec propagation is iBGP.  But the example in section
2 appears to say otherwise - the draft would benefit from some clarity over the
intended (and safe) scope of propagation of such interface flowspecs.

The third comment is that the draft is a mix of motivation for the desired
mechanism, advocating the chosen solution, and the protocol mechanisms
(extension to BGP extended community set). My own personal taste is to split
this to a document about the need, and a seperate document about the protocol
mechanism and the related IANA considerations.

The fourth comment is that the section “Security Considerations” appears to
also contain some critical design information that is conveniently ignored in
the rest of the draft. A broader document about the general problem space and
the strengths and weaknesses of various approaches to automated traffic filter
management in devices (see previous comment) would be a better place to argue
the relative merits of various forms of network automation vs the use of
signalling within BGP. Previous schools of through were that flow spec
signalling was an ideal approach to remote (inter-AS) RBH signalling, while
various in-house forms of network management would be more approach to operate
the local network. This draft does not appear to to clearly state exactly what
problem it is solving. If it is trying to perform remote filter management in
Other Peoples Networks then there are huge security implications. The draft
conveniently waves its hands about the group identifier and its intended
interpretation. This is a large conceptual hole in the draft imho. The second
part of this is also touched upon in a passing comment in the Security
Considerations, that these filters are ephemeral in nature, as compared to a
more ‘conventional’ network management tool that would maintain filters as
configured elements in the device.

I think what is missing relates to the observation that sure, you CAN stuff
this into BGP using extended communities, but SHOULD we do this? What are the
reasons why this particular approach makes sense over and above other existing
tools and approaches. If the role of this WG is to document everything we COULD
do in BGP then the workload may well be infinite - if the role is to document
what we SHOULD be specifying as a BGP-based tool then this would make more
sense. As a result, I suspect that this draft could benefit from some
operational perspectives. Does this materially help network operators in
attempting to respond to DDOS attacks? Or is it just another tool in an
environment already replete with various tools and technique and as such
limited adoption would imply that it would be effectively unused by network
operators.

Obviously I am at this point unconvinced that it “makes sense” in the broader
sense, and rather than trying to add more words to a single document it may be
helpful to look at splitting the specification of the proposed mechanism and
the IANA instructions and the discussion of why this particular approach to
distributed filter management makes more sense than what current operational
practices rely on.

regards,

   Geoff

> On 24 Feb 2017, at 3:40 pm, Yemin (Amy) <amy.yemin@huawei.com> wrote:
>
> Hi Geoff,
>
> Please would you be the routing directorate QA reviewer for
draft-ietf-idr-flowspec-interfaceset > >
https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-interfaceset/ > > Note
that this is a “QA review.” The document does not yet have consensus to be
forwarded to the IESG. The goal of this review is to provide a new perspective
on the work in progress and to improve its quality. Hence, your comments will
be provided primarily for the benefit of the IDR chairs and the document
authors. > Please could you provide your comments by March, 9th, 2017? You
should send your comments to the draft authors and WG chairs, and copy the
relevant WG mailing list and the rtg-dir list. > The following web page
contains a briefing on the QA process, and guidance for the QA reviewer. >
https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa > > Please let me know if you
can do it, or not. > > Many thanks > Amy > > > > This e-mail and its
attachments contain confidential information from HUAWEI, which > is intended
only for the person or entity whose address is listed above. Any use of the >
information contained herein in any way (including, but not limited to, total
or partial > disclosure, reproduction, or dissemination) by persons other than
the intended > recipient(s) is prohibited. If you receive this e-mail in error,
please notify the sender by > phone or email immediately and delete it!