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.dun...@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 <rob...@raszuk.net> > *Sent:* Sunday, July 26, 2020 5:23 PM > *To:* Linda Dunbar <linda.dun...@futurewei.com> > *Cc:* Lizhenbin <lizhen...@huawei.com>; Jakob Heitz (jheitz) < > jhe...@cisco.com>; i...@ietf.org; grow@ietf.org grow@ietf.org < > grow@ietf.org>; rt...@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.dun...@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 <rob...@raszuk.net> > *Sent:* Friday, July 24, 2020 2:50 PM > *To:* Linda Dunbar <linda.dun...@futurewei.com>; Lizhenbin < > lizhen...@huawei.com> > *Cc:* Jakob Heitz (jheitz) <jhe...@cisco.com>; i...@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.dun...@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) <jhe...@cisco.com> > *Sent:* Thursday, July 23, 2020 5:37 PM > *To:* Linda Dunbar <linda.dun...@futurewei.com>; i...@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.dun...@futurewei.com> > *Sent:* Thursday, July 23, 2020 3:24 PM > *To:* Jakob Heitz (jheitz) <jhe...@cisco.com>; i...@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) <jhe...@cisco.com> > *Sent:* Thursday, July 23, 2020 5:20 PM > *To:* Linda Dunbar <linda.dun...@futurewei.com>; i...@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-boun...@ietf.org> *On Behalf Of *Linda Dunbar > *Sent:* Thursday, July 23, 2020 2:57 PM > *To:* i...@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 > i...@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
