Subject: [Idr] Last Call Expired: <draft-ietf-idr-error-handling-18.txt>

From: DraftTracker Mail System <[email-masked]>
Date: Thu, 12 Mar 2015 00:08:49 -0700

Please DO NOT reply to this email.

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.

---

From: Rob Shakir <[email-masked]>
Date: Thu, 12 Mar 2015 11:26:45 +0000

> On 12 Mar 2015, at 07:08, DraftTracker Mail System <[email-masked]> wrote:
> 

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

---

From: Rob Shakir <[email-masked]>
Date: Thu, 12 Mar 2015 11:26:45 +0000

Folks, Authors,

r.

---

From: Alia Atlas <[email-masked]>
Date: Thu, 12 Mar 2015 12:01:49 -0400

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 <[email-masked]> wrote:

> > ID Tracker URL:
> http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/
> >
> Keeping track of the IESG comments on this draft, and some of the other
> feedback that’s been received from directorate reviews:
>
> * multiple comments about §6 of the document and particularly the rfc2119
> wording have been raised. Can I suggest that we restructure this section
> slightly:
>
>   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.
>
>         * 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).
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 12 Mar 2015 12:01:49 -0400

Alia

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 12 Mar 2015 16:11:03 +0000

On 3/12/15, 4:26 AM, "Rob Shakir" <[email-masked]> wrote:

Rob:

Hi!

>  * 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?

A section would be nice, but I don¹t have a problem with 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

Yes, the result is ³better² (at least there¹s less disruption), but it
might still result in isolation of an ASN at a route level.  Not all
routes are made the same.

Alvaro.

>
>Thanks for all the work thus far on this document ‹ I look forward to
>this doc progressing further!
>
>r.
>
>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 12 Mar 2015 16:11:03 +0000

Rob:

Hi!

Alvaro.