Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

From: Haoyu Song <[email-masked]>
Date: Thu, 23 Jul 2020 18:49:33 +0000

I support the WGLC for this draft.

Haoyu

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, July 23, 2020 3:03 AM
To: [email-masked]
Subject: Idr Digest, Vol 195, Issue 71

Send Idr mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7Cec6063b237cb4659526608d82eefa1c1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637310954044325270&amp;sdata=1WzbgZLGv4HYv8H2Fe9NTBnSJdO6CunUZeP0fztZl4Q%3D&amp;reserved=0
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Idr digest..."

Today's Topics:

   1. Re: WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)
      (Ketan Talaulikar (ketant))

----------------------------------------------------------------------

Message: 1
Date: Thu, 23 Jul 2020 10:02:51 +0000
From: "Ketan Talaulikar (ketant)" <[email-masked]>
To: Robert Raszuk <[email-masked]>, Susan Hares <[email-masked]>
Cc: "idr@ietf. org" <[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
	7/29/2020)
Message-ID:
	<[email-masked]>
	
Content-Type: text/plain; charset="utf-8"

+1 and I also agree on Jakob?s comments/discussion on a parallel thread.

The individual version of this draft was called draft-li-idr-flowspec-rpd. When it came up for WG adoption, perhaps most people thought it was yet another Flowspec extension and did not have a close look at it.

The draft got adopted in Nov 2019 and since then, there has hardly been any change for it (other than IANA allocations update) : https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-idr-rpd-00%26url2%3Ddraft-ietf-idr-rpd-05&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7Cec6063b237cb4659526608d82eefa1c1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637310954044325270&amp;sdata=OiRR7jbB%2Fk9XF978DOjGFok7cyqHou1%2FlSFb%2FCmcN9A%3D&amp;reserved=0

I am not sure if this document has received sufficient review and inputs from the WG over the recent 9 months of its life as a WG document. Those provided by Robert previously seem not to have been incorporated?

Not sure if I missed implementation reports or some operator feedback on this.

Some more/other comments on why I believe this draft is not a good idea:

  *   How does the controller or provisioning entity know the status of the Route Policy provisioning on the target router. Even that it was successfully propagated to it and installed on it?
  *   Seems like one can have multiple policies advertised for a single peer/neighbor? How would they be handled?
  *   The draft has support for IPv4 and IPv6 prefix list and AS regex. What other route policy tools does the WG expect to extend in further drafts? Perhaps we end up with yet another boatload of extension drafts for BGP for RPD?

We have Route Policy yang model defined at the IETF for provisioning of route policies that provide better and more comprehensive solution than the proposal in this document. That approach is also very robust from operational perspective. We don?t need to be putting this into BGP protocol.

In summary, my suggestion would also be not proceed further on this document.

Thanks,
Ketan

From: Idr <[email-masked]> On Behalf Of Robert Raszuk
Sent: 17 July 2020 18:38
To: Susan Hares <[email-masked]>
Cc: idr@ietf. org <[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Dear IDR WG,

As discussed previously on the list I strongly object to proceed with this draft any further.

While I am as others quite sceptical about distributing more configuration over BGP this can be said to be debatable especially for p2mp applications.

However including peer's IP address in the NLRI to which given policy applies goes completely AGAINST BGP spray principle of p2mp information distribution. Adding such extension to BGP can only deteriorate the protocol further. It is not a fit in p2mp protocol to by definition use it as p2p transport channel.

The prefix 0 which is in the draft is not the solution to the above problem.

Moreover wide community ATOM also can already contain that peer's address so placing it in the NLRI of MP_REACH is not needed at all.

To the specific questions asked:

Ad 1) No.
Ad 2) No.
Ad 3) No..
Ad 4) No.
Ad 5) Yes.

Kind regards,
R.

On Wed, Jul 15, 2020 at 3:11 PM Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
This begins a 2 week WG LC on draft-ietf-idr-rpd from 7/15 to 7/29/2020.  You can obtain this draft at:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-rpd%2F&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7Cec6063b237cb4659526608d82eefa1c1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637310954044325270&amp;sdata=tta1Pm9351tpOdp5oMlZE%2FP8hUXXlN1P9dWNM1CoOhQ%3D&amp;reserved=0

This draft defines a new AFI/SAFI and new atoms for the Wide Communities.  This WG LC has been delayed as I waited for a resubmission of the Wide Communities draft.
I had hoped to do these 2 WG LC in parallel.

I?ve not received the Wide Communities draft, but we will start this WGLC to provide feedback to the authors.
We may have to run a short follow-up to this WG LC If there are changes to the Wide Communities draft during Its WG LC.

There is an IPR statement on this draft.

In your responses please answer the following questions:

1) Do you feel this draft has an solution that is acceptable
   With the IPR as a WG RFC?

2) Do you feel this draft is ready to publish?

3) Do you know of implementations of this draft?

4) Do you know of deployments of this draft?
If so, is this feature useful in the deploy ments.

5) Do you feel that Wide Communities is ready for Publication?

Cheerily, Susan Hares
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7Cec6063b237cb4659526608d82eefa1c1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637310954044325270&amp;sdata=1WzbgZLGv4HYv8H2Fe9NTBnSJdO6CunUZeP0fztZl4Q%3D&amp;reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fidr%2Fattachments%2F20200723%2F83cc8cba%2Fattachment.htm&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7Cec6063b237cb4659526608d82eefa1c1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637310954044325270&amp;sdata=%2F4rMkfpGXufv5wI2yibtM4MWNws6UM7vunV%2FOp2ukV0%3D&amp;reserved=0>

------------------------------

Subject: Digest Footer

_______________________________________________
Idr mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7Cec6063b237cb4659526608d82eefa1c1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637310954044325270&amp;sdata=1WzbgZLGv4HYv8H2Fe9NTBnSJdO6CunUZeP0fztZl4Q%3D&amp;reserved=0

------------------------------

End of Idr Digest, Vol 195, Issue 71
************************************

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 23 Jul 2020 21:56:39 +0000

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.
This draft has been discussed in IDR for 5 years!  Very long time.

I do have a couple of questions:

1. Page 6, last sentence of 4.1:  It says:
      "When receiving a BGP UPDATE message, a BGP speaker processes it only
      if the peer IP address in the NLRI is the IP address of the BGP
      speaker or 0."

      Do you mean that " the node that receives the BGP UPDATE will process the message  if only the if the peer IP address in the NLRI is the IP address of the receiver"?

      If doesn't match, the node will not process the message. Does it mean the node will propagate the message to its neighbors?  or simply drop the message?

2. Page 13, the first bullet: "Control route advertising: Only routes that match the rules specified in a policy are advertised."
      Is it referring to the node receiving the BGP UPDATE, or the node that originating the UPDATE?

      Does the "routes" in your statement refer to the IP addresses in the IP prefix sub-TLV within the Wide Community TLV?

Thank you very much.

Linda Dunbar

-----Original Message-----
From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, July 23, 2020 3:03 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Idr Digest, Vol 195, Issue 71

Send Idr mailing list submissions to
        [email-masked]<mailto:[email-masked]>

To subscribe or unsubscribe via the World Wide Web, visit
        https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C6f6f02e9cbde484211d308d82f392fec%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637311269973876029&amp;sdata=Xm%2FR48JT7wsCWuUuFDlUTOgBM9Q9TiNi%2BOV6xbK7erU%3D&amp;reserved=0
or, via email, send a message with subject or body 'help' to
        [email-masked]<mailto:[email-masked]>

You can reach the person managing the list at
        [email-masked]<mailto:[email-masked]>

Today's Topics:

Message: 1
Date: Thu, 23 Jul 2020 10:02:51 +0000
From: "Ketan Talaulikar (ketant)" <[email-masked]<mailto:[email-masked]>>
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>, Susan Hares <[email-masked]<mailto:[email-masked]>>
Cc: "idr@ietf. org<mailto:idr@ietf.%20org>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
        7/29/2020)
Message-ID:
        <[email-masked]<mailto:[email-masked]>>

The draft got adopted in Nov 2019 and since then, there has hardly been any change for it (other than IANA allocations update) : https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-idr-rpd-00%26url2%3Ddraft-ietf-idr-rpd-05&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C6f6f02e9cbde484211d308d82f392fec%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637311269973876029&amp;sdata=kdeFWmH1Kmft0%2F3RIS6%2BQx9v6Kpz5EAzFSmRl057Irs%3D&amp;reserved=0

Thanks,
Ketan

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: 17 July 2020 18:38
To: Susan Hares <[email-masked]<mailto:[email-masked]>>
Cc: idr@ietf. org <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Dear IDR WG,

Ad 1) No.
Ad 2) No.
Ad 3) No..
Ad 4) No.
Ad 5) Yes.

Kind regards,
R.

On Wed, Jul 15, 2020 at 3:11 PM Susan Hares <[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>> wrote:
This begins a 2 week WG LC on draft-ietf-idr-rpd from 7/15 to 7/29/2020.  You can obtain this draft at:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-rpd%2F&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C6f6f02e9cbde484211d308d82f392fec%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637311269973876029&amp;sdata=bOHocA883h%2BJGOOhViukhr734yCGmDRq5%2BIkNFxloJc%3D&amp;reserved=0

Cheerily, Susan Hares
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C6f6f02e9cbde484211d308d82f392fec%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637311269973876029&amp;sdata=Xm%2FR48JT7wsCWuUuFDlUTOgBM9Q9TiNi%2BOV6xbK7erU%3D&amp;reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fidr%2Fattachments%2F20200723%2F83cc8cba%2Fattachment.htm&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C6f6f02e9cbde484211d308d82f392fec%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637311269973876029&amp;sdata=%2BBQAHVIPKwQfC8u3wlcEApc9SRbXehZnScvA6GIOHN0%3D&amp;reserved=0>

Subject: Digest Footer

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C6f6f02e9cbde484211d308d82f392fec%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637311269973886023&amp;sdata=JY6VcakYMD65L1cD%2BvzUG8AluXKp2uPPLk%2FozwBNURU%3D&amp;reserved=0

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C6f6f02e9cbde484211d308d82f392fec%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637311269973886023&amp;sdata=JY6VcakYMD65L1cD%2BvzUG8AluXKp2uPPLk%2FozwBNURU%3D&amp;reserved=0

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 23 Jul 2020 22:20:17 +0000

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 <[email-masked]> On Behalf Of Linda Dunbar
Sent: Thursday, July 23, 2020 2:57 PM
To: [email-masked]
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 23 Jul 2020 22:23:33 +0000

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) <[email-masked]>
Sent: Thursday, July 23, 2020 5:20 PM
To: Linda Dunbar <[email-masked]>; [email-masked]
Subject: RE: WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Regards,
Jakob.

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Linda Dunbar
Sent: Thursday, July 23, 2020 2:57 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 23 Jul 2020 22:37:05 +0000

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.
- 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.
- 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.

There are already ways in BGP for an AS to signal preference across AS boundaries:
Med, AS-path length, communities.

Ketan and Robert added other objections.

Regards,
Jakob.

From: Linda Dunbar <[email-masked]>
Sent: Thursday, July 23, 2020 3:24 PM
To: Jakob Heitz (jheitz) <[email-masked]>; [email-masked]
Subject: RE: WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Jakob,

Thank you very much,
Linda Dunbar

From: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 23, 2020 5:20 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Regards,
Jakob.

---

From: reta Yang <[email-masked]>
Date: Fri, 24 Jul 2020 05:53:38 +0000

I support it.

Reta

________________________________
From: Idr <[email-masked]> on behalf of Jakob Heitz (jheitz) <jheitz=[email-masked]>
Sent: Friday, July 24, 2020 6:37 AM
To: Linda Dunbar <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

- Atomic Transactions:

- Feedback:

  BGP is "spray and pray".

- Persistence:

Regards,

Jakob.

From: Linda Dunbar <linda.dunbar@futurewei..com>
Sent: Thursday, July 23, 2020 3:24 PM
To: Jakob Heitz (jheitz) <[email-masked]>; [email-masked]
Subject: RE: WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Jakob,

Thank you very much,

Linda Dunbar

out in previous emails.

Regards,

Jakob.

---

From: ruoxin huang <[email-masked]>
Date: Fri, 24 Jul 2020 05:58:02 +0000

I support the WGLC for the draft.

Ruoxin

________________________________
From: Idr <[email-masked]> on behalf of reta Yang <[email-masked]>
Sent: Friday, July 24, 2020 1:53 PM
To: [email-masked] <[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

I support it.

Reta

- Atomic Transactions:

- Feedback:

  BGP is "spray and pray".

- Persistence:

Regards,

Jakob.

Jakob,

Thank you very much,

Linda Dunbar

out in previous emails.

Regards,

Jakob.

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..

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 24 Jul 2020 16:28:41 +0000

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) <[email-masked]>
Sent: Thursday, July 23, 2020 5:37 PM
To: Linda Dunbar <[email-masked]>; [email-masked]
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".

[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 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.

[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 <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 23, 2020 3:24 PM
To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Jakob,

Thank you very much,
Linda Dunbar

Regards,
Jakob.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 24 Jul 2020 18:41:25 +0000

The reason I'm comparing an apple with an orange is because you are building an apple
when you need an orange.
BGP, PCEP and Netconf all exist, because they solve different problems.
Netconf has the features needed to distribute route policy configurations
BGP does not.

Another feature:
Authentication.
You can't have just anyone configuring you devices.
Netconf is designed to run over SSH and TLS.
BGP is not.

About the "spray and pray":
This causes transient routing loops and other anomalies when distributing routes.
We have developed a litany of technologies designed to minimize these problems
for route distribution, such as FRR, LFA, PIC.

You will have transients if you distribute route policy configurations with BGP.
Have you studied the kinds of transients you will encounter and how you will
mitigate them?

Netconf is designed to allow configurations to be installed in a predictable order
and to respond properly to errors in configuration installation to avoid transients.
BGP is not.

Regards,
Jakob.

From: Linda Dunbar <[email-masked]>
Sent: Friday, July 24, 2020 9:29 AM
To: Jakob Heitz (jheitz) <[email-masked]>; [email-masked]
Subject: RE: WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Jakob,

- Feedback:
  BGP is "spray and pray".

- Persistence:

Linda Dunbar

Regards,
Jakob.

Jakob,

Thank you very much,
Linda Dunbar

Regards,
Jakob.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 24 Jul 2020 21:49:57 +0200

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 <[email-masked]>
wrote:

> 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.
>
>
>
> *From:* Jakob Heitz (jheitz) <[email-masked]>
> *Sent:* Thursday, July 23, 2020 5:37 PM
> *To:* Linda Dunbar <[email-masked]>; [email-masked]
> *Subject:* RE: WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)
>
>
>
> [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".
>
> [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:
>
> [Linda] That is very true. The originator can only “Pray” as BGP is
> intended for.
>
>
>
> [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).
>
>
>
>
>
> *From:* Linda Dunbar <[email-masked]>
> *Sent:* Thursday, July 23, 2020 3:24 PM
> *To:* Jakob Heitz (jheitz) <[email-masked]>; [email-masked]
> *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?
>
> *From:* Jakob Heitz (jheitz) <[email-masked]>
> *Sent:* Thursday, July 23, 2020 5:20 PM
> *To:* Linda Dunbar <[email-masked]>; [email-masked]
> *Subject:* RE: WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of *Linda Dunbar
> *Sent:* Thursday, July 23, 2020 2:57 PM
> *To:* [email-masked]
> *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.
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Randy Bush <[email-masked]>
Date: Sat, 25 Jul 2020 14:56:14 -0700

> 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.

just in case folk missed the last time i agreed with this sentiment,

+1

randy

---

From: Sebastian Becker <[email-masked]>
Date: Sun, 26 Jul 2020 10:42:30 +0200

Me, too! +1

-- 
Sebastian Becker
[email-masked]

> Am 25.07.2020 um 23:57 schrieb Randy Bush <[email-masked]>:
> 
> 
>>

---

From: Gert Doering <[email-masked]>
Date: Sun, 26 Jul 2020 16:49:46 +0200

Hi,

> just in case folk missed the last time i agreed with this sentiment,

Yep, another +1

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Pedro Andres Aranda Gutierrez <[email-masked]>
Date: Wed, 29 Jul 2020 06:54:42 +0200

big applause and +1
/PA

On Tue, 28 Jul 2020 at 22:22, Sebastian Becker <[email-masked]> wrote:

> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellet zu werden
Georg Kreisler