Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Fri, 24 July 2020 18:41 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 59AD83A11ED for <idr@ietfa.amsl.com>; Fri, 24 Jul 2020 11:41:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level:
X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 header.b=aGRI8t6b; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=KnokbEZv
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 ZT8-iqX76gpw for <idr@ietfa.amsl.com>; Fri, 24 Jul 2020 11:41:29 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3ED3A11EB for <idr@ietf.org>; Fri, 24 Jul 2020 11:41:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25603; q=dns/txt; s=iport; t=1595616089; x=1596825689; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=KH1Ut47itKojB3/byqMEdloosYx9uQVVeJndUmtChQk=; b=aGRI8t6beq2+cdmHqrC2nqo/jLfcIabTkF6BCCviyGSqDpEdNCg1rBNi AEo+DwIVLE9LVMwnPMX4E6ULPznshnI0R5A5jIOk2OWUYO757T5PyJ464 2KCUutd+CIb70TJ0I/SkHhqgo41bsyjaHponfNbmSHdPKODYjNlLvaNFZ Q=;
IronPort-PHdr: =?us-ascii?q?9a23=3Aq0/qGRXNsn73reQxiqhznBd7b7PV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBN+BufxZl/fMvr/tWCoL5pPS+HwBcZkZUR?= =?us-ascii?q?gDhI1WmgE7G8eKBAX9K+KidC01GslOFToHt3G2OERYAoDyMlvVpHDh4yMOBw?= =?us-ascii?q?/yKgd0YO/yH92ag8G+zevn/ZrVbk1Bjya8ZrUnKhKwoE3Ru8AajJEkJLw2z0?= =?us-ascii?q?7Co2BDfKJdwmY7KA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BJAADxKRtf/4QNJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTYHAQELAYEiL1EHb1gvLId5A4RYiH6YX4EugSUDVQsBAQE?= =?us-ascii?q?MAQEtAgQBAYRMAoIiAiQ0CQ4CAwEBCwEBBQEBAQIBBgRthVwMhXEBAQEBAxI?= =?us-ascii?q?bEwEBOA8CAQgRBAEBIQcHMhQJCAIEARIIGoMFgX5NAy4Bo3wCgTmIYXSBNIM?= =?us-ascii?q?BAQEFhTQYgg4JgTgBgmyKDxqBQT+BEUOCTT6BBIM7NIMTgi2PJBmJeIMaiDa?= =?us-ascii?q?QYgqCXY8Pin6Ce5xkkhSBaJ0sAgQCBAUCDgEBBYFTOoFXcBWDJFAXAg2OHoN?= =?us-ascii?q?xilZ0NwIGCAEBAwl8j0UBAQ?=
X-IronPort-AV: E=Sophos;i="5.75,391,1589241600"; d="scan'208,217";a="793518195"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jul 2020 18:41:28 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 06OIfSpq012627 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Jul 2020 18:41:28 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Jul 2020 13:41:27 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Jul 2020 14:41:26 -0400
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 24 Jul 2020 14:41:26 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Krx6ZFKCGdLVBAMrebHLt3hUm5c1jJmr49g4rLCFyQJHaHQPKQv2UH84rTlBBnPIC2U36fTLYNcEQPmqrU1BnbTRbntsZMDPe7b85KINu8gGi0996wLMmyb9Ix4eVLIJwuTKs4dPY02KFYzsF/1jFQ3Q9gLDBWJdmuPHRJkofRfDcx7uHjzMwKopVAMAZVj6Pgte2OpP0G+cMLiPQ4AthFvKbAkgTDERYFBWzAI4EwrAn+jtvbulKGMHKsK65iDSbz9iMcxFLRiPMdvAoehiA0ia8QTFkWepWOfdJNGW12erBgu8Vhs6JXV+exEHx6PDUS3S/jvmBknMaBNG//YfoQ==
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=XhaZagSlV/Yi+aa4zbS/J1yvUS5nJmP5Hapnr8cXb2Q=; b=fF7k0KD0p+U7kLS+2XK6e1KujlJ8Lm4Bv1e9AeXcPuHrK5ayPbGwAtifsY3nb8oF/BltfnTjJ9UgeyyPU2DoVJdIRHAy7DLSGGgeUFNR9bZRv3rl6cLye1J2RNkwhDWg2Ez0JOpFIMq5QyyVx8qH3NFhVJrjVfX0lK4g+jdoOe5RE0lniE7UgvxZ0PXCgVGDXF1hEmBKhEkPqM7tvF1/zsc+qaYj7yXoYAfVuMfd6NTv0CiW0/StlAQBRpibBongOB6BoMxqUVGuOMzY1DyyDS1qdUxVHAXPhIE8ded1MarUqyns3OnGQYpNkZKI6GlwIfuEsPXbD8RIrH1CxXyghA==
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=XhaZagSlV/Yi+aa4zbS/J1yvUS5nJmP5Hapnr8cXb2Q=; b=KnokbEZv3L0MNkGoNanY4bHV/fmXiC4uniVXTCa7DgCAcVjBxgfRNpd9XOLS8pjBjKco5ZZjehx8yebPdfD3VOpyHooi5jmxcJdr5aM9qWCJEgO3QdjUVEXQcbHsmvu36SCDYUAaa1hDrl8e8+loDSRvQU09Eir8AOW4TnlCnDs=
Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BY5PR11MB4244.namprd11.prod.outlook.com (2603:10b6:a03:1bb::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.20; Fri, 24 Jul 2020 18:41:25 +0000
Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::c0a8:f52f:8d8d:ebff]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::c0a8:f52f:8d8d:ebff%5]) with mapi id 15.20.3216.026; Fri, 24 Jul 2020 18:41:25 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Linda Dunbar <linda.dunbar@futurewei.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)
Thread-Index: AdZhId1/r8LrVew2ScuG2HA5ggcnOwABcDLQAAXhb+AAAB3+QAAAbrlAACNu3NAABkepIA==
Date: Fri, 24 Jul 2020 18:41:25 +0000
Message-ID: <BYAPR11MB3207CCB5E51A7F674956E54BC0770@BYAPR11MB3207.namprd11.prod.outlook.com>
References: <MN2PR13MB2768FA084068B2AC594FCF9F9A760@MN2PR13MB2768.namprd13.prod.outlook.com> <SN6PR13MB2334C4D7D54DE9D8F12F687E85760@SN6PR13MB2334.namprd13.prod.outlook.com> <BYAPR11MB32077F59F573D8A129EFB02AC0760@BYAPR11MB3207.namprd11.prod.outlook.com> <SN6PR13MB23346310695F957202320F2885760@SN6PR13MB2334.namprd13.prod.outlook.com> <BYAPR11MB3207A5A462FEE0CC07551943C0760@BYAPR11MB3207.namprd11.prod.outlook.com> <SN6PR13MB2334ED45BF23645D1AAE56E485770@SN6PR13MB2334.namprd13.prod.outlook.com>
In-Reply-To: <SN6PR13MB2334ED45BF23645D1AAE56E485770@SN6PR13MB2334.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2601:647:5701:46e0:4a3:1f38:ea7d:9e8c]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b7ce7244-5f6e-44a6-9a91-08d830012b70
x-ms-traffictypediagnostic: BY5PR11MB4244:
x-microsoft-antispam-prvs: <BY5PR11MB42449E80C7817E7DE048336BC0770@BY5PR11MB4244.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: z4ghJZcQVwHC7+uaT32HTh7CrnDSvPCOUzQh5F7mG8MMTw1RmaFvH/7/AqTjAKHg4GN+CDFKgcWaVuj00vMV6Cd/f95lM9gwyTon5KL5m1Tq5alHiyWqihCymrgJggk3lKiPNiNeCwUMjYy1dD7LSq2fqpMH8OxhkpItzFQdgY2gCgE+HU4yQbjScsmnKZc4SpaVfR1YEyZzfLyzev1A8pc3HLlNn6rs/dmZ2H82ctjSaIyv8bCc9ZxneuBdDJHYgpDcZJPAVfbzVg1GfGAozG4imoq23nQpdbbx3U4xLJFjFecc3q6ha40Bej1J9DLyryywA1Q3k3NNvYYQtGc/cQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3207.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(136003)(376002)(39860400002)(346002)(52536014)(478600001)(7696005)(71200400001)(6506007)(53546011)(186003)(8936002)(9686003)(83380400001)(55016002)(8676002)(316002)(86362001)(5660300002)(64756008)(66556008)(2906002)(110136005)(33656002)(66946007)(66446008)(66476007)(76116006); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: BlXkwAx35gNj3oKnOm95U8rrtmzkbUbpU+1YZo4SMP02oJ1u8nET6PFA3BCExr7p6pDoIJSprw9vdsiem2pOrFU26eTE7CFc0M8uebP2TcxBXtTmCse5LiS7rSx7LLHBfJhgZtC/ArPpjNPdY7c2OL/uHPoe4dtA2Isi971LrX56hmL9MKAlOItyi+2ohWftUUMHy2+Y7TNO0WI/O++kpLlzlaYyo+HcaQvvqVdcblYei7aXan5tp0i1pN5zf+gvS+EKrUoWaoEryuCz5K6efANwLP/WH2l3jylm8g4JcPDwrfVp/zyiToq4BxBaNeSCIUfRRxAJkhgxTP/n70m9YJ4VL1R0f2ku2BG0BcW4yqJWGp/Sx/EVI9zNjPSkFa0y9eEEIbplbCxTHJMa1dOc7BOViRxdbFOwSTlJJShaf4qWnubLfdfnGsiGA5Y+p4lM96fuV5MvoaNyAp9nenycSvkrwftjIbF0gyL42tdN/qJAhW3NpyZDof/C8KlZoxVT4MLALTcrCBzGsXGjdTx6/DA5NSNDrx5VmlgVYUKOcHQ=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB3207CCB5E51A7F674956E54BC0770BYAPR11MB3207namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3207.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b7ce7244-5f6e-44a6-9a91-08d830012b70
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2020 18:41:25.3876 (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: 1JomJMKkK9bpkCmmvjTF5VEcsl8Bdi9ZuNxi7gDIm89kG0zBaIUfd0gYaewTrmz8nAE1c8BM5ctxWYWG7shBvA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4244
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/aucrDc1P4LvrWSwgLyYfij7pihw>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)
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, 24 Jul 2020 18:41:34 -0000

The reason I'm comparing an apple with an orange is because you are building an apple
when you need an orange.
BGP, PCEP and Netconf all exist, because they solve different problems.
Netconf has the features needed to distribute route policy configurations
BGP does not.

Another feature:
Authentication.
You can't have just anyone configuring you devices.
Netconf is designed to run over SSH and TLS.
BGP is not.

About the "spray and pray":
This causes transient routing loops and other anomalies when distributing routes.
We have developed a litany of technologies designed to minimize these problems
for route distribution, such as FRR, LFA, PIC.

You will have transients if you distribute route policy configurations with BGP.
Have you studied the kinds of transients you will encounter and how you will
mitigate them?

Netconf is designed to allow configurations to be installed in a predictable order
and to respond properly to errors in configuration installation to avoid transients.
BGP is not.

Regards,
Jakob.

From: Linda Dunbar <linda.dunbar@futurewei.com>
Sent: Friday, July 24, 2020 9:29 AM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>om>; idr@ietf.org
Subject: RE: WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Jakob,

Comparing Netconf with BGP  is not apple to apple comparison.
I remember a few years ago that  Netconf advocators have claimed that Netconf can replace PCE, replace BGP, replace xx, ...

After many years debate,  many of the Netconf  limitations have been acknowledged,  that is why PCE still exists, so does BGP.

Other comments are inserted below:

From: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>
Sent: Thursday, July 23, 2020 5:37 PM
To: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>; idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Netconf provides needed features that BGP does not have:
- Atomic Transactions:
  If one configuration item fails, they all fail.
  They all either succeed or all fail. There is no partial success.
  Multiple configurations in one transaction are applied at the same time.
   . This avoids non-deterministic transient behavior between application of the first policy and the last.
[Linda] Just like Routes Advertisement, receivers can improperly install the routes into their RIB/FIB.  BGP has been running for over 3 decades. Those who don't implement correctly eventually fix their bugs.
 If the Policies sent to peers are not enforced  as the RPD is asking for,  traffic might be sent to non-preferred links, just like a BGP receiver incorrectly processes the BGP route updates.

- Feedback:
  BGP is "spray and pray".
  Netconf provides an acknowledgement that the config either failed or was applied,
  which then allows the controller to take the next steps with
  reliable information about what configuration exists in the network.

[Linda]  BGP UPDATE is over reliable TCP transport and BGP protocol itself can guarantee the proper distribution of the UDPATE. Therefore, its "spray and pray" nature has its advantage of optimized processing. BGP  Route Update doesn't expect confirmation from  the receivers.

- Persistence:
  If the BGP session were to go down, all the configuration it sent will be implicitly withdrawn.

If another AS would not allow a foreign AS to configure it with netconf,
it would not allow it with RPD either.
[Linda] That is very true. The originator can only "Pray" as BGP is intended for.

There are already ways in BGP for an AS to signal preference across AS boundaries:
Med, AS-path length, communities.

[Linda] All those methods you have mentioned require heavy duty configurations, which is difficult to change on the fly. The proposed method is a flexible method which allows policies to be changed on the fly (depending on real time traffic conditions).


Ketan and Robert added other objections.
[Linda] I have been studying their reasons for the objections.

Thank you very much for the explanation.

Linda Dunbar


Regards,
Jakob.

From: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>
Sent: Thursday, July 23, 2020 3:24 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>; idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Jakob,

Can you elaborate those automation configuration methods that are much better and less error prone than the proposed one?
It will take a long time to dig through so many IDR emails to find them.

Thank you very much,
Linda Dunbar

From: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>
Sent: Thursday, July 23, 2020 5:20 PM
To: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>; idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Of course it's better than manual configuration.
That's not much of an argument, because there are plenty of
automatic configuration methods that are much better and
less error prone than this draft as I and others have pointed
out in previous emails.

Regards,
Jakob.

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Linda Dunbar
Sent: Thursday, July 23, 2020 2:57 PM
To: idr@ietf.org<mailto:idr@ietf.org>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

I support the WGLC for the draft. I think the proposed distribution of policy can scale much better and less error prone than any manual configuration.