Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?

[Josh Reynolds]

I kinda feel the same way.  I wish FRR was a big more mature at this
point though.

On Mon, Jul 3, 2017 at 10:21 PM, Baldur Norddahl
 wrote:
> Why not use a Linux or BSD computer for this? It is cheap and you know
> exactly what you are getting. It will forward 10 gig at line rate at least
> for normal traffic.
>
> Regards
>
> Baldur
>
> Den 3. jul. 2017 21.08 skrev "Job Snijders" :
>
>> Dear NANOG,
>>
>> Some friends of mine are operating a nonprofit (on shoe string) and looking
>> to connect some CDN caches to an IX fabric. A BGP speaking device is needed
>> between the caches and the BGP peers connected to the fabric. The BGP
>> speaker is needed to present the peers on the IX with a unified view of the
>> assemblage of CDN nodes.
>>
>> I was wondering whether anyone was experience with the "EdgeRouter Infinity
>> XG" device, specifically in the role of a simple peering router for a
>> couple of tens of thousands of routes. (I'd point default to the left and
>> take just the on-net routes on the right to reduce the table size
>> requirement).
>>
>> I hope the device can do at least 2xLACP trunks, has a sizable FIB, is
>> automatable (supports idempotency), can forward IMIX at line-rate, *flow,
>> and exposes some telemetry via SNMP.
>>
>> Any note sharing would be appreciated!
>>
>> Kind regards,
>>
>> Job
>>

Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?

[Baldur Norddahl]

Why not use a Linux or BSD computer for this? It is cheap and you know
exactly what you are getting. It will forward 10 gig at line rate at least
for normal traffic.

Regards

Baldur

Den 3. jul. 2017 21.08 skrev "Job Snijders" :

> Dear NANOG,
>
> Some friends of mine are operating a nonprofit (on shoe string) and looking
> to connect some CDN caches to an IX fabric. A BGP speaking device is needed
> between the caches and the BGP peers connected to the fabric. The BGP
> speaker is needed to present the peers on the IX with a unified view of the
> assemblage of CDN nodes.
>
> I was wondering whether anyone was experience with the "EdgeRouter Infinity
> XG" device, specifically in the role of a simple peering router for a
> couple of tens of thousands of routes. (I'd point default to the left and
> take just the on-net routes on the right to reduce the table size
> requirement).
>
> I hope the device can do at least 2xLACP trunks, has a sizable FIB, is
> automatable (supports idempotency), can forward IMIX at line-rate, *flow,
> and exposes some telemetry via SNMP.
>
> Any note sharing would be appreciated!
>
> Kind regards,
>
> Job
>

Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?

[Josh Reynolds]

EdgeOS was forked and employees were poached from Vyatta before it was
purchased by Broadcom, when it was open source.  I think a few things
came down from VyOS after that, but not many.

On Mon, Jul 3, 2017 at 9:28 PM, Hugo Slabbert  wrote:
>
> On Mon 2017-Jul-03 19:26:17 -0500, Josh Reynolds 
> wrote:
>
>> On Jul 3, 2017 7:23 PM, "Josh Reynolds"  wrote:
>>
>>> Specs...
>>>
>>>
>>>- MIPS64 16 Core 1.8 GHz
>>>- 16 GB DDR4 RAM
>>>- 8 MB NOR Flash 4 GB eMMC NAND Flash
>>>- Data Ports: (1) RJ45 Serial Port, (8) SFP+ Ports (1) RJ45 Gigabit
>>>Ethernet Port
>>>- 2 hotswap power supplies
>>>
>>>
>>> No LACP. ECMP is currently broken. MPLS/VPLS is currently broken and not
>>> done in hardware - this may eventually change. As far as the other stuff,
>>> "telemetry" etc - no.
>>>
>>> As far as BGP crunching, plenty of routes, etc - it would easily and
>>> happily be fine with that.
>>>
>>> As far as automation, it's a JunOS-like CLI originally based on vyatta,
>>> which AT now owns - and one of the main reasons is it's scriptability,
>>> use of Ansible and other tools right on the device, python, etc.
>
>
> Technically I believe it's based on VyOS rather than Vyatta.  Same base, but
> just delineating that VyOS is open source and I don't believe AT wields
> any control over it.
>
>>>
>>> - Josh
>>>
>
> --
> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> pgp key: B178313E   | also on Signal
>
>
>>> On Jul 3, 2017 2:09 PM, "Job Snijders"  wrote:
>>>
 Dear NANOG,

 Some friends of mine are operating a nonprofit (on shoe string) and
 looking
 to connect some CDN caches to an IX fabric. A BGP speaking device is
 needed
 between the caches and the BGP peers connected to the fabric. The BGP
 speaker is needed to present the peers on the IX with a unified view of
 the
 assemblage of CDN nodes.

 I was wondering whether anyone was experience with the "EdgeRouter
 Infinity
 XG" device, specifically in the role of a simple peering router for a
 couple of tens of thousands of routes. (I'd point default to the left
 and
 take just the on-net routes on the right to reduce the table size
 requirement).

 I hope the device can do at least 2xLACP trunks, has a sizable FIB, is
 automatable (supports idempotency), can forward IMIX at line-rate,
 *flow,
 and exposes some telemetry via SNMP.

 Any note sharing would be appreciated!

 Kind regards,

 Job

>>>
>

Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?

[Hugo Slabbert]

On Mon 2017-Jul-03 19:26:17 -0500, Josh Reynolds  wrote:


On Jul 3, 2017 7:23 PM, "Josh Reynolds"  wrote:


Specs...


   - MIPS64 16 Core 1.8 GHz
   - 16 GB DDR4 RAM
   - 8 MB NOR Flash 4 GB eMMC NAND Flash
   - Data Ports: (1) RJ45 Serial Port, (8) SFP+ Ports (1) RJ45 Gigabit
   Ethernet Port
   - 2 hotswap power supplies


No LACP. ECMP is currently broken. MPLS/VPLS is currently broken and not
done in hardware - this may eventually change. As far as the other stuff,
"telemetry" etc - no.

As far as BGP crunching, plenty of routes, etc - it would easily and
happily be fine with that.

As far as automation, it's a JunOS-like CLI originally based on vyatta,
which AT now owns - and one of the main reasons is it's scriptability,
use of Ansible and other tools right on the device, python, etc.


Technically I believe it's based on VyOS rather than Vyatta.  Same base, 
but just delineating that VyOS is open source and I don't believe AT 
wields any control over it.




- Josh



--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


On Jul 3, 2017 2:09 PM, "Job Snijders"  wrote:


Dear NANOG,

Some friends of mine are operating a nonprofit (on shoe string) and
looking
to connect some CDN caches to an IX fabric. A BGP speaking device is
needed
between the caches and the BGP peers connected to the fabric. The BGP
speaker is needed to present the peers on the IX with a unified view of
the
assemblage of CDN nodes.

I was wondering whether anyone was experience with the "EdgeRouter
Infinity
XG" device, specifically in the role of a simple peering router for a
couple of tens of thousands of routes. (I'd point default to the left and
take just the on-net routes on the right to reduce the table size
requirement).

I hope the device can do at least 2xLACP trunks, has a sizable FIB, is
automatable (supports idempotency), can forward IMIX at line-rate, *flow,
and exposes some telemetry via SNMP.

Any note sharing would be appreciated!

Kind regards,

Job





signature.asc
Description: Digital signature

Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?

[Josh Reynolds]

- Josh

On Jul 3, 2017 7:23 PM, "Josh Reynolds"  wrote:

> Specs...
>
>
>- MIPS64 16 Core 1.8 GHz
>- 16 GB DDR4 RAM
>- 8 MB NOR Flash 4 GB eMMC NAND Flash
>- Data Ports: (1) RJ45 Serial Port, (8) SFP+ Ports (1) RJ45 Gigabit
>Ethernet Port
>- 2 hotswap power supplies
>
>
> No LACP. ECMP is currently broken. MPLS/VPLS is currently broken and not
> done in hardware - this may eventually change. As far as the other stuff,
> "telemetry" etc - no.
>
> As far as BGP crunching, plenty of routes, etc - it would easily and
> happily be fine with that.
>
> As far as automation, it's a JunOS-like CLI originally based on vyatta,
> which AT now owns - and one of the main reasons is it's scriptability,
> use of Ansible and other tools right on the device, python, etc.
>
> - Josh
>
> On Jul 3, 2017 2:09 PM, "Job Snijders"  wrote:
>
>> Dear NANOG,
>>
>> Some friends of mine are operating a nonprofit (on shoe string) and
>> looking
>> to connect some CDN caches to an IX fabric. A BGP speaking device is
>> needed
>> between the caches and the BGP peers connected to the fabric. The BGP
>> speaker is needed to present the peers on the IX with a unified view of
>> the
>> assemblage of CDN nodes.
>>
>> I was wondering whether anyone was experience with the "EdgeRouter
>> Infinity
>> XG" device, specifically in the role of a simple peering router for a
>> couple of tens of thousands of routes. (I'd point default to the left and
>> take just the on-net routes on the right to reduce the table size
>> requirement).
>>
>> I hope the device can do at least 2xLACP trunks, has a sizable FIB, is
>> automatable (supports idempotency), can forward IMIX at line-rate, *flow,
>> and exposes some telemetry via SNMP.
>>
>> Any note sharing would be appreciated!
>>
>> Kind regards,
>>
>> Job
>>
>

Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?

[Jeremy Austin]

On Mon, Jul 3, 2017 at 2:44 PM, Seth Mattinen  wrote:

>
> EdgeRouter is... meh. If I was looking at that class of gear I'd go with a
> Mikrotik.


Job,

There is a bit of a price differential here, depending on whether you need
SFP+; the Infinity is "dead cheap", and has fairly opaque BGP
daemon+debugging tools. Also still technically a beta product. Not sure if
it meets your automation requirements. I wouldn't want to be deploying them
in a redundant pair, myself, but just when you say something can't be done…

Mikrotik's CCR1072: 10-gig router (shipping, not anything that's just been
announced) has an API, can certainly handle a few tens of thousands of
routes fine (single core BGP though), but I can't vouch for its ability to
do IMIX or *flow at line rate. This has probably been stress tested by
somebody. I doubt the sampling is in hardware.

If you don't need 10G ports then your options expand considerably. Do you
have a target throughput?

-- 
Jeremy Austin

(907) 895-2311 office
(907) 803-5422 cell
jhaus...@gmail.com

Heritage NetWorks
Whitestone Power & Communications
Vertical Broadband, LLC

Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?

[Seth Mattinen]

On 7/3/17 12:07 PM, Job Snijders wrote:

I was wondering whether anyone was experience with the "EdgeRouter Infinity
XG" device, specifically in the role of a simple peering router for a
couple of tens of thousands of routes. (I'd point default to the left and
take just the on-net routes on the right to reduce the table size
requirement).



EdgeRouter is... meh. If I was looking at that class of gear I'd go with 
a Mikrotik.


~Seth

Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?

[Mike Hammett]

I'm Ubiquiti's biggest critic. I'll check with my colleagues. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Job Snijders"  
To: nanog@nanog.org 
Sent: Monday, July 3, 2017 2:07:28 PM 
Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? 

Dear NANOG, 

Some friends of mine are operating a nonprofit (on shoe string) and looking 
to connect some CDN caches to an IX fabric. A BGP speaking device is needed 
between the caches and the BGP peers connected to the fabric. The BGP 
speaker is needed to present the peers on the IX with a unified view of the 
assemblage of CDN nodes. 

I was wondering whether anyone was experience with the "EdgeRouter Infinity 
XG" device, specifically in the role of a simple peering router for a 
couple of tens of thousands of routes. (I'd point default to the left and 
take just the on-net routes on the right to reduce the table size 
requirement). 

I hope the device can do at least 2xLACP trunks, has a sizable FIB, is 
automatable (supports idempotency), can forward IMIX at line-rate, *flow, 
and exposes some telemetry via SNMP. 

Any note sharing would be appreciated! 

Kind regards, 

Job 

Call for presentations RIPE 75 and DCTM info

[Benno Overeinder]

Dear colleagues,

Please find the CFP for RIPE 75 below or at:
https://ripe75.ripe.net/submit-topic/cfp/.

The deadline for submissions is *20 August 2017*.

Note: due to UAE law, confirmed speakers will need to submit a copy of
their passport and contact information in advance of the meeting.  More
details are available here:
https://ripe75.ripe.net/attend/dctm-requirements

Kind regards,

Benno Overeinder
RIPE PC Chair
https://ripe75.ripe.net/ripe-pc/

>>><<<

Call for Presentations

A RIPE Meeting is an open event where Internet Service Providers,
network operators and other interested parties get together.  Although
the meeting is mostly technical, it is also a chance for people to meet
and network with others in their field.

RIPE 75 will take place from 22-26 October in Dubai, UAE.

The RIPE Programme Committee (PC) is now seeking content proposals from
the RIPE community for the plenary sessions, BoFs (Birds of a Feather
sessions), panels, workshops, tutorials and lightning talks at RIPE 75.
See the full descriptions of the different presentation formats,
https://ripe75.ripe.net/submit-topic/presentation-formats/.

Proposals for plenary sessions, BoFs, panels, workshops and tutorials
must be submitted for full consideration no later than *20 August 2017*.
Proposals submitted after this date will be considered depending on the
remaining available space in the programme.

The PC is looking for presentations covering topics of network
engineering and operations, including but not limited to:

- IPv6 deployment
- Managing IPv4 scarcity
- Data centre technologies
- Network and DNS operations
- Internet governance and regulatory practices
- Network and routing security
- Content delivery
- Internet peering and mobile data exchange
- Connected Things (aka. Internet of Things - IoT)

Speakers

Due to UAE law, confirmed speakers will need to submit a copy of their
passport and contact information in advance of the meeting.  More
details are available here:
https://ripe75.ripe.net/attend/dctm-requirements

Please also note that speakers do not receive any discount or funding
towards the meeting fee at RIPE Meetings.

Submissions

RIPE Meeting attendees are quite sensitive to keeping presentations
non-commercial, and product marketing talks are strongly discouraged.
Repeated audience feedback shows that the most successful talks focus on
operational experience, research results, or case studies.  For example,
presenters wishing to describe a commercial solution should focus on the
underlying technology and not attempt a product demonstration.

Presenters should indicate how much time they will require.  In general,
the time allocated for the different presentation formats is as follows:

- Plenary presentations: 20-25 minutes presentation with 5-10 minutes
  discussion
- Tutorials: up to two hours (Monday morning)
- Workshops: one hour (during evening sessions) to two hours (Monday
  morning)
- BoFs: approximately one hour
- Lightning talks: 10 minutes total for both presentation and any
  discussion

The following general requirements apply:

- Proposals must be submitted using the meeting submission system,
  https://ripe75.ripe.net/submit-topic/
- Lightning talks should also be submitted using the meeting submission
  system (https://ripe75.ripe.net/submit-topic/) and can
  be submitted any time up to and including the meeting week. The
  allocation of lightning talks will be announced on short notice, in
  some cases on the same day but often one day prior to the time slot
  allocated.
- Presenters who propose a panel or BoF are encouraged to include
  speakers from several (perhaps even competing) companies and/or a
  neutral facilitator.
- All presentation proposals will only be considered by the PC if they
  contain at least draft presentation slides (slides may be updated
  later on). For panels, proposals must contain a clear description, as
  well as the names of invited panellists, presenters and moderators.

If you have any questions or requests concerning content submissions,
please email pc [at] ripe [dot] net.


-- 
Benno J. Overeinder
NLnet Labs
http://www.nlnetlabs.nl/

EdgeRouter Infinity as medium-sized "IXP Peering Router"?

[Job Snijders]

Dear NANOG,

Some friends of mine are operating a nonprofit (on shoe string) and looking
to connect some CDN caches to an IX fabric. A BGP speaking device is needed
between the caches and the BGP peers connected to the fabric. The BGP
speaker is needed to present the peers on the IX with a unified view of the
assemblage of CDN nodes.

I was wondering whether anyone was experience with the "EdgeRouter Infinity
XG" device, specifically in the role of a simple peering router for a
couple of tens of thousands of routes. (I'd point default to the left and
take just the on-net routes on the right to reduce the table size
requirement).

I hope the device can do at least 2xLACP trunks, has a sizable FIB, is
automatable (supports idempotency), can forward IMIX at line-rate, *flow,
and exposes some telemetry via SNMP.

Any note sharing would be appreciated!

Kind regards,

Job

Re: IPv4 Hijacking For Idiots

[John Curran]

On 3 Jul 2017, at 10:18 AM, Randy Bush > 
wrote:

Only if you sign the RSA and give up certain legal rights to your legacy
blocks/property.

the word 'certain' is not apt given that the LRSA Ts may be
arbitrarily changed by ARIN

Randy -

Not quite arbitrarily - ARIN can change it because of a change in the 
applicable caselaw,
but otherwise RSA changes happen only with the consent of the Members -


"(e) ARIN may only modify the terms of this Agreement under the following 
circumstances:
  (1) The Board finds an immediate and compelling need to amend the 
Agreement due to a definable, discrete, identifiable change in relevant statute 
or caselaw; or
  (2) Upon recommendation of the Board and ratification by Member vote.”

(Yes, this is one the changes that rolled out with the most recent RSA/LRSA,
 so you might not have been aware of same.)

Thanks!
/John

John Curran
President and CEO
ARIN

Re: IPv4 Hijacking For Idiots

[John Curran]

On 2 Jul 2017, at 2:22 PM, Bryan Fields  wrote:
> 
> On 7/2/17 1:28 PM, John Curran wrote:
>> Note that ARIN does provide RPKI services for legacy blocks, but it is true 
>> that we 
>> require more legalisms than other RIRs…  You can caulk this up to the 
>> abundance 
>> of legacy resources of questionable provenance in this region, to the 
>> colorful US 
>> legal environment, and/or to a desire not to endanger the services we’re 
>> already 
>> providing to thousands of customers. 
> 
> Only if you sign the RSA and give up certain legal rights to your legacy
> blocks/property.  I can't speak for everyone, but those I do know are not
> willing to do this.

And they may choose to do so.   Others have no problem signing the LRSA/RSA 
(which are effectively the same T’s now aside from fee schedule), and like 
having 
a very clear statement of their rights to the number resources, such as right 
to transfer,
access to arbitration, etc.  (These rights weren’t well spelt out in the 
earlier versions 
of the LRSA or RSA, but we eventually got their in the current form.) 

Of course, the other little detail isn’t whether they’re willing to sign, it is 
whether they
are entitled to sign, since the only parties that can enter an LRSA is the 
recipient or
their legal successor to the rights.  (It can be amusing when recently created 
entities
attempt to explain why they are the legal rights holder to a legacy number 
block…) 

> I'd propose there must be a better way that doesn't require legacy holders
> sign the RSA.  RPKI is important enough that something should be possible.

RPKI is quite important, but it also requires a solid legal foundation –
Resource certification absent the proper legal details as to who has
the rights and what rights that they have) is likely worse than no RPKI 
at all.

Thanks,
/John

John Curran
President and CEO
ARIN

 

Re: Transit Providers in Bracknell, UK

[Stuart Howlette]

I don't know personally, but have you tried asking on the UKNOF mailing list?
Regards,

Stuart Howlette
stu...@stuarthowlette.me.uk

On Fri, Jun 30, 2017 at 11:31 pm, Gary T. Giesen via NANOG  
wrote:

> Can anyone recommend a transit provider in Bracknell, UK? Not too picky on 
> requirements, but IPv6 is a must; RTBH and good peering are a very good to 
> have. We're looking to replace one of our current providers (Virgin Media - 
> AS5089). I have no problem naming them as they treat prefix list updates like 
> service changes (and charge £250 for the privilege). We gave in and paid it 
> and and 2 weeks later they have still not processed the change. Cheers, GTG

Re: Point 2 point IPs between ASes

[Thomas Bellman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2017-06-29/17 17:06, Job Snijders wrote:

> On Wed, Jun 28, 2017 at 11:09:25PM +0200, Thomas Bellman wrote:

>> I know that many devices allow you to configure any subnet size, but
>> is there any RFC allowing you to use e.g. /124 or /126?

> Breaking the law! Some IETFers will come hunt you do, be aware! ;-)

:-)  But I figure if the standards disallow certain things, then there
will likely be implementations that don't handle those things.  You
might need or want to interoperate with those, and when it is you that
is not following the standards, you can't complain much to the other
side.

Of course, for a point-to-point link, it tends to be fairly easy to
check with the other end what they support.  And if they (or you)
change equipment, then you will have a downtime for that link anyway
and can change your addresses at the same time.  Tends to be less
easy for a network with multiple hosts.


> Here is some historical perspective looking at the IETF standarsd and
> current Internet-Drafts:
> 
> RFC 3513 "only /64 is valid"
> RFC 3627 "don't use /127, use /126 if you must"
> RFC 4291 "reaffirming: only /64 is valid"
> RFC 6164 "a /127 is OK to use too"
> RFC 6583 "there are problems with /64"
> RFC 7421 "/64 is the best!"
> RFC 7608 "every prefix length must be forward-able"
> RFC 4291bis-07 "fine, /64 and /127 are valid, but nothing else!"
> draft-bourbaki-6man-classless-ipv6-00 "IPv6 is classless FFS"
> RFC 4291bis-08 "fine, /64 and /127 are valid, and anything defined in future 
> standards, and anything configured manually"
> 
> Quoting from 4291bis-08: 
> 
> """
> Interface Identifiers are 64 bit long except if the first three bits
> of the address are 000, or when the addresses are manually
> configured, or by exceptions defined in standards track documents.
> The rationale for using 64 bit Interface Identifiers can be found in
> [RFC7421]. An example of a standards track exception is [RFC6164]
> that standardises 127 bit prefixes on inter-router point-to-point
> links.
> 
>   Note: In the case of manual configuration, the Prefix and
>   Interface Identifier can be any length as long as they add up to
>   128.
> """
> source: 
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-08.txt
> full file: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-08

Thanks for this information!


/Bellman
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJZVgBuAAoJEGqUdKqa3HTsGm8P/3mY5KPJ/dlKOVtbjz1DIBdU
GKogsA3jAnysAOQJRyga4CJFN4wHmFRskbC9Vl5xLY2ihh2hATzZfLonozKaVd9/
m9QT8ObHf6XKO4euvKWdust4sZvV8Mw1upx5gokGWi/ciWvwWPy8WJ59ic6xengw
34Emmz8LMVUVq3uIZEyp7YWgc+yfeZFDJAnJbZNYXnQkQutyke/kR0SDCFtO7/nI
ZtE4+e5I0jtlujXsfeSJtlJTbQ6smJMXEHZZMtwo6LiA0zyAbHvvKDmndo0NbA1P
hARpN442QysjVE8amF8UeE9muDs90gitSo+c0n1QzMDm5tV8bG3Vo5gENQM5Amv7
9ovPt25efO3Lb6jEbeIZOjLRLNzVlaiavGwLUk8AgwAOaSkOXVhkMmp/Iqyp/lNx
+bIHbimzi057Dw62e2NugQKaCnc4jgAfzzvicyOELdjU0yQy4p/uA89cJ7G5ycSG
tQ0j/Xi39+MXwHGnRmJdwrXOAAkqoa4SYwAYAF0PymP+/4JrXilp6FkZkEXugpu7
9DqRfLB9nY4dKDysqlE9tGwBykeVvy44sd6AM/hKBrAVwnRGuXywFBXLetEaBCOp
wcDbFEtUIOccEysNnfxDOt8btMtvsUUNUSMky0o2oqEQeWaaxXvVuMrUOoVbfFVW
VWUBP2dPjOFy+KDwdD5R
=qAKT
-END PGP SIGNATURE-

Re: IPv4 Hijacking For Idiots

[Randy Bush]

> Only if you sign the RSA and give up certain legal rights to your legacy
> blocks/property.

the word 'certain' is not apt given that the LRSA Ts may be
arbitrarily changed by ARIN

Re: Transit Providers in Bracknell, UK

[Simon Lockhart]

On Mon Jul 03, 2017 at 08:36:45AM -0400, Gary T. Giesen via NANOG wrote:
> Thanks all for the on- and off-list suggestions. I've joined the UKNOF list
> and will seriously look at Vodafone (former C).

You could also look at A - www.aaisp.net.uk - very clueful and based in
Bracknell.

Simon

Re: Transit Providers in Bracknell, UK

[Gary T . Giesen via NANOG]

Thanks all for the on- and off-list suggestions. I've joined the UKNOF list and 
will seriously look at Vodafone (former C).

Cheers,

GTG


On Sunday, July 02, 2017 13:58 EDT, Stuart Howlette 
 wrote:
 I don't know personally, but have you tried asking on the UKNOF mailing list? 
Regards,

Stuart Howlette
stu...@stuarthowlette.me.uk  On Fri, Jun 30, 2017 at 11:31 pm, Gary T. Giesen 
via NANOG  wrote:Can anyone recommend a transit provider in 
Bracknell, UK? Not too picky on requirements, but IPv6 is a must;  RTBH and 
good peering are a very good to have. We're looking to replace one of our 
current providers (Virgin Media - AS5089). I have no problem naming them as 
they treat prefix list updates like service changes (and charge £250 for the 
privilege). We gave in and paid it and and 2 weeks later they have still not 
processed the change. Cheers, GTG