Re: [Lsvr] FW: RtgDir Early Review: draft-ietf-lsvr-bgp-spf-02

Keyur Patel <keyur@arrcus.com> Wed, 13 November 2019 18:10 UTC

Return-Path: <keyur@arrcus.com>
X-Original-To: lsvr@ietfa.amsl.com
Delivered-To: lsvr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BB11200FA; Wed, 13 Nov 2019 10:10:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 yL44rf55Oufc; Wed, 13 Nov 2019 10:10:23 -0800 (PST)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-eopbgr800051.outbound.protection.outlook.com [40.107.80.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB161200D7; Wed, 13 Nov 2019 10:10:23 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kZUtMzoOkh1NI5FJt4ZimIlS59Is21dRpQwubySvGqaC5YoVBS511YsMzjYbLG+WPD3KYSO+Que8RTvd3T588ZQ1SUItJT0glg9hbJnXoHTI/k97n0OY+ieUbmkhlbJDNlPViJykF7X0pUymQ3hRR3LPtKsz5Z34W7HbiXY+XhvEAZZ3KrhvKBw69bVx/8FkdHH+9Vl4g+GyjL/zCPkYc9LkOYrZ9h9kmDQkJ+rXJ7w1NUZtqfuyKaasb1icM69d9s+CrBOcETTJ3qpSIniv2Taib7nOdTSfIfy1YeL9L0qgXn/eqokqxSFOYtwUMVonK3fJREcH3pmxlhctky+pPg==
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=zJdUhul6C0jbRw8cOVcEe29PzQvVneAm53DzUC5VGx8=; b=DbvKUGw30DOEswJiMvHLkRLRpuhPoZBwqeIMTqzeX7oWFbcZ5AgSdszVcfBto+LE5piOCw93RhWy1SgSWwd6jp3HMsmFKJ0aJo/gx9XJIydzgj5+thawb6X1uBGzkdewavDTd0AFLES6OyyLrJkXXTcpfevFI25n02oYRIzOnXNR+g7mGf31Qi7Rcdv986fezcly/JzPRKJOsQ7b7H6XBUOoie6bY/9GSGGt35eMv1SsksQxQ+crlQ65/ilGj7PPxoIgXzkQDnWxMw7amcbG5pSFN83eJ3bixUnhn4IPxenJ7p8PihNbyTFzvbmaswkKTi41juxtwXpSvLAfxDwU8g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zJdUhul6C0jbRw8cOVcEe29PzQvVneAm53DzUC5VGx8=; b=Uq229nGHCUyJ0tKY1jG5CMt3tgSH+rGxFXG1nEYh/L/lRPRsrZs6hacQJadObBVYJYG2whbwrflmK8a9IiarnxjM3Zrv6rUkk7ZyF+FzzFiW3M3YDGlWbjtEyNg9QBpdqaIfuqvamoXWgRn4n6AQkoLK0EeW/FpNG1DOuhGejMQ=
Received: from BYAPR18MB2856.namprd18.prod.outlook.com (20.179.59.30) by BYAPR18MB2887.namprd18.prod.outlook.com (20.179.56.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.20; Wed, 13 Nov 2019 18:10:20 +0000
Received: from BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::51d:21b6:1895:ec09]) by BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::51d:21b6:1895:ec09%5]) with mapi id 15.20.2430.028; Wed, 13 Nov 2019 18:10:20 +0000
From: Keyur Patel <keyur@arrcus.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, "frost@mm.st" <frost@mm.st>
CC: Routing Directorate <rtg-dir@ietf.org>, "lsvr@ietf.org" <lsvr@ietf.org>, Routing ADs <rtg-ads@tools.ietf.org>
Thread-Topic: [Lsvr] FW: RtgDir Early Review: draft-ietf-lsvr-bgp-spf-02
Thread-Index: AQHVmk2cygbb26ww40mJjxlwCf29iQ==
Date: Wed, 13 Nov 2019 18:10:20 +0000
Message-ID: <5BB8E7E8-558A-4AEA-8B73-96600025D270@arrcus.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com;
x-originating-ip: [70.234.233.187]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: adef2df1-1200-4b8b-a08f-08d76864bee5
x-ms-traffictypediagnostic: BYAPR18MB2887:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BYAPR18MB28872162E41AC6E997219BC5C1760@BYAPR18MB2887.namprd18.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0220D4B98D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(366004)(136003)(39830400003)(346002)(13464003)(189003)(199004)(52294003)(54906003)(508600001)(14454004)(229853002)(186003)(54896002)(26005)(6306002)(102836004)(966005)(6436002)(6486002)(5660300002)(606006)(99286004)(53546011)(110136005)(25786009)(2616005)(476003)(4326008)(6506007)(316002)(7736002)(6512007)(86362001)(8936002)(486006)(2501003)(8676002)(71200400001)(71190400001)(6246003)(66446008)(33656002)(36756003)(66066001)(3846002)(6116002)(14444005)(236005)(256004)(2906002)(81156014)(66946007)(76116006)(66476007)(66556008)(64756008)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2887; H:BYAPR18MB2856.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: qEvNYeTkiw2bcDUrHUFmTcBc1LWW12wnieHFFOxK2uHMT5XmR7xjYwPcs7kXWdAibYvldx/ETTcenXrpUSTgwijfNeN7pERDyKbTQx2qtBG+WzEoDveik7B9X+5DIIIIbiUW/ww7zOa8BDybBDxXW+4srwiNj/sFtzW5+5BsnN8fTlsgmO0chZstVLNsZErLS8lY4mdZwpAybdOguoL4uL9WzeRZVlc6eRkCs6w7BgXmwbGJFVpRiS/AlYOcqgqr2VS0OP4cz1Ew0C6iBhpF1u/HOBWL9+2PdDRGNkVeugIUBatlQ95F7U/W3J50Ggk/VaurgBQjsXCdS5gy8nTgU4pXSdG/rAYE4ifp+PJBQC4zhydI4b2lYxqDFdlrxE/7KHP/I3XyW4Y8504MMdcIpgi1sGxayl8677sVTAnyitt3cQWJCO1gc+aU8rmHXDo0+jp4FgTngwZDLH0SMwcz3TyrID7TCzEVGmZLWLAaxIc=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_5BB8E7E8558A4AEA8B7396600025D270arrcuscom_"
MIME-Version: 1.0
X-OriginatorOrg: arrcus.com
X-MS-Exchange-CrossTenant-Network-Message-Id: adef2df1-1200-4b8b-a08f-08d76864bee5
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2019 18:10:20.3473 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: O1cxKNwrRxUn6II5XMT78jXXpk2rFhLJbSH7A5tmc8kJZzEj7YSinQUSm05TgR55cDfpaTm61Y5Y2tBJvM3eyw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2887
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/9z_KGdwqHlmhnzD5HWrarmlSroU>
Subject: Re: [Lsvr] FW: RtgDir Early Review: draft-ietf-lsvr-bgp-spf-02
X-BeenThere: lsvr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Vector Routing <lsvr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsvr>, <mailto:lsvr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsvr/>
List-Post: <mailto:lsvr@ietf.org>
List-Help: <mailto:lsvr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsvr>, <mailto:lsvr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Nov 2019 18:10:28 -0000

Hi Dan, Gunter, Victor,

We believe that the current version of both drafts addresses all the comments received from RTGDIR early review.


  1.  https://datatracker.ietf.org/doc/draft-ietf-lsvr-applicability/

Peering models have been documented in section 6.2.


  1.  https://datatracker.ietf.org/doc/draft-ietf-lsvr-bgp-spf/


Section 4.4 and section 5.1 have been augmented.
Explicit text added to ignore MinRouteAdvertisementIntervalTimer (Note: All implementations AFAIK provide a knob to override the value)
Section 8: Management Considerations have been added.

Please let us know if you have comments/suggestions.

Regards,
Keyur

From: Lsvr <lsvr-bounces@ietf.org> on behalf of "Acee Lindem (acee)" <acee@cisco.com>
Date: Tuesday, September 3, 2019 at 7:29 AM
To: "frost@mm.st" <frost@mm.st>
Cc: Routing Directorate <rtg-dir@ietf.org>, "lsvr@ietf.org" <lsvr@ietf.org>, Routing ADs <rtg-ads@tools.ietf.org>
Subject: [Lsvr] FW: RtgDir Early Review: draft-ietf-lsvr-bgp-spf-02
Resent-From: <keyur@arrcus.com>

Hi Dan,

I guess we didn’t conclude this discussion on the list.

We believe the current version satisfies your non-AD comments. It includes a “Management Considerations” section.

https://datatracker.ietf.org/doc/draft-ietf-lsvr-bgp-spf/

Thanks,
Acee



-----Original Message----- C
From: Dan Frost <frost@mm.st><mailto:frost@mm.st&gt>;
Sent: Tuesday, August 21, 2018 16:18
To: rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>; draft-ietf-lsvr-bgp-spf.all@ietf.org<mailto:draft-ietf-lsvr-bgp-spf.all@ietf.org>
Cc: rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>
Subject: RtgDir Early Review: draft-ietf-lsvr-bgp-spf-02


Hello,

I have been selected to do a routing directorate "early" review of this draft.

https://datatracker.ietf.org/doc/draft-ietf-lsvr-bgp-spf

The routing directorate will, on request from the working group chair, perform an "early" review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft's lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached.

As this document has recently been adopted by the working group, my focus for the review is on providing a new perspective on the work, with the intention of catching any issues early on in the document's life cycle.

For more information about the Routing Directorate, please see https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-lsvr-bgp-spf-02
Reviewer: Dan Frost
Review Date: 2018-08-21
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG.

Comments:

This document proposes extensions to BGP that in effect allow it to operate as a shortest-path-first link-state routing protocol. The cited motivation is the wide deployment of BGP in large data-center networks, combined with the deficiencies of BGP when deployed in said networks. Admirably, the authors avoid any hint of irony when describing this state of affairs.

Taking its premise as given, the draft is clear and well-written, addressing important details but remaining concise throughout. The Introduction (Section 1) is particularly good, providing the necessary context and relevant references.

A few further comments:

- This comment is primarily intended for the ADs and not specific to this draft. For quite a long time now, the IETF has been in the mode of extending BGP to carry ever more diverse forms of data, some of which are, at best, tenuously connected to routing. BGP is being used as an ad hoc distributed general-purpose database because of its flexibility, deployment scale, and implementation maturity. In many ways this is a testament to the robustness of BGP's design and the ingenuity of engineers faced with an ever-growing list of requirements to share more and more data. The fact remains, though, that BGP was not designed to be a general-purpose distributed database. With every new BGP extension RFC that adds a few more AFI/SAFIs and TLVs and a new set of processing rules, this becomes more painfully obvious. At some point (preferably 20 years ago) we need to look beyond the tactical level and produce or adopt a solution designed to address the root problem and fit to last for the next 50 years. There's a strategic hole of monumental proportions here.

- Section 2 on Peering Models is a little too brief. The draft would benefit from expanded discussion of the possibilities here and some detailed examples. Alternatively, this could be the focus of a separate document.

- The usage of the sequence number discussed in Sections 4.4 and 5.1 is not entirely clear to me from the text, particularly the implications of a sequence number reset. Some examples as to how convergence works in this case would help.

- The third paragraph of Section 5 states, regarding rapid propagation of changed NLRI: "To accomplish this, the MinRouteAdvertisementIntervalTimer and MinRouteAdvertisementIntervalTimer [RFC4271] are not applicable to the BGP-LS-SPF SAFI." For one thing the same timer is listed twice here. More generally, since BGP SPF routing is apparently not going to be governed by the usual BGP timers, a more complete specification is needed here. Any deviations should be itemized and thoroughly documented. Do new timers and knobs specific to BGP SPF need to be introduced? How is the operator expected to control these parameters?

- A Manageability Considerations section for the benefit of operators seems particularly important given the deviations of BGP SPF from classic BGP operation. This should summarize, at least, things like timer differences, applicability or non-applicability of specific policy mechanisms, impact of restarts and sequence number resets, and any new configuration parameters that implementations should provide and operators should be aware of.

Cheers,
-d