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

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
>>
>>
>
>