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

[Thomas Mangin <[e-mail]>]

Robert,

I do not have a login

1	Yes
2	Yes
3	Yes
4a	Yes
4b	Yes
5a	You can send extended UPDATE . So No ?
5b	Yes

Thomas

> On 21 Nov 2017, at 15:25, Robert Raszuk <[e-mail]> wrote:
> 
> Cool :) 
> 
> Care to add ExaBGP to the wiki ? 
> 
> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations <https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations>
> 
> Thx,
> R.
> 
> On Tue, Nov 21, 2017 at 4:21 PM, Thomas Mangin <[e-mail] <mailto:[e-mail]>> wrote:
> Your wish is my command: done !
> https://github.com/Exa-Networks/exabgp/commit/80612f0cef940d8f8b03b16f543c9173615188c5 <https://github.com/Exa-Networks/exabgp/commit/80612f0cef940d8f8b03b16f543c9173615188c5>
> 
> 
> Thomas
> 
>> On 21 Nov 2017, at 15:03, Robert Raszuk <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> My take would be to make it enabled by default (potentially with a knob to disable it if needed) .. otherwise we are creating even worse swiss cheese even among those implementations which do support it. 
>> 
>> Thx,
>> R.
>> 
>> On Tue, Nov 21, 2017 at 3:56 PM, Thomas Mangin <[e-mail] <mailto:[e-mail]>> wrote:
>> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
>>> 
>>> _______________________________________________
>>> Idr mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
>>> 
>>> 
>> 
>> 
>> _______________________________________________
>> Idr mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
> 
> _______________________________________________
> Idr mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr