Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

"Enke Chen (enkechen)" <enkechen@cisco.com> Fri, 09 August 2019 16:31 UTC

Return-Path: <enkechen@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 5FB2B12002E; Fri, 9 Aug 2019 09:31:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, SPF_PASS=-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 header.b=lMdVNdb5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=n0NONy0H
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 RhLATM8DPV5m; Fri, 9 Aug 2019 09:31:26 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8556120019; Fri, 9 Aug 2019 09:31:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34349; q=dns/txt; s=iport; t=1565368286; x=1566577886; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YLgK10tkkM3yObcYd1KGjoT8/bjyDsgZMfwuCKSvSFE=; b=lMdVNdb58XoxTk8G6/wA1vlz/C0M62ifS0Kv7zg9bcdYv4VYy0fz7DMB x5ZblXIK/LDN6NIi4LL+gdoDNG3wj+OVXar66tI0+FSF/nLbtYLAUKmie 5QKmxtPGJG0MldLg48r7eYmaPtGSvCWop3cgFYABzaqqJRElOjBNXxvQ7 c=;
IronPort-PHdr: =?us-ascii?q?9a23=3ABh5riRYLu2Fw/cwaLrdfVJf/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavnaS83F8RPUndu/mqwNg5eH8OtL1A=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAAAzn01d/4UNJK1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAMBAQEBAQsBgRUvUANtVSAECyqDXkCDRwOLEII2JX6?= =?us-ascii?q?IXY4GgS4UgRADVAkBAQEMAQEYAQwIAgEBhD8CF4JKIzUIDgEEAQEEAQEEAQp?= =?us-ascii?q?thScMhUoBAQEBAwEBCgYRHQEBLAsBDwIBBgIRAwECIQcDAgICHwYLFAkIAgQ?= =?us-ascii?q?BDQUigwABgR1NAx0BDgOPZZBhAoE4iGBygTKCegEBBYEzAYNkDQuCFAMGgTQ?= =?us-ascii?q?Bi2MXgUA/gREnDBOCFzU+ghpHAQECAYEmIDgNCYJVMoImjDaBEIEZMYUMiQG?= =?us-ascii?q?NbEAJAoIdhmKJVIN5G4Iwhy+OWY1RgTaGKIF4jikCBAIEBQIOAQEFgVIBNYF?= =?us-ascii?q?YcBU7KgEvghIJgjmDcoUUhT9yAQEBgSaNZgEB?=
X-IronPort-AV: E=Sophos;i="5.64,364,1559520000"; d="scan'208,217";a="307764303"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Aug 2019 16:31:24 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x79GVOk7031397 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Aug 2019 16:31:24 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 9 Aug 2019 11:31:24 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 9 Aug 2019 12:31:21 -0400
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 9 Aug 2019 11:31:21 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Sm+EYs3HfQq6gsYuGjYxLvz21Wd6uM1h4BfVaIq1tLrSEkLFuG8FX1yup8SzFJ6Oro4nz32Y2C8xqwsLmnkz023HVo3sXWUCN5y3uuEHhi6oSOVdUjG7di2rNvGzeengBZnOPQWu1D9PA92JoMgIKK0Yhud+aTga+BYurNvpBpqfYI+BJVrMYSRETJIZbEmHpLGOXalYfuCswHiELUNEZiK4HxrQETMINlEBqn+FoX/zKd5cUaXgHDeH6iQ27mvyGydL7HdB/Vh9xEyezlj2jna3IeZ/cGRTAEWGofsP5pSJFsihWizOUhsi7A9Y4uK9sQWy/QG1YRA7bFqv9afLdQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YLgK10tkkM3yObcYd1KGjoT8/bjyDsgZMfwuCKSvSFE=; b=gwK9RwXwUDWswq6+kn9exc8k8OSbDP/RihbB26kLkzvIzd4m8TQr0dnC8cHKq64BiEk5Skf34U3lsGw0fDa++/DzFXJPnIX4uGarSaurqI4YWgZqUpOMM8JpNtGWJULf7cN2/3Ki7t+jkoaZZBQxmjuX6NkfhIuFrUwvOM4Mzp+aMTeHQJkObwTeqmd+gPonvjTclpqqBt3tcagwTOS4r7EF7S4XoEZ87Kg9e10drnGenvLaAqfVwMHHdybDDufDkxDIapib/akGopJSu3m5k2OjpzUOb5Sfk/Hh8Fj6PcVXf3DOkbCvOtmO6w/DGvlWeyMt69+uP68KRcjmTTzAJQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YLgK10tkkM3yObcYd1KGjoT8/bjyDsgZMfwuCKSvSFE=; b=n0NONy0HyHnQDyzMalP2MlMsPNQwQbeGj08SCijbGKczeyhd5CD7RqiO/vHa/mtbCIR7BLiE0T8nRRoRl6He+yxYt9n72T4pzVpWcXw5XqwbDqGMg0FU6XqZc3pzcPMyIsHMFPfWc+FXO0/zM8jx4AonsytjYxwBC2Yi8/D3BM0=
Received: from BY5PR11MB3990.namprd11.prod.outlook.com (10.255.162.95) by BY5PR11MB4276.namprd11.prod.outlook.com (52.132.252.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.16; Fri, 9 Aug 2019 16:31:20 +0000
Received: from BY5PR11MB3990.namprd11.prod.outlook.com ([fe80::f45d:7bcf:e344:af99]) by BY5PR11MB3990.namprd11.prod.outlook.com ([fe80::f45d:7bcf:e344:af99%6]) with mapi id 15.20.2136.022; Fri, 9 Aug 2019 16:31:20 +0000
From: "Enke Chen (enkechen)" <enkechen@cisco.com>
To: Robert Raszuk <robert@raszuk.net>, Alvaro Retana <aretana.ietf@gmail.com>
CC: "idr@ietf. org" <idr@ietf.org>, "draft-ietf-idr-bgp-extended-messages@ietf.org" <draft-ietf-idr-bgp-extended-messages@ietf.org>, Susan Hares <shares@ndzh.com>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "Enke Chen (enkechen)" <enkechen@cisco.com>
Thread-Topic: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages
Thread-Index: AQHVR9vBZYyS0SwmxEOAkc+tFB2gRaby3MSAgAAw9QD//4z0AA==
Date: Fri, 9 Aug 2019 16:31:20 +0000
Message-ID: <8BE36C2B-5B31-4416-A076-F498B94EC60A@cisco.com>
References: <CAMMESsyvuU8_dBOeoOXPBt=-HwoF0eHvYgm5d8CgF-4o_oiP=g@mail.gmail.com> <CAMMESszw4PGXdQ+r0xhJaXMWF1J+BFxG_U3FPVrGBgnCTYdHNg@mail.gmail.com> <CAOj+MMEJv3K3juuy9FWthMB-Yk7tYuU08D_wQ6h3gdo8q4dtqg@mail.gmail.com>
In-Reply-To: <CAOj+MMEJv3K3juuy9FWthMB-Yk7tYuU08D_wQ6h3gdo8q4dtqg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1b.0.190715
authentication-results: spf=none (sender IP is ) smtp.mailfrom=enkechen@cisco.com;
x-originating-ip: [2001:420:c0c8:1004::394]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 57e53d79-ba55-4c4e-60fe-08d71ce702d1
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BY5PR11MB4276;
x-ms-traffictypediagnostic: BY5PR11MB4276:
x-ms-exchange-purlcount: 6
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BY5PR11MB4276D474312A0CD1CAA11E7AC5D60@BY5PR11MB4276.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01244308DF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(39860400002)(376002)(346002)(396003)(189003)(52084003)(199004)(6116002)(8676002)(2616005)(14444005)(7736002)(476003)(256004)(236005)(6306002)(54896002)(6512007)(53936002)(46003)(11346002)(446003)(478600001)(66476007)(66556008)(64756008)(66446008)(186003)(66946007)(76116006)(7110500001)(6246003)(966005)(81166006)(81156014)(53546011)(99286004)(4326008)(76176011)(71200400001)(110136005)(229853002)(58126008)(71190400001)(33656002)(6436002)(25786009)(102836004)(54906003)(107886003)(606006)(5660300002)(5070765005)(86362001)(561944003)(486006)(36756003)(14454004)(316002)(15650500001)(6506007)(6486002)(2420400007)(8936002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR11MB4276; H:BY5PR11MB3990.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: FlomcyTABurE7xsPbHIIy5kTXucf8CecKg90VtgnLymgA58LyDLNr3NyCyAjBD3y6Viqb+1oUVrDti2EmT48jmJmXDzsc2EeaF4LKrxmWBKi6m8CjwBNew0X2nnngsapJc2uXQue3fOu7KZ2AS4UAJEMdsjUNT/cU+H7JrWkIYnZO8Q3k0Jpg3nAQ87oEIWZ2zLQpabKmpITSRdnAKoQxvOzKyeM9dl2T0Udbo1JmdWoxTgp0maYm5ASSbTQho0Ua6Kwe0kL4eHQIQLxHlzr/ne9yjV18qS22yMWqln3LjwMY65HtLoCul0wUzaQHRnP1e7SYaveitvV51yZO37rD8xmsL02Hbp6Lw7nvoKgrXZidEA/uJlJ669SEdMrS5JJM5x126BWBGBKlrGgakmfVAPOYvO+ZRiFn2WH9py8u2c=
Content-Type: multipart/alternative; boundary="_000_8BE36C2B5B314416A076F498B94EC60Aciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 57e53d79-ba55-4c4e-60fe-08d71ce702d1
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2019 16:31:20.4115 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: enkechen@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4276
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.22, xch-aln-012.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/jbMioX0q6PN0VR1Lz8P1xTYK7ag>
Subject: Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 09 Aug 2019 16:31:30 -0000

Hi, Robert:

If “A” sends a large message to “B”, and requests “B” to play back. Then “A” has to advertise the
Large Message capability.   Is that not intuitive or logical?

Thanks.  -- Enke

From: Idr <idr-bounces@ietf.org>; on behalf of Robert Raszuk <robert@raszuk.net>;
Date: Friday, August 9, 2019 at 9:24 AM
To: Alvaro Retana <aretana.ietf@gmail.com>;
Cc: "idr@ietf. org" <idr@ietf.org>;, "draft-ietf-idr-bgp-extended-messages@ietf.org"; <draft-ietf-idr-bgp-extended-messages@ietf.org>;, Susan Hares <shares@ndzh.com>;, "idr-chairs@ietf.org"; <idr-chairs@ietf.org>;
Subject: Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

Hi Alvaro,

So imagine that BGP Operational Message draft get's standardized and one TLV will ask to replay back the received message to the sender.

Example: 3.4.3.3<https://tools.ietf.org/html/draft-ietf-idr-operational-message-00#section-3.4.3.3>;. Malformed Update Dump (MUD)

How is this going to work in this case when I receive over 4K PDU and can not mirror it back to sender per his request ?

Aren't we getting ourselves into the trap here and "Oooops" condition by allowing this asymmetry ?

Thx,
R.


On Fri, Aug 9, 2019 at 9:28 AM Alvaro Retana <aretana.ietf@gmail.com<mailto:aretana.ietf@gmail.com>> wrote:
Hi!

Thank you for everyone’s opinion and discussion!

The current text in -35 says this:

   A BGP speaker that is capable of receiving BGP Extended Messages
   SHOULD advertise the BGP Extended Message Capability to its peers
   using BGP Capabilities Advertisement [RFC5492].  A BGP speaker MAY
   send Extended Messages to a peer only if the Extended Message
   Capability was received from that peer.

   An implementation that advertises the BGP Extended Message capability
   MUST be capable of receiving a message with a Length up to and
   including 65,535 octets.


From the thread, the consensus is to keep the asymmetric capability advertisement.  As written, operators have the flexibility to advertise (or not) the capability to meet their local policy.


Jeff brought up the point that rfc4271 (§6.3 / UPDATE Message Error Handling) says that, for some errors, the NOTIFICATION "Data field MUST contain the attribute (type, length, and value)."  The problem is that if an Extended UPDATE (> 4k) with an erroneous attribute is received from a speaker that hasn't advertised the Capability (which is ok because of the asymmetry), then that peer may not be able to handle an Extended NOTIFICATION (> 4k).

NEW (to be inserted as the 3rd paragraph in §5 (Error Handling))>
   The UPDATE Message Error Handling, as specified in Section 6.3 of [RFC4271],
   is not changed.  However, if a NOTIFICATION is to be sent to a BGP speaker
   that hasn't advertised the BGP Extended Message Capability, the maximum size
   of the message MUST NOT exceed 4096 octets.


Authors: If no word-smithing suggestions are received in the next couple of days, please submit a revised draft by the middle of next week.

Thanks!

Alvaro.


On July 31, 2019 at 4:06:04 PM, Alvaro Retana (aretana.ietf@gmail.com<mailto:aretana.ietf@gmail.com>) wrote:
On July 31, 2019 at 1:31:11 PM, Susan Hares (shares@ndzh.com<mailto:shares@ndzh.com>) wrote:

Dear WG:

As I hope all of you know, the Extended Messages draft is being processed by the IESG.

Enke had brought up [1] some confusion in the text in rfc5492 related to the need, or not, for both BGP speakers to advertise a Capability before it can be used.  I discussed this point with Enke and John Scudder last week in Montreal — we looked at the text in the RFC and how recent Capabilities had been specified — and concluded that the intent of the RFC was to require at least one speaker to advertise the Capability…but that it should be the responsibility of any document defining a Capability to explicitly specify any changes.

IOW, in some cases it may be enough for one of the peers to advertise a Capability, but in other cases it may be required for both to do so.  [Enke/John will work on an Update to rfc5492 to clarify.]

Related to Extended Messages, here’s is what Enke proposed on the list [2]:

   As long as Speaker A is able and willing to receive large messages (by advertising
   the capability), its neighbor would be allowed to send such messages to Speaker A.
   Such behavior does not depend on whether Speaker A is able / willing / need to
   send any large messages to its neighbors.


We have modified the text in draft-ietf-idr-bgp-extended-messages to reflect Enke’s proposal (from -35):

   A BGP speaker that is capable of receiving BGP Extended Messages
   SHOULD advertise the BGP Extended Message Capability to its peers
   using BGP Capabilities Advertisement [RFC5492].  A BGP speaker MAY
   send Extended Messages to a peer only if the Extended Message
   Capability was received from that peer.

   An implementation that advertises the BGP Extended Message capability
   MUST be capable of receiving a message with a Length up to and
   including 65,535 octets.


During the IESG Evaluation, Sue pointed out that we removed the piece of text below:

Just to let you know that the text below:

“A peer which does not advertise this capability MUST NOT send BGP
   Extended Messages, and BGP Extended Messages MUST NOT be sent to it.”

was added due to comments on the IDR WG list from reviewers and operators.

Given that Extended Messages is a very important extension to BGP, and even though I didn’t see objections in the thread mentioned above, I want to confirm one more time that the current text is ok with the WG.  The effective change is really related to the piece that says "A peer which does not advertise this capability MUST NOT send BGP Extended Messages”, which would require that both peers advertise the Capability before it can be used.

Please reply with any comments by end-of-day on August 8, 2019.  Please explain any arguments against what is currently specified in -35.   The document is scheduled to be considered by the IESG on Aug/8, but I will hold approving publication until there is consensus on this thread.

Thanks!

Alvaro.

[1] https://mailarchive.ietf.org/arch/msg/idr/vaBLOKHQZlRCiJOMTT8VjJrWp7c
[2] https://mailarchive.ietf.org/arch/msg/idr/K5rA5rVci6VhMv5-UqXXaoRlvXo
_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr