Re: IPv6 deployment excuses

2016-07-03 Thread Mark Tinka
On 2/Jul/16 17:35, Ruairi Carroll wrote: > - ECMP issues (Mostly around flow labels and vendor support for that, also > feeds back into PMTUD issues) Do you rely on the ToS field in IPv4 for ECMP? > - Maintaining 2x IP stacks is inherently expensive Vs 1 How so? Mark.

Re: IPv6 deployment excuses

2016-07-03 Thread Mark Tinka
On 2/Jul/16 18:49, William Astle wrote: > Their specific excuse du jour changes every few months but it usually > boils down to "we don't want to put any effort or resources into > updating anything". If you keep asking your girlfriend out on a date each week, and she refuses to go out with yo

Re: IPv6 deployment excuses

2016-07-03 Thread Ruairi Carroll
On 3 July 2016 at 11:42, Mark Tinka wrote: > > > On 2/Jul/16 17:35, Ruairi Carroll wrote: > > - ECMP issues (Mostly around flow labels and vendor support for that, also > feeds back into PMTUD issues) > > > Do you rely on the ToS field in IPv4 for ECMP? > > Nope. I use l4 tuple for flow hashing t

Re: IPv6 deployment excuses

2016-07-03 Thread Mark Tinka
On 3/Jul/16 12:01, Ruairi Carroll wrote: > > Core of the issue is that we _need_ to get an ICMP message back to the > original "real server" who sent it. It's a non-issue in the SP space, > but imagine if your ECMP groups were stateful in both directions... Okay. > > > Think about it in lay

Re: IPv6 deployment excuses

2016-07-03 Thread Ruairi Carroll
On 3 July 2016 at 12:15, Mark Tinka wrote: > > > On 3/Jul/16 12:01, Ruairi Carroll wrote: > > > Core of the issue is that we _need_ to get an ICMP message back to the > original "real server" who sent it. It's a non-issue in the SP space, but > imagine if your ECMP groups were stateful in both di

Re: IPv6 deployment excuses

2016-07-03 Thread Tore Anderson
* Mark Tinka > I understand your points - to your comment, my question is around > whether it is cheaper (for you) to just run IPv6 in lieu of IPv6 and > IPv4. We've found that it is. IPv6-only greatly reduces complexity compared to dual stack. This means higher reliability, lower OpEx, shorter r

Charter FYI - FW: [SANOG] Reliance Jio (AS55836) origating a /16 belonging to Charter (AS20115)

2016-07-03 Thread Suresh Ramasubramanian
From: sanog on behalf of Anurag Bhatia Date: Sunday, 3 July 2016 at 8:46 PM To: SANOG Subject: [SANOG] Reliance Jio (AS55836) origating a /16 belonging to Charter (AS20115) Hello everyone! Is anyone from Jio network engineering team on this list? I see AS55836 is orig

Re: Charter FYI - FW: [SANOG] Reliance Jio (AS55836) origating a /16 belonging to Charter (AS20115)

2016-07-03 Thread Suresh Ramasubramanian
On 03/07/16, 9:05 PM, "NANOG on behalf of Suresh Ramasubramanian" wrote: > Is anyone from Jio network engineering team on this list? > I see AS55836 is originating 47.35.0.0/16 while the pool belongs to > Charter. There's even /18 slices of the pool being announced by Charter. Acked / fixed

Re: Charter FYI - FW: [SANOG] Reliance Jio (AS55836) origating a /16 belonging to Charter (AS20115)

2016-07-03 Thread Jay R. Ashworth
- Original Message - > From: "Suresh Ramasubramanian" > On 03/07/16, 9:05 PM, "NANOG on behalf of Suresh Ramasubramanian" > wrote: > >> Is anyone from Jio network engineering team on this list? >> I see AS55836 is originating 47.35.0.0/16 while the pool belongs to >> Charter. There's e

Charter FYI - FW: [SANOG] Reliance Jio (AS55836) origating a /16 belonging to Charter (AS20115)

2016-07-03 Thread Ca By
On Sunday, July 3, 2016, Jay R. Ashworth > wrote: > - Original Message - > > From: "Suresh Ramasubramanian" > > > On 03/07/16, 9:05 PM, "NANOG on behalf of Suresh Ramasubramanian" > > wrote: > > > >> Is anyone from Jio network engineering team on this list? > >> I see AS55836 is originat