Subject: Re: [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-07.txt

From: "George, Wes" <[email-masked]>
Date: Tue, 14 Apr 2015 16:43:32 -0400

Hi -

Gave this a thorough review at the request of the chairs. I'll apologize
in advance if I'm retreading old ground, I hadn't been paying close
attention to this doc in the past.

Nits:
2.1: expand ASBR on first use. Also, reference RFC4760, etc since you're
basically discussing MP-BGP?
3.4: add reference for MP_REACH_NLRI, are the last two "should" normative?
If so, capitalize
3.5: is "recommended" normative? If so, you can probably drop the SHOULD
(or vice versa)
4.2: is first "may" in 3rd paragraph normative? If so, capitalize

Multiple instances of the phrase "It SHOULD be noted that..." - reword to
make it clearer what is being normatively directed here and avoid passive
voice, or eliminate normative SHOULD. Caveats and warnings don't
necessarily need to be normative in that way.

Fair warning - our newly-minted routing AD poked me repeatedly over making
statements like "Operators [$2119_word] do [foo]" as a misuse of 2119
words. I defended it as being useful when warning about specific things
that operators might do to break things, but you may want to use it
carefully and be prepared to defend your choice. :-)

Substantive:

Section 2.2 mixes requirements and problem statement in a way that I'm
finding a bit confusing. There's good text here that continues the problem
statement's narrative about the changes to how we're using BGP. The first
section talks about it from an SP infrastructure perspective, and then
this section discusses it from the customer-facing services perspective.
However, the inclusion of some requirements about how BGP needs to behave
in these cases are better pulled from 2.2 and placed in a more clearly
defined top section that discusses the requirements that are derived from
both parts of the previous section's problem statements. In other words,
I'm not sure you want normative text in a problem statement. You also want
to be careful to distinguish what you mean by "requirements" since in the
context of this document, they can be interpreted as both "what we need
the protocol or implementations to do/what problem the IETF needs to
solve" and "customer expectation of the performance and robustness of the
service that is built using the protocols the IETF has defined". The
latter is certainly important information, but IMO keeping the two cleanly
differentiated will make for a clearer document.

Similarly, I might suggest moving the normative text in the first part of
section 3 and in section 3.5 elsewhere, as it is out of place with the
rest of the text categorizing types of errors so that each type can be
handled differently. Maybe move to the first part of section 4?

More fundamentally: I think some parts of this document are beyond what is
appropriate for an informational requirements document that doesn't
formally update the BGP protocol spec(s). There is normative text in
sections 3.4 and 4.1 (first paragraph) and the first part of section 5
that to the casual reader (who is not familiar with the difference between
PS and info and/or missed the brief caveat at the end of the abstract) is
explicitly defining new behavior in conflict with the existing standard.
If this is simply defining what we'd like the behavior to be in order to
address the problems defined elsewhere, we should dispense with the
normative text and present it as a recommendation.
When I think of a requirement in the context of an IETF document, I think
in terms of a list of problems that need to be addressed by a given
solution, or a list of functions that a given solution needs to provide.
Usually we write those types of docs when we don't have a good solution
yet, or we have multiple solutions and need a way to compare them by
evaluating how many of the specific requirements each meets. It doesn't
seem like either of those are true here, because this draft has actual
solutions and even implementation guidance in a number of places. I like
the solutions, and I think it's the right way to solve the problems
discussed here, so let's skip a step and just publish the solution. Make
some tweaks, keeping some of the first couple of sections as intro matter,
and have the meat of the document focused on codifying the changes to the
protocol and BGP speaker behavior. Move to PS, add the right "updates"
metadata, and harden the normative language accordingly so that you can
implement from this document.

However, as a PS document, there's a question as to where it belongs, and
the answer is probably IDR rather than GROW. I'm not sure how that works
with the requirements for multiple interoperable implementations before a
doc will last call in IDR, but perhaps that's something that the chairs
and ADs can discuss to give us the most expedient path forward so that
what comes out the other side is vendor implementations that help address
the problems we've identified here?

Thanks,

Wes

On 11/10/14, 1:43 AM, "[email-masked]" <[email-masked]> wrote:

>Hi GROW,
>
>After a relatively long time dormant, since the solutions draft in idr
>stablised, I¹ve updated the error handling requirements document. It
>captures all the feedback that I¹ve received since the last rev.
>
>I hope this is stable enough for us to progress to last-call again :-)
>
>I¹d welcome comments,
>r.
>
>>
>>        Title           : Operational Requirements for Enhanced Error
>>Handling Behaviour in BGP-4
>>        Author          : Rob Shakir
>>      Filename        : draft-ietf-grow-ops-reqs-for-bgp-error-handling-07.txt
>>      Pages           : 14
>>      Date            : 2014-11-09

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.