Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Job Snijders <[e-mail]>]

Hi Robert,

On Sat, Nov 19, 2016 at 03:27:09PM +0100, Robert Raszuk wrote:
> RFC4271 says:
> 
>   0                   1                   2                   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  | Error code    | Error subcode |   Data (variable)             |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> ...
> 
> Note that the length of the Data field can be determined from
> the message Length field by the formula:
> 
>   Message Length = 21 + Data Length
> 
> RFC4486 says:
> 
>    If a BGP speaker decides to administratively shut down its peering
>    with a neighbor, then the speaker SHOULD send a NOTIFICATION message
>    with the Error Code Cease and the Error Subcode "Administrative
>    Shutdown".
> 
> That all means there is no guarantee that if you insert length some
> CPEs will not crush even if the length value will be all 0.

By 'length' you mean filling in the "Data (variable)" field?

> That means that in my network where there is 15000 CEs if at least one
> crashes I can not upgrade any longer any PE OS which may be needed for
> other reasons.

If your CE crashes because there is trailing data after a Cease subcode
2, I consider your implementation to be non-compliant with how the rest
of the world understands BGP. Already today one can send you trailing
data after a Subcode 2 Cease NOTIFICATION, I've found no examples of
software which is not capable of handling that.

By using the "A device might crash somewhere"-argument you block any
innovation. Will you withdraw all your active internet-drafts?

> If we are to continue to use subcode 2 let's stay with current 4271
> format and not update 4271 RFC with this proposal.
> 
> Or let's define new cease subcode say "INFO" which will be injected
> only when operator types in a string. That way existing deployments
> are safe and you can enjoy new communication channel (hopefully with
> some well defined keywords :).

The notification message, of all the BGP messages, is uniquely (albeit
crudely) extensible without permission since there is no question of
being "punished" by having the session torn down if you send a
nonconforming message. Might as well admit that and be robust to
noncomforming extensions.

Kind regards,

Job