Fwd: Re: RPSL support for 32 bit ASN
Date: Wed, 23 Aug 2006 11:20:53 +0200 To: Mark Prior <mrp@mrp.net> From: Henk Uijterwaal <henk@ripe.net> Subject: Re: RPSL support for 32 bit ASN Cc: rpslnp@ripe.net, asn32@ripe.net, ggm@apnic.net
At 15:08 18/08/2006, Mark Prior wrote:
Is it worth doing another update to RPSL to include this
This would certainly help us a lot (we can point to a document when we update our tools), so ...
... I spent a morning writing essentially a 1 page document just to update this and submitted it as an individual submission ID, draft-uijterwaal-rpsl-4byteas-ext-00.txt. To appear in the ID repository soon.
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 ------------------------------------------------------------------------------
1160438400 + 381600 = 1160820000.
------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000.
Henk, On Wed, Aug 23, 2006 at 11:21:41AM +0200, Henk Uijterwaal wrote:
... I spent a morning writing essentially a 1 page document just to update this and submitted it as an individual submission ID, draft-uijterwaal-rpsl-4byteas-ext-00.txt. To appear in the ID repository soon.
For the record, I am willing to sponsor this document as soon as IETF has decided what the 'standard' notation is going to be. I hope that makes sense. David Kessens ---
On Wed, 23 Aug 2006 10:47:50 -0700 David Kessens <david.kessens@nokia.com> wrote:
Henk,
On Wed, Aug 23, 2006 at 11:21:41AM +0200, Henk Uijterwaal wrote:
... I spent a morning writing essentially a 1 page document just to update this and submitted it as an individual submission ID, draft-uijterwaal-rpsl-4byteas-ext-00.txt. To appear in the ID repository soon.
For the record, I am willing to sponsor this document as soon as IETF has decided what the 'standard' notation is going to be. I hope that makes sense.
David Kessens ---
[cc Geoff] Thanks David, that makes sense. My next step is to cut an 02 draft and put it to Yakov Rechter/Susan Hares for discussion in IDR at San Diego. I've been led to believe this is the most appropriate WG for it to get signoff and move on from. cheers -George
On Wed, 23 Aug 2006, David Kessens wrote:
For the record, I am willing to sponsor this document as soon as IETF has decided what the 'standard' notation is going to be. I hope that makes sense.
Which group in IETF is going to decide this? -- William Leibzon Elan Networks william@elan.net
William, On Thu, Aug 24, 2006 at 11:17:04AM -0700, william(at)elan.net wrote:
On Wed, 23 Aug 2006, David Kessens wrote:
For the record, I am willing to sponsor this document as soon as IETF has decided what the 'standard' notation is going to be. I hope that makes sense.
Which group in IETF is going to decide this?
The RPSL document would be an AD sponsored individual submission. That is, it will not come out of an IETF working group but will be contributed by an individual (Henk). This document would be last called so everybody has a chance to comment, and as you can see from the discussions among the CC'ed, a good set of people who are involved with RPSL in one way or the other have been involved by Henk. David Kessens ---
On Thu, 24 Aug 2006, David Kessens wrote:
For the record, I am willing to sponsor this document as soon as IETF has decided what the 'standard' notation is going to be. I hope that makes sense.
Which group in IETF is going to decide this?
The RPSL document would be an AD sponsored individual submission. That is, it will not come out of an IETF working group but will be contributed by an individual (Henk). This document would be last called so everybody has a chance to comment, and as you can see from the discussions among the CC'ed, a good set of people who are involved with RPSL in one way or the other have been involved by Henk.
I was asking which group in IETF is deciding on "standard notation". -- William Leibzon Elan Networks william@elan.net
William,
I was asking which group in IETF is deciding on "standard notation".
IDR, I guess, since this WG did all ASN32 work so far. There is a (at the moment individual submission) http://www.ietf.org/internet-drafts/draft-michaelson-4byte-as-representation.... This draft has been proposed as a WG item. Henk
-- William Leibzon Elan Networks william@elan.net
------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000.
Henk Uijterwaal wrote:
Date: Wed, 23 Aug 2006 11:20:53 +0200 To: Mark Prior <mrp@mrp.net> From: Henk Uijterwaal <henk@ripe.net> Subject: Re: RPSL support for 32 bit ASN Cc: rpslnp@ripe.net, asn32@ripe.net, ggm@apnic.net
At 15:08 18/08/2006, Mark Prior wrote:
Is it worth doing another update to RPSL to include this
This would certainly help us a lot (we can point to a document when we update our tools), so ...
... I spent a morning writing essentially a 1 page document just to update this and submitted it as an individual submission ID, draft-uijterwaal-rpsl-4byteas-ext-00.txt. To appear in the ID repository soon.
Henk
There was considerable discussion during the development of the RPSLng spec (RFC4012) concerning modifying the syntax for existing attributes. The consensus was that this approach should not be taken and that new attributes should be created wherever an IPv6 address could appear so as not to break existing tools. draft-uijterwaal-rpsl-4bytesas-ext-00.txt appears to have abandoned this approach. -Larry Blunk Merit
Larry,
There was considerable discussion during the development of the RPSLng spec (RFC4012) concerning modifying the syntax for existing attributes. The consensus was that this approach should not be taken and that new attributes should be created wherever an IPv6 address could appear so as not to break existing tools. draft-uijterwaal-rpsl-4bytesas-ext-00.txt appears to have abandoned this approach.
That is correct. I looked at the problem and creating new attributes for ASN32 would cause the number of attributes to expand as N^2. In other words, for each kind of attribute, there would be a version for IPv4-ASN16, IPv6-ASN16, IPv4-ASN32 and IPv6-ASN32. If something else is changed in the future, this will result in 8 versions of essentially the same attribute. This does not look very attractive to me. Also, contrary to IPv4 and IPv6, we are very likely to have a mixed ASN16 and ASN32 world "forever". In fact, the ASN32 standard is specifically designed with this in mind, and the two worlds can live happily together. So, any tool will have to be upgraded sooner or later, the only question is when and how. In both cases (change existing attributes or create new ones), people will have to upgrade when they move into the ASN32 world. The difference is in the code change. In my draft, the tools will have to recognize 2 versions for an AS. Changing attributes means that tools will have to check if the ASN16 or ASN32 version is there, then parse that to get the information. In the end, this doesn't look like a big difference to me. 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 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000.
Hi Larry,
There was considerable discussion during the development of the RPSLng spec (RFC4012) concerning modifying the syntax for existing attributes. The consensus was that this approach should not be taken and that new attributes should be created wherever an IPv6 address could appear so as not to break existing tools. draft-uijterwaal-rpsl-4bytesas-ext-00.txt appears to have abandoned this approach.
That is correct. I looked at the problem and creating new attributes for ASN32 would cause the number of attributes to expand as N^2. In other words, for each kind of attribute, there would be a version for IPv4-ASN16, IPv6-ASN16, IPv4-ASN32 and IPv6-ASN32. If something else is changed in the future, this will result in 8 versions of essentially the same attribute. This does not look very attractive to me.
<skip> I support Henk in this. To strictly follow the RPSL extention guidelines, one has to add 12 new attributes to existing objects and 7 new classes (with total of 30+ new attributes) to accept 32bit ASn. Following RPSL extention guidelines where possible is good, but I think here alternative approach is justified. -- Katie Petrusha RIPE NCC
Henk Uijterwaal wrote:
Larry,
There was considerable discussion during the development of the RPSLng spec (RFC4012) concerning modifying the syntax for existing attributes. The consensus was that this approach should not be taken and that new attributes should be created wherever an IPv6 address could appear so as not to break existing tools. draft-uijterwaal-rpsl-4bytesas-ext-00.txt appears to have abandoned this approach.
That is correct. I looked at the problem and creating new attributes for ASN32 would cause the number of attributes to expand as N^2. In other words, for each kind of attribute, there would be a version for IPv4-ASN16, IPv6-ASN16, IPv4-ASN32 and IPv6-ASN32. If something else is changed in the future, this will result in 8 versions of essentially the same attribute. This does not look very attractive to me.
Also, contrary to IPv4 and IPv6, we are very likely to have a mixed ASN16 and ASN32 world "forever". In fact, the ASN32 standard is specifically designed with this in mind, and the two worlds can live happily together.
So, any tool will have to be upgraded sooner or later, the only question is when and how.
In both cases (change existing attributes or create new ones), people will have to upgrade when they move into the ASN32 world. The difference is in the code change. In my draft, the tools will have to recognize 2 versions for an AS. Changing attributes means that tools will have to check if the ASN16 or ASN32 version is there, then parse that to get the information. In the end, this doesn't look like a big difference to me.
The big difference is that existing tools can potentially break if the syntax is changed in existing attributes. I agree that adding new attributes is undesirable, but I see a couple alternatives. The first would be to use straight integer notation for the AS numbers instead of the "." notations. This is actually compatible with the RFC 2622 flex macro for AS numbers (as Mark Prior noted) and would likely be compatible with existing tools. INT [[:digit:]]+ ASNO AS{INT} The presentation and submission layers could optionally support the "." notation. Note that RFC3779 uses a straight integer for 32-bit ASN's (as opposed to the dotted character bitstrings for IPv4 numbers), so this is not unprecedented. The other option would be to update RFC4012 (RPSLngbis?) as it is relatively fresh and the tools to process mp- attributes are few. -Larry
Larry,
The big difference is that existing tools can potentially break if the syntax is changed in existing attributes. I agree that adding new attributes is undesirable, but I see a couple alternatives. The first would be to use straight integer notation for the AS numbers instead of the "." notations.
The IESG has asked for a standard notation for ASN32 when processing draft-ietf-idr-as4bytes. draft-michaelson-4byte-as-representation was written to suggest the "x.y" notation. This draft is likely to be accepted soon. My draft follows this "x.y" notation simply because I don't think that it is a good idea to have 2 different formats for the same thing. At least, it'd drive me nuts if I had to type 1.0 in one place (my router CLI, for example) and 65536 in another (an RPSL tool) when referring to the same thing.
This is actually compatible with the RFC 2622 flex macro for AS numbers (as Mark Prior noted) and would likely be compatible with existing tools.
An AS has been a 16 bit number forever (in terms of the lifetime of the Internet) and authors have implicitly used that when writing their tools. That means: regular int's (or even short unsigned ints) in the code, checks on input that numbers entered are below 65536 and/or 5 digits, arrays dimensioned to 65536, etc. All this code will have to be checked and updated. I would definitely not feel comfortable using code with numbers outside the range of the original spec.
Note that RFC3779 uses a straight integer for 32-bit ASN's (as opposed to the dotted character bitstrings for IPv4 numbers), so this is not unprecedented.
I seriously doubt that the authors of RFC3779 had ASN32 in mind when they wrote that RFC. I also think that this is a good example of why things have to be checked; a regular C integer (31 bits plus sign bit) in your code will fail for ASN 32768.0. It should be an unsigned int. 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 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000.
Henk Uijterwaal wrote:
Larry,
The big difference is that existing tools can potentially break if the syntax is changed in existing attributes. I agree that adding new attributes is undesirable, but I see a couple alternatives. The first would be to use straight integer notation for the AS numbers instead of the "." notations.
The IESG has asked for a standard notation for ASN32 when processing draft-ietf-idr-as4bytes. draft-michaelson-4byte-as-representation was written to suggest the "x.y" notation. This draft is likely to be accepted soon.
My draft follows this "x.y" notation simply because I don't think that it is a good idea to have 2 different formats for the same thing. At least, it'd drive me nuts if I had to type 1.0 in one place (my router CLI, for example) and 65536 in another (an RPSL tool) when referring to the same thing.
The tool could convert from "x.y" when processing for submission, so you wouldn't have to deal with 2 different formats.
This is actually compatible with the RFC 2622 flex macro for AS numbers (as Mark Prior noted) and would likely be compatible with existing tools.
An AS has been a 16 bit number forever (in terms of the lifetime of the Internet) and authors have implicitly used that when writing their tools. That means: regular int's (or even short unsigned ints) in the code, checks on input that numbers entered are below 65536 and/or 5 digits, arrays dimensioned to 65536, etc. All this code will have to be checked and updated. I would definitely not feel comfortable using code with numbers outside the range of the original spec.
The original spec doesn't specify a range. Some code will have problems with numbers greater than 16-bit, others won't. Certainly fewer implementations will have issues with 32-bit numbers than "x.y" notation.
Note that RFC3779 uses a straight integer for 32-bit ASN's (as opposed to the dotted character bitstrings for IPv4 numbers), so this is not unprecedented.
I seriously doubt that the authors of RFC3779 had ASN32 in mind when they wrote that RFC. I also think that this is a good example of why things have to be checked; a regular C integer (31 bits plus sign bit) in your code will fail for ASN 32768.0. It should be an unsigned int.
Actually, they did have 32 bit AS numbers in mind. That's why they defined the following in the RFC -- Autonomous System number - a 32-bit number that identifies an autonomous system. I'm not sure if this is actually compatible with the ASN.1 INTEGER definition, but they definitely had the foresight to allow for 32-bit AS numbers.
Larry,
The tool could convert from "x.y" when processing for submission, so you wouldn't have to deal with 2 different formats.
Yes, it could. I'm not sure if it will though. There is a canonical representation for printing these numbers and as a developper I'd use that. If somebody wants another format internally because that is easier, I expect him to do that in his tool. For the same reason, I allow people to enter an IPv4 adress as 193.0.1.49, I don't expect them to do the artimethic to convert it to 3238002993 even if in my code, I use unsigned int's.
An AS has been a 16 bit number forever (in terms of the lifetime of the Internet) and authors have implicitly used that when writing their tools. That means: regular int's (or even short unsigned ints) in the code, checks on input that numbers entered are below 65536 and/or 5 digits, arrays dimensioned to 65536, etc. All this code will have to be checked and updated. I would definitely not feel comfortable using code with numbers outside the range of the original spec.
The original spec doesn't specify a range. Some code will have problems with numbers greater than 16-bit, others won't. Certainly fewer implementations will have issues with 32-bit numbers than "x.y" notation.
The AS spec does. Then, nothing prevents you to convert "x.y" into an unsigned int in your code and use that internally. 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 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000.
Henk Uijterwaal wrote:
Larry,
The tool could convert from "x.y" when processing for submission, so you wouldn't have to deal with 2 different formats.
Yes, it could. I'm not sure if it will though. There is a canonical representation for printing these numbers and as a developper I'd use that. If somebody wants another format internally because that is easier, I expect him to do that in his tool.
For the same reason, I allow people to enter an IPv4 adress as 193.0.1.49, I don't expect them to do the artimethic to convert it to 3238002993 even if in my code, I use unsigned int's.
I guess I wasn't being clear. I was speaking of the input processor for the routing registry itself. For example, the RIPE software will convert inetnum attributes from CIDR prefix format to range format. The point is that a number tools using the registry. Some use the whois interface, while others do bulk downloads of the registry data to process it. While not a huge population of users, I think you may underestimate the number and variety of tools. Further, these tools will not always reference objects registered by the user. There may be object references to external route-set's/as-set's, etc.. Tools that do bulk processing of registry files will scan through all the objects (looking for particular AS numbers in route: objects for example). -Larry
An AS has been a 16 bit number forever (in terms of the lifetime of the Internet) and authors have implicitly used that when writing their tools. That means: regular int's (or even short unsigned ints) in the code, checks on input that numbers entered are below 65536 and/or 5 digits, arrays dimensioned to 65536, etc. All this code will have to be checked and updated. I would definitely not feel comfortable using code with numbers outside the range of the original spec.
The original spec doesn't specify a range. Some code will have problems with numbers greater than 16-bit, others won't. Certainly fewer implementations will have issues with 32-bit numbers than "x.y" notation.
The AS spec does.
Then, nothing prevents you to convert "x.y" into an unsigned int in your code and use that internally.
Henk
participants (6)
-
David Kessens -
George Michaelson -
Henk Uijterwaal -
Katie Petrusha -
Larry J. Blunk -
william(at)elan.net