Hi Tom, all, Thanks for sharing the notes.
This is really interesting work. As I already shared with the authors of the API draft, draft-ietf-opsawg-teas-attachment-circuit/<https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/> can be leveraged here. You may refer to https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-teas-attachment-circuit-08#name-connecting-a-virtualized-en for an interconnection API flow example. Cheers, Med De : GROW <[email protected]> De la part de Tom Strickx Envoyé : jeudi 21 mars 2024 16:41 À : [email protected] Objet : [GROW] Peering API side meeting 2024-03-21 minutes 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 ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
