This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[routing-wg] new RPSL import-via/export-via attributes in aut-num Class
- Previous message (by thread): [routing-wg] Fwd: [address-policy-wg] Draft proposal: Guidance Requested: Reassigning Referenced ASNs
- Next message (by thread): [routing-wg] [training] RIPE NCC Webinars - new dates
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Job Snijders
job.snijders at atrato.com
Wed Aug 14 16:28:34 CEST 2013
Dear Routing working group, As some of you might know I've been working on extending the RPSL syntax to make life easier for certain scenario's, such as operating a Route Server. Below is the message I've posted in db-wg at ripe.net, and I suggest we discuss this in the db-wg@ to keep the conversation central. - Job ------------------------------------------------------------ The purpose of the new attributes and the patch is to make life easier for Route Server operators whom have to deal with participants who have been assigned a 32 bit ASN. There currently is no way to relay information between non-adjacent ASNs, and 32 bit ASNs do not fit into standard BGP communities when coupled with an action code. Often Route server operators overload BGP communities to assess which participant should receive what prefixes, the "via" feature addresses exactly that concern. I have submitted the following draft to the IETF: http://tools.ietf.org/html/draft-snijders-rpsl-via And I have submitted a patch for the RIPE whois server to support the feature. https://github.com/job/whois The extension should be backward compatible with minimal impact on existing tools and processes, following Section 10.2 of RFC2622. RPSL parsers which do not understand the new attributes are expected to just ignore it. I am looking for feedback from this community, and especially the community's blessing to allow RIPE NCC to adopt the patch. Kind regards, Job -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: </ripe/mail/archives/routing-wg/attachments/20130814/b18fda56/attachment.sig>
- Previous message (by thread): [routing-wg] Fwd: [address-policy-wg] Draft proposal: Guidance Requested: Reassigning Referenced ASNs
- Next message (by thread): [routing-wg] [training] RIPE NCC Webinars - new dates
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]