Early Review of draft-ietf-idr-flowspec-interfaceset-02
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?
** 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.
> On 24 Feb 2017, at 3:40 pm, Yemin (Amy) <firstname.lastname@example.org> wrote:
> Hi Geoff,
> Please would you be the routing directorate QA reviewer for 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.
> Please let me know if you can do it, or not.
> Many thanks
> 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!