Just starting out here having been hired as the new peering coordinator for NetThrones. What is the critical information to include peering requests? Can’t this all be automated or at least put into a simple standard peering template?
-- Samwell Tarly
As a matter of fact, a small crew of us from the peering community are working now on a proposed Peering Session Management Protocol (PSMP) to standardize the format of peering requests. We will be looking for some folks from the community to talk through the spec, and then use the spec to communicate peering requests.
The idea is to deliver the peering requests the way they are done today, via simple e-mail. Nothing different here. But the spec does provide a naming convention for the relevant fields, and specifies which ones are mandatory (ASN, contact info, locations and session info, for example) and which ones are not mandatory. The text is human readable so peering coordinators will start to see another, perhaps more formal, description of the peering session to be set up.
The target peer will edit/update their peering details in the peering request and return it with an “accept” indication, and both parties can attach the completed record into their trouble ticket or network provisioning system for turn up preparation.
Of course the neat part is that, being formatted in YAML, the requests are both human readable and machine parseable. You will see some open source software coming out to prepare, process, and respond to peering requests as automatically as you would like. Several companies have already done exactly this, but are using natural language processing systems to detect and extract relevant fields. If the community can come to consensus on a spec, the peering process can be automated, reducing the chances of human error in peering session establishment.
During the lifecycle of a peering session, sessions at new locations will be added, and this will generate a new peering request and response. Likewise, dropped peering sessions and locations can be handled with notifications. These simple cases are handled in version 1 of the spec, and over time, other complexities can be addressed. Right now, the intent is to standardize on the basic information required for the most common peering use cases.
If you are interested in participating as a PSMP beta tester, which means letting us talk you through the spec to getting your feedback on it, send me a note (DrPeering@DrPeering.net). The plan is to share and discuss the document with interested folks at peering events over the next few months.
I implemented the spec in software, coded in Apple’s new development language called Swift. I literally cut and pasted the spec into the IDE, and converted the descriptions into comments, and the attributes into objects and properties. Swift is a modern object-oriented message passing language, so very well suited for creating a model of the peers and the messages they pass between themselves.
One thing I learned is that there are many ways to structure the messages. The trick is to find a format that is intuitive for humans that manually process each peering request. We don’t want to mess up the current systems, but we do want to create a seamless path for those that can see migrating from the manual peering system of today towards a more automated approach to capturing the relevant peering details.
I hope this helps -