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

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

Enke and Jakob: 

I am not commenting on the operational desires or your implementations in this message, only to clarify that the "slow retry" is not an absolute in the state machine.  There is also no logical difference in the current statement machine between BGP header error (Event 21) or an OPEN message header error (Event 22) in the FSM. 

So, if you are talking code and the RFC4271 specification in your messages - I do not understand your comments.  RFC4271 consider the issues you are indicating and put in optional switches to control behaviors.  There are knobs to have no peer damping, little peer damping or lots of peer damping.    It is also possible to have logic in implementations which sets these options based on a previous response. 

If you are speaking about your implementations, you know best. 

Sue 

==========================

If the OPEN exceeds the maximum size, it is a header size error (Event 21, p 49, RFC4271 ) in the state machine.  If the logical flag SendNOTIFICATIONwithoutOPEN (p. 37, RFC4271), then the state machine will respond to an open with a Notification with the header error message. 

Two possible sequences in the FSM if the logical SENDNOTIFICATIONwithoutOpen is sent 

Sequence 1 - Peer with Extended BGP message establishes first 

TCP connection establish ------
Send Open ---> 
[open sent state] 
(5000)                 <----- NOTIFICATION (header error) 
		      Performs peer damping (if this option is set) 
		       Peer 2 goes to idle and restarts 
		      [p. 57, RFC4271] 

Reception of NOTIFICATON
Clears all BGP resources 
Goes to IDLE.
Manual/automatic start can restart session 

If you configure peer damping, then you have a delay. 
If you configure "no peer damping" and "automatic start"
And the implementation logic knows to switch back to 4096,  
This sequence does not have to delay the peer. 

If you configure peer damping, then it does damp.
If not, you can sequence through this quickly.  
 
Sequence 2 - Peer with Normal BGP sends first open 

TCP connection 
          <--------- (open) (less than or equal to 4096) 
		No extended message capability 

Open ----> 
Extended peer should not send  a OPEN with more than 4096. 

====================
You could specify in a specification these optional settings + peer logic without changing RFC4271 FSM. 
You just would specify some optional settings as mandatory and a logic around them. 
I agree with Enke that additional text should be created to define these for open. 

If you specify that the Open cannot be greater than 4096, then the logic changes in the 
OPEN validation code.  And the errors messages is OPEN-MSG-Format error. 
You would go through the exact sequence in the FSM (see page 57 of RFC4271), 
And the error is not specific to the error length.  

Sue 
 

-----Original Message-----
From: Enke Chen [mailto:[e-mail]] 
Sent: Wednesday, March 8, 2017 3:14 PM
To: Jakob Heitz (jheitz)
Cc: Borchert, Oliver (Fed); 'idr wg'; [e-mail]; 'Robert Raszuk'; Susan Hares; [e-mail]; Enke Chen
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

If one has to send a large OPEN, then it is rejected by the remote speaker, then the session needs to be held down (or for slow retry) until the remote speaker is upgraded or the OPEN size reduced locally as you are saying.

The details need to be specified in a new revision.

Thanks.  -- Enke

On 3/8/17 12:04 PM, Jakob Heitz (jheitz) wrote:
> I don't think it makes sense to fallback if a long OPEN message fails.
> Suppose the OPEN message is 4100 bytes long and it fails.
> How will you shrink it?
> The operator will need to remove some features from the configuration before trying again.
> 
> Thanks,
> Jakob.
> 
>> -----Original Message-----
>> From: Idr [mailto:[e-mail]] On Behalf Of Borchert, Oliver 
>> (Fed)
>> Sent: Tuesday, March 07, 2017 5:21 PM
>> To: Enke Chen (enkechen) <[e-mail]>
>> Cc: 'idr wg' <[e-mail]>; 
>> [e-mail]; 'Robert Raszuk' 
>> <[e-mail]>; Susan Hares <[e-mail]>; 
>> [e-mail]
>> Subject: Re: [Idr] AD Review of 
>> draft-ietf-idr-bgp-extended-messages-20
>>
>> Enke,
>>
>> thanks for the pointer. With this in mind, it makes perfectly sense 
>> then to have all bgp messages included rather than “cherry picking” some of them.
>>
>> Oliver
>>
>> On 3/7/17, 6:49 PM, "Enke Chen" <[e-mail]> wrote:
>>
>>     Please check out the following document:
>>
>>     Extended Optional Parameters Length for BGP OPEN Message
>>     draft-ietf-idr-ext-opt-param-02
>>
>>     -- Enke
>>
>>     On 3/7/17 3:44 PM, Borchert, Oliver (Fed) wrote:
>>     > I am wondering – according to RFC 4271, how can an OPEN message ever exceed 284 bytes?
>>     > The bgp message header has 19 bytes and the OPEN message payload adds 10. This is 29, then the only
>>     > addition here are the Optional Parameters which cannot exceed 
>> 255 bytes combined due to the 1 byte length field.
>>     >
>>     > Therefore, an open message cannot exceed 284 bytes and if larger than 284 bytes, wouldn’t it be invalid.
>>     >
>>     > In this regard, I don’t really understand the whole discussion about allowing an OPEN message larger than 4K.
>>     > It shouldn’t even be larger than 284 bytes?  Maybe I am missing something.
>>     >
>>     > BTW, same is true for KEEPALIVE (max 19 bytes)
>>     >
>>     > Oliver
>>     >
>>     >
>>     >
>>     > On 3/7/17, 1:45 PM, "Idr on behalf of Enke Chen" <[e-mail] on behalf of [e-mail]> wrote:
>>     >
>>     >     Hi, Folks:
>>     >
>>     >     o There is no extra work for a receiver to cover message types other than UPDATE.
>>     >     o There is a little bit work for a sender that wishes to send a large OPEN (e.g.,
>>     >       using the prior capability and possibly subsequent NOTIFICATION).
>>     >
>>     >     Additionally, I do not see a need to touch on the FSM specified in RFC 4271 even
>>     >     in the case of sending a large OPEN, which potentially may involve two separate
>>     >     consecutive sessions but each session would just follow the existing FSM.
>>     >
>>     >     Thanks.   -- Enke
>>     >
>>     >     On 3/7/17 7:32 AM, Susan Hares wrote:
>>     >     > Robert:
>>     >     >
>>     >     > <individual contributor’s hat on>
>>     >     >
>>     >     > Yep  - Easier to just include all messages.
>>     >     >
>>     >     >
>>     >     >
>>     >     > Sue
>>     >     >
>>     >     >
>>     >     >
>>     >     > *From:*[e-mail] [mailto:[e-mail]] *On Behalf Of *Robert Raszuk
>>     >     > *Sent:* Tuesday, March 7, 2017 10:33 AM
>>     >     > *To:* Susan Hares
>>     >     > *Cc:* Randy Bush; Enke Chen; Jeffrey Haas; Alvaro Retana (aretana); [e-mail]; draft-ietf-idr-
>> [e-mail]; idr wg
>>     >     > *Subject:* Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20
>>     >     >
>>     >     >
>>     >     >
>>     >     > Hi Sue,
>>     >     >
>>     >     >
>>     >     >
>>     >     >> My suggestion is to include all messages including future messages if approved.
>>     >     >
>>     >     >
>>     >     >
>>     >     > Ahh then it is great - we are in sync !
>>     >     >
>>     >     >
>>     >     >
>>     >     > My other comments were just an opinion ... but if it is easier to extend all messages then perfect.
>>     >     >
>>     >     >
>>     >     >
>>     >     > Cheers,
>>     >     >
>>     >     > R.
>>     >     >
>>     >     >
>>     >     >
>>     >     >
>>     >     >
>>     >
>>     >     _______________________________________________
>>     >     Idr mailing list
>>     >     [e-mail]
>>     >     https://www.ietf.org/mailman/listinfo/idr
>>     >
>>     >
>>
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr