Dear All,
We are pleased to announce that the MIXP management committee appointed
Mr Ranveer Kumar as Chairman and Dr Amreesh Dev Phokeer as Vice-chair
for the MIXP management committee.
They were elected during the last management committee meeting dated
18th July 2022
The term for both position shall be for 1 year.
Congratulations to Mr Ranveer and Dr Amreesh!
--
Keessun Fokeerah
Secretariat
MIXP team
--
Mauritius Internet Exchange Point(MIXP)
w:http://www.mixp.org/
Here are the results of the recent MIXP election.
The election system allowed for each peer (ASN) to vote for up to
_*seven (7) individuals*_. The MIXP has *twenty-two (22) ASNs that
peer*, of which *nineteen (19) count as peers that are eligible to vote*
The networks that were considered ineligible to vote are networks that
are operated by the MIXP ops team, namely:
1.
AS 112 - this is a local copy of the AS112 project,
2.
AS 37324 - this is the MIXP route server ASN,
3.
AS 327821 - this is the MIXP route collector ASN / management
network ASN
Additionally, we were informed by the following peers that they would
not be voting:
1.
AS 3856 - Packet Clearing House
2.
AS 42 - Woodynet
*From a total of seventeen (17) expected voting networks*, fifteen (15)
networks voted. zero (0) were spoilt votes.
There were a total of ninety (90) names selected out of a possible one
hundred and five (105).
The candidates with the most votes, and thus elected to the MIXP
management committee are:
1.
Amreesh Phokeer (13)
2.
Eric Loos (9)
3.
Ganesh Ramalingum (6)
4.
Jason Leong Son (10)
5.
Nishal Goburdhan (14)
6.
Ranveer Seetaloo (13)
7.
Sharma Baljinder (6)
Congratulations to the newly elected management committee, and thank you
to all that participated to make our first ever open election, a success.
--
Keessun Fokeerah
MIXP team
--
Mauritius Internet Exchange Point(MIXP)
w:http://www.mixp.org/
Dear All,
The MIXP Secretariat is pleased to announce the following final
candidate slate for the seven (7) open seat on the MIXP Management
Committee 2022 - 2023.
1. Dr. Amreesh Phokeer
2. Mr. Bhaveshdeo Sreekeessoon
3. Mr. Eddy LAREINE
4. Mr. Eric Loos
5. Mr. Ganesh Ramalingum
6. Mr. Jason LEONG SON
7. Mr. Nishal Goburdhan
8. Mr. Ranveer Kumar Seetaloo
9. Mr. Ravi PUDARUTH
10. Mr. Sharma BALJINDER
11. Mr. Tejas Pagooah
12. Mr. Zaheer Ramjaun
The Biography of each candidate has been published at
https://www.mixp.org/#elections2022
This time the election will be conducted electronically; electronic
voting will start on Monday 13th June June 2022 at 10:00am(UTC) and
shall close on Monday 27 June 2022 at 10:00am(UTC).
Each MIXP peer shall receive an email from Helios with more details on
how to proceed with voting. Note that each peer will have an electronic
ballot where they can each vote for up to 7 persons to be on the
management committee.
For any queries or clarification, please contact the Nomination
Committee by email at election[at]mixp.org
--
Keessun Fokeerah
MIXP Secretariat
--
Mauritius Internet Exchange Point(MIXP)
w:http://www.mixp.org/
Dear All,
We experienced around 1 hour downtime on Friday 3 June 2022.
There has been a temporary fix until we drill down further on the root
cause.
Impacted peers where we note their BGP sessions went impacted during
this time-frame were 36868, 21351, 328728 and 327821
Summary:
* Downtime date: Friday 3 June 2022
* Duration: 1 hour
* Impact: around 100M traffic decrease on the MIXP fabric
* Root cause: Under investigation
We deeply regret any inconveniences this may have caused on your networks.
--
Keessun Fokeerah
MIXP team
--
Mauritius Internet Exchange Point(MIXP)
w:http://www.mixp.org/
Hello everyone,
The MIXP operates the community-run Internet exchange point, with the
management committee elected from the general Internet community. It is
now time to elect new members to the management committee. This is your
chance to contribute to the management and operations of the 100%
community operated IXP, to grow a better peering environment for
yourselves and the Internet community. Elected persons are natural
persons; ie. they do not have to be from a participating network at the
MIXP, nor from any particular geography, but should have a legitimate
interest in improving the peering landscape. (Note: However, only
peering networks are eligible to vote).
The committee usually meet online once a month, to set policy and
provide managerial oversight to the MIXP's operations. Committee members
may also jointly decide for meet in person.
Are you, or someone else at your organisation willing to stand as a
candidate for MIXP’s Management Committee for 2022?
If you'd like to suggest someone, or even nominate yourself, please
indicate as follows:
I'd like to suggest the following potential candidate:
Name:
Email address:
Organisation:
Have you checked if this person is willing? [ ] Yes [ ] Not yet
Alternatively, is there perhaps someone whom you think the MIXP team
should approach to potentially serve on the Management Committee?
I'd like to suggest the following potential candidate:
Name:
Email address:
Organisation:
Have you checked if this person is willing? [ ] Yes [ ] Not yet
If you feel up to the challenge, and want to contribute to the peering
community, please reply to election(a)mixp.org, by 16:00 MUT on 12 May 2022.
Kind regards,
Keessun Fokeerah
MIXP secretariat
--
Keessun Fokeerah
MIXP team
--
Mauritius Internet Exchange Point(MIXP)
w:http://www.mixp.org/
Dear MIXP participants.
I hope that you are all well. It has been a while since we last sent
out an update about MIXP activities, and we thought that it would be
useful to keep you updated on some of the work that has been happening
in the background.
#1 - 10Gb/s port availability
We’ve recently taken delivery of 2x 10Gb/s capable switches, courtesy of
a kind donation from our friends at INX-ZA in South Africa. We have
already integrated one of these into the MIXP fabric, and we are
thrilled to announce that we are ready to support peers that want to
upgrade their ports to 10Gb/s at the MIXP-RGC site, as from 4 April
2022. Ports at the MIXP are at no cost, thanks to sponsorships and
donations, so upgrading to a 10Gb/s port will continue to be free!
#2 - Sunset on copper, and multi-mode fibre ports.
As we move along the technology ladder, we need to be able to leave
legacy behind us. To that end, the MIXP will no longer be supporting
copper and multi-mode fibre ports. All future connections from peers
*MUST* be via single-mode fibre 1310nm. This will provide you with the
best long-term growth opportunities.
#3 - Upcoming maintenance
Two years ago, we implemented RPKI checking, and dropping of RPKI
invalid prefix announcements. We are now working on the next extension
to our route-server platform (anti dDOS techniques) and to make that
transition smooth, we would need to upgrade the route-server daemons at
the MIXP. Starting in two weeks, we’ll be migrating to new versions of
the existing software/daemons that support some of the features we’ve
identified that we need.
We are quite excited by this change for several reasons, and we’ll
announce more on the plans to implement anti dDOS techniques, as well as
some planned training that we would like to perform within the
community, so that you (the peers) can make the most of this important
feature.
#4 - Call for volunteers
The team that runs and build the infrastructure for the MIXP is purely
volunteer-led. We work in our spare time to keep the IX operational,
and to grow new services. We are a small group of dedicated volunteers,
that believe in peering, and the benefits that it can bring to the
Internet ecosystem in Mauritius. If you would like to be a part of this
dynamic team, and are willing to dedicate a few hours a month to making
the MIXP better, please write to us, mentioning your interest, and
skill-set.
#5 - Call for donations
As mentioned earlier, the MIXP is run at no-cost to participants, thanks
to ongoing sponsorship and donations. In order to continue to grow the
MIXP, and add additional services, we have need of several items that
would make the MIXP operations smoother. If you feel that the MIXP is
adding value to your network, and are willing to make a small in-kind
donation, please write to us at noc(a)mixp.org.
For the MIXP volunteer team,
Keessun.
--
Keessun Fokeerah
MIXP team
--
Mauritius Internet Exchange Point(MIXP)
w: http://www.mixp.org/
The MIXP has two route servers aka route reflectors. When a participant
peers with the route server, No traffic will be exchanged with the route
servers themselves, or their ASN. They just facilitate the exchange of
BGP updates.
We highly recommend that you set up session to either one to enable
prefixes and traffic exchange from any other participant who also has a
session to the route server, if your peering policy is open.
Please set up sessions to the following:
Route Server 1:
ASN: 37324
IPv4 Neighbour: 196.223.0.201
IPv6 Neighbour: 2001:43f8:270:d0d0::201
Route Server 2:
ASN: 37324
IPv4 Neighbour: 196.223.0.202
IPv6 Neighbour: 2001:43f8:270:d0d0::202
Route-collector/looking-glass service: Peering to this will never result
in any traffic exchange. This is meant purely for troubleshooting and
statistical purposes.
Peering sessions to the route collector server are publicly viewable
here: https://lg.mixp.org/
We strongly request you to set up a session for both IPv4 and IPv6, it
does not share any of your routes to anyone else nor provide you any
routing or traffic.
You are encouraged to keep the configuration and filters on this session
identical to your route-server and bilateral sessions, so that the
information in the looking glass is accurate.
Route Collector
ASN: 327821
IPv4: 196.223.0.199
IPv6: 2001:43f8:270:d0d0::199
For any additional support, please contact peering(a)mixp.org
MIXP technical volunteers
--
Keessun Fokeerah
MIXP team
--
Mauritius Internet Exchange Point(MIXP)
w: http://www.mixp.org/
FYI
-------- Forwarded Message --------
Subject: [zanog-discuss] Fwd: PCH Peering Survey 2021
Date: Fri, 29 Oct 2021 14:58:43 +0200
From: Nishal Goburdhan via zanog-discuss <zanog-discuss(a)lists.nog.net.za>
Reply-To: Nishal Goburdhan <nishal(a)pch.net>
To: ZANog discuss <zanog-discuss(a)lists.nog.net.za>
[hat=PCH]
hi,
apologies if you’ve seen this on other lists already.
if you are a peering network, please take the time to complete this;
it’s a *really* quick survey, and the results are actually very useful
to researchers and policy makers. if you want to know how/why, you’re
welcome to ping me off-list (or read through the slides/listen to one of
the recording referenced below).
thanks in advance, for your support! :-)
-n.
Forwarded message:
> From: Bill Woodcock <woody(a)pch.net>
> Subject: PCH Peering Survey 2021
> Date: Fri, 29 Oct 2021 14:00:34 +0200
>
> Background:
>
> Five and ten years ago PCH conducted comprehensive global surveys
> characterizing Internet peering agreements. They are the only ones of
> their kind, and are relied upon by legislators and regulators
> throughout the world to understand the Internet interconnection landscape.
>
> Our write-ups of the prior surveys can be found here:
>
> https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2011…
> <https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2011…>
>
> https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2016…
> <https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2016…>
>
> …and video of the NANOG presentation of the 2016 results is here:
>
> https://www.youtube.com/watch?v=lPuoBmxyXMc
> <https://www.youtube.com/watch?v=lPuoBmxyXMc>
>
> At the time of the 2011 survey, we committed to repeating the survey
> every five years, to provide time-series data about the direction
> peering trends take. We’re now conducting the third iteration of the
> survey.
>
> Among other things, the surveys have helped establish a better
> understanding of trends in:
>
> • The increasingly uniform global norms of interconnection
> • National preferences within the network operator community for
> country of governing law
> • The long tail of small networks which don’t yet support IPv6 routing
> • The significance of multilateral peering agreements in the density
> of the interconnection mesh
>
> These findings, particularly the first, have been invaluable in giving
> regulators in the vast majority of the world’s countries a data-driven
> basis for refraining from prescriptively regulating Internet
> interconnection. They have demonstrated in objective terms that the
> Internet self-regulates in a way that’s more globally uniform and
> closely harmonized than any coordination of national regulatory bodies
> could accomplish.
>
> Participation:
>
> The survey is global in scope, and our goal is to reflect the
> diversity of peering agreements in the world. Your participation
> ensures that your norms and ways of doing business are represented
> accurately and proportionately in the dataset. If you don’t
> participate, the way you do business will be less well-represented in
> the data, and will seem less normal to regulators and policy-makers.
> We’re interested in large ISPs and small ISPs, ISPs in Afghanistan and
> in Zimbabwe, bilateral agreements and multilateral, private and
> public. Our intent is to be as comprehensive as possible. In 2011, the
> responses we received represented 4,331 networks in 96 countries, or
> 86% of the world’s ISPs at that time. In 2016, responses represented
> 10,794 networks in 148 countries, or 60% of the world’s ISPs in 2016.
> Our aim is to be equally inclusive this year.
>
> Since our principal method of soliciting participation is via NOG
> mailing lists, I’m afraid many of you will see this message several
> times, on different lists, for which we apologize.
>
> Privacy:
>
> In 2011 and 2016, we promised to collect the smallest set of data
> necessary to answer the questions, to perform the analysis
> immediately, and not to retain the data after the analysis was
> accomplished. In that way, we ensured that the privacy of respondents
> was fully protected. We did as we said, no data was leaked, and the
> whole community benefited from the trust that was extended to us. We
> ask for your trust again now as we make the same commitment to protect
> the privacy of all respondents, using the same process as was
> successfully employed the last two times. We are asking for no more
> data than is absolutely necessary. We will perform the analysis
> immediately upon receiving all of the data. We will delete the data
> once the analysis has been performed.
>
> The Survey:
>
> We would like to know your Autonomous System Number, and the following
> five pieces of information relative to each other AS you peer with:
>
> • Your peer’s ASN (peers only, not upstream transit providers or
> downstream customers)
> • Whether a written and signed peering agreement exists (the
> alternative being a less formal arrangement, such as a "handshake
> agreement")
> • Whether the terms are roughly symmetric (the alternative being that
> they describe an agreement with different terms for each of the two
> parties, such as one compensating the other, or one receiving more or
> fewer than full customer routes)
> • Whether a jurisdiction of governing law is defined
> • Whether IPv6 routes are being exchanged (this year, we’ll still
> assume that IPv4 are)
>
> The easiest way for us to receive the information is as a tab-text or
> CSV file or an Excel spreadsheet, consisting of rows with the
> following columns:
>
> Your ASN: Integer
> Peer ASN: Integer
> Written agreement: Boolean [true,1,yes,y] or [false,0,no,n]
> Symmetric: Boolean [true,1,yes,y] or [false,0,no,n]
> Governing Law: ISO 3166 two-digit country-code, or empty
> IPv6 Routes: Boolean [true,1,yes,y] or [false,0,no,n]
>
> For instance:
>
> 42 <tab> 715 <tab> false <tab> true <tab> us <tab> true <cr>
> 42 <tab> 3856 <tab> true <tab> true <tab> us <tab> true <cr>
>
> We need the ASNs so we can avoid double-counting a single pair of
> peers when we hear from both of them, and so that when we hear about a
> relationship in responses from both peers we can see how closely the
> two responses match, an important check on the quality of the survey.
> As soon as we've collated the data, we will protect your privacy by
> discarding the raw data of the responses, and only final aggregate
> statistics will be published. We will never disclose any ASN or any
> information about any ASN.
>
> If you’re peering with an MLPA route-server, you’re welcome to include
> just the route-server’s ASN, if that’s easiest, rather than trying to
> include each of the peer ASNs on the other side of the route-server.
> Either way is fine.
>
> If all of your sessions have the same characteristics, you can just
> tell us what those characteristics are once, your own ASN once, and
> give us a simple list of your peer ASNs.
>
> If your number of peers is small enough to be pasted or typed into an
> email, rather than attached as a file, and that’s simpler, just go
> ahead and do that.
>
> If you have written peering agreements that are covered by
> non-disclosure agreements, or if your organizational policy precludes
> disclosing your peers, but you’d still like to participate in the
> survey, please let us know, and we’ll work with whatever information
> you’re able to give us and try to ensure that your practices are
> statistically represented in our results.
>
> If you're able to help us, please email me the data in whatever form
> you can. If you need a non-disclosure, we're happy to sign one.
>
> Finally, if there are questions you’d like us to try to answer when we
> analyze the data, please suggest them, and if there are any additional
> questions you’d like us to include in future iterations of the survey,
> please let us know so that we can consider including them in the 2026
> survey.
>
> Please respond by replying to this email, by the middle of November,
> two weeks from now.
>
> Thank you for considering participating. We very much appreciate it,
> and we look forward to returning the results to the community.
>
> -Bill Woodcock
> Executive Director
> Packet Clearing House
_______________________________________________
zanog-discuss mailing list
zanog-discuss(a)lists.nog.net.za
https://lists.nog.net.za/cgi-bin/mailman/listinfo/zanog-discuss
Colleagues,
I have some good news from the tech team. We’ve recently received a
donation of two new servers from the Internet Society to help provide
additional services at the MIXP. We are now ready to incorporate these
into our setup, so that we can start serving you better.
To start, we will be using these to provide resiliency for the BGP route
server (BGP-RS) service that the MIXP provides. So, this weekend, we’re
going to move RS1 to one of the servers on the new cluster. We’re going
to use the time to do some system maintenance as well (new kernel
updates), so you will see a brief outage to your BGP-RS and BGP-RC
(route collector) sessions, whilst we reboot and upgrade these.
Of course we’ll do this carefully, and only one at a time, so no actual
traffic flow should be interrupted, even though you will see the BGP
sessions reset.
We have some other great tools that we will adding to our setup. More
on this to follow.
For now, please take note that during the time period 01h00 UTC on
Saturday 7 Nov you can expect to see the BGP sessions mentioned above
reset.
If you have any questions, or suggestions, please feel free to teach out
to the techical team via noc(a)mixp.org.
Regards,
--
Keessun Fokeerah
MIXP team
--
Mauritius Internet Exchange Point(MIXP)
w: http://www.mixp.org/
Hi All,
The MIXP has taken a further step in helping to reduce the potential for
routing abuse, by digitally signing the network prefixes that it uses
for operating the IXP in Mauritius. This is part of its ongoing
programme to grow and foster best practices in IXP management, and
teaching networks best peering practices.
RPKI is a mechanism for cryptographically signalling which Internet
network (or, in technical terms, which origin autonomous system) is
allowed to publish a routing statement for a block of IP addresses.
This is one of the techniques that has become widespread to help combat
some of the attempts at hijacking network address space; a very real
problem that exists on the Internet, and one that is likely going to get
worse, as it becomes more and more difficult to get additional IPv4
address space.
Three weeks ago, the MIXP took the important step of dropping all
routing announcements, that are considered to be a violation of this
policy, that go through the MIXP routing infrastructure. We did this,
after research into the networks prefixes that are announced at the
MIXP, and after working with participating domestic operators to clean
up their networks.
Over the past week, the MIXP team signed the network prefixes (IP
addresses) that we use for the MIXP infrastructure. This means that any
well-run network, that participates in using RPKI, will automatically be
immune to routing hijacks for the MIXP address space, and is considered
global best practice. The MIXP team is hoping to encourage more network
operators in Mauritius to start using RPKI, and hopes to start running
training classes on this soon.
During this process, we uncovered a bug in the AFRINIC RPKI system, that
we are working with AFRINIC to resolve. This highlights, the need for
operators to “get their hands dirty” with newer technologies, so that
they earn confidence, and make sure that the supporting systems around
this, are built to scale, and support operator needs.
--
Keessun Fokeerah
MIXP team
--
Mauritius Internet Exchange Point(MIXP)
w: http://www.mixp.org/