[GROW]Peering API new version posted: draft-ramseyer-grow-peering-api-05
Hello GROW, Thank you again for your feedback on the Peering API Internet Draft at IETF119. Based on the feedback we received at the GROW meeting and the side meeting, we (Arturo, Carlos, Matt, Tom, and I) have posted a new version of the draft to the datatracker: https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/05/ It has been a few months since the meeting, so I have included the notes from the meeting below for context. I believe we have addressed all the points discussed, so please take a look at the draft and let us know if you would be willing to call for adoption on the draft. Of note: we would particularly like help from GROW on the sections pertaining to RPKI-Signed-Checklists. We have added some initial description of how RSC would work on the API, but would welcome any feedback or technical suggestions from the list. Thank you, Jenny Ramseyer From: GROW on behalf of Job Snijders Date: Thursday, March 21, 2024 at 2:48 AM To: Tom Strickx Cc: grow@ietf.org Subject: Re: [GROW] Peering API side meeting 2024-03-21 minutes Thanks Tom! Looks like it was a good meeting. I’ll wait for a next revision before issuing the call for the working group adoption. Kind regards, Job Co-chair GROW On Thu, 21 Mar 2024 at 16: 41, Tom Strickx ZjQcmQRYFpfptBannerStart This Message Is From an External Sender ZjQcmQRYFpfptBannerEnd Thanks Tom! Looks like it was a good meeting. I’ll wait for a next revision before issuing the call for the working group adoption. Kind regards, Job Co-chair GROW On Thu, 21 Mar 2024 at 16:41, Tom Strickx mailto:40cloudflare@dmarc.ietf.org>> wrote: Dear grow members, please find the minutes of the Peering API side meeting below: Attendees: Aussie Broadband, Amazon, Workonline, Huawei, APNIC, Telstra, Meta, Cloudflare (12 attendees) 1. Brief walkthrough of PeeringAPI. 2. Open questions: PNIs: who issues LOAs, who orders XCs, exchanging preferences (redundant links, who unfilters first, ...). PeeringDB is not good enough. RPKI signed checklists could be worth it. Provisioning Finite State Machine. 3. Work with Peering Manager to implement the API to advance adoption. 4. Aussie agrees this is a good idea. Great for an eyeball network. Reduces complexity, single pane of glass. 5. 2 Types of business logic: peering logic and business logic that goes in the provisioning. The second one is what needs modelling. 6. IXP Manager integration? 7. Are there any additional security considerations? 8. Ben Maddison explains RSC. Signatures over arbitrary blobs of data. Rough workflow: each party issues a challenge. Sign the challenge. Provide signed blob back over the API (inband). PeeringDB is good enough for now, but baking it into the protocol as a first-class citizen might be a mistake. Make RSC a first-class citizen, and machine-to-machine OATH as a fallback. Similar to the key negotiation within SSH: Offer list of IdPs, receive list of IdPs. Ordering is not important, as long as you pick an IdP that is trusted. No need to use the same IdP in both directions. 9. Don't roundtable the FSM. Might need a workflow negotiation system. Might be good to communicate operational state. Get a feedback loop going. 2 classes of state transition: 1 that requires coordination, 1 that doesn't. To what extent do we expose "hygiene" of turnup testing. Protocol coordination will need to happen for ordering-of-actions. Might need a deadlock state. What are the preferences we should care about? Provide a human address for "escalation" in case of deadlock. Tie-break decision algorithms? Make the errors more expressive, but structured text. ENUM for the most frequent ones, but allow extendability. Look to YANG? Allow for resumption through the FSM once deadlocks have been resolved. If data-leaf is not provided, block state transition, and progress once that's there. Coordinated data-collection exercise. Route-server sessions? Next steps: We'll work on adding a section on the RSC challenge-response proposed authorization and authentication workflow. Work will also start on a minimal provisioning FSM. We want to thank all the contributors of today's meeting, and look forward to working with the Working Group in advancing this draft. -- Tom Strickx Principal Network Engineer AS13335 - Cloudflare ___ GROW mailing list GROW@ietf.org<mailto:GROW@ietf.org> https://www.ietf.org/mailman/listinfo/grow<https://www.ietf.org/mailman/listinfo/grow> ___ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
Re: [GROW] Peering API: Internet Draft submission
Hi all, Thank you all for the feedback on the draft! After some discussion, we have published a new version of the draft: https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/04/. I, along with some of my collaborators (cc’d), will be at the IETF 119 meeting in Brisbane this week. As proposed below, I believe this may fall under the GROW charter, and so, we will present at the group meeting on Wednesday.I look forward to the discussion there. We have also scheduled a side meeting on Thursday at 14:00-15:00 to discuss further—please join us if you are interested! It will be in Room M9, and I believe there will be a web link as well. Please let us know if you have any comments! I look forward to meeting some of you in Brisbane. Jenny From: GROW on behalf of Jenny Ramseyer Date: Friday, January 19, 2024 at 4:20 AM To: grow@ietf.org Cc: Matt Joras Subject: [GROW] Peering API: Internet Draft submission Hello GROW, 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/ ZjQcmQRYFpfptBannerStart This Message Is From an External Sender ZjQcmQRYFpfptBannerEnd Hello GROW, 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/<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<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<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. Thank you, Jenny Ramseyer ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Peering API: Internet Draft submission
Thank you, I have joined the list now. I look forward to discussing with you all—please do let me know if anyone has any feedback or questions on the draft. I’ll be at the IETF 119 meeting, and hope to meet some of you there. Thanks! Jenny From: GROW on behalf of Christopher Morrow Date: Thursday, January 18, 2024 at 11:34 PM To: Jenny Ramseyer Cc: grow@ietf.org , Matt Joras Subject: Re: [GROW] Peering API: Internet Draft submission !---| This Message Is From an Untrusted Sender You have not previously corresponded with this sender. |---! Jeremy, you'll want to take a moment to join the mailing-list... else someone will have to keep accepting your mails in the mailman interface :) (delaying and unnecessarily gatekeeping your part of the conversation) thanks! -chris (also, thanks for the submission!) On Thu, Jan 18, 2024 at 11:32 PM Jenny Ramseyer wrote: > > 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/<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<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<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. > > > > Thank you, > > > > Jenny Ramseyer > > > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow<https://www.ietf.org/mailman/listinfo/grow> ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow<https://www.ietf.org/mailman/listinfo/grow> ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Peering API: Internet Draft submission
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. Thank you, Jenny Ramseyer ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Peering API: Internet Draft submission
Hello GROW, 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. Thank you, Jenny Ramseyer ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
