10 Dec
2015
10 Dec
'15
12:34 p.m.
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
10 Dec
10 Dec
10:15 p.m.
New subject: Proposal for allocation of AS numbers
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
11 Dec
11 Dec
1:36 a.m.
New subject: Proposal for allocation of AS numbers
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
4:05 a.m.
New subject: Proposal for allocation of AS numbers
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
4:09 a.m.
New subject: Proposal for allocation of AS numbers
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
4:28 a.m.
New subject: Proposal for allocation of AS numbers
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
4:56 a.m.
New subject: Proposal for allocation of AS numbers
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(a)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.
...
11:13 a.m.
New subject: Proposal for allocation of AS numbers
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
11:55 a.m.
New subject: Proposal for allocation of AS numbers
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(a)lavanauts.org
xmpp: antonioquerubin(a)gmail.com
12:35 p.m.
New subject: Proposal for allocation of AS numbers
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 ;-)
12:53 p.m.
New subject: Proposal for allocation of AS numbers
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.
1:54 p.m.
New subject: Proposal for allocation of AS numbers
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.
2:52 p.m.
New subject: Proposal for allocation of AS numbers
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.
2:59 p.m.
New subject: Proposal for allocation of AS numbers
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.
3:39 p.m.
New subject: Proposal for allocation of AS numbers
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:
- Hessu, OH7LZB
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.
18 Dec
18 Dec
5 a.m.
New subject: Proposal for allocation of AS numbers
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
3264
days inactive
3272
days old
15 comments
7 participants
participants (7)
-
Antonio Querubin -
Dani EA4GPZ -
Egbert - DD9QP -
Heikki Hannikainen -
Marius Petrescu -
Patrick Ryan KC6VVT -
Rob Janssen