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

["Susan Hares" <[e-mail]>]

Jeff:

I now understand your "wiggle room".   We both agree on the FSM actions and
that we need operator input on the choices. 

1) Open Message < 4096 - hold while at BGP version 4  
  [This can be held at the Open Message header tests (event 22)]
  While all other MESSAGES > 4096 if 
  open capability for extended messages. 

2) all Messages at > 4096 - with BGP version 5 
    (no capability negotiation) 

3) Open Message < 4096  - with BGP version 4 +  Dynamic Capabilities
    All other BGP-4 messages > 4096 if 
    Open capability for extended messages 

4) Update message only at > 4096 
   if  Open capability for extended messages

Did I miss an open?  If not, I will open a request for feedback on IDR, and
add this to the grow request for input. 

Sue Hares 

-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Tuesday, March 14, 2017 6:53 PM
To: Susan Hares
Cc: 'Enke Chen'; 'idr wg'; 'Robert Raszuk'; [e-mail];
[e-mail]
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

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