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] https://www.ietf.org/mailman/listinfo/grow
