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

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:idr-bounces@ietf.org] On Behalf Of Borchert, Oliver (Fed)
> Sent: Tuesday, March 07, 2017 5:21 PM
> To: Enke Chen (enkechen) <enkechen@cisco.com>
> Cc: 'idr wg' <idr@ietf.org>; draft-ietf-idr-bgp-extended-messages@ietf.org; 'Robert Raszuk' <robert@raszuk.net>;
> Susan Hares <shares@ndzh.com>; idr-chairs@ietf.org
> 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" <enkechen@cisco.com> 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" <idr-bounces@ietf.org on behalf of enkechen@cisco.com> 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:*rraszuk@gmail.com [mailto:rraszuk@gmail.com] *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); idr-chairs@ietf.org; draft-ietf-idr-
> bgp-extended-messages@ietf.org; 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
>     >     Idr@ietf.org
>     >     https://www.ietf.org/mailman/listinfo/idr
>     >
>     >
> 
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr