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
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)
> *Sent:* Thursday, July 23, 2020 5:37 PM
> *To:* Linda Dunbar ; 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
