Re: [Idr] Alissa Cooper's Discuss on draft-ietf-idr-rfc8203bis-07: (with DISCUSS and COMMENT)

[Alissa Cooper <[e-mail]>]

This is much better, thanks. So the idea is basically that the operator might learn out-of-band what message length is supported, or might learn by trial-and-error?

Alissa

> On Oct 8, 2020, at 1:22 AM, Jakob Heitz (jheitz) <[e-mail]> wrote:
> 
> Fair question.
> Proposed text change:
> OLD
>   If a Shutdown Communication longer than 128 octets is sent to a BGP
>   speaker that implements [RFC8203], then that speaker will treat it as
>   an error, the consequence of which is a log message.  For this
>   reason, operators would be wise to keep shutdown communications to
>   less than 128 octets when feasible.
> 
>   There is no guarantee that the receiver supports either this
>   specification or [RFC8203], so any shutdown communication might not
>   be logged in an easily-readable form at all.  Therefore, operators
>   would also be wise not to rely on shutdown communications as their
>   sole form of communication with their peer for important events.
> NEW
>   If a Shutdown Communication longer than 128 octets is sent to a BGP
>   speaker that implements [RFC8203], then that speaker will treat it as
>   an error, the consequence of which should be a log message.
> 
>   If a Shutdown Communication of any length is sent to a BGP
>   speaker that implements neither [RFC8203] nor this specification,
>   then that speaker will treat it as
>   an error, the consequence of which should be a log message.
> 
>   In any case, a receiver of a NOTIFICATION message is unable to
>   acknowledge the receipt and correct understanding of any
>   Shutdown Communication.
> 
>   Operators should not rely on Shutdown Communications as their
>   sole form of communication with their peer for important events.
> 
>   If it is known that the peer BGP speaker supports this specification,
>   then a Shutdown Communication that is not longer than 255 octets MAY be sent.
>   Otherwise, a Shutdown Communication MAY be sent, but it SHOULD NOT be
>   longer than 128 octets.
> END
> 
> 
> Regards,
> Jakob.
> 
> -----Original Message-----
> From: Alissa Cooper <[e-mail]> 
> Sent: Wednesday, October 7, 2020 6:52 PM
> To: Jakob Heitz (jheitz) <[e-mail]>
> Cc: IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Susan Hares <[e-mail]>; [e-mail]
> Subject: Re: Alissa Cooper's Discuss on draft-ietf-idr-rfc8203bis-07: (with DISCUSS and COMMENT)
> 
> 
> 
>> On Oct 7, 2020, at 8:59 PM, Jakob Heitz (jheitz) <[e-mail]> wrote:
>> 
>> There is no way to know whether the neighbor supports RFC8203 either,
>> so the problem is not unique to the bis.
> 
> Ok. How do operators decide whether to use RFC 8203 and, if this document is approved, how long of a message to use?
> 
> Alissa
> 
>> 
>> This is a best-effort message for convenience.
>> The session is going down whether the message makes it or not.
>> If the peer operator is confused, he will pick up the phone and
>> call the NOC or whatever else they do today.
>> The message prevents that phone call.
>> When maintenance is scheduled, it should be agreed upon beforehand,
>> so both ends should be expecting the cease notification anyway.
>> This message serves only as a reminder in case people don't read their email and such.
>> 
>> Regards,
>> Jakob.
>> 
>> -----Original Message-----
>> From: Alissa Cooper via Datatracker <[e-mail]> 
>> Sent: Wednesday, October 7, 2020 5:10 PM
>> To: The IESG <[e-mail]>
>> Cc: [e-mail]; [e-mail]; [e-mail]; Susan Hares <[e-mail]>; [e-mail]; [e-mail]
>> Subject: Alissa Cooper's Discuss on draft-ietf-idr-rfc8203bis-07: (with DISCUSS and COMMENT)
>> 
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-idr-rfc8203bis-07: Discuss
>> 
>> 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 https://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:
>> https://datatracker.ietf.org/doc/draft-ietf-idr-rfc8203bis/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> "If a Shutdown Communication longer than 128 octets is sent to a BGP
>>  speaker that implements [RFC8203], then that speaker will treat it as
>>  an error, the consequence of which is a log message.  For this
>>  reason, operators would be wise to keep shutdown communications to
>>  less than 128 octets when feasible."
>> 
>> I have a similar question to what Éric asked. Doesn't the above mostly undercut
>> the value of doing this bis at all? If operators can't expect longer messages
>> to be understood, will they implement some kind of policy logic or heuristics
>> to decide when to try to send them and when not? Otherwise, under what
>> circumstances will they send them?
>> 
>> Was it considered to instead add a new subcode to the BGP Cease NOTIFICATION
>> subcode registry to capture this case (admin reset or shutdown with long
>> shutdown message)? That way at least those who want to use it can differentiate
>> between recipients that don't support RFC 8203, those that do, and those that
>> support longer communications. I'm not at all steeped in BGP so I'm happy to
>> drop this if it's unworkable, but I wanted to ask.
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> For the IESG: it would be good to discuss a bit if there is some process we can
>> use to avoid this kind of oversight (that occurred with RFC 8203) in the
>> future. i18ndir didn't exist when it was published, but even if it had I'm not
>> sure we would have caught this.
>> 
>> 
>> 
>