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 <[email protected]> on behalf of Job Snijders <[email protected]> Date: Thursday, March 21, 2024 at 2:48 AM To: Tom Strickx <[email protected]> Cc: [email protected] <[email protected]> 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 <tstrickx=40cloudflare. com@ dmarc. ietf. org> 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/grow<https://www.ietf.org/mailman/listinfo/grow>
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
