Need for "import-via:" and "export-via:" attributes in AUT-NUM object
Dear colleagues, During the RIPE 67 Meeting in Athens last week, there was some discussion about the introduction of new "via" attributes to the AUT-NUM object. The reasoning behind these attributes is explained in this draft RFC: http://tools.ietf.org/html/draft-snijders-rpsl-via-02 Although the proposal had received some support when discussed recently on the Database Working Group mailing list, there was some discussion during the RIPE 67 Routing Working Group session that the community field can be used to achieve the same result as these proposed "via" attributes. However, some people have commented that the community field cannot be used for this purpose with 32-bit AS Numbers. As a result, the RIPE NCC was asked to bring the issue back to this mailing list for further discussion. We would appreciate any feedback, whether positive or negative, about the introduction of these new attributes. Regards, Denis Walker Business Analyst RIPE NCC Database Team
On Thu, Oct 24, 2013 at 03:05:21PM +0200, Denis Walker wrote:
Although the proposal had received some support when discussed recently on the Database Working Group mailing list, there was some discussion during the RIPE 67 Routing Working Group session that the community field can be used to achieve the same result as these proposed "via" attributes.
IMHO, overloading the BGP community field is not the appropiate place for such inter-domain policy publication. Not only is the BGP community field only 32 bit (thus not allowing for targetting 32 bit ASNs with an action) - it will never provide a uniform interface for users as each AS interprets and treats communities in their own way.
However, some people have commented that the community field cannot be used for this purpose with 32-bit AS Numbers. As a result, the RIPE NCC was asked to bring the issue back to this mailing list for further discussion.
Exactly. Also, I feel that we should be careful in this thread not to venture into a zealotic discussion what the best approach is (BGP Communities versus RPSL), but rather discuss if RPSL-via is valid and workable, and if yes allow people to use it. Kind regards, Job
On Thu, 24 Oct 2013 15:05:21 +0200 Denis Walker <denis@ripe.net> wrote:
Although the proposal had received some support when discussed recently on the Database Working Group mailing list, there was some discussion during the RIPE 67 Routing Working Group session that the community field can be used to achieve the same result as these proposed "via" attributes. However, some people have commented that the community field cannot be used for this purpose with 32-bit AS Numbers. As a result, the RIPE NCC was asked to bring the issue back to this mailing list for further discussion.
Overloading of the community field is something that is done by current route server operators. This is because of the lack of a proper alternative. While it is something that works for most cases, it does not accurately describe the actual policy. An example: export: to AS6777 action community .= { 6777:6777, 6777:64514, 6777:64515 }; announce AS1200 This specifies that routes are being sent to AS6777 tagged with a set of communities. Without the additional knowledge of how AS6777 treats these communities it is not at all clear that this policy in fact describes a peering relationship between AS1200 and AS64514/AS64515 via the Multi-Lateral Peering service operated by AS6777. The "import-via/export-via" attributes would allow operators to accurately describe these indirect adjacencies, because it actually defines 64514 and 64515 as Autonomous System numbers. Furthermore, the community-approach is problematic due to the lack of room for specifying policies for 32-bit ASNs, which has already been mentioned in this thread. For the above two reasons I would like to see these attributes implemented. Kind regards, Martin
Dear people, On Thu, Oct 24, 2013 at 03:05:21PM +0200, Denis Walker wrote:
During the RIPE 67 Meeting in Athens last week, there was some discussion about the introduction of new "via" attributes to the AUT-NUM object.
This issue has been discussed on both the Database and Routing Working Group mailing lists and at RIPE 67 in both Database and Routing sessions. Overall there was support for it on the Database Working Group list. On the routing-wg@ mailinglist one comment was made, also in support of the introduction of these attributes. The software is ready to be deployed, but the RIPE NCC needs someone to say 'yes, go ahead' if there is consensus. Does anyone have a problem with moving forward towards deployment? Bullet point pitch: - The change is backwards compatible with older RPSL parsers. - The new attributes are completely optional. - This change adds advanced functionality that will especially benefit route server operators and participants. Kind regards, Job
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks,
Bullet point pitch:
- The change is backwards compatible with older RPSL parsers. - The new attributes are completely optional. - This change adds advanced functionality that will especially benefit route server operators and participants.
Can I encourage those that have an opinion about this to voice it? The NCC would like some confirmation from the community that there is some demand to implement this (and no objection to doing it). Job: What are the plans for advancing the I-D? Cheers, Rob -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKWMREACgkQF83fs8P8zalu1ACgwlCUB8Jc23I0LtvZR6cgW1m2 87oAn0omzasDIhWxX23uvwaBPSUel3OV =QExP -----END PGP SIGNATURE-----
On Wed, Nov 27, 2013 at 05:51:13PM +0000, Rob Evans wrote:
Job: What are the plans for advancing the I-D?
I will continue to improve the wording and examples based on feedback, and eventually produce a top-notch RFC. It is not entirely clear at this stage in which working group this document the can be discussed and worked upon, the original RPS working group has been concluded. It is possible an individual submission will be appropriate. Kind regards, Job
On 27/11/2013 17:51, Rob Evans wrote:
- The change is backwards compatible with older RPSL parsers. - The new attributes are completely optional. - This change adds advanced functionality that will especially benefit route server operators and participants.
Can I encourage those that have an opinion about this to voice it? The NCC would like some confirmation from the community that there is some demand to implement this (and no objection to doing it).
I don't object to this change, and possibly a good purpose will be served by having it although I don't plan to use it. By way of historical context, this syntax was previously implemented about 15 years ago using the rs-in: and rs-out: statements for the routing arbiter project. These parameters were lost in the mists of time, but you can still find traces of them here and there, e.g.
http://www.nanog.org/mailinglist/mailarchives/old_archive/1999-10/msg00429.h...
My main concern about the changes is that they unearth a more fundamental problem with rpsl, namely that it is not possible to extend the language without creating a new incompatible statement fork with duplicated syntax. Probably this can be handled relatively efficiently by the back-end code but from the point of view of language design, it's ugly. Nick
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi db-wg and routing-wg,
Can I encourage those that have an opinion about this to voice it? The NCC would like some confirmation from the community that there is some demand to implement this (and no objection to doing it).
The only feedback since that message has been from Nick who, if I may summarise, said that he didn't object, it may serve some use, but this creates an ugly (but inevitable) fork in RPSL. There was mild support before RIPE 67, and the NCC have asked if we can now declare consensus and move on. My interpretation is "yes." Cheers, Rob -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKp2GQACgkQF83fs8P8zalp7wCfbMI6Cr1/kIZ+u1ZvTERaVjha BJkAn3x+GTjxrq9EE3AZvzPnlkt5ceJz =MEex -----END PGP SIGNATURE-----
On Thu, Dec 12, 2013 at 03:38:12PM +0000, Rob Evans wrote:
Can I encourage those that have an opinion about this to voice it? The NCC would like some confirmation from the community that there is some demand to implement this (and no objection to doing it).
The only feedback since that message has been from Nick who, if I may summarise, said that he didn't object, it may serve some use, but this creates an ugly (but inevitable) fork in RPSL.
If this change anything: I do not object. :) Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
participants (6)
-
Denis Walker -
Job Snijders -
Martin Pels -
Nick Hilliard -
Piotr Strzyzewski -
Rob Evans