Subject: Re: [Idr] Draft on the textual representation of AS Numbers

From: David Woodgate <[email-masked]>
Date: Fri, 22 Aug 2008 23:31:53 +1000

I'd like to point out that an ASDOT formatted AS number could allow 
functionality not easily achieved with ASPLAIN.

If you consider:

"2.570  2.1010  6.777  6.5  3.818  5.322"

then on the basis of IANA allocations to date you can immediately 
identify that the route has been sourced from an AfriNIC-allocated 
AS, and has transited through ASs allocated through RIPE, ARIN and 
APNIC. If you're prepared to make a loose association between the 
allocating RIR and the region of use, then you could take this path 
as an indication that the route is likely to have been sourced in 
Africa, and has then been announced through Europe, North America and 
the Asia-Pacific. Such information could be useful in diagnosis.

Further, such formatting would allow regexp expressions to be applied 
to ASs by allocating region - e.g. 6\.[0-9]+ would represent ASs 
allocated by ARIN. Some operators may find this useful in traffic engineering.

In comparison, the same AS path in ASPLAIN is:

"131642  132082  393993  393221  197426  328002"

To my mind, it neither conveys the RIR information as readily as the 
ASDOT format, nor can it easily be used for identifying 
RIR-allocations in regexps.

I suspect other functionality could emerge as well from a formatted 
AS number, and I think that the use of ASPLAIN would miss future 
opportunities of this type. (If it's too hard to introduce a format 
now - before 4-byte ASs have actually been used - then it will 
certainly be too hard to change it once adoption has happened.) I 
also observe that ASPLAIN would leave AS numbers as the only 4-byte 
attribute in the Internet (at least, that I can think of) without any 
structured formatting.

However, having said all of this, I recognise that it may be the case 
that it is already too late to change because of the large legacy of 
systems and practices adopted over the past 15 years, and that this 
may force us to adopt ASPLAIN.

Regards,

					David Woodgate

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Brian Dickson <[email-masked]>
Date: Fri, 22 Aug 2008 10:00:55 -0400

> functionality not easily achieved with ASPLAIN.

The point of the proposal, and as indicated in the taxonomy (asplain, 
asdot, asdot+), these are *decimal* (base-10) representations.

Splitting the 32-bit value into two 16-bit values both creates structure 
where there is none, and mixes base-10 with base-2 (or base 2^n) schemes.

I'd suggest that rather than arguing for asdot/asdot+, if you want to 
introduce structure, that it be exclusively on both a representation and 
structure basis.

I.e.,  that the base for the representation also be 2^n, such as binary 
or hexadecimal. The additional benefit to this would be no need for a 
delimiter.

But... (see below)

> allocated by ARIN. Some operators may find this useful in traffic 

The draft talks about places where a single standard for representation 
(on *input* and *output*) benefits the user base.

However, on things that are neither input nor output, *such as regexps*, 
there is no need to restrict usage to decimal methods.

For example, it would still be acceptable to build regexps (and regexp 
processing rules) that match the *content*, rather than the 
*representation*, via other number bases, such as:

0x???2???? (to match what in asdot+ would be 2.*)

BTW - in case it wasn't already clear, I too endorse ASPLAIN.

Brian Dickson

---

From: Larry Blunk <[email-masked]>
Date: Fri, 22 Aug 2008 10:52:04 -0400

David Woodgate wrote:
> identify that the route has been sourced from an AfriNIC-allocated AS, 
> and has transited through ASs allocated through RIPE, ARIN and APNIC. 
> If you're prepared to make a loose association between the allocating 
> RIR and the region of use, then you could take this path as an 
> indication that the route is likely to have been sourced in Africa, 
> and has then been announced through Europe, North America and the 
> Asia-Pacific. Such information could be useful in diagnosis.
>

    My assumption is that the existing 16-bit
numbers will be with us for many years to come and thus
one will not be able to rely on such filtering or visible
cues in the AS path in any meaningful way.

-Larry Blunk

---

From: David Woodgate <[email-masked]>
Date: Sun, 24 Aug 2008 17:51:42 +1000

At the moment, an AS number is formally a simple identifier of an 
abstract entity known as an autonomous system. In practice, AS 
numbers as deployed in the Internet represent companies and 
especially ISPs. If that is the continuing intent, and no 
organisation of AS numbers is required, then ASPLAIN is the correct 
representation.

But the practical use of AS numbers in the Internet is as an optional 
secondary routing attribute, used to govern policy filtering where 
desired. If it is acknowledged that that is a valid use of AS 
numbers, then any more information that can be incorporated into an 
AS number would mean the greater the refinement of routing policy 
that can be applied. Attributes like geography, network capability, 
etc. could be deduced from the AS number if it were appropriately structured.

It it worth considering such structuring? I think that greatly 
depends on the expected growth of AS number use - if only 10,000 
4-byte AS numbers are ever going to be used, then probably not, but I 
suspect that if 1,000,000 4-byte ASs were considered likely then 
there would be reasons why structured ASs would be desirable for 
reasons of routing efficiency and management.

If we did implement a structured 4-byte AS number, it would be 
unusual in the Internet to not have a textual representation 
reflecting that, even though (as has been pointed out) it is not 
strictly necessary. (Consider the formatting used for addresses and 
BGP communities, as examples.)

So the point of this email and my previous one is to ask whether, if 
we endorse ASPLAIN, are we implicitly endorsing  that an AS number is 
only a simple undistinguished identifier, or do we wish to consider 
adding in elements of organisation and structure to AS numbers that 
may enhance their use as routing attributes, and which might be used 
to improve routing efficiency and management?

Note that in asking this I'm questioning the use of ASPLAIN rather 
than specifically endorsing ASDOT - it might be that a better 
representation might emerge if and when an AS-number structure had 
been determined.

Regards,

						David Woodgate

---

From: Richard A Steenbergen <[email-masked]>
Date: Sun, 24 Aug 2008 05:29:35 -0500

> reasons of routing efficiency and management.

The idea of doing something constructive with 32-bit ASNs other than 
simply extending the size of the field to an absurdly large number is not 
wholly without merit. The problem here is with the practical 
implementation of such a system, and whether it passes a cost:benefit 
value test.

The first problem is that the . character is pretty much the worst 
possible choice for a delimiter of two fields like this. The number of 
conflicts it introduces with practical-use systems like regexp, snmp, and 
OSS systems that interpret it as a floating point number as massive. 
Breaking compatibility with so many key systems would really need to 
introduce massive benefits to be worthy of implementation, and I don't 
think asdot is even close to meeting that test.

But even ignoring the delimiter problem, I'm not sure there is any 
significant value in trying to place a geographic structure on ASN 
allocations. An ASN has no geographic boundaries by its very nature, and 
even knowing what RIR it was allocated from has remarkably little to do 
with routing or routing policy. Besides, there is absolutely no reason 
that this needs to be aligned to 16 bit fields. You could accomplish the 
same goals by saying "hey ARIN, you allocate from 100000-199999, RIPE you 
allocate from 200000-299999, etc" without breaking established systems. 
Are you expecting 65535 RIRs or something? This just doesn't seem 
realistic.

If you really wanted to do something useful with a 32-bit ASN structure, 
the best use that comes to mind would be a 24.8 system giving 24 bits of 
unique entity identifier and 8 bits of autonomous systems in a traditional 
networking sense. For example, a registrant would get a unique 24 bit 
identifier from their RIR, and then use the last 8 bits to create up to 
256 individual ASNs for routing purposes. Think of it like giving everyone 
an automatic block of 256 ASNs, aligned on bit boundaries. Given the number 
of folks out there with multiple discrete networks and ASN allocation 
blocks, this seems like a much more productive structuring of the 32-bit 
space. I also don't think that anyone can make a reasonable argument that 
the current routing system is in any danger of successfully scaling to 
anywhere near 16 million ASNs, so the 24-bit space seems quite reasonable.

But honestly, I don't think even this passes the benefit:cost ratio test 
to implement. Providing structure to the ASN space is one of those things 
that sounds great in theory, but absolutely horrible in practice, and at 
the end of the day the network operators are the ones who have to live 
with the decision.  I think the operators have almost unanimously said 
"please don't introduce arbitrary delimiters into this field", and for 
good reason. Introducing structure into the allocation is fine (i.e. the 
ranges I listed above, etc), as long as it doesn't creep into the 
representation unnecessarily.

-- 
Richard A Steenbergen <[email-masked]>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 25 Aug 2008 10:18:55 -0400

> BGP communities, as examples.)

Such a problem would need to be addressed with a generic as-4byte
community anyway: These would have to go into an extended community.

Yakov,

Had you given any thought about asking IANA to reserve a code-point for
a generic 4 octet extended community as a direct analog to our current 2
octet general-use communities?  You currently are requesting points for
route-target and route-origin only.

-- Jeff

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 25 Aug 2008 08:25:45 -0700

Jeff,

> route-target and route-origin only.

I have no problems doing this.

Yakov.

---

From: David Woodgate <[email-masked]>
Date: Wed, 27 Aug 2008 13:22:05 +1000

Richard,

As one of the transit network operators, I am happy to consider 
changing formats if I can see appropriate long-term benefit in it (or 
the capability to avoid long-term problems).

As I've been implying though, I am comfortable with ASPLAIN if there 
is community agreement on the following assumptions:

- Fewer than 1,000,000 ASs will be required for the foreseeable 
future (at least several decades)
         - 650,000 ASs takes us to an average of ~1 AS per 10,000 people
         - 6.5M would be about 1:1000; I feel if we got to that ratio 
we should review the general routing model

- The complexity of transit AS interconnections remains comparable to 
current levels
         - I.e. Average AS Path length does got grow significantly, 
and most AS growth is in stub ASs

I'd be interested to hear from anyone who disagrees with (or just 
questions) those assumptions.

Regards,

                                                 David Woodgate

---

From: David Conrad <[email-masked]>
Date: Tue, 26 Aug 2008 20:46:53 -0700

David,

> questions) those assumptions.

I personally expect multi-homing to become much (MUCH) more prevalent  
in the future as people become more and more dependent on the Internet  
for basic infrastructure and hence, less tolerant of intermittent  
failures either at work or at home.

However, with that said, I don't have a strong opinion on ASDOT vs.  
ASPLAIN.  IANA went with ASDOT because (at the time) we thought the  
industry was heading in that direction.  It is a trivial matter for  
IANA to change (or even to support both in the IANA registries).  In  
fact, arbitrarily changing the AS registry is becoming a favorite  
pastime (as Geoff will readily attest :-)).

Regards,
-drc

---

From: David Woodgate <[email-masked]>
Date: Wed, 27 Aug 2008 17:00:08 +1000

Hi David,

Would you care to take a guess at how much more prevalent?

Currently, you (mostly) need to be an ISP to receive an AS - i.e. 
portable number space and two upstream providers. The only exceptions 
tend to be the largest businesses with strong Internet interests, or 
elements of Internet infrastructure (E.g. RIRs). I'm assuming that 
this situation is unlikely to change.

If that's true, that would mean that any substantial growth of 
(active) ASs would be likely to be driven by ISPs becoming smaller, 
rather than through greater use of ASs by non-ISPs. I'm hoping that 
ISPs (on average) don't become too "small" (whatever definition of 
small you'd like to use), and so there would be a natural limit on AS use.

Can you think of any scenarios in which ASs will start being used 
substantially by organisations other than ISPs (and so break the 
above assumption)? I'm hoping that we don't end up with dual 
providers per home! :-)

Regards,

                                                         David

---

From: David Conrad <[email-masked]>
Date: Wed, 27 Aug 2008 08:05:19 -0700

David,

This is largely (ok, completely) irrelevant to the discussion about AS  
notation.  I think it is a safe assumption that we won't see  
significant change in AS consumption patterns in the near term. Should  
there be significant change, it is likely it will require a more  
fundamental technology change as current routing technology is simply  
not capable of scaling.  And if there is a change in technology, the  
question of AS notation will likely be the least of the concerns.

However, with that said:

On Aug 27, 2008, at 12:00 AM, David Woodgate wrote:
> portable number space and two upstream providers.

You don't need to be an ISP.  All you need is to demonstrate a unique  
routing policy, which pretty much anyone who multi-homes can do.  The  
question becomes how prevalent will multi-homing become in the  
future.  As Internet connectivity becomes more and more of a basic  
infrastructure that people simply assume is always there, I personally  
think multi-homing will become much more common, becoming the norm  
rather than the exception.

> The only exceptions tend to be the largest businesses with strong  
> Internet interests, or elements of Internet infrastructure (E.g.  
> RIRs). I'm assuming that this situation is unlikely to change.

Given IPv4 depletion, deployment of more FTTH, WiMax, ether-over- 
powerline, "broadband wireless", etc., and increasing customer demand  
for true "always on" connectivity, I am supremely skeptical that the  
way things are now is the way things will be in (say) 10 years. When  
your home security system, your home monitoring system, all your  
entertainment, all your communications facilities, your lawn sprinkler  
control system, your pet food dispenser, your HVAC controls, etc.,  
etc., all _depend_ (not "make use of") Internet connectivity, I  
suspect people's tolerance for even momentary connectivity disruption  
will decrease to the point where people won't bat an eye about paying  
another $20/month. And that's just home users.

> I'm hoping that we don't end up with dual providers per home! :-)

You're already beginning to see this.  And you're not being nearly  
pessimistic enough -- think every cellphone-as-a-router-to-your-PAN  
bouncing between Wifi, WiMAX, UMTS, quantum entanglement based  
communications, x-ray laser, etc.  Fortunately, by then, the  
Singularity will have come and the (Internet connected) Global AI Hive  
Mind will handle everything for us.  I, for one, will welcome our new  
Internet-dependent overlords.

More seriously, we have been bitten over and over by assuming things  
will stay more-or-less the same, particularly when it comes to  
questions of scale.  The fact that the question of how to deal with 4  
byte AS numbers has come up is a perfect example.  How many times do  
we need to get bitten before we start assuming things grow beyond what  
we anticipate?

Regards,
-drc

---

From: Geoff Huston <[email-masked]>
Date: Thu, 28 Aug 2008 07:02:02 +1000

> there

well, every prediction of this form over the past decade or longer has  
been proved wrong. I see no reason why this prediction is any  
different from the rest and no reason why it will not suffer a similar  
fate.

>         - 650,000 ASs takes us to an average of ~1 AS per 10,000  

so what?

> we should review the general routing model

and the RRG's current work is therefore irrelevant?

> and most AS growth is in stub ASs

I have no idea of future routing use models and the implications. I  
wonder as to the particular nature of your unique insight that allow  
you to make such an assumption.

> questions) those assumptions.

These "assumptions" seem to be completely indistinguishable from many  
of the guesses about routing that have made in the past - so far some  
have held out, and some have been blown out of the water. 
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Geoff Huston <[email-masked]>
Date: Thu, 28 Aug 2008 07:03:11 +1000

> pastime (as Geoff will readily attest :-)).

constant practice makes perfect, as they say :-)

   Geoff

---

From: David Woodgate <[email-masked]>
Date: Thu, 28 Aug 2008 07:28:40 +1000

David,

At 01:05 AM 28/08/2008, David Conrad wrote:
>notation.

Actually, not quite - if we expect massive changes, then that could 
require additional information/structure in AS numbers in order to 
achieve the greater routing refinement that might be needed in a 
changed envionment, and that new structure may impact notation. But...

>I think it is a safe assumption that we won't see

If we (the community) are agreed on that, then ASPLAIN is fine for now.

>we need to get bitten before we start assuming things grow beyond what

This is why I'm asking these questions now - the introduction of 
4-byte ASs seemed like a good point at which to do so.

The fact that no one seems to see an issue in the near term 
recommends the use of ASPLAIN. In fact, it could be argued that if we 
do need to change later, that it would be easier to make that change 
from an unformatted number now to a formatted number later - by when 
we will actually know what is needed in the format  - rather than 
choosing a format now and finding we need to adopt another new format 
later because of incorrect guesses today.

This does assume though that the pattern of IANA allocations from a 
4-byte space is constrained in such a way that if we need to change 
notation later that we will be able to adequately partition (what 
will be by then) the legacy allocations to that point.

Should an upper limit be put on the AS number that can be assigned, 
at least for the time being? Or in other words, should the IETF 
reserve part of the 4-byte AS space on the basis of concerns of 
technology scaling?
If so, what should that reservation be? (E.g. Should ASs 1,000,000 
through to (2^32 -1) be reserved for now, so that the highest AS 
assignment would be 999,999 before an IETF review was required?)

Regards,

                 David

---

From: David Woodgate <[email-masked]>
Date: Thu, 28 Aug 2008 07:41:10 +1000

Geoff,

>you to make such an assumption.
I do not claim any special insight - I was simply stating the basis 
on which I am prepared to support ASPLAIN over ASDOT, and was seeking 
feedback on the extent to which the community agreed with that basis.

Regards,

                                                 David

---

From: Geoff Huston <[email-masked]>
Date: Thu, 28 Aug 2008 07:56:08 +1000

On 28/08/2008, at 7:41 AM, David Woodgate wrote:

> on which I am prepared to support ASPLAIN over ASDOT, and was  
> seeking feedback on the extent to which the community agreed with  
> that basis.

and such feedback was being provided from this particular member of  
the community, as you requested.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "tom.petch" <[email-masked]>
Date: Thu, 28 Aug 2008 13:49:25 +0200

----- Original Message -----
From: "David Conrad" <[email-masked]>
To: "David Woodgate" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 27, 2008 5:05 PM
Subject: Re: [Idr] Draft on the textual representation of AS Numbers

<snip>

> we need to get bitten before we start assuming things grow beyond what

Agree absolutely.

For example, AS usage might be affected by
- a new routing system as being discussed on the RRG (the obvious solution to
FIB growth is a two-tier system and some tentative proposals have suggested
something AS-like for the upper tier; that could be 1,000,000 AS)
 - IPv6; I don't know how, but I think that the consequences of the advent of
IPv6 will be surprising
 - ...
so assume 1,000,000 and that could still be too little.

And I do not see even-six digit numbers as easy to read, transcribe and input
accurately, I think that structure is needed at the level of eg 142421 or 133322
to reduce the risks of transcription error.

There is a risk that a structure will emerge as part of some future usage that
will make our 16+16 split inappropriate but the risk of transcription errors is
here now; we need that separator in the middle.

I agree too with the points about the period character being overloaded so in
that sense, I do not support either draft.

Tom Petch

---

From: Paul Jakma <[email-masked]>
Date: Fri, 29 Aug 2008 15:02:15 +0100 (BST)

On Thu, 28 Aug 2008, tom.petch wrote:

> And I do not see even-six digit numbers as easy to read, transcribe 
> and input accurately, I think that structure is needed at the level 
> of eg 142421 or 133322 to reduce the risks of transcription error.

We already have ways of spacing decimal digits to increase 
legibility. The exact details differ between locales, but I believe 
SI recognises ',' or '.' to group on 10^(3n) boundaries (one more 
popular with British-influenced locales, the other for the more 
francophilic locales):

 	142,421
 	142.421

Standard library routines exist to, at least, display numbers in such 
forms, in various languages.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
emissions from GSM-phones
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Fri, 29 Aug 2008 17:17:19 +0200

> -----Original Message-----
> > and input accurately, I think that structure is needed at 
> the level of 
> > eg 142421 or 133322 to reduce the risks of transcription error.
> 
> legibility. The exact details differ between locales, but I 
> believe SI recognises ',' or '.' to group on 10^(3n) 
> boundaries (one more popular with British-influenced locales, 
> the other for the more francophilic locales):
> 
>  	142,421
>  	142.421
> 
> Standard library routines exist to, at least, display numbers 
> in such forms, in various languages.
>

This may open another can of worms because e.g. RIR db will produce
output according to their locale while requester of such information may
have different locale. We'd then just substitute one problem with
another.

For me vanila ASPLAIN seems more appropriate. If we can manage to pass
telephone numbers from one person to another, should be able to handle
AS numbers too.

Kind regards,
iLya

---

From: Paul Jakma <[email-masked]>
Date: Fri, 29 Aug 2008 16:23:40 +0100 (BST)

On Fri, 29 Aug 2008, Ilya Varlashkin wrote:

> output according to their locale while requester of such 
> information may have different locale. We'd then just substitute 
> one problem with another.

Absolutely.

The comment had wetware in mind.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
It is illegal to drive more than two thousand sheep down Hollywood
Boulevard at one time.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: James Aldridge <[email-masked]>
Date: Fri, 29 Aug 2008 17:42:08 +0200

> have different locale. We'd then just substitute one problem with

Being British, to me those look like one hundred and forty two thousand, 
four hundred and twenty one and a fraction somewhere between one hundred 
and forty two and one hundred and forty three respectively.  Some of my 
colleagues would see these the other way around.

If you're going to split the two 16-bit halves of a 32-bit AS number using 
a dot (or in other locales, a comma) you risk interpreting these as 
fractional numbers.  Whatever they may look like, the 32-bit AS number 
represented as "142.421" is not the same as those represented by "142.4210" 
or "142.42100".  Similarly, "142.421", "142.0421" and "142.00421" probably 
do refer to the same 32-bit AS number.

James

---

From: "tom.petch" <[email-masked]>
Date: Sat, 30 Aug 2008 18:45:50 +0200

----- Original Message -----
From: "Paul Jakma" <[email-masked]>
Sent: Friday, August 29, 2008 4:02 PM
Subject: Re: [Idr] Draft on the textual representation of AS Numbers

> forms, in various languages.

Yes, I agree about visual presentation, but I was thinking of a slightly
different problem (and not expressing it clearly), namely about errors in verbal
communication, between organisations, between departments, between support staff
and customers.  For example, the
telcos I use recommend that the 11-digit phone numbers we have are stated both
5-6 and 4-3-4 and I know the confusion that can arise when a 5-6-speaker meets a
4-3-4-speaker:-(

If all numbers were six digit (or 12 digit) I think it would be easier if not
easy, it is the mix of lengths, in eg an ASPATH, that concerns me.

I think that one of the great inventions that helped the progress of IPv4 was
dotted decimal, so simple that it is under-rated.  I do not want long AS numbers
to be the experiment that demonstrates how great a convention dotted decimal is
:-)

Tom Petch

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 30 Aug 2008 20:56:41 -0400

> to be the experiment that demonstrates how great a convention dotted decimal is

I wasn't there and this is *complete* speculation:

Dotted quads make a lot more sense when your address space is class A, B
or C.  It's an obvious presentation of the classful breakdown.

The fact that it's a convenient shorthand is convenient but I suspect
coincidental.

Similarly, the community breakdown of AS:## is a nice breakdown since it
shows the structure.  An AS doesn't currently have structure and
probably shouldn't be broken down as if it does.

-- Jeff