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://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%7C6fc32b560e9342a27bd508daf800bdf7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638094979345574739%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RnQ95WO35tXFp0ZzFkw7J%2B71q8hogfLSoRf1Wft%2FhMY%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 >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
