Re: [Idr] Post-Last Call Shepherd Comments for draft-ietf-idr-error-handling (was Re: Last Call Expired: <draft-ietf-idr-error-handling-18.txt>)

[Alia Atlas <[e-mail]>]

I'm not convinced that we can use 2119 SHOULD language to put requirements
on humans.
I do agree about what the operators should do but without the SHOULD...

Alia

On Thu, Mar 12, 2015 at 7:26 AM, Rob Shakir <[e-mail]> wrote:

>
> > On 12 Mar 2015, at 07:08, DraftTracker Mail System <
> [e-mail]> wrote:
> >
> > I-D: <draft-ietf-idr-error-handling-18.txt>
> > ID Tracker URL:
> http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/
> >
> > IETF Last Call has ended, and the state has been changed to
> > Waiting for AD Go-Ahead.
>
> Folks, Authors,
>
> Keeping track of the IESG comments on this draft, and some of the other
> feedback that’s been received from directorate reviews:
>
> * gen-art provided some comments (you can find them at [0]) that it would
> be good to address.
>
> * Stephen Farrell’s review raised a few nits (some of which are duplicate
> from the gen-art review.
>
> * multiple comments about §6 of the document and particularly the rfc2119
> wording have been raised. Can I suggest that we restructure this section
> slightly:
>
>    Although the "treat-as-withdraw" error-handling behavior defined in
>    Section 2 makes every effort to preserve BGP's correctness, we note
>    that if an UPDATE received on an iBGP session is subjected to this
>    treatment, inconsistent routing within the affected Autonomous System
>    may result.  The consequences of inconsistent routing can include
>    long-lived forwarding loops and black holes.  While lamentable, this
>    issue is expected to be rare in practice, and, more importantly, is
>    seen as less problematic than the session-reset behavior it replaces.
>    The treat-as-withdraw mechanism is different from discarding an UPDATE
>    message. The latter violates the basic BGP principle of
>    incremental UPDATE, and causes invalid routes to be kept.
>
>    Since treat-as-withdraw may result in such inconsistent routing within
>    an AS, complete un-reachability or sub-optimal routing for the
>    destinations whose routes are carried in an affected UPDATE message, a
>    BGP speaker MUST provide debugging facilities to permit issues caused
>    by a malformed UPDATE to be diagnosed. At a minimum, such facilities
> MUST
>    include logging an error listing the NLRI involved, and containing the
>    entire malformed UPDATE message.
>
>    When such an error is logged, it is recommended that an operator
>    SHOULD analyse the logged UPDATE message, and SHOULD investigate the
> root cause.
>    Where there source of the erroneous UPDATE message is external to the
>    autonomous system, or administrative domain, of the operator - we
>    RECOMMEND that an operator traces the erroneous UPDATE message to the
>    ingress router which sourced the routes, or received the routes
>    externally - and applies a filter to prevent the routes being announced.
>    This helps to maintain routing consistency in the network.
>
>    Section 8 mentions that attribute discard should not be used in cases
>    where “the attribute in question has or may have an effect on route
>    selection.” Although all cases that specify attribute discard in this
>    document do not affect route selection by default, in principle,
>    routing policies could be written that affect selection based on such
>    an attribute. Operators SHOULD take care when writing such policies
>    to consider the possible consequences of attribute discard. (In general,
>    as long as such policies are only applied to external BGP sessions,
>    correctness issues are not expected to arise.)
>
>   Hopefully this makes reasonable use of RFC2119 wording too. I think that
> if we are saying that the implementation MUST/SHOULD do something to
> maintain correctness then we should say that the operator SHOULD do
> something too! I think structuring the section into these two elements
> (box-behaviours followed by people-behaviours) adds some clarity.
>
>   * Stephen also raised a point about security considerations - this
> seemed (to me) to relate more to security considerations of
> treat-as-withdraw when used as a behaviour within BGPSEC. My (personal
> opinion) is that this concern would be better covered in the BGPSEC
> documents - since this document (at the moment) does not update any
> document related to BGPSEC.
>
>   * Our esteemed new AD reviewed too — thanks Alvaro. The review can be
> found at [1].
>         * 1 & 2 - there is a request to have a summary of what RFCs are
> updated and how in the document. Potentially this could be added as an
> appendix?
>         * In the security considerations section, Alvaro observes that
> remote withdrawal could be a new attack vector that is introduced. We
> should mention this, but raise the consideration that rather than causing
> session tear-down (which might result in isolation of an ASN).
>
> Thanks for all the work thus far on this document — I look forward to this
> doc progressing further!
>
> r.
>
>
> [0]: https://www.ietf.org/mail-archive/web/ietf/current/msg92265.html
> [1]: https://www.ietf.org/mail-archive/web/idr/current/msg14113.html
>
>