Re: sFlow vs netFlow/IPFIX

[Mark Tinka]

On 2/Mar/16 19:25, Peter Phaal wrote:

> The Nexus 3200 should work well with 100G flows - I believe it's based on the 
> latest Broadcom Tomahawk ASIC. The older Trident II ASICs in the Nexus 9k are 
> 40g parts.

Yes, the new Tomahawk chips support native 100Gbps lanes.

Mark.

Re: About inetnum "ownership"

[Bob Evans]

As far as I know there is no requirement to announce your assigned or
legacy owned prefixes to the world. You have the right to announce them. 
I don't think you can legally stop others from announcing your path to
them. Once you publicly announce something, it's out there.

Oh well, maybe I didn't get the original question. I thought the
discussion was about a network's right to prevent others in the world from
announcing/propagating a route to that network's prefixes. Seemed to be a
legal question and the field analogy someone put forth seemed to apply
well. I can't take credit for that as I simply tuned it and showed how it
fit in a historical way. I think a lawyer would probably make this analogy
in a court.

Thank You
Bob Evans
CTO


>
> Interesting demonstration of why retreat to analogies does not help in a
> discussion.
>
> A question:  If you stop announcing your routes, where will the world
> get them from?
>
> --
> sed quis custodiet ipsos custodes? (Juvenal)
>
>

Re: About inetnum "ownership"

[Larry Sheldon]

On 3/2/2016 08:05, Bob Evans wrote:

The numbers (IP addresses) are not the field. The servers are the field.
The numbers are the street addresses of the server. Domain names would be
a nick name for the numbers, like PaddingHouse.com is at 55.51.52.1. The
BGP table is a road map.

That's why it was once called the Super Information Highway, remember?

You can sell street/road maps to the stars, and the stars don't have to
let you in.

Thank You
Bob Evans
CTO





On Wed, 2016-03-02 at 00:44 -0500, William Herrin wrote:

Do I have the legal right to exclude others from announcing my block
of IP addresses to the public Internet routing tables? It's not well
tested in court but the odds are exceptionally strong that I do.

If I own some property - say a field - the location of that field is
with certain rare exceptions public information. I as the owner cannot
enforce a requirement on you to NOT tell people where my field is. I
can't demand that you NOT build roads past it, or that you NOT put up
signs saying how to get to my field, or even that you NOT tell people
who owns the field. I have the right to exclusive use of the property,
but I have no rights to information about the property, nor any
property rights outside the boundary of the property.

Testing in court the idea that you may not advertise my routes would be
a fascinating exercise. If you falsely advertised them it would be a
different matter.

Has this sort of thing been tested in the courts at all? In any
jurisdiction?


Indeed, the whole point of registration is to facilitate
determination
of -who- has the exclusive right over -which- blocks of addresses.

The problem is what rights we are talking about. I would say that
practically speaking the only real right here is the right to configure
an address on an interface. But anyone else can send packets to an
address, or advertise to others the direction of travel towards that
network. Malicious activity excluded of course - DoS attacks and so on,
but I think the issues there are different. Also, contractually
regulated relationships are different - if I connect something up to
ISPX and have a contract with ISPX to NOT advertise the route to me,
then ISPX is constrained.

Regards, K.

--
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4









Interesting demonstration of why retreat to analogies does not help in a 
discussion.


A question:  If you stop announcing your routes, where will the world 
get them from?


--
sed quis custodiet ipsos custodes? (Juvenal)

Re: About inetnum "ownership"

[Constantine A. Murenin]

On 2 March 2016 at 03:46, William Herrin  wrote:
> On Wed, Mar 2, 2016 at 1:12 AM, Karl Auer  wrote:
>> Testing in court the idea that you may not advertise my routes would be
>> a fascinating exercise. If you falsely advertised them it would be a
>> different matter.
>
> Hi Karl,
>
> I'm having trouble seeing the nit you're picking. I can't compel you
> to announce my BGP route but if you do announce it and your
> announcement is inconsistent with my own then by definition it's
> false. If your announcement is consistent with my own then you're
> propagating the route as intended and I have no cause for complaint.
>
>> Has this sort of thing been tested in the courts at all? In any
>> jurisdiction?
>
> So far as I know, network operators have interceded and the false
> routes have been withdrawn long before any route hijacking cases would
> have gone to court.

Care to explain why noone has bothered to seek punitive damages, then?

C.

Re: sFlow vs netFlow/IPFIX

[Peter Phaal]

On Wed, Mar 2, 2016 at 2:45 PM, Nick Hilliard  wrote:
> Peter Phaal wrote:
>> Monitoring ingress and egress in the switch is wasteful of resources.
>
> It's more than a waste of resources:  it's pathologically broken and
> Cisco decline to fix it, despite the fact that enabling ingress-only or
> egress-only is fully supported via API in the Broadcom SDKs, and
> consequently the amount of configuration glue required to fix it in
> NX-OS is nearly zero.
>
> Broadcom chipsets don't support netflow, so sflow is the only game in
> town if you need data telemetry on broadcom-based ToR boxes.
>
> As I said in a previous email on this thread, refusing to support this
> properly is a harmful and short sighted approach to customers' requirements.

I think "pathologically broken" somewhat overstates the case.
Bidirectional sampling is allowed by the sFlow spec and other vendors
have made that choice. Another vendor used to implement egress only
sampling (also allowed) but unusual. I agree that ingress is the most
common and easiest to deal with, but a decent sFlow analyzer should be
able to handle all three cases without over / under counting.

More annoying is differences in how vendors report telemetry from LAG
/ MLAG topologies. The "sFlow LAG Counters Structure" extension was
published in 2012 and defines how counters and samples should be
generated on LAGs. Anyone with using LAG / MLAG topologies might want
to ask their vendor if they support / plan to support the extension.

Re: sFlow vs netFlow/IPFIX

[Nick Hilliard]

Peter Phaal wrote:
> Monitoring ingress and egress in the switch is wasteful of resources.

It's more than a waste of resources:  it's pathologically broken and
Cisco decline to fix it, despite the fact that enabling ingress-only or
egress-only is fully supported via API in the Broadcom SDKs, and
consequently the amount of configuration glue required to fix it in
NX-OS is nearly zero.

Broadcom chipsets don't support netflow, so sflow is the only game in
town if you need data telemetry on broadcom-based ToR boxes.

As I said in a previous email on this thread, refusing to support this
properly is a harmful and short sighted approach to customers' requirements.

Nick

Re: sFlow vs netFlow/IPFIX

[Peter Phaal]

On Wed, Mar 2, 2016 at 9:30 AM, Nick Hilliard  wrote:
> Peter Phaal wrote:
>> The Nexus 3200 should work well with 100G flows - I believe it's
>> based on the latest Broadcom Tomahawk ASIC. The older Trident II
>> ASICs in the Nexus 9k are 40g parts
>
> does nx-os still force ingress-and-egress sflow?  sflow is pretty
> useless you can define an accounting perimeter, which means that you
> need either ingress across the board, or egress.  ingress-and-egress is
> basically useless because you end up double counting everything.

Monitoring ingress and egress in the switch is wasteful of resources.
In most use switch  use cases (a leaf / spine fabric for example) the
next hop switch will also be reporting ingress sFlow and so when you
combine sFlow streams from both switches you get bi-directional
visibility into every link. Enabling ingress only sFlow on all switch
ports catches all packet paths and halves the overhead of
bi-directional sampling.

The sFlow architecture shifts intelligence from the devices to
external software. The goal is to have a general purpose telemetry
stream that can be used for a variety of purposes. Rather than having
the complexity of configuring sFlow selectively at the sender, the
receiver is responsible for de-duplicate the sFlow stream for
accounting (the packet stream selection and elimination you are doing
in the switch configuration can equally be applied on receipt).
Shifting the decision to the collector means you can also use the
stream to diagnose performance problems (for example identifying top
flows on a busy link), traffic engineering of large flows, etc. If the
sender is configured to suite one application, you limit the value of
the measurements for other applications.

An often overlooked feature of sFlow is that the agent also
periodically sends interface counters (reducing or eliminating the
need for SNMP polling in many use cases). The counters and packet
samples are tied together in the sFlow data model - for example you
can use the interface speed information from the counter samples to
compute utilizations based on the packet sample stream etc). Broadcom
also defined sFlow metrics to provide additional visibility into the
ASIC forwarding pipeline (layer 2 / layer 3 / ACL table utilization,
buffer utilization, microburst detection) and the inclusion of these
metrics with the samples packet data in the sFlow telemetry stream
provides a way to identify the traffic that is consuming the hardware
resources.

Re: Cogent & Google IPv6

[Owen DeLong]

I think actually, that Cogent is the new SPRINT.

I remember a time when virtually all of the internet Transited SPRINT and it 
was nearly impossible to avoid going through SPRINT’s network.

Then SPRINT started de-peering left and right. Today, as near as I can tell, 
this strategy has made then an “also-ran”.

Cogent is already essentially the weakest of any who can lay claim to the idea 
of “tier-1” whatever that’s supposed to mean (varies widely depending on who 
you ask).

For now, Cogent is hoping that they can force the same environment in IPv6 as 
they have enjoyed in IPv4 while ignoring the reality that many players have 
surpassed them in IPv6 and that there are new opportunities to go settlement 
free in IPv6 that didn’t exist in the IPv4 world. The IPv6 game is somewhat 
different than IPv4 and recent rulings from the FCC are going to potentially 
change the game even further.

My guess is that Cogent won’t blink, but they will continue to become more and 
more isolated from more and more IPv6 networks who become wise to their game. 
As a result, they will become less and less relevant in the market until they 
join SPRINT on the also-ran list.

Owen

> On Feb 24, 2016, at 12:12 , Patrick W. Gilmore  wrote:
> 
> Are HE & Google the new L3 & FT?
> 
> Nah, L3 would never have baked Cogent a cake. :)
> 
> Shall we start a pool? Only problem is, should the pool be “who will 
> disconnect from Cogent next?” or “when will Cogent blink?” I’m voting for the 
> former.
> 
> -- 
> TTFN,
> patrick
> 
>> On Feb 24, 2016, at 3:08 PM, Baldur Norddahl  
>> wrote:
>> 
>> This is Google saying that Google does not want to pay for traffic to
>> Cogent. If Cogent wants to exchange any traffic with Google, Cogent is
>> invited to peer directly with Google. Of course Cogent refuses. And now
>> Cogent is not only missing the part of IPv6 internet that is Hurricane
>> Electric single homed but also everything Google.
>> 
>> Why does Cogent refuse? They used to deliver this traffic on free peering
>> with another tier 1 provider. Now they are asked to deliver the same
>> traffic for the same price (free) on a direct peering session. They won't
>> because Cogent believes Google should pay for this traffic. That another
>> Cogent customer already paid for the traffic does not matter. They want
>> double dipping or nothing. So nothing it is.
>> 
>> Seems to me that if you are serious about IPv6 you can not use Cogent as
>> your primary or secondary transit provider. You can use them as your third
>> if you want to.
>> 
>> Regards,
>> 
>> Baldur
>> 
>> 
>> 
>> On 24 February 2016 at 20:46, Matt Hoppes 
>> wrote:
>> 
>>> Correct me if I'm wrong, but if Cogent isn't peering with Google IPv6,
>>> shouldn't the traffic flow out to one of their peer points where another
>>> peer DOES peer with Google IPv6 and get you in?
>>> 
>>> Isn't that how the Internet is suppose to work?
>>> 
>>> 
>>> On 2/24/16 2:43 PM, Damien Burke wrote:
>>> 
 Not sure. I got the same thing today as well.
 
 Is this some kind of ipv6 war?
 
 -Original Message-
 From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ian Clark
 Sent: Wednesday, February 24, 2016 10:25 AM
 To: NANOG
 Subject: Cogent & Google IPv6
 
 Anyone know what's actually going on here?  We received the following
 information from the two of them, and this just started a week or so ago.
 
 
 *From Cogent, the transit provider for a branch office of ours:*
 
 Dear Cogent Customer,
 
 Thank you for contacting Cogent Customer Support for information about
 the Google IPv6 addresses you are unable to reach.
 
 Google uses transit providers to announce their IPv4 routes to Cogent.
 
 At this time however, Google has chosen not to announce their IPv6 routes
 to Cogent through transit providers.
 
 We apologize for any inconvenience this may cause you and will notify you
 if there is an update to the situation.
 
 
 
 *From Google (re: Cogent):*
 
 Unfortunately it seems that your transit provider does not have IPv6
 connectivity with Google. We suggest you ask your transit provider to look
 for alternatives to interconnect with us.
 
 Google maintains an open interconnect policy for IPv6 and welcomes any
 network to peer with us for access via IPv6 (and IPv4). For those networks
 that aren't able, or chose not to peer with Google via IPv6, they are able
 to reach us through any of a large number of transit providers.
 
 For more information in how to peer directly with Google please visit
 https://peering.google.com
 
 
 --
 Ian Clark
 Lead Network Engineer
 DreamHost
 
 
> 

Re: Juniper PTX1000

[Saku Ytti]

On 2 March 2016 at 19:59, Peter Kranz  wrote:

> Anyone played with the newish Juniper PTX1000 platform? Seems quite
> interesting for compact deployments, but I've not been able to find much
> pricing information to see just how interesting..

I would expect it to be priced competitively against Jericho boxes.
Initial look at its brother from another mother are mostly positive,
but then again I had realistic expectations, I didn't expect denser
Trio.

-- 
  ++ytti

Re: BGP MVPN RFC6513, Section 10

[Jason Iannone]

Thanks for responding.  What's interesting is that even though no
listener joins to RP, one must be configured for PIM Sparse Mode ASM
to function.  I suppose this is a result of MVPN outsmarting PIM.

In my testing so far, generating a working flow with rpt-spt is much
faster than spt-only.  I suspect this has to do with the conditional
nature of the Type 7 Join which waits for receipt of a Type 5 SA
before signaling interest upstream.  spt-only mode seems objectively
superior to rpt-spt in every other way.

Jason

On Fri, Feb 26, 2016 at 2:33 AM, Yann Lejeune  wrote:
> Hi
> To support the section §10 in your conf you have two choices:
> a. (§10.1) implementing the RP on your PE (protocol pim rp local). It will
> advertises the route type after pim register message (or msdp source active
> from other RP is you have other rp in your network)
> + be sure to use spt-only mvpn mode (default one)
>
> b. (§10.2) implementing an MSDP session between the RP and its PE
> each time the RP will learn a source (either because it receives a pim
> register or a SA message from another RP (full meshing msdp between rp), it
> will advertise route type 5 to the mVPN. This way receiver PE will learnt
> source and if they received join (*,g), they will be able to advertise the
> good route type 7 to the source PE. The required conf is:
> - msdp session between the pe and the rp
> - defining the rp address (protocols pim rp static)
> - be sure to use spt-only mvpn mode (default one)
>
> The route type 6 is used in another mode call rpt-spt, where you are closer
> to the traditionnal multicast behavior (first we build the rp tree and
> second we build the source tree). this mode must be enable explicitely per
> routing-instance in the mvpn-mode knob. One thing: even in spt-only mode,
> the junos will create a route type 6 when receiving a join (*,g) but will
> not advertise it. It just wait to get a related route type 5
>
> It's up to you to choose what mode you want to use:
> - spt-only: is quite "simple". We only have (s,g) in the core. To validate
> an os, it's faster.
> - rpt-spt. We have both (*,g) and (s,g) in the core. the validation is more
> complex, the protocol is more dynamic...
>
> Regards,
> Yann.
>
>
>
> On 23 February 2016 at 16:39, Jason Iannone  wrote:
>>
>> Hi all,
>>
>> I'm having trouble interpreting under what circumstance section 10 of
>> BGP MVPN comes into play.
>>
>> The way I read this section, upon the receipt of PIM/IGMP Join to
>> (*,G) the Receiver Site PE does not signal Type 6 or Type 7 Joins
>> until a Type 5 Source Active route is received from a Sender Site PE.
>>
>> If Section 10 assumes the use of ASM groups in the VPN, why develop a
>> Type 6 Shared Tree Join A-D route for unknown sources?
>>
>> What are the practical minimum Juniper configurations to support
>> Section 10 for ASM and (*,G) PIM Join when the PE doesn't know a
>> source?
>>
>> CE1---PE1,C-RP-P-PE2---CE2
>> Sender Site---Receiver Site
>>
>> 1. CE1 has no active source
>> 2. CE2 forwards PIM Join (*,G) to PE2 toward PE1,C-RP
>> 3. PE2 eats PIM Join, maintains (*,G) state
>> 4. CE1 generates Register messages to PE1
>> 5. PE1 originates Type 5 (S,G)
>> 6. PE2 receives Type 5 (S,G)
>> 7. PE2 verifies existing (*,G) state
>> 8. PE2 advertises Type 7 Join (S,G)
>> 9. PE2 does PMSI and P-Tunnel attachment
>> 10. PE1 receives (S,G) from PE2
>> 11. PE1 adds PMSI to downstream interfaces
>> 12. Multicast flow end to end
>> 13. Achievement unlocked!
>>
>> I'm least sure about steps 2 & 3.
>>
>> Comprehension challenged,
>>
>> Jason
>
>

Re: Any large IPv4 space brokers?

[Hank Nussbacher]

On 02/03/2016 19:28, Brough Turner wrote:
> https://www.arin.net/resources/transfer_listing/facilitator_list.html
>
> Thanks,
> Brough

There was a RIPE site:
https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers
but most of the links are broken (like Brokers and IP Transfer Listing
Service) so try these:
https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers/brokers
https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers/transfer-faqs

-Hank

Juniper PTX1000

[Peter Kranz]

Anyone played with the newish Juniper PTX1000 platform? Seems quite
interesting for compact deployments, but I've not been able to find much
pricing information to see just how interesting..

 

Peter Kranz
www.UnwiredLtd.com  
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com  

 

Re: sFlow vs netFlow/IPFIX

[Nick Hilliard]

Peter Phaal wrote:
> The Nexus 3200 should work well with 100G flows - I believe it's
> based on the latest Broadcom Tomahawk ASIC. The older Trident II
> ASICs in the Nexus 9k are 40g parts

does nx-os still force ingress-and-egress sflow?  sflow is pretty
useless you can define an accounting perimeter, which means that you
need either ingress across the board, or egress.  ingress-and-egress is
basically useless because you end up double counting everything.

Nick

Re: Any large IPv4 space brokers?

[Brough Turner]

https://www.arin.net/resources/transfer_listing/facilitator_list.html

Thanks,
Brough

Brough Turner
netBlazr Inc. – Free your Broadband!
Mobile:  617-285-0433   Skype:  brough
netBlazr Inc.  | Google+
 | Twitter
 | LinkedIn
 | Facebook
 | Blog
 | Personal website




On Wed, Mar 2, 2016 at 2:34 AM, Jonas Bjork  wrote:

> Hi, these sites sell PA network space, I assume? Where may I buy PI nets?
>
> Best regards,
> Jonas
>
> Sent from my iPad
>
> > On 02 Mar 2016, at 01:54, Jim Mercer  wrote:
> >
> >> On Tue, Mar 01, 2016 at 05:32:44PM -0500, Paras Jha wrote:
> >> Does anyone know of any IP space brokers other than Hilco Streambank?
> I'm
> >> looking to get a feel for the market a little bit.
> >
> > register with the ARIN STLS, there are some blocks available there too.
> >
> > --jim
> >
> > --
> > Jim Mercer Reptilian Research  j...@reptiles.org+1 416
> 410-5633
> >
> > Life should not be a journey to the grave with the intention of
> > arriving safely in a pretty and well preserved body, but rather
> > to skid in broadside in a cloud of smoke, thoroughly used up,
> > totally worn out, and loudly proclaiming "Wow! What a Ride!"
> > -- Hunter S. Thompson
>

Re: sFlow vs netFlow/IPFIX

[Peter Phaal]

> 
> On Mar 1, 2016, at 10:12 PM, Mark Tinka  wrote:
> 
> 
> 
>> On 2/Mar/16 08:04, Mark Tinka wrote:
>> 
>> We were initially looking at at the Nexus 9000, but then moved to the
>> 7700 because the Broadcom chip on the 7700 cannot do single flows larger
>> than 40Gbps on the 100Gbps ports.
> 
> The Broadcom chip on the 9000, I meant...
> 
> Mark.

The Nexus 3200 should work well with 100G flows - I believe it's based on the 
latest Broadcom Tomahawk ASIC. The older Trident II ASICs in the Nexus 9k are 
40g parts

Re: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS

[Michael O'Connor]

ESnet employs MPLS virtual circuits from our customer sites to VLANs
connecting over DX cross connects in US-EAST and US-WEST regions. Exploring
the DX provider paradigm we have demonstrated that the billing of the DX
network service can be billed to the provider with the compute costs billed
directly to the customer. In this way a network provider can cover the
shared network resource cost, if desired.

While the carrier does provision EBGP, in our use case it was only used for
monitoring not for exchanging routes. Each of our customers provision both
a public and private/VPC EBGP peering, see public and private DX services.

This gets interesting when you realized the routes advertised by AWS differ
by geographic region in the public Internet case and when peering with DX
AWS advertises a much larger table and recommends that end sites build
policies based on the information in this link:

https://ip-ranges.amazonaws.com/ip-ranges.json

At some point your DX customers will need to make the decision to prefer
the public AWS route prefixes that you export to them or those received
directly from their DX public EBGP service.

-Mike O'Connor


On Wed, Mar 2, 2016 at 5:03 AM, James Bensley  wrote:

> On 1 March 2016 at 20:41, Michael O'Connor  wrote:
> > Jay,
> >
> > VPC is supported over IPsec if your public path is sufficient into the
> AWS
> > cloud.
>
> ^ This.
>
> I work for a DirectConnect provider, albeit in the UK though. We have
> fibre links to a AWS edge routers and we have multiple customers
> seperated by VLANs over a fibre link, each terminating into different
> VRFs on our edge and the AWS edge. For each customer we have an eBGP
> session with a virtual gateway that lives inside the customer's VPC
> domain.
>
> Also for each customer they have backup tunnels using IPSec over the
> Internet. Again we run eBGP over the IPSec tunnels to the virtual
> gateway inside each customers VPC domain.
>
> "just works".
>
> James.
>



-- 
Michael O'Connor
ESnet Network Engineering
m...@es.net
631 344-7410

Re: About inetnum "ownership"

[Bob Evans]

The numbers (IP addresses) are not the field. The servers are the field.
The numbers are the street addresses of the server. Domain names would be
a nick name for the numbers, like PaddingHouse.com is at 55.51.52.1. The
BGP table is a road map.

That's why it was once called the Super Information Highway, remember?

You can sell street/road maps to the stars, and the stars don't have to
let you in.

Thank You
Bob Evans
CTO




> On Wed, 2016-03-02 at 00:44 -0500, William Herrin wrote:
>> Do I have the legal right to exclude others from announcing my block
>> of IP addresses to the public Internet routing tables? It's not well
>> tested in court but the odds are exceptionally strong that I do.
>
> If I own some property - say a field - the location of that field is
> with certain rare exceptions public information. I as the owner cannot
> enforce a requirement on you to NOT tell people where my field is. I
> can't demand that you NOT build roads past it, or that you NOT put up
> signs saying how to get to my field, or even that you NOT tell people
> who owns the field. I have the right to exclusive use of the property,
> but I have no rights to information about the property, nor any
> property rights outside the boundary of the property.
>
> Testing in court the idea that you may not advertise my routes would be
> a fascinating exercise. If you falsely advertised them it would be a
> different matter.
>
> Has this sort of thing been tested in the courts at all? In any
> jurisdiction?
>
>> Indeed, the whole point of registration is to facilitate
>> determination
>> of -who- has the exclusive right over -which- blocks of addresses.
>
> The problem is what rights we are talking about. I would say that
> practically speaking the only real right here is the right to configure
> an address on an interface. But anyone else can send packets to an
> address, or advertise to others the direction of travel towards that
> network. Malicious activity excluded of course - DoS attacks and so on,
> but I think the issues there are different. Also, contractually
> regulated relationships are different - if I connect something up to
> ISPX and have a contract with ISPX to NOT advertise the route to me,
> then ISPX is constrained.
>
> Regards, K.
>
> --
> ~~~
> Karl Auer (ka...@biplane.com.au)
> http://www.biplane.com.au/kauer
> http://twitter.com/kauer389
>
> GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
> Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
>
>
>
>

Re: About inetnum "ownership"

[William Herrin]

On Wed, Mar 2, 2016 at 1:12 AM, Karl Auer  wrote:
> Testing in court the idea that you may not advertise my routes would be
> a fascinating exercise. If you falsely advertised them it would be a
> different matter.

Hi Karl,

I'm having trouble seeing the nit you're picking. I can't compel you
to announce my BGP route but if you do announce it and your
announcement is inconsistent with my own then by definition it's
false. If your announcement is consistent with my own then you're
propagating the route as intended and I have no cause for complaint.

> Has this sort of thing been tested in the courts at all? In any
> jurisdiction?

So far as I know, network operators have interceded and the false
routes have been withdrawn long before any route hijacking cases would
have gone to court.

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: About inetnum "ownership"

[William Herrin]

On Wed, Mar 2, 2016 at 2:46 AM, Jonas Bjork  wrote:
> shouldn't the same logic of ownership of DNS domain names apply to inetnum 
> address space?

Hi Jonas,

A trademark owner invoking the UDRP generally is able to exclude
anyone else that can't present an equally valid claim to the name.
That's why the vast majority of squatted names are for sale at just
under the cost of invoking the UDRP.

Regards,
Bill Herrin

-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS

[James Bensley]

On 1 March 2016 at 20:41, Michael O'Connor  wrote:
> Jay,
>
> VPC is supported over IPsec if your public path is sufficient into the AWS
> cloud.

^ This.

I work for a DirectConnect provider, albeit in the UK though. We have
fibre links to a AWS edge routers and we have multiple customers
seperated by VLANs over a fibre link, each terminating into different
VRFs on our edge and the AWS edge. For each customer we have an eBGP
session with a virtual gateway that lives inside the customer's VPC
domain.

Also for each customer they have backup tunnels using IPSec over the
Internet. Again we run eBGP over the IPSec tunnels to the virtual
gateway inside each customers VPC domain.

"just works".

James.

Re: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS

[Bevan Slattery]

***disclaimer - info on subject from a shareholder*** :)

Yeah.  In addition to Equinix and a few others  Megaport is expanding pretty 
quickly in US at present.  30+ locations 7 US markets.  Worth a look if you are 
trying to get your Azure and AWS fix from a single provider via 100% SDN, API 
driven platform (also and other services such as AMS-IX peering).  Interesting 
differences such as a flat rate Virtual X-Connect regardless of speed and where 
the other end of the circuit is in the metro.  Day/month/year from 1mbps to 
10gbps.  Been doing elastic interconnects since 2013.

https://www.megaport.com/services/megaport_enabled_locations

Well known in Asia but less so in US/NANOG hence the first and last public post 
about this.

Anyway, maybe worth a look.

Cheers

B

> On 2 Mar 2016, at 9:28 AM, Dave Cohen  wrote:
> 
> I can confirm that AWS (and Equinix, by extension, from a facility operator
> perspective) permit carriers to have multiple end users share a physical
> interface into the AWS gateway. The key is whether the providers that are
> permitted into the DX environment (I believe AWS has limited the list to
> only 7 or 8 in total - anyone else is reselling capacity off of those
> carriers) are willing to deal with the constraints of that configuration -
> essentially that the carrier needs to take responsibility of engaging
> directly with AWS to associate the EVC on the provider interface with the
> VPC on the AWS interface. I can confirm that at least one provider other
> than Equinix will do this. Point being, it's not an AWS restriction as much
> as whether the provider is willing to get its hands a bit dirtier. My $.02
> at least.
> 
> - Dave
> 
>> On Tue, Mar 1, 2016 at 7:59 PM, Mike Hammett  wrote:
>> 
>> I haven't heard it from the horse's mouth, but I heard that the only way
>> to have customers share an AWS DX (apparently) cross connect is through
>> Equinix's cloud exchange service. Can anyone confirm that? It doesn't seem
>> right that I could transport people to AWS all day long if they buy their
>> own cross connect, but once we share, I have to go through someone offering
>> a competitive service.
>> 
>> 
>> 
>> 
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>> 
>> Midwest-IX
>> http://www.midwest-ix.com
>> 
>> - Original Message -
>> 
>> From: "Michael O'Connor" 
>> To: "Jay R. Ashworth" 
>> Cc: "North American Network Operators' Group" 
>> Sent: Tuesday, March 1, 2016 2:41:35 PM
>> Subject: Re: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS
>> 
>> Jay,
>> 
>> VPC is supported over IPsec if your public path is sufficient into the AWS
>> cloud.
>> 
>> AWS shortens DirectConnect to DX not DC for some reason.
>> 
>> The AWS DirectConnect service is built on 10G infrastructure so using
>> potentially larger interconnects over public peerings with IPsec could be
>> advantageous.
>> 
>> DX requires fiber cross connects in addition to any other AWS peerings that
>> you may have at a particular location.
>> 
>> -Mike O'Connor
>> 
>> 
 On Tue, Mar 1, 2016 at 12:16 PM, Jay R. Ashworth  wrote:
>>> 
>>> Just got this dropped on my desk an hour ago, and I'm not finding as much
>>> material online as I might have hoped for...
>>> 
>>> It looks like the easiest solution is to just hang a router/firewall at
>>> Equinix Ashburn and AWS-DC to that, and then peer it to carriers both IP
>>> and
>>> MPLS; is there a "native" way to do that from an AWS VPC instead?
>>> 
>>> Any public or private replies cheerfully accepted; will summarize what I
>>> can to the list.
>>> 
>>> Cheers,
>>> -- jra
>>> 
>>> --
>>> Jay R. Ashworth Baylink
>>> j...@baylink.com
>>> Designer The Things I Think RFC
>>> 2100
>>> Ashworth & Associates http://www.bcp38.info 2000 Land
>>> Rover DII
>>> St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647
>>> 1274
>> 
>> 
>> 
>> --
>> Michael O'Connor
>> ESnet Network Engineering
>> m...@es.net
>> 631 344-7410
> 
> 
> -- 
> - Dave Cohen
> eM: craetd...@gmail.com
> AIM: dCo says
> 
> 
> -- 
> - Dave Cohen
> eM: craetd...@gmail.com
> AIM: dCo says