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

[Alissa Cooper <[e-mail]>]

> 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.
> 
> 
>