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
