Hello NANOG community,
I am conducting a survey as part of a research project on segment routing (SR)
deployment practices among network operators. The goal is to better understand
the current state of SR deployment and how its management varies across ASes.
If you are involved in the
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 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 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 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 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 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
Owen DeLong wrote:
Saying /16 is ambiguous depends on IP version.
Not really… A /16 in IPv6 is a lot more addresses, but its still
using the first 16 bits to specify the prefix, same as IPv4.
As I wrote:
: But, it should be noted that a single class B routing table entry
: often serves for
> On Jun 23, 2020, at 4:16 AM, Masataka Ohta
> wrote:
>
> Mark Tinka wrote:
>
>>> But, it should be noted that a single class B...
>> CIDR - let's not teach the kids old news :-).
>
> Saying /16 is ambiguous depends on IP version.
Not really… A /16 in IPv6 is a lot more addresses, but it’s
On Mon, Jun 22, 2020 at 7:18 PM Randy Bush wrote:
> how did that work out for the ptts? :)
>
Though its release slipped by three years, by 1995 ATM had started to
replace IP as the protocol of choice. By 1999, IP was used only by a small
number of academic networks.
Nah, I don't think there is
adamv0...@netconsultings.com wrote:
The key takeaway however is that no single entity in SP network, be it PE,
or RR, or ASBR, ever needs everything, you can always slice and dice
indefinitely.
So to sum it up you simply can not run into any scaling ceiling with MP-BGP
architecture.
Floodi
Masataka Ohta wrote:
The point of Yakov on day one was that, flow driven approach of
Ipsilon does not scale and is unacceptable.
Though I agree with Yakov here, we must also eliminate all the
flow driven approaches by MPLS or whatever.
I still don't see them in practice, even though they may
Mark Tinka wrote:
Personally, the level of intelligence we have in routers now beyond
being just Layer 1, 2, 3 - and maybe 4 - crunching machines is just as
far as I'm willing to go.
Once upon a time in Japan, NTT proudly announced to have
developed and actually deployed telephone exchangers t
Mark Tinka wrote:
But, it should be noted that a single class B...
CIDR - let's not teach the kids old news :-).
Saying /16 is ambiguous depends on IP version.
And, if I understand BGP-MP correctly, all the routing information of
all the customers is flooded by BGP-MP in the ISP.
Yes, be
>> The requirement from the E2E principle is that routers should be
>> dumb and hosts should be clever or the entire system do not.
>> scale reliably.
>
> And yet in the PTT world, it was the other way around. Clever switching
> and dumb telephone boxes.
how did that work out for the ptts? :)
On 22/Jun/20 16:30, adamv0...@netconsultings.com wrote:
> Not quite,
> The routing information is flooded by default, but the receivers will cherry
> pick what they need and drop the rest.
> And even if the default flooding of all and dropping most is a concern -it
> can be addressed where onl
> Masataka Ohta
> Sent: Monday, June 22, 2020 1:49 PM
>
> Robert Raszuk wrote:
>
> > Moreover if you have 1000 PEs and those three sites are attached only
> > to 6 of them - only those 6 PEs will need to learn those routes (Hint:
> > RTC -
> > RFC4684)
>
> If you have 1000 PEs, you should be ser
Masataka Ohta wrote on 22/06/2020 13:49:
But, it should be noted that a single class B routing table entry
"a single class B routing table entry"? Did 1993 just call and ask for
its addressing back? :-)
But, it should be noted that a single class B routing table entry
often serves for an
On 22/Jun/20 15:17, Masataka Ohta wrote:
>
>
> The point of Yakov on day one was that, flow driven approach of
> Ipsilon does not scale and is unacceptable.
>
> Though I agree with Yakov here, we must also eliminate all the
> flow driven approaches by MPLS or whatever.
I still don't see them
On 22/Jun/20 15:08, Masataka Ohta wrote:
>
> The requirement from the E2E principle is that routers should be
> dumb and hosts should be clever or the entire system do not.
> scale reliably.
And yet in the PTT world, it was the other way around. Clever switching
and dumb telephone boxes. How
> From: Masataka Ohta
> Sent: Monday, June 22, 2020 2:17 PM
>
> adamv0...@netconsultings.com wrote:
>
> > But MPLS can be made flow driven (it can be made whatever the policy
> > dictates), for instance DSCP driven.
>
> The point of Yakov on day one was that, flow driven approach of Ipsilon
doe
On 22/Jun/20 14:49, Masataka Ohta wrote:
>
> But, it should be noted that a single class B...
CIDR - let's not teach the kids old news :-).
> If you have 1000 PEs, you should be serving for somewhere around 1000
> customers.
It's not linear.
We probably have 1 edge router serving severa
adamv0...@netconsultings.com wrote:
But MPLS can be made flow driven (it can be made whatever the policy
dictates), for instance DSCP driven…
The point of Yakov on day one was that, flow driven approach of
Ipsilon does not scale and is unacceptable.
Though I agree with Yakov here, we must als
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
Mark Tinka wrote:
So, with hierarchical routing, routing protocols can
carry only rough information around destinations, from
which, source side can not construct detailed (often
purposelessly nested) labels required for MPLS.
But hosts often point default to a clever router.
The requirement
Robert Raszuk wrote:
Neither link wise nor host wise information is required to accomplish say
L3VPN services. Imagine you have three sites which would like to
interconnect each with 1000s of users.
For a single customer of an ISP with 1000s of end users. OK.
But, it should be noted that a si
> 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
> Masataka Ohta
> Sent: Sunday, June 21, 2020 1:37 PM
>
> > Whether you do it manually or use a label distribution protocol, FEC's
> > are pre-computed ahead of time.
> >
> > What am I missing?
>
> If all the link-wise (or, worse, host-wise) information of possible
destinations
> is distributed i
this handbasket? (was Devil's Advocate - Segment
Routing, Why?)
The problem of MPLS, however, is that, it must also be flow driven,
because detailed route information at the destination is necessary
to prepare nested labels at the source, which costs a lot and should
be attempted only fo
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
> 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 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
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,
>
> 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 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
> 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
> 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
On 21/Jun/20 15:48, Robert Raszuk wrote:
>
>
> Actually when IGP changes LSPs are not recomputed with LDP or SR-MPLS
> (when used without TE :).
>
> "LSP" term is perhaps what drives your confusion --- in LDP MPLS there
> is no "Path" - in spite of the acronym (Labeled Switch *Path*). Labels
>
On 21/Jun/20 14:58, Baldur Norddahl wrote:
>
> Not really the same. Lets say the best path is through transit 1 but
> the customer thinks transit 1 sucks balls and wants his egress traffic
> to go through your transit 2. Only the VRF approach lets every BGP
> customer, even single homed ones, ma
On 21/Jun/20 14:36, Masataka Ohta wrote:
>
>
> That is a tragedy.
Well...
> If all the link-wise (or, worse, host-wise) information of possible
> destinations is distributed in advance to all the possible sources,
> it is not hierarchical but flat (host) routing, which scales poorly.
>
> R
> 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
Let's clarify a few things ...
On Sun, Jun 21, 2020 at 2:39 PM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
If all the link-wise (or, worse, host-wise) information of possible
> destinations is distributed in advance to all the possible sources,
> it is not hierarchical but flat (host
It is destination based flat routing distributed 100% before any data
packet within each layer - yes. But layers are decoupled so in a sense this
is what defines a hierarchy overall.
So transport is using MPLS LSPs most often hosts IGP routes are matched
with LDP FECs and flooded everywhere in spi
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
Mark Tinka wrote:
If information to create labels at or near sources to all the
possible destinations is distributed in advance, may be.
But this is what happens today.
That is a tragedy.
Whether you do it manually or use a label distribution protocol, FEC's
are pre-computed ahead of time.
On 21/Jun/20 13:11, Masataka Ohta wrote:
>
> If information to create labels at or near sources to all the
> possible destinations is distributed in advance, may be.
But this is what happens today.
Whether you do it manually or use a label distribution protocol, FEC's
are pre-computed ahead
On 21/Jun/20 12:45, Baldur Norddahl wrote:
>
> Yes I once made a plan to have one VRF per transit provider plus a
> peering VRF. That way our BGP customers could have a session with each
> of those VRFs to allow them full control of the route mix. I would of
> course also need a Internet VRF for
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
Robert Raszuk wrote:
MPLS LDP or L3VPNs was NEVER flow driven.
Since day one till today it was and still is purely destination based.
If information to create labels at or near sources to all the
possible destinations is distributed in advance, may be. But
it is effectively flat routing, or,
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
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 20/Jun/20 17:12, Robert Raszuk wrote:
>
> MPLS is not flow driven. I sent some mail about it but perhaps it
> bounced.
>
> MPLS LDP or L3VPNs was NEVER flow driven.
>
> Since day one till today it was and still is purely destination based.
>
> Transport is using LSP to egress PE (dst IP).
On 20/Jun/20 17:08, Robert Raszuk wrote:
>
>
> But with that let's not forget that aggregation here is still not
> spec-ed out well and to the best of my knowledge it is also not
> shipping yet. I recently proposed an idea how to aggregate SRGBs ..
> one vendor is analyzing it.
Hence why I t
On 20/Jun/20 15:39, Masataka Ohta wrote:
> Ipsilon was hopeless because, as Yakov correctly pointed out, flow
> driven approach to automatically detect flows does not scale.
>
> The problem of MPLS, however, is that, it must also be flow driven,
> because detailed route information at the desti
On 20/Jun/20 01:32, Randy Bush wrote:
> there is saku's point of distributing labels in IGP TLVs/LSAs. i
> suspect he is correct, but good luck getting that anywhere in the
> internet vendor task force. and that tells us a lot about whether we
> can actually effect useful simplification and
On 20/Jun/20 22:00, Baldur Norddahl wrote:
>
> I can't speak for the year 2000 as I was not doing networking at this
> level at that time. But when I check the specs for the base mx204 it
> says something like 32 VRFs, 2 million routes in FIB and 6 million
> routes in RIB. Clearly those numbers
On 21/Jun/20 00:54, Sabri Berisha wrote:
> That will be very advantageous in a datacenter environment, or any other
> environment dealing with a lot of ECMP paths.
>
> I can't tell you how often during my eBay time I've been troubleshooting
> end-to-end packetloss between hosts in two datacent
> 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 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 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, a
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 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 da
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
> The problem of MPLS, however, is that, it must also be flow driven,
> because detailed route information at the destination is necessary
> to prepare nested labels at the source, which costs a lot and should
> be attempted only for detected flows.
>
MPLS is not flow driven. I sent some mail abou
> 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
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
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 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
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 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 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
< 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
>
> 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 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
> 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
>
> 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 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
>
> 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,
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
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
> 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
> 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
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
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
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 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
> 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
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 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 15:24, steve ulrich wrote:
> never underestimate the desire of product managers and engineering teams to
> have their own petri dishes to swim around in.
Probably what got us (and keeps getting us) into this mess to begin with.
Mark.
On 19/Jun/20 14:50, Tim Durack wrote:
> If y'all can deal with the BU, the Cat9k family is looking
> half-decent: MPLS PE/P, BGP L3VPN, BGP EVPN (VXLAN dataplane not MPLS)
> etc.
> UADP programmable pipeline ASIC, FIB ~200k, E-LLW, mandatory DNA
> license now covers software support...
>
> Of c
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
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
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 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 19/Jun/20 10:57, Radu-Adrian Feurdean wrote:
>
> Yes, exactly that one.
> Which also happens to spill outside the DC area, because the main "vertical"
> allows it to be sold at lower prices.
These days, half the gig is filtering the snake oil.
Mark.
On 19/Jun/20 10:40, Saku Ytti wrote:
> Maybe this is fundamental and unavoidable, maybe some systematic bias
> in human thinking drives us towards simple software and complex
> hardware.
>
> Is there an alternative future, where we went with Itanium? Where we
> have simple hardware and an increa
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
1 - 100 of 168 matches
Mail list logo
