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://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-net2cloud-problem-statement-18#section-3.1>. 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 <[email protected]> On Behalf Of Robert Raszuk Sent: Monday, January 16, 2023 2:03 PM To: Linda Dunbar <[email protected]> Cc: [email protected]; [email protected] 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 <[email protected]<mailto:[email protected]>> wrote: Robert, Who are the "folks" responsible for making the change? Linda From: Robert Raszuk <[email protected]<mailto:[email protected]>> Sent: Monday, January 16, 2023 2:32 PM To: Linda Dunbar <[email protected]<mailto:[email protected]>> Cc: Jeffrey Haas <[email protected]<mailto:[email protected]>>; Gyan Mishra <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-net2cloud-problem-statement%2F&data=05%7C01%7Ckmajumdar%40microsoft.com%7C73aed04a767d45111eef08daf80d6f61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638095033847536253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wyUeXwdJn0QxqbLumCoRvOkDqgSKM1URvOmfE8h1H%2Bs%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 <[email protected]<mailto:[email protected]>> Sent: Monday, January 16, 2023 1:45 PM To: Robert Raszuk <[email protected]<mailto:[email protected]>> Cc: Linda Dunbar <[email protected]<mailto:[email protected]>>; Gyan Mishra <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/idr<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=05%7C01%7Ckmajumdar%40microsoft.com%7C73aed04a767d45111eef08daf80d6f61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638095033847536253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OSAuEnteo1Bs5Q2GLeCw6EPmU%2BPOVcJKMN46fGOyd%2Fo%3D&reserved=0>
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
