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

From: Linda Dunbar <[email-masked]>
Date: Sun, 26 Jul 2020 21:53:43 +0000

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/ 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 <[email-masked]>
Sent: Friday, July 24, 2020 2:50 PM
To: Linda Dunbar <[email-masked]>; Lizhenbin <[email-masked]>
Cc: Jakob Heitz (jheitz) <[email-masked]>; [email-masked]; [email-masked] [email-masked] <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 23, 2020 5:37 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)

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

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]<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)

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]<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)

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
[email-masked]<mailto:[email-masked]>
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%7C1b6af7f1a44245c2f84108d8300ac4e7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637312170107446540&sdata=LLVoHDipGL8iT2tmQBaci0XRf6NWZk0%2FMnwOmShOcgs%3D&reserved=0>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 27 Jul 2020 00:22:59 +0200

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

Thx,
R.

On Sun, Jul 26, 2020 at 11:53 PM Linda Dunbar <[email-masked]>
wrote:

> *https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/*
> <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/>
> 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.
>
>
>
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Friday, July 24, 2020 2:50 PM
> *To:* Linda Dunbar <[email-masked]>; Lizhenbin <
> [email-masked]>
> *Cc:* Jakob Heitz (jheitz) <[email-masked]>; [email-masked]; [email-masked]
> [email-masked] <[email-masked]>
> *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.
>
> On Fri, Jul 24, 2020 at 6:28 PM Linda Dunbar <[email-masked]*
> <[email-masked]>> wrote:
> Jakob,
>
> 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]* <[email-masked]>>
> *Sent:* Thursday, July 23, 2020 5:37 PM
> *To:* Linda Dunbar <[email-masked]*
> <[email-masked]>>; [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] 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]*
> <[email-masked]>>
> *Sent:* Thursday, July 23, 2020 3:24 PM
> *To:* Jakob Heitz (jheitz) <[email-masked]* <[email-masked]>>;
> [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]* <[email-masked]>>
> *Sent:* Thursday, July 23, 2020 5:20 PM
> *To:* Linda Dunbar <[email-masked]*
> <[email-masked]>>; [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]* <[email-masked]>> *On Behalf Of
> *Linda Dunbar
> *Sent:* Thursday, July 23, 2020 2:57 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 the WGLC for the draft. I think the proposed distribution of
> policy can scale much better and less error prone than any manual
> configuration.
> [email-masked]* <[email-masked]>
> *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%7C1b6af7f1a44245c2f84108d8300ac4e7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637312170107446540&sdata=LLVoHDipGL8iT2tmQBaci0XRf6NWZk0%2FMnwOmShOcgs%3D&reserved=0>
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 27 Jul 2020 00:21:02 +0000

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 <[email-masked]>
Sent: Sunday, July 26, 2020 5:23 PM
To: Linda Dunbar <[email-masked]>
Cc: Lizhenbin <[email-masked]>; Jakob Heitz (jheitz) <[email-masked]>; [email-masked]; [email-masked] [email-masked] <[email-masked]>; [email-masked]
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.

*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 <[email-masked]<mailto:[email-masked]>> wrote:
Robert, Jakob, etc.

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.

Thank you very much.

Linda Dunbar
From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Friday, July 24, 2020 2:50 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; Lizhenbin <[email-masked]<mailto:[email-masked]>>
Cc: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Linda,

Kind regards,
R.

- Feedback:
  BGP is "spray and pray".

- Persistence:

Linda Dunbar

Regards,
Jakob.

Jakob,

Thank you very much,
Linda Dunbar

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.
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
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>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 27 Jul 2020 11:50:27 +0200

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

> *Sent:* Sunday, July 26, 2020 5:23 PM
> *To:* Linda Dunbar <[email-masked]>
> *Cc:* Lizhenbin <[email-masked]>; Jakob Heitz (jheitz) <
> [email-masked]>; [email-masked]; [email-masked] [email-masked] <
> [email-masked]>; [email-masked]
> *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,
>
>
>
> 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*
>
>
>
> <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.
>
>
>
>
>
> 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
> On Fri, Jul 24, 2020 at 6:28 PM Linda Dunbar <[email-masked]>
> wrote:
>
> Jakob,
>
>
>
> *From:* Jakob Heitz (jheitz) <[email-masked]>
> *To:* Linda Dunbar <[email-masked]>; [email-masked]
> *From:* Linda Dunbar <[email-masked]>
> *To:* Jakob Heitz (jheitz) <[email-masked]>; [email-masked]
> *From:* Jakob Heitz (jheitz) <[email-masked]>
> *To:* Linda Dunbar <[email-masked]>; [email-masked]
> *From:* Idr <[email-masked]> *On Behalf Of *Linda Dunbar
> *To:* [email-masked]
> [email-masked]
> 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>
>
>
>
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 27 Jul 2020 22:45:49 +0000

RPD is not automation.
Automation is an application program that senses the state of the network and then
instructs various network nodes to direct traffic in different ways.
That part may be manual or have a degree of automation attached to it.
RPD or netconf is just a way to signal the intention from the app to the nodes.
If there is no application program, then the process is still manual,
even if you have RPD.

RPD might work in the simple diagram you have drawn.
However, a PE does not have just a single vCPE.
Using RPD, you would apply the same policy to every vCPE on that PE.

An alternative solution using enduring policies is to set MED based on communities.
For each CE session, the PE would set a high MED by default.
Then each CE session would set a lower MED based on a community match.
Each CE session would match a different community at the cloud side PE.
That way, the CE at the enterprise can send the community that matches its chosen
PE at the cloud end.
You could make several variations using as-prepend, origin, cost-community,
color-community paired with SR-policy.
[An Ink Drawing]
On PE1, we configure (pseudocode):
router BGP x
  neighbor CE1
    route policy out
      if community matches 65000:1001 then
         set MED 2
      else
         set MED 1
      endif
    end
  end
  neighbor CE2
    route policy out
      if community matches 65000:1002 then
         set MED 2
      else
         set MED 1
      endif
    end
  end
end

On PE2, we configure:
router BGP x
  neighbor CE1
    route policy out
      if community matches 65000:2001 then
         set MED 2
      else
         set MED 1
      endif
    end
  end
  neighbor CE2
    route policy out
      if community matches 65000:2002 then
         set MED 2
      else
         set MED 1
      endif
    end
  end
end

On PE3, we configure:
router BGP x
  neighbor CE3
    route policy out
      if community matches 65000:3003 then
         set MED 2
      else
         set MED 1
      endif
    end
  end
  neighbor CE4
    route policy out
      if community matches 65000:3004 then
         set MED 2
      else
         set MED 1
      endif
    end
  end
end

On PE4, we configure:
router BGP x
  neighbor CE3
    route policy out
      if community matches 65000:4003 then
         set MED 2
      else
         set MED 1
      endif
    end
  end
  neighbor CE4
    route policy out
      if community matches 65000:4004 then
         set MED 2
      else
         set MED 1
      endif
    end
  end
end

Now, CE10 has full control over which CE it chooses at which site.
It can choose a different PE as bestpath for each CE for each route
and for each site.

Much more flexibility than the RPD draft.

It requires no coordination between route distribution and
ephemeral policy distribution.

Much more simplicity than the RPD draft.

You might argue that with ephemeral policy distribution, you can make
a wholesale change by changing just one policy and not re-advertising
all the routes. However, remember that if you make a policy change,
all the routes need to be readvertised anyway.

Regards,
Jakob.

From: Linda Dunbar <[email-masked]>
Sent: Sunday, July 26, 2020 2:54 PM
To: Robert Raszuk <[email-masked]>; Lizhenbin <[email-masked]>
Cc: Jakob Heitz (jheitz) <[email-masked]>; [email-masked]; [email-masked] [email-masked] <[email-masked]>; [email-masked]
Subject: The automatic policy exchange by draft-ietf-idr-rpd-05.txt can be used for draft-ietf-rtgwg-net2cloud-gap-analysis

Robert, Jakob, etc.

Thank you very much.

Linda Dunbar

Linda,

Kind regards,
R.

- Feedback:
  BGP is "spray and pray".

- Persistence:

Linda Dunbar

Regards,
Jakob.

Jakob,

Thank you very much,
Linda Dunbar

Regards,
Jakob.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 27 Jul 2020 23:19:50 +0000

Oops, I got the MEDs back-to-front. Thinking Local-pref.

Regards,
Jakob.

From: rtgwg <[email-masked]> On Behalf Of Jakob Heitz (jheitz)
Sent: Monday, July 27, 2020 3:46 PM
To: Linda Dunbar <[email-masked]>; Robert Raszuk <[email-masked]>; Lizhenbin <[email-masked]>
Cc: [email-masked]; [email-masked] [email-masked] <[email-masked]>; [email-masked]
Subject: RE: The automatic policy exchange by draft-ietf-idr-rpd-05.txt can be used for draft-ietf-rtgwg-net2cloud-gap-analysis

RPD is not automation.

On PE2, we configure:
router BGP x
  neighbor CE1
    route policy out

On PE3, we configure:
router BGP x
  neighbor CE3
    route policy out

On PE4, we configure:
router BGP x
  neighbor CE3
    route policy out

Regards,
Jakob.

From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, July 26, 2020 2:54 PM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Lizhenbin <[email-masked]<mailto:[email-masked]>>
Cc: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: The automatic policy exchange by draft-ietf-idr-rpd-05.txt can be used for draft-ietf-rtgwg-net2cloud-gap-analysis

Robert, Jakob, etc.

Thank you very much.

Linda Dunbar

Linda,

Kind regards,
R.

- Feedback:
  BGP is "spray and pray".

- Persistence:

Linda Dunbar

Regards,
Jakob.

Jakob,

Thank you very much,
Linda Dunbar

Regards,
Jakob.

---

From: Greg Skinner <[email-masked]>
Date: Tue, 28 Jul 2020 18:05:24 -0700

(I limited the recipients in my response in order to (hopefully) focus on the IDR-specific topics covered in the quoted text.)

Regarding draft-raszuk-ti-bgp-01, if IDR has an interest in pursuing it again, I have some concerns:

There were several issues raised <https://www.ietf.org/proceedings/75/minutes/idr.txt> during the IDR WG meeting during IETF 75 that should be addressed, IMO.
I found some other issues in the draft that weren’t brought up during that meeting.  For example, in Section 5.5 <https://tools.ietf.org/html/draft-raszuk-ti-bgp-01#section-5.5>, it is stated that "On the network side all today's BGP messages are send with IP precedence value of Internetwork Control of 110000, which is used for high-priority routing traffic.”  Is this true, even for open-source BGP implementations?  I looked at the source code for three implementations (Bird, FRR, and OpenBGPD), and was only able to confirm this for IPv4 OpenBGPD messages.
One of the normative references, RFC 5226 <https://tools.ietf.org/html/rfc5226>, has been obsoleted by RFC 8126 <https://tools.ietf.org/html/rfc8126>.
Several of the informative references have expired.
The draft would require numerous editorial changes due to errors in spelling, grammar, etc.

Regards, Greg

> On Jul 27, 2020, at 2:50 AM, Robert Raszuk <[email-masked]> wrote:
> 
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Robert,
> 
>  
> 
> From: Robert Raszuk <[email-masked] <mailto:[email-masked]>> 
> To: Linda Dunbar <[email-masked] <mailto:[email-masked]>>
> Cc: Lizhenbin <[email-masked] <mailto:[email-masked]>>; Jakob Heitz (jheitz) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]> [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Robert, Jakob, etc.
> 
>  
> 
> 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.
> 
>  
> 
> From: Robert Raszuk <[email-masked] <mailto:[email-masked]>> 
> To: Linda Dunbar <[email-masked] <mailto:[email-masked]>>; Lizhenbin <[email-masked] <mailto:[email-masked]>>
> Cc: Jakob Heitz (jheitz) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]> [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> On Fri, Jul 24, 2020 at 6:28 PM Linda Dunbar <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Jakob,
> 
>  
> 
> From: Jakob Heitz (jheitz) <[email-masked] <mailto:[email-masked]>> 
> To: Linda Dunbar <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>    . This avoids non-deterministic transient behavior between application of the first policy and the last..
> 
> From: Linda Dunbar <[email-masked] <mailto:[email-masked]>> 
> To: Jakob Heitz (jheitz) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> From: Jakob Heitz (jheitz) <[email-masked] <mailto:[email-masked]>> 
> To: Linda Dunbar <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> From: Idr <[email-masked] <mailto:[email-masked]>> On Behalf Of Linda Dunbar
> To: [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 29 Jul 2020 01:38:40 +0000

Hi Jakob,

    Thanks much for your providing an example of configurations to illustrate that configurations can be used to adjust/redirect the traffic.

    7 years ago, when a set of SR drafts were discussed in IETF, most of people strongly opposed SR. The reasons for opposing SR include 1) what SR can do, the existing protocols can do or even better, 2) SR introduces big overhead, ans so on. There was a Canadian ISP supporting SR around that time because she thought that SR would make operations on networks simple. Time flies like a light, this seems happened like yesterday.

    Configurations can be used to adjust the traffic. There are multiple customers who have deployed the RPD. Before deploying the RPD, they used the configurations to adjust the traffic in their networks. When the idea of the RPD was proposed, they preferred to it and thought that it would make their work on adjusting the traffic simpler. The results of the deployments have showed that it makes the work on adjusting the traffic easier.

Best Regards,
Huaimo
________________________________
From: rtgwg <[email-masked]> on behalf of Jakob Heitz (jheitz) <jheitz=[email-masked]>
Sent: Monday, July 27, 2020 6:45 PM
To: Linda Dunbar <[email-masked]>; Robert Raszuk <[email-masked]>; Lizhenbin <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: The automatic policy exchange by draft-ietf-idr-rpd-05.txt can be used for draft-ietf-rtgwg-net2cloud-gap-analysis

RPD is not automation.

even if you have RPD.

PE at the cloud end.

[An Ink Drawing]

router BGP x

  neighbor CE1

    route policy out

         set MED 2

      else

         set MED 1

      endif

    end

  end

  neighbor CE2

    route policy out

         set MED 2

      else

         set MED 1

      endif

    end

  end

end

On PE2, we configure:

router BGP x

  neighbor CE1

    route policy out

         set MED 2

      else

         set MED 1

      endif

    end

  end

  neighbor CE2

    route policy out

         set MED 2

      else

         set MED 1

      endif

    end

  end

end

On PE3, we configure:

router BGP x

  neighbor CE3

    route policy out

         set MED 2

      else

         set MED 1

      endif

    end

  end

  neighbor CE4

    route policy out

         set MED 2

      else

         set MED 1

      endif

    end

  end

end

On PE4, we configure:

router BGP x

  neighbor CE3

    route policy out

         set MED 2

      else

         set MED 1

      endif

    end

  end

  neighbor CE4

    route policy out

         set MED 2

      else

         set MED 1

      endif

    end

  end

end

and for each site.

Regards,

Jakob.

Robert, Jakob, etc.

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%7Chuaimo.chen%40futurewei.com%7C50fd5c640e6c4edf103d08d8327edbcb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637314867739477976&sdata=vHK4gBauqLe7rjr%2BLdrhuJz1Y7p0ZziKVSOqgQbd2JY%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.

Thank you very much.

Linda Dunbar

Linda,

Kind regards,
R.

Jakob,

- Atomic Transactions:

- Feedback:

  BGP is "spray and pray".

- Persistence:

Linda Dunbar

Regards,

Jakob.

Jakob,

Thank you very much,

Linda Dunbar

out in previous emails.

Regards,

Jakob.

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
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%7Chuaimo.chen%40futurewei.com%7C50fd5c640e6c4edf103d08d8327edbcb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637314867739477976&sdata=ndiQFRb97%2BdocVLbQFk5iMXq7cN%2BAIuIvxMj5hm5O18%3D&reserved=0>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 29 Jul 2020 05:30:08 +0000

Huaimo,

MPLS source routing was first proposed in 2004 in this draft
https://tools.ietf.org/html/draft-tian-mpls-lsp-source-route-01
So, in 10 years, your idea might take off too.
Cheers Albert.

I just can't see this. There is no way to specify a specific BGP session on the
addressed peer. Having the same policy applied to every session on one peer
seems unworkable. Maybe in your implementation you have a special case
to deal with this or you only have one session as a test implementation.
Anyway, I think you are leaving out some details about your use case.

Could you answer two questions:
1. Can you give enough details about your use case to convince the
working group that this is a good idea.
2. Why do you think a new address family in BGP is the best way to do
this, given that there are so many apparently better ways.

Regards,
Jakob.

From: Huaimo Chen <[email-masked]>
Sent: Tuesday, July 28, 2020 6:39 PM
To: Jakob Heitz (jheitz) <[email-masked]>; Linda Dunbar <[email-masked]>; Robert Raszuk <[email-masked]>; Lizhenbin <[email-masked]>
Cc: [email-masked]; [email-masked] [email-masked] <[email-masked]>; [email-masked]
Subject: Re: The automatic policy exchange by draft-ietf-idr-rpd-05.txt can be used for draft-ietf-rtgwg-net2cloud-gap-analysis

Hi Jakob,

    Thanks much for your providing an example of configurations to illustrate that configurations can be used to adjust/redirect the traffic..

Best Regards,
Huaimo
________________________________
From: rtgwg <[email-masked]<mailto:[email-masked]>> on behalf of Jakob Heitz (jheitz) <jheitz=[email-masked]<mailto:jheitz=[email-masked]>>
Sent: Monday, July 27, 2020 6:45 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Lizhenbin <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: The automatic policy exchange by draft-ietf-idr-rpd-05.txt can be used for draft-ietf-rtgwg-net2cloud-gap-analysis

RPD is not automation.

even if you have RPD.

PE at the cloud end.

[An Ink Drawing]

router BGP x

  neighbor CE1

    route policy out

         set MED 2

      else

         set MED 1

      endif

    end

  end

  neighbor CE2

    route policy out

         set MED 2

      else

         set MED 1

      endif

    end

  end

end

On PE2, we configure:

router BGP x

  neighbor CE1

    route policy out

         set MED 2

      else

         set MED 1

      endif

    end

  end

  neighbor CE2

    route policy out

         set MED 2

      else

         set MED 1

      endif

    end

  end

end

On PE3, we configure:

router BGP x

  neighbor CE3

    route policy out

         set MED 2

      else

         set MED 1

      endif

    end

  end

  neighbor CE4

    route policy out

         set MED 2

      else

         set MED 1

      endif

    end

  end

end

On PE4, we configure:

router BGP x

  neighbor CE3

    route policy out

         set MED 2

      else

         set MED 1

      endif

    end

  end

  neighbor CE4

    route policy out

         set MED 2

      else

         set MED 1

      endif

    end

  end

end

Now, CE10 has full control over which CE it chooses at which site..

and for each site.

Regards,

Jakob.

Robert, Jakob, etc.

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.

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.

Thank you very much.

Linda Dunbar

Linda,

Kind regards,
R.

Jakob,

I remember a few years ago that  Netconf advocators have claimed that Netconf can replace PCE, replace BGP, replace xx, ...

- Atomic Transactions:

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

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

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: Robert Raszuk <[email-masked]>
Date: Wed, 29 Jul 2020 11:05:53 +0200

Hi Greg,

Many thx for your comments. I do agree with all of them and if there is
interest in IDR to proceed all of your points will be addressed.

Just a note on the first point you made ...

The proposal was shelved due to claims being made at and around Stockholm
IETF that all we need is working BGP multi sessions to demux specific
AFI/SAFI to a different session or different process within the box.

Well 10 years after I have not seen this to happen in *any* implementation.

Moreover in the mean time I see the proposals like BGP-LS which were
promised during WG processing and LC to be deployed separately from Routing
BGP (ex: dedicated RRs) in real deployments running on the same session and
on the same platforms (RRs) where LSDB is fighting for processing resources
with IP routes.

So here when we are discussing just using BGP as a transport because:

a) it is there
b) it takes everything (well used to till today :)
c) it is loop free distribution

my point of mentioning use of ti-bgp proposal (btw second choice if you go
back to the note - first being JSON format and CURL for this type of
distributions) was to at least decouple it hard from IP routing.

Many thx,
Robert.

On Wed, Jul 29, 2020 at 3:06 AM Greg Skinner <[email-masked]>
wrote:

> (I limited the recipients in my response in order to (hopefully) focus on
> the IDR-specific topics covered in the quoted text.)
>
>    - There were several issues raised
>    <https://www.ietf.org/proceedings/75/minutes/idr.txt> during the IDR
>    WG meeting during IETF 75 that should be addressed, IMO.
>    - I found some other issues in the draft that weren’t brought up
>    during that meeting.  For example, in Section 5.5
>    <https://tools.ietf.org/html/draft-raszuk-ti-bgp-01#section-5.5>, it
>    is stated that "On the network side all today's BGP messages are send with
>    IP precedence value of Internetwork Control of 110000, which is used for
>    high-priority routing traffic.”  Is this true, even for open-source BGP
>    implementations?  I looked at the source code for three implementations
>    (Bird, FRR, and OpenBGPD), and was only able to confirm this for IPv4
>    OpenBGPD messages.
>    - One of the normative references, RFC 5226
>    <https://tools.ietf.org/html/rfc5226>, has been obsoleted by RFC 8126
>    <https://tools.ietf.org/html/rfc8126>.
>    - Several of the informative references have expired.
>    - The draft would require numerous editorial changes due to errors in
>    spelling, grammar, etc.
>
>
> Regards, Greg
>

---

From: Zhuangshunwan <[email-masked]>
Date: Wed, 29 Jul 2020 10:09:23 +0000

Hi Robert,

When you mentioned BGP multi-session, I wondered what the drawbacks of this solution were that it was abandoned?

Thanks,
Shunwan

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, July 29, 2020 5:06 PM
To: Greg Skinner <[email-masked]>
Cc: [email-masked]
Subject: [Idr] Transport Instance BGP

Hi Greg,

Many thx for your comments. I do agree with all of them and if there is interest in IDR to proceed all of your points will be addressed.

The proposal was shelved due to claims being made at and around Stockholm IETF that all we need is working BGP multi sessions to demux specific AFI/SAFI to a different session or different process within the box.

Moreover in the mean time I see the proposals like BGP-LS which were promised during WG processing and LC to be deployed separately from Routing BGP (ex: dedicated RRs) in real deployments running on the same session and on the same platforms (RRs) where LSDB is fighting for processing resources with IP routes.

a) it is there

my point of mentioning use of ti-bgp proposal (btw second choice if you go back to the note - first being JSON format and CURL for this type of distributions) was to at least decouple it hard from IP routing.

Many thx,
Robert.

On Wed, Jul 29, 2020 at 3:06 AM Greg Skinner <[email-masked]<mailto:[email-masked]>> wrote:
(I limited the recipients in my response in order to (hopefully) focus on the IDR-specific topics covered in the quoted text.)

  *   There were several issues raised<https://www.ietf.org/proceedings/75/minutes/idr.txt> during the IDR WG meeting during IETF 75 that should be addressed, IMO.
  *   I found some other issues in the draft that weren’t brought up during that meeting.  For example, in Section 5.5<https://tools.ietf.org/html/draft-raszuk-ti-bgp-01#section-5.5>, it is stated that "On the network side all today's BGP messages are send with IP precedence value of Internetwork Control of 110000, which is used for high-priority routing traffic.”  Is this true, even for open-source BGP implementations?  I looked at the source code for three implementations (Bird, FRR, and OpenBGPD), and was only able to confirm this for IPv4 OpenBGPD messages.
  *   One of the normative references, RFC 5226<https://tools.ietf.org/html/rfc5226>, has been obsoleted by RFC 8126<https://tools.ietf.org/html/rfc8126>.
  *   Several of the informative references have expired.
  *   The draft would require numerous editorial changes due to errors in spelling, grammar, etc.

Regards, Greg

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 29 Jul 2020 14:22:40 +0200

Multi-sessions was not (I guess) fully abandoned - but it never was
designed to provide full protocol separation.

For example such separation that proposals which utilize p2mp transport in
a p2p fashion to distribute configuration around can be taken out of IDR
and if community wishes be progressed in other WGs under different protocol
name.

Besides multi sessions in number of implementations as I recall was very
buggy.

Thx,
R.

On Wed, Jul 29, 2020 at 12:09 PM Zhuangshunwan <[email-masked]>
wrote:

> Hi Robert,
>
>
>
> When you mentioned BGP multi-session, I wondered what the drawbacks of
> this solution were that it was abandoned?
>
>
>
> Thanks,
>
> Shunwan
>
>
>
> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Robert Raszuk
> *Sent:* Wednesday, July 29, 2020 5:06 PM
> *To:* Greg Skinner <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* [Idr] Transport Instance BGP
>
>
>
> Hi Greg,
>
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 29 Jul 2020 20:26:52 +0000

Jakob,

Thank you very much for writing down the detailed configuration.

Two questions on your suggested configuration:

  1.  How does “CE10 has full control over which CE it chooses at which site”? is it via changing the matching address in MED2 and MED1?

  1.  Are those changes via NETCON? Are you suggesting the NETCON configurations sent among PEs?

Thank you.

Linda

From: Jakob Heitz (jheitz) <[email-masked]>
Sent: Monday, July 27, 2020 6:20 PM
To: Jakob Heitz (jheitz) <jheitz=[email-masked]>; Linda Dunbar <[email-masked]>; Robert Raszuk <[email-masked]>; Lizhenbin <[email-masked]>
Cc: [email-masked]; [email-masked] [email-masked] <[email-masked]>; [email-masked]
Subject: RE: The automatic policy exchange by draft-ietf-idr-rpd-05.txt can be used for draft-ietf-rtgwg-net2cloud-gap-analysis

Regards,
Jakob.

From: rtgwg <[email-masked]<mailto:[email-masked]>> On Behalf Of Jakob Heitz (jheitz)
Sent: Monday, July 27, 2020 3:46 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Lizhenbin <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: The automatic policy exchange by draft-ietf-idr-rpd-05.txt can be used for draft-ietf-rtgwg-net2cloud-gap-analysis

RPD is not automation.

On PE2, we configure:
router BGP x
  neighbor CE1
    route policy out

On PE3, we configure:
router BGP x
  neighbor CE3
    route policy out

On PE4, we configure:
router BGP x
  neighbor CE3
    route policy out

Regards,
Jakob.

Robert, Jakob, etc.

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%7C61b3ad50c727441f9ef208d8328392bd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637314887990050056&sdata=etWPXc%2FswCdQpS8cPB0PX3tvVJvFpnEJITH5e7kO6DU%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.

Thank you very much.

Linda Dunbar

Linda,

Kind regards,
R.

- Feedback:
  BGP is "spray and pray".

- Persistence:

Linda Dunbar

Regards,
Jakob.

Jakob,

Thank you very much,
Linda Dunbar

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.
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
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%7C61b3ad50c727441f9ef208d8328392bd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637314887990060052&sdata=n6vhuJaq34ewp4stBxi%2BvILdYrU5%2Fz%2B%2BzAhYWm6yoP4%3D&reserved=0>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 29 Jul 2020 20:42:50 +0000

By sending the appropriate community or communities with its route.

Suppose it wants CE1 to use PE1 and CE2 to use PE2, then it would
attach the communities 65000:1001, 65000:2002 to that route.
For another route, it might attach different communities.
If it wants to direct the traffic of CE4 and/or CE3,
it would attach communities for them as well.

No policies are ephemeral. They are set once and endure.
The traffic direction is done by attaching communities to routes.

(I fixed my earlier error of MED values)

Regards,
Jakob.

From: Linda Dunbar <[email-masked]>
Sent: Wednesday, July 29, 2020 1:27 PM
To: Jakob Heitz (jheitz) <[email-masked]>; Jakob Heitz (jheitz) <jheitz=[email-masked]>; Robert Raszuk <[email-masked]>; Lizhenbin <[email-masked]>
Cc: [email-masked]; [email-masked] [email-masked] <[email-masked]>; [email-masked]
Subject: RE: The automatic policy exchange by draft-ietf-idr-rpd-05.txt can be used for draft-ietf-rtgwg-net2cloud-gap-analysis

Jakob,

Thank you.

Linda

To: Jakob Heitz (jheitz) <jheitz=[email-masked]<mailto:jheitz=[email-masked]>>; Linda Dunbar <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Lizhenbin <[email-masked]<mailto:[email-masked]>>

Regards,
Jakob.

RPD is not automation.

On PE2, we configure:
router BGP x
  neighbor CE1
    route policy out

On PE3, we configure:
router BGP x
  neighbor CE3
    route policy out

On PE4, we configure:
router BGP x
  neighbor CE3
    route policy out

Regards,
Jakob.

Robert, Jakob, etc.

Thank you very much.

Linda Dunbar

Linda,

Kind regards,
R.

- Feedback:
  BGP is "spray and pray".

- Persistence:

Linda Dunbar

Regards,
Jakob.

Jakob,

Thank you very much,
Linda Dunbar

Regards,
Jakob.

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 30 Jul 2020 01:51:44 -0400

Robert

After reviewing your draft I do see a merit in reviving the draft.

I think SAFI stacking PE-RR can get out of control and all eggs in one
basket with a single TCP session.

I have designed some  implementations in the past where I have  broken out
the SAFI manually into separate IP TCP sessions iBGP loopback per SAFI to
provide redundancy but also from SAFI 128 129 perspective used for IP VPN
per VRF TE which was cumbersome but worked for total session separation
 also allows to break out each VRF into its own TE instance.

Now with the advent of SR you get the same per VRF coloring out of the box
pnp without having to breakout the session. 😊

Kind Regards

Gyan

On Wed, Jul 29, 2020 at 8:23 AM Robert Raszuk <[email-masked]> wrote:

>> Many thx for your comments.. I do agree with all of them and if there is
>> my point of mentioning use of ti-bgp proposal (btw second choice if you
>> go back to the note - first being JSON format and CURL for this type of
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Jul 2020 10:00:21 +0200

Hi Gyan,

Many thx for your support.

As said, if there is interest I am happy to respin the draft (fixing some
obvious deficiencies) and ask for adoption. That should be the good gauge
if there is rough consensus on this to proceed or not.

Above all when BGP is used to carry IP routing or VPNv4 or BGP-LS it seems
obvious that there is value to let the operator control which process is
serviced by how many CPU cores. And we could generalize this more leaving
port 179 to IP routing AFs and allowing not one but perhaps range of ports
to be defined for local selection on a per application basis.

Especially when we see BGP virtualization and functions like reflection
being deployed on x86 commodity compute servers there is no longer need to
keep everything under one front process umbrella and let the implementation
decide how many sub-processes/threads is used along with compute or
memory allocations.

My only personal fear is that success of this work may even further delay
work and adoption on network message bus NMB type of distribution of data
among network elements in a true pub-sub fashion. Something I do believe we
should have a long time back. For one while I have seen interest in
community I observed no interest from major vendors and for two why bother
if we have BGP which can take more and more load on it ... Perhaps shutting
down RPD draft can be a good trigger for such an effort to start.

Kind regards,
R.

On Thu, Jul 30, 2020 at 7:51 AM Gyan Mishra <[email-masked]> wrote:

>> For example such separation that proposals which utilize p2mp transport
>> in a p2p fashion to distribute configuration around can be taken out of IDR
>>> The proposal was shelved due to claims being made at and around
>>> Stockholm IETF that all we need is working BGP multi sessions to demux
>>> specific AFI/SAFI to a different session or different process within the
>>> box.
>>>
>>>
>>>
>>> (I limited the recipients in my response in order to (hopefully) focus
>>> on the IDR-specific topics covered in the quoted text.)
>>>
>>>
>>>
>>>    - The draft would require numerous editorial changes due to errors
>>>    in spelling, grammar, etc.
>>>
>>>
>>>
>>> Regards, Greg
>>>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 30 Jul 2020 15:09:28 +0000

Jakob,

Don’t you think your described procedure is extremely configuration heavy and error prone?
If PE1 and PE2 is configured with FAT fingers causing the number not matching with the communities that CE10 is using, then this procedure won’t work.

Linda Dunbar

From: Jakob Heitz (jheitz) <[email-masked]>
Sent: Wednesday, July 29, 2020 3:43 PM
To: Linda Dunbar <[email-masked]>; Jakob Heitz (jheitz) <jheitz=[email-masked]>; Robert Raszuk <[email-masked]>; Lizhenbin <[email-masked]>
Cc: [email-masked]; [email-masked] [email-masked] <[email-masked]>; [email-masked]
Subject: RE: The automatic policy exchange by draft-ietf-idr-rpd-05.txt can be used for draft-ietf-rtgwg-net2cloud-gap-analysis

Regards,
Jakob.

To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>; Jakob Heitz (jheitz) <jheitz=[email-masked]<mailto:jheitz=[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Lizhenbin <[email-masked]<mailto:[email-masked]>>

Jakob,

Thank you.

Linda

Regards,
Jakob.

RPD is not automation.

On PE2, we configure:
router BGP x
  neighbor CE1
    route policy out

On PE3, we configure:
router BGP x
  neighbor CE3
    route policy out

On PE4, we configure:
router BGP x
  neighbor CE3
    route policy out

Regards,
Jakob.

Robert, Jakob, etc.

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%7C89333027acd2498c1fd008d833fff82d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637316521774594105&sdata=INEOt%2F%2FstDbv7ooETdlbS6i%2FgKQnoUbrqH7ymSrNJ4E%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.

Thank you very much.

Linda Dunbar

Linda,

Kind regards,
R.

- Feedback:
  BGP is "spray and pray".

- Persistence:

Linda Dunbar

Regards,
Jakob.

Jakob,

Thank you very much,
Linda Dunbar

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.
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
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%7C89333027acd2498c1fd008d833fff82d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637316521774604060&sdata=kEZ3AlyS8OBJWOJdxqgk3fcid9oCJmjGOgtCRv9jmvw%3D&reserved=0>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 30 Jul 2020 15:57:19 +0000

No. I don't.
A signaling mechanism is not "error prone".
A UI (User Interface) may be error prone.
You design a UI to allow a user to make choices and error check the choices.
The UI then formulates the message.
We are talking about the signaling mechanism, not the UI here.

Regards,
Jakob.

Sent: Thursday, July 30, 2020 8:09 AM

Jakob,

Linda Dunbar

To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; Jakob Heitz (jheitz) <jheitz=[email-masked]<mailto:jheitz=[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Lizhenbin <[email-masked]<mailto:[email-masked]>>

Regards,
Jakob.

Jakob,

Thank you.

Linda

Regards,
Jakob.

RPD is not automation.

On PE2, we configure:
router BGP x
  neighbor CE1
    route policy out

On PE3, we configure:
router BGP x
  neighbor CE3
    route policy out

On PE4, we configure:
router BGP x
  neighbor CE3
    route policy out

Regards,
Jakob.

Robert, Jakob, etc.

Thank you very much.

Linda Dunbar

Linda,

Kind regards,
R.

- Feedback:
  BGP is "spray and pray".

- Persistence:

Linda Dunbar

Regards,
Jakob.

Jakob,

Thank you very much,
Linda Dunbar

Regards,
Jakob.

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 30 Jul 2020 19:05:52 -0400

Welcome.  Let’s see what others think and  if it’s worthwhile.

IDR folks -

Please review this draft and let Robert and myself know if its something
worth reviving.

https://tools.ietf.org/html/draft-raszuk-ti-bgp-01

I noticed in the draft it mentioned BGP instances for critical and not
critical.  That is a very interesting topic.  I believe the you are
referring to multiple BGP instances on a router meaning on a single router
or these days now virtual instantiation of a router

Over the years it has been painstakingly difficult having the restriction
of a single BGP AS instance on a router, and would be nice to be able to
have multiple instances.  There are are of course special overlay or fusion
router type scenarios where you are routing between VRF and Global table on
the same router.  There are other overlay scenarios where it would be nice
to be able to have multiple instances such as for critical and not critical
as described in the draft or any use case type really.  To get around this
issue you end up having to use BGP knobs as a workaround such as local-as,
as-override and allowas-in to get around this issue.

I agree with the concept as it’s similar to dynamic BGP where you have
promiscuous peering where you specify an address range for the promiscuous
peer to come up, similarly I can see having a range of TCP ports per SAFI
and then be able to distribute across processors and cores providing
parallel processing (symmetrical multi processing) versus pipelining or
single threading all SAFI, thus splitting off each SAFI onto a discrete
thread.  From a management and MTTR perspective it is much easier to do
multi session with same IP then binding each SAFI to a different IP.

Agreed as the move from commodify hardware to white box hardware and
software vendors merchant silicon over property asic  or even incumbent
vendor now providing disaggregation of hardware and software.

Also with virtualization of network functions and removal of physical
hardware in a service chain with VNF software VMs with advent of NFV for
control plane functions such as RR - perfect candidate for NFV processed in
software.  I can see NVF implementations benefiting from this solution.

All the more reason I think that this would help with redundancy and
scalability as well as optimization when stack of SAFI PE-RR is a mile long.

Trying to garner support from vendors is challenging for individual
contributors without vendor affiliation but it is definitely possible if
you can build the concept into a marketing strategy that had monetary gain
with the gap being filled.  I agree we don’t want the dump trunk approach
with BGP, as is first and foremost job is as a routing protocol and it’s
sole purpose in life is to carry AFI/SAFI NLRI.

Is tried searching for the nmb draft but could not locate.

My 2 cents in summary as to why we should bring back the draft:

1. Multiple BGP instances feature

2. Decoupling SAFI onto different sockets and different processors or cores

Kind Regards

Gyan

On Thu, Jul 30, 2020 at 4:00 AM Robert Raszuk <[email-masked]> wrote:

>> I have designed some  implementations in the past where I have  broken
>> out the SAFI manually into separate IP TCP sessions iBGP loopback per SAFI
>> to provide redundancy but also from SAFI 128 129 perspective used for IP
>> VPN per VRF TE which was cumbersome but worked for total session separation
>> Now with the advent of SR you get the same per VRF coloring out of the
>> box pnp without having to breakout the session. 😊
>>
>> Kind Regards
>>
>> Gyan
>>
>>
>>
>>>> Many thx for your comments.. I do agree with all of them and if there
>>>> is interest in IDR to proceed all of your points will be addressed.
>>>>
>>>
>>>>
>>>>    <https://www.ietf.org/proceedings/75/minutes/idr.txt> during the
>>>>    IDR WG meeting during IETF 75 that should be addressed, IMO.
>>>>    <https://tools.ietf.org/html/draft-raszuk-ti-bgp-01#section-5.5>,
>>>>    it is stated that "On the network side all today's BGP messages are send
>>>>    with IP precedence value of Internetwork Control of 110000, which is used
>>>>    for high-priority routing traffic.”  Is this true, even for open-source BGP
>>>>    <https://tools.ietf.org/html/rfc5226>, has been obsoleted by RFC
>>>>    8126 <https://tools.ietf.org/html/rfc8126>.
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>>
>> --

*Gyan Mishra*

---

From: Randy Bush <[email-masked]>
Date: Thu, 30 Jul 2020 21:17:09 -0700

> https://tools.ietf.org/html/draft-raszuk-ti-bgp-01

imiho, there are a lot of things currently called "routing related" i
would throw on the other side of that wall.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 31 Jul 2020 12:48:42 +0200

Very true ... we could always rename it to "Internet routing related"

In fact this should be win-win for both ... more stable Internet on one
hand and lower bar for new twicks and mangling with BESS like or NETCONF
like insertions to essentially a p2mp path vector protocol.

In fact we see it more and more these days (example SRv6-NP long
discussions) where Internet engineering and stability and close domain
network design and engineering do not align. They are very different and
trying to either stretch one or trim the other what we see in number of
IETF WGs is just not the right thing to do.

One would think that IETF as the name says is about the former ... but if
we see RFCs and drafts maybe just a small percentage of them indicates so.
Almost like the "I" there stands for IP and not Internet ....

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 31 Jul 2020 17:25:56 -0400

Sounds like plan.

I like the win-win for BGP.👍

Those two camps Service Provider and  Enterprise are closely aligning and
converging as a major the variable is size, and if the private closed
domain is a worldwide massive network, they are very close to being
completely aligned as is the case with Verizon and maybe other Tier 1 and
Tier 2 providers.  Of course the closed domain bar can swing from tiny to
massive which is your point. Agreed.

I agree on the former however the IETF has individual representation from
all camps thus the world we live in and cannot satisfy everyone but the bar
can swing from small to large.  Finding the happy medium is a challenge but
that is part of our job in achieving WG consensus and IETF adoption on any
protocol specification.

That being said from an IETF and protocol development perspective you have
to think of the trickle down of the protocol specifications as it applies
to all vendors and all routers switches appliances you name it that runs
any protocol or specification developed - ospf Isis BGP MPLS SR etc.

Since that protocol specification developed by the IETF can sit on a tiny
CPE box running BGP MPLS SR or even BIER or commodify incumbent hardware
vendor Service Provider massive OTN box with high 400G density, or NFV
server - router VNFs, or 1RU pizza box white box running disaggregated
software from incumbent commodity vendor, the IETF standard is a standard
for all implementation of the protocol specification independent of
hardware mode or brand big or small it applies to every vendor development
and implementing software.

Kind Regards

Gyan

*Gyan Mishra*

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 31 Jul 2020 15:03:22 -0700

There had been a variety of proposals (to my memory) to decouple BGP(kitchen sink) from BGP(reachability).
I’d be all in to rejuvenate this effort, and use Robert’ document as the starting point.

Cheers,
Jeff
On Jul 31, 2020, 2:26 PM -0700, Gyan Mishra <[email-masked]>, wrote:
> Those two camps Service Provider and  Enterprise are closely aligning and converging as a major the variable is size, and if the private closed domain is a worldwide massive network, they are very close to being completely aligned as is the case with Verizon and maybe other Tier 1 and Tier 2 providers.  Of course the closed domain bar can swing from tiny to massive which is your point. Agreed.
>
> I agree on the former however the IETF has individual representation from all camps thus the world we live in and cannot satisfy everyone but the bar can swing from small to large.  Finding the happy medium is a challenge but that is part of our job in achieving WG consensus and IETF adoption on any protocol specification.
>
> That being said from an IETF and protocol development perspective you have to think of the trickle down of the protocol specifications as it applies to all vendors and all routers switches appliances you name it that runs any protocol or specification developed - ospf Isis BGP MPLS SR etc.
>
> Since that protocol specification developed by the IETF can sit on a tiny CPE box running BGP MPLS SR or even BIER or commodify incumbent hardware vendor Service Provider massive OTN box with high 400G density, or NFV server - router VNFs, or 1RU pizza box white box running disaggregated software from incumbent commodity vendor, the IETF standard is a standard for all implementation of the protocol specification independent of hardware mode or brand big or small it applies to every vendor development and implementing software.
>
>
> Kind Regards
>
> Gyan
>
>
> > > In fact this should be win-win for both ... more stable Internet on one hand and lower bar for new twicks and mangling with BESS like or NETCONF like insertions to essentially a p2mp path vector protocol.
> > >
> > > In fact we see it more and more these days (example SRv6-NP long discussions) where Internet engineering and stability and close domain network design and engineering do not align. They are very different and trying to either stretch one or trim the other what we see in number of IETF WGs is just not the right thing to do.
> > >
> > > One would think that IETF as the name says is about the former ... but if we see RFCs and drafts maybe just a small percentage of them indicates so.  Almost like the "I" there stands for IP and not Internet ....
> > >
> Gyan Mishra
> Network Solutions Architect
> M 301 502-1347
> 13101 Columbia Pike
> Silver Spring, MD
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 1 Aug 2020 00:05:49 +0200

Hi Jeff,

Can you provide any references to other proposals aiming at this space
within BGP ?

Thank you,
R.

On Sat, Aug 1, 2020 at 12:03 AM Jeff Tantsura <[email-masked]>
wrote:

> There had been a variety of proposals (to my memory) to decouple
> BGP(kitchen sink) from BGP(reachability).
> *M 301 502-1347 13101 Columbia Pike *Silver Spring, MD
>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 31 Jul 2020 18:54:08 -0400

Please count me all in as well on the rejuvenation effort!!

Kind Regards

Gyan

On Fri, Jul 31, 2020 at 6:06 PM Robert Raszuk <[email-masked]> wrote:

>> That being said from an IETF and protocol development perspective you
>> have to think of the trickle down of the protocol specifications as it
>> applies to all vendors and all routers switches appliances you name it that
>> runs any protocol or specification developed - ospf Isis BGP MPLS SR etc.
>>
>>> One would think that IETF as the name says is about the former ... but
>>> if we see RFCs and drafts maybe just a small percentage of them indicates
>>> so.  Almost like the "I" there stands for IP and not Internet ....
>>>
>> *M 301 502-1347 13101 Columbia Pike

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 31 Jul 2020 19:18:12 -0400

Jeff

So let’s say we look at the AFI SAFI list below

https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml

Quick parse into 2 buckets

SAFI = Reachability all others

SAFI = Kitchen Sink
7  8 64 66 67 68 69 71 72  73 74 75 76 132 133 134, 140 RPD and the likes

On Fri, Jul 31, 2020 at 6:54 PM Gyan Mishra <[email-masked]> wrote:

>>> Those two camps Service Provider and  Enterprise are closely aligning
>>> and converging as a major the variable is size, and if the private closed
>>> I agree on the former however the IETF has individual representation
>>> from all camps thus the world we live in and cannot satisfy everyone but
>>> the bar can swing from small to large.  Finding the happy medium is a
>>> challenge but that is part of our job in achieving WG consensus and IETF
>>> adoption on any protocol specification.
>>>
>>> Since that protocol specification developed by the IETF can sit on a
>>> tiny CPE box running BGP MPLS SR or even BIER or commodify incumbent
>>> hardware vendor Service Provider massive OTN box with high 400G density, or
>>> NFV server - router VNFs, or 1RU pizza box white box running disaggregated

*Gyan Mishra*

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 31 Jul 2020 20:06:43 -0700

I clearly remember Kireeti talking about it, perhaps at MPLS congress, around 2013. I can’t find any  traces of it though ;-)

Regards,
Jeff

> On Jul 31, 2020, at 15:06, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Hi Jeff,
> 
> Can you provide any references to other proposals aiming at this space within BGP ? 
> 
> Thank you,
> R.
> 
>> On Sat, Aug 1, 2020 at 12:03 AM Jeff Tantsura <[email-masked]> wrote: