https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/
-----Original Message----- From: Linda Dunbar Sent: Monday, August 19, 2024 5:44 PM To: Jim Guichard <jguichard1...@gmail.com> Cc: James Guichard <james.n.guich...@futurewei.com>; draft-ietf-rtgwg-net2cloud-problem-statem...@ietf.org; rtgwg@ietf.org Subject: RE: AD review for draft-ietf-rtgwg-net2cloud-problem-statement Jim, The revision to address your comments has been uploaded. Thank you very much. Linda -----Original Message----- From: Jim Guichard <jguichard1...@gmail.com> Sent: Monday, August 19, 2024 10:42 AM To: Linda Dunbar <linda.dun...@futurewei.com> Cc: James Guichard <james.n.guich...@futurewei.com>; draft-ietf-rtgwg-net2cloud-problem-statem...@ietf.org; rtgwg@ietf.org Subject: Re: AD review for draft-ietf-rtgwg-net2cloud-problem-statement Hi Linda, This should be sufficient but please add a requirements language section and post a new version. Jim On Mon, Aug 19, 2024 at 1:36 PM Linda Dunbar <linda.dun...@futurewei.com> wrote: > Jim, > > > > Thank you very much for the additional comments. > > See below for the detailed resolution to your comments. > > > > Please let us know if more actions are needed. > > > > Linda > > > > *From:* James Guichard <james.n.guich...@futurewei.com> > *Sent:* Sunday, August 18, 2024 7:40 AM > *To:* Linda Dunbar <linda.dun...@futurewei.com>; > draft-ietf-rtgwg-net2cloud-problem-statem...@ietf.org > *Cc:* rtgwg@ietf.org > *Subject:* Re: AD review for > draft-ietf-rtgwg-net2cloud-problem-statement > > > > Hi Linda, > > > > A few more comments. > > > > You added the following: > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this > > document are to be interpreted as described in [RFC2119]. > > > > Please use the correct template as per RFC 8174 under a separate > “Requirements Language” section. > > > > [Linda] Changed to the wording suggested by RFC8174. Is it good enough? > Or do you mean adding a separate “Requirement Language Section? > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", > and "OPTIONAL" in this document are to be interpreted as described in > BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all > capitals, as shown here. > > > > > > 196 - When a Cloud DC eBGP session supports a limited number of > > 197 routes from external entities, the on-premises DCs need to > set > > 198 up default routes and filter as many routes as practical > > 199 replacing them with a default in the eBGP advertisement to > > 200 minimize the number of routes to be exchanged with the > Cloud DC > > 201 eBGP peers. > > > > Jim> I do not understand the above paragraph. Is a Cloud DC different > Jim> to > an on-premise DC? Who is advertising default to who? The scenario that > you are trying to convey above is non-obvious, at least to me, so > please clarify. > > [Linda] How about the following statement? > > *“A Cloud DC GW typically has multiple eBGP sessions with various > clients and sets a route limit for each one. Therefore, on-premises > data center gateways with eBGP sessions to the Cloud DC GW should > configure default routes and filter out as many routes as possible, > replacing them with a default route in their eBGP advertisements. This > approach minimizes the number of routes exchanged with the Cloud DC > eBGP peers.”* > > > > > > > > [Linda] The statement is meant to emphasize when a cloud DC GW doesn’t > multi-hop eBGP sessions with their peers, a tunnel should be > established to achieve IP adjacency. > > For example, AWS Transit Gateway does not support traditional > multi-hop eBGP sessions. AWS recommends establishing eBGP sessions > with third-party virtual appliances (like SD-WAN appliances) running > in a VPC to exchange routing information between on-premises network > and multiple VPCs through a central point. > > > > Jim> Okay but in the latest version of the document you do not clarify > Jim> it > or change any text. Reading the above paragraph I still cannot fathom > from the text what you are trying to convey. Your explanation is not > reflected in the text so again please try to clarify what you want the > reader to understand. > > > > 202 - When a Cloud GW receives inbound routes exceeding the maximum > > 203 routes threshold for a peer, the currently common practice > is > > 204 generating out-of-band alerts (e.g., Syslog entries) via the > > 205 management system or terminating the BGP session (with cease > > 206 notification messages [RFC4486] being sent). Although out of > > 207 the scope of this document, more discussion is needed in the > > 208 IETF Inter-Domain Routing (IDR) Working Group for potential > in- > > 209 band or autonomous notification directly to the peers when > the > > 210 inbound routes exceed the maximum routes threshold. > > > > Jim> More explanation is needed here including a reference to section > Jim> 4 of > RFC4486 that describes the procedure for terminating a peering with a > NOTIFICATION message and error code providing a reason e.g. “Maximum > number of prefixes reached”. > > [Linda] Azure doesn’t want BGP session to be terminated when max > number of prefixes reached. Azure wants a method to notify the peers > when the routes received exceeding some threshold. Today’s practice of > using Syslog only informs Azure when max routes exceeded. But there is > no effective way to notify peers to reduce routes. > draft-sas-idr-maxprefix-inbound-05 would be a good solution. But the draft is > expired. > > We are hoping to continue the draft by stating that “more discussion > is needed in the IETF Inter-Domain Routing (IDR) Working Group for > potential in-band or autonomous notification directly to the peers > when the inbound routes exceed the maximum routes threshold.” > > > > Jim> Again, my original comment is not addressed in the latest > Jim> version. At > a minimum, a reference to section 4 of RFC4486 is needed. > > [Linda] Does the following revision address your original comment? > > *When a Cloud GW receives inbound routes exceeding the maximum routes > from a peer, the current practice is to generate out-of-band alerts > (e.g., Syslog entries) via the management system or to terminate the > BGP session (with a cease notification message being sent per Section > 4 of [RFC4486]) _______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
