Hi Jenny, all, while I understand the theoretical reasoning behind your answer, I would like to discuss a few practical issues to clarify the way forward for route server support before adoption.
(1) Integrating route server support requires minimal effort and the changes are not specific to route servers Honestly, I was quite amused by the huge number of changes and added complexity in the current revision of the draft [1], while small changes for route server support are deemed out of scope :-) Especially since the additional fields can be copied from the IX-API route server endpoint definition [2] and are already agreed upon by several relevant IXPs, so extensive discussions are unlikely. The only changes I see are for the session descriptor in 5.1: * Extend peer_type from [public, private] to [public, private, route_server] (if private means PNI, not clear from draft) * Add an optional Enum [passive, active] mode, if set to passive, the requestor must open the connection, if missing defaults to active * Add an optional Enum [public, collector] mode, if set to collector, the peer must not redistribute routes, if missing defaults to public * Add an optional String as_set_v4/v6, format is AS-SET@IRR; field is required if peer_type==route_server * Add an optional int max_prefix_v4/v6, session will be dropped if max_prefix is violated, if missing no limit That's all. Notably, these fields are not specific to route servers; they are also useful in other contexts (e.g., transit across peering LANs). If you do not want to file these additions under route server support, you can simply file them under general BGP support, which is within the scope of the proposal. (2) How a separate draft proposal for RSes would likely play out in practice Let's assume we submit our own draft proposal. Doing so would require you to integrate exchangeable or extendable definitions of session descriptors in your draft (which is a reasonable change if you want to support follow-up work). At this point, the effort is already higher than adding the fields mentioned above. But let's assume we ignore that: it would result in a minimal draft proposal for an RS extension, half of which would probably be general preamble. There is nothing wrong with small and concise proposals, but I think at some point in the process, the question will arise whether the two proposals should be merged to avoid wasting valuable resources for reviews and discussions. (3) Having private peering in a separate draft is a better cut than RSes, as private peering is a much larger topic Except the description of the session, everything in this draft is in place for provisioning route server sessions. As opposed to that, private peering is a much larger topic with a lot more unknowns that are hard to solve: involving data centers, establishing fiber connections, LOAs, cost, common identifiers to name just a few. That being said, the IETF is not political and shouldn't be, but integrating route servers would certainly help with the acceptance of this draft in the IXP community. My offer to assist with an integration into the draft and the OpenAPI definition still stands. Best regards, Matthias [1] https://author-tools.ietf.org/iddiff?url1=draft-ramseyer-grow-peering-api-04&url2=draft-ramseyer-grow-peering-api-05&difftype=--html <https://author-tools.ietf.org/iddiff?url1=draft-ramseyer-grow-peering-api-04&url2=draft-ramseyer-grow-peering-api-05&difftype=--html> [2] https://docs.ix-api.net/latest/#operation/network_feature_configs_create <https://docs.ix-api.net/latest/#operation/network_feature_configs_create> -- Dr.-Ing. Matthias Wichtlhuber Team Lead Research and Development ------------------------------ DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt (Germany) phone: +49 69 1730902 141 mobile: +49 171 3836036 fax: +49 69 4056 2716 e-mail: matthias.wichtlhu...@de-cix.net <mailto:matthias.wichtlhu...@de-cix.net> <mailto:matthias.wichtlhu...@de-cix.net <mailto:matthias.wichtlhu...@de-cix.net>> web: www.de-cix.net <http://www.de-cix.net/> <http://www.de-cix.net/>> ------------------------------ DE-CIX Management GmbH Executive Directors: Ivaylo Ivanov and Sebastian Seifert Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne On 26.06.24, 16:39, "Jenny Ramseyer" <ramseyer=40meta....@dmarc.ietf.org <mailto:40meta....@dmarc.ietf.org> <mailto:40meta....@dmarc.ietf.org <mailto:40meta....@dmarc.ietf.org>>> wrote: 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 <matthias.wichtlhuber=40de-cix....@dmarc.ietf.org <mailto:40de-cix....@dmarc.ietf.org> <mailto:40de-cix....@dmarc.ietf.org <mailto:40de-cix....@dmarc.ietf.org>>> Date: Wednesday, June 26, 2024 at 4:01 AM To: Stavros Konstantaras <stavros.konstanta...@ams-ix.net <mailto:stavros.konstanta...@ams-ix.net> <mailto:stavros.konstanta...@ams-ix.net <mailto:stavros.konstanta...@ams-ix.net>>>, grow@ietf.org <mailto:grow@ietf.org> <mailto:grow@ietf.org <mailto:grow@ietf.org>> <grow@ietf.org <mailto:grow@ietf.org> <mailto:grow@ietf.org <mailto:grow@ietf.org>>> 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" <stavros.konstanta...@ams-ix.net <mailto:stavros.konstanta...@ams-ix.net> <mailto:stavros.konstanta...@ams-ix.net <mailto:stavros.konstanta...@ams-ix.net>> <mailto:stavros.konstanta...@ams-ix.net <mailto:stavros.konstanta...@ams-ix.net> <mailto:stavros.konstanta...@ams-ix.net <mailto:stavros.konstanta...@ams-ix.net>> <mailto:stavros.konstanta...@ams-ix.net <mailto:stavros.konstanta...@ams-ix.net> <mailto:stavros.konstanta...@ams-ix.net <mailto:stavros.konstanta...@ams-ix.net>>>>> 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 <stavros.konstanta...@ams-ix.net <mailto:stavros.konstanta...@ams-ix.net> <mailto:stavros.konstanta...@ams-ix.net <mailto:stavros.konstanta...@ams-ix.net>> <mailto:stavros.konstanta...@ams-ix.net <mailto:stavros.konstanta...@ams-ix.net> <mailto:stavros.konstanta...@ams-ix.net <mailto:stavros.konstanta...@ams-ix.net>> <mailto:stavros.konstanta...@ams-ix.net <mailto:stavros.konstanta...@ams-ix.net> <mailto:stavros.konstanta...@ams-ix.net <mailto:stavros.konstanta...@ams-ix.net>>>>> Date: Wednesday, 12 June 2024 at 22:37 To: Job Snijders <job=40fastly....@dmarc.ietf.org <mailto:40fastly....@dmarc.ietf.org> <mailto:40fastly....@dmarc.ietf.org <mailto:40fastly....@dmarc.ietf.org>> <mailto:40fastly....@dmarc.ietf.org <mailto:40fastly....@dmarc.ietf.org> <mailto:40fastly....@dmarc.ietf.org <mailto:40fastly....@dmarc.ietf.org>> <mailto:40fastly....@dmarc.ietf.org <mailto:40fastly....@dmarc.ietf.org> <mailto:40fastly....@dmarc.ietf.org <mailto:40fastly....@dmarc.ietf.org>>>>>, grow@ietf.org <mailto:grow@ietf.org> <mailto:grow@ietf.org <mailto:grow@ietf.org>> <mailto:grow@ietf.org <mailto:grow@ietf.org> <mailto:grow@ietf.org <mailto:grow@ietf.org>> <mailto:grow@ietf.org <mailto:grow@ietf.org> <mailto:grow@ietf.org <mailto:grow@ietf.org>>>> <grow@ietf.org <mailto:grow@ietf.org> <mailto:grow@ietf.org <mailto:grow@ietf.org>> <mailto:grow@ietf.org <mailto:grow@ietf.org> <mailto:grow@ietf.org <mailto:grow@ietf.org>> <mailto:grow@ietf.org <mailto:grow@ietf.org> <mailto:grow@ietf.org <mailto:grow@ietf.org>>>>> 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 <job=40fastly....@dmarc.ietf.org <mailto:40fastly....@dmarc.ietf.org> <mailto:40fastly....@dmarc.ietf.org <mailto:40fastly....@dmarc.ietf.org>> <mailto:40fastly....@dmarc.ietf.org <mailto:40fastly....@dmarc.ietf.org> <mailto:40fastly....@dmarc.ietf.org <mailto:40fastly....@dmarc.ietf.org>> <mailto:40fastly....@dmarc.ietf.org <mailto:40fastly....@dmarc.ietf.org> <mailto:40fastly....@dmarc.ietf.org <mailto:40fastly....@dmarc.ietf.org>>>>> Date: Friday, 7 June 2024 at 20:13 To: grow@ietf.org <mailto:grow@ietf.org> <mailto:grow@ietf.org <mailto:grow@ietf.org>> <mailto:grow@ietf.org <mailto:grow@ietf.org> <mailto:grow@ietf.org <mailto:grow@ietf.org>> <mailto:grow@ietf.org <mailto:grow@ietf.org> <mailto:grow@ietf.org <mailto:grow@ietf.org>>>> <grow@ietf.org <mailto:grow@ietf.org> <mailto:grow@ietf.org <mailto:grow@ietf.org>> <mailto:grow@ietf.org <mailto:grow@ietf.org> <mailto:grow@ietf.org <mailto:grow@ietf.org>> <mailto:grow@ietf.org <mailto:grow@ietf.org> <mailto:grow@ietf.org <mailto:grow@ietf.org>>>>> 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/>> <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/&gt;>> <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/>> <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/&gt;&gt;>> <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/>> <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/&gt;&gt;>> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&gt;> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&gt;> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&amp;gt;>> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&gt;>> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&amp;gt;>>> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&amp;gt;>>> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&amp;amp;gt;&gt;&gt;>> 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 -- grow@ietf.org <mailto:grow@ietf.org> <mailto:grow@ietf.org <mailto:grow@ietf.org>> <mailto:grow@ietf.org <mailto:grow@ietf.org> <mailto:grow@ietf.org <mailto:grow@ietf.org>> <mailto:grow@ietf.org <mailto:grow@ietf.org> <mailto:grow@ietf.org <mailto:grow@ietf.org>>>> To unsubscribe send an email to grow-le...@ietf.org <mailto:grow-le...@ietf.org> <mailto:grow-le...@ietf.org <mailto:grow-le...@ietf.org>> <mailto:grow-le...@ietf.org <mailto:grow-le...@ietf.org> <mailto:grow-le...@ietf.org <mailto:grow-le...@ietf.org>> <mailto:grow-le...@ietf.org <mailto:grow-le...@ietf.org> <mailto:grow-le...@ietf.org <mailto:grow-le...@ietf.org>>>>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
