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

heasley <heas@shrubbery.net> Thu, 16 November 2017 03:43 UTC

Return-Path: <heas@shrubbery.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4514212948A; Wed, 15 Nov 2017 19:43:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2-80rtTQ5ox; Wed, 15 Nov 2017 19:43:50 -0800 (PST)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352E012945D; Wed, 15 Nov 2017 19:43:50 -0800 (PST)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id A5FB35C923; Thu, 16 Nov 2017 03:43:49 +0000 (UTC)
Date: Thu, 16 Nov 2017 03:43:49 +0000
From: heasley <heas@shrubbery.net>
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-ads@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Message-ID: <20171116034349.GC43959@shrubbery.net>
References: <000901d35c08$3f12d950$bd388bf0$@ndzh.com> <CA+b+ER=PnW0-Qr9K4KTY4OAQC6-PQqRcbtc4yABXeRoz0xhw5A@mail.gmail.com> <43b50b8982fe411fa275b294c210edfa@XCH-ALN-014.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <43b50b8982fe411fa275b294c210edfa@XCH-ALN-014.cisco.com>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.9.1 (2017-09-22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/8gxieyLDAHAX8pH2vafwNAgUZow>
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2017 03:43:52 -0000

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