On 18/Jul/20 15:31, adamv0...@netconsultings.com wrote:
>
> Well luckily we have MEF to set expectations about ones
> EPL/EVPL/EPLAN/EVPLAN performance. (and formal SLA contracts
> describing every single aspect of the service and its performance).
>
> Anyways, when I was designing these the
On 17/Jul/20 22:09, Josh Luthman wrote:
> I do dozens of VZW WiFi calls a day. My phone is behind NAT, no problem.
>
> It's probably 50/50 where the call starts on WiFi vs switches to WiFi
> after ~3 seconds from the poor VZW signal.
Same here, one of my cell operators uses VoWiFi for their
On 17/Jul/20 18:42, Tom Hill wrote:
> Yes, I rather think that you've drawn comparison to "consumer" as being
> in a home somewhere.
>
> Someone that consumes a circuit, and someone that provides the service
> (or resells one). A business customer is a consumer in that case - I
> won't
On 17/Jul/20 17:12, Nick Hilliard wrote:
>
> I was going to suggest that there wasn't much in the way of consumer
> grade international circuits, so why would you even bring this up?
> But then I lol'd.
Now you have me wondering whether Tom was serious or not :-).
It's time for my Friday
On 17/Jul/20 17:06, Tom Hill wrote:
> The differentiation is: consumer vs. service provider.
>
> If you're a service provider, don't buy a consumer product and hope to
> sell it on at a similar (or higher) SLA rate to other consumers; that
> way lies ruin.
I don't know of "Consumers" that buy
On 17/Jul/20 11:50, Robert Raszuk wrote:
>
> Fortunately very fortunately Mark.
Hehe, I meant in the context of not having a similar condition as the OP.
> L2VPNs running on someone's IP backbone sold by many as "circuits" has
> many issues ... stability, MTU blackhols, random drops -
On 17/Jul/20 02:37, Harivishnu Abhilash wrote:
>
>
> Thanks for the update. You have any backhauls, that is running over an
> L2 xconnect ? I’m facing issue only on the backhaul link over a l2vpn
> ckt.
>
Unfortunately not. All our backbones are either over dark fibre or EoDWDM.
Mark.
On 16/Jul/20 05:51, Harivishnu Abhilash wrote:
>
> *Classification:**Public*
>
>
>
> Guys, I’m looking for recommendation regarding BFD timers that we can
> use for long haul circuit. RTT is roughly around 110 ms. In fact this
> is a l2vpn ckt provided by a telco.
>
> Can you please advise the
On 13/Jul/20 17:33, Mike Hammett wrote:
> Fiscal and logistic reasons, would be my guess.
Nick was being facetious :-).
Mark.
On 13/Jul/20 17:25, Nick Hilliard wrote:
>
> Obviously he means countries like Sweden, Ireland and Switzerland.
>
>> https://en.wikipedia.org/wiki/Third_World#/media/File:Cold_War_alliances_mid-1975.svg
>>
>
> It's not clear why there's any relationship between third world status
> and the
On 13/Jul/20 17:16, Rubens Kuhl wrote:
>
> Brazil-Angola cable is SACS, which for an European route would be
> paired with WACS to go from Angola to Portugal.
> Brazil-Cameroon cable is SAIL, which to get to Europe would be paired
> with ACE to go from Cameroon to Portugal or France.
WACS is
On 13/Jul/20 16:23, Nick Hilliard wrote:
>
> 160gbit/sec split over a standard 80ch itu dwdm grid sounds like
> 2gbit/sec per channel (although there are more efficient options than
> the standard itu grid). This sounds like it's seriously not worth it
> for today's bandwidth requirements,
On 13/Jul/20 15:41, Colin Stanners (lists) wrote:
>
> Looking at the Wikipedia article, it claims that Atlantis-2 “can
> already be upgraded with current technology to 160Gbit/s”. Would be
> interesting why that wasn’t already done on this 20-year-old cable –
> assuming that the underground
On 12/Jul/20 23:43, J. Hellenthal via NANOG wrote:
> Almost no surprise they are all third world, still scary in a sense.
> Might just have to rethink a blacklist strategy for traffic
> originating behind those locations.
Still don't know what "third world" means (of course I do...), but
On 12/Jul/20 17:19, Rubens Kuhl wrote:
>
>
> Alternative routes before EllaLink comes into operation would be one
> of the Brazil-Africa cables (one to Cameroon, the other to Angola) and
> then to Europe.
Are you talking about SAex?
There is SACS as well.
Mark.
On 12/Jul/20 17:05, Max Tulyev wrote:
>
>
> I see there is only one undersea cable going directly from Brazil to
> Europe. Why?
Have you ever read a C contract for a submarine cable build :-)?
Mark.
On 12/Jul/20 14:00, Paul Nash wrote:
> Not quite VSAT, but in the bad old SA days (pre-demicracy), I did some work
> for a company that used a UK-based satellite provider for data to the client
> (data was sent in the VBI), and dial-up for the traffic from the client.
>
> Still relied on a
On 11/Jul/20 02:16, Brandon Martin wrote:
>
> All of the part numbers I was able to find a description of (after
> sifting through the numerous pages copying the vulnerability
> disclosure) appeared to be low-cost, low- to mid-density pizza-box
> EPON OLTs. I didn't see any ONUs, but then I
On 11/Jul/20 00:22, Alexander Neilson wrote:
>
> For these to be internet exposed presumably they must be including a
> router function and not simply doing some bridging of customer traffic.
Well, if the attacker were able to find a way into your bastion host...
Mark.
On 10/Jul/20 18:58, Owen DeLong wrote:
> https://www.zdnet.com/article/backdoor-accounts-discovered-in-29-ftth-devices-from-chinese-vendor-c-data/?ftag=TRE-03-10aaa6b=29077120342825113007211255328545=12920625=2211510872
>
>
> Wow… Just wow.
And unlike routers, switches (and OLT's) don't seem
On 10/Jul/20 10:50, Eric Kuhnke wrote:
> With common Ku band TVRO (receive only) dishes and decoders, one of
> the constraints for moving to higher bitrates is the physical sizes of
> the customer dish and economics.
>
> For a good example go to a very densely populated developing nation
>
On 9/Jul/20 22:49, Masataka Ohta wrote:
> We should also use IP even over radio waves. IP over MPEG2-TS
> over DVB (or terrestrial broadcast network) is doable though
> IP directly over DVB should be better.
Well, when we moved over from traditional satellites to inclined orbit
satellites
On 9/Jul/20 18:00, Christopher Munz-Michielin wrote:
> I'd assume it's a question of available bandwidth and availability of
> decoders. From my observations most HD satellite feeds seem to sit
> between 3 and 5 mbps, a typical Ku band transponder might have a
> bandwidth of around
On 9/Jul/20 17:51, Joel M Snyder wrote:
> Oh man I wish that were wholly true... Satellite/VSAT has another very
> very important attribute: it's not subject to the whims of the local
> government or regulators. So when there's an election or some unrest or
> coup or the prime minister has
On 9/Jul/20 16:51, Christopher Munz-Michielin wrote:
>
> There are a few 4K test streams. NASA TV is one:
>
> https://www.lyngsat.com/tvchannels/us/NASA-TV-UHD.html
>
> I just piped it into ffmpeg and the NASA TV feed runs 10-15mbps, H.265
> encoding at a resolution of 3840x2160. So
On 9/Jul/20 04:47, Denys Fedoryshchenko wrote:
>
> I don't think traditional satellites have much future as backbone.
> Only as broadcasting media.
Does anyone know of (m)any satellite TV services delivering 1080p or
greater? The most I've seen on our side of the rock is 1080i.
If there is
On 8/Jul/20 15:21, Paul Nash wrote:
> When we started TICSA (Internet Africa/Verizon/whatever), we went with a 9600
> bps satellite link to New Jersey specifically because the SAT-2 fibre had
> just been installed and traffic was being moved off satellite. The satellite
> folk were getting
On 8/Jul/20 12:42, Radu-Adrian Feurdean wrote:
> Errr sorry, but at the latest news, TCP was supposed to handle out of
> order packets and reorder them before sending them to upper layer.
> Not to mention hashing that almost systematically makes that all packets of
> the same TCP stream
On 7/Jul/20 19:23, JORDI PALET MARTINEZ via NANOG wrote:
>
>
> There was, long time ago, something developed by ISC, but I think
> never completed and not updated …
>
>
>
> 464XLAT is always a solution and becomes much cheaper, than CGN from
> vendors, even if you need to replace the CPEs.
On 7/Jul/20 23:09, Adam Thompson wrote:
> Good luck with tunnelling LACP, no matter what boxes you have - LACP has (de
> facto) hard jitter requirements of under 1msec, or you'll be getting TCP
> resets coming out your ears due to mis-ordered packets.
Hmmh - this is odd.
We once provided a
On 7/Jul/20 21:58, Eric Kuhnke wrote:
> Watching the growth of terrestrial fiber (and PTP microwave) networks
> going inland from the west and east African coasts has been
> interesting. There's a big old C-band earth station on the hill above
> Freetown, Sierra Leone that was previously the
On 7/Jul/20 10:07, Eric Kuhnke wrote:
> The most noteworthy thing I'm seeing in C band these days, is many
> customers formerly 100% reliant upon it shifting their traffic to
> newly built submarine fiber routes.
Before most of Africa had submarine fibre, a lot of our traffic was
carried on
On 7/Jul/20 08:51, Denys Fedoryshchenko wrote:
>
> And as Ku is often covering specific regions, often it means rainy
> days for most transponder customers.
> This is why in zones closer to equator, with their long-term monsoon,
> C-Band was only option,
> no idea about now.
In much of
On 1/Jul/20 09:10, James Bensley wrote:
> True, but what's changed in two weeks with regards to LDv6 and SR?
>
> What was your use case / requirement for LDv6 - to remove the full
> table v6 feed from your core or to remove IPv4 from your IGP or both?
Give me a year to work this and report
On 30/Jun/20 20:37, James Bensley wrote:
> Mark, does someone have a gun to your head? Are you in trouble? Blink
> 63 times for yes, 64 times for no ;)
You're pretty late to this party, mate...
Mark.
On 30/Jun/20 14:15, Darin Steffl wrote:
> Why isn't Hurricane in your mix yet? They have great routes, some of
> the lowest pricing available, and they are always easy to reach at the
> NOC. They also peer at nearly every IX possible. They're #1 in number
> of BGP adjacencies.
>
> It looks
On 29/Jun/20 19:22, Rubens Kuhl wrote:
>
>
> A switch's maturity is much more dependent on hardware while a router
> is much more dependent on software, so I suggest assessing a switch on
> their own merits, regardless of bad experiences with that vendor in
> the router realm.
Well, these
On 30/Jun/20 13:14, James Braunegg wrote:
>
> Dear Nanog
>
>
>
> For those running a AS with multiply POP locations around the world
> who would you recommend as a strong tier 1 transit provider in Europe
> (good routes to Africa would be a bonus)
>
>
>
> We currently take full table feeds
On 29/Jun/20 07:34, Owen DeLong wrote:
> Personally, I’d like to see the Netflix UI upgraded so that you could have
> the option of indexing all content (whether you could view it or not) and
> each time you clicked on something you weren’t allowed to view, it provided
> contact information
On 27/Jun/20 00:39, Grant Taylor via NANOG wrote:
>
>
> Amazon does better.
> YouTube does better.
> CBS does better.
> Hulu does better.
I wouldn't immediately compare all of those services to Netflix (or even
to each other), especially in a global context... but then this thread
could get
On 29/Jun/20 19:37, Matt Harris wrote:
> Cisco doesn't want to sell 2960 series anymore and they made that
> perfectly clear to me over the past couple of years. I ended up
> switching to Juniper EX gear in places I had been deploying 2960's
> previously. The EX3400 lineup is better priced than
On 28/Jun/20 19:37, Randy Bush wrote:
> think of the burden on the netflix customer support of HE's IPv6
> tunnels.
I wasn't aware about the HE situation and Netflix. I just learned about
this via this thread.
I understand why they are blocking those tunnels.
Mark.
On 26/Jun/20 20:15, colin johnston wrote:
> I don’t understand the rational to block specific ipv6 ranges, for example
> the UK ipv6 ranges and Africa ipv6 ranges are not blocked from testing done
> here with satellite comms and fibre backhaul uk comms
Do you have more information on this
On 26/Jun/20 20:08, Brandon Jackson via NANOG wrote:
>
> As much as I hate it as I use said tunnel service it is understandable
> and I don't really blame Netflix for this, I blame the content
> producer/owners and the industry as a whole for mandating such
> restrictive practices.
Unless I
On 26/Jun/20 19:40, Sabri Berisha wrote:
> Don't hold your breath. It's most likely not related to the capabilities
> of the hardware, or even the kernel running on the platform.
I'm hoping a new device will bring with it renewed vigour :-).
I'm probably being ambitious. Overly.
> My
On 26/Jun/20 15:48, Owen DeLong wrote:
> I can’t speak for Netflix, but the reality is that there’s really no good
> way to “fix” CGNAT other than migrating to IPv6 and eliminating it.
>
> CGNAT by its nature combines multiple subscribers behind a single address.
>
> When you make subscribers
On 26/Jun/20 19:25, Gary E. Miller wrote:
> Nope. Netflix blocks a lot of IPv6. Their blocking of HE has been
> discussed here many times.
Possibly, but I was merely referring to a compatible device.
Actual ability to get IPv6 transport toward Netflix is an entirely
different matter.
Mark.
On 26/Jun/20 03:12, Denys Fedoryshchenko wrote:
>
>
> Honestly, this is very confusing suggestion from Netflix support (i
> have native ipv6!).
> Looking to
> https://www.reddit.com/r/ipv6/comments/evv7r8/ipv6_and_netflix/ there
> is definitely some issues for other users too.
This seems to
On 25/Jun/20 18:08, Brandon Jackson via NANOG wrote:
> Actually it's a good thing that Netflix does support IPv6 for this. As
> any device using Netflix via IPv6 from your ISP would likely correctly
> be protected as not a VPN or proxy.
>
> The problem is the ISPs that deploy CGNAT without
On 25/Jun/20 16:45, Christian wrote:
> wow. blaming support for IPv6 rather than using cgnat is a huge
> stretch of credibility
I have no idea what's going through Netflix's mind - it's all, as my
American friend would say, conjecturbation on my part.
CG-NAT isn't new, and if Netflix are
On 25/Jun/20 11:08, Denys Fedoryshchenko wrote:
> Did anybody noticed that Netflix just became useless due to tons of
> proxy/unblocker false detection on CGNAT ranges?
> Even my home network is dual stack, i am absolutely sure there is no
> proxy/vpn/whatsoever (but ipv4 part is over CGNAT) -
On 23/Jun/20 07:52, Saku Ytti wrote:
>
> S1-S2-S3-S1 is operator L2 metro-ring, which connects customers and
> 2xPE routers. It VLAN backhauls customers to PE.
Okay.
In 2014, we hit a similar issue, although not in a ring.
Our previous architecture was to interconnect edge routers via
On 23/Jun/20 07:32, Saku Ytti wrote:
>
> Ring of 3 switches, minimum possible topology to explain the issue for
> people not familiar with L2.
To be clear, is the customer's device S3, or is S3 the ISP's device that
terminates the customer's service?
Mark.
On 23/Jun/20 07:21, Saku Ytti wrote:
> Metro: S1-S2-S3-S1
> PE1: S1
> PE2: S2
> Customer: S3
> STP blocking: ANY
>
> S3 sends frame, it is unknown unicast flooded, S1+S2 both get it
> (regardless of which metro port blocks), which will send it via PE to
> Internet.
>
> STP doesn't help, at
On 23/Jun/20 06:41, Saku Ytti wrote:
>
> I can't tell you how common it is, because that type of visibility is
> not easy to acquire, But I can explain at least one scenario when it
> occasionally happens.
>
> 1) Imagine a ring of L2 metro ethernet
> 2) Ring is connected to two PE routers, for
On 22/Jun/20 16:30, adamv0...@netconsultings.com wrote:
> Not quite,
> The routing information is flooded by default, but the receivers will cherry
> pick what they need and drop the rest.
> And even if the default flooding of all and dropping most is a concern -it
> can be addressed where
On 22/Jun/20 15:17, Masataka Ohta wrote:
>
>
> The point of Yakov on day one was that, flow driven approach of
> Ipsilon does not scale and is unacceptable.
>
> Though I agree with Yakov here, we must also eliminate all the
> flow driven approaches by MPLS or whatever.
I still don't see
On 22/Jun/20 15:08, Masataka Ohta wrote:
>
> The requirement from the E2E principle is that routers should be
> dumb and hosts should be clever or the entire system do not.
> scale reliably.
And yet in the PTT world, it was the other way around. Clever switching
and dumb telephone boxes.
On 22/Jun/20 14:49, Masataka Ohta wrote:
>
> But, it should be noted that a single class B...
CIDR - let's not teach the kids old news :-).
> If you have 1000 PEs, you should be serving for somewhere around 1000
> customers.
It's not linear.
We probably have 1 edge router serving
On 21/Jun/20 23:01, Robert Raszuk wrote:
>
> Nope. You need to get to PQ node via potentially many hops. So you
> need to have even ordered or independent label distribution to its
> loopback in place.
I have some testing I want to do with IS-IS only announcing the Loopback
from a set of
On 21/Jun/20 22:21, Robert Raszuk wrote:
>
> Well this is true for one company :) Name starts with j
>
> Other company name starting with c - at least some time back by
> default allocated labels for all routes in the RIB either connected or
> static or sourced from IGP. Sure you could
On 21/Jun/20 21:15, adamv0...@netconsultings.com wrote:
> I wouldn't say it's known to many as not many folks are actually limited by
> only up to ~1M customer connections, or next level up, only up to ~1M
> customer VPNs.
It's probably less of a problem now than it was 10 years ago.
On 21/Jun/20 19:34, Robert Raszuk wrote:
>
> That is true for P routers ... not so much for PEs.
>
> Please observe that label space in each PE router is divided for IGP
> and BGP as well as other label hungy services ... there are many
> consumers of local label block.
>
> So it is always
On 21/Jun/20 15:48, Robert Raszuk wrote:
>
>
> Actually when IGP changes LSPs are not recomputed with LDP or SR-MPLS
> (when used without TE :).
>
> "LSP" term is perhaps what drives your confusion --- in LDP MPLS there
> is no "Path" - in spite of the acronym (Labeled Switch *Path*). Labels
>
On 21/Jun/20 14:58, Baldur Norddahl wrote:
>
> Not really the same. Lets say the best path is through transit 1 but
> the customer thinks transit 1 sucks balls and wants his egress traffic
> to go through your transit 2. Only the VRF approach lets every BGP
> customer, even single homed ones,
On 21/Jun/20 14:36, Masataka Ohta wrote:
>
>
> That is a tragedy.
Well...
> If all the link-wise (or, worse, host-wise) information of possible
> destinations is distributed in advance to all the possible sources,
> it is not hierarchical but flat (host) routing, which scales poorly.
>
>
On 21/Jun/20 13:11, Masataka Ohta wrote:
>
> If information to create labels at or near sources to all the
> possible destinations is distributed in advance, may be.
But this is what happens today.
Whether you do it manually or use a label distribution protocol, FEC's
are pre-computed ahead
On 21/Jun/20 12:45, Baldur Norddahl wrote:
>
> Yes I once made a plan to have one VRF per transit provider plus a
> peering VRF. That way our BGP customers could have a session with each
> of those VRFs to allow them full control of the route mix. I would of
> course also need a Internet VRF
On 21/Jun/20 12:10, Masataka Ohta wrote:
>
> It was implemented and some technology was used by commercial
> router from Furukawa (a Japanese vendor selling optical
> fiber now not selling routers).
I won't lie, never heard of it.
> GMPLS, you are using, is the mechanism to guarantee QoS
On 20/Jun/20 17:12, Robert Raszuk wrote:
>
> MPLS is not flow driven. I sent some mail about it but perhaps it
> bounced.
>
> MPLS LDP or L3VPNs was NEVER flow driven.
>
> Since day one till today it was and still is purely destination based.
>
> Transport is using LSP to egress PE (dst IP).
On 20/Jun/20 17:08, Robert Raszuk wrote:
>
>
> But with that let's not forget that aggregation here is still not
> spec-ed out well and to the best of my knowledge it is also not
> shipping yet. I recently proposed an idea how to aggregate SRGBs ..
> one vendor is analyzing it.
Hence why I
On 20/Jun/20 15:39, Masataka Ohta wrote:
> Ipsilon was hopeless because, as Yakov correctly pointed out, flow
> driven approach to automatically detect flows does not scale.
>
> The problem of MPLS, however, is that, it must also be flow driven,
> because detailed route information at the
On 20/Jun/20 01:32, Randy Bush wrote:
> there is saku's point of distributing labels in IGP TLVs/LSAs. i
> suspect he is correct, but good luck getting that anywhere in the
> internet vendor task force. and that tells us a lot about whether we
> can actually effect useful simplification and
On 20/Jun/20 22:00, Baldur Norddahl wrote:
>
> I can't speak for the year 2000 as I was not doing networking at this
> level at that time. But when I check the specs for the base mx204 it
> says something like 32 VRFs, 2 million routes in FIB and 6 million
> routes in RIB. Clearly those numbers
On 21/Jun/20 00:54, Sabri Berisha wrote:
> That will be very advantageous in a datacenter environment, or any other
> environment dealing with a lot of ECMP paths.
>
> I can't tell you how often during my eBay time I've been troubleshooting
> end-to-end packetloss between hosts in two
They've been harassing me all day - I've been ignoring.
Mark.
On 20/Jun/20 23:33, Tim Pozar wrote:
> Looks like a spammer is harvesting email addresses from the NANOG list. i
> I will be unscribing as I don't need this additional noise in my mailbox.
>
> Tim
>
> - Forwarded message from
On 20/Jun/20 00:41, Anoop Ghanwani wrote:
> One of the advantages cited for SRv6 over MPLS is that the packet
> contains a record of where it has been.
I can't see how advantageous that is, or how possible it would be to
implement, especially for inter-domain traffic.
Mark.
On 20/Jun/20 19:58, Gert Doering wrote:
> The 6880/6840 products were promising at that time, but the pricing made
> it uninteresting. So we kept our 6506Es for a time...
We haven't done anything with them since we bought and deployed them in
2014.
They are serving their purpose quite well,
On 19/Jun/20 20:19, ljwob...@gmail.com wrote:
> >From the vendor standpoint, the market has never been able to agree on what
> >makes a "core" application. If I have five "big" customers, I guarantee you
> >that:
> - one of them will need really big ACLs, even though it's a "core" box to
On 19/Jun/20 17:26, Gert Doering wrote:
> There's a special place in hell for people re-using the "Catalyst" brand
> name and then putting yearly renewable licenses on it. Or IOS XE.
>
> I'm not actually sure *which* BU is doing "Catalyst" these days, but
> we're so annoyed about Cisco these
On 20/Jun/20 14:41, Masataka Ohta wrote:
>
> There are many. So, our research group tried to improve RSVP.
I'm a lot younger than the Internet, but I read a fair bit about its
history. I can't remember ever coming across an implementation of RSVP
between a host and the network in a
On 20/Jun/20 11:27, Baldur Norddahl wrote:
>
>
> We run the Internet in a VRF to get watertight separation between
> management and the Internet. I do also have a CGN vrf but that one has
> very few routes in it (99% being subscriber management created, eg.
> one route per customer). Why would
On 19/Jun/20 18:00, Masataka Ohta wrote:
> There seems to be serious confusions between label switching
> with explicit flows and MPLS, which was believed to scale
> without detecting/configuring flows.
>
> At the time I proposed label switching, there already was RSVP
> but RSVP-TE was
On 19/Jun/20 17:40, Masataka Ohta wrote:
>
> As the first person to have proposed the forwarding paradigm of
> label switching, I have been fully aware from the beginning that:
>
> https://tools.ietf.org/html/draft-ohta-ip-over-atm-01
>
> Conventional Communication over ATM in a
On 19/Jun/20 17:13, Robert Raszuk wrote:
>
> So I think Ohta-san's point is about scalability services not flat
> underlay RIB and FIB sizes. Many years ago we had requests to support
> 5M L3VPN routes while underlay was just 500K IPv4.
Ah, if the context, then, was l3vpn scaling, yes, that
On 19/Jun/20 16:45, Masataka Ohta wrote:
> The problem of MPLS, or label switching in general, is that, though
> it was advertised to be topology driven to scale better than flow
> driven, it is actually flow driven with poor scalability.
>
> Thus, it is impossible to deploy any technology
On 19/Jun/20 16:09, Tim Durack wrote:
>
> It could be worse: Nexus ;-(
>
> There is another version of the future:
>
> 1. SP "Silicon One" IOS-XR
> 2. Enterprise "Silicon One" IOS-XE
>
> Same hardware, different software, features, licensing model etc.
All this forking weakens a vendor's
On 19/Jun/20 15:24, steve ulrich wrote:
> never underestimate the desire of product managers and engineering teams to
> have their own petri dishes to swim around in.
Probably what got us (and keeps getting us) into this mess to begin with.
Mark.
On 19/Jun/20 14:50, Tim Durack wrote:
> If y'all can deal with the BU, the Cat9k family is looking
> half-decent: MPLS PE/P, BGP L3VPN, BGP EVPN (VXLAN dataplane not MPLS)
> etc.
> UADP programmable pipeline ASIC, FIB ~200k, E-LLW, mandatory DNA
> license now covers software support...
>
> Of
I think it's less about just the forwarding chips and more about an
entire solution that someone can go and buy without having to fiddle
with it.
You remember the saying, "Gone are the days when men were men and wrote
their own drivers"? Well, running a network is a full-time job, without
having
On 19/Jun/20 13:11, Saku Ytti wrote:
> ASR9k also has low and high scale cards, we buy the low scale, even
> for edge. But even low scale is pretty high scale in this context.
You're probably referring to the TR vs. SE line cards, yes?
We would also buy TR line cards for high-touch
On 19/Jun/20 10:57, Radu-Adrian Feurdean wrote:
>
> Yes, exactly that one.
> Which also happens to spill outside the DC area, because the main "vertical"
> allows it to be sold at lower prices.
These days, half the gig is filtering the snake oil.
Mark.
On 19/Jun/20 10:40, Saku Ytti wrote:
> Maybe this is fundamental and unavoidable, maybe some systematic bias
> in human thinking drives us towards simple software and complex
> hardware.
>
> Is there an alternative future, where we went with Itanium? Where we
> have simple hardware and an
On 19/Jun/20 10:18, Saku Ytti wrote:
> I need to give a little bit of credit to DC people. If your world is
> compute and you are looking out to networks. MPLS _is hard_, it's
> _harder_ to generate MPLS packets in Linux than arbitrarily complex IP
> stack. Now instead of fixing that on the OS
On 19/Jun/20 09:50, Saku Ytti wrote:
> I'm sure such devices exist, I can't name any from top of my head. But
> this market perversion is caused by DC people who did not understand
> networks and suffer from not-invented-here. Everyone needsa tunnel
> solution, but DC people decided before
On 19/Jun/20 09:20, Radu-Adrian Feurdean wrote:
>
> A whole ocean of "datacenter" hardware, from pretty much evey vendor.
You mean the ones deliberately castrated so that we can create a
specific "DC vertical", even if they are, pretty much, the same box a
service provider will buy, just
On 19/Jun/20 09:32, Saku Ytti wrote:
> We need to decide if we are discussing a specific market situation or
> fundamentals. Ideally we'd drive the market to what is fundamentally
> most efficient, so that we pay the least amount of the kit that we
> use. If we drive SRv6, we drive cost up,
On 18/Jun/20 15:26, Warren Kumari wrote:
> Ah, because, if you word / negotiate your contract carefully, the
> failure to meet the 24/7 SLO can be converted into credit -- either
> actual discounts or simply a big stick when negotiating new stuff.
> Many years ago I worked for a company who
On 18/Jun/20 14:56, Saku Ytti wrote:
> Somewhere between 2000..2005 I personally still delivered customer
> connections that needed that. But we were providing 64kbps still to
> some odd locations, like paper mill in the middle of nowhere. I also
> needed to do MLPPP over 2*64kbps so that
On 18/Jun/20 14:49, Bill Woodcock wrote:
> What time was that?
Back when a 12000 GSR chassis had one line card in slot 0 for the public
Internet, and another in slot 5 for the MPLS backbone. They had to be
that far apart, for safety :-)...
Mark.
signature.asc
Description: OpenPGP digital
1101 - 1200 of 2587 matches
Mail list logo
