Mailing List Archive

On 18/Jun/20 14:30, adamv0025@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&v6 data packets via L2&L3 MPLS VPN services), there are simply more important projects than to experiment with v6 control-plane, like for instance perfecting/securing the v6 customer facing services (delivered over the underlying v4 signalled MPLS infrastructure, that no customer really cares about).

Fair enough.


> But I understand your frustrations case it seems like you're taking the bullet for us late adopters and in a sense you are, cause say in 10 years from now when I decide to migrate to v6 control-plane and management-plane as then it might be viewed as common courtesy, it will be all there on a silver plate waiting for me allowing for a relatively effortless and painless move. All thanks to you fighting the good fight today.

You better hope and pray I don't run out wine. Equipment manufacturers
make me drink, and I like my wine :-).


> And I'd say the future is now, cause there is an actual need for v6 services.
> But need for v6 control & management plane? - It's not like operators are losing business opportunities not having that. (they might even be viewed as conservative->stable, which might be preferred by some customers).

Well, the other way to look at it, especially if you are a Broadband or
mobile network operator, is what your plan is when you can no longer
stretch the IPv4 you have, can no longer obtain IPv4 from an RIR, and
can't afford to buy IPv4 on the open market.

For mobile operators, paying US$50 million/year in CGN line cards and
licensing is not even a rounding error on the books. But the telco space
has been under pressure for some time now, further amplified and
accelerated this Coronavirus pandemic. Even though mobile networks are
ATM machines printing money for the shareholders, they probably made
more money in the days of SMS than they do now building and selling
4G/5G packet cores. At some point, that US$50 million/year is going to
start getting some ex-co and Board level visibility, as capex spend
begins to pinch revenue because of the data demands of subscribers, and
the ever-falling ARPU's to go along with it.

Perhaps, at that point, massive IPv6 deployment in the mobile space is
what will wake everyone else up, as the race to grab on to every $$
tightens.

Mark.

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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.
> Yes, this.
>
> Vendor feedback for those not supporting LDPv6 is that there is no
> demand for it. And like I said in the previous thread, LDPv6 demand is
> not about LDPv6, it's about IPv6.
>
> If the majority of the high-paying vendors' favorite customers that pay
> for CGN's continue to do so, what incentive do they have to ask for
> IPv6. The T-Mobile US's of the world are few and far between, sadly.
>
> I suppose I would not be unwilling to push the vendors to support
> SR-OSPFv3 and SR-ISISv6 as I am also pushing them to support LDPv6 where
> it is lacking, because at some point in the future, I do want to deploy
> SR-MPLS in the same way I envisioned doing so back in 2014. I just need
> to take it on a few dates first before I bring it home to meet the folks
> :-).
>
>
>
>> FWIW I am definitely saying that, and it should be IGP+BGP. I do
>> accept and realise a lot of platforms only did and do Martini not
>> Kompella, so reality isn't quite there.
> That was me in 2013/2014. Dump LDP, dump RSVP, get SR deployed, forward
> IPv4 natively in MPLSv4, and IPv6 natively in MPLSv6. But life happened.
>
> Nonetheless, I will go SR-MPLS in many years to come, after I'm feeling
> comfortable about it. That's a promise. But until then, I'd like
> trusted, stable IPv4-IPv6 MPLS forwarding parity.
>
> I have never cared much for VPLS because I thought it was a very messy
> piece of tech. from Day 1. And while EVPN makes more sense, for our
> market, more than 98% of the traffic we sell is IP-based, so we have no
> demand for mp2mp Ethernet VPN's. But for those that adore VPLS (or
> EVPN), let them have the choice of LDP or BGP, which both Cisco and
> Juniper, after years of muscle-flexing, both ended up agreeing on
> anyway, despite all the fuss.
>
> So the LDPv6 vs. SR-MPLS vs. SRv6 vs. SRv6+ posturing is a rehash of
> those LDP vs. BGP days, which just wastes everyone's time.
>
> Mark.
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Thu, 18 Jun 2020 at 22:25, Benny Lyne Amorsen via cisco-nsp
<cisco-nsp@puck.nether.net> 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 license. 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.

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 overhead on the tunnel.

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, if we drive MPLS, we drive
cost down.

Even today in many cases you can take a cheap L2 chip, and make it an
MPLS switch, due to them supporting VLAN swap! Which has no clue of
IPV6 or IPV4.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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, if we drive MPLS, we drive
> cost down.
>
> Even today in many cases you can take a cheap L2 chip, and make it an
> MPLS switch, due to them supporting VLAN swap! Which has no clue of
> IPV6 or IPV4.

We need a new toy.

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 pipes.

So we need to invent a new toy around which we can wrap a story about
"adding value to your network" to "drive new business" and "reduce
operating costs", to entice money to leave wallets, when all that's
really still happening is the selling of more boxes and line cards, so
that we can continue to broaden carriage pipes.

There are very few things that have been designed well from scratch, and
stand the test of time regardless of how much wind is thrown at them.
MPLS is one of those things, IMHO. Nearly 20 years to the day since
inception, and I still can't find another packet forwarding technology
that remains as relevant and versatile as it is simple.

Mark.

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Fri, 19 Jun 2020 at 11:03, Mark Tinka <mark.tinka@seacom.mu> 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 pipes.
>
> So we need to invent a new toy around which we can wrap a story about
> "adding value to your network" to "drive new business" and "reduce
> operating costs", to entice money to leave wallets, when all that's
> really still happening is the selling of more boxes and line cards, so
> that we can continue to broaden carriage pipes.

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 stack, to have a great
ecosystem on software to deal with MPLS, which is easy to fix, we are
fixing that in silicon, which is hard and expensive to fix.

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 starting from networks.


>
> There are very few things that have been designed well from scratch, and
> stand the test of time regardless of how much wind is thrown at them.
> MPLS is one of those things, IMHO. Nearly 20 years to the day since
> inception, and I still can't find another packet forwarding technology
> that remains as relevant and versatile as it is simple.
>
> Mark.
>


--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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 stack, to have a great
> ecosystem on software to deal with MPLS, which is easy to fix, we are
> fixing that in silicon, which is hard and expensive to fix.
>
> 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 starting from networks.

Which I totally appreciate and, fundamentally, have nothing against.

My concern is when we, service providers, start to get affected because
equipment manufacturers need to follow the data centre money hard, often
at our expense. This is not only in the IP world, but also in the
Transport world, where service providers are having to buy DWDM gear
formatted for DCI. Yes, it does work, but it's not without its
eccentricities.

Cycling, over the past decade, between TRILL, OTV, SPB, FabricPath,
VXLAN, NV-GRE, ACI... and perhaps even EVPN, there is probably a lesson
to be learned.

Mark.

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Fri, 19 Jun 2020 at 11:35, Mark Tinka <mark.tinka@seacom.mu> 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 starting from networks.
>
> Which I totally appreciate and, fundamentally, have nothing against.
>
> My concern is when we, service providers, start to get affected because
> equipment manufacturers need to follow the data centre money hard, often
> at our expense. This is not only in the IP world, but also in the
> Transport world, where service providers are having to buy DWDM gear
> formatted for DCI. Yes, it does work, but it's not without its
> eccentricities.
>
> Cycling, over the past decade, between TRILL, OTV, SPB, FabricPath,
> VXLAN, NV-GRE, ACI... and perhaps even EVPN, there is probably a lesson
> to be learned.

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 increasingly complex compiler and
increasingly complex runtime making sure the program runs fast on that
simple hardware?
Instead we have two guys in tel aviv waking up in night terror every
night over confusion why does x86 run any code at all, how come it
works. And I'm at home 'hehe new intc make program go fast:)))'

Now that we have comparatively simple compilers and often no runtime
at all, the hardware has to optimise the shitty program for us, but as
we don't get to see how the sausage is made, we think it's probably
something that is well done, robust and correct. If we'd do this in
software, we'd all have to suffer how fragile the compiler and runtime
are and how unapproachable they are.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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 increasingly complex compiler and
> increasingly complex runtime making sure the program runs fast on that
> simple hardware?
> Instead we have two guys in tel aviv waking up in night terror every
> night over confusion why does x86 run any code at all, how come it
> works. And I'm at home 'hehe new intc make program go fast:)))'
>
> Now that we have comparatively simple compilers and often no runtime
> at all, the hardware has to optimise the shitty program for us, but as
> we don't get to see how the sausage is made, we think it's probably
> something that is well done, robust and correct. If we'd do this in
> software, we'd all have to suffer how fragile the compiler and runtime
> are and how unapproachable they are.

So this brings back a discussion you and I had last year about a
scenario where the market shifts toward open vendor in-house silicon,
sold as a PCI card one can stick in a server.

Trio, ExpressPlus, Lightspeed, Silicon One, Cylon, QFP, e.t.c., with
open specs. so that folk can code for them and see what happens.

At the moment, everyone is coding for x86 as an NPU, and we know that
path is not the cheapest or most efficient for packet forwarding.

Vendors may feel a little skittish about "giving away" their IP, but I
don't think it's an issue because:

* The target market is folk currently coding for x86 CPU's to run as
NPU's.

* No one is about to run 100Gbps backbones on a PCI card. But hey, the
world does surprise :-).

* Writing code for forwarding traffic as well as control plane
protocols is not easy. Buying a finished product from an equipment
vendor will be the low-hanging fruit for most of the landscape.

It potentially also has the positive side effect of getting Broadcom to
raise their game, which would make them a more viable option for
operators with significant high-touch requirements.

As we used to say in Vladivostok, "It could be a win win" :-).

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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 can't sell such box and IP switching has
been added to data plane there.

Bottom line - I doubt you will find any vendor (from OEM to big ones) which
can afford to differentiate price wise boxes which would do line rate MPLS
and any thing less then line rate for IP. And as such IP clearly brings a
lot of value for simplification of control plane and route aggregation and
IMHO is a good (well best) universal transport today for all types of
services from WAN via Campus to DCs (or even MSDCs).

Cheers,
R.








On Fri, Jun 19, 2020 at 9:36 AM Saku Ytti <saku@ytti.fi> wrote:

> On Thu, 18 Jun 2020 at 22:25, Benny Lyne Amorsen via cisco-nsp
> <cisco-nsp@puck.nether.net> 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 license. 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.
>
> 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 overhead on the tunnel.
>
> 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, if we drive MPLS, we drive
> cost down.
>
> Even today in many cases you can take a cheap L2 chip, and make it an
> MPLS switch, due to them supporting VLAN swap! Which has no clue of
> IPV6 or IPV4.
>
> --
> ++ytti
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Fri, 19 Jun 2020 at 13:29, Robert Raszuk <robert@raszuk.net> 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 hardware cost and performance when you would only need to switch at rates MPLS.
>
> Well real world showed that you can't sell such box and IP switching has been added to data plane there.

IP switching was there day 1, just not at DFZ scale in Broadway. But
indeed, they got DFZ scale at Paradise, using off-chip HMC. Which is
bad in numerous ways, not just because it costs a lot (there is either
2 or 3 HMC chip for every PE chip, so like double the front-plate
without HMC) but it also makes the device fragile. There are 6 PE
chips per LC, so 3*6 18 HMC chips, any of these HMC chips gets any
problem and it's a full linecard reload of 15-20min. Even though 2/3
of the HMC chips are just delay buffer, and could be reloaded locally
without impacting anything else. The remaiing 1/3 is lookup tables,
and it can be argued it's cheaper to reload whole linecard than figure
out how to resynchornise the FIB.

Anyhow this design adds your cost, removes your ports and increases
your outages.

> Bottom line - I doubt you will find any vendor (from OEM to big ones) which can afford to differentiate price wise boxes which would do line rate MPLS and any thing less then line rate for IP. And as such IP clearly brings a lot of value for simplification of control plane and route aggregation and IMHO is a good (well best) universal transport today for all types of services from WAN via Campus to DCs (or even MSDCs).

Maybe I'm naive, but I believe we can learn.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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 switch at rates MPLS.
>
> Well real world showed that you can't sell such box and IP switching has
> been added to data plane there.
>
> Bottom line - I doubt you will find any vendor (from OEM to big ones) which
> can afford to differentiate price wise boxes which would do line rate MPLS
> and any thing less then line rate for IP. And as such IP clearly brings a
> lot of value for simplification of control plane and route aggregation and
> IMHO is a good (well best) universal transport today for all types of
> services from WAN via Campus to DCs (or even MSDCs).

I would agree to some extent.

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:

   
https://www.insight.com/en_US/shop/product/CRS-LSP/CISCO%20SYSTEMS/CRS-LSP/Cisco-CRS3-Label-Switch-Processor--control-processor/

The goal was a packet processor cheaper than both the MSC and FP data
planes that had been shipping at the time. The LSP card had reduced IP
and QoS scale, as the idea was that all the heavy-lifting would be done
in MPLS.

But, as with the ASR14000 and ME2600X boxes, the LSP card didn't last
long. I guess Cisco figured the FP was a better option, as more and more
traffic started leaving VPN's for the cloud and CDN's.

For us, the PTX1000/10002 make absolute sense, and are options we are
clearly looking at for fixed form factor core platforms as we seek
cheaper 100Gbps ports than we can currently get for the CRS (or even the
MX and ASR9000).

For us, a low-scale IP services box or line card for the core is
something we are very interested in. We don't need rich IP services in
that area of the network, nor do we need rich MPLS services either.
Simple, low-scale IP/MPLS will do.

But for data centre operators who may be anti-MPLS, the vendors will be
stuck between how they develop for them and how they develop for network
operators, for some time to come.

Mark.

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Fri, 19 Jun 2020 at 14:04, Mark Tinka <mark.tinka@seacom.mu> 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 low scale is pretty high scale in this context.

I think there would be market for on-chip only LSR/core cards.
Ultimately if you design for that day1, it won't add lot of costs to
you. Yes the BOM difference may not be that great, because ultimately
silicon is cheap and costs are in NRE. But the on-chip only cards
would have bit more ports and they'd have better availability due to
less component failures.
I would fight very hard for us buy such cards in core, if vendor would
offer them.

Like the trio-in-pci full open, I think this is just marketing
failure. Vendors are wearing their DC glasses and don't see anything
else. While the big-name DC are lost cause, AMZN employs more chip
designers than JNPR, matter of time before JNPR loses amzn edge too to
internal amzn product.

Someone with bit bolder vision on what the market could be, may have
real opportunity here.
--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

> 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.

r.


On Fri, Jun 19, 2020 at 1:04 PM Mark Tinka <mark.tinka@seacom.mu> wrote:

>
>
> 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 switch at rates MPLS.
> >
> > Well real world showed that you can't sell such box and IP switching has
> > been added to data plane there.
> >
> > Bottom line - I doubt you will find any vendor (from OEM to big ones)
> which
> > can afford to differentiate price wise boxes which would do line rate
> MPLS
> > and any thing less then line rate for IP. And as such IP clearly brings a
> > lot of value for simplification of control plane and route aggregation
> and
> > IMHO is a good (well best) universal transport today for all types of
> > services from WAN via Campus to DCs (or even MSDCs).
>
> I would agree to some extent.
>
> 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:
>
>
>
> https://www.insight.com/en_US/shop/product/CRS-LSP/CISCO%20SYSTEMS/CRS-LSP/Cisco-CRS3-Label-Switch-Processor--control-processor/
>
> The goal was a packet processor cheaper than both the MSC and FP data
> planes that had been shipping at the time. The LSP card had reduced IP
> and QoS scale, as the idea was that all the heavy-lifting would be done
> in MPLS.
>
> But, as with the ASR14000 and ME2600X boxes, the LSP card didn't last
> long. I guess Cisco figured the FP was a better option, as more and more
> traffic started leaving VPN's for the cloud and CDN's.
>
> For us, the PTX1000/10002 make absolute sense, and are options we are
> clearly looking at for fixed form factor core platforms as we seek
> cheaper 100Gbps ports than we can currently get for the CRS (or even the
> MX and ASR9000).
>
> For us, a low-scale IP services box or line card for the core is
> something we are very interested in. We don't need rich IP services in
> that area of the network, nor do we need rich MPLS services either.
> Simple, low-scale IP/MPLS will do.
>
> But for data centre operators who may be anti-MPLS, the vendors will be
> stuck between how they develop for them and how they develop for network
> operators, for some time to come.
>
> Mark.
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

But talking about commodity isn't this mainly Broadcom ? And is there
single chip there which does not support line rate IP ? Or 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 <
cisco-nsp@puck.nether.net> wrote:

>
>
>
> ---------- Forwarded message ----------
> From: Benny Lyne Amorsen <benny+usenet@amorsen.dk>
> 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 <saku@ytti.fi> 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 overhead on the tunnel.
>
> What you say is obviously true.
>
> However, no one AFAIK makes an MPLS switch at prices comparable to basic
> layer 3 IPv6 switches. You can argue that it is a market failure as much
> as you want, but I can only buy what is on the market. According to the
> market, MPLS is strictly Service Provider, with the accompanying Service
> Provider markup (and then ridiculous discounts to make the prices seem
> reasonable). Enterprise and datacenter are not generally using MPLS, and
> I can only look on in envy at the prices of their equipment.
>
> There is room for a startup to rethink the service provider market by
> using commodity enterprise equipment. Right now that means dumping MPLS,
> since that is only available (if at all) at the most expensive license
> level. Meanwhile you can get get low-scale BGPv6 and line-speed GRE with
> commodity hardware without extra licenses.
>
> I am not saying that it will be easy to manage such a network, the
> tooling for MPLS is vastly superior. I am merely saying that with just a
> simple IPv6-to-the-edge network you can deliver similar services to an
> MPLS-to-the-edge network at lower cost, if you can figure out how to
> build the tooling.
>
> Per-packet overhead is hefty. Is that a problem today?
>
>
>
>
> ---------- Forwarded message ----------
> From: Benny Lyne Amorsen via cisco-nsp <cisco-nsp@puck.nether.net>
> 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?
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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 use-cases, because, as
you say, that is pretty high scale as well, already :-).

I think the SE line cards are meant for high-capacity BNG terminations
in a single chassis, per line card. But with most IP traffic a network
is carrying being best-effort and capacity available all over the place,
what's the point anymore?


>
> I think there would be market for on-chip only LSR/core cards.
> Ultimately if you design for that day1, it won't add lot of costs to
> you. Yes the BOM difference may not be that great, because ultimately
> silicon is cheap and costs are in NRE. But the on-chip only cards
> would have bit more ports and they'd have better availability due to
> less component failures.
> I would fight very hard for us buy such cards in core, if vendor would
> offer them.

Same here.

For now, we are exploring the PTX1000/10002 machinery. I know fixed form
factor boxes for a core are a bit strange, but looking at how far the
tech has come, I'm feeling a lot more bullish about having a core box
that isn't redundant in control planes, data planes, and all the rest.
Just power supplies :-).

A lot of money to be saved if the idea works.


> Like the trio-in-pci full open, I think this is just marketing
> failure. Vendors are wearing their DC glasses and don't see anything
> else. While the big-name DC are lost cause, AMZN employs more chip
> designers than JNPR, matter of time before JNPR loses amzn edge too to
> internal amzn product.
>
> Someone with bit bolder vision on what the market could be, may have
> real opportunity here.

This is what I've been telling the vendors since about 2017, both IP and
Transport. It's only a matter of time before the level of development
happening in the cloud + content houses far surpasses what the vendors
are doing, if not already. Why spend all your time, energy and resources
on a market that isn't going to find use for your NRE, and can probably
out-code  and out-research you with one hand tied behind their back, any
day?

The only reason they aren't building their own core routers yet is
because that's an area where they can still afford to offload
development time to the vendors. The edge is where they need to badly
optimize, and they will do it a lot more efficiently than the vendors
can, in time, if not already.

When I saw one cloud provider present their idea on collapsing an entire
DWDM line card into an optic that they can code for and stick into a
server, I saw the DWDM's vendor's hearts sink right across the table
where I sat. This was 3 years ago.

The vendors need, as you say, someone with a bold enough vision to pivot
the tradition.

Mark.

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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 in forcing it to traverse some
> specific core boxes.

In 2015, we had a customer that wanted EoMPLS services that simulated
EoDWDM behaviour, i.e., if the path failed, don't automatically
re-route, which is what LDP does by default.

So, reluctantly, we built a bunch of RSVP-TE tunnels, but only because
it was short-term, the money was great, and there was a migration path
toward EoDWDM.

As soon as they migrated, we ditched RSVP. All our network runs only on
LDP. I can't stand RSVP :-).

Granted, SR-TE is meant to be a lot more hassle-free than RSVP-TE was,
but I still wouldn't do it, as I can throw bandwidth at the problem.

At a previous job, we ran p2mp RSVP-TE to deliver IPTV Multicast in
NG-MVPN infrastructure. We'd began testing our migration to p2mp mLDP,
so we can dump RSVP, but then I had to bail and move on.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Fri, 19 Jun 2020 at 14:23, Benny Lyne Amorsen via cisco-nsp
<cisco-nsp@puck.nether.net> 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 per-packet overhead attacker gets huge leverage,
as they inject pure IP, then we add overhead, and we need that
overhead capacity everywhere to transport it.

I'd say the fundamental metrics are

a) tunnel must be LEM only on a small on-chip database
b) tunnel header must be narrow
c) tunnel header must be transistor cheap to parse (wattage, yield)
d) all traffic in core must be tunneled

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Fri, 19 Jun 2020 at 14:26, Mark Tinka <mark.tinka@seacom.mu> 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
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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 to learn how to code for hardware and protocols.

There are many start-ups that are working off of commodity chips and
commodity face plates. Building software for those disparate hardware
systems, and then developing the software so that it can be used in
commercial deployments is non-trivial. That is the leverage Cisco,
Juniper, Nokia... even Huawei, have, and they won't let us forget it.

Then again, if one's vision is bold enough, they could play the long
game, start now, patiently build, and then come at us in 8 or so years.
Because the market, surely, can't continue at the rate we are currently
going. Everything else around us is dropping in price and revenue, and
yet traditional routing and switching equipment continues to stay the
same, if not increase. That's broken!`

Mark.

On 19/Jun/20 13:25, Robert Raszuk wrote:
> But talking about commodity isn't this mainly Broadcom ? And is there
> single chip there which does not support line rate IP ? Or 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 <
> cisco-nsp@puck.nether.net> wrote:
>
>>
>>
>> ---------- Forwarded message ----------
>> From: Benny Lyne Amorsen <benny+usenet@amorsen.dk>
>> 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 <saku@ytti.fi> 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 overhead on the tunnel.
>> What you say is obviously true.
>>
>> However, no one AFAIK makes an MPLS switch at prices comparable to basic
>> layer 3 IPv6 switches. You can argue that it is a market failure as much
>> as you want, but I can only buy what is on the market. According to the
>> market, MPLS is strictly Service Provider, with the accompanying Service
>> Provider markup (and then ridiculous discounts to make the prices seem
>> reasonable). Enterprise and datacenter are not generally using MPLS, and
>> I can only look on in envy at the prices of their equipment.
>>
>> There is room for a startup to rethink the service provider market by
>> using commodity enterprise equipment. Right now that means dumping MPLS,
>> since that is only available (if at all) at the most expensive license
>> level. Meanwhile you can get get low-scale BGPv6 and line-speed GRE with
>> commodity hardware without extra licenses.
>>
>> I am not saying that it will be easy to manage such a network, the
>> tooling for MPLS is vastly superior. I am merely saying that with just a
>> simple IPv6-to-the-edge network you can deliver similar services to an
>> MPLS-to-the-edge network at lower cost, if you can figure out how to
>> build the tooling.
>>
>> Per-packet overhead is hefty. Is that a problem today?
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Benny Lyne Amorsen via cisco-nsp <cisco-nsp@puck.nether.net>
>> 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?
>> _______________________________________________
>> cisco-nsp mailing list cisco-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> .

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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 course you do have to deal with a BU that lives in a parallel universe
(SDA, LISP, NEAT etc) - but the hardware is the right price-perf, and
IOS-XE is tolerable.

No large FIB today, but Cisco appears to be headed towards "Silicon One"
for all of their platforms: RTC ASIC strapped over some HBM. The strategy
is interesting: sell it as a chip, sell it whitebox, sell it fully packaged.

YMMV

On Fri, Jun 19, 2020 at 7:40 AM Mark Tinka <mark.tinka@seacom.mu> wrote:

> 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 to learn how to code for hardware and protocols.
>
> There are many start-ups that are working off of commodity chips and
> commodity face plates. Building software for those disparate hardware
> systems, and then developing the software so that it can be used in
> commercial deployments is non-trivial. That is the leverage Cisco, Juniper,
> Nokia... even Huawei, have, and they won't let us forget it.
>
> Then again, if one's vision is bold enough, they could play the long game,
> start now, patiently build, and then come at us in 8 or so years. Because
> the market, surely, can't continue at the rate we are currently going.
> Everything else around us is dropping in price and revenue, and yet
> traditional routing and switching equipment continues to stay the same, if
> not increase. That's broken!`
>
> Mark.
>
> On 19/Jun/20 13:25, Robert Raszuk wrote:
>
> But talking about commodity isn't this mainly Broadcom ? And is there
> single chip there which does not support line rate IP ? Or 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 <cisco-nsp@puck.nether.net> wrote:
>
>
> ---------- Forwarded message ----------
> From: Benny Lyne Amorsen <benny+usenet@amorsen.dk> <benny+usenet@amorsen.dk>
> 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 <saku@ytti.fi> <saku@ytti.fi> 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 overhead on the tunnel.
>
> What you say is obviously true.
>
> However, no one AFAIK makes an MPLS switch at prices comparable to basic
> layer 3 IPv6 switches. You can argue that it is a market failure as much
> as you want, but I can only buy what is on the market. According to the
> market, MPLS is strictly Service Provider, with the accompanying Service
> Provider markup (and then ridiculous discounts to make the prices seem
> reasonable). Enterprise and datacenter are not generally using MPLS, and
> I can only look on in envy at the prices of their equipment.
>
> There is room for a startup to rethink the service provider market by
> using commodity enterprise equipment. Right now that means dumping MPLS,
> since that is only available (if at all) at the most expensive license
> level. Meanwhile you can get get low-scale BGPv6 and line-speed GRE with
> commodity hardware without extra licenses.
>
> I am not saying that it will be easy to manage such a network, the
> tooling for MPLS is vastly superior. I am merely saying that with just a
> simple IPv6-to-the-edge network you can deliver similar services to an
> MPLS-to-the-edge network at lower cost, if you can figure out how to
> build the tooling.
>
> Per-packet overhead is hefty. Is that a problem today?
>
>
>
>
> ---------- Forwarded message ----------
> From: Benny Lyne Amorsen via cisco-nsp <cisco-nsp@puck.nether.net> <cisco-nsp@puck.nether.net>
> 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?
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> .
>
>
>

--
Tim:>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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 course you do have to deal with a BU that lives in a parallel
> universe (SDA, LISP, NEAT etc) - but the hardware is the right
> price-perf, and IOS-XE is tolerable.
>
> No large FIB today, but Cisco appears to be headed towards "Silicon
> One" for all of their platforms: RTC ASIC strapped over some HBM. The
> strategy is interesting: sell it as a chip, sell it whitebox, sell it
> fully packaged.
>
> YMMV

I'd like to hear what Gert thinks, though. I'm sure he has a special
place for the word "Catalyst" :-).

Oddly, if Silicon One is Cisco's future, that means IOS XE may be headed
for the guillotine, in which case investing any further into an IOS XE
platform could be dicey at best, egg-face at worst.

I could be wrong...

Mark.

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

>
> On Jun 19, 2020, at 08:06, Mark Tinka <mark.tinka@seacom.mu> 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, mandatory DNA
>> license now covers software support...
>>
>> Of course you do have to deal with a BU that lives in a parallel
>> universe (SDA, LISP, NEAT etc) - but the hardware is the right
>> price-perf, and IOS-XE is tolerable.
>>
>> No large FIB today, but Cisco appears to be headed towards "Silicon
>> One" for all of their platforms: RTC ASIC strapped over some HBM. The
>> strategy is interesting: sell it as a chip, sell it whitebox, sell it
>> fully packaged.
>>
>> YMMV
>
> I'd like to hear what Gert thinks, though. I'm sure he has a special
> place for the word "Catalyst" :-).
>
> Oddly, if Silicon One is Cisco's future, that means IOS XE may be headed
> for the guillotine, in which case investing any further into an IOS XE
> platform could be dicey at best, egg-face at worst.
>
> I could be wrong...

never underestimate the desire of product managers and engineering teams to have their own petri dishes to swim around in.

--
steve ulrich (sulrich@botwerks.*)

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/