Re: The future of transport in the metro area

2019-08-02 Thread Mark Tinka


On 31/Jul/19 16:48, Etienne-Victor Depasquale wrote:

>
> "I'm trying to identify trends in adoption of transport technology in
> the metro-area. If legacy is SDH/SONET and its successor in circuit
> transport is OTN, what are network providers implementing and planning
> to implement as transport technology in the metro area? For example,
> are packet transport technologies being considered as a replacement?
> As a complementary technology? By packet transport technologies, I am
> thinking of PBB-TE and MPLS-TP but ultimately, the problem regards how
> network providers are balancing circuit-transport and packet-transport
> technologies in current and planned deployments."

Ethernet has been ruling the Metro for some time now. The control and
forwarding planes that drive that are a decision left to the operator.

There is a healthy sharing of the pie between DWDM and packet to drive
these Ethernet Metro's, depending on use-case, the operators' business
model, whether it's an ISP or a content network, e.t.c.

In all, SDH/SONET Metro networks, while not completely gone, are
certainly on the decline.

As far as OTN goes, I've always heard more talk than actual biting by
customers. In our market, every time a customer has shown interest in
OTN, they end up going for EoDWDM, all the time.

Mark.


Re: The future of transport in the metro area

2019-08-02 Thread Mark Tinka
And just to add that I think that as part of the future, 5G is likely to
play a big part as well, somewhere between the Metro and the Access.

Mark.


Re: The future of transport in the metro area

2019-08-02 Thread Mark Tinka



On 2/Aug/19 10:17, Etienne-Victor Depasquale wrote:

> Mark, when you write "There is a healthy sharing of the pie between
> DWDM and packet to drive these Ethernet Metro's ", can you elaborate a
> little? Are you referring specifically to EoDWDM, or do you have
> something else in mind?

EoDWDM.

Ethernet is very widely used, regardless of the Transport technology.

In other markets, you will find SDH Transports delivering Ethernet as
well (EoSDH), although that is dying in favour of EoDWDM or just
Ethernet over (dark) fibre.

Mark.


Re: Phoenix IX down/gone?

2019-08-02 Thread Bryan Holloway



On 8/2/19 3:29 AM, Brandon Wade via NANOG wrote:

Corrected URL:
https://peeringdb.com/ix/662

Anyone know what happened to Phoenix IX? https://peeringdb.com/ix/66  They
seem off the air including website and phones.. permanently?

-PeterK at 32354  


We (AS53767) are passing traffic on Phoenix IX. The person who operates 
the exchange (Paul Emmons) is frequently traveling for business. I 
suspect something is simply wrong with the website.


I'll reach out to him through a private channel and make sure he's aware 
the website is down.


Best regards,
Brandon Wade
iCastCenter.com / AS53767



The web-site appears to be up again.


Re: UK, NL, & Asia LTE Providers for Opengear Console Servers

2019-08-02 Thread James Bensley
On Thu, 1 Aug 2019 at 02:36, Ryan Gelobter  wrote:
>
> Anyone have recommendations for providers who I can use for LTE on Opengear 
> console servers in the UK, Netherlands, and Singapore? 1 provider for all 3 
> countries would be great but I'll take what I can get. Oddly when talking to 
> Opengear they don't really have any great advice. We use Verizon SIM cards in 
> the US with static IPs.
>
> Thanks,
> Ryan

Hi Ryan,

Vodafone GDSP (Global Data Service Platform) might be what you're
looking for "We offer 4G LTE roaming in over 100 countries." - I've
been looking into this recently but can't find a list of those
countries publically available. I think you'd need to approach
Vodafone directly as an interested customer/party, and I'm working via
a VAR so no direct channel.

Cheers,
James.


Re: UK, NL, & Asia LTE Providers for Opengear Console Servers

2019-08-02 Thread Tom Hill
On 01/08/2019 15:14, Nick Olsen wrote:
> It roams on 3UK. And works fine. Albeit the LTE deployment isn't near as
> wide there as it is in the US. And you end up on HSDPA pretty frequently.

To the this point, I've a Three contract here (UK). It has slightly been
frustrating recently, I'll admit.

It does look like they're aiming to address that, however. More
re-farming 3G frequencies to 4G, additional bands:

https://www.ispreview.co.uk/index.php/2019/08/three-uk-in-l-band-rollout-as-mobile-data-usage-per-user-hits-9-1gb.html

-- 
Tom


MAP-E

2019-08-02 Thread Baldur Norddahl
Hello

Are there any known public deployments of MAP-E? What about CPE routers
with support?

The pricing on IPv4 is now at USD 20/address so I am thinking we are forced
to go the CGN route going forward. Of all the options, MAP-E appears to be
the most elegant. Just add/remove some more headers on a packet and route
it as normal. No need to invest in anything as our core routers can already
do that. No worries about scale.

BUT - our current CPE has zero support. We are too small that they will
make this feature just for us, so I need to convince them there is going to
be a demand. Alternatively I need to find a different CPE vendor that has
MAP-E support, but are there any?

What is holding MAP-E back?  In my view MAP-E could be the end game for
IPv4. Customers get full IPv6 and enough of IPv4 to be somewhat compatible.
The ISP networks are not forced to do a lot of processing such as CGN
otherwise requires.

I read some posts from Japan where users are reporting a deployment of
MAP-E. Anyone know about that?

Regards,

Baldur


Re: MAP-E

2019-08-02 Thread Mikael Abrahamsson

On Fri, 2 Aug 2019, Baldur Norddahl wrote:

be a demand. Alternatively I need to find a different CPE vendor that 
has MAP-E support, but are there any?


Broadcom supports MAP-E and LW4o6 encap/decap in fastpath on at least 
BCM63138 with their latest BSP versions.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: MAP-E

2019-08-02 Thread JORDI PALET MARTINEZ via NANOG
Ask the vendor to support RFC8585.

 

Also, you can do it with OpenWRT.

 

I think 464XLAT is a better option and both of them are supported by OpenWRT.

 

You can also use OpenSource (Jool) for the NAT64.

 

Regards,

Jordi

@jordipalet

 

 

 

El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl"  escribió:

 

Hello

 

Are there any known public deployments of MAP-E? What about CPE routers with 
support?

 

The pricing on IPv4 is now at USD 20/address so I am thinking we are forced to 
go the CGN route going forward. Of all the options, MAP-E appears to be the 
most elegant. Just add/remove some more headers on a packet and route it as 
normal. No need to invest in anything as our core routers can already do that. 
No worries about scale.

 

BUT - our current CPE has zero support. We are too small that they will make 
this feature just for us, so I need to convince them there is going to be a 
demand. Alternatively I need to find a different CPE vendor that has MAP-E 
support, but are there any?

 

What is holding MAP-E back?  In my view MAP-E could be the end game for IPv4. 
Customers get full IPv6 and enough of IPv4 to be somewhat compatible. The ISP 
networks are not forced to do a lot of processing such as CGN otherwise 
requires.

 

I read some posts from Japan where users are reporting a deployment of MAP-E. 
Anyone know about that?

 

Regards,

 

Baldur

 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.



Re: MAP-E

2019-08-02 Thread Brian J. Murrell
On Fri, 2019-08-02 at 15:37 +0200, JORDI PALET MARTINEZ via NANOG
wrote:
> Ask the vendor to support RFC8585.
> 
>  
> 
> Also, you can do it with OpenWRT.
> 
>  
> 
> I think 464XLAT is a better option and both of them are supported by
> OpenWRT.
> 
>  
> 
> You can also use OpenSource (Jool) for the NAT64.

Will any of these (including MAP-E) support such nasty (in terms of
burying IP addresses in data payloads) protocols as FTP and SIP/SDP?

Cheers,
b.



signature.asc
Description: This is a digitally signed message part


Re: MAP-E

2019-08-02 Thread Mikael Abrahamsson

On Fri, 2 Aug 2019, Brian J. Murrell wrote:

Will any of these (including MAP-E) support such nasty (in terms of 
burying IP addresses in data payloads) protocols as FTP and SIP/SDP?


LW4o6 is regular NAT44 and then tunnel encap. MAP-E is similar.

So if there is NAT44 helper for these protocols then it should work the 
same as if you just had NAT44.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: MAP-E

2019-08-02 Thread Aled Morris via NANOG
On Fri, 2 Aug 2019 at 14:49, Brian J. Murrell  wrote:

> Will any of these (including MAP-E) support such nasty (in terms of
> burying IP addresses in data payloads) protocols as FTP and SIP/SDP?
>

I'm a fan of these solutions that (only) use NAT44 in the CPE as this is
exactly what they're currently doing, and the CPE vendors have already
"solved" the problem of  application support (SIP, FTP etc.) at least as
far as the end-user is concerned.

It seems that introducing an extra layer of NAT at the ISP for NAT444 is
creating a range of new problems, not least being scalability.  Big CGNAT
boxes are expensive.

Aled


Re: Phoenix IX down/gone?

2019-08-02 Thread Adrian
On Thursday 01 August 2019 14:48:53 Peter Kranz via NANOG wrote:
> Anyone know what happened to Phoenix IX? https://peeringdb.com/ix/66 They
> seem off the air including website and phones.. permanently?
> 

$DAYJOB is peered and passes traffic thru there. I don't have full access to 
check but it looks like traffic is flowing thru the peer points currently, for 
thing like MSN/OWA/etc. I can ping and reach peers, but all traceroute thru 
the peering point seems to now stop at the border. Maybe they added some sort 
of filtering and hosed themselves? Not sure.

Adrian



Phoenix IX down/gone?

2019-08-02 Thread Paul Emmons
VoIP is up and running but the web site server crashed.  Currently
restoring server.

Voice number 602 688-6414

~Paul


Re: The future of transport in the metro area

2019-08-02 Thread Etienne-Victor Depasquale
Mark, when you write "There is a healthy sharing of the pie between DWDM
and packet to drive these Ethernet Metro's ", can you elaborate a little?
Are you referring specifically to EoDWDM, or do you have something else in
mind?

Etienne

On Fri, Aug 2, 2019 at 10:10 AM Mark Tinka  wrote:

> And just to add that I think that as part of the future, 5G is likely to
> play a big part as well, somewhere between the Metro and the Access.
>
> Mark.
>


-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale


Re: MAP-E

2019-08-02 Thread Baldur Norddahl
On Fri, Aug 2, 2019 at 3:49 PM Brian J. Murrell 
wrote:

>
> Will any of these (including MAP-E) support such nasty (in terms of
> burying IP addresses in data payloads) protocols as FTP and SIP/SDP?
>
>

All MAP-E does is reserving a port range for each customer. So customer A
might be assigned port range 2000-2999, customer B gets 3000-3999 etc. The
traffic is then routed to the correct customer using port range in addition
to the destination IP address. This is done by encapsulating the original
IPv4 packet in an IPv6 tunnel packet.

Multiple customers share an IPv4 address each with an assigned port range.

The customer CPE router does what it has always done. It does the NAT
function but is restricted to only use the port numbers assigned. Therefore
anything that works today will continue to work, providing it does not
require access to hard coded port numbers. So customer A can not run a web
server on port 80. But he could run a web server on port 2080 if he wanted
to. Of course few customers are going to run inbound services with this
setup.

NAT helpers on the CPE for FTP and SIP should work as expected.

I like the approach because no actual NAT is going on in the ISP network.
It is almost the same as dual stack except a few bits of the port number is
used for routing purposes. You need a device to do the MAP encapsulation
but everything else in your network only has to do ordinary IPv6. Many core
routers have MAP support now, so you might not even need a dedicated MAP
encapsulation device.

Regards,

Baldur


Re: MAP-E

2019-08-02 Thread Baldur Norddahl
Hi Jordi

My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to
avoid the expense and operative nightmare of having to run a redundant NAT
server setup with thousands of users. MAP is the only alternative that
avoids a provider run NAT server.

Regards,

Baldur


On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG <
nanog@nanog.org> wrote:

> Ask the vendor to support RFC8585.
>
>
>
> Also, you can do it with OpenWRT.
>
>
>
> I think 464XLAT is a better option and both of them are supported by
> OpenWRT.
>
>
>
> You can also use OpenSource (Jool) for the NAT64.
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl" <
> nanog-boun...@nanog.org en nombre de baldur.nordd...@gmail.com> escribió:
>
>
>
> Hello
>
>
>
> Are there any known public deployments of MAP-E? What about CPE routers
> with support?
>
>
>
> The pricing on IPv4 is now at USD 20/address so I am thinking we are
> forced to go the CGN route going forward. Of all the options, MAP-E appears
> to be the most elegant. Just add/remove some more headers on a packet and
> route it as normal. No need to invest in anything as our core routers can
> already do that. No worries about scale.
>
>
>
> BUT - our current CPE has zero support. We are too small that they will
> make this feature just for us, so I need to convince them there is going to
> be a demand. Alternatively I need to find a different CPE vendor that has
> MAP-E support, but are there any?
>
>
>
> What is holding MAP-E back?  In my view MAP-E could be the end game for
> IPv4. Customers get full IPv6 and enough of IPv4 to be somewhat compatible.
> The ISP networks are not forced to do a lot of processing such as CGN
> otherwise requires.
>
>
>
> I read some posts from Japan where users are reporting a deployment of
> MAP-E. Anyone know about that?
>
>
>
> Regards,
>
>
>
> Baldur
>
>
>
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>


Re: MAP-E

2019-08-02 Thread JORDI PALET MARTINEZ via NANOG
I understand that, but the inconvenient is the fix allocation of ports per 
client, and not all the clients use the same number of ports. Every option has 
good and bad things.

 

MAP is less efficient in terms of maximizing the “use” of the existing IPv4 
addresses.

 

https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl"  escribió:

 

Hi Jordi

 

My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to avoid 
the expense and operative nightmare of having to run a redundant NAT server 
setup with thousands of users. MAP is the only alternative that avoids a 
provider run NAT server.

 

Regards,

 

Baldur

 

 

On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG  
wrote:

Ask the vendor to support RFC8585.

 

Also, you can do it with OpenWRT.

 

I think 464XLAT is a better option and both of them are supported by OpenWRT.

 

You can also use OpenSource (Jool) for the NAT64.

 

Regards,

Jordi

@jordipalet

 

 

 

El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl"  escribió:

 

Hello

 

Are there any known public deployments of MAP-E? What about CPE routers with 
support?

 

The pricing on IPv4 is now at USD 20/address so I am thinking we are forced to 
go the CGN route going forward. Of all the options, MAP-E appears to be the 
most elegant. Just add/remove some more headers on a packet and route it as 
normal. No need to invest in anything as our core routers can already do that. 
No worries about scale.

 

BUT - our current CPE has zero support. We are too small that they will make 
this feature just for us, so I need to convince them there is going to be a 
demand. Alternatively I need to find a different CPE vendor that has MAP-E 
support, but are there any?

 

What is holding MAP-E back?  In my view MAP-E could be the end game for IPv4. 
Customers get full IPv6 and enough of IPv4 to be somewhat compatible. The ISP 
networks are not forced to do a lot of processing such as CGN otherwise 
requires.

 

I read some posts from Japan where users are reporting a deployment of MAP-E. 
Anyone know about that?

 

Regards,

 

Baldur

 


**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.



Re: MAP-E

2019-08-02 Thread Bryan Holloway




On 8/2/19 5:16 PM, Baldur Norddahl wrote:


Multiple customers share an IPv4 address each with an assigned port range.




One downside that has been brought up on the list before is that a DDoS 
attack against a single subscriber will impact many, but that particular 
drawback may not outweigh the benefits (costs).




Re: MAP-E

2019-08-02 Thread Jay Hanke
Is there a summary presentation someplace laying out the options that
are active in the wild with some deployment stats?

On Fri, Aug 2, 2019 at 10:34 AM JORDI PALET MARTINEZ via NANOG
 wrote:
>
> I understand that, but the inconvenient is the fix allocation of ports per 
> client, and not all the clients use the same number of ports. Every option 
> has good and bad things.
>
>
>
> MAP is less efficient in terms of maximizing the “use” of the existing IPv4 
> addresses.
>
>
>
> https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/
>
>
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl" 
>  escribió:
>
>
>
> Hi Jordi
>
>
>
> My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to avoid 
> the expense and operative nightmare of having to run a redundant NAT server 
> setup with thousands of users. MAP is the only alternative that avoids a 
> provider run NAT server.
>
>
>
> Regards,
>
>
>
> Baldur
>
>
>
>
>
> On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG 
>  wrote:
>
> Ask the vendor to support RFC8585.
>
>
>
> Also, you can do it with OpenWRT.
>
>
>
> I think 464XLAT is a better option and both of them are supported by OpenWRT.
>
>
>
> You can also use OpenSource (Jool) for the NAT64.
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl" 
>  escribió:
>
>
>
> Hello
>
>
>
> Are there any known public deployments of MAP-E? What about CPE routers with 
> support?
>
>
>
> The pricing on IPv4 is now at USD 20/address so I am thinking we are forced 
> to go the CGN route going forward. Of all the options, MAP-E appears to be 
> the most elegant. Just add/remove some more headers on a packet and route it 
> as normal. No need to invest in anything as our core routers can already do 
> that. No worries about scale.
>
>
>
> BUT - our current CPE has zero support. We are too small that they will make 
> this feature just for us, so I need to convince them there is going to be a 
> demand. Alternatively I need to find a different CPE vendor that has MAP-E 
> support, but are there any?
>
>
>
> What is holding MAP-E back?  In my view MAP-E could be the end game for IPv4. 
> Customers get full IPv6 and enough of IPv4 to be somewhat compatible. The ISP 
> networks are not forced to do a lot of processing such as CGN otherwise 
> requires.
>
>
>
> I read some posts from Japan where users are reporting a deployment of MAP-E. 
> Anyone know about that?
>
>
>
> Regards,
>
>
>
> Baldur
>
>
>
>
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or 
> confidential. The information is intended to be for the exclusive use of the 
> individual(s) named above and further non-explicilty authorized disclosure, 
> copying, distribution or use of the contents of this information, even if 
> partially, including attached files, is strictly prohibited and will be 
> considered a criminal offense. If you are not the intended recipient be aware 
> that any disclosure, copying, distribution or use of the contents of this 
> information, even if partially, including attached files, is strictly 
> prohibited, will be considered a criminal offense, so you must reply to the 
> original sender to inform about this communication and delete it.
>
>
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or 
> confidential. The information is intended to be for the exclusive use of the 
> individual(s) named above and further non-explicilty authorized disclosure, 
> copying, distribution or use of the contents of this information, even if 
> partially, including attached files, is strictly prohibited and will be 
> considered a criminal offense. If you are not the intended recipient be aware 
> that any disclosure, copying, distribution or use of the contents of this 
> information, even if partially, including attached files, is strictly 
> prohibited, will be considered a criminal offense, so you must reply to the 
> original sender to inform about this communication and delete it.
>


Re: MAP-E

2019-08-02 Thread Baldur Norddahl
On Fri, Aug 2, 2019 at 5:33 PM Bryan Holloway  wrote:

>
>
> On 8/2/19 5:16 PM, Baldur Norddahl wrote:
> >
> > Multiple customers share an IPv4 address each with an assigned port
> range.
> >
>
>
> One downside that has been brought up on the list before is that a DDoS
> attack against a single subscriber will impact many, but that particular
> drawback may not outweigh the benefits (costs).
>
>

That is true for every CGN solution. At least with MAP the DDoS will only
hit multiple users if the attackers hit random port numbers.

Regards,

Baldur


contact from AS 45382

2019-08-02 Thread Ricardo Patara
hi,
any contact from ASN 45382 in the list?

it seems one of its customers is announcing a ipv4 block allocated to
other organization.

the 45.164.24.0/24 is part of a /22 allocated to a brazilian
organization and it is currently being announced with origin in the
45382 and transit via 4766, both in Korea.

thanks


OT: Tech bag

2019-08-02 Thread Dovid Bender
Hi,

Sorry for the OT email. I travel extensively to DC's and my computer bag
seems to keep collecting more tools which includes your usual console
cables, spare everything, two laptops etc. My Swissgear has been taking a
beating and I was wondering what others who have to lug around 30-35 pounds
use.

TIA.


Re: OT: Tech bag

2019-08-02 Thread Hunter Fuller
I carry this. It's a preference I gained in my past life:
https://www.kleintools.com/catalog/tool-storage/tradesman-pro-backpack

I put my notebook (Surface Pro) in a sleeve and sandwich it between
the halves. It hasn't gotten crushed to death yet. I'll admit this is
not optimal.

This one has since been released, and it has a laptop compartment. My
co-worker loves it:
https://www.kleintools.com/catalog/tradesman-pro-organizers/tradesman-pro-tech-backpack

On Fri, Aug 2, 2019 at 11:14 AM Dovid Bender  wrote:
>
> Hi,
>
> Sorry for the OT email. I travel extensively to DC's and my computer bag 
> seems to keep collecting more tools which includes your usual console cables, 
> spare everything, two laptops etc. My Swissgear has been taking a beating and 
> I was wondering what others who have to lug around 30-35 pounds use.
>
> TIA.
>
>


Re: MAP-E

2019-08-02 Thread Baldur Norddahl
The goal is to minimize cost. Assuming 4 bits for the MAP routing (16 users
sharing one IPv4), leaving 12 bits for customer ports (4096 ports) and a
current price of USD 20 per IPv4 address, this gives a cost of USD 1.25 per
user for a fully redundant solution. For us it is even cheaper as we can
recirculate existing address space.

Regards,

Baldur


On Fri, Aug 2, 2019 at 5:32 PM JORDI PALET MARTINEZ <
jordi.pa...@consulintel.es> wrote:

> I understand that, but the inconvenient is the fix allocation of ports per
> client, and not all the clients use the same number of ports. Every option
> has good and bad things.
>
>
>
> MAP is less efficient in terms of maximizing the “use” of the existing
> IPv4 addresses.
>
>
>
> https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/
>
>
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl" <
> nanog-boun...@nanog.org en nombre de baldur.nordd...@gmail.com> escribió:
>
>
>
> Hi Jordi
>
>
>
> My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to
> avoid the expense and operative nightmare of having to run a redundant NAT
> server setup with thousands of users. MAP is the only alternative that
> avoids a provider run NAT server.
>
>
>
> Regards,
>
>
>
> Baldur
>
>
>
>
>
> On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG <
> nanog@nanog.org> wrote:
>
> Ask the vendor to support RFC8585.
>
>
>
> Also, you can do it with OpenWRT.
>
>
>
> I think 464XLAT is a better option and both of them are supported by
> OpenWRT.
>
>
>
> You can also use OpenSource (Jool) for the NAT64.
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl" <
> nanog-boun...@nanog.org en nombre de baldur.nordd...@gmail.com> escribió:
>
>
>
> Hello
>
>
>
> Are there any known public deployments of MAP-E? What about CPE routers
> with support?
>
>
>
> The pricing on IPv4 is now at USD 20/address so I am thinking we are
> forced to go the CGN route going forward. Of all the options, MAP-E appears
> to be the most elegant. Just add/remove some more headers on a packet and
> route it as normal. No need to invest in anything as our core routers can
> already do that. No worries about scale.
>
>
>
> BUT - our current CPE has zero support. We are too small that they will
> make this feature just for us, so I need to convince them there is going to
> be a demand. Alternatively I need to find a different CPE vendor that has
> MAP-E support, but are there any?
>
>
>
> What is holding MAP-E back?  In my view MAP-E could be the end game for
> IPv4. Customers get full IPv6 and enough of IPv4 to be somewhat compatible.
> The ISP networks are not forced to do a lot of processing such as CGN
> otherwise requires.
>
>
>
> I read some posts from Japan where users are reporting a deployment of
> MAP-E. Anyone know about that?
>
>
>
> Regards,
>
>
>
> Baldur
>
>
>
>
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>


Removing defunct IRR records from LEVEL3 rr

2019-08-02 Thread Tim Howe
Has anyone successfully gotten Level3/Centurylink to remove defunct IRR
objects?  All paths seem to lead to trying to get me to log into a
customer portal.  If they have incorrect objects for IP resources I
control, how am I supposed to get them cleaned up if I am not a
customer?

--TimH


Re: MAP-E

2019-08-02 Thread JORDI PALET MARTINEZ via NANOG
The cost of sharing IPs in a static way, is that services such as Sony 
Playstation Network will put those addresses in the black list, so you need to 
buy more addresses. This hasn’t been the case for 464XLAT/NAT64, which shares 
the addresses dynamically.

 

Furthermore, if some users need less ports than others, you “infra-utilize” 
those addresses, which again is not the case for 464XLAT/NAT64. Each user gets 
automatically as many ports as he needs at every moment.

 

So, you save money in terms of addresses, that you can invest in a couple of 
servers running a redundant NAT64 setup 
(https://www.jool.mx/en/session-synchronization.html). Those servers can be 
actually VMs, so you don’t need dedicated hardware, especially because when you 
deploy IPv6 with 464XLAT, typically 75% (and going up) of you traffic will be 
IPv6 and only 25% will go thru the NAT64.

 

Regards,

Jordi

@jordipalet

 

 

 

El 2/8/19 18:24, "NANOG en nombre de Baldur Norddahl"  escribió:

 

The goal is to minimize cost. Assuming 4 bits for the MAP routing (16 users 
sharing one IPv4), leaving 12 bits for customer ports (4096 ports) and a 
current price of USD 20 per IPv4 address, this gives a cost of USD 1.25 per 
user for a fully redundant solution. For us it is even cheaper as we can 
recirculate existing address space.

 

Regards,

 

Baldur

 

 

On Fri, Aug 2, 2019 at 5:32 PM JORDI PALET MARTINEZ 
 wrote:

I understand that, but the inconvenient is the fix allocation of ports per 
client, and not all the clients use the same number of ports. Every option has 
good and bad things.

 

MAP is less efficient in terms of maximizing the “use” of the existing IPv4 
addresses.

 

https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl"  escribió:

 

Hi Jordi

 

My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to avoid 
the expense and operative nightmare of having to run a redundant NAT server 
setup with thousands of users. MAP is the only alternative that avoids a 
provider run NAT server.

 

Regards,

 

Baldur

 

 

On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG  
wrote:

Ask the vendor to support RFC8585.

 

Also, you can do it with OpenWRT.

 

I think 464XLAT is a better option and both of them are supported by OpenWRT.

 

You can also use OpenSource (Jool) for the NAT64.

 

Regards,

Jordi

@jordipalet

 

 

 

El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl"  escribió:

 

Hello

 

Are there any known public deployments of MAP-E? What about CPE routers with 
support?

 

The pricing on IPv4 is now at USD 20/address so I am thinking we are forced to 
go the CGN route going forward. Of all the options, MAP-E appears to be the 
most elegant. Just add/remove some more headers on a packet and route it as 
normal. No need to invest in anything as our core routers can already do that. 
No worries about scale.

 

BUT - our current CPE has zero support. We are too small that they will make 
this feature just for us, so I need to convince them there is going to be a 
demand. Alternatively I need to find a different CPE vendor that has MAP-E 
support, but are there any?

 

What is holding MAP-E back?  In my view MAP-E could be the end game for IPv4. 
Customers get full IPv6 and enough of IPv4 to be somewhat compatible. The ISP 
networks are not forced to do a lot of processing such as CGN otherwise 
requires.

 

I read some posts from Japan where users are reporting a deployment of MAP-E. 
Anyone know about that?

 

Regards,

 

Baldur

 


**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.


**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
par

Re: OT: Tech bag

2019-08-02 Thread James Downs
On Fri, Aug 02, 2019 at 11:19:08AM -0500, Hunter Fuller wrote:

> This one has since been released, and it has a laptop compartment. My

Yeah, I definitely look for some sort of laptop compartment. If not
padded on its own, I stick the laptop into a padded sleeve. I run one
of these: https://tacticalgear.com/511-all-hazards-prime-backpack-black

And subdivide for a particular loadout with various smaller cases like:
https://countycomm.com/collections/view-all-storage-products/products/apx-multi-purpose-dual-zip-case-by-maratac

or something similar to these: 
https://www.casesbysource.com/category/soft-padded-cases

Unfortunately Deep Outdoors, who made a number of great soft-sided padded cases
has gone out of business...



Re: OT: Tech bag

2019-08-02 Thread Laszlo Hanyecz




On 2019-08-02 16:42, James Downs wrote:

On Fri, Aug 02, 2019 at 11:19:08AM -0500, Hunter Fuller wrote:


This one has since been released, and it has a laptop compartment. My

Yeah, I definitely look for some sort of laptop compartment. If not
padded on its own, I stick the laptop into a padded sleeve. I run one
of these: https://tacticalgear.com/511-all-hazards-prime-backpack-black

And subdivide for a particular loadout with various smaller cases like:
https://countycomm.com/collections/view-all-storage-products/products/apx-multi-purpose-dual-zip-case-by-maratac

or something similar to these: 
https://www.casesbysource.com/category/soft-padded-cases

Unfortunately Deep Outdoors, who made a number of great soft-sided padded cases
has gone out of business...



I use GORUCK GR1
https://www.goruck.com/gr1
It has a padded laptop compartment.

-Laszlo



Weekly Routing Table Report

2019-08-02 Thread Routing Analysis Role Account
This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 03 Aug, 2019

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  766119
Prefixes after maximum aggregation (per Origin AS):  295002
Deaggregation factor:  2.60
Unique aggregates announced (without unneeded subnets):  368513
Total ASes present in the Internet Routing Table: 65068
Prefixes per ASN: 11.77
Origin-only ASes present in the Internet Routing Table:   55956
Origin ASes announcing only one prefix:   23986
Transit ASes present in the Internet Routing Table:9112
Transit-only ASes present in the Internet Routing Table:287
Average AS path length visible in the Internet Routing Table:   4.5
Max AS path length visible:  42
Max AS path prepend of ASN ( 27978)  31
Prefixes from unregistered ASNs in the Routing Table:24
Number of instances of unregistered ASNs:24
Number of 32-bit ASNs allocated by the RIRs:  28103
Number of 32-bit ASNs visible in the Routing Table:   22950
Prefixes from 32-bit ASNs in the Routing Table:  103973
Number of bogon 32-bit ASNs visible in the Routing Table:14
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:286
Number of addresses announced to Internet:   2842112000
Equivalent to 169 /8s, 103 /16s and 48 /24s
Percentage of available address space announced:   76.8
Percentage of allocated address space announced:   76.8
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.3
Total number of prefixes smaller than registry allocations:  256375

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   206466
Total APNIC prefixes after maximum aggregation:   61655
APNIC Deaggregation factor:3.35
Prefixes being announced from the APNIC address blocks:  201513
Unique aggregates announced from the APNIC address blocks:84021
APNIC Region origin ASes present in the Internet Routing Table:9933
APNIC Prefixes per ASN:   20.29
APNIC Region origin ASes announcing only one prefix:   2753
APNIC Region transit ASes present in the Internet Routing Table:   1480
Average APNIC Region AS path length visible:4.6
Max APNIC Region AS path length visible: 27
Number of APNIC region 32-bit ASNs visible in the Routing Table:   4936
Number of APNIC addresses announced to Internet:  771136640
Equivalent to 45 /8s, 246 /16s and 156 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-141625
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:226639
Total ARIN prefixes after maximum aggregation:   105937
ARIN Deaggregation factor: 2.14
Prefixes being announced from the ARIN address blocks:   225670
Unique aggregates announced from the ARIN address blocks:107080
ARIN Region origin ASes present in the Internet Routing Table:18544
ARIN Prefixes per ASN:12.17
ARIN Regi

Re: The future of transport in the metro area

2019-08-02 Thread Etienne-Victor Depasquale
Bear with me one more time as I drill down a little and spell things out.
I've realized that there may be more than one interpretation of "EoDWDM".
Are you referring to:

(a) Ethernet packets in OTU frames - thereby implying an underlying OTN?

(b) Ethernet optical SFP+ transceivers with a cable connection into a
transponder plugging into a DWDM Mux or DWDM OADM? (no circuit transport)



On Fri, Aug 2, 2019 at 10:32 AM Mark Tinka  wrote:

>
>
> On 2/Aug/19 10:17, Etienne-Victor Depasquale wrote:
>
> > Mark, when you write "There is a healthy sharing of the pie between
> > DWDM and packet to drive these Ethernet Metro's ", can you elaborate a
> > little? Are you referring specifically to EoDWDM, or do you have
> > something else in mind?
>
> EoDWDM.
>
> Ethernet is very widely used, regardless of the Transport technology.
>
> In other markets, you will find SDH Transports delivering Ethernet as
> well (EoSDH), although that is dying in favour of EoDWDM or just
> Ethernet over (dark) fibre.
>
> Mark.
>


-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale


Re: Removing defunct IRR records from LEVEL3 rr

2019-08-02 Thread Michael Davis

I recently did this with an email to rout...@level3.net

Took all of a few hours, no issues..

thanks
mike

On 8/2/19 12:24 PM, Tim Howe wrote:

Has anyone successfully gotten Level3/Centurylink to remove defunct IRR
objects?  All paths seem to lead to trying to get me to log into a
customer portal.  If they have incorrect objects for IP resources I
control, how am I supposed to get them cleaned up if I am not a
customer?

--TimH



--
 Mike Davis
 Manager, Network Routing and Switching
 IT - University of Delaware  - 302.831.8756
 Newark, DE  19716 Email da...@udel.edu



Re: OT: Tech bag

2019-08-02 Thread John Covici
https://www.tombin.com has some great bags for laptops, etc.  Not
cheap but very good stuff.

On Fri, 02 Aug 2019 12:19:08 -0400,
Hunter Fuller wrote:
> 
> I carry this. It's a preference I gained in my past life:
> https://www.kleintools.com/catalog/tool-storage/tradesman-pro-backpack
> 
> I put my notebook (Surface Pro) in a sleeve and sandwich it between
> the halves. It hasn't gotten crushed to death yet. I'll admit this is
> not optimal.
> 
> This one has since been released, and it has a laptop compartment. My
> co-worker loves it:
> https://www.kleintools.com/catalog/tradesman-pro-organizers/tradesman-pro-tech-backpack
> 
> On Fri, Aug 2, 2019 at 11:14 AM Dovid Bender  wrote:
> >
> > Hi,
> >
> > Sorry for the OT email. I travel extensively to DC's and my computer bag 
> > seems to keep collecting more tools which includes your usual console 
> > cables, spare everything, two laptops etc. My Swissgear has been taking a 
> > beating and I was wondering what others who have to lug around 30-35 pounds 
> > use.
> >
> > TIA.
> >
> >
> 

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici wb2una
 cov...@ccs.covici.com


Re: Removing defunct IRR records from LEVEL3 rr

2019-08-02 Thread Christopher Morrow
agree with michael, they were super helpful to me over the last few months.

On Fri, Aug 2, 2019 at 2:18 PM Michael Davis  wrote:
>
> I recently did this with an email to rout...@level3.net
>
> Took all of a few hours, no issues..
>
> thanks
> mike
>
> On 8/2/19 12:24 PM, Tim Howe wrote:
> > Has anyone successfully gotten Level3/Centurylink to remove defunct IRR
> > objects?  All paths seem to lead to trying to get me to log into a
> > customer portal.  If they have incorrect objects for IP resources I
> > control, how am I supposed to get them cleaned up if I am not a
> > customer?
> >
> > --TimH
>
>
> --
>   Mike Davis
>   Manager, Network Routing and Switching
>   IT - University of Delaware  - 302.831.8756
>   Newark, DE  19716 Email da...@udel.edu
>


Re: OT: Tech bag

2019-08-02 Thread Christopher Morrow
On Fri, Aug 2, 2019 at 2:50 PM John Covici  wrote:
>
> https://www.tombin.com has some great bags for laptops, etc.  Not

'server has no ip address' .
$ ping www.tombin.com
PING www.tombin.com (127.0.0.1)

good try to get us all infected by malware...

On a less funny note, try out some of the various osprey bags.


> cheap but very good stuff.
>
> On Fri, 02 Aug 2019 12:19:08 -0400,
> Hunter Fuller wrote:
> >
> > I carry this. It's a preference I gained in my past life:
> > https://www.kleintools.com/catalog/tool-storage/tradesman-pro-backpack
> >
> > I put my notebook (Surface Pro) in a sleeve and sandwich it between
> > the halves. It hasn't gotten crushed to death yet. I'll admit this is
> > not optimal.
> >
> > This one has since been released, and it has a laptop compartment. My
> > co-worker loves it:
> > https://www.kleintools.com/catalog/tradesman-pro-organizers/tradesman-pro-tech-backpack
> >
> > On Fri, Aug 2, 2019 at 11:14 AM Dovid Bender  wrote:
> > >
> > > Hi,
> > >
> > > Sorry for the OT email. I travel extensively to DC's and my computer bag 
> > > seems to keep collecting more tools which includes your usual console 
> > > cables, spare everything, two laptops etc. My Swissgear has been taking a 
> > > beating and I was wondering what others who have to lug around 30-35 
> > > pounds use.
> > >
> > > TIA.
> > >
> > >
> >
>
> --
> Your life is like a penny.  You're going to lose it.  The question is:
> How do
> you spend it?
>
>  John Covici wb2una
>  cov...@ccs.covici.com


Re: OT: Tech bag

2019-08-02 Thread Andrew Latham
Correct url may be https://www.tombihn.com/

On Fri, Aug 2, 2019 at 1:50 PM John Covici  wrote:

> https://www.tombin.com has some great bags for laptops, etc.  Not
> cheap but very good stuff.
>
> On Fri, 02 Aug 2019 12:19:08 -0400,
> Hunter Fuller wrote:
> >
> > I carry this. It's a preference I gained in my past life:
> > https://www.kleintools.com/catalog/tool-storage/tradesman-pro-backpack
> >
> > I put my notebook (Surface Pro) in a sleeve and sandwich it between
> > the halves. It hasn't gotten crushed to death yet. I'll admit this is
> > not optimal.
> >
> > This one has since been released, and it has a laptop compartment. My
> > co-worker loves it:
> >
> https://www.kleintools.com/catalog/tradesman-pro-organizers/tradesman-pro-tech-backpack
> >
> > On Fri, Aug 2, 2019 at 11:14 AM Dovid Bender 
> wrote:
> > >
> > > Hi,
> > >
> > > Sorry for the OT email. I travel extensively to DC's and my computer
> bag seems to keep collecting more tools which includes your usual console
> cables, spare everything, two laptops etc. My Swissgear has been taking a
> beating and I was wondering what others who have to lug around 30-35 pounds
> use.
> > >
> > > TIA.
> > >
> > >
> >
>
> --
> Your life is like a penny.  You're going to lose it.  The question is:
> How do
> you spend it?
>
>  John Covici wb2una
>  cov...@ccs.covici.com
>


-- 
- Andrew "lathama" Latham -


Re: The future of transport in the metro area

2019-08-02 Thread Mark Tinka



On 2/Aug/19 20:06, Etienne-Victor Depasquale wrote:
> Bear with me one more time as I drill down a little and spell things
> out. I've realized that there may be more than one interpretation of
> "EoDWDM". Are you referring to:
>
> (a) Ethernet packets in OTU frames - thereby implying an underlying OTN?
>
> (b) Ethernet optical SFP+ transceivers with a cable connection into a
> transponder plugging into a DWDM Mux or DWDM OADM? (no circuit transport)

Either one would count as EoDWDM, in my book.

The general use-case for OTN is to have SDH/SONET-like OAM
characteristics, but over the DWDM network.

In basic deployments, there was a time when folk argued about whether
they take LAN-PHY or WAN-PHY EoDWDM services from providers. The OTN vs.
DWDM discussion kind of falls around there, in my opinion. Considering
that almost all use-cases for EoDWDM are into router ports, where basic
day-to-day Ethernet is the cheapest and simplest option, I haven't heard
of any customers asking for WAN-PHY or OTN in the last 3 years. Not on
our network at least, anyway...

I think the costs of WAN-PHY/OTN re: OAM have been outweighed by making
the right choice in choosing an operator that is able to deliver an SLA,
back it up, and have a NOC that works well.

Now, the next step in all this that is starting to gain a bit of
traction is "spectrum", i.e., rather than take a normal grey service
from a Transport operator, have them deliver you a portion of the DWDM
spectrum so that you can run as much bandwidth as you want over their
network. Think of it as dark fibre, but lit...

Mark.



Re: OT: Tech bag

2019-08-02 Thread Pete Baldwin - TCC
I use a Veto Pro Pac 

https://www.vetopropac.com/product/tech-pac-lt/

More focused on tools, but it fits my Thinkpad p50 without issue, all of my 
cables, and most of the tools that I use day to day.   

I used to use more tactical focused backpacks but I kept ripping compartments 
or breaking zippers.  This thing has held up really well so far.  


-- 

Tuckersmith Communications
IT Manager
O: 519-565-2400
F: 519-565-2477
C: 519-441-7383


On August 2, 2019 12:14:33 p.m. EDT, Dovid Bender  wrote:
>Hi,
>
>Sorry for the OT email. I travel extensively to DC's and my computer
>bag
>seems to keep collecting more tools which includes your usual console
>cables, spare everything, two laptops etc. My Swissgear has been taking
>a
>beating and I was wondering what others who have to lug around 30-35
>pounds
>use.
>
>TIA.


Re: OT: Tech bag

2019-08-02 Thread Valdis Klētnieks
On Fri, 02 Aug 2019 14:54:49 -0400, Christopher Morrow said:
> 'server has no ip address' .
> $ ping www.tombin.com
> PING www.tombin.com (127.0.0.1)
>
> good try to get us all infected by malware...

Anybody who gets infected by malware from that IP address has bigger 
problems





pgpsARxK0jKqb.pgp
Description: PGP signature


Re: OT: Tech bag

2019-08-02 Thread Christopher Morrow
On Fri, Aug 2, 2019 at 5:01 PM Valdis Klētnieks  wrote:
>
> On Fri, 02 Aug 2019 14:54:49 -0400, Christopher Morrow said:
> > 'server has no ip address' .
> > $ ping www.tombin.com
> > PING www.tombin.com (127.0.0.1)
> >
> > good try to get us all infected by malware...
>
> Anybody who gets infected by malware from that IP address has bigger 
> problems

https://media.giphy.com/media/6iLiUnuthOSu4/giphy.gif

>
>


Spam due to new ARIN allocation

2019-08-02 Thread Tim Burke
We recently received a new ASN from ARIN - you know what that means... the 
sales vultures come out to play!

So far, it has resulted in spam from Cogent (which is, of course, to be 
expected), and now another company called "CapCon Networks" - 
http://www.capconnetworks.com. As far as I am aware, this practice is against 
ARIN's Terms of Use. Is it worth reporting to ARIN, or perhaps it's worth 
creating a List of People To Never Do Business With™, complete with these 
jokers, and other vultures that engage in similar tactics? 

Regards,
Tim Burke
t...@burke.us


Re: Spam due to new ARIN allocation

2019-08-02 Thread Brandon Martin

On 8/2/19 7:32 PM, Tim Burke wrote:

So far, it has resulted in spam from Cogent (which is, of course, to be expected), and 
now another company called "CapCon Networks" -http://www.capconnetworks.com. As 
far as I am aware, this practice is against ARIN's Terms of Use. Is it worth reporting to 
ARIN, or perhaps it's worth creating a List of People To Never Do Business With™, 
complete with these jokers, and other vultures that engage in similar tactics?


I'm not sure what you can really do to prevent it.  It's the pain of 
having publicly available whois data which I'd argue the usefulness of, 
especially for ASNs, outweighs the spam potential for.


Just bin it and don't do business with them.

And yes, "CapCon Networks" also contacted me in a similar situation. 
You can imagine how much I want to do business with them...  Name and 
shame, I guess.

--
Brandon Martin


Re: Spam due to new ARIN allocation

2019-08-02 Thread Ryan Hamel
>
> Do it. I'd name and shame all of them.

Ryan

On Fri, Aug 2, 2019, 4:33 PM Tim Burke  wrote:
>
>> We recently received a new ASN from ARIN - you know what that means...
>> the sales vultures come out to play!
>>
>> So far, it has resulted in spam from Cogent (which is, of course, to be
>> expected), and now another company called "CapCon Networks" -
>> http://www.capconnetworks.com. As far as I am aware, this practice is
>> against ARIN's Terms of Use. Is it worth reporting to ARIN, or perhaps it's
>> worth creating a List of People To Never Do Business With™, complete with
>> these jokers, and other vultures that engage in similar tactics?
>>
>> Regards,
>> Tim Burke
>> t...@burke.us
>>
>


Re: OT: Tech bag

2019-08-02 Thread Brian Knight
About a year ago, I switched from a Swissgear to a High Sierra Endeavor wheeled 
backpack and been very happy with it. Most of the time I carry < 15 lbs of gear 
when I commute to the office on the train, so I’ll have it on my back. But when 
I head to the colo with a heavy load, it’s handy (and a real relief to my neck 
and shoulders) to be able to switch to wheeled mode. It’s held an ASR920 + 
laptop + hardware + usual load with a bit of room to spare.

HTH,

-Brian

> On Aug 2, 2019, at 11:14 AM, Dovid Bender  wrote:
> 
> Hi,
> 
> Sorry for the OT email. I travel extensively to DC's and my computer bag 
> seems to keep collecting more tools which includes your usual console cables, 
> spare everything, two laptops etc. My Swissgear has been taking a beating and 
> I was wondering what others who have to lug around 30-35 pounds use.
> 
> TIA.
> 
>  



Re: The future of transport in the metro area

2019-08-02 Thread Brandon Martin

On 8/2/19 4:10 PM, Mark Tinka wrote:

Now, the next step in all this that is starting to gain a bit of
traction is "spectrum", i.e., rather than take a normal grey service
from a Transport operator, have them deliver you a portion of the DWDM
spectrum so that you can run as much bandwidth as you want over their
network. Think of it as dark fibre, but lit...


How are they handling optical power balancing across amplifiers and 
such?  Do they just trust the customer to provide light at the power 
levels agreed upon?  Bulk attenuate the entire "spectrum" automatically? 
 Monitor and drop the whole lot if something is out of whack and 
causing saturation or gain balance problems for others?


Or is this something you're only seeing at metro distances where 
separate amplifiers are superfluous?  I've inquired with a few metro 
operators in my area about something like this, albeit a few years ago, 
and I got a pretty hard "no way we'd ever do that" out of them 
presumably for the reasons above.

--
Brandon Martin


Re: MAP-E

2019-08-02 Thread Masataka Ohta

Brian J. Murrell wrote:


You can also use OpenSource (Jool) for the NAT64.


Will any of these (including MAP-E) support such nasty (in terms of 
burying IP addresses in data payloads) protocols as FTP and SIP/SDP?


Are you saying ICMP and DNS nasty?

As DNS protocol is still actively maintained, keeping NAT gateways
transparent to DNS is not easy.


Aled Morris via NANOG wrote:


I'm a fan of these solutions that (only) use NAT44 in the CPE as this
is exactly what they're currently doing, and the CPE vendors have
already "solved" the problem of  application support (SIP, FTP etc.)
at least as far as the end-user is concerned.


It's better to modify NAT to preserve the end to end transparency.
See draft-ohta-e2e-nat-00 for details.


JORDI PALET MARTINEZ via NANOG wrote:

The cost of sharing IPs in a static way, is that services such as 
SonyPlaystation Network will put those addresses in the black list, 
so you need to buy more addresses. This hasn’t been the case for 
464XLAT/NAT64, which shares the addresses dynamically.


A problem of dynamic sharing is that logging information to be
used for such purposes as crime investigation becomes huge.

Furthermore, if some users need less ports than others, you 
"infra-utilize" those addresses,


Users needing more ports should pay more money and share an
IP address with smaller number of users.

which again is not the case for 464XLAT/NAT64. Each user gets 
automatically as many ports as he needs at every moment.


Unless all the ports are used up.

Thus, even with dynamic port assignment, users needing more
ports should pay more money and share an IP address with
smaller number of users.

Masataka Ohta