Re: [Idr] [EXTERNAL] Re: draft-ietf-rtgwg-net2cloud-problem-statement description on BGP error valid? (was RE: WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

[Linda Dunbar <[e-mail]>]

Robert,

Jeff Haas said in his Jan 16 email (attached)

"John Scudder made most of the arguments I'd be supporting.  This is optional, and capabilities say you should be ignoring things you don't understand anyway.  Why force the implementation to hang up the session?"

Do you need BGP profile to achieve continuing the BGP session when receiving the unrecognized "optional capability" in BGP Open message?

Linda

From: Robert Raszuk <[e-mail]>
Sent: Monday, January 16, 2023 6:14 PM
To: Kausik Majumdar <[e-mail]>
Cc: Linda Dunbar <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [EXTERNAL] Re: [Idr] draft-ietf-rtgwg-net2cloud-problem-statement description on BGP error valid? (was RE: WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25


> Can we use our current Draft to update and describe the best practices for the mitigation?

I don't think that the Informational draft in RTGWG can be used to make any modifications to any BGP Message Error Handling.

> As the scope of the document is to characterize the network-related problems that Enterprises
> face today when interconnecting their branch offices with dynamic workloads in the Cloud DCs
> and the mitigation practices, it might be useful to recommend /capture mitigation practices for the
> Section 3.1 BGP Errors Handling.

The problem is that we do not have a separate BGP "version/profile" for interconnecting branch offices with Cloud DCs.

That means that we can not customize core BGP protocol operation to be optimal to such deployment space.

- - -

I think that if we would go and define the notion of "BGP Profiles" - lot's of useful customization could be made with
lowering the bar for each.

I could think of few obvious such profiles already:

* Internet BGP IPv4/IPv6 Profile
* Intradomain Routing Profile
* Data Center BGP Profile
* Private Overlay Transport BGP Profile

Now the obvious challenge is to maximize the code reuse while at the same time achieve profile isolation/separation.

Regards,
Robert


On Tue, Jan 17, 2023 at 12:25 AM Kausik Majumdar <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert, Sue, IDR Chairs, et. all,

Can we use our current Draft to update and describe the best practices for the mitigation? As the scope of the document is to characterize the network-related problems that Enterprises face today when interconnecting their branch offices with dynamic workloads in the Cloud DCs and the mitigation practices, it might be useful to recommend /capture mitigation practices for the Section 3.1 BGP Errors Handling.


3.1<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-rtgwg-net2cloud-problem-statement-18%23section-3.1&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C938968be009a4538691708daf81fc400%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638095112586296054%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JUI%2B2dMjbQKtkZhfXZyYSSmgYVfDuVS5uo7OydiIt8k%3D&reserved=0>. Increased BGP errors and Mitigation Methods
-----------------------------------------------------------------------------------------------------
Abstract

   This document describes the network-related problems enterprises
   face today when interconnecting their branch offices with dynamic
   workloads in third-party data centers (a.k.a. Cloud DCs) and some
   mitigation practices.
­-----------------------------------------------------------------------------------------------------


Regards,
Kausik


From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Robert Raszuk
Sent: Monday, January 16, 2023 2:03 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: [Idr] draft-ietf-rtgwg-net2cloud-problem-statement description on BGP error valid? (was RE: WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25


Any IDR WG member ... :)

On Mon, Jan 16, 2023 at 10:59 PM Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:
Robert,
Who are the "folks" responsible for making the change?

Linda

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Monday, January 16, 2023 2:32 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: Jeffrey Haas <[e-mail]<mailto:[e-mail]>>; Gyan Mishra <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: draft-ietf-rtgwg-net2cloud-problem-statement description on BGP error valid? (was RE: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Hi Linda,

I see where you are going with this .. I was expecting so - thank you for confirming.

So RFC7606 talks about BGP UPDATE Message error handling.

To the best of my knowledge we do not have revised Error Handling for BGP OPEN Message. So I would propose you encourage folks to work on it before you proceed with the below section 3.1.

Many thx,
Robert


On Mon, Jan 16, 2023 at 9:22 PM Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:
Robert, Jeffrey, Gyan,

The reason for my question is to validate the description of the Section 3.1 (Increased BGP error) in the https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-net2cloud-problem-statement%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C938968be009a4538691708daf81fc400%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638095112586296054%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cAnaj7s3crPbUCREIDjjd23Zb0cAGmDxF5Sm0Te4Y%2Fw%3D&reserved=0>

Love to hear your comments to this description
--------------------------------------------------
3.1. Increased BGP errors and Mitigation Methods
Many network service providers have limited number of BGP peers and usually have prior negotiated peering policies with their BGP peers. Cloud GWs need to peer with many more parties, via private circuits or IPsec over public internet. Many of those peering parties may not be traditional network service providers. Their BGP configurations practices might not be consistent, and some are done by less experienced personnel. All those can contribute to increased BGP peering errors, such as capability mismatch, BGP ceasing notification, unwanted route leaks, missing Keepalives, etc. Capability mismatch can cause BGP sessions not established properly.
If a BGP speaker receives a BGP OPEN message with the unrecognized Optional Parameters, an error message should be generated per RFC 4271, although the BGP session can be established. When receiving a BGP UPDATE with a malformed attribute, the revised BGP error handling procedure [RFC7606] should be followed instead of session resetting.
Many Cloud DCs don't support multi hop eBGP peering with external devices. To get around this limitation, it is necessary for enterprises GWs to establish IP tunnels to the Cloud GWs to form IP adjacency.
Some Cloud DC eBGP peering only supports limited number of routes from external entities. To get around this limitation, on-premises DCs need to set up default routes to be exchanged with the Cloud DC eBGP peers.
-----------

Thank you very much
Linda Dunbar

-----Original Message-----
From: Jeffrey Haas <[e-mail]<mailto:[e-mail]>>
Sent: Monday, January 16, 2023 1:45 PM
To: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Cc: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; Gyan Mishra <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Robert,

On Mon, Jan 16, 2023 at 08:28:27PM +0100, Robert Raszuk wrote:
> I am afraid you are talking about BGP version while Linda is asking
> about the subject draft bgp version ... Both are completely unrelated "versions".

I'm answering Linda's literal question.  In the cited text, she is not asking about the new version capability.  If her intent was to ask about that, her text wasn't stating what she wanted to ask.

> While we are here I did reread RFC4271 and I am not sure either if
> there is text to mandate closing the session when new BGP OPEN
> Optional Parameter is not recognized. Neither does FSM. Generating
> NOTIFICATION and continue should be allowed by the spec unless I
> missed some embedded mandate to close it.

RFC 4271, §6.2:

:    If one of the Optional Parameters in the OPEN message is not
:    recognized, then the Error Subcode MUST be set to Unsupported
:    Optional Parameters.
:
:    If one of the Optional Parameters in the OPEN message is recognized,
:    but is malformed, then the Error Subcode MUST be set to 0
:    (Unspecific).

-- Jeff

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C938968be009a4538691708daf81fc400%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638095112586296054%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RrjOaqOVuegtCj5bkyFKAUrmBfyl2YxQEv3sKn9RcTU%3D&reserved=0>

--- Begin Message ---

On Sun, Jan 15, 2023 at 07:28:33PM +0000, Jakob Heitz (jheitz) wrote:
> I can agree to using a new BGP OPEN Optional Parameter.
> 
> I would add that if after receiving the OPEN message, the BGP neighbor closes the session
> with “Unsupported Optional Parameters”, that the sender of that OPEN message try
> opening the session again without the version parameter.
> 
> Graceful restart is affected. When a restarted session is restarted a second time,
> stale markings are removed. To prevent that, when a neighbor has previously restarted a session
> due to not supporting the new version parameter, a session that is restarted due to GR should not
> include the version parameter.

Whereas for exactly these reasons, I wouldn't want it in the optional
parameter.

John Scudder made most of the arguments I'd be supporting.  This is
optional, and capabilities say you should be ignoring things you don't
understand anyway.  Why force the implementation to hang up the session?

-- Jeff

_______________________________________________
Idr mailing list
[e-mail]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C525b05620f8d4eeb4b9108daf7f75e14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638094939070062949%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5vzNoGSMtnUYuDNeLkA63CplQ2fzEp%2BG80rwciAvyUU%3D&reserved=0

--- End Message ---