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

[Robert Raszuk <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> *Sent:* Sunday, July 26, 2020 5:23 PM
> *To:* Linda Dunbar <[e-mail]>
> *Cc:* Lizhenbin <[e-mail]>; Jakob Heitz (jheitz) <
> [e-mail]>; [e-mail]; [e-mail] [e-mail] <
> [e-mail]>; [e-mail]
> *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 <[e-mail]>
> 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 <[e-mail]>
> *Sent:* Friday, July 24, 2020 2:50 PM
> *To:* Linda Dunbar <[e-mail]>; Lizhenbin <
> [e-mail]>
> *Cc:* Jakob Heitz (jheitz) <[e-mail]>; [e-mail]; [e-mail]
> [e-mail] <[e-mail]>
> *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 <[e-mail]>
> 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) <[e-mail]>
> *Sent:* Thursday, July 23, 2020 5:37 PM
> *To:* Linda Dunbar <[e-mail]>; [e-mail]
> *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 <[e-mail]>
> *Sent:* Thursday, July 23, 2020 3:24 PM
> *To:* Jakob Heitz (jheitz) <[e-mail]>; [e-mail]
> *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) <[e-mail]>
> *Sent:* Thursday, July 23, 2020 5:20 PM
> *To:* Linda Dunbar <[e-mail]>; [e-mail]
> *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 <[e-mail]> *On Behalf Of *Linda Dunbar
> *Sent:* Thursday, July 23, 2020 2:57 PM
> *To:* [e-mail]
> *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
> [e-mail]
> 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>
>
>
>
>