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