Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

[Jeffrey Haas <[e-mail]>]

Sue,


On Wed, Mar 08, 2017 at 08:29:37PM -0500, Susan Hares wrote:
> Caveat - I am not commenting on operational issues.  If your brief comment
> denotes some operational issues, I would appreciate a longer description
> on-list or off-list. 
> 
> If you are comment on the functionality within the RFC4271 FSM, I am not
> sure why the "wiggle room is reduced when the open message size is changed"?
> I have been specific on this list as to the functionality a message header
> length error enacts (Event 21) versus an Open Message Header enacts (Event
> 22).    Please be as specific in your response if it is a FSM issues. 

This is to some extent a simple issue with regard to extended and
non-extended speakers trying to interoperate.  However, the version case
with the changes under discussion complicate the matter slightly.

Presume old RFC 4271 speaker, O.
Presume new extended message speaker E.

If E sends an open message > 4096 octets to O, the generally expected
behavior is that O will send a notification message with a Bad Message
Length subcode.  O has no reason to change its behavior.

E may have course note this specific error and try to back-off, if possible
to a <= 4096 message size.  However, I tend to agree with other threads that
we're better off blocking the peering session from coming up without further
intervention.  I am *not* a supporter of deferring the larger Open
operations to another message; we'd be better off getting something like
Dynamic Capabilities working and we've had a number of discussions about why
some of that behavior is problematic.

(Alternatively, we simply have the extended open message, but that's a bit
of a change in the FSM.)

So... why did I bring up the version negotiation point?

Mostly because for version negotiation to work, once we leave -4 behind, we
need to be able to generate an Unsupported Version Number error.  We can't
do that if the receiver simply dumps the session due to hitting the message
length validation failure first.

As I mention too tersely in my response... oh well.  But it does mean that
if we go with > 4k open messages that old speakers will only get upset about
PDUs that are too big rather than giving us other useful information about
why session negotiation is failing.

I suspect this is fine, but it should be a choice that is clearly
understood.

-- Jeff