FYI... ifyou think you have an opinion about this, it might be worth a read before the IESG dictates how you can use/code these badboys... ----- The IESG has received a request from an individual submitter to consider the following document: - 'Canonical representation of 4-byte AS numbers ' <draft-michaelson-4byte-as-representation-01.txt> as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-11-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-michaelson-4byte-as-representation... --bill
Randy Bush wrote:
- 'Canonical representation of 4-byte AS numbers ' <draft-michaelson-4byte-as-representation-01.txt> as an Informational RFC
and what is good or bad about this representation? seems simple to me. and having one notation seems reasonable. what am i missing?
Using '.' as a delimiter will be somewhat annoying when used in regular expressions and likely to induce errors. Would '-' be a better choice? - Kevin
somehow we seem to have survived similar issues in IP quad representation.
true but we don't typically user them in regex expressions as much (at least I haven't). Its more masks and inverted masks... Regards, Neil. -- Neil J. McRae - Alive and Kicking - Team Hong Nor neil@DOMINO.ORG
On Tue, Oct 10, 2006 at 01:59:22AM -0500, Randy Bush wrote:
somehow we seem to have survived similar issues in IP quad representation.
Or domain names. I'm concerned by the kind of discussion I'm seeing here. RFC's are not law, and if your router vendor adopts this informational document in such a way that it breaks your scripts then that's an issue to take up with your router vendor(s). I don't see why there's any reason it can't be made so (excuse me for using what little Cisco configuration language I can remember): o 'conf t' accepts: router bgp 255.255.255.254 neighbor 10.0.0.1 remote-as 255.255.255.255 o 'wr mem/term' writes out: router bgp 4294967294 # 255.255.255.254 neighbor 10.0.0.1 remote-as 4294967295 # 255.255.255.255 or even: # BGP 255.255.255.254 router bgp 4294967294 # EZ-ASN: 255.255.255.255 neighbor 10.0.0.1 remote-as 4294967295 One or both of which probably won't break anyone's scripts. The point is that this is a configuration language versioning issue, which isn't something I think of the IETF having either a lot of interest or ability to define. As Shields has indicated, email the IETF mailing lists if you must. I'm in favor of people sending mail to lists to which I do not subscribe. But it's just /weird/ to ask the IETF to have this kind of role...one it has never had to my memory, and seeks constantly not to fulfill. -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DDNS & DHCP. Email training@isc.org. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
On 10-Oct-2006, at 12:01, David W. Hankins wrote:
But it's just /weird/ to ask the IETF to have this kind of role...one it has never had to my memory, and seeks constantly not to fulfill.
It's not so weird when you realise that the notation adopted has an impact on other IETF work (RPSL is the obvious example that springs to mind). Joe
On Tue, Oct 10, 2006 at 02:53:53PM -0500, Joe Abley wrote:
On 10-Oct-2006, at 12:01, David W. Hankins wrote:
But it's just /weird/ to ask the IETF to have this kind of role...one it has never had to my memory, and seeks constantly not to fulfill.
It's not so weird when you realise that the notation adopted has an impact on other IETF work (RPSL is the obvious example that springs to mind).
I think you misunderstand me... It's not weird that this document exists. It is weird, to me, that people who have concerns about their router's configuration syntax expect to be able to take this up with the IETF, rather than their router manufacturer. -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DDNS & DHCP. Email training@isc.org. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
On 2006-10-10 13:41:42, David W. Hankins wrote:
It is weird, to me, that people who have concerns about their router's configuration syntax expect to be able to take this up with the IETF, rather than their router manufacturer.
Personally, I care less about which notation we choose to express four-byte ASNs than that *everyone choose one notation*. Choosing a mediocre notation and using it consistently would be better than having to live forever with multiple notations. Operating a heterogenous network is hard enough already. As to whether this is within the scope of the IETF, note that they are already going far, far beyond this in the Netconf WG, which is defining a complete router configuration protocol. http://www.ietf.org/html.charters/netconf-charter.html http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-12.txt -- Shields.
On Tue, Oct 10, 2006 at 09:23:54PM +0000, Michael Shields wrote:
Personally, I care less about which notation we choose to express four-byte ASNs than that *everyone choose one notation*. Choosing a
Totally, and I would be surprised if that were not the eventual outcome. In the absence of any other format, the dotted quad will probably bubble up into user interfaces eventually. I think everyone else is wrong that there is going to be some sort of heinous "y2k" doomsday scenario here in regards to breaking their current-day scripts or operational practices, or if there were that this is an issue to take up with the IETF rather than the vendors making said changes.
As to whether this is within the scope of the IETF, note that they are already going far, far beyond this in the Netconf WG, which is defining a complete router configuration protocol.
Netconf absolutely, and zeroconf too. These are machine languages, they aren't user interfaces. So this is just a level of indirection. If someone were suggesting a change to the netconf wire format that is not reverse compatible, that's obviously something that should be brought up at the IETF! But a change to the config file or web/scripting interface or whatever that you use to trigger Netconf into action? Totally not their bag. -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DDNS & DHCP. Email training@isc.org. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
On Tue, 10 Oct 2006, Kevin Loch wrote:
Randy Bush wrote:
- 'Canonical representation of 4-byte AS numbers ' <draft-michaelson-4byte-as-representation-01.txt> as an Informational RFC
and what is good or bad about this representation? seems simple to me. and having one notation seems reasonable. what am i missing?
Using '.' as a delimiter will be somewhat annoying when used in regular expressions and likely to induce errors. Would '-' be a better choice?
No. We already use "." for number of ip resources so this is good. I suspect new tools & config systems will also accept full 32bit number as well (just like its sometimes possible with ip addresses) which will give you way out if you do not like "." in ASN. And regular ASNs < 65k will work without "0." in this way as well. -- William Leibzon Elan Networks william@elan.net
- 'Canonical representation of 4-byte AS numbers '
http://www.ietf.org/internet-drafts/draft-michaelson-4byte-as-representation...
and what is good or bad about this representation? seems simple to me. and having one notation seems reasonable. what am i missing?
It breaks any applications which recognize IP address-like objects by seeing a dot in an otherwise numeric token. For the purposes of parsing a string into internal representation, an application can treat IP addresses, netmasks and inverse masks identically. We all know that the Internet is awash in homegrown scripts written in PERL or TCL or bash or Ruby or Python. It is likely that many authors have, in the past 15 years, written scripts which contain regular expressions like "[0123456789.]*" to match a string containing only digits and the period. Those scripts will be confused by this AS number notation. Also, any script which "recognizes" IP address-like objects when it hits the first period in a numeric string. The real question is what does the notation 1.0 add that the notation 65536 does not provide? All I can see is that it adds the risk of broken scripts and the confusion of AS numbers that look like decimal numbers. If the IETF had really wanted to create a universal notation then they should have recommended that AS numbers be represented in the form AS65536 which is completely unambiguous. When IP addresses were created, it was important to indicate the boundaries between the network number and the host address. Originally, the periods represented this boundary for the three classes of IP address, class A, class B and class C. Long ago, we removed this classfulness attribute, but the notation remains because lots of applications expect this notation. So why on earth are we changing AS number notation today? --Michael Dillon
At 9:44 +0100 10/10/06, Michael.Dillon@btradianz.com wrote:
It breaks any applications which recognize IP address-like objects by seeing a dot in an otherwise numeric token.
I can't believe grown engineers are afraid of a dot.
We all know that the Internet is awash in homegrown scripts written in PERL or TCL or bash or Ruby or Python. It is likely
I find that more of a reason to do a change than to leave well enough alone. What's gonna happen when all of the current generation (the writers of the scripts) retire and close the door on their careers? How will the Internet live on? Shouldn't a technical beast be able to thrive on technical changes? But that question isn't germane to the issue at hand.
The real question is what does the notation 1.0 add that the notation 65536 does not provide?
Fair enough - my answer is it provides the same as the dotted quad for IP, it makes it easier for human to human conveyance. It also makes the transition from 2 byte to 4 byte more obvious in the interim.
If the IETF had really wanted to create a universal notation
The IETF "really" doesn't "want to create" anything. The IETF is just a forum where folks can gather to discuss an issue like this. (Pardon my second non-germane comment on this thread.)
When IP addresses were created, it was important to indicate the boundaries between the network number and the host address. Originally, the periods represented this boundary for the three classes of IP address, class A, class B and class C. Long ago, we removed this classfulness attribute, but the notation remains because lots of applications expect this notation. So why on earth are we changing AS number notation today?
For the same reason - to distinguish the boundaries between what the old engineers know from what the future young engineers will take for granted. The dot would outlast the old engineers just as the dotted quad persists into the CIDR age. "Why on earth?" Because there aren't [m]any IP addresses on the moon. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch.
On 2006-10-10 09:41:37, Edward Lewis wrote:
I can't believe grown engineers are afraid of a dot.
People have been burned in the past, and this leads them to exaggerate the cost. But even if the cost is not as large as they fear, it is not zero. If you are in favor of a new notation because you think it will save work overall by reducing confusion, or because you prefer it aesthetically, or because you want change for the sake of change in order to flush out old tools, then you should write up your arguments and get them included in the document. It would be much more efficient to explain the benefits once in the RFC, rather than a thousand times whenever someone complains that they don't like it. Whatever the benefits are, it's apparent from the thread here that many operators are not convinced, and that they have concerns that may not have been considered. Although this subject is relatively on-topic for NANOG, talking about it here is not going to have any effect on the draft. If you feel strongly about it, you should join the IDR or IESG lists. -- Shields.
participants (11)
-
bmanning＠karoshi.com -
David W. Hankins -
Edward Lewis -
Joe Abley -
Kevin Loch -
Michael Shields -
Michael.Dillon＠btradianz.com -
Neil J. McRae -
Randy Bush -
shields＠msrl.com
-
william(at)elan.net