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

[Rob Shakir <[e-mail]>]

> 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