Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

Hello Robert,

As this is a capability, it is an option to be enabled per neighbour.

I thought it made sense to give the user control of this option: one may not want to enable the feature - and therefore they should be able to do so IMHO.

Thomas

> On 21 Nov 2017, at 14:22, Robert Raszuk <robert@raszuk.net> wrote:
> 
> Hi Thomas,
> 
> Great that you implemented it in ExaBGP. Is it on by default or do you need a global/per peer knob ? 
> 
> - - - 
> 
> As to your point that even today you may have the same problem ... well if you consider the problem to be interworking between peers when one is already receiving 4K update and want to add more stuff ... you are right it can fail today. 
> 
> But this is not the main problem I am pointing out. The problem is that in the above case the local guy who is adding stuff to existing update will locally and immediately know that it failed. 
> 
> In the new model it is nodes far far away who happily injected larger then 4K update messages will never know that their updates never made it through as they intended.
> 
> And since IDR and community failed to progress OPERATIONAL MSG in BGP providing a bit of a ops feedback between peers and perhaps beyond we are where we are. https://goo.gl/JTpQDc <https://goo.gl/JTpQDc>
> 
> Best,
> Robert.
> 
> 
> On Tue, Nov 21, 2017 at 11:26 AM, Thomas Mangin <thomas.mangin@exa.net.uk <mailto:thomas.mangin@exa.net.uk>> wrote:
> Hello Everyone,
> 
> I support the draft; and I therefore implemented it on ExaBGP master.
> 
> I am will keep an eye on the discussion regarding the potential issue transiting messages with larger than 4k total attributes size could cause. 
> 
> I would have no objection myself on seeing an arbitrary limit on the Total Path Attribute set to prevent backward compatibility as the most likely quick win is going to be on packing more NLRI ATM.
> 
> That said, I am not aware of any guideline in previous RFC to cover this issue and it is already possible to encounter this problem today. So while the draft make the issue more likely, it does not make things worse from a specification POV.
> 
> I am therefore wondering if this should not be covered by another unrelated RFC as it can affect current speakers and is not specific to this draft.
> 
> Sincerely,
> 
> Thomas
> 
>> On 12 Nov 2017, at 22:47, Susan Hares <shares@ndzh.com <mailto:shares@ndzh.com>> wrote:
>> 
>> This begins a 2 week WG LC for draft-ietf-idr-bgp-extended-messages (11/12 to 11/26).  Please note this draft has at least 2 implementations.    Please comment on whether you feel this draft is ready for publication.   
>>  
>> Susan Hares 
>>  
>> PS – the request for this WG LC is at:
>> https://www.ietf.org/mail-archive/web/idr/current/msg18801.html <https://www.ietf.org/mail-archive/web/idr/current/msg18801.html>
>>  
>>  
>>  
>>  
>>  
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org <mailto:Idr@ietf.org>
>> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org <mailto:Idr@ietf.org>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
> 