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 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 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 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 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]). > However, a more operation-friendly approach would be for peers to reduce > the number of routes they are advertising. Therefore, it is worth > considering adding a "route threshold crossing" alert mechanism to request > peers to take action to reduce their advertised routes, rather than their > BGP sessions being terminated by Cloud GW. Although this is beyond the > scope of this document, further discussion in the IETF Inter-Domain Routing > (IDR) Working Group is needed. This could lead to the addition of new > subcodes in RFC4486 Section 3 and corresponding descriptions in RFC4486 > Section 4 to facilitate this more efficient approach.* > > > > Thanks! > > > > Jim > > > > > > > _______________________________________________ > rtgwg mailing list -- rtgwg@ietf.org > To unsubscribe send an email to rtgwg-le...@ietf.org >
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
