Marius:
Coming back to the IP range/AS assignment:
IMHO there must and shall not be such a correspondence. An AS is used to group one or more subnets into an well, Autonomous System (AS), and it should support, based on network architecture and layout, a possible migration of subnets from/to a specific AS, without any changes in the peering structure. e.g. If there is a subnet with access via AS 1 it should be there. But if later this subnet will be reorganized, and lets say will be accessed via AS 2, it should be possible to move it to AS 2 without any change in the BGP peering. This is not possible using AS numbers generated from IPs.
The idea behind using the IP address to calculate the AS is to make sure that AS numbers are always unique, without having to use a registry and without having to coordinate. When there is more than one subnet, it does not matter which one is used to calculate the AS number. When the one that was used to calculate the AS is being moved, some care will be required so it is not used again for this purpose at the new site.
Up to now we only route to the "regional subnet" level and each region has only a single subnet, so there are no problems. If an additional subnet is added and then the original one is moved there could be problems, but this is not likely.
This whole thing can depend on local issues and policies, but it does not really matter how you do things locally as long as everyone uses the same method to generate the prefix of the number. I will stick to that E.212 thing as it uses only 3 digits and because others are already doing this. (if not, I would probably have removed the "44" digits and added 2 available digits at the end, as proposed by Robbie)
Rob
On 10.12.2015 at 19:34 CET Rob Janssen wrote:
Up to now we only route to the "regional subnet" level and each region has only a single subnet, so there are no problems. If an additional subnet is added and then the original one is moved there could be problems, but this is not likely.
Even if it would happen it would only cause the lack of reachability of network-parts in your country. This could be fixed locally quick and easy. Never ever it would (should) bother any traffic between other countries, that's good.
This whole thing can depend on local issues and policies, but it does not really matter how you do things locally as long as everyone uses the same method to generate the prefix of the number.
ACK
I will stick to that E.212 thing as it uses only 3 digits and because others are already doing this.
Sounds good. So let's see what we have up to now:
1.) private 32bit-ASN for 44/8 depending on E.212 country codes.
unique prefix for every country yes 42<mcc>xxxxx ASN space dependend on size of country on the go yes multi mccs for "big" ones already used by some countries yes YO PA LU* (* only proposal) mapable on internet-ASNs at edge yes --> see HamWan Group compatible to existing 16bit-ASNs yes --> European HAMNET compatible to existing hard-/software yes mikrotik, quagga, bird(?) total unique management in own ASNs yes within own 42<mcc>-Range allows different policies/registries yes every country decides allows automatic IP-dependend ASNs yes every country decides (PA) allows other methods for "generating" yes e.g. "klick a free ASN" allows integration of "old" 16bit yes --> European HAMNET allows integration of other 16bit yes no doubles --> mcc prefix Transfer 32bit through 16bit possible yet not verified for HAMNET Transfer 16bit through 32bit possible yet not verified for HAMNET
Anything else? Anyone out there who sees problems that could cause issues when using this thing worldwide in ampr.org?
Once more: This is dedicated only to internal bgp-routing, not for routing through internet.
73 de Egbert - DD9QP
Some comments on the point provided by Egbert, DD9QP:
- on the EU Hamnet, extant AS' are actually 32 bit with leading bits 0. The implementation which is used in the Mikrotik router is "New" BGP - LU has used initially 42x private AS' but now has its own real AS, 15780, nothing has changed in this case except peering definition - My router interoperates without issues with LU using 4222620001 while LU uses 15780 - both use MT equipment like the EU Hamnet - on the same time it uses old style peering with DE, without problems
I don't think that for implementing these AS numbering scheme, there is any need to change anything in the established 16bit-like BGP peers, except proper 32bit peer setup as they build up.
73s, Marius
Am 11.12.2015 um 08:36 schrieb Marius Petrescu:
(Please trim inclusions from previous messages) _______________________________________________ Some comments on the point provided by Egbert, DD9QP:
- on the EU Hamnet, extant AS' are actually 32 bit with leading bits 0.
The implementation which is used in the Mikrotik router is "New" BGP
That's correct. Only on userinterface asn with leading bits 0 show up as pseudo 16-bits. The same appears when you are configuring the mikrotik with doted notation e.g. 0.12345 This also ends up in showing 12345 to the userinterface, but internally it's using new-BGP.
- LU has used initially 42x private AS' but now has its own real AS,
15780, nothing has changed in this case except peering definition
- My router interoperates without issues with LU using 4222620001 while
LU uses 15780 - both use MT equipment like the EU Hamnet
- on the same time it uses old style peering with DE, without problems
I can confirm. I am peering with LX using old style, AS-path looks clean.
I don't think that for implementing these AS numbering scheme, there is any need to change anything in the established 16bit-like BGP peers,
ACK. Hopefully that would reduce some further testing to a very low level. At this moment we are just testing mixing old-style and 32bit-ASNs it between different countries. Thanks Marius and Jann DG8NGN for supporting this.
except proper 32bit peer setup as they build up.
I think thats the only thing we must take care of.
73s Egbert
Together with Jann, we just switched my peering with the Hamnet from 16bit to 32bit. It seems to work properly, without issues, so it seems the road is wide open.
Marius, YO2LOJ
Am 11.12.2015 um 11:09 schrieb Marius Petrescu:
(Please trim inclusions from previous messages) _______________________________________________ Together with Jann, we just switched my peering with the Hamnet from 16bit to 32bit. It seems to work properly, without issues, so it seems the road is wide open.
I am just looking into the as-path on several routers in EU-HAMNET. Your 32bit-ASN is showing up properly preceeded by the 16bit-ASN from traversing through the HAMNET-Routers. No problems at all for thie ment. 99 percent of the routers in EU-HAMNET are mikrotik. Perhaps we can hold this setup for a while or forever ;-) I know of Bernd at KIT Karlsruhe. He is doing BGP on some linux mashines using bird/quagga. I will notice him to throw an eye on this and tell wether he notices any issues but I think there won'nt be any.
73s Egbert
No problem. It will stay this way if no problems arise.
-----Original Message----- From: Egbert - DD9QP Sent: Friday, December 11, 2015 12:28 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] Proposal for allocation of AS numbers
... Perhaps we can hold this setup for a while or forever ;-) I know of Bernd at KIT Karlsruhe. He is doing BGP on some linux mashines using bird/quagga. I will notice him to throw an eye on this and tell wether he notices any issues but I think there won'nt be any.
...
On 11.12.2015 at 11:09 CET Marius Petrescu wrote:
Together with Jann, we just switched my peering with the Hamnet from 16bit to 32bit. It seems to work properly, without issues, so it seems the road is wide open.
It seems that you are absolutely right.
Meanwhile I temporarily injected some 32bit-Sites in between all of the 16bit-AS of EU HAMNET to have a full mixed-up Network. Indeed our mainly Rf-based EU HAMNET behaves exactly as the mixed setups, which are common on the internet for quite a long time.
Although there are some specials in the EU HAMNET. Internaly the ASes mainly use BGP-Confederation, OSPF or other routing mechanisms are existent but rare (depends on the size of an AS and number of links to peers). Even a totally mixed-up Config within an AS works perfectly in the whole net: 16bit-ASN with 32bit-ASN for iBGP-Confederation works as well (proofed at KIT Karlsruhe) as 32bit-ASN with oldstyle-16bit-Confederation inside (proofed by myself on other sites). No issues found on mikrotik, quagga, bird up to now. We don't need to talk about that any more.
So what the hell we are waiting for?
EU HAMNET has started thinking about using private 32bit-ASN quite some time ago. Diskussions in our regular meetings pulsed up since 32bit-ASN where available.
But what we always were missing up to now was an international proposal for all countries using the 44-Net and, of course, a common agreement for using that. It makes no sense when everyone is rolling out a different System without talking to others. Chances of crashing are high and planing isn't even worth the time.
Regardless wether there is a registry, policy, human- or computerbased IP-Net-to-ASN-Generator out there, we all have to respect one minimal policy to keep everything running in the future:
Don't use concurrent private-ASN-proposals in parallel! Everything else is left to the countries themselves.
For example: Using the 42<mcc>xxxxxx in all countries is fine. But if some country starts using eg 42<IP-OctetofCountryDeployment>xxxxx there is high risk to crash with:
Greece, Netherlands, Belgium, France, Monaco, Andorra, Spain, Hungary, Bosnia, Croatia, Serbia, Montenegro, Italy, Vatican, Romania, Switzerland, Czech Rep., Slovak Rep., Austria, United Kingdom, Denmark, Sweden, Finland, Lithuania, Latvia, Estonia, Russia, Ukraine
All of them have mcc-codes between 0 and 255.
Using 42<dxcc>xxxxx in parallel to 42<mcc>xxxxx would hurt even more countries worldwide (higher density of countries between 0-255 in dxcc). And vice versa...
Some people within EU HAMNET tend to join to the 42<mcc>xxxxx proposal.
Last five digits are free to use. That gives about 100000 (0 - 99999) ASNs per country with one single assignment in mcc. Bigger countries with more mcc get more ASNs.
The 42<mcc>xxxxx proposal would work ok on a worldwide basis and it is used already by some countries.
EU HAMNET as a community of 16 countries will sit together and find out how they plan to deal with that. The internal discussion about that has been started on our internal channels. There is no reason to hesitate because even today EU HAMNET is compatible with 32bit-ASN peering.
73s Egbert
On Fri, 11 Dec 2015, Egbert - DD9QP wrote:
Regardless wether there is a registry, policy, human- or computerbased IP-Net-to-ASN-Generator out there, we all have to respect one minimal policy to keep everything running in the future:
Don't use concurrent private-ASN-proposals in parallel!
Actually, not really. This is not the same problem as combining multiple private-IP zones that have overlapping addresses. This is a tagging issue - addresses aren't duplicated. As long as private tags are filtered/consolidated with normal ASNs at some border and continue to do so, even when the private ASN zones begin to touch, there really isn't that big of a problem. And when the need to deconflict ASNs actually does arise, renumbering ASNs at peering borders should not be anywhere near as painful as renumbering addresses throughout a network. Ie. the urgency to move everyone to a single universal private-AS (is that an oxymoron? :) ) numbering scheme seems a bit exaggerated.
Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com
An 11.12.2015 at 18:55 Antonio Querubin wrote:
Actually, not really. This is not the same problem as combining multiple private-IP zones that have overlapping addresses. This is a tagging issue - addresses aren't duplicated. As long as private tags are filtered/consolidated with normal ASNs at some border and continue to do so, even when the private ASN zones begin to touch, there really isn't that big of a problem. And when the need to deconflict ASNs actually does arise, renumbering ASNs at peering borders should not be anywhere near as painful as renumbering addresses throughout a network. Ie. the urgency to move everyone to a single universal private-AS (is that an oxymoron? :) ) numbering scheme seems a bit exaggerated.
Hi Antonio
down here we have a little silly adage:
Everything can happen but nothing must :-)
73s and always keep it simple and stupid ;-)
El 11/12/15 a las 17:13, Egbert - DD9QP escribió:
EU HAMNET as a community of 16 countries will sit together and find out how they plan to deal with that. The internal discussion about that has been started on our internal channels. There is no reason to hesitate because even today EU HAMNET is compatible with 32bit-ASN peering.
Hi Egbert and all,
Here Dani EA4GPZ speaking for the Spanish HAMNET, since I'm probably the most active person in there. I will however raise this ongoing discussion to my colleagues in case anyone wants to join in.
The 42<mcc>xxxxxx proposal sounds fairly reasonable to me, so let's see if there is some consensus for this among the EU HAMNET. In Spain we are in a good position for making the change to 32bit numbering, because we have currently few sites deployed, so the change will be easy.
I think that 32bit numbering is definitely the way to go if one looks to the near future. The current distribution of private 16bit ASN's used in the EU HAMNET is fine for countries such as Germany and Austria, which have plenty of sites, plenty of AS's and all their network infrastructure already built. For the time being, it's also fine for countries where this whole thing is just starting, such as Spain, because we have only very few sites. However, this won't be the case in the future if more people start joining in an many more sites are deployed.
73,
Dani EA4GPZ/M0HXM.
To avoid a world wide issue, it seems to me, in my ignorance, that it would be wise to use the latitude and longitude in your proposal for the 44Net, not unlike APRS uses.
For example DDD.ddd.DDD.ddd where D = Degrees, d = decimal degrees, listing Latitude first, Longitude second set.
That would save having a registry world wide, and the only coordination of use would be with your neighbors.
Which coordinates? Of the server, the router, the antenna, the point of the network farther to east or to west? How do you define the position of a network? The geometrical centum of the cabling or of the radio links? When you move a router to a new position will you change your AS? If you move to a new QTH will you change it also?
Let's get this clear: AS numbers represent a computer group, which may have multiple subnets, spanning possible over wide geographical areas, not an individual computer. For that we use IP addresses. It is a functional routing group, with nothing to do with IPs and positions. It is used just for plain routing, nothing else. And there is no need for each person to have an AS. It is not a computer identifier, it is a network group identifier, used to identify a path through the network to be used to reach that specific group, a path which gets propagated to all connected routers, so in the end everybody knows how to reach any other party.
So any numbering method would do, but from the point of view of a network engineer, a functional hierarchical approach is easier to manage, not a geographic one. Coincidentally, national allocations correspond somehow to functional zones, from a administrative approach. And the aim is to have a hierarchical scheme, to allow an easy to use management, not to be able to identify the user or the location of the network.
-----Original Message----- From: Patrick Ryan KC6VVT Sent: Friday, December 11, 2015 21:54 To: AMPRNet working group Subject: Re: [44net] Proposal for allocation of AS numbers
(Please trim inclusions from previous messages) _______________________________________________ To avoid a world wide issue, it seems to me, in my ignorance, that it would be wise to use the latitude and longitude in your proposal for the 44Net, not unlike APRS uses.
For example DDD.ddd.DDD.ddd where D = Degrees, d = decimal degrees, listing Latitude first, Longitude second set.
That would save having a registry world wide, and the only coordination of use would be with your neighbors.
As an additional observation:
No one hosting a single subnet, with a single gateway interface (speak a single connectivity provider) will ever need an AS. Unless you have 2 or more connection possibilities, the classic routing is sufficient, since your subnet will happily be incorporated into the AS of your upstream, BGP routing giving you no advantage at all.
Hi,
The E.212 MCC proposal seems good to me, the arguments are good. A few further (less significant) arguments:
* There is a precedent: MCC is used in amateur radio DMR (MotoTRBO & friends) ID allocations in the DMR-MARC network as the country prefix for station IDs (in a DMR network, each user needs an unique 24-bit "phone number").
* I would guess the E.212 MCC numbering is pretty well carved in stone (for currently existing countries, anyway), and outlive the DXCC country code numbering.
* The DXCC list is being maintained for the purpose of DX hunting and QSL validation for awards. The E.212 MCC list is being maintained for the purpose of managing unique network addressing.
On Fri, 11 Dec 2015, Egbert - DD9QP wrote:
I will stick to that E.212 thing as it uses only 3 digits and because others are already doing this.
Sounds good. So let's see what we have up to now:
1.) private 32bit-ASN for 44/8 depending on E.212 country codes.
unique prefix for every country yes 42<mcc>xxxxx ASN space dependend on size of country on the go yes multi mccs for "big" ones already used by some countries yes YO PA LU* (* only proposal) mapable on internet-ASNs at edge yes --> see HamWan Group compatible to existing 16bit-ASNs yes --> European HAMNET compatible to existing hard-/software yes mikrotik, quagga, bird(?) total unique management in own ASNs yes within own 42<mcc>-Range allows different policies/registries yes every country decides allows automatic IP-dependend ASNs yes every country decides (PA) allows other methods for "generating" yes e.g. "klick a free ASN" allows integration of "old" 16bit yes --> European HAMNET allows integration of other 16bit yes no doubles --> mcc prefix Transfer 32bit through 16bit possible yet not verified for HAMNET Transfer 16bit through 32bit possible yet not verified for HAMNET
Anything else? Anyone out there who sees problems that could cause issues when using this thing worldwide in ampr.org?
Once more: This is dedicated only to internal bgp-routing, not for routing through internet.
- Hessu, OH7LZB
Hi
As there was no more traffic in this thread the last days I think we can live with this.
But wait - it still comes much better than the E.212 MCC proposal!
The E.212 MCC proposal is a subset of the "List of data Country or geographical area codes in the X.121 recommendation of ITU-T. They are listed in "Annex J" pages 25-32. It can be downloaded for free here:
https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.121-200010-I!!...
Starting page for further information is here:
https://www.itu.int/rec/T-REC-X.121/en
What does this meen for our private ASN solution?
- Everything can still remain as we have discussed it here! - The numeric MCCs are still the same as the Country or geographical area codes in X.121. - There are a lot of countries with high densitiy of telco-networks that have even more "MCCs" as listed in the E.212 document. - This may correspond with density of radio amateurs in that countries.
Example:
In E.212 the netherlands are listed with MCC204. That would result in private ASN-range of 42204xxxxx for our solution/proposal. Next country listed in E.212 is Belgium with MCC206. What is with "MCC205"? This additionaly is listed in the X.121 document and there it is assigned to Netherlands.
That means that in our proposal the netherlands could have two ranges:
42204xxxxx and 42205xxxxx
France has 208-211, Spain has 214-215, Poland 260-261, Germany 262-265 and so on.
In document X.121 most of the "gaps" between the MCCs from document E.212 are filled and assigned to certain countries.
Many (bigger) countries can have just much more ASN-range when we base our proposal on the "data country or geographical area codes" in ITU-T X.121 recommendation.
Very nice ;-)
On 11.12.2015 at 22:39 CET Heikki Hannikainen wrote:
Hi,
The E.212 MCC proposal seems good to me, the arguments are good. A few further (less significant) arguments:
- There is a precedent: MCC is used in amateur radio DMR (MotoTRBO &
friends) ID allocations in the DMR-MARC network as the country prefix for station IDs (in a DMR network, each user needs an unique 24-bit "phone number").
- I would guess the E.212 MCC numbering is pretty well carved in stone
(for currently existing countries, anyway), and outlive the DXCC country code numbering.
I think you are right - especially taking ITU-T X.121 taking into account.
...
On Fri, 11 Dec 2015, Egbert - DD9QP wrote:
I will stick to that E.212 thing as it uses only 3 digits and because others are already doing this.
Sounds good. So let's see what we have up to now:
1.) private 32bit-ASN for 44/8 depending on E.212 country codes.
unique prefix for every country yes 42<mcc>xxxxx ASN space dependend on size of country on the go yes multi mccs for "big" ones already used by some countries yes YO PA LU* (* only proposal) mapable on internet-ASNs at edge yes --> see HamWan Group compatible to existing 16bit-ASNs yes --> European HAMNET compatible to existing hard-/software yes mikrotik, quagga, bird(?) total unique management in own ASNs yes within own 42<mcc>-Range allows different policies/registries yes every country decides allows automatic IP-dependend ASNs yes every country decides (PA) allows other methods for "generating" yes e.g. "klick a free ASN" allows integration of "old" 16bit yes --> European HAMNET allows integration of other 16bit yes no doubles --> mcc prefix Transfer 32bit through 16bit possible yet not verified for HAMNET Transfer 16bit through 32bit possible yet not verified for HAMNET
Transfer 32bit through 16bit possible verified for EU-HAMNET Transfer 16bit through 32bit possible verified for EU-HAMNET
I think there is nothing that should prevent us to change our proposal based on X.121 than on E.212.
73s de Egbert DD9QP
-
Antonio Querubin -
Dani EA4GPZ -
Egbert - DD9QP -
Heikki Hannikainen -
Marius Petrescu -
Patrick Ryan KC6VVT -
Rob Janssen