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

RFC 4271 does not address the issue, because at the time there were no features that required messages longer than 4096 octets. Exceeding the maximum message length just didn't happen. Now, it needs to be addressed.

Thanks,
Jakob

-----Original Message-----
From: heasley [mailto:heas@shrubbery.net] 
Sent: Wednesday, November 15, 2017 7:44 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: Robert Raszuk <robert@raszuk.net>; Susan Hares <shares@ndzh.com>; idr wg <idr@ietf.org>; idr-ads@ietf.org; idr-chairs@ietf.org
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

Wed, Nov 15, 2017 at 07:24:12PM +0000, Jakob Heitz (jheitz):
> Good point Robert. How about adding something like:
> 
> Certain features used by some BGP speakers require the use of extended messages.
> Such features are indicated with a BGP capability.
> If a BGP speaker sends an extended message to a second speaker, but that message
> does not use a feature that requires extended messages, then the contents of that
> message may not be distributed correctly throughout the BGP space to which that content is targeted.
> This is because while the immediate neighbor speaker may support extended messages, every
> BGP speaker within the said BGP space might not support extended messages.
> 
> For example, a certain BGP feature requires the use of a large BGP attribute.
> This feature is not supported by every BGP speaker within a BGP space.
> BGP updates with the large attribute removed might be acceptable to speakers
> that do not support the feature, even though functionality is reduced without the feature.
> If such a BGP update is longer than 4096 octets when the
> large attribute is removed, then it cannot be distributed to those speakers.
> 
> To prevent the failures outlined above, a BGP speaker SHOULD not generate a message
> that is longer than 4096 octets if a feature that requires extended messages is not used.
> Furthermore, a BGP speaker SHOULD not generate a message that cannot be reduced to
> 4096 octets or less by another speaker that needs to remove the feature that requires
> extended messages.

A feature that requires large attributes would also require extended messages
and if the capabilities do not reflect both, I expect the open would fail and
the capability would be excluded subsequently.  Are there features requiring
extended communities that are not themselves represented by a capability?
Implying that those attributes would naturally be removed, leaving the normal
reduction of NLRI to fit within the former msg limit?

not that some manner of feedback is not necessary.  a route could contain a
mix of community attributes leading it to exceed the former msg limit.  And
4271 offers no direction for that case either.  I expect the update to be
discarded and a trap and syslog is generated, but I do not know.

> Thanks,
> Jakob
> 
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
> Sent: Wednesday, November 15, 2017 5:56 AM
> To: Susan Hares <shares@ndzh.com>
> Cc: idr wg <idr@ietf.org>; idr-ads@ietf.org; idr-chairs@ietf.org
> Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)
> 
> Hi,
> 
> I am concerned with the lack of clear description of what router which supports extended msg should do
> when on one side he receives an attribute bigger then 4K and not of all it's peers can handle it.
> 
> IMO the below statement is true but a bit too vague:
> 
> "Therefore putting an attribute which can not be decomposed to 4096 octets or less in an
> 
>    Extended Message is a likely path to routing failure.
> 
> "
> 
> 
> 
> And the worst part is that the BGP speaker which in fact generated
> 
> such attribute 
> 
> be it on purpose or by error will not find out that its propagation has
> 
> failed one or N hops away.
> 
> 
> 
> Today when one is trying to inject msg over 4K (say due to a bug) it will fail locally,
> 
> generate syslog etc ... 
> 
> 
> 
> 
> 
> Any comments from authors and WG on that ?
> 
> 
> 
> Thx,
> 
> R.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Sun, Nov 12, 2017 at 11:47 PM, 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
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org<mailto:Idr@ietf.org>
> https://www.ietf.org/mailman/listinfo/idr
> 

> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr