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

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Wed, 15 November 2017 19:24 UTC

Return-Path: <jheitz@cisco.com>
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 F16F9126D74; Wed, 15 Nov 2017 11:24:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level:
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 PoEEzhnzxSXq; Wed, 15 Nov 2017 11:24:15 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB73C1200F3; Wed, 15 Nov 2017 11:24:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24334; q=dns/txt; s=iport; t=1510773854; x=1511983454; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dyRyJOrRzeunowMeuASUM6CDhqDpj203ORGnZQwNrxU=; b=eAFRSpZ5XQ8Lwp2506cypJP1pdF8tR28yiRpXWy++jR/knc57SZ40K54 lLZsWs+B+jFbyAx1mAd/NByMd213L5QfNfCpMe78cL1ITbXZjis5+L51i Yl/vxtz8lY4Wn8cfF+kdYv45UaD5CIsBFvEMJ6WHkgvmj9LLiWWk73pB0 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CbAAAJlAxa/4ENJK1eGQEBAQEBAQEBAQEBAQcBAQEBAYJERC5kbicHg3iKH48ggX2WXRCCAQoYAQqFGAIahHQ/GAEBAQEBAQEBAWsohR4BAQEEAQEhCkELEAIBCBEEAQEoAwICAiULFAkIAQEEAQ0FCIk4ZBCpeoInixABAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYM0ggeBVYReNYR4AQEGToJfgmMFii2JNYU8iRkClHuCHoYKiyWKM4tOAhEZAYE4AR84QoEyehVJgmSCXBwZgU53AYlagSSBEQEBAQ
X-IronPort-AV: E=Sophos; i="5.44,399,1505779200"; d="scan'208,217"; a="31400565"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2017 19:24:13 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vAFJODlj003315 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Nov 2017 19:24:13 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 15 Nov 2017 13:24:13 -0600
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1320.000; Wed, 15 Nov 2017 13:24:12 -0600
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Robert Raszuk <robert@raszuk.net>, Susan Hares <shares@ndzh.com>
CC: idr wg <idr@ietf.org>, "idr-ads@ietf.org" <idr-ads@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Thread-Topic: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)
Thread-Index: AdNcB5lUqir6ZylBRUe7xuFnWiyeYQCRCmeAAAKXf6A=
Date: Wed, 15 Nov 2017 19:24:12 +0000
Message-ID: <43b50b8982fe411fa275b294c210edfa@XCH-ALN-014.cisco.com>
References: <000901d35c08$3f12d950$bd388bf0$@ndzh.com> <CA+b+ER=PnW0-Qr9K4KTY4OAQC6-PQqRcbtc4yABXeRoz0xhw5A@mail.gmail.com>
In-Reply-To: <CA+b+ER=PnW0-Qr9K4KTY4OAQC6-PQqRcbtc4yABXeRoz0xhw5A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.32.47]
Content-Type: multipart/alternative; boundary="_000_43b50b8982fe411fa275b294c210edfaXCHALN014ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/AriFDt5t5auLNHApFh6F5RxYykk>
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: Wed, 15 Nov 2017 19:24:17 -0000

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.

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