--- Begin Message ---
On 21/06/2020 7:30 am, Mark Tinka wrote:
Personally I would only recommend Meraki for a small business with
very basic and well defined requirements. Even then once you factor
in the cost of licensing + hardware and compare it to a low end Cisco
Enterprise product that
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
On 20/Jun/20 08:49, Reuben Farrelly via cisco-nsp wrote:
> Meraki doesn't currently support IPv6 in any way, shape or form.
>
> Some other things you'll find missing in Meraki products:
>
> - Zone based firewalls - Meraki MX doesn't do zones
> - Routing protocols for all but the most absolutely
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,
Hi,
On Sat, Jun 20, 2020 at 07:42:31PM +0200, Mark Tinka wrote:
> On 19/Jun/20 17:26, Gert Doering wrote:
>
> We bought the C6880-X for our core switch back in 2014. It's still
> humming, running plain old IOS.
The 6880/6840 products were promising at that time, but the pricing made
it
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
--- Begin Message ---
On 20/06/2020 4:14 pm, c...@marenda.net wrote:
I've been told Merak is very nice... if all you're interested in is "sell
to
Enterprise customers and make lots of cash".
We asked the sales-person weather that meraki devices can handle ipv6
(as customer traffic) and
> I've been told Merak is very nice... if all you're interested in is "sell
to
> Enterprise customers and make lots of cash".
We asked the sales-person weather that meraki devices can handle ipv6
(as customer traffic) and for the cloudy management access (in an ipv4 free
world)
But they
>
> One of the advantages cited for SRv6 over MPLS is that the packet contains
>> a record of where it has been.
>>
>
Not really ... packets are not tourists in a bus.
First there are real studies proving that most large production networks
for the goal of good TE only need to place 1, 2 or 3
Hi,
On Fri, Jun 19, 2020 at 03:05:50PM +0200, Mark Tinka wrote:
> 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
On Fri, Jun 19, 2020 at 10:34 AM Mark Tinka wrote:
>
>
> 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
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 Fri, Jun 19, 2020 at 9:05 AM Mark Tinka wrote:
>
>
> 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,
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 Jun 19, 2020, at 08:06, Mark Tinka wrote:
>
>> 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,
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
is there any
> chip which supports MPLS and cost less then IP/MPLS one ?
>
> On Fri, Jun 19, 2020 at 1:22 PM Benny Lyne Amorsen via cisco-nsp
> wrote:
>
>
> -- Forwarded message --
> From: Benny Lyne Amorsen
> To: cisco-nsp@puck.nether.net
> Cc:
>
>>
>>
>> -- Forwarded message --
>> From: Benny Lyne Amorsen
>> To: cisco-nsp@puck.nether.net
>> Cc:
>> Bcc:
>> Date: Fri, 19 Jun 2020 13:12:06 +0200
>> Subject: Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
>> Saku Ytti
On Fri, 19 Jun 2020 at 14:26, Mark Tinka 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?
I do, correct.
--
++ytti
On Fri, 19 Jun 2020 at 14:23, Benny Lyne Amorsen via cisco-nsp
wrote:
> Per-packet overhead is hefty. Is that a problem today?
For us it is in DDoS scenario, we have customers whose product is to
ingest DDoS and send clean out, so we need to deliver the bad traffic
to them. With large
On 19/Jun/20 13:11, Robert Raszuk wrote:
>
> > For us, the PTX1000/10002 make absolute sense, and are options we are
>
> If you ever need some TE in your network just make sure it can run
> SR-MPLS (segment endpoint functions) as it turns out that sweet spots
> for flow engineering is very often
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
net> wrote:
>
>
>
> -- Forwarded message --
> From: Benny Lyne Amorsen
> To: cisco-nsp@puck.nether.net
> Cc:
> Bcc:
> Date: Fri, 19 Jun 2020 13:12:06 +0200
> Subject: Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
> Saku Ytti writes:
>
--- Begin Message ---
Saku Ytti writes:
> This is simply not fundamentally true, it may be true due to market
> perversion. But give student homework to design label switching chip
> and IPv6 switching chip, and you'll use less silicon for the label
> switching chip. And of course you spend less
On Fri, 19 Jun 2020 at 14:04, Mark Tinka wrote:
> Even Cisco sort of went down this path with the CRS-3 when they - very
> briefly - sold the so-called CRS LSP (Label Switch Processor) forwarding
> engine:
ASR9k also has low and high scale cards, we buy the low scale, even
for edge. But even
> For us, the PTX1000/10002 make absolute sense, and are options we are
If you ever need some TE in your network just make sure it can run SR-MPLS
(segment endpoint functions) as it turns out that sweet spots for flow
engineering is very often in forcing it to traverse some specific core
boxes.
On 19/Jun/20 12:29, Robert Raszuk wrote:
> Saku,
>
> What you are saying is technically true but not realistically important.
>
> Why - the answer is history of PTX.
>
> It was originally designed and architected on the very basis of hardware
> cost and performance when you would only need to
On Fri, 19 Jun 2020 at 13:29, Robert Raszuk wrote:
Hey,
> What you are saying is technically true but not realistically important.
>
> Why - the answer is history of PTX.
I think this is interesting anecdote, but not much more.
> It was originally designed and architected on the very basis of
Saku,
What you are saying is technically true but not realistically important.
Why - the answer is history of PTX.
It was originally designed and architected on the very basis of hardware
cost and performance when you would only need to switch at rates MPLS.
Well real world showed that you
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 Fri, 19 Jun 2020 at 11:35, Mark Tinka wrote:
> > So instead of making it easy for software to generate MPLS packets. We
> > are making it easy for hardware teo generate complex IP packets.
> > Bizarre, but somewhat rational if you start from compute looking out
> > to networks, instead of
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 Fri, 19 Jun 2020 at 11:03, Mark Tinka wrote:
> MPLS has been around far too long, and if you post web site content
> still talking about it or show up at conferences still talking about it,
> you fear that you can't sell more boxes and line cards on the back of
> "just" broadening carriage
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 Thu, 18 Jun 2020 at 22:25, Benny Lyne Amorsen via cisco-nsp
wrote:
> > I don't understand the point of SRv6. What equipment can support IPv6
> > routing, but can't support MPLS label switching?
> This probably does not change anything for SRv6, as that too will likely
> be an extra cost
On 18/Jun/20 21:02, Benny Lyne Amorsen via cisco-nsp wrote:
> It makes non-MPLS tunnelling solutions very
> attractive though, since you can get away with a very "cost-effective"
> core and only require smarts in the edge.
Such as?
Mark.
___
--- Begin Message ---
Dave Bell writes:
> I don't understand the point of SRv6. What equipment can support IPv6
> routing, but can't support MPLS label switching?
There is some equipment where the license to enable MPLS switching is
comparable in cost to the hardware itself. IPv6 routing is
can you please remove me from this list.
On 18/06/2020 09:42, Mark Tinka wrote:
On 18/Jun/20 09:30, Saku Ytti wrote:
Yes work left to be done. Ultimately the root problem is, no one cares
about IPv6. But perhaps work with vendors in parallel to LDPv6 to get
them to fix OSPFv3 and/or ISIS.
On 18/Jun/20 14:30, adamv0...@netconsultings.com wrote:
> Hence our current strategy is to stay on IPv4 control-plane (and IPv4
> management plane) as it suits, and for the foreseeable future will suite, all
> our needs (which are to transport v4 data packets via L2 MPLS VPN
> services),
> From: Mark Tinka
> Sent: Thursday, June 18, 2020 12:51 PM
>
> On 18/Jun/20 13:23, adamv0...@netconsultings.com wrote:
>
> > is the current state is not the end state, this is a pretty dynamic
> > industry
> that I'm sure is converging/evolving towards a v4:v6 parity, however the pace
> may
On 18/Jun/20 13:23, adamv0...@netconsultings.com wrote:
> You do have the LDP vs SR choice (in v4 anyways) yes there's not a good 1:1
> feature parity with v6, but the important point...
But the lack of IPv4/IPv6 parity is a crucial one.
There is only so long we can stretch IPv4, if one can
> From: NANOG On Behalf Of Mark Tinka
> Sent: Thursday, June 18, 2020 8:13 AM
>
> There are probably as many networks running SR-MPLS as there are running
> LDPv6, likely fewer if your SR deployment doesn't yet support OSPFv3 or SR-
> ISISv6. I concede that for some networks looking to go
On Thu, 18 Jun 2020 at 13:28, Robert Raszuk wrote:
> To your IGP point let me observe that OSPF runs over IP and ISIS does not.
> That is first fundamental difference. There are customers using both all over
> the world and therefore any suggestion to just use OSPFv3 is IMHO quite
>
On 18/Jun/20 12:28, Robert Raszuk wrote:
> To your IGP point let me observe that OSPF runs over IP and ISIS does
> not. That is first fundamental difference. There are customers using
> both all over the world and therefore any suggestion to just use
> OSPFv3 is IMHO quite unrealistic.
Are
Hi Saku,
To your IGP point let me observe that OSPF runs over IP and ISIS does not.
That is first fundamental difference. There are customers using both all
over the world and therefore any suggestion to just use OSPFv3 is IMHO
quite unrealistic. Keep in mind that OSPF hierarchy is 2 (or 3 with
> From: Saku Ytti
> Sent: Thursday, June 18, 2020 6:26 AM
>
> On Thu, 18 Jun 2020 at 01:17, Mark Tinka wrote:
>
> > Yes, we all love less state, I won't argue that. But it's the same question
> that is being asked less and less with each passing year - what scales better
> in
> 2020, OSPF or
On 18/Jun/20 09:30, Saku Ytti wrote:
> Yes work left to be done. Ultimately the root problem is, no one cares
> about IPv6. But perhaps work with vendors in parallel to LDPv6 to get
> them to fix OSPFv3 and/or ISIS.
Yes, this.
Vendor feedback for those not supporting LDPv6 is that there is
On Thu, 18 Jun 2020 at 10:13, Mark Tinka wrote:
> Which is great for you, me, and a ton of other folk that run IS-IS on
> Juniper. What about folk that don't have Juniper, or run OSPF?
>
> I know, not your or my problem, but the Internet isn't just a few networks.
Yes work left to be done.
On 18/Jun/20 08:34, Gert Doering wrote:
>
> There's an argument for testability of the code base here...
Which is absolutely my point.
Mark.
signature.asc
Description: OpenPGP digital signature
___
cisco-nsp mailing list
On 18/Jun/20 07:25, Saku Ytti wrote:
> The IGP mess we are in is horrible, but I can't blame SR for it. It's
> really unacceptable we spend NRE hours developing 3 identical IGP
> (OSPFv2, OSPFv3, ISIS). We all pay a 300-400% premium for a single
> IGP.
>
> In a sane world, we'd retire all of
Hi,
On Thu, Jun 18, 2020 at 12:17:20AM +0200, Mark Tinka wrote:
> Routers, in 2020, still ship with RIPv2. If anyone wants to use it (as I
> am sure there are some that do), who are we to stand in their way, if it
> makes sense for them?
There's an argument for testability of the code base
On 18/Jun/20 02:47, Phil Bedard wrote:
>
> [pmb] There are things I can do with SR and a stack of globally significant
> labels I can't do with LDP or RSVP-TE. I don't know if I'm going to call
> them programmability though, that's a loaded marketing term.
Loaded marketing terms are
On 18/Jun/20 02:32, Phil Bedard wrote:
> I look at the basic SR via IGP extensions like VPLS vs. EVPN. If we had a
> way to go back in history I'm not sure anyone would have said VPLS was a good
> idea vs. EVPN.
>
> There were reasons back in the day why something like SR wasn't done.
On 18/Jun/20 00:29, Robert Raszuk wrote:
>
> Example: If your hardware ASICs do not support IPv6 while support IPv4
> - LDPv4 will work just fine while LDPv6 will have a rather a bit of
> hard time :)
Well, safe to say that if your box doesn't support IPv6, MPLSv6 is
probably the least of
On Thu, 18 Jun 2020 at 01:17, Mark Tinka wrote:
> IOS XR does not appear to support SR-OSPFv3.
> IOS XE does not appear to support SR-ISISv6.
> IOS XE does not appear to support SR-OSPFv3.
> Junos does not appear to support SR-OSPFv3.
The IGP mess we are in is horrible, but I can't blame SR for
On 6/17/20, 6:31 PM, "cisco-nsp on behalf of Mark Tinka"
wrote:
On 17/Jun/20 23:07, adamv0...@netconsultings.com wrote:
> First of all the "SR = network programmability" is BS, SR = MPLS, any
> programmability we've had for MPLS since ever works the same way for SR.
I see
I look at the basic SR via IGP extensions like VPLS vs. EVPN. If we had a way
to go back in history I'm not sure anyone would have said VPLS was a good idea
vs. EVPN.
There were reasons back in the day why something like SR wasn't done. The
thought of global MPLS labels scared people and
>
> Anything that can support LDPv4 today can support LDPv6, in hardware.
>
While I am trying to stay out of this interesting discussion the above
statement is not fully correct.
Yes in the MPLS2MPLS path you are correct,
But ingress and egress switching vectors are very different for LDPv6 as
On 17/Jun/20 23:07, adamv0...@netconsultings.com wrote:
> First of all the "SR = network programmability" is BS, SR = MPLS, any
> programmability we've had for MPLS since ever works the same way for SR.
I see it the same way.
> Yes anything that works for RSVP-TE (i.e. PCEP), if you want
On 17/Jun/20 19:38, Saku Ytti wrote:
> I don't like this, SR-MPLS and SRv6 are just utterly different things
> to me, and no answer meaningfully applies to both.
I know they are different, but that was on purpose, because even with
SR-MPLS, there are a couple of things to consider:
* IOS
On 17/Jun/20 20:40, Dave Bell wrote:
> I don't understand the point of SRv6. What equipment can support IPv6
> routing, but can't support MPLS label switching?
Indeed.
Anything that can support LDPv4 today can support LDPv6, in hardware.
SRv6 and SRv6+ is a whole other issue, not to mention
> From: NANOG On Behalf Of Mark Tinka
> Sent: Wednesday, June 17, 2020 6:07 PM
>
>
> I've heard a lot about "network programmability", e.t.c.,
First of all the "SR = network programmability" is BS, SR = MPLS, any
programmability we've had for MPLS since ever works the same way for SR.
> but
Hey,
> Why do we really need SR? Be it SR-MPLS or SRv6 or SRv6+?
I don't like this, SR-MPLS and SRv6 are just utterly different things
to me, and no answer meaningfully applies to both.
I would ask, why do we need LDP, why not use IGP to carry labels?
Less state, protocols, SLOC, cost, bug
Hi all.
When the whole SR concept was being first dreamed up, I was mildly
excited about it. But then real life happened and global deployment (be
it basic SR-MPLS or SRv6) is what it is, and I became less excited. This
was back in 2015.
All the talk about LDPv6 this and last week has had me
66 matches
Mail list logo
