Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
Randy and everyone: I restate my objection to ASPLAIN.
1. writing 32-bit interger as a ASDOT is much more readible by human than ASPLAN
2. Just as Randy noticed during the meeting, 32-bit AS is the same range as IPv4. I would think everyone would agree that writing and communicating IPv4 as a single integer (3420323840 is the same as 203.222.32.0) is a bad idea.
3. It was mentioned that we probably will not exceed 7 digit ASN. However, this is exactly the mentality that got us here in 16-bit ASN and with IPv4. We can not forsee the new use of ASN in the future. It may happen that every household gets an ASN for mobile service in the future.
4. It is in the equipment vendors' best interest to make their code to deal with both ASPLAIN and ASDOT, and provide best human-interface possible. ASDOT presents a much better human-interface than ASPLAIN.
5. APNIC as a registry should also present the best human interface as possible. ASDOT is the better choice.
I also have the inpression that IANA and other registry entities are using ASDOT.
yi
----- Original Message ---- From: Randy Bush randy@psg.com To: Policy SIG sig-policy@apnic.net Sent: Friday, August 29, 2008 12:25:07 AM Subject: [sig-policy] last call: prop-065: Format for delegation and recording of 4-byte AS numbers
---------------------------------------------------------------------- prop-065: Format for delegation and recording of 4-byte AS numbers -----------------------------------------------------------------------
Dear colleagues
This is the final call for comments on policy proposal prop-065, "Format for delegation and recording of 4-byte AS numbers".
This proposal was presented at APNIC 26 and was accepted by consensus.
The proposal has been submitted to the Policy SIG mailing list for an eight-week discussion period. At the end of that period, if consensus appears to have been achieved, the Policy SIG Chair will ask the Executive Council to endorse the proposal for implementation.
* Send all comments and questions to: sig-policy@apnic.net * Deadline for comments: 24 October 2008
Proposal details ----------------
APNIC to adopt the ASPLAIN format for representing four-byte AS numbers.
Proposal details including the full text of the proposal, presentations, links to relevant meeting archives and links to mailing list discussions are available at:
http://www.apnic.net/policy/proposals/prop-065-v001.html * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Hi Yi,
Yi Chu said the following on 10/9/08 11:24:
Randy and everyone: I restate my objection to ASPLAIN.
- writing 32-bit interger as a ASDOT is much more readible by human than ASPLAN
And what do routers do? After all, routers are the ones that have to deal with these things.
- Just as Randy noticed during the meeting, 32-bit AS is the same range as IPv4. I would think everyone would agree that writing and communicating IPv4 as a single integer (3420323840 is the same as 203.222.32.0) is a bad idea.
Have you tried using a 32 bit integer IP address? It works. Besides, the dotted notation came out of history, helping to separate different classes of IP address space. If we didn't have classes, I'm sure we'd have come up with some other notation for IPv4 addresses. Plus we don't have classes of AS space (nothing about it in the 4-byte ASN RFC), so using any separator is plain dumb.
- It was mentioned that we probably will not exceed 7 digit ASN. However, this is exactly the mentality that got us here in 16-bit ASN and with IPv4. We can not forsee the new use of ASN in the future. It may happen that every household gets an ASN for mobile service in the future.
I still don't see how use of an ASN has anything to do with how it is written into the router.
- It is in the equipment vendors' best interest to make their code to deal with both ASPLAIN and ASDOT, and provide best human-interface possible. ASDOT presents a much better human-interface than ASPLAIN.
Have you tried writing regular expressions to handle the dot-format ASN? If not, please go and do that, and let us know how you got on. Maybe give us some examples.
- APNIC as a registry should also present the best human interface as possible. ASDOT is the better choice.
Personal preference. Those of us who configure routers prefer the Internet to work, not look pretty. Did you object to the format of IPv6 addresses when they first appeared? ;-)
philip --
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Yi Chu wrote: \
- Just as Randy noticed during the meeting, 32-bit AS is the same
range as IPv4. I would think everyone would agree that writing and communicating IPv4 as a single integer (3420323840 is the same as 203.222.32.0) is a bad idea.
203.222.32.0 is 3420332032. and that's 52190.8192 in ASDOT.
3468851153 is 52930.30673
I don't see any readability / writing enhancement. there is still 10 characters to deal with.
- It was mentioned that we probably will not exceed 7 digit ASN.
However, this is exactly the mentality that got us here in 16-bit ASN and with IPv4. We can not forsee the new use of ASN in the future. It may happen that every household gets an ASN for mobile service in the future.
and like we have seen with IPv6, not making it backward compatible has its own drawbacks. In a live environment today, I don't see any advantage of not making things backward compatible. The additional work needed to change all the OSS and regexp is considerably larger when we change formats.
As Randy said, if we do want a delimiter, why not ASSMILEY.
thanks -gaurab
i have stayed out of all ASDOT/PLAIN discussions because i think they exemplify how much time and energy can be spent on something trivial. but i fear that i actually have a minor insight to contribute :(
3468851153 is 52930.30673
i think that we hope that the ASDOT notation will 'make sense.' this is because we think that they will be assigned incrementally. i.e. we think that, for some years, it will look like 1.42 1.666 2.711 etc. like global warming, we will leave ugliness such as your example to our grandchildren.
<sarcasm> hey iana! how about issuing the next chunk from the middle of the range? i.e. give 32666.0 - 32666.1023 to APNIC.
this would be in line with the "they will only change if we make them suffer" philosophy of making ipv4 difficult so folk might move to ipv6. </sarcasm>
randy
I think we are dealing with two things here the admin side which is more of the concerns for the ASDOT and the routing side that makes ASDOT complicated for the regular expression.
Just a simple suggestion, again just a suggestion :) can we think in a way that maybe can we keep the readability in place (with the ASDOT for admin purpose) so that IANA and the RIR's life would be easy when it comes to assigning 4 byte ASN. But still in the routing side we'll keep the PLAIN format (maybe a simple conversion from the ASDOT to PLAIN is needed).
On 11/09/2008, at 8:17 AM, Gaurab Raj Upadhaya wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Yi Chu wrote: \
- Just as Randy noticed during the meeting, 32-bit AS is the same
range as IPv4. I would think everyone would agree that writing and communicating IPv4 as a single integer (3420323840 is the same as 203.222.32.0) is a bad idea.
203.222.32.0 is 3420332032. and that's 52190.8192 in ASDOT.
3468851153 is 52930.30673
I don't see any readability / writing enhancement. there is still 10 characters to deal with.
- It was mentioned that we probably will not exceed 7 digit ASN.
However, this is exactly the mentality that got us here in 16-bit ASN and with IPv4. We can not forsee the new use of ASN in the future. It may happen that every household gets an ASN for mobile service in the future.
and like we have seen with IPv6, not making it backward compatible has its own drawbacks. In a live environment today, I don't see any advantage of not making things backward compatible. The additional work needed to change all the OSS and regexp is considerably larger when we change formats.
As Randy said, if we do want a delimiter, why not ASSMILEY.
thanks -gaurab
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkjIR48ACgkQSo7fU26F3X1cggCgyCo1WOTGh4Xgx4RJMxlDniW4 6mYAnj7UnCSpCskURND/2/q+sSDR8s+u =L+I3 -----END PGP SIGNATURE-----
sig-policy: APNIC SIG on resource managementpolicy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
On 11/09/2008, at 12:11 PM, Amante Alvaran wrote:
I think we are dealing with two things here the admin side which is more of the concerns for the ASDOT and the routing side that makes ASDOT complicated for the regular expression.
I would have thought the admin side would be far easier dealing with a 32bit integer rather than the structured ASDOT notation.
Just a simple suggestion, again just a suggestion :) can we think in a way that maybe can we keep the readability in place (with the ASDOT for admin purpose) so that IANA and the RIR's life would be easy when it comes to assigning 4 byte ASN. But still in the routing side we'll keep the PLAIN format (maybe a simple conversion from the ASDOT to PLAIN is needed).
Some vendors are having problems delivering /any/ four byte ASN capability in a suitable timeframe, irrespective of notation. The last thing we want is for those vendors to direct their engineering time towards the ASDOT notation that does not work well in an operational environment. Which they are. Because the wider community is unintentionally telling the that ASDOT should be used.
Do people really feel that the presentation of 32bit ASNs is more important than their operational usability? Or that we should wait for some other entity to make that call for us, and hope it happens soon enough to be useful?
Cheers, Jonny.
Activity Summary
- 5489 days inactive
- 5489 days old
- sig-policy@lists.apnic.net
- 6 participants
- 5 comments