Re: [sig-policy] prop--065: Format for delegation and recording of 4-byt
David Woodgate said the following on 20/8/08 13:02:
> I oppose prop-065 on the following grounds:
To help discussion, would you please explain how existing widely
deployed AS PATH regular expressions are going to work, given that "."
matches "any character".
The following construct is used frequently in traffic engineering
multihoming - I've used AS100 as an example:
^100_[0-9]+$
which matches AS100 and ASes immediately adjacent to AS100.
You'll have to rewrite this regexp as follows to get the same effect:
^100_([0-9]+\.([0-9]+))$
Would you be willing to offer resources to help the ISPs around the
world to rewrite their traffic engineering policies?
> - I believe that it is strongly desirable to promote a structured
> format for 4-byte AS numbers;
There is a nice structured format called a 32-bit integer. What's wrong
with that?
> - Although ASDOT is not an IETF standard at this time, it is in use
> now by all RIRs and IANA
Only because they started using it without consulting the industry. ;-)
The industry so far hasn't really cared as none of them have had 32 bit
ASNs or have had to wrangle with regexps.
> - The documentation by APNIC of AS numbers in ASDOT notation does not
> prevent the simple conversion and use of those numbers in ASPLAIN
> format by ISPs where required.
Correct. Do you think there will be any transcription errors when they
do so? If they are so likely to make mistakes using the standard 32-bit
notation, why won't they make mistakes converting AS2.4 in to AS131076?
> ASDOT is distinctive in its notation from that used for the other
> well-known 4-byte Internet resources - IPv4 addresses and BGP
> Communities.
You do regular expression matching on IPv4 addresses? BGP communities?
BGP communities gained the colon separator as it was useful for ISPs to
denote communities with ASN as the first 16 bits, and local policy for
the second 16 bits, as per RFC 1998. I can't see any useful reason for
denoting a 32-bit ASN with a "dot". All it does is break many ASN based
policies as implemented across the entire Internet. Why go to all the
effort of extending ASNs to 32-bit, and be backward compatible with
16-bit ASNs, to then go and throw it all away by introducing a
completely incompatible notation.
> An AS number in ASDOT notation therefore would be
> readily identified as such, where as an ASPLAIN number is not
> identifiable out of context. (Even though this has been the case for
> 2-byte ASs as well, I suspect that the small number of digits used in
> AS numbers allocated so far have made this less of an issue in the
> 2-byte world.)
AS 32768 has the same number of digits as AS 65537. Please explain.
> My personal experience with BGP communities was that working with a
> plain 32-bit number was awkward.
Fully agreed - but no one ever used them in 32-bit format. Convention
from the outset was with the colon format, as that's what the major ISPs
(mine included) required for the reasons I mentioned above.
> Although working with dual formats
> is also awkward, I would rather accept that as an issue of transition
> rather than accept the permanent issues (especially typos) that could
> accompany long-term use of long unformatted numbers.
Typos happen with colon separated communities too. ;-) I see them all
the time.
> Given that ASDOT has already been recognised (if not necessarily used
> or formally approved) quite widely within the Internet community, I
> think it would be a step in the wrong direction to start moving back
> from ASDOT to an unformatted number. I would instead prefer to see
> further efforts to progress either ASDOT or an alternative format
> towards a ratified standard and adopted in vendor OSs, etc.
I think you need to explain how AS-PATH regexps will work. I fully agree
that the dot is visually pleasing, but the practical reality is that it
is a major pain in the proverbial when it comes to operational reality. :-(
philip
--