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

[<[e-mail]>]

Hi Brian,


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

>Hi Rob,
>
>On 3/6/15 3:59 PM, [e-mail] wrote:
>><snip>
>> 
>
>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.

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.