> 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 <[email protected]> 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://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]> > wrote: > > Robert, > > Who are the “folks” responsible for making the change? > > > > Linda > > > > *From:* Robert Raszuk <[email protected]> > *Sent:* Monday, January 16, 2023 2:32 PM > *To:* Linda Dunbar <[email protected]> > *Cc:* Jeffrey Haas <[email protected]>; Gyan Mishra <[email protected]>; > [email protected]; [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]> > 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]> > Sent: Monday, January 16, 2023 1:45 PM > To: Robert Raszuk <[email protected]> > Cc: Linda Dunbar <[email protected]>; Gyan Mishra < > [email protected]>; [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] > 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
