From: GROW <[email protected]> on behalf of Jenny Ramseyer <[email protected]> Sent: 17 January 2024 21:08
Hello GROW chairs, I’m Jenny Ramseyer, from Meta. I have just submitted an Internet Draft, which I would like to share for your review. I believe it falls under the GROW working group’s charter. Here is the draft: https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/ In this draft, I outline a proposed standard for programmatically configuring BGP peering connections through a machine-to-machine API. With this work, I and my collaborators hope to standardize and simplify peering automation, and encourage fast, reliable, and cost-effective interconnection for networks. This work started as an extension of an earlier NANOG85 presentation: https://youtu.be/Cko5-lWyN60?si=4w_ZicpGIgGoyaTR. Out of that presentation, we established a discussion group, and presented an early proposal at NANOG88: https://youtu.be/kMxsoplROYs?si=nKvkkL9aXa8pjAGw This draft is built from the discussions through that group, and is joint work with my collaborators at AWS, Cloudflare, Google, and FullCtl. As we are proposing a standard way to automate BGP interconnections with the goal of simplifying and encouraging peering, I am hoping that it would fall under your charter’s second goal: “Document and suggest operational solutions to problematic aspects of the currently deployed routing system.” I would like to request a talking slot at the upcoming GROW meeting at IETF 119 to discuss the draft. Please let me know if you think this draft might meet your charter, and if it would be possible to discuss at the next GROW meeting. <tp> Try again! I know what I am trying to say but am struggling to find the words. Jenny This is about style, the IETF's. Authors are expected to guide the readers as to what they need to know in order to understand an I-D or an RFC and this is indicated with Normative References at the end of the document. In fact, with a new I-D. I often look there first to see if I should expect to understand a document - here there are none. At a quick glance I would expect to see references to documents on BGP4, RPKI, Restful, MD5, PeeringDB and the like. That tells we whether or not we are on the same page. Most references are or should be to IETF I-D or RFC because most is building on earlier work. If they are from another SDO, then they should not be behind a paywall. Further, they should be ASCII documents. github does not count and formats such as .pdf or .docx I find an obstacle. Yes github is used, but for ephemeral data such as outstanding issues, potential text updates prior to publishing a new version of an I-D and the like. If a datatype specification or a flow diagram is a necessary part of the Peering API then it needs to be in the I-D or in a stable reference therefrom (ie not github and not behind a paywall) Likewise the place for the latest I-D should always be the IETF datatracker, not github Finally, the IETF has invented a number of data modelling constructs, such as YANG; TLS invented its own many years ago and it is not the only one. Do we need another or is there prior art that would do? HTH Tom Petch Thank you, Jenny Ramseyer _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
