- Test - lists.nanog.org

colocation in Kansas City
by Tom Ammon 18 Jan '19

18 Jan '19

Does anybody here do business with Tierpoint in Kansas City? Do you recommend them? Tom -- ----------------------------------------------------------------------------- Tom Ammon M: (801) 784-2628 thomasammon(a)gmail.com -----------------------------------------------------------------------------

2 1

Anyone using AT&T's ECOMP/ONAP?
by adamv0025＠netconsultings.com 18 Jan '19

18 Jan '19

Hi gents, I'm looking for physical network services orchestration framework for network service providers that could later be used/extended to orchestrate other areas of the business (virtualized services in DC, etc..). So far it appears to me that there's no such ready-made commercial product on the market that would contain all the building blocks I'd be interested in (well especially the easy to use service designer tool). ECOMP and now OANP seem to have it all and much more I'm just curious if anyone is using it in anger (or parts of it for that matter) for orchestration/design/automation of services on physical network. I'd like to hear some stories from trenches with regards to the implementation, but I'd be also interested in your thoughts in case you just assessed the tool for implementation (why did liked not liked about it). Thank you adam netconsultings.com ::carrier-class solutions for the telecommunications industry::

4 4

RE: Your opinion on network analysis in the presence of uncertain events
by adamv0025＠netconsultings.com 18 Jan '19

18 Jan '19

> From: Mel Beckman <mel(a)beckman.org> > Sent: Wednesday, January 16, 2019 9:21 PM > > MTBF can’t be used alone to predict failure probability, because product > mortality follows the infamous “bathtub curve”. Products are as likely to fail > early in their lives as later in their lives. MTBF as a scalar value is just an > average. > Yes very good point -however that's where the historical data should come to rescue to help bend the MTBF line into this expected "bathtub curve". adam

1 0

Re: ASNs decimation in ZW this morning
by Colin Johnston 18 Jan '19

18 Jan '19

> On 15 Jan 2019, at 17:03, C. A. Fillekes <cfillekes(a)gmail.com> wrote: > > > Whole countries falling off the net? BUT TEH TOP POSTINGS!!! > > I'm a little frustrated with the very existence of that thread. > > Trying to constructively change the topic to something more interesting lol. > > I guess the concerning thing to me is that the whole point of packet switched networks was to provide resilience in the face of e.g. civil disorder. > > On Tue, Jan 15, 2019 at 11:50 AM Colin Johnston <colinj(a)gt86car.org.uk <mailto:colinj@gt86car.org.uk>> wrote: > sorry top posting, > yup whatsup doesnt work in harare. > phone circuits land ok though and checked ok > > col > > Sent from my iPod > > On 15 Jan 2019, at 15:42, C. A. Fillekes <cfillekes(a)gmail.com <mailto:cfillekes@gmail.com>> wrote: > >> >> >> On Tue, Jan 15, 2019 at 10:34 AM C. A. Fillekes <cfillekes(a)gmail.com <mailto:cfillekes@gmail.com>> wrote: >> >> So @meileaben on twitter this morning notes: >> >> Many #Zimbabwe <https://twitter.com/hashtag/Zimbabwe?src=hash> Internet routes withdrawn around 9:30 UTC amidst civil unrest in the country. near-realtime on #RIPEstat <https://twitter.com/hashtag/RIPEstat?src=hash> here: https://stat.ripe.net/ZW <https://t.co/sgJ4O3310z> #OpenNetworkIntelligence <https://twitter.com/hashtag/OpenNetworkIntelligence?src=hash> #ZimbabweShutdown <https://twitter.com/hashtag/ZimbabweShutdown?src=hash> >> >> https://twitter.com/meileaben/status/1085118237157851136 <https://twitter.com/meileaben/status/1085118237157851136> >> >> wondering if anyone here has additional info on that. Looing at stat.ripe.net/ZW <http://stat.ripe.net/ZW> now it looks as though one (out of an original 18, current 9) ASN has recovered, but kind of curious as to what exactly happened there. >> >> So Bloomberg notes that a number of ISPs were shut down to quell online protest >> https://www.bloomberg.com/news/articles/2019-01-15/by-killing-the-internet-… <https://www.bloomberg.com/news/articles/2019-01-15/by-killing-the-internet-…> but are there no work-arounds available, if implemented? zimbabwe situation link below re telecom problems https://www.zimbabwesituation.com/news/zimbabwe-telecoms-jammed-after-viole… <https://www.zimbabwesituation.com/news/zimbabwe-telecoms-jammed-after-viole…> I was back in Zim myself last month as well to see family children, internet was working well then inc whats up, mobile and adsl. I wonder how they block social media sites/whats up, is it null routing on peering cores or filtering since did not see filtering in place from ZIM<>UK last month... Colin

4 8

No IPv6 by design to increase reliability...
by John Von Essen 17 Jan '19

17 Jan '19

I was having a debate with someone on this. Take a critical web site, say one where you want 100% global uptime, no potential issues with end users having connectivity or routing issues getting to your IP. Would it be advantageous to purposely not support a AAAA record in DNS and disable IPv6, only exist on IPv4? My argument against this was "Broken IPv6 Connectivity" doesn't really occur anymore, also, almost all browsers and OS IP stacks implement Happy Eyeballs algorithm where both v4 and v6 are attempted, so if v6 dies it will try v4. I would also argue that lack of IPv6 technically makes the site unreachable from native IPv6 clients, and in the event of an IPv4 outage, connectivity might still remain on IPv6 if the site had an IPv6 address (I've experienced scenarios with a bad IPv4 BGP session, but the IPv6 session remained up and transiting traffic...) Thoughts? -John

6 6

Announcing Peering-LAN prefixes to customers
by Dominic Schallert 17 Jan '19

17 Jan '19

Hi all, this might be a stupid question but today I was discussing with a colleague if Peering-LAN prefixes should be re-distributed/announced to direct customers/peers. My standpoint is that in any case, Peering-LAN prefixes should be filtered and not announced to peers/customers because a Peering-LAN represents some sort of DMZ and there is simply no need for them to be reachable by third-parties not being physically connected to an IXP themselves. Also from a security point of view, a lot of new issues might occur in this situation. I’ve been seeing a few transit providers lately announcing (even reachable) Peering-LAN prefixes (for example DE-CIX Peering LAN) to their customers. I’m wondering if there is any document or RFC particularly describing this matter? Thanks Dominic

14 20

Stupid Question maybe?
by Aseem Choudhary 17 Jan '19

17 Jan '19

Hi Christian, Discontinuous mask for IPv6 was supported in IOS-XR in release 5.2.2. You can refer below link for details: https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/ip-addresses… Regards, Aseem On Wed, Dec 19, 2018 at 8:32 AM Saku Ytti <saku at ytti.fi <https://mailman.nanog.org/mailman/listinfo/nanog>> wrote: >* On Wed, 19 Dec 2018 at 02:55, Philip Loenneker *>* <Philip.Loenneker at tasmanet.com.au <https://mailman.nanog.org/mailman/listinfo/nanog>> wrote: *>>* > I had a heck of a time a few years back trying to troubleshoot an issue *>* where an upstream provider had an ACL with an incorrect mask along the *>* lines of 255.252.255.0. That was really interesting to talk about once we *>* discovered it, though it caused some loss of hair beforehand... *>>* Juniper originally didn't support them even in ACL use-case but were *>* forced to add later due to customer demand, so people do have *>* use-cases for them. If we'd still support them in forwarding, I'm sure *>* someone would come up with solution which depends on it. I am not *>* advocating we should, I'll rather take my extra PPS out of the HW. *>>* However there is one quite interesting use-case for discontinuous mask *>* in ACL. If you have, like you should have, specific block for customer *>* linknetworks, you can in iACL drop all packets to your side of the *>* links while still allowing packets to customer side of the links, *>* making attack surface against your network minimal. * And unfortunately is still not supported by IOS-XR for IPv6, which could mean not having a scaleable way on your edge to protect your internal network. -- Christian e-mail/xmpp: christian at errxtx.net <https://mailman.nanog.org/mailman/listinfo/nanog> PGP Fingerprint: B458 E4D6 7173 A8C4 9C75315B 709C 295B FA53 2318

2 1

Coloblox Atlanta down?
by Raleigh Apple 17 Jan '19

17 Jan '19

Is anyone else experiencing issues connecting to equipment hosted at Coloblox in Atlanta? -- Raleigh Apple JP Technologies office: 770/831-1036x105 “A dying culture invariably exhibits personal rudeness. Bad manners. Lack of consideration for others in minor matters. A loss of politeness, of gentle manners, is more significant than is a riot.” --Robert Heinlein

1 0

Call for Nominees NANOG Program Committee
by L Sean Kennedy 17 Jan '19

17 Jan '19

Dear NANOG Community, Nominations <https://www.nanog.org/elections/2018/CommitteeNominations> are now open for the NANOG Program Committee <http://nanog.org/elections/2017/PCcandidates>! The volunteers on the committee are responsible to develop and select content to program each of the three yearly NANOG conferences and other events. The Program Committee is a highly skilled, dedicated and diverse team of people who strive to improve the NANOG organization and make our industry, as a whole, better. Specific committee member responsibilities are listed here <https://www.nanog.org/governance/pgm/member_responsibilities> and appointments are to 2 year terms, except when appointed to complete a retiring members term. Committee nominations will close at 9:00 PM ET on Tuesday, February 19, 2019. The NANOG Board of Directors will make appointments on February 20, 2019. Emails detailing the selection results will be sent to candidates shortly thereafter, and a full announcement will be sent to the nanog-announce distribution list during the following week. Volunteer participation by members on NANOG committees is part of the essential fabric of the NANOG organization. PC members have developed new NANOG programs such as the Hackathon, proposed changes such as providing a meeting maker tool and having a forum to discuss the experiences of women in our industry, and meeting after meeting develop unique programs showcasing the state of Network Operations. Please consider running for the Program Committee if you are passionate about NANOG and can commit to participating! If you know someone that you believe would be interested, please nominate them. The nomination form <https://www.nanog.org/elections/2018/PCnominationform> accepts either self or 3rd party nominations. Myself and the other board members are available to discuss this opportunity, so do not hesitate to reach out to us if you are interested and want to learn more. As always, our dedicated professional staff stands ready to answer your questions at operations(a)nanog.org. Finally, I’d like to extend my best wishes to each of you for a happy and healthy 2019. I look forward to seeing you on February 18 in San Francisco for NANOG 75 <http://www.cvent.com/events/nanog-75/event-summary-948222eca5834bc2b7a67939…> . Thanks, L Sean Kennedy (for the NANOG Board of Directors)

1 0

Your opinion on network analysis in the presence of uncertain events
by Vanbever Laurent 17 Jan '19

17 Jan '19

Hi NANOG, Networks evolve in uncertain environments. Links and devices randomly fail; external BGP announcements unpredictably appear/disappear leading to unforeseen traffic shifts; traffic demands vary, etc. Reasoning about network behaviors under such uncertainties is hard and yet essential to ensure Service Level Agreements. We're reaching out to the NANOG community as we (researchers) are trying to better understand the practical requirements behind "probabilistic" network reasoning. Some of our questions include: Are uncertain behaviors problematic? Do you care about such things at all? Are you already using tools to ensure the compliance of your network design under uncertainty? Are there any good? We designed a short anonymous survey to collect operators answers. It is composed of 14 optional questions, most of which (13/14) are closed-ended. It should take less than 10 minutes to complete. We expect the findings to help the research community in designing more powerful network analysis tools. Among others, we intend to present the aggregate results in a scientific article later this year. It would be *terrific* if you could help us out! Survey URL: https://goo.gl/forms/HdYNp3DkKkeEcexs2 Thanks much! Laurent Vanbever, ETH Zürich PS: It goes without saying that we would also be extremely grateful if you could forward this email to any operator you know and who may not read NANOG.

4 7