[routing-wg]Representation of four byte AS numbers.
Hi all, At some point in the coming week I expect to see a new policy proposal hit the policy-announce and address-policy mailing lists that we might want to be aware of here. In past working group sessions we've already discussed the benefits and disadvantages of the various methods of representing 32 bit ASNs (i.e. 'asplain,' 'asdot'). There is now an internet-draft recommending asplain (which is just a single 32 bit integer) in last call at the IETF which can be obtained from the following URL: http://www.ietf.org/internet-drafts/draft-ietf-idr-as-representation-01.txt A related policy proposal reached consensus at the last APNIC meeting and is now in last call there: http://www.apnic.net/policy/proposals/prop-065-v001.html Whilst we already have a presentation on experiences of using a 32 bit ASN scheduled for the Routing working group session, the policy is being discussed in the Address Policy working group. At the moment it will be presented during the session just before lunch on Tuesday morning. At the same time there will also be a presentation on the proposal for certification of PA resources, which you may also be interested in. All the best, Rob
In past working group sessions we've already discussed the benefits and
disadvantages of the various methods of representing 32 bit ASNs (i.e. 'asplain,' 'asdot'). There is now an internet-draft recommending asplain (which is just a single 32 bit integer) in last call at the IETF which can be obtained from the following URL:
http://www.ietf.org/internet-drafts/draft-ietf-idr-as-representation-01.txt
A related policy proposal reached consensus at the last APNIC meeting and is now in last call there:
this proposal was accepted by the apnic sig and member meetings, and is in final discussion on the mailing list. it has no significant additional comment, and would be passed to the apnic ec before the end of this month. but, friends at the ietf have said that they believe they can get the ietf document done and fully processed before the end of the year. so we plan to stall the apnic process in hopes that the ietf can execute theirs. randy, apnic policy chair
Hi, Here's a bit more background, if you are at all interested. The recent action in the APNIC policy SIG has prompted the submission of a draft to the IETF that proposed the adoption of a plain integer format for AS Numbers an Internet Standard. The document, draft-ietf-idr-as- representation-01.txt, has now been through an IETF review process of acceptance by the IDR Working Group, review in a Working Group Last Call, the preparation of an implementation report, and has now been passed across to the IESG for publication as a Proposed Standard. The document is currently in IETF Last Call (https://datatracker.ietf.org/idtracker/?search_button=SEARCH&search_filename=draft-ietf-idr-as-representation-01.txt&sub_state_id=6 ). The Last Call ends today (20th October 2008). Within the context of the APNIC policy development process, the APNIC proposal's authors have been requested to consider delaying the APNIC implementation procedure in order to allow the IETF Standards process to run to completion in this case (http://mailman.apnic.net/mailing-lists/sig-policy/archive/2008/10/msg00008.h... ). Speaking personally, I'm not sure what the objective would be in introducing a similar proposal to RIPE at this stage, given that the IETF process of standardization of nomenclature for 32-bit AS numbers is reaching a conclusion in the coming couple of weeks or so, but I guess (hope?) that the motivation for doing this in parallel in the context of the RIPE policy development process will become apparent once the proposal you refer to is actually posted to the address- policy mailing list. regards, Geoff Huston Disclaimer - speaking just for me, as usual! On 19/10/2008, at 8:47 PM, Rob Evans wrote:
Hi all,
At some point in the coming week I expect to see a new policy proposal hit the policy-announce and address-policy mailing lists that we might want to be aware of here.
In past working group sessions we've already discussed the benefits and disadvantages of the various methods of representing 32 bit ASNs (i.e. 'asplain,' 'asdot'). There is now an internet-draft recommending asplain (which is just a single 32 bit integer) in last call at the IETF which can be obtained from the following URL:
http://www.ietf.org/internet-drafts/draft-ietf-idr-as-representation-01.txt
A related policy proposal reached consensus at the last APNIC meeting and is now in last call there:
http://www.apnic.net/policy/proposals/prop-065-v001.html
Whilst we already have a presentation on experiences of using a 32 bit ASN scheduled for the Routing working group session, the policy is being discussed in the Address Policy working group. At the moment it will be presented during the session just before lunch on Tuesday morning. At the same time there will also be a presentation on the proposal for certification of PA resources, which you may also be interested in.
All the best, Rob
Hi, On Mon, Oct 20, 2008 at 04:34:18AM +1100, Geoff Huston wrote:
Speaking personally, I'm not sure what the objective would be in introducing a similar proposal to RIPE at this stage, given that the IETF process of standardization of nomenclature for 32-bit AS numbers is reaching a conclusion in the coming couple of weeks or so, but I guess (hope?) that the motivation for doing this in parallel in the context of the RIPE policy development process will become apparent once the proposal you refer to is actually posted to the address- policy mailing list.
The main issue is that our policy documents explicitely use ASDOT notation for 4-byte AS numbers. If the IETF decides to deprecate this notation, our documents need changing, and we need a formal policy proposal to do that - and since this is an address policy document, the proposal landed on APWG's plate. I've asked the routing- and DB-WG chairs to send a "heads up" to their respective working groups, so that interested parties can participate in the discussion (if needed), and because it will also need an implementation change in the RIPE DB software. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On 20/10/2008, at 4:57 AM, Gert Doering wrote:
Hi,
On Mon, Oct 20, 2008 at 04:34:18AM +1100, Geoff Huston wrote:
Speaking personally, I'm not sure what the objective would be in introducing a similar proposal to RIPE at this stage, given that the IETF process of standardization of nomenclature for 32-bit AS numbers is reaching a conclusion in the coming couple of weeks or so, but I guess (hope?) that the motivation for doing this in parallel in the context of the RIPE policy development process will become apparent once the proposal you refer to is actually posted to the address- policy mailing list.
The main issue is that our policy documents explicitely use ASDOT notation for 4-byte AS numbers.
If the IETF decides to deprecate this notation, our documents need changing, and we need a formal policy proposal to do that - and since this is an address policy document, the proposal landed on APWG's plate.
I've asked the routing- and DB-WG chairs to send a "heads up" to their respective working groups, so that interested parties can participate in the discussion (if needed), and because it will also need an implementation change in the RIPE DB software.
Thanks for this explanation Gert - it is now easier to appreciate what you are after here with this proposal. As a gentle suggestion to the authors of this as yet unseen proposal, they may want to consider simply proposing that RIPE uses recognized standard notations for IP addresses and AS numbers in its registry and in all published material, as and when such standards are published, and thereby attempt to avid any subsequent revisiting of this matter on a case-by-case basis. (With reference to your deprecate comment, I should note that the IETF never adopted the ASDOT notation in the first place, or adopted formally any other notation for AS numbers in the past. The informal adoption of the ASDOT notation was one that had a more organic origin. A specification of notation was not part of the 4-byte AS Internet draft. The original slideware used by Enke Chen, and the original implementations of this code in Redback products, used a ASCOLON notation. When the original 32-bit AS policy proposal for the RIRs was introduced to the policy communities it included reference to this defacto ASCOLON notation. The ARIN policy forum provided feedback that the colon was confusing with respect to communities and some other delimiter would be better, and ASDOT was suggested. Subsequent iterations of the policy were adjusted to remove all reference to AS number notation because notation standards was not an RIR responsibility so all reference to ASDOT or anything else was stripped from the policy proposals in the RIRs. But in the absence of anything else what was left was ASDOT, and thats what was sused to populate the IANA registry, the RIRs' registries and early implementations of 32- bit AS BGP. To be frank I'm not sure why it resurfaced in APNIC earlier this year as a formal policy proposal, given the earlier view that notational standards were properly the business of the IETF in this context, but I guess that some flexibility is an attribute of our system.) regards, Geoff Huston Disclaimer: what I said last time - its still just me!
Hi Rob, Gert Doering wrote: [...]
I've asked the routing- and DB-WG chairs to send a "heads up" to their respective working groups, so that interested parties can participate in the discussion (if needed), and because it will also need an implementation change in the RIPE DB software.
I presume this will end up as a task for the RIPE NCC for our region. But... Just as a reminder or marker - who or which group is expected to update the (relevant) tools these days? And, do we have an common understanding of the term "relevant" in this context? :-)
Gert Doering -- APWG chair
Wilfried.
Hi Wilfried,
Gert Doering wrote: [...]
I've asked the routing- and DB-WG chairs to send a "heads up" to their respective working groups, so that interested parties can participate in the discussion (if needed), and because it will also need an implementation change in the RIPE DB software.
I presume this will end up as a task for the RIPE NCC for our region.
But... Just as a reminder or marker - who or which group is expected to update the (relevant) tools these days? And, do we have an common understanding of the term "relevant" in this context? :-)
When I ran the project to introduce ASN32 at the RIPE NCC (back in 2006/7), we went through our documents for all instances of an AS number and changed it. We still have this list somewhere. And more general, this is on my desk to look at as soon as the discussion in the IETF converges. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Ceterum censeo Asplain esse delendam (Cato & Henk)
On 20/10/2008, at 15:16, Wilfried Woeber, UniVie/ACOnet wrote:
Hi Rob,
Gert Doering wrote: [...]
I've asked the routing- and DB-WG chairs to send a "heads up" to their respective working groups, so that interested parties can participate in the discussion (if needed), and because it will also need an implementation change in the RIPE DB software.
I presume this will end up as a task for the RIPE NCC for our region.
But... Just as a reminder or marker - who or which group is expected to update the (relevant) tools these days?
I am guessing that would be their respective maintainers or, for full open source projects, whoever implements the necessary changes. For instance, the IRRToolset is currently a community project, with some resource backing to ensure regular integration of patches submitted by contributors (see http://irrtoolset.isc.org/ for details)
And, do we have an common understanding of the term "relevant" in this context? :-)
i think this is a classical feedback loop :-) Joao
Hi Wilfried,
But... Just as a reminder or marker - who or which group is expected to update the (relevant) tools these days? And, do we have an common understanding of the term "relevant" in this context? :-)
I'm not sure, what do you think of as the relevant tools? :-) I assume the RIPE NCC will update the database software and associated documentation to adhere to whichever standards develop. IRRToolset is moving to a more open development platform, which we will also have a presentation on during the Routing WG session. I'm sure patches for this will be more than welcome from whoever wishes to contribute them (such is the open source model). Other tools, such as 'irrd' are probably out of the scope of the RIPE working groups, but the maintainers of those utilities presumably keep up with developments in the standardisation bodies. I don't think the RPSL/RPSL-NG specifications specify the range of valid AS numbers, just the format of AS<number>. ...but perhaps I'm misunderstanding the question... All the best, Rob
participants (7)
-
Geoff Huston -
Gert Doering -
Henk Uijterwaal -
Joao Damas -
Randy Bush -
Rob Evans -
Wilfried Woeber, UniVie/ACOnet