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

[Brian Haberman <[e-mail]>]

Hi Rob,
     Thanks for continuing this conversation...

On 3/8/15 2:49 PM, [e-mail] wrote:
> 
> 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.

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