Roman Danyliw has entered the following ballot position for draft-ietf-rtgwg-net2cloud-problem-statement-41: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Paul Kyzivat for the GENART review. ** Section 3. This section identifies some high-level problems that the IETF could address, especially within the Routing area. Other Cloud DC problems (e.g., managing cloud spending) are out of the scope of this document. The scope of what collection of problems will be described in this document is made less clear by this paragraph. What makes these IETF problem to solve? ** Section 3 Here are the recommended mitigation practices: - If a Cloud Gateway (GW), a BGP speaker, receives from its BGP peer a capability that it does not itself support or recognize, it MUST ignore that capability, and the BGP session MUST NOT be terminated per [RFC5492]. - When receiving a BGP UPDATE with a malformed attribute, the revised BGP error handling procedure in [RFC7606] should be followed instead of session resetting. Does this amount to saying, “just follow RFC7606”? I’m having trouble understanding how this guidance differs from existing PS documents. ** Section 3. Speculative text about IETF WG. -- Section 3.1 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. -- Section 3.4 The IETF CATS (Computing-Aware Traffic Steering) working group is examining general aspects of this space, and may come up with protocol recommendations for this information exchange. Is this text needed? Why speculate on the activity of other WGs? ** Section 3.3. -- Which subset of the problem described here (i.e., bulleted list after “Here are some problems associated with DNS-based solutions”) are addressed by the mitigations described later in this section. -- What protocol behavior is envisioned to address a “misbehaving client”? ** Section 3.4 [METADATA-PATH] describes a mechanism to get around those problem. If [METADATA-PATH] is a solution. Why is this section describing a solved problem? Is this section needed? ** Section 3.7 One of the concerns of enterprises using Cloud services is the lack of awareness of the locations of their services hosted in the Cloud, as Cloud operators can move the service instances from one place to another. While the geographic locations are usually exposed to the enterprises, such as Availability Zones or Regions, the topological location is usually hidden. Is this a technical problem or a contractual problem? Could the problem statement be refined? The customer is buying a PaaS or some other kind of *aaS, but they don’t understand where in the service provider’s network it is being run beyond high level descriptions like Zone or Region? How would the customer get that information? What is topological information this context? ** Section 3.7 For enterprises that instantiate virtual routers in Cloud DCs, metadata can be attached (e.g., GENEVE [RFC8926] header or IPv6 optional header) to indicate additional properties, including useful information about the sites where they are instantiated. What remains unsolved after using IPv6 optional headers (is there a specific mechanism) or GENEVE? ** Section 4 and 5. What problem are these sections describing? In particular, Section 4 seems to be referencing vendor specific procedures. Will these statements age well? _______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
