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

Robert Raszuk <robert@raszuk.net> Mon, 27 July 2020 09:50 UTC

Return-Path: <robert@raszuk.net>
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 C5B753A1877 for <idr@ietfa.amsl.com>; Mon, 27 Jul 2020 02:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 sueb8HSzDcgU for <idr@ietfa.amsl.com>; Mon, 27 Jul 2020 02:50:39 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440163A1841 for <idr@ietf.org>; Mon, 27 Jul 2020 02:50:39 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id b13so9264270edz.7 for <idr@ietf.org>; Mon, 27 Jul 2020 02:50:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sLPWAa2gr+snmMJ/6LdC5O7Y+zf+VkcbUwbT7LgujpA=; b=PG02Q0VHsRwfe3iqcJFjTOKy4wUh4YkiW9EX740Eny26o0xoCascBdB54LpuMTVfHV D2bCJY7FfWXfPWBjP4oJK+chwSuIXOWS2LFypRM40DFmxeJY4l8bnkb+OhrZlnU9cl5s 6sScCcaZ8E/LT2WtknZUIlVk8wKEwDaxaZD65x5JQfhjpEIO4ZZ0Ibbu/B1Nij7bzqh0 nw8grymJya6+oZom7v9gA3L01lQWAIUaGyZ+cHCcG9K+UA6rrOkxsqOW4PCbCbr7IrYR fl1rOPs7I7Vmh3/50MIAmV5+fGhwyuhgspbIG7kk1yqE7MJ2S7I2A61DhnIj8FpXqNga Cm8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sLPWAa2gr+snmMJ/6LdC5O7Y+zf+VkcbUwbT7LgujpA=; b=Vlq2syhKykFsyLJiimsQE4qKCBQBq0m9WUbAfBQZ1oR5oUlvoIS8deqrHzI9Mhfk64 C5GSyoL7hlOPk59odBUK3M5XX7dujnqXiWhBZb87kS2Zj3qSz0cbTHXJYvqvzMy08c1I +IUIeS/yCijFP2mP87eqVeLZBV+eEeONLFsZhQznNOJ4aAQSWKB/JFmo3qf+WH2Y7zkv JZub+JBtvwryLRC3gWeThbc+YzZtuuhMtlopxagx++nUQ76tsrWHwQ/MPReveu5hyXaP nzcencLBqts18bY5EJAmef+DOSuVWDQlteaihD8/bBBjFxFofRmScCNlu1hCZ4eVVqSv /g+Q==
X-Gm-Message-State: AOAM531YXch6PnGq0PIFCwJn1cs2prfva9JFw7h+a3qc4wWVgucRGIXh pmqlKOATcMSuFqY0gp3nJaKAt7P1xyvzIfwzu78pEQ==
X-Google-Smtp-Source: ABdhPJzmbQi4cuQMbl4yIIr+9Miyw2zHWQjDx4QMJBO4xm0DpFrEW9Xse9SVcjG+ZQ1OehFuEzg6jaY3nk+G4T2A3co=
X-Received: by 2002:a05:6402:a5b:: with SMTP id bt27mr4194395edb.120.1595843437433; Mon, 27 Jul 2020 02:50:37 -0700 (PDT)
MIME-Version: 1.0
References: <SN6PR13MB23347FC0BC5212B52E62591385750@SN6PR13MB2334.namprd13.prod.outlook.com> <CAOj+MMFqFaQ3e6voR-4LyZaAwY2VVX12h_z8tTtJMV+y9KJjyw@mail.gmail.com> <SN6PR13MB2334CCDC36A49DC07F05946485720@SN6PR13MB2334.namprd13.prod.outlook.com>
In-Reply-To: <SN6PR13MB2334CCDC36A49DC07F05946485720@SN6PR13MB2334.namprd13.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 27 Jul 2020 11:50:27 +0200
Message-ID: <CAOj+MMHOt+7-suB9Y3cRbC0osM5i+-ueNaGUjfVO3iShUF276Q@mail.gmail.com>
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: Lizhenbin <lizhenbin@huawei.com>, "Jakob Heitz (jheitz)" <jheitz@cisco.com>, "idr@ietf.org" <idr@ietf.org>, "grow@ietf.org grow@ietf.org" <grow@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Content-Type: multipart/related; boundary="000000000000352db905ab6941c5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/cVfZ077iDwkH3gBOlqf-Ou1ybvA>
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: Mon, 27 Jul 2020 09:50:59 -0000

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>
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>
> *Sent:* Sunday, July 26, 2020 5:23 PM
> *To:* Linda Dunbar <linda.dunbar@futurewei.com>
> *Cc:* Lizhenbin <lizhenbin@huawei.com>om>; Jakob Heitz (jheitz) <
> jheitz@cisco.com>gt;; idr@ietf.org; grow@ietf.org grow@ietf.org <
> grow@ietf.org>gt;; 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>
> 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.
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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>
> *Sent:* Friday, July 24, 2020 2:50 PM
> *To:* Linda Dunbar <linda.dunbar@futurewei.com>om>; Lizhenbin <
> lizhenbin@huawei.com>
> *Cc:* Jakob Heitz (jheitz) <jheitz@cisco.com>om>; idr@ietf.org; grow@ietf.org
> grow@ietf.org <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>
> 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>
> *Sent:* Thursday, July 23, 2020 5:37 PM
> *To:* Linda Dunbar <linda.dunbar@futurewei.com>om>; 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>
> *Sent:* Thursday, July 23, 2020 3:24 PM
> *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,
>
>
>
> 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>
> *Sent:* Thursday, July 23, 2020 5:20 PM
> *To:* Linda Dunbar <linda.dunbar@futurewei.com>om>; 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> *On Behalf Of *Linda Dunbar
> *Sent:* Thursday, July 23, 2020 2:57 PM
> *To:* 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
> 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>
>
>
>
>