Hi Matthias, Stavros, GROW, Thanks for your comments. As we discussed offline, while this API could be extended to be used for route servers, we are keeping this draft focused to public peering requests.
As this is the first draft for the network peering API, we decided to keep the first draft scoped only to the security considerations and peer-to-peer public peering configuration. Private peering and route server peering are both reasonable extensions to consider, but would expand the complexity of the draft. As a result, we decided to leave them out for the original proposal. We hope to add additional features in a subsequent proposal (private peering being the next one of interest), and would encourage you to submit a separate proposal for route server support. Hopefully, by building off of the same standard, we will be able to extend the features of the API, while still keeping each individual proposal well-scoped. Thank you again for the feedback on the draft, and we look forward to collaborating on further versions with everyone. Jenny From: Matthias Wichtlhuber <[email protected]> Date: Wednesday, June 26, 2024 at 4:01 AM To: Stavros Konstantaras <[email protected]>, [email protected] <[email protected]> Subject: [GROW]Re: Working Group Call for Adoption for draft-ramseyer-grow-peering-api (start 07/Jun/2024 end 21/Jun/2024) Hi Stavros, thanks for pointing out the lack of route server support. I had some private conversations with the authors on this. Maybe they want to comment on this specific issue themselves? I agree the draft is only missing a few additional fields in the session description that can be added as optional fields (mainly the ones mentioned by Stavros + AS-SET and preferred IRR). Regards, Matthias On 21.06.24, 22:18, "Stavros Konstantaras" <[email protected] <mailto:[email protected]>> wrote: Hi all, This has been done already but for the sake of the discussion, I thought it might be useful to post some general comments over here as well. * It seems the standard does not include the Route Servers option and authors noted it down in section 10. That’s very unfortunate and I am really sorry to read this, we would love to learn more why this happens and what are the complications. However, could be possible to make the standard a bit more ready for such a scenario so in the future we would not need to go into an extensive restructuring? * In section 4.4 perhaps the following fields could be included as well in the struct??? * TTL (optional) * Address family (mandatory) * BGP Role from RFC9234 (optional) * I would like to echo Rayhaan’s comment that publishing the URL in WHOIS is a neat way to distribute the API endpoints. * I would like to echo Matthias’ comment that section 9 regarding security considerations needs some extra clarity as it is a bit hard to digest in the current status. Thank you in advance for your work and looking forward for your feedback. Kind Regards Stavros From: Stavros Konstantaras <[email protected] <mailto:[email protected]>> Date: Wednesday, 12 June 2024 at 22:37 To: Job Snijders <[email protected] <mailto:[email protected]>>, [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>> Subject: [GROW]Re: Working Group Call for Adoption for draft-ramseyer-grow-peering-api (start 07/Jun/2024 end 21/Jun/2024) Hi Job and GROW-WG I like the idea of having a Peering API that sets the path for more automation in service-level. Is a good idea in general. However, I have some second thoughts that make me a bit hesitant and for the time being, I can only echo Mohamed’s and Matthias’ concerns. I will contact the authors and provide them feedback in a separate e-mail thread to see what can be addressed. Kind Regards Stavros From: Job Snijders <[email protected] <mailto:[email protected]>> Date: Friday, 7 June 2024 at 20:13 To: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>> Subject: [GROW]Working Group Call for Adoption for draft-ramseyer-grow-peering-api (start 07/Jun/2024 end 21/Jun/2024) Dear GROW, The author of draft-ramseyer-grow-peering-api asked whether the GROW working group could consider adoption of their internet-draft. This message is a request to the group for feedback on whether this internet-draft should be adopted. Title: Peering API Abstract: We propose an API standard for BGP Peering, also known as interdomain interconnection through global Internet Routing. This API offers a standard way to request public (settlement-free) peering, verify the status of a request or BGP session, and list potential connection locations. The API is backed by PeeringDB OIDC, the industry standard for peering authentication. We also propose future work to cover private peering, and alternative authentication methods. The Internet-Draft can be found here: https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/ <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>> Please share with the mailing list if you would like this work to be adopted by GROW, are willing to review and/or otherwise contribute to this draft! WG Adoption call ends June 21st, 2024. Kind regards, Job / Chris GROW co-chairs _______________________________________________ GROW mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]>
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
