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 refl
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 surf
On Wed, 17 Jun 2020 at 18:42, Saku Ytti wrote:
> 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 don't understand the point of SRv6. What equipm
> 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
On 17/06/2020 18:38, Saku Ytti wrote:
>> 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?
>
>
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 XR
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
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 to
On 17/Jun/20 23:46, Tom Hill wrote:
> Unsurprisingly, there would be no way on Earth that I could have said
> that better, so you shall find only loud cheering from over here.
Out of pure curiousity, have you deployed (or are you deploying)?
Mark.
>
> 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
y
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 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 your
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 th
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. Ultim
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
> 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 IS
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 su
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 you
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
> unrealisti
> 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 SR-MPLS
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: 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 b
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&v6 data packets via L2&L3 MPLS VPN
> services
On Wed, Jun 17, 2020, at 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?
A whole ocean of "datacenter" hardware, from pretty much evey vendor. Because
many of them automatically link MPLS to RSV
On Fri, 19 Jun 2020 at 10:24, Radu-Adrian Feurdean
wrote:
> > I don't understand the point of SRv6. What equipment can support IPv6
> > routing, but can't support MPLS label switching?
>
> A whole ocean of "datacenter" hardware, from pretty much evey vendor. Because
> many of them automatically
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 given
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 lo
On Fri, Jun 19, 2020, at 10:11, Mark Tinka wrote:
>
> 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, pret
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.
> Saku Ytti
> Sent: Friday, June 19, 2020 8:50 AM
>
> On Fri, 19 Jun 2020 at 10:24, Radu-Adrian Feurdean adrian.feurdean.net> wrote:
>
>
> > > I don't understand the point of SRv6. What equipment can support
> > > IPv6 routing, but can't support MPLS label switching?
> >
> Maybe these inferior
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 pipes.
The problem of MPLS, or label s
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 scal
Hi Mark,
As actually someone who was at that table you are referring to - I must say
that MPLS was never proposed as replacement for IP.
MPLS was since day one proposed as enabler for services originally L3VPNs
and RSVP-TE. Then bunch of others jumped on the same encapsulation train.
If at that v
> MPLS was since day one proposed as enabler for services originally
> L3VPNs and RSVP-TE.
MPLS day one was mike o'dell wanting to move his city/city traffic
matrix from ATM to tag switching and open cascade's hold on tags.
randy
Mark Tinka wrote:
I wouldn't agree.
MPLS is a purely forwarding paradigm, as is hop-by-hop IP.
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
Conven
Robert Raszuk wrote:
MPLS was since day one proposed as enabler for services originally L3VPNs
and RSVP-TE.
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 s
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 is
>
> But, today, people are seems to be using, so called, MPLS, with
>
explicitly configured flows, administration of which does not
> scale and is annoying.
>
I am actually not sure what you are talking about here.
The only per flow action in any MPLS deployments I have seen was mapping
flow grou
> On Jun 19, 2020, at 11:34 AM, Randy Bush wrote:
>
>
>>
>> MPLS was since day one proposed as enabler for services originally
>> L3VPNs and RSVP-TE.
>
> MPLS day one was mike o'dell wanting to move his city/city traffic
> matrix from ATM to tag switching and open cascade's hold on tags.
A
On Wed, Jun 17, 2020 at 11:40 AM Dave Bell wrote:
>
>
> On Wed, 17 Jun 2020 at 18:42, Saku Ytti wrote:
>
>> 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 appl
>
> 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 hops
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 Internet
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 propos
On Sat, Jun 20, 2020 at 11:08 AM Mark Tinka wrote:
> > MPLS with hierarchical routing just does not scale.
>
> With Internet in a VRF, I truly agree.
>
> But if you run a simple global BGP table and no VRF's, I don't see an
> issue. This is what we do, and our scaling concerns are exactly the sam
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 t
Mark Tinka wrote:
At the time I proposed label switching, there already was RSVP
but RSVP-TE was proposed long after MPLS was proposed.
RSVP failed to take off, for whatever reason (I can think of many).
There are many. So, our research group tried to improve RSVP.
Practically, the most ser
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 commercia
On Sat, Jun 20, 2020 at 12:38 PM Mark Tinka wrote:
>
>
> 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 man
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 Jun 20, 2020, at 2:27 PM, Mark Tinka wrote:
Hi Mark,
> 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,
That will be very advantageous in
> On Jun 20, 2020, at 2:27 PM, Mark Tinka wrote:
>
>
>
> 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
>
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 datacent
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
Mark Tinka 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 commercial setting.
No, of course, b
On Sun, Jun 21, 2020 at 9:56 AM Mark Tinka wrote:
>
>
> 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
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 b
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 for
On Sun, Jun 21, 2020 at 1:30 PM Mark Tinka wrote:
>
>
> 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 ro
> I'm saying that, if some failure occurs and IGP changes, a
> lot of LSPs must be recomputed, which does not scale
> if # of LSPs is large, especially in a large network
> where IGP needs hierarchy (such as OSPF area).
>
> Masataka Ohta
>
Actually
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, ma
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
>
> The LFIB in each node need only be as large as the number of LDP-enabled
routers in the network.
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
> From: NANOG On Behalf Of Mark Tinka
> Sent: Friday, June 19, 2020 7:28 PM
>
>
> 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 route
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 the
>
> I should point out that all of my input here is based on simple MPLS
> forwarding of IP traffic in the global table. In this scenario, labels
> are only assigned to BGP next-hops, which is typically an IGP Loopback
> address.
>
Well this is true for one company :) Name starts with j
Othe
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. But,
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 alw
> Wouldn't T-LDP fix this, since LDP LFA is a targeted session?
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.
Best,
R.
On Sun, Jun 21, 2020 at 10:58 PM Mark Tinka wrote:
>
>
> On 21/Jun/2
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 route
> From: NANOG On Behalf Of Masataka Ohta
> Sent: Friday, June 19, 2020 5:01 PM
>
> 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 5
Hi Baldur,
>From memory mx204 FIB is 10M (v4/v6) and RIB 30M for each v4 and v6.
And remember the FIB is hierarchical -so it’s the next-hops per prefix you are
referring to with BGP FRR. And also going from memory of past scaling testing,
if pfx1+NH1 == x, then Pfx1+NH1+NH2 !== 2x, where x
On Wed, 17 Jun 2020 at 22:09, wrote:
>
> > 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
On Wed, 17 Jun 2020 at 18:08, Mark Tinka wrote:
>
> 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
> 2
On Wed, 17 Jun 2020 at 23:19, 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 IS-IS. That is becoming less relevant as control planes keep
> getting
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 Tue, 30 Jun 2020 at 22:07, Mark Tinka wrote:
>
>
>
> 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...
True, but what's changed in two weeks
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 bac
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. The
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
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 pip
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: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 sta
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 increa
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
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
ck.nether.net> wrote:
>
>>
>>
>> -- Forwarded message --
>> From: Benny Lyne Amorsen
>> To: cisco-...@puck.nether.net
>> Cc:
>> Bcc:
>> Date: Fri, 19 Jun 2020 13:12:06 +0200
>> Subject: Re: [c-nsp] Devil's Advocate - Segment Rout
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
> wrote:
>
>
> -- Forwarded message --
> From: Benny Lyne Amorsen
> To: cis
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 c
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 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, E-LLW,
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 posit
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 software
> Maybe this is fundamental and unavoidable, maybe some systematic bias
> in human thinking drives us towards simple software and complex
> hardware.
how has software progressed in the last 50-70 years as compared to
hardware?
my watch has how many orders of magnitude of compute vs the computer
w
>
> 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 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 da
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 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, a
< ranting of a curmudgeonly old privileged white male >
>>> MPLS was since day one proposed as enabler for services originally
>>> L3VPNs and RSVP-TE.
>> MPLS day one was mike o'dell wanting to move his city/city traffic
>> matrix from ATM to tag switching and open cascade's hold on tags.
> And II
Randy Bush wrote:
MPLS was since day one proposed as enabler for services originally
L3VPNs and RSVP-TE.
MPLS day one was mike o'dell wanting to move his city/city traffic
matrix from ATM to tag switching and open cascade's hold on tags.
And IIRC, Tag switching day one was Cisco overreacting t
> 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.
Perhaps I will surprise a few but this is not only already in RFC formats -
it is also shipping already across vendors for some time
1 - 100 of 131 matches
Mail list logo