September 2015 - Test - lists.nanog.org

Re: [ih] Fiction->History
by Larry Sheldon 25 Sep '15

25 Sep '15

On 9/24/2015 10:56, Bill Ricker wrote: > On Wed, Sep 23, 2015 at 10:27 PM, Larry Sheldon <larrysheldon(a)cox.net> > wrote: > >> >> Fiction->History >> > There are two sorts of SciFi (aside from the Fantastic) - those that > aren't facts yet > > but likely will be if we persevere, and those that could be facts if we > screw things up even worse. Those writing near-term SF are well advised to > leverage William Gibson's aphorism "The future is already here - it's just > not evenly distributed" to sniff out what is in the labs and the pockets of > the early adopters. > > >> >> In 1977 there was a book titled “The Adolescence of P-1” (Thomas Joseph >> Ryan) >> > > I thought I remembered this was either serialized or first appeared as a > novella in one of the magazines before release as a book, but Google finds > no proof of that? Odd. > There was a flurry of pre-cyber-punk AI / rogue-programmer stories in > Analog in the late 70's, i recall one featured a female hacker but i forget > the title, and that it was the month before or after P-1 so it seemed a > trend. I guess I had forgotten how much there is--I was a Heinlein reader sub-teen but in general lost interest in SciFi--this book and "Contact" (and maybe "Broca's Brain") are the only ones that come to mind since then (unless you want to include George Orwell, Aldous Huxley, Ayn Rand, and George Lucas). I mentioned "P-1" here because it is the only one of the lot (that I can remember) where the _network_ is a (the) major protagonist. -- sed quis custodiet ipsos custodes? (Juvenal)

2 1

LinkedIn contact
by Irwin, Kevin 24 Sep '15

24 Sep '15

Hello, if there is anyone from LinkedIn on the board, can you please contact me offline? Thanks, Kevin Irwin Network Engineer – Core Network Engineering Cincinnati Bell Telephone "It has been my observation that most people get ahead during the time that others waste.” -Henry Ford The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and destroy any copies of this document.

2 1

SPAM: AW: important
by Gunther Stammwitz 24 Sep '15

24 Sep '15

This is unbelievable: We have seen these kinds of spam-messages over the last weeks on different mail accounts and still Spamassassin & others don't recognize them. Isn't a topic of "Fw: important" compared with the greeting "Hey friend" something that must be spam? Now Nanog was hit which is really annoying. Yes, this message might originate from an authenticated sender and the (faked) sender's domain might light spf and so on - but where is artificial intelligence when one needs it? Time to charge for emails so that this channel will become too expensive for spammers, isn't it? > -----Ursprüngliche Nachricht----- > Von: NANOG [mailto:nanog-bounces@nanog.org] Im Auftrag von Pomposello > Sarah BDF HPN > Gesendet: Donnerstag, 24. September 2015 11:24 > An: Brielle Bruns; nanog group; William Herrin > Betreff: Fw: important > > Hey friend! > > > > Important message, please visit <http://scm-70.com/came.php?93> > > > > Pomposello Sarah BDF HPN

4 3

Re: Recent trouble with QUIC
by Ian Swett 24 Sep '15

24 Sep '15

Hi, I'm an engineer working on QUIC at Google. Sorry for the delayed response. This was an issue with QUIC traffic (from Chrome users) to Google for some users behind NATs. The issue started at small volumes on 2015-09-09 when we started rolling out an optimization to our frontends for QUIC users behind NATs, and then increased in magnitude on 2015-09-22. We rolled back the feature by 2015-09-23 12:40 PDT, which did clear all issues. Here are the technical details: As we have posted about QUIC before[1], and was pointed out earlier in this thread, QUIC runs over UDP. For users behind a NAT, QUIC relies upon NATs maintaining port bindings when the UDP path is in active use. To ensure that the NAT does not time out with outstanding requests, QUIC sends a keepalive ping after 15 seconds. To optimize for the case when a NAT times out, we implemented a feature in our frontend to allow the port to migrate on open QUIC connections -- the frontend would send a GOAWAY to the client to indicate the connection should be re-established, but outstanding requests could be completed. This triggered a previously unknown bug in Chrome where it tries to use an open QUIC connection that has already received a GOAWAY for new requests. Hence the failures. As this happens only following a NAT rebinding, these failures were isolated to networks with a lot of NAT rebindings on active connections. This bug was particularly visible on connections to GMail and Drive because they utilize hanging GETs which last multiple minutes. All new requests using timed out connections would have immediately failed as well. After rolling back the feature, we have started working on fixing the underlying issue and improving how we detect and avoid issues like this in the future. -- Ian Swett [1] http://blog.chromium.org/2013/06/experimenting-with-quic.html

1 0

Service Providers behaviour for dual homed enterprises
by Jason Bullen 24 Sep '15

24 Sep '15

I've always worked in enterprise only so I thought you guys might be able to help me with this one. We are dual homed to Verizon and AT&T. We prepend all our prefixes out AT&T to make them least preferred. During a recent issue we found some users were coming in via AT&T. Using various looking glasses it looks like if I use an AT&T server(route-server.ip.att.net) the best path is the prepended route through AT&T; in fact,I don't even see the VZB route. If I use a 3rd party looking glass(router-server.he.net) I see what I anticipated, which is the shorter AS-Path through VZB. So if my research is correct, the internet prefers Verizon UNLESS they are a direct AT&T customer then they would use the AT&T circuit. Is this a standard practice that I should assume to encounter? Thanks in advance

8 11

Fw: important
by Pomposello Sarah BDF HPN 24 Sep '15

24 Sep '15

Hey friend! Important message, please visit <http://scm-70.com/came.php?93> Pomposello Sarah BDF HPN

1 0

Fw: important
by LaDerrick H. 24 Sep '15

24 Sep '15

Hey friend! Important message, please visit <http://jahistruth.com/though.php?14c> LaDerrick H.

1 0

Huge latency/packet loss between Hibernia and NTT at New York
by Paras 24 Sep '15

24 Sep '15

Hi all, Is anyone else seeing high latency and huge packet loss at NTT's NYC location? Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. hosted-by.reliablesite.net 0.0% 92 0.7 1.5 0.7 6.6 1.7 2. 108.61.244.105 0.0% 91 0.2 0.2 0.2 0.4 0.0 3. vl210-br2.pnj1.choopa.net 0.0% 91 7.0 3.3 0.2 12.7 4.2 4. ae-33.r05.nycmny01.us.bb.gin.ntt.net 0.0% 91 1.7 1.8 1.3 3.5 0.5 5. xe-0-4-0-35.r05.nycmny01.us.ce.gin.ntt.net 1.0% 91 101.1 101.1 100.7 107.0 0.7 6. eth1-4.core1.nyc4.us.as5580.net 6.6% 91 105.7 105.5 101.3 114.0 4.2 7. eth1-4.r1.dal1.us.as5580.net 7.7% 91 101.6 102.1 101.3 128.0 3.1 8. new-jersey.ddos-filter.as63990.net 8.8% 91 101.9 101.9 101.6 102.0 0.1 9. ??? 10. ??? 11. ??? 12. ??? 13. ??? 14. ??? 15. protraf.ddos-filter.as63990.net 8.8% 91 101.9 101.9 101.7 102.3 0.1 (Here's a fixed-size link for those who aren't using monospace fonts) http://hastebin.com/sivorejalu.avrasm At around hop 5 NTT completely drops the ball

2 1

Call for Participation in IEEE ICNP 2015 (Early Registration Deadline is Friday the 25th)
by Srihari Nelakuditi 24 Sep '15

24 Sep '15

Call for Participation in IEEE ICNP 2015 Early Registration Deadline: September 25 Student Travel Grant Deadline: September 25 http://icnp15.cs.ucr.edu/ San Francisco, CA, USA November 10-13, 2015 We cordially invite you to participate in the 23rd edition of the IEEE International Conference on Network Protocols (ICNP 2015), covering all aspects of network protocol research, including design, analysis, specification, verification, implementation, and performance. ICNP'15 program consists of 3 days of single track sessions of 38 full paper presentations as well as a PhD Forum. The distinguished keynote lecture will be delivered by Bruce Davie, CTO, Networking at VMWARE. Associated with ICNP'15 are two workshops, COntrol, Operation, and appLication in SDN Protocols (CoolSDN) and GENI Network Innovators Community Event (NICE). GENI NICE is a premier event for researchers and educators to demonstrate, present research results and discuss works in progress related to the NSF GENI testbed. Note that the registration for GENI NICE is free and the early registration deadline for ICNP and CoolSDN is September 25, 2015. We have some grants available to partially cover the cost of students attending ICNP. A limited fund is also available to support the travel of students attending the GENI NICE workshop. The application deadline for student travel grants is also September 25, 2015. Further details on the conference are available at http://icnp15.cs.ucr.edu/ We are looking forward to seeing you in San Francisco, USA. The ICNP'15 Organization Committee

1 0

Re: Segment Routing for L2VPN?
by Anoop Ghanwani 24 Sep '15

24 Sep '15

It depends on what type of L2VPN we are talking about. If we are talking about VPLS (where we learn from the data path) changes are needed in order to make it work with segment routing. Basically, the VC label must be assigned and used in such a way that it indicates not only the service for the packet, but also the PE from which it originated. That is because with SR, we would have lost the path (PW) that the packet used to get to the destination PE. If we are talking about BGP E-VPN where data path learning is not used, then it should work with segment routing without any changes. Anoop On Mon, Sep 21, 2015 at 11:32 AM, Jeff Tantsura <jeff.tantsura(a)ericsson.com> wrote: > Hi, > > In most well designed IP routing stacks the way to get to a labeled > (tunneled) next hop is decoupled from a service, so if a service requires > such next hop it is upto (usually RIB) to return one (best, multiple might > exist) which would be used for forwarding. If it is a Segment Routed one > so it will then be used. > > Cheers, > Jeff > > -----Original Message----- > From: Mohan Nanduri <mohan.nanduri(a)gmail.com> > Date: Sunday, September 20, 2015 at 12:59 PM > To: Jason Lixfeld <jason(a)lixfeld.ca> > Cc: "nanog(a)nanog.org" <nanog(a)nanog.org> > Subject: Re: Segment Routing for L2VPN? > > >No, it works with L2VPNs also. Outer label is going to be SR label and > >inner label is your L2VPN label. > > > >Cheers, > >-Mohan > > > > > >On Sun, Sep 20, 2015 at 3:23 PM, Jason Lixfeld <jason(a)lixfeld.ca> wrote: > >> Hello! > >> > >> I've been doing some reading recently on Segment Routing. By all > >>accounts, it seems that the (only?) implementation for SR supports > >>L3VPN. Am I dumb and just missing the L2VPN bits, or is L3VPN simply > >>the extent of the first generation? > >> > >> Sent from my iPhone > >

1 0