Subject: [Idr] Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT)

From: "Brian Haberman" <[email-masked]>
Date: Fri, 06 Mar 2015 12:40:43 -0800

Brian Haberman has entered the following ballot position for
draft-ietf-idr-error-handling-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for a clearly written document.  The only point I will make is
that I do not think the 2119 keywords in section 6 are necessary.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 6 Mar 2015 15:48:31 -0500

Brian:

My recollection is that there was a lengthy outage caused by a bogus route received by IBGP and then sent to the rest  of the world.   Rob Shakir may have a better memory.  After the draft deadline, I will look for the incident's write-up in NANOG or in my BGP mail archive.  Therefore, the word RECOMMEND was considered appropriate. 

Sue 

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]] 
Sent: Friday, March 06, 2015 3:41 PM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Thank you for a clearly written document.  The only point I will make is that I do not think the 2119 keywords in section 6 are necessary.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 6 Mar 2015 15:48:31 -0500

Brian:

Sue

---

From: <[email-masked]>
Date: Fri, 6 Mar 2015 20:59:34 +0000

Hi Sue,

You remember correct ‹ there were a number of issues that occurred around
the time that this document got started (I presented about them at NANOG
51 ‹ http://www.slideshare.net/robjs/bgp-error-handling-nanog-51), and I
also edited the requirements document for this work (which is in GROW ‹
https://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling
-07). 

We also wrote up some recommendations based on the original AS4_PATH
incident (which triggered draft-scudder-idr-optional-transitive) which
were on NANOG and IDR -
http://mailman.nanog.org/pipermail/nanog/2009-January/006816.html and
http://www.ietf.org/mail-archive/web/idr/current/msg03546.html.

The reason that I think the 2119 wording is in there (and is still
appropriate) is that there are complexities that are introduced
operationally with this mechanism that did not occur before. The previous
behaviour of a failed session makes a bunch of noise, and hence the issue
can be diagnosed and examined. With the treat-as-withdraw approach it¹s
critical for operators to be able to determine when malformed UPDATEs are
being received, and that sufficient information is given to the operator
to resolve the problem. If we do not have these mechanisms, prefixes are
being withdrawn via an (otherwise working) session - with the operator
having no clue this is happening. Needless to say, this would be
undesirable, and hence to avoid it, these recommendations are made.

r.

[06/03/2015 20:48, "Susan Hares" <[email-masked]>]

>Brian:
>
>My recollection is that there was a lengthy outage caused by a bogus
>route received by IBGP and then sent to the rest  of the world.   Rob
>Shakir may have a better memory.  After the draft deadline, I will look
>for the incident's write-up in NANOG or in my BGP mail archive.
>Therefore, the word RECOMMEND was considered appropriate.
>
>
>Sue 
>
>Cc: [email-masked]; [email-masked]; [email-masked];
>[email-masked]
>Subject: Brian Haberman's No Objection on
>draft-ietf-idr-error-handling-18: (with COMMENT)
>

---

From: <[email-masked]>
Date: Fri, 6 Mar 2015 20:59:34 +0000

Hi Sue,

r.

---

From: Brian Haberman <[email-masked]>
Date: Fri, 06 Mar 2015 16:09:41 -0500

Hi Rob,

> undesirable, and hence to avoid it, these recommendations are made.

The above is quite clear and shows me how I think I misread the second
paragraph.  I read it has saying the operator SHOULD identify the
offending route and trace it back to its ingress into the network.  The
description above sounds like the text is saying the router SHOULD
provide enough information so that the operator knows to trace the
offending route.

Am I interpreting that correctly?

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Fri, 06 Mar 2015 16:09:41 -0500

Hi Rob,

Regards,
Brian

---

From: <[email-masked]>
Date: Sun, 8 Mar 2015 18:49:14 +0000

Hi Brian,

[06/03/2015 21:09, "Brian Haberman" <[email-masked]>]

>><snip>

In my view, it¹s both.

If we have erroneous UPDATEs that are being transmitted by a router, this
means that something, somewhere is wrong. It¹s not really desirable for
there to be routing updates that are known to have issues present in the
system, and as such an operator should really examine this and fix it.
Today, they have to do so, as the router transmitting the error is likely
to be disconnected from the network (or some other system downstream will
be, due to it transmitting the erroneous message).

The recommendation is maybe stating something obvious, but I see no harm
in having it in the document - we should remind people that transmitting
an erroneous UPDATE is still a BadThing (tm), and is likely to be causing
log messages for all other operators that see it in the DFZ. The best
practice is clearly to clean up the error.

r.

---

From: <[email-masked]>
Date: Sun, 8 Mar 2015 18:49:14 +0000

Hi Brian,

In my view, it¹s both.

r.

---

From: Brian Haberman <[email-masked]>
Date: Mon, 09 Mar 2015 08:21:23 -0400

Hi Rob,
     Thanks for continuing this conversation...

> practice is clearly to clean up the error.

I agree that it belongs in the document, but it appears to me to be a
little opaque.  I read the text in the draft as strictly something the
operator has to worry about.  The description you provided indicated
that there needs to be sufficient notification from the router so that
the operator can act on it.

Perhaps what is needed is just a little clarification.  Given that I
raised this as a Comment, making any changes is really up to the
authors/WG/AD.  My thought would be a slight re-wording of the 2nd
paragraph to indicate that the router needs to provide a notification
when a malformed attribute is detected.  That then provides the input
needed for the operator to act on the recommendation in the section.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Mon, 09 Mar 2015 08:21:23 -0400

Hi Rob,

Regards,
Brian

---

From: Rob Shakir <[email-masked]>
Date: Thu, 12 Mar 2015 10:51:55 +0000

Brian,

Apologies for the delay in my reply.

> On 9 Mar 2015, at 12:21, Brian Haberman <[email-masked]> wrote:
> 

I agree — let me work with the authors as part of the post-IESG review comments to see whether we can clarify the wording here (perhaps based around the summaries here). Since there are multiple comments around this clarification, then making changes would seem advisable to me!

Thanks again for the review.

Cheers,
r.

---

From: Rob Shakir <[email-masked]>
Date: Thu, 12 Mar 2015 10:51:55 +0000

Brian,

Cheers,
r.