-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Jenny,
it's great to see this document! Under section "4.2.3. REQUEST" - AS-SET is not included, but I note that later it specified that it will be pulled from public sources. If I have multiple AS-SETs how will you know which one to use? I think it could be an optional field in the initial request. Based on the structure of the request, I assume Local IP and Peer IP contain a single value/IP, so (although not explained in the draft!) I assume I have to submit two requests in order to bring up an IPv4 and an IPv6 peering session? With IPv4 via IPv6 next-hop only increasing in popularity, I think it might be wise to add something like an address family field; Local IP: X Peer IP: Y Family v4 / v6 If family is v4 and the IPs are v4, it's v4 via v4 next-hop. If family is v6 and the IPs are v6, it's v6 via v6 next-hop. If family is v4 and the IPs are v6, it's v4 via v6 next-hop. If family is v6 and the IPs are v4, it's v6 via v4 next-hop. There may be a better way to encode that info. This is just meant as an example. Regarding the location field of the request: """ Location (Commonly agreed identifier of the BGP speaker, e.g. PeeringDB IX lan ID) """ PeeringDB seems like the obvious choice but it might not be the only choice. It might be wise here to add a method of encoding the location DB. So you've got "Location is X" and Location DB is Y". Where Y means "look in peering DB" and X is an ID in peering DB. When it comes to the (still in draft) section of the document about private peering, many facilities aren't in peeringDB, so specifying an alternative location DB could pay off when you come to private peerings. Regarding section "6.3.3. Private Peering (DRAFT)". One party will provide the IP addresses, so this is an additional concern not listed (I know this section is a WIP). We handle this internally buy triggering a peering request with no IPs in the payload, this tells our orchestration system we need to allocate the IPs. If the peer is providing the IPs, we put them in the payload, and this tells our orchestration system to use those IPs provided by the peer (we can also specify our own IPs in the payload, to ensure a specific subnet is reused, such as in the case of moving a PNI between routers, we can delete it and re-add it with the same IPs). So some method like allowing the IP field to be blank is required to signal that the other party needs to provide the IP addresses (there might be a better way to encode this, this is just an example). The document doesn't statement anything about idempotency (or maybe I missed it?). Is it assumed the API will be idempotent? Not sure if my ramblings were helpful. Great work on the document so far, this will make a big difference. Cheers, James. On Wednesday, July 9th, 2025 at 17:20, Jenny Ramseyer <[email protected]> wrote: > Hello GROW WG, > > Based on the feedback we received at the previous IETF meetings, we (Arturo, > Carlos, Matt, Q, Tom, and I) have posted a new version of the Peering API > draft: https://datatracker.ietf.org/doc/draft-ietf-grow-peering-api/01/ > > Of note: We have changed the authentication method of the API to support both > standard OAuth, and RPKI Attested OAuth. The details of RPKI Attested OAuth > have been split into a new draft: > https://datatracker.ietf.org/doc/html/draft-blahaj-grow-rpki-oauth > > Arturo will present Peering API at the next grow and opsarea meetings at > IETF123. > > Thank you all for the feedback on our draft. > > Jenny -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsG5BAEBCgBtBYJodiDLCZCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0 aW9ucy5vcGVucGdwanMub3JnhRTyQ269gnSGt51UIfTL4g5MtvCTQf/DeG3l eo/5ffEWIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAAe60QALFXr2u6gVpV2bqv VklZ07+XLDdAowaK8a8LWmyGQdA7H7evcUik1zkWsvsHfp1Y1rhWMS5JKveB d7pK131eGihwgYBChVyhPsNwxK4a4Tx3U4TXOUUTahoBA3zo68XZs//PCYlu vVzRsPZ74EOL9ZMoM/LCFlkCHR6qmjLXqtGJEIWic8An6KOboqeYgQh9mCPG CWFzQM9jjNjQA+tQzbmkJcANrH8u4ayBLD4CEYnAdS3E3S+FdC7pNcYIBK7x C7Ocyoju1ep2Z2Qp7TiKt28tfCNEAhIMhpR3VinSXfj78jMZ0ml9xdwKnyvI vsve4J7Ulzs+Yr4VS4K7VnWyKJKLgoIHsEdIKu9mGDnKnvT0rkbolDrYO8bP 9OMvwKwcPZYy1w9oKPbdb1mUN+y6YLyPYkiX3cIMdf9DQgkwYoR0oL2OXLed /lmwgjVW42bKRb8OgQSsDvojmEcWLEPHLze2V57w+IkahtF3M3amNQhtDSqm rStDKZXsT6e2bfk2XdOsPm1M2flCA6SiGWq9hGmkPxMh2m52nyoWl70KZp03 cBewlWROgmlyV1FSHrWrDIGYBazA0Oj89j0fk3ukY/FxEQQ7VDs1RBX246W0 SI6x9vr8xoR60hONyIgKqp7QSyEKFXiW3JnhxJDWsXDyivG8NRkgs0e/QgQY pGICIMsW =+8k3 -----END PGP SIGNATURE-----
publickey - [email protected] - 0x3E936359.asc
Description: application/pgp-keys
publickey - [email protected] - 0x3E936359.asc.sig
Description: PGP signature
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
