Unfortunately my mail connection broke down for a few hours shortly after I posted my proposal, so I missed most of the replies in my mail. I am now replying based on the archive, but this means it is difficult to quote your messages.
Robbie: that is a good point. In my design I anticipated that one would not want to route a smaller network than a /24, but in fact that could happen in the AMPRnet. The reason I put the 44 in the AS number is to reduce the probability that an AS would collide with another private AS allocated using a different system. However, it of course uses precious space. See below.
Marius: that is interesting. This is exactly the kind of response I hoped for, as I prefer to use a method that is already established rather than inventing my own. I found it appealing that the subnet address can be seen and recognized, these E.212 codes are obscure to me (but probably not to the person who invented this method). This method leaves 5 digits within the country range, which allows for smaller subnets as Robbie proposed. I see one problem: because there is no 1:1 mapping between E.212 code and AMPRnet /16 subnet, it will not always be possible to directly number the AS from the subnet. For typical European countries it will work well, but for the USA there is a "problem" because there are many more /16 subnets allocated to them than there are E.212 codes. Of course there are still more than enough AS numbers, but it means they need to use some registry instead of a direct derivation of the number.
Pedja: as mentioned early in the message, these AS are not for use on the public internet but only on our private radio network. Gateways between radio and internet are supposed not to be running BGP across them, or to filter the private AS and send out the routing under their public AS. That is already happening.
It looks like I will modify the system to look like this for our local use (and others are welcome to follow it: 42eeexxxyy where eee is the E.212 code, xxx is the third octet of the IP address, and yy is a local sequence number 00-99 in cases where multiple AS exist in that subnet. So for 44.137.40.0/22 it will be 4220404000 (204 is the E.212 code for the Netherlands which has 44.137.0.0/16) When I would want an AS for my personal subnet 44.137.41.96/28 it could be 4220404096 or some other arbitrary 42204040xx number. (for now, we only route to the regional subnets level)
In my opinion, it is less easy to read than the first proposal, but of course it has the advantage of more AS space within the local area, and the fact that it is already established in some places. That is an important advantage.
Rob
On Wed, 9 Dec 2015, Rob Janssen wrote:
Of course there are still more than enough AS numbers, but it means they need to use some registry instead of a direct derivation of the number.
Thank you, there has been a registry for this kind of thing: :)
whois -h 44.4.64.10 -p 4321 44.24.241.98
Tim Osburn http://www.m2os.com W7RSZ / JG1MBR
The E.212 mobile network codes (MNC) are well established and assigned by ITU. They are the codes used by mobile phone operators to uniquely identify their networks world wide. Unfortunately, official ITU document access cost money so no direct link is available on www.itu.int https://en.wikipedia.org/wiki/Mobile_country_code
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.
And another issue. An subnet or user does not need a individual AS number as long as it/he does not have more than 1 gateway. The subnet is part of an AS at a higher level. In this case, having MNC codes 310 to 316 assigned to the US, this will give 16000 possible AS numbers, which I think are more then enough:
42 310 xx xxx United Stated of America 42 311 xx xxx United Stated of America 42 312 xx xxx United Stated of America 42 313 xx xxx United Stated of America 42 314 xx xxx United Stated of America 42 315 xx xxx United Stated of America 42 316 xx xxx United Stated of America
Regarding peering with subnets that are already part of an extant public AS, there are no problems, they just use their public AS and that's it. If they like, they can just accept the needed private AS peers, and just discard them in their upper layer peering by a simple filter.
The fact that BGP subnets can be aggregated (confederated) simplifies peering even more. A group of AS' can be grouped together to appear as a single AS to its peer (in this case, the AS/IP naming hinders this even more).
Let's look at this example (myself): 42 226 00 000 BGP Conferderation Romania 42 226 2x xxx YO2, YP2, YQ2, YR2 42 226 20 001 YO2LOJ
Internaly in my network I have 2 AMPR subnets and 4 private IP subnets. I use 42 226 20 001 (spaces for easy reading) as my AS. Other networks in my area use 42 226 20 nnn as their AS. The connectivity between us would be ensured, so from a national POV the YO2 space will be agregated int a single AS, 42 226 20 000. The same can happen for other AS groups, so any peering between them can use 42 226 [2-9]0 000 In international peerings, since we can ensure our internal links, they may be one or more external peerings using all the agregated AS 42 226 00 000. And this will ensure redundancy for all subnets inside this space.
Marius, YO2LOJ
Correction: There are 70 000 AS' in that range
-----Original Message----- From: Marius Petrescu Sent: Thursday, December 10, 2015 10:16 To: AMPRNet working group Subject: Re: [44net] Proposal for allocation of AS numbers
... In this case, having MNC codes 310 to 316 assigned to the US, this will give 16000 possible AS numbers, which I think are more then enough:
42 310 xx xxx United Stated of America 42 311 xx xxx United Stated of America 42 312 xx xxx United Stated of America 42 313 xx xxx United Stated of America 42 314 xx xxx United Stated of America 42 315 xx xxx United Stated of America 42 316 xx xxx United Stated of America
1 digit (0-6) followed by 5 digits makes 700 000 ASNs according to my maths.
The e.212 has been borrowed from the CCS7 system in use for D-Star and DMR stations.
73 de Marc, LX1DUC
On 2015-12-10 09:45, Marius Petrescu wrote:
(Please trim inclusions from previous messages) _______________________________________________ Correction: There are 70 000 AS' in that range
-----Original Message----- From: Marius Petrescu Sent: Thursday, December 10, 2015 10:16 To: AMPRNet working group Subject: Re: [44net] Proposal for allocation of AS numbers
... In this case, having MNC codes 310 to 316 assigned to the US, this will give 16000 possible AS numbers, which I think are more then enough:
42 310 xx xxx United Stated of America 42 311 xx xxx United Stated of America 42 312 xx xxx United Stated of America 42 313 xx xxx United Stated of America 42 314 xx xxx United Stated of America 42 315 xx xxx United Stated of America 42 316 xx xxx United Stated of America
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 10.12.2015. 09:16, Marius Petrescu wrote:
The E.212 mobile network codes (MNC) are well established and assigned by ITU. They are the codes used by mobile phone operators to uniquely identify their networks world wide.
When I fist read this information about using these codes for ASN i thought it was odd. Why use mobile network codes when almost each country has several mobile network provider, meaning several network codes? That is confusing.
Why not using country codes, or even better, to stay in amateur radio, DXCC entity codes. That would provide single code for each country (or entity).
Current DXCC list is available at: http://www.arrl.org/files/file/DXCC/2015_Current_Deleted.txt
Pedja YT9TP
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
These MNCs use E.212 ITU country codes, which are formatted as a nice 3 digit number, ready to use, and perfectly fit the range after 42 in the private ASN numbering scheme.
You are right, every operator has a unique network number. But the first 3 digits are the country code (MCC) which we used for the AS'. The same codes are used in other communication system (including rose over ax.25 if I remember correctly).
Marius, YO2LOJ
-----Original Message----- From: Pedja YT9TP Sent: Thursday, December 10, 2015 11:04 To: AMPRNet working group Subject: Re: [44net] Proposal for allocation of AS numbers
(Please trim inclusions from previous messages) _______________________________________________ ...
When I fist read this information about using these codes for ASN i thought it was odd. Why use mobile network codes when almost each country has several mobile network provider, meaning several network codes? That is confusing.
...
In this case only the Mobile Country Code is used. Just like in CCS7 for D-Star and DMR stations.
(Yes, some countries have several Mobile Country Codes and some don't. I haven't done any research if the number of MNCs correlates to the size of the country/the population, so I don't say the system provides a faire distribution, but it comes closer than using 1 same length identifier for every country.)
Also incorporating the subnet into the ASN might not fly everywhere, as some border routers may announce several prefixes on behalf of other routers (not capable of BGP).
73 de Marc, LX1DUC
On 2015-12-10 10:04, Pedja YT9TP wrote:
(Please trim inclusions from previous messages) _______________________________________________
On 10.12.2015. 09:16, Marius Petrescu wrote:
The E.212 mobile network codes (MNC) are well established and assigned by ITU. They are the codes used by mobile phone operators to uniquely identify their networks world wide.
When I fist read this information about using these codes for ASN i thought it was odd. Why use mobile network codes when almost each country has several mobile network provider, meaning several network codes? That is confusing.
Why not using country codes, or even better, to stay in amateur radio, DXCC entity codes. That would provide single code for each country (or entity).
Current DXCC list is available at: http://www.arrl.org/files/file/DXCC/2015_Current_Deleted.txt
Pedja YT9TP
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
I found list of mobile network codes at http://www.mcc-mnc.com/
Now, when I saw the table, I realized that you maybe meant to use MCC (Mobile Country Code) not MNC (Mobile Network code).
From the perspective of usability, MCC is ok, but I would still vote to use DXCC entities, for few reasons:
- It is amateur radio de-facto standard for designating countries and it relates to every other aspect of amateur radio activities.
- DXCC entity codes are already well known to hams so they are familiar to use them.
- It follows amateur radio definition of "country" which is not the same as waht is used for MCC. It means amateur radio country may cover several MCC or, reversed, one MCC may cover several amateur radio countries.
- If you ever need to link data to other ham radio data sources, if you use DXCC entities that is easy task as other data sources to use DXCC as county designator. If you use MCC, you will have to provide mapping table and make sure it is updated all the time.
Pedja YT9TP
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
I am not so convinced that dxcc numbers are optimal. Because there is 1 single dxx entity for each country. So if you think that Market Reef or Heard Island will need the same amount of AS as the United States...
On 10.12.2015. 10:47, Marius Petrescu wrote:
I am not so convinced that dxcc numbers are optimal. Because there is 1 single dxx entity for each country. So if you think that Market Reef or Heard Island will need the same amount of AS as the United States...
It does not matter. There is a lot of never to be used space for country codes, anyways.
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
You mean E.212, they are accessible at the ITU site
https://www.itu.int/itudoc/itu-t/ob-lists/icc/e212_685.pdf
Bob VE3TOK
On 15-12-10 03:16 AM, Marius Petrescu wrote:
(Please trim inclusions from previous messages) _______________________________________________ The E.212 mobile network codes (MNC) are well established and assigned by ITU. They are the codes used by mobile phone operators to uniquely identify their networks world wide. Unfortunately, official ITU document access cost money so no direct link is available on www.itu.int https://en.wikipedia.org/wiki/Mobile_country_code
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.
And another issue. An subnet or user does not need a individual AS number as long as it/he does not have more than 1 gateway. The subnet is part of an AS at a higher level. In this case, having MNC codes 310 to 316 assigned to the US, this will give 16000 possible AS numbers, which I think are more then enough:
42 310 xx xxx United Stated of America 42 311 xx xxx United Stated of America 42 312 xx xxx United Stated of America 42 313 xx xxx United Stated of America 42 314 xx xxx United Stated of America 42 315 xx xxx United Stated of America 42 316 xx xxx United Stated of America
Regarding peering with subnets that are already part of an extant public AS, there are no problems, they just use their public AS and that's it. If they like, they can just accept the needed private AS peers, and just discard them in their upper layer peering by a simple filter.
The fact that BGP subnets can be aggregated (confederated) simplifies peering even more. A group of AS' can be grouped together to appear as a single AS to its peer (in this case, the AS/IP naming hinders this even more).
Let's look at this example (myself): 42 226 00 000 BGP Conferderation Romania 42 226 2x xxx YO2, YP2, YQ2, YR2 42 226 20 001 YO2LOJ
Internaly in my network I have 2 AMPR subnets and 4 private IP subnets. I use 42 226 20 001 (spaces for easy reading) as my AS. Other networks in my area use 42 226 20 nnn as their AS. The connectivity between us would be ensured, so from a national POV the YO2 space will be agregated int a single AS, 42 226 20 000. The same can happen for other AS groups, so any peering between them can use 42 226 [2-9]0 000 In international peerings, since we can ensure our internal links, they may be one or more external peerings using all the agregated AS 42 226 00 000. And this will ensure redundancy for all subnets inside this space.
Marius, YO2LOJ
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 9.12.2015. 23:02, Rob Janssen wrote:
Pedja: as mentioned early in the message, these AS are not for use on the public internet but only on our private radio network. Gateways between radio and internet> are supposed not to be running BGP across them, or to filter the private AS and send out the routing under their public AS. That is already happening.
That is clear, issues may happen if someone already uses private ASN numbers.
However, as your proposal is using long ASN with 44 prefix, I guess that minimizes chances to have collisions.
Pedja YT9TP
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus