Re: [Idr] The automatic policy exchange by draft-ietf-idr-rpd-05.txt can be used for draft-ietf-rtgwg-net2cloud-gap-analysis

Greg Skinner <gregskinner0@icloud.com> Wed, 29 July 2020 01:06 UTC

Return-Path: <gregskinner0@icloud.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 B0F1C3A0DEB for <idr@ietfa.amsl.com>; Tue, 28 Jul 2020 18:06:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 iO9Zw3I_xH1C for <idr@ietfa.amsl.com>; Tue, 28 Jul 2020 18:06:08 -0700 (PDT)
Received: from mr85p00im-ztdg06011901.me.com (mr85p00im-ztdg06011901.me.com [17.58.23.198]) (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 CD2FE3A0DE2 for <idr@ietf.org>; Tue, 28 Jul 2020 18:06:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1595984766; bh=ayUzrRVCJHtNGldTJpzUc9acqb8P52mOS16/L9tqHwM=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=EZKwkulSfALLFtD+dMVi2VKZTty/hDx4lrOwYRvDB//yBX+0zLJwfeejBdAnrNLAh K8uV+Bf00PWyskYoRIHDCnVAYYawDHNMieSSRym0S1kfly94bzANVYTw04gEFq6zqE dGt17ku8xq+iXLv3LSf1icn/F1bE0Zd/Y3PxeZGZHo96Id9mQry4dC+hYR027XF/O4 Rwwsdlf9v2F7OqU52XcSx5M0+oVvp0LEHy911v4c4k0nk43ntyls8q9EHN74xTdaSK DLv/I/1wGJyx9XXwt+kWBBpKukpS0puXYuftERCY3TlvjiFfuggQ3hv8L4Po8k9H3D p3M0LMv3VguPA==
Received: from [172.20.10.2] (178.sub-174-194-210.myvzw.com [174.194.210.178]) by mr85p00im-ztdg06011901.me.com (Postfix) with ESMTPSA id B9522A607B4; Wed, 29 Jul 2020 01:05:29 +0000 (UTC)
From: Greg Skinner <gregskinner0@icloud.com>
Message-Id: <214FC810-D50E-4F48-96AB-0DAB894FBB8A@icloud.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2EF4B8A7-F8ED-4437-92E4-14B014FE585E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Tue, 28 Jul 2020 18:05:24 -0700
In-Reply-To: <CAOj+MMHOt+7-suB9Y3cRbC0osM5i+-ueNaGUjfVO3iShUF276Q@mail.gmail.com>
Cc: Linda Dunbar <linda.dunbar@futurewei.com>, "idr@ietf.org" <idr@ietf.org>
To: Robert Raszuk <robert@raszuk.net>
References: <SN6PR13MB23347FC0BC5212B52E62591385750@SN6PR13MB2334.namprd13.prod.outlook.com> <CAOj+MMFqFaQ3e6voR-4LyZaAwY2VVX12h_z8tTtJMV+y9KJjyw@mail.gmail.com> <SN6PR13MB2334CCDC36A49DC07F05946485720@SN6PR13MB2334.namprd13.prod.outlook.com> <CAOj+MMHOt+7-suB9Y3cRbC0osM5i+-ueNaGUjfVO3iShUF276Q@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-29_01:2020-07-28, 2020-07-28 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1031 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2004280000 definitions=main-2007290005
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/LAm-8dIvyz4TmpPRvYrl6aC1WGA>
Subject: Re: [Idr] The automatic policy exchange by draft-ietf-idr-rpd-05.txt can be used for draft-ietf-rtgwg-net2cloud-gap-analysis
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: Wed, 29 Jul 2020 01:06:12 -0000

(I limited the recipients in my response in order to (hopefully) focus on the IDR-specific topics covered in the quoted text.)

Regarding draft-raszuk-ti-bgp-01, if IDR has an interest in pursuing it again, I have some concerns:

There were several issues raised <https://www.ietf.org/proceedings/75/minutes/idr.txt> during the IDR WG meeting during IETF 75 that should be addressed, IMO.
I found some other issues in the draft that weren’t brought up during that meeting.  For example, in Section 5.5 <https://tools.ietf.org/html/draft-raszuk-ti-bgp-01#section-5.5>, it is stated that "On the network side all today's BGP messages are send with IP precedence value of Internetwork Control of 110000, which is used for high-priority routing traffic.”  Is this true, even for open-source BGP implementations?  I looked at the source code for three implementations (Bird, FRR, and OpenBGPD), and was only able to confirm this for IPv4 OpenBGPD messages.
One of the normative references, RFC 5226 <https://tools.ietf.org/html/rfc5226>, has been obsoleted by RFC 8126 <https://tools.ietf.org/html/rfc8126>.
Several of the informative references have expired.
The draft would require numerous editorial changes due to errors in spelling, grammar, etc.

Regards, Greg

> On Jul 27, 2020, at 2:50 AM, Robert Raszuk <robert@raszuk.net> wrote:
> 
> 
> If people still think of adding p2p config push to the protocol which allows all of us to function - by all means the answer to your question is YES. 
> 
> Thx,
> R.
> 
> On Mon, Jul 27, 2020 at 2:21 AM Linda Dunbar <linda.dunbar@futurewei.com <mailto:linda..dunbar@futurewei.com>> wrote:
> Robert,
> 
>  
> 
> Thank you very much for the explanation.
> 
> “new BGP Transport Instance with new separate port and separate process”, very interesting perspective.
> 
>  
> 
> But draft-raszuk-ti-bgp-01 was written 10 years ago. Is it still valid and worth pursuing?
> 
>  
> 
> Thank you
> 
> Linda
> 
>  
> 
> From: Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>> 
> Sent: Sunday, July 26, 2020 5:23 PM
> To: Linda Dunbar <linda.dunbar@futurewei.com <mailto:linda.dunbar@futurewei.com>>
> Cc: Lizhenbin <lizhenbin@huawei.com <mailto:lizhenbin@huawei.com>>; Jakob Heitz (jheitz) <jheitz@cisco.com <mailto:jheitz@cisco.com>>; idr@ietf.org <mailto:idr@ietf.org>; grow@ietf.org <mailto:grow@ietf.org> grow@ietf.org <mailto:grow@ietf.org> <grow@ietf.org <mailto:grow@ietf.org>>; rtgwg@ietf.org <mailto:rtgwg@ietf.org>
> Subject: Re: The automatic policy exchange by draft-ietf-idr-rpd-05.txt can be used for draft-ietf-rtgwg-net2cloud-gap-analysis
> 
>  
> 
> Hi Linda,
> 
>  
> 
> So are you suggesting that this new SAFI is to be sent on EBGP too ?? Whow ... Note BGP is not too secure transport ! I would never allow any peer to push me policy via eBGP to my ASBRs regardless how much I would trust it. 
> 
>  
> 
> That aside I think no one is questioning that overall this is nice to have BGP policy distributed in a dynamic way. We are however concerned in three planes ... 
> 
>  
> 
> Aspect #1 - BGP is p2mp and information and encoding (NLRI) here clearly make this proposal p2p. And no Robin p2p is not a special case of p2mp :) 
> 
>  
> 
> Aspect #2 - This proposal adds additional burden to IP Routing BGP subsystem and its clear that if approved there will be more and more extensions to new MATCH and SET sub-TLVs coming. While it is easy to write a draft that at the end requires a serious commitment from any vendor to now turn BGP into configuration channel. That means overall more cycles spend and more burden on BGP dev teams. 
> 
>  
> 
> Aspect #3 - The proposal has lots of technical issues (as described) which can not just be swapped under the carpet. 
> 
>  
> 
> My recommendations (in order of preference): 
> 
>  
> 
> *1* 
> 
>  
> 
> Turn proposed sub-TLVs into JSON and use HTTPS PUT, GET & DELETE along with real time response status codes to send required policy over targeted TCP sessions just using curl to remote ASBRs. Note all vendors today support RESTful commands or httpd on the routers. Some already even support JSON based BGP configuration for some time now (ex: NX-OS). 
> 
>  
> 
> *2* 
> 
>  
> 
> At least decouple it from routing BGP - support new BGP Transport Instance with new separate port and separate process. Whenever we need to use such protocol (call it Configuration Transport Protocol "CTP") for loop free information dissemination such isolation could deliver what you are really after with no impact to stability of IP routing. 
> 
> Ref: https://tools.ietf.org/html/draft-raszuk-ti-bgp-01 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-raszuk-ti-bgp-01&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cfc692e6f8ad641dd5b9908d831b27afd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637313989929483251&sdata=t6YI2%2BYcngtpCMJ3d%2BSFAkuffeGFW236zvXIZsd7cA8%3D&reserved=0>  
> 
>  
> 
> Thx,
> 
> R.
> 
>  
> 
>  
> 
> On Sun, Jul 26, 2020 at 11:53 PM Linda Dunbar <linda.dunbar@futurewei.com <mailto:linda.dunbar@futurewei.com>> wrote:
> 
> Robert, Jakob, etc.
> 
>  
> 
> Thank you very much for detailed explanation of the issues.
> 
> One of the points you all raised is that p2p policies should be administrated by controller via NETCONF.
> 
>  
> 
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/ <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-net2cloud-gap-analysis%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cfc692e6f8ad641dd5b9908d831b27afd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637313989929483251&sdata=ESJ%2BqmxEnlpAq32P3H3WxrkWzFIN863%2F7bKtucFdTrg%3D&reserved=0> describes a scenario of one vCPE in cloud DC reachable by multiple PEs. Depending on the nature of the applications or/and network conditions, some applications may need to egress or ingress from PE1, others may need to egress or ingress from PE2.
> 
>  
> 
> Today’s Cloud DC configuration can use the AS Path metric to influence the preferred path to/from a specific PEs. But requires manual configuration.
> 
> After reading through the draft-ietf-idr-rpd-05, I think the automatic approach can make the change on demand. The policy change can be ephemeral.
> 
> Therefore, if one side doesn’t implement the feature, the “spray” doesn’t have any impact. The traffic egress or ingress to the peer network would just go with the configuration. If the “spray” is answered, then the performance can be improved.
> 
>  
> 
>  
> 
>  
> 
> <image001.jpg>
> 
>  
> 
>  
> 
>  
> 
> If not using the automatic method proposed by draft-ietf-idr-rpd, do you have other suggestions?
> 
>  
> 
> Thank you very much.
> 
>  
> 
> Linda Dunbar
> 
> From: Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>> 
> Sent: Friday, July 24, 2020 2:50 PM
> To: Linda Dunbar <linda.dunbar@futurewei.com <mailto:linda.dunbar@futurewei.com>>; Lizhenbin <lizhenbin@huawei.com <mailto:lizhenbin@huawei.com>>
> Cc: Jakob Heitz (jheitz) <jheitz@cisco.com <mailto:jheitz@cisco.com>>; idr@ietf.org <mailto:idr@ietf.org>; grow@ietf.org <mailto:grow@ietf.org> grow@ietf.org <mailto:grow@ietf.org> <grow@ietf.org <mailto:grow@ietf.org>>
> Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)
> 
>  
> 
> Linda,
> 
>  
> 
> It seems that authors of this document are strongly pushing to pass the last call irrespective of observations made by WG. 
> 
>  
> 
> As said before and as reiterated by Jakob and Ketan BGP is not the right tool for p2p config push. We must stop adding such extensions to BGP like this one or BGP-LS or SR Policies if we really want to keep routing at some proper stability levels. 
> 
>  
> 
> But even if you would convince everyone in IDR that this is all great the draft itself is so immature that I can't imagine why are we discussing last call at this time. 
> 
>  
> 
> * Please observe that BGP state is ephemeral. When BGP sessions resets all state previously distributed is gone (modulo GR ...) Is the expectation here that state distributed by this new SAFI will persists ? If so for how long ? If not have you even considered the initial churn ? 
> 
>  
> 
> * We have hooks to make sure LDP and IGP play in concert with BGP reachability. Would we need to now add to also wait for BGP policy to be received from controllers ? 
> 
>  
> 
> * We have spent fair amount of time to make sure GR works well. Do you expect to now GR to recognize all policy parameters and sync deltas locally upon BGP sessions restarts ? 
> 
>  
> 
> * Do you expect BGP implementations to now get busy with understanding all BGP policies syntax and semantics not in current terms how they are send or received in BGP UPDATEs but how they are applied implementation by implementation ... 
> 
>  
> 
> * What happens when some implementation does not allow some policy defined in the draft ... for example flexible AS_PATH creation as defined in AS-Path Change sub-TLV ? Note that this section alone is catastrophic for BGP protocol to allow insertion of more then your own ASN into AS-PATH. Just looking at this alone should be enough to reject this draft. 
> 
>  
> 
> And there are many many more real issues with this proposal  .... 
> 
>  
> 
> See when document has low adoption bar it does not mean that it will also have the same low bar to progress it :) 
> 
>  
> 
> Kind regards,
> R.
> 
>  
> 
> PS. Let me cc GROW WG here as I think more operational review and comments would be highly valuable at this point. 
> 
>  
> 
>  
> 
>  
> 
> On Fri, Jul 24, 2020 at 6:28 PM Linda Dunbar <linda.dunbar@futurewei.com <mailto:linda.dunbar@futurewei.com>> wrote:
> 
> 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.
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org <mailto:Idr@ietf.org>
> https://www.ietf.org/mailman/listinfo/idr <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cfc692e6f8ad641dd5b9908d831b27afd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637313989929483251&sdata=HMOd%2FD7ak6rGTS6b6NV7Xr%2FIF6FX9HF8uaM0KaHRRuM%3D&reserved=0>
>  
> 
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow