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

[Robert Raszuk]

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 
wrote:

> Robert,
>
>
>
> Thank you very much for the explanation.
>
> “new BGP Transport Instance with new separate port and separate process”,
> very interesting perspective.
>
>
>
> But draft-raszuk-ti-bgp-01 was written 10 years ago. Is it still valid and
> worth pursuing?
>
>
>
> Thank you
>
> Linda
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Sunday, July 26, 2020 5:23 PM
> *To:* Linda Dunbar 
> *Cc:* Lizhenbin ; Jakob Heitz (jheitz) <
> jhe...@cisco.com>; i...@ietf.org; grow@ietf.org grow@ietf.org <
> grow@ietf.org>; rt...@ietf.org
> *Subject:* Re: The automatic policy exchange by draft-ietf-idr-rpd-05.txt
> can be used for draft-ietf-rtgwg-net2cloud-gap-analysis
>
>
>
> Hi Linda,
>
>
>
> So are you suggesting that this new SAFI is to be sent on EBGP too ?? Whow
> ... Note BGP is not too secure transport ! I would never allow any peer to
> push me policy via eBGP to my ASBRs regardless how much I would trust it.
>
>
>
> That aside I think no one is questioning that overall this is nice to have
> BGP policy distributed in a dynamic way. We are however concerned in
> three planes ...
>
>
>
> Aspect #1 - BGP is p2mp and information and encoding (NLRI) here clearly
> make this proposal p2p. And no Robin p2p is not a special case of p2mp :)
>
>
>
> Aspect #2 - This proposal adds additional burden to IP Routing BGP
> subsystem and its clear that if approved there will be more and more
> extensions to new MATCH and SET sub-TLVs coming. While it is easy to write
> a draft that at the end requires a serious commitment from any vendor to
> now turn BGP into configuration channel. That means overall more cycles
> spend and more burden on BGP dev teams.
>
>
>
> Aspect #3 - The proposal has lots of technical issues (as described) which
> can not just be swapped under the carpet.
>
>
>
> My recommendations (in order of preference):
>
>
>
> *1*
>
>
>
> Turn proposed sub-TLVs into JSON and use HTTPS PUT, GET & DELETE along
> with real time response status codes to send required policy over targeted
> TCP sessions just using curl to remote ASBRs. Note all vendors today
> support RESTful commands or httpd on the routers. Some already even support
> JSON based BGP configuration for some time now (ex: NX-OS).
>
>
>
> *2*
>
>
>
> At least decouple it from routing BGP - support new BGP Transport Instance
> with new separate port and separate process. Whenever we need to use such
> protocol (call it Configuration Transport Protocol "CTP") for loop free
> information dissemination such isolation could deliver what you are really
> after with no impact to stability of IP routing.
>
> Ref: https://tools.ietf.org/html/draft-raszuk-ti-bgp-01
> 
>
>
>
>
> Thx,
>
> R.
>
>
>
>
>
> On Sun, Jul 26, 2020 at 11:53 PM Linda Dunbar 
> wrote:
>
> Robert, Jakob, etc.
>
>
>
> Thank you very much for detailed explanation of the issues.
>
> One of the points you all raised is that p2p policies should be
> administrated by controller via NETCONF.
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/
> 
> 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 
> *Sent:* Friday, July 24, 2020 2:50 PM
> *To:* Linda Dunbar ; Lizhenbin <
> 

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

[Linda Dunbar]

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 
Sent: Sunday, July 26, 2020 5:23 PM
To: Linda Dunbar 
Cc: Lizhenbin ; Jakob Heitz (jheitz) ; 
i...@ietf.org; grow@ietf.org grow@ietf.org ; rt...@ietf.org
Subject: Re: The automatic policy exchange by draft-ietf-idr-rpd-05.txt can be 
used for draft-ietf-rtgwg-net2cloud-gap-analysis

Hi Linda,

So are you suggesting that this new SAFI is to be sent on EBGP too ?? Whow ... 
Note BGP is not too secure transport ! I would never allow any peer to push me 
policy via eBGP to my ASBRs regardless how much I would trust it.

That aside I think no one is questioning that overall this is nice to have BGP 
policy distributed in a dynamic way. We are however concerned in three planes 
...

Aspect #1 - BGP is p2mp and information and encoding (NLRI) here clearly make 
this proposal p2p. And no Robin p2p is not a special case of p2mp :)

Aspect #2 - This proposal adds additional burden to IP Routing BGP subsystem 
and its clear that if approved there will be more and more extensions to new 
MATCH and SET sub-TLVs coming. While it is easy to write a draft that at the 
end requires a serious commitment from any vendor to now turn BGP into 
configuration channel. That means overall more cycles spend and more burden on 
BGP dev teams.

Aspect #3 - The proposal has lots of technical issues (as described) which can 
not just be swapped under the carpet.

My recommendations (in order of preference):

*1*

Turn proposed sub-TLVs into JSON and use HTTPS PUT, GET & DELETE along with 
real time response status codes to send required policy over targeted TCP 
sessions just using curl to remote ASBRs. Note all vendors today support 
RESTful commands or httpd on the routers. Some already even support JSON based 
BGP configuration for some time now (ex: NX-OS).

*2*

At least decouple it from routing BGP - support new BGP Transport Instance with 
new separate port and separate process. Whenever we need to use such protocol 
(call it Configuration Transport Protocol "CTP") for loop free information 
dissemination such isolation could deliver what you are really after with no 
impact to stability of IP routing.
Ref: 
https://tools.ietf.org/html/draft-raszuk-ti-bgp-01

Thx,
R.


On Sun, Jul 26, 2020 at 11:53 PM Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:
Robert, Jakob, etc.

Thank you very much for detailed explanation of the issues.
One of the points you all raised is that p2p policies should be administrated 
by controller via NETCONF.

https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/
 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.



[cid:image001.jpg@01D66381.DF851460]



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 mailto:rob...@raszuk.net>>
Sent: Friday, July 24, 2020 2:50 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Lizhenbin 
mailto:lizhen...@huawei.com>>
Cc: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>; 
i...@ietf.org; grow@ietf.org 
grow@ietf.org mailto:grow@ietf.org>>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Linda,

It seems that authors of this document are strongly pushing to pass the last 
call irrespective of observations 

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

[Robert Raszuk]

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 
wrote:

> Robert, Jakob, etc.
>
> Thank you very much for detailed explanation of the issues.
> One of the points you all raised is that p2p policies should be
> administrated by controller via NETCONF.
>
> *https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/*
> 
> 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 
> *Sent:* Friday, July 24, 2020 2:50 PM
> *To:* Linda Dunbar ; Lizhenbin <
> lizhen...@huawei.com>
> *Cc:* Jakob Heitz (jheitz) ; i...@ietf.org; grow@ietf.org
> grow@ietf.org 
> *Subject:* Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
> 7/29/2020)
>
> Linda,
>
> It seems that authors of this document are strongly pushing to pass the
> last call irrespective of observations made by WG.
>
> As said before and as reiterated by Jakob and Ketan BGP is not the right
> tool for p2p config push. We must stop adding such extensions to BGP like
> this one or BGP-LS or SR Policies if we really want to keep routing at some
> proper stability levels.
>
> But even if you would convince everyone in IDR that this is all great the
> draft itself is so immature that I can't imagine why are we discussing last
> call at this time.
>
> * Please observe that BGP state is ephemeral. When BGP sessions resets all
> state previously distributed is gone (modulo GR ...) Is the
> expectation here that state distributed by this new SAFI will persists ? If
> so for how long ? If not have you even considered the initial churn ?
>
> * We have hooks to make sure LDP and IGP play in concert with BGP
> reachability. Would we need to now add to also wait for BGP policy to be
> received from controllers ?
>
> * We have spent fair amount of time to make sure GR works well. Do you
> expect to now GR to recognize all policy parameters and sync deltas locally
> upon BGP sessions restarts ?
>
> * Do you expect BGP implementations to now get busy with understanding all
> BGP policies syntax and semantics not in current terms how they are send or
> received in BGP UPDATEs but how they are applied implementation by
>