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...
- '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?
randy
Randy Bush wrote:
- 'Canonical representation of 4-byte AS numbers '
<draft-michaelson-4byte-as-representation-01.txt> as an Informational RFCand 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
Using '.' as a delimiter will be somewhat annoying when used in
regular expressions and likely to induce errors. Would '-' be a
better choice?
somehow we seem to have survived similar issues in IP quad
representation.
randy
> - 'Canonical representation of 4-byte AS numbers '
>
http://www.ietf.org/internet-drafts/draft-michaelson-4byte-as-representation-01.txt
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
> > - 'Canonical representation of 4-byte AS numbers '
> >
http://www.ietf.org/internet-drafts/draft-michaelson-4byte-as-representation-01.txt>
> 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.
Well, it will break an applications that considers everything
consisting of numbers and dots to be an IP address/netmask/inverse
mask. I don't think many applications do this, as they will then
treat the typo "193.0.1." as an IP address. It won't break applications
that check if there are exactly 4 numbers in the 0-255 range and 3 dots.
The alternative notation (x:y) is much worse in this respect. "x:y"
is something (a community string). "x.y" is not.
The real question is what does the notation 1.0 add that the
notation 65536 does not provide?
It is (for me, and I guess most other humans) much easier to read and
remember, just as 193.0.1.49 is easier to read and remember than
3238002993. It also reflects that on the wire there are two 16
bit numbers, rather than 1 32-bit number.
More important: I think it is a mistake to assume that using AS65536
will NOT break things:
1. If you are a 16-bit AS speaker (ASN16), then AS65536 is not just
the next one in the line, it is an AS that will have to be treated
differently. The code has to recognize it and replace it by the
transistion mechanism AS.
2. Just as people having used the regexps that you mentioned, I'm
also certain that people have used unsigned short int's or
signed long int's in their code.
In short, like it or not, you will have to check and update your tools
anyway.
If the IETF had really wanted
The IETF process is open and you can still comment on the issue.
Henk
Well, it will break an applications that considers everything
consisting of numbers and dots to be an IP address/netmask/inverse
mask. I don't think many applications do this, as they will then
treat the typo "193.0.1." as an IP address.
An application using "[0123456789.]*" will not break when it
sees the above typo. 193.0.1. *IS* an IP address-like object
and any existing code will likely report it as mistyped
IP address or mask.
It won't break applications
that check if there are exactly 4 numbers in the 0-255 range and 3 dots.
True, however my point is that I do not believe that all
existing applications do this. Therefore, changing their
input in an unexpected way will break them.
>The real question is what does the notation 1.0 add that the
>notation 65536 does not provide?It is (for me, and I guess most other humans) much easier to read and
remember, just as 193.0.1.49 is easier to read and remember than
3238002993. It also reflects that on the wire there are two 16
bit numbers, rather than 1 32-bit number.
In my experience, ISPs do not transmit numbers by phone calls
and paper documents. They use emails and web pages which allow
cut'n'paste to avoid all transcription errors. And I know of no
earthly reason why a general written representation needs to
represent the format of bits on the wire. How many people
know or care whether their computer is bid-endian or little
endian?
1. If you are a 16-bit AS speaker (ASN16), then AS65536 is not just
the next one in the line, it is an AS that will have to be treated
differently. The code has to recognize it and replace it by the
transistion mechanism AS.
And how is a special notation superior to
if asnum > 65535 then
process_big_as
else
process_little_as
In any case, people wishing to treat big asnums differently will need
to write new code so the dot notation provides them zero benefit.
2. Just as people having used the regexps that you mentioned, I'm
also certain that people have used unsigned short int's or
signed long int's in their code.
Typically ISPs are using apps written in higher level languages
which are more likely to treat integers as 32-bit signed quantities.
In any case, this is a length issue, not an issue of notation.
In short, like it or not, you will have to check and update your tools
anyway.
My point is that if we do NOT introduce a special notation
for ASnums greater than 65536, then tools only need to be
checked, not updated. If your tool was written by someone
who left the company 7 years ago then you might want to
do such checking by simply testing it with large as numbers,
not by inspecting the code. The dot notation requires that
somebody goes in and updates/fixes all these old tools.
--Michael Dillon
I don't agree with you but this is a valid argument. I suggest you
make it to the IESG before they decide.
Henk
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.
>My point is that if we do NOT introduce a special notation
for ASnums
>greater than 65536, then tools only need to be checked, not
updated. If
>your tool was written by someone who left the company 7
years ago then
>you might want to do such checking by simply testing it with
large as
>numbers, not by inspecting the code. The dot notation requires that
>somebody goes in and updates/fixes all these old tools.I don't agree with you but this is a valid argument. I
suggest you make it to the IESG before they decide.Henk
Yes, I agree too. Please make sure to introduce your proposal within time.
If you need some (virtual) signatures of supporters just ask on the list 
Gunther
Henk Uijterwaal wrote:
My point is that if we do NOT introduce a special notation
for ASnums greater than 65536, then tools only need to be
checked, not updated. If your tool was written by someone
who left the company 7 years ago then you might want to
do such checking by simply testing it with large as numbers,
not by inspecting the code. The dot notation requires that
somebody goes in and updates/fixes all these old tools.I don't agree with you but this is a valid argument. I suggest you
make it to the IESG before they decide.Henk
RFC2622 uses the following Flex macro for AS numbers --
INT [[:digit:]]+
ASNO AS{INT}
Note that this does not limit the length of the AS number. While
it's no guarantee that an RPSL tool wouldn't break with longer AS
numbers, it would seem less likely than with the "." notation.
-Larry Blunk
Merit
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.
I can't believe grown engineers are afraid of a dot.
they are not. but they have enough free time on their hands
to endlessly discuss a dot.
randy
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.
Well, it will break an applications that considers everything
consisting of numbers and dots to be an IP address/netmask/inverse
mask. I don't think many applications do this, as they will then
treat the typo "193.0.1." as an IP address.An application using "[0123456789.]*" will not break when it
sees the above typo. 193.0.1. *IS* an IP address-like object
and any existing code will likely report it as mistyped
IP address or mask.
Actually, most code will parse it as equivalant of 193.0.0.1.
Most of the IP address parsers I have encountered will do
zero insertion in the middle, such that 10.253 is parsed the
same as 10.0.0.253, 10.3.24 is parsed as 10.0.3.24, 192.159.8
is parsed as 192.159.0.8, etc. I'm not saying I think this is
necessarily good, but, it is the behavior observed.
The real question is what does the notation 1.0 add that the
notation 65536 does not provide?It is (for me, and I guess most other humans) much easier to read and
remember, just as 193.0.1.49 is easier to read and remember than
3238002993. It also reflects that on the wire there are two 16
bit numbers, rather than 1 32-bit number.In my experience, ISPs do not transmit numbers by phone calls
and paper documents. They use emails and web pages which allow
cut'n'paste to avoid all transcription errors. And I know of no
earthly reason why a general written representation needs to
represent the format of bits on the wire. How many people
know or care whether their computer is bid-endian or little
endian?
Your experience differs from mine. There are lots of situations
where ASNs are discussed on telephone calls and/or transcribed
to/from yellow stickies, etc.
As to matching bits on the wire, no, it's not necessary, but, it is
a convenient side-effect.
1. If you are a 16-bit AS speaker (ASN16), then AS65536 is not just
the next one in the line, it is an AS that will have to be treated
differently. The code has to recognize it and replace it by the
transistion mechanism AS.And how is a special notation superior to
if asnum > 65535 then
process_big_as
else
process_little_asIn any case, people wishing to treat big asnums differently will need
to write new code so the dot notation provides them zero benefit.
The dot notation is an improvement in human readability. It offers
no benefit to machines as they don't care as long as they have a good
parser for whatever notation is chosen. The notation is for the human
interface.
My point is that if we do NOT introduce a special notation
for ASnums greater than 65536, then tools only need to be
checked, not updated. If your tool was written by someone
who left the company 7 years ago then you might want to
do such checking by simply testing it with large as numbers,
not by inspecting the code. The dot notation requires that
somebody goes in and updates/fixes all these old tools.
So will the colon notation for IPv6 addresses.
Owen
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.
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.
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
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.
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