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

Cool :)

Care to add ExaBGP to the wiki ?

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 <thomas.mangin@exa.net.uk>
wrote:

> Your wish is my command: done !
> https://github.com/Exa-Networks/exabgp/commit/
> 80612f0cef940d8f8b03b16f543c9173615188c5
>
>
> Thomas
>
> On 21 Nov 2017, at 15:03, Robert Raszuk <robert@raszuk.net> 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 <thomas.mangin@exa.net.uk>
> 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 <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
>>
>> Best,
>> Robert.
>>
>>
>> On Tue, Nov 21, 2017 at 11:26 AM, Thomas Mangin <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> 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
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>>
> _______________________________________________
> 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
>
>