Re: [Idr] WG Last call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)

Huaimo Chen <huaimo.chen@futurewei.com> Tue, 03 August 2021 03:23 UTC

Return-Path: <huaimo.chen@futurewei.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 141353A0D8B for <idr@ietfa.amsl.com>; Mon, 2 Aug 2021 20:23:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 v5a_4BAUxMo2 for <idr@ietfa.amsl.com>; Mon, 2 Aug 2021 20:23:48 -0700 (PDT)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2134.outbound.protection.outlook.com [40.107.244.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5543A0D82 for <idr@ietf.org>; Mon, 2 Aug 2021 20:23:48 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ESEr2D1edLqXW79mWBtvLTIIkgkVbxrIJjGV2K5tPIeCStGuvskvUygFtYLSEHgIGtDHdguIMwcf3wYpQzDxV2qORNvfyTzRg2W+f3sa7hp9OVc5OpQqqPiJGec8lhEIzeNc6sIeHAQz36LyMHzmbYxwy1wrkyT+7mfBtXoTBFdcZAJLr2mtSSF8LpsICflrXFIct7jHo6rwlgMYHy8F1nEkE1AKqX3hMwtS1HMsm7y5awIZf1nV8pyiqXoHM7JrsirkW7E0BNcxWxVLyBNF80JiM51GpX6UOmu1hC2yHNC5A3O9M4uZdPODfKoI5VUGgMReRKeWLMED2dqYlzNCVA==
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=YKuYG5bAT3J+wjtGmzLmOA0y5uHSa9rWYc7tLqz7zJY=; b=n2xM0/pWR6/RsqYl5G+N+ij8v/EYctz5AH5k9PwgN1TGRmyyETBbzvXaqYsWiRG2B4UDXAWAxDLGCgTboOw+ji3fjKMi83ED7oc/K0ax119alOO8/kGLMhyYJd91RgZaAaIsubOs3l6rzrb6Z81S7UpYmBtltc1CoqEnZ31e+JGYistltPbNpwA6uuhouULZlONzcm4eEi+Hi3w/aU+eneJ7AGYWxZhRgoUrz4Or4qJaO+KyZ1OjCviShVfpfyo6u3tBGWzcQi2znKghlB5im3J/xRIsF6I8IXf+oN9eRJFa33FZgGet9wZ/SiBqDzy/5ukjKMxrnDhBbzY/1cNR6w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YKuYG5bAT3J+wjtGmzLmOA0y5uHSa9rWYc7tLqz7zJY=; b=A8wXEyp5cdS5OKLum+S9/JQ5y0xUrq7+JGxZO4eyHYrCRsgeSCy+I58xYi9+E8ie8HITSWMggZbgdeawcRwQwD1IoqIG2lYTbnS8MsqDhz99ozQ7aErrwC6OpgquoVEbXAKtwNaJt/r48ST5X1RQhuVouV71N1Dx/2qx8tZRwd4=
Received: from BY3PR13MB5044.namprd13.prod.outlook.com (2603:10b6:a03:362::22) by BY5PR13MB4549.namprd13.prod.outlook.com (2603:10b6:a03:1c6::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.9; Tue, 3 Aug 2021 03:23:45 +0000
Received: from BY3PR13MB5044.namprd13.prod.outlook.com ([fe80::8892:9918:1d4f:e5ca]) by BY3PR13MB5044.namprd13.prod.outlook.com ([fe80::8892:9918:1d4f:e5ca%4]) with mapi id 15.20.4394.015; Tue, 3 Aug 2021 03:23:45 +0000
From: Huaimo Chen <huaimo.chen@futurewei.com>
To: "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>, Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] WG Last call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)
Thread-Index: AdeFT1W0wKASwuKtQzCnplILtGZelgCxkycK
Date: Tue, 3 Aug 2021 03:23:45 +0000
Message-ID: <BY3PR13MB5044D4EB61DEA050A9151166F2F09@BY3PR13MB5044.namprd13.prod.outlook.com>
References: <MW3PR11MB457097DCB9C86BA70D826C50C1EC9@MW3PR11MB4570.namprd11.prod.outlook.com>
In-Reply-To: <MW3PR11MB457097DCB9C86BA70D826C50C1EC9@MW3PR11MB4570.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=futurewei.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5b072be3-8ad1-451f-f032-08d9562e19f4
x-ms-traffictypediagnostic: BY5PR13MB4549:
x-microsoft-antispam-prvs: <BY5PR13MB454966DE3B2FC8606B40B502F2F09@BY5PR13MB4549.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: mVM7xdSkOFyeoNa4sT3uVg6DqMbhTMCBi5CyvMpSA5IFKSR4I7PbB6GbUDRXyks3XMx//VK7omL26r1Pf5FGv1Ujtujap06EpPsKgV7QKdNsxq2Csha0ifSV79GLEkj/t1vW8S3/Fi312vO+VoB3PdOH6iAoy9bQVdEZpi4JWIDDGdlcjey2NL5DU4oX8AZEg3+n4xK5Xg7kC+Veh+NKkbWqRzcIyxkOgkdJGJFWdvQ0owfuxIi6prNnOHG+CzcOS0HB2dloTZzxn3S2br2zt3dFBavtmAkJv235RjFqEYkR77S2SntICy6CU6Tue1+sRUL7Ggis1270/bSsfCrpkCyTUTtvyGRNCc8Rt1JtvV4Bz5PhJzrejAAVB6Myvxv501mzH1rr8UfSQu3jhtGYOEmcOm7qMN/Q0+N9WyVz2c/i6k46CSZahPVYM0Brxyr916yQChsQM+EGOpZZC2IkyZ+ZdkszHnl6O9qWtdzD3dC6Thx8qOWTlchQJv4vpP31jQJ5MonM3fsvnWjBuwMGHfMj5Z6f7UeLLVx3hIGW4Sj1E6P8iTMUA2hiVzgUPIhUMCXTt+/l14w3PdGV1+mnyG77LMCQjW6PEU6IyNc6kl2nQ7B6dgDsS00BJitEOIT8aYMNLcdENwA+wQNbxBSSbhKd3DboppCP22wUnyLhaU18vjxXW+IVdcC5Y2T3muhxwxXEcliKqGw/KT+xms6rv1IWz+DSrVW8ZU/MRlSd0JPh2PuaetEngiC0G3hr4oPF1Kq9DIUEJRpuRa84kyx6VJn3d0VohVASHynxKOd1bc6iFrrj4KC+coMK3+USJ045
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB5044.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(366004)(136003)(39840400004)(376002)(110136005)(316002)(9686003)(55016002)(66574015)(86362001)(2906002)(166002)(71200400001)(83380400001)(33656002)(52536014)(966005)(44832011)(76116006)(186003)(38100700002)(122000001)(66946007)(66476007)(66556008)(64756008)(66446008)(91956017)(6506007)(19627405001)(5660300002)(38070700005)(478600001)(7696005)(8676002)(8936002)(53546011); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WWJBZDRCZXJrS1E0RlB2Lys5dE5McGJUZXpJaklGMXRIZHlucDRJZkV5MFps?= =?utf-8?B?a2wycUk3MlFudlVWaUlXUlJZYU9LSStpUXJyQ0kvUEFiajNUVi9MRnNWS0Fq?= =?utf-8?B?SzBmUFhOZTFGRFJ0K0tuRE5xaGhzVEFEVm93RlczVkJnOWozaHhMSEFMR2pj?= =?utf-8?B?MHN3aDkraHdjb0Ric0dWaFF3aTFNWTNHY0RGblpuTDFiVVgyS2R2dklNQUZI?= =?utf-8?B?WWdYcXRGd2RrMGNsUVdBNlFKYmdMM1hJdWRqbzBCWkxlQ0R4SWxPU0ZOc3B6?= =?utf-8?B?YXFOMHpJeG81aXR6RlIzQ2hlblUzL3RRc3ppTTB4S2NWUTZ3OWhVQWIxUzUy?= =?utf-8?B?M25HWmg2TlNqQU0wSHBzVyt6dXVvMTVKd20waWlLT0RqakxvejdMU2h2NmRr?= =?utf-8?B?VEtnSnNqTGRCWjA5T2h1VHMzSjBFN05kNHVFS3F3UjY5OURQSlZlV2lMbVEv?= =?utf-8?B?UU1EZGFKOUtDVWpPaUVHZ3FNNlJMYkgyNVRUYnkxaStVUUs5eEJ2WUozb200?= =?utf-8?B?THhGZTZyMlYzeWhGYThGbnhqWFRxWTIvWDhyVUhwOFZ3azdNcEdOeGpicWxD?= =?utf-8?B?UEY4VVQzODlPWEtpRUs2cng0OEQreG8vWHk2cU5yNS82d3g3cVhoUWxyT2ph?= =?utf-8?B?RkpTQmNwZmFMOGFzamN4bUdwZlE4dyt2VTczZWN6cGF5aHhCTnM5WlJCNzB6?= =?utf-8?B?MFRxZm13R0N5VW90dXNZd0tyTjBUTjJOMEtRdlEzQ1NDNUdKVHEyVVpScUpZ?= =?utf-8?B?L2s5WjV5eUVvd0JHREx1UmxlZGwwbzZIcGlodjI3ci8wQVNRWlRvZU8rMzRQ?= =?utf-8?B?cUVMajYzRW10ZGlSVCs2VkwzZWozNzdRY21mWFd6MWluTXkzbGEwVHY2RllN?= =?utf-8?B?Z1FDNFMweG84UEpyejlvVkVnQ1FMbTArSk9RVDQ1U0IwdCs3VXg1emtBNDFD?= =?utf-8?B?djkwVzhuTUdDd2FOWjkvN00zT3dkc0pZd2RtMlRreGwvRlkvWWdoSkppR0hI?= =?utf-8?B?VFkwbXljMWQ2bnUvM0t0WUNyTjhxQy8yWDNVMWYwVFBiM3BET05lcW5iUURz?= =?utf-8?B?VjZjSmg3STFyUU5YLytGYkhKdzJUMzF0ZC9Nd3VPVCtQN2F5UGJvTWRtTlFq?= =?utf-8?B?amRFS3I3THl4YmN0WkRqdVVlQzA1MHdRUGpsdTN5V2Z3RTRzNUpPTW93RCt1?= =?utf-8?B?bUZvekpjU0Y2cE1JdENLM1lDM3ZPelRtc0x3dUZwZFZhM1ZUSnZsaG1KUFhO?= =?utf-8?B?bUowK2ZiQWp6QzBuUnArWFVZWXVOM3NYejZOOFVyRWhyUHZSVHQwcUcrUk55?= =?utf-8?B?YlVUUE02d1hxN2l0Q3VybnR4QktRUlNhMEhmUzNpSEg5MU92d3lIdlZKc1dl?= =?utf-8?B?NzhTM09xMzJ6Y1ZBQTlQZm1Tb1RpK3VidDZDZGcwSHpuTHAvQnkyQk5uRUw3?= =?utf-8?B?enJUaU5MandlTGo0Rnova0xwZXBlVDZ3NFUySmw2YVc3Z2g3N3JMcksvTFlE?= =?utf-8?B?SEwvejJBZ2xhWndrZWpPdkhheDVmN0NWRzNoTENyeG1zNGdna1dYNGRvSStz?= =?utf-8?B?Uyt4eHZzb2dpVG9oV2hFd3VaRXQvSDJoMy8wSlBLR0l0SWZPWTJ2eDRKTUt5?= =?utf-8?B?a2swd1AySmxqWU5RQ3VkQU9CcVNzVW4yVy9YKzhBZ3ZLMWErUWdrNzNFR1Qw?= =?utf-8?B?VVBzYmhMcVJxMjZxdEVHdW1saE1HOTk5eU1sZ1J1YW1BQlZocnkxVDlOTnhW?= =?utf-8?B?V0g3ZHc2TG1oOXlGaDNoKyt4Y2NjbWlISW9KRkp4UTRLVmVnaGlNeE5YcUU1?= =?utf-8?Q?bhvGUGISwxbp1EEix1OsJWUk8neXfTY4jkgE0=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BY3PR13MB5044D4EB61DEA050A9151166F2F09BY3PR13MB5044namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB5044.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5b072be3-8ad1-451f-f032-08d9562e19f4
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2021 03:23:45.0924 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 7dG294j9N5oUFD6aYPWFU+BQs74zp950visjLxuh5DuV+5+RwXGunJ8FnDrsyKs5tTskAyENd454uYQSIuTr4A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB4549
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/KqWfesPjVChma0IRdNZrsdV1lrM>
Subject: Re: [Idr] WG Last call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)
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: Tue, 03 Aug 2021 03:23:53 -0000

Hi Ketan,

    Thank you very much for your three specific comments.
    My responses to them are inline below with [HC].

1. The introduction gives the raison d'etre for this work as
“complex and error prone configuration and maintenance of route policies”.
 Perhaps the authors have the view of network engineers going to individual
routers and operating CLI and while this is true in the real world, we do
now have automation systems that have been (and are being) built to not
only take care of consistent provisioning network-wide but also verify
their successful application. More importantly have the ability to detect
issues/errors and where necessary rollback to a consistent state.
IETF facilitates the same using YANG models
(e.g. https://datatracker.ietf.org/doc/draft-ietf-rtgwg-policy-model/)
and there are other models also out there. These aspects are (still)
not covered or addressed adequately in this proposal.
[HC]: In some cases, it seems that there are lots of route policies
that have been configured on some border nodes of a network domain
and are relatively stable.
For dynamically adjusting traffic based on the network traffic,
we may dynamically add or change some route policies.
Some users seem not like this way (i.e., dynamically adding
or changing some route policies to the stable route policies)
even though they have configuration automation systems (including
YANG models) that can take care of consistency of configurations
network wide, verify their successful application and rollback to
a consistent state after detecting issues/errors in the updated
configurations. They seem like separating the stable route policies
from the ones that are changing dynamically.
In addition, adding or changing some route policies
through a configuration automation system may be slow.
For adjusting some traffic to avoid congestions or get around
congested points, it seems better to use a fast way to apply some
policies. I have updated the related text accordingly.

2. The changes to introduce ordering do address some comments provided
previously, but don’t address the key aspect that it is desirable for
a policy to be considered as “atomic”. If one rule in the middle fails,
the result can be dramatically different. This aspect/ability is not
addressed from my quick reading.
[HC]: It seems that the chance for one rule to fail while applying it
is very low.  A router or controller seems very reliable since there
should be a primary control plane and secondary control plane in the
controller and router.
Even when there is a failure (such as a controller failure) while
applying the rule, it should be recovered through using the existing
BGP mechanisms. When the controller fails, BGP Graceful Restart (GR)
and BGP Long-lived Graceful Restart (LLGR) can be used to let the
router keep the routes from the controller for some time. After the
controller recovers, the router will have all the routes (including
the rule being applied) from the controller. I have added/updated
some related text accordingly.

3. I find the text introduced in
https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd-12#section-5.2
to be particularly disconcerting.
[HC]: I have added some connections.

Best Regards,
Huaimo

________________________________
From: Idr <idr-bounces@ietf.org> on behalf of Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org>
Sent: Friday, July 30, 2021 10:29 AM
To: Susan Hares <shares@ndzh.com>; idr@ietf.org <idr@ietf.org>
Subject: Re: [Idr] WG Last call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)


< fixed the subject line ... just to make sure ... in case WG members thought this was still the IPR call 😉 >



The updates to the draft do not change my position from the previous WGLC – that this is not a good idea to pursue for IDR.

https://mailarchive.ietf.org/arch/msg/idr/MmYyhpKdZIhmh8yywGNrvWYzUNo/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fidr%2FMmYyhpKdZIhmh8yywGNrvWYzUNo%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C242d44b942df4b9e4c8b08d953668b29%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637632522162008738%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dY7hjuJngbEmLbX8UPzm9jwd6NEdDKeA6GiHV3m%2FDhY%3D&reserved=0>



I do appreciate that the authors have tried to update the draft to address the several comments provided. However, they do not change the fundamental issues in my opinion.



I will try to point out some specifics and here is the diff between the previous and this WGLC for the benefit of other WG members : https://www.ietf.org/rfcdiff?url1=draft-ietf-idr-rpd-05&url2=draft-ietf-idr-rpd-12<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-idr-rpd-05%26url2%3Ddraft-ietf-idr-rpd-12&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C242d44b942df4b9e4c8b08d953668b29%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637632522162018696%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ubTSB9IlxAgcaEO%2FygYJj%2B%2Bl0%2FdjQtH7%2BVzoE%2FNNZSg%3D&reserved=0>



  1.  The introduction gives the raison d'etre for this work as “complex and error prone configuration and maintenance of route policies”. Perhaps the authors have the view of network engineers going to individual routers and operating CLI and while this is true in the real world, we do now have automation systems that have been (and are being) built to not only take care of consistent provisioning network-wide but also verify their successful application. More importantly have the ability to detect issues/errors and where necessary rollback to a consistent state. IETF facilitates the same using YANG models (e.g. https://datatracker.ietf.org/doc/draft-ietf-rtgwg-policy-model/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-policy-model%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C242d44b942df4b9e4c8b08d953668b29%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637632522162018696%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aKc1SywChJyS563Em%2FeRKBq1kR3NyU7MjvR2RQKK%2B5U%3D&reserved=0>) and there are other models also out there. These aspects are (still) not covered or addressed adequately in this proposal.



  1.  The changes to introduce ordering do address some comments provided previously, but don’t address the key aspect that it is desirable for a policy to be considered as “atomic”. If one rule in the middle fails, the result can be dramatically different. This aspect/ability is not addressed from my quick reading.



  1.  I find the text introduced in https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd-12#section-5.2<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-rpd-12%23section-5.2&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C242d44b942df4b9e4c8b08d953668b29%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637632522162018696%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cqGzXRMFi4ZUkWyGN7bc%2FawtSAkCnEtrvR7JpDebRYQ%3D&reserved=0> to be particularly disconcerting.





Thanks,

Ketan



From: Idr <idr-bounces@ietf.org> On Behalf Of Susan Hares
Sent: 23 July 2021 22:53
To: idr@ietf.org
Subject: [Idr] IPR call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)



This begins a 2 week WG last call on draft-ietf-idr-rpd-11.txt.



There is one missing IPR statement from Liang Ou.

Liang should send the IPR statements in response to this WG LC.



The implementation report is at:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rpd%20impolementations%20<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fwiki%2Fdraft-ietf-idr-rpd%2520impolementations%2520&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C242d44b942df4b9e4c8b08d953668b29%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637632522162028652%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LEfda1H9w2EideGilFu3FvPD5Nn8HUNFSDPtlfucrE0%3D&reserved=0>



The two implementations are different implementations from Huawei.



This document describes BGP Extensions for Routing

   Policy Distribution (BGP RPD) to support this.



Please consider in your review of this draft:

1) if this draft is ready for deployment,

2) if the BGP extensions for routing policy distribution

Help deployments of BGP in the Internet.



Cheerily, Susan Hares