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....@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 > https://www.ietf.org/mailman/listinfo/grow >
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
