Mailing List Archive

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 surface

And we get more features to boot, with LDP if you want LFA, you need
to form tLDP to every Q-space node, on top of your normal LDP, because
you don't know label view from anyone else but yourself. With SR by
nature you know the label view for everyone, thus you have full LFA
coverage for free, by-design.
Also by-design IGP/LDP Sync.

So no need to justify it by any magic new things, it's just a lot
simpler than LDP, you don't need to need new things to justify
SR-MPLS, you need to want to do existing things while reducing
complexity and state.

--
++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/

> From: NANOG <nanog-bounces@nanog.org> 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 can anyone
> point me toward a solution that actually does this in the way that it has been
> touted for years? A true flow that shows the implementation of "network
> programming" over any incarnation of SR? Perhaps one a customer can go to
> the shop and grab off the shelf?
>
Yes anything that works for RSVP-TE (i.e. PCEP), if you want to play there's this free app on top of ODL(acting as PCEP+BGP-LS) to program LSPs (can't recall the name).


> I've heard about "end-to-end service chaining" as a use-case for SR.
"service chaining" = traffic-engineering, you can do that with or without SR just fine.

> To
> service-chain what?
To service-chain DC or as hipsters call it "cloud" stuff. To TE path from VM to FW to ...whatever, or to TE mice flows around elephant flows.

> Classic telco's don't offer complex over-the-top services
They do via telco cloud.

> What problems are 90% of the
> operators running MPLS having that SR will truly fix,
>
None,
The same point I was trying to get across in our LDPv6 (or any v6 in control-plane or management plane for that matter) discussion, there's no problem to solve.
Personally I'll be doing SR only in brand new greenfield deployments or if I start running out of RSVP-TE scale on existing deployments.


adam

_______________________________________________
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 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 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.
* MPLS/VPN service signaling in IPv6-only networks also has gaps in SR.

So for networks that run OSPF and don't run Juniper, they'd need to move
to IS-IS in order to have SR forward IPv6 traffic in an MPLS
encapsulation. Seems like a bit of an ask. Yes, code needs to be
written, which is fine by me, as it also does for LDPv6.


> I would ask, why do we need LDP, why not use IGP to carry labels?
>
> Less state, protocols, SLOC, cost, bug surface

I'd be curious to understand what bugs you've suffered with LDP in the
last 10 or so years, that likely still have open tickets.

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 faster and cheaper.

I'm not saying that if you are dealing with 100,000 T-LDP sessions you
should not consider SR, but if you're not, and SR still requires a bit
more development (never mind deployment experience), what's wrong with
having LDPv6? If it makes near-as-no-difference to your control plane in
2020 or 2030 as to whether your 10,000-node network is running LDP or
SR, why not have the choice?


>
> And we get more features to boot, with LDP if you want LFA, you need
> to form tLDP to every Q-space node, on top of your normal LDP, because
> you don't know label view from anyone else but yourself. With SR by
> nature you know the label view for everyone, thus you have full LFA
> coverage for free, by-design.
> Also by-design IGP/LDP Sync.
>
> So no need to justify it by any magic new things, it's just a lot
> simpler than LDP, you don't need to need new things to justify
> SR-MPLS, you need to want to do existing things while reducing
> complexity and state.

Again, it's a question of scale and requirements. Some large networks
don't run any RSVP, while some small networks do.

I'm not saying let's not do SR; but for those who want something mature,
and for those who want something new, I don't see a reason why the
choice can't be left up to the operator.

Routers, in 2020, still ship with RIPv2. If anyone wants to use it (as I
am sure there are some that do), who are we to stand in their way, if it
makes sense for them?

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 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 the amount of work
needed to write code for it.


> Not just this, but the LFA path is always the post-convergence path.
> You don't get microloops.
>
> You can implement TE on top if that is your thing. No need to run
> RSVP. Another protocol you don't need to run.
>
> You don't need to throw out all your old kit, and replace with new in
> one go. You can incrementally roll it out, and leave islands of LDP
> where needed. LDP-SR interworking is pretty simple.
>
> We are currently introducing it into our core. It will probably be a
> while before we fully phase out LDP, but its definitely on the roadmap.

Happy to hear, and I have nothing against your choice if you are happy
with it.

But for a network that may not see the need in spending cycles doing
yet-another roll out, it tastes funny when you are forced down a new path.

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 17/Jun/20 23:07, adamv0025@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 play there's this free app on top of ODL(acting as PCEP+BGP-LS) to program LSPs (can't recall the name).

In short, more working and not the panacea it was made out to be. No
problem with that, if you're one to roll your sleeves up.


> "service chaining" = traffic-engineering, you can do that with or without SR just fine.

I don't make the terms up... best-of-breed and all that :-).


> To service-chain DC or as hipsters call it "cloud" stuff. To TE path from VM to FW to ...whatever, or to TE mice flows around elephant flows.

And how many classic telco's are doing this at scale in a way that only
SR can solve?


> They do via telco cloud.

What's that :-)?


> None,
> The same point I was trying to get across in our LDPv6 (or any v6 in control-plane or management plane for that matter) discussion, there's no problem to solve.
> Personally I'll be doing SR only in brand new greenfield deployments or if I start running out of RSVP-TE scale on existing deployments.

If I want to remove BGP state in the core (which is a good thing, given
how heavy BGP code and FIB requirements are), LDPv4 and LDPv6 are useful
for native dual-stack networks that do not share fate between either IP
protocol.

But, YMMV on that one :-).

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/

>
> 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
you need to match on IPv6 vs LDPv4 ingress where you match on IPv4 to map
it to correct label stack rewrite.

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
:)

Cheers,
R.
_______________________________________________
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 look at the basic SR via IGP extensions like VPLS vs. EVPN. If we had a way to go back in history I'm not sure anyone would have said VPLS was a good idea vs. EVPN.

There were reasons back in the day why something like SR wasn't done. The thought of global MPLS labels scared people and source routing was also evil. So LDP was created to distribute labels hop by hop, while still relying 100% on the IGP to do so. It kind of defies common sense when you look at it now, but there were supposedly good reasons for it back then.

SR-MPLS on an existing device supporting MPLS forwarding is a control-plane change, meaning almost any device could support SR-MPLS.

SR is meant to be data plane agnostic, the SID is just an identifier. Most support MPLS, some support IPv6.

Phil

?On 6/17/20, 1:15 PM, "cisco-nsp on behalf of Mark Tinka" <cisco-nsp-bounces@puck.nether.net on behalf of mark.tinka@seacom.mu> 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 2015.

All the talk about LDPv6 this and last week has had me reflecting a
great deal on where we are, as an industry, in why we are having to
think about SR and all its incarnations.

So, let me be the one that stirs up the hornets' nest...

Why do we really need SR? Be it SR-MPLS or SRv6 or SRv6+?





_______________________________________________
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 6/17/20, 6:31 PM, "cisco-nsp on behalf of Mark Tinka" <cisco-nsp-bounces@puck.nether.net on behalf of mark.tinka@seacom.mu> wrote:


On 17/Jun/20 23:07, adamv0025@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.

[pmb] There are things I can do with SR and a stack of globally significant labels I can't do with LDP or RSVP-TE. I don't know if I'm going to call them programmability though, that's a loaded marketing term.

Phil






_______________________________________________
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 01:17, Mark Tinka <mark.tinka@seacom.mu> 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 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 them except OSPFv3 and put all NRE
focus on there or move some of the NRE dollars to some other problems
we have, perhaps we would have room to support some different
non-djikstra IGP.

In a half sane world, IGP code, 90% of your code would be identical,
then you'd have adapter/ospfv2 adapter/ospfv3 adapter/isis which
translates internal struct to wire and wire to internal struct. So any
features you code, come for free to all of them. But no one is doing
this, it's 300% effort, and we all pay a premium for that.

In a quarter sane world we'd have some CIC, common-igp-container RFC
and then new features like SR would be specified as CIC-format,
instead of OSPFv2, OSPFv3, ISIS and BGP. Then each OSPFv2, OSPFv3,
ISIS and BGP would have CIC-to-x RFC. So people introducing new IGP
features do not need to write 4 drafts, one is enough.

I would include IPv4+IPv6 my-igp-of-choice SR in my RFP. Luckily ISIS
is supported on platforms I care about for IPV4+IPV6, so I'm already
there.

> MPLS/VPN service signaling in IPv6-only networks also has gaps in SR.

I don't understand this.


> So for networks that run OSPF and don't run Juniper, they'd need to move to IS-IS in order to have SR forward IPv6 traffic in an MPLS encapsulation. Seems like a bit of an ask. Yes, code needs to be written, which is fine by me, as it also does for LDPv6.

And it's really just adding TLV, if it already does IPv4 all the infra
should be in place, only thing missing is transporting the
information. Adding TLV to IGP is a lot less work than LDPv6.

> I'd be curious to understand what bugs you've suffered with LDP in the last 10 or so years, that likely still have open tickets.

3 within a year.
- PR1436119
- PR1428081
- PR1416032

I don't have IOS-XR LDP bugs within a year, but we had a bunch back
when going from 4 to 5. And none of these are cosmetic, these are
blackholing.

I'm not saying LDP is bad, it's just, of course more code lines you
exercise more bugs you see.

But yes, LDP has a lot of bug surface compared to SR, but in _your
network_ lot of that bug surface and complexity is amortised
complexity. So status quo bias is strong to keep running LDP, it is
simpler _NOW_ as a lot of the tax has been paid and moving to an
objectively simpler solution carries risk, as its complexity is not
amortised yet.


> 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 faster and cheaper.

I don't think it ever was relevant.

> I'm not saying that if you are dealing with 100,000 T-LDP sessions you should not consider SR, but if you're not, and SR still requires a bit more development (never mind deployment experience), what's wrong with having LDPv6? If it makes near-as-no-difference to your control plane in 2020 or 2030 as to whether your 10,000-node network is running LDP or SR, why not have the choice?

I can't add anything to the upside of going from LDP to SR that I've
not already said. You get more by spending less, it's win:win. Only
reason to stay in LDP is status quo bias which makes short term sense.

> Routers, in 2020, still ship with RIPv2. If anyone wants to use it (as I am sure there are some that do), who are we to stand in their way, if it makes sense for them?

RIP might make sense in some deployments, because it's essentially
stateless (routes age out, no real 'session') so if you have 100k VM
per router that you need to support and you want dynamic routing, RIP
might be the least resistance solution with the highest scale. Timing
wheels should help it scale and maintain great number of timers.

--
++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 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 worries :-).

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 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 thought of global MPLS labels scared people and source routing was also evil. So LDP was created to distribute labels hop by hop, while still relying 100% on the IGP to do so. It kind of defies common sense when you look at it now, but there were supposedly good reasons for it back then.
>
> SR-MPLS on an existing device supporting MPLS forwarding is a control-plane change, meaning almost any device could support SR-MPLS.
>
> SR is meant to be data plane agnostic, the SID is just an identifier. Most support MPLS, some support IPv6.

Fair enough.

There's still a whole IGP mess to sort out though, not to mention many
years of field experience to bake in.

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 18/Jun/20 02:47, Phil Bedard wrote:

>
> [pmb] There are things I can do with SR and a stack of globally significant labels I can't do with LDP or RSVP-TE. I don't know if I'm going to call them programmability though, that's a loaded marketing term.

Loaded marketing terms are meant to encourage you to reach for your
cheque book. We lose time in dealing with those associations when we
deny ourselves the chance to scrutinize what is real, and what's fluff.

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/

Hi,

On Thu, Jun 18, 2020 at 12:17:20AM +0200, Mark Tinka wrote:
> Routers, in 2020, still ship with RIPv2. If anyone wants to use it (as I
> am sure there are some that do), who are we to stand in their way, if it
> makes sense for them?

There's an argument for testability of the code base here...

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de

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 them except OSPFv3 and put all NRE
> focus on there or move some of the NRE dollars to some other problems
> we have, perhaps we would have room to support some different
> non-djikstra IGP.
>
> In a half sane world, IGP code, 90% of your code would be identical,
> then you'd have adapter/ospfv2 adapter/ospfv3 adapter/isis which
> translates internal struct to wire and wire to internal struct. So any
> features you code, come for free to all of them. But no one is doing
> this, it's 300% effort, and we all pay a premium for that.
>
> In a quarter sane world we'd have some CIC, common-igp-container RFC
> and then new features like SR would be specified as CIC-format,
> instead of OSPFv2, OSPFv3, ISIS and BGP. Then each OSPFv2, OSPFv3,
> ISIS and BGP would have CIC-to-x RFC. So people introducing new IGP
> features do not need to write 4 drafts, one is enough.

While I don't have a real opinion on how to fix the IGP mess, the point
is we sit with it now. Getting all these fixed is going to increase the
bug surface area for some time to come as both vendors and operators
work the kinks out, in addition to SR's own kinks.

Yes, it's all par for the course for new features, which is why I'd also
like to have an alternative that has been baked in for many years to
give me an option for stability, as we roll the new kid out.

I probably will deploy SR-MPLS at some point in my lifetime, but I'm not
feeling awfully comfortable to do so right now; and yet I do need MPLSv6
forwarding.


>
> I would include IPv4+IPv6 my-igp-of-choice SR in my RFP. Luckily ISIS
> is supported on platforms I care about for IPV4+IPV6, so I'm already
> there.

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.



> I don't understand this.

I mean the same gaps that exist in RFC 7439, for would-be IPv6-only MPLS
networks.



> And it's really just adding TLV, if it already does IPv4 all the infra
> should be in place, only thing missing is transporting the
> information. Adding TLV to IGP is a lot less work than LDPv6.

What we theorize as "should be easy" can turn out to be a whole
discussion with the vendors about it being months or years of work. Not
being inside their meeting rooms, I can't quite challenge how they
present the task.

Fundamentally, LDPv6 already has 5+ years in implementation (and LDPv4
is 20 years old), inter-op issues seem to be mostly fixed, and for what
we need it to do, it's working very well.

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, label
distribution state reduction is probably higher up on the agenda than
MPLSv6 forwarding. For me, I'd like the option to have both, and decide
whether my network is in a position to handle the additional state
required for LDPv6, if I feel that I'd prefer to deal with a protocol
that has had more exposure to the sun.

Ultimately, boxes with LDPv6 have been shipping for some time, and we
have a ton of them deployed and running for a while now. If it comes
down to kicking out the 20% that won't support it because of an
all-or-nothing vendor approach on a platform without full SR-MPLS
support for all IGP's, it is what it is.



> 3 within a year.
> - PR1436119
> - PR1428081
> - PR1416032
>
> I don't have IOS-XR LDP bugs within a year, but we had a bunch back
> when going from 4 to 5. And none of these are cosmetic, these are
> blackholing.
>
> I'm not saying LDP is bad, it's just, of course more code lines you
> exercise more bugs you see.
>
> But yes, LDP has a lot of bug surface compared to SR, but in _your
> network_ lot of that bug surface and complexity is amortised
> complexity. So status quo bias is strong to keep running LDP, it is
> simpler _NOW_ as a lot of the tax has been paid and moving to an
> objectively simpler solution carries risk, as its complexity is not
> amortised yet.

And FWIW, if some operators are willing to benefit from all the
experience that has gone into developing and maintaining LDP, while we
let SR settle down, I don't see why that choice shouldn't be there.

I'm not saying it should be an SR vs. LDP debate like it was
BGP-signaling vs. LDP-signaling for VPLS 12+ years ago. All I'm saying
is for those who want to go bleeding edge with SR, go for it. For those
who prefer to gracefully transition toward SR over time by settling on
LDP that has been in the field for a minute, go for it too.

I won't claim to know whether LDP or SR have a smaller or larger bug
surface area. What I do know is that there will be plenty of bugs for
SR, as there have been for MPLS and all related protocols in the last
20+ years. From my side, I'd prefer to give SR the time it needs to get
all of its Vitamin D, but don't oppose anyone that prefers to deploy it.


> I can't add anything to the upside of going from LDP to SR that I've
> not already said. You get more by spending less, it's win:win. Only
> reason to stay in LDP is status quo bias which makes short term sense.

I can't argue the usefulness of reducing label distribution state in
MPLS. Heck, that is what got me excited about SR back in 2013, and also
what caused me to pump the brakes on the noise I was making to vendors
about developing LDPv6 (which started in 2008), because I was finally
going to get native MPLSv6 forwarding in SR without all the LDP/RSVP
fluff. But, things took their own turn, and with the IGP mess that it
currently is, we are where we are. Thankfully, some vendors did develop
LDPv6 anyway, so we got MPLSv6 in the end as SR was still in the embryo.

If I'm still in the game in half-a-decade from now or so, I will very
likely dump LDP and move to SR-MPLS. I'm just not too comfortable doing
so now because IGP support is not where it needs to be, and it still has
to through its own life cycle of bugs and fixes, which will be quite an
effort as global deployment is still far behind LDP and RSVP.


> RIP might make sense in some deployments, because it's essentially
> stateless (routes age out, no real 'session') so if you have 100k VM
> per router that you need to support and you want dynamic routing, RIP
> might be the least resistance solution with the highest scale. Timing
> wheels should help it scale and maintain great number of timers.

I guess my point was the vendors won't be dumping RIP, even if general
conensus is to avoid it whenever possible.

If I'm not concerned about LDP state, and protocol stability is more
important to me in the near-to-medium term, we'd be remiss to start a
culture of taking that choice away.

Because the next time vendors get bored with what they've built and sold
and decide that SR or some other feature has seen enough light of day,
let's dream up something else to shout about between the 2030 -  2040
decade, they'll have the had the experience of cornering operators into
making rash decisions, and they'd never let us forget it.

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 18/Jun/20 08:34, Gert Doering wrote:

>
> There's an argument for testability of the code base here...

Which is absolutely my point.

Mark.

On Thu, 18 Jun 2020 at 10:13, Mark Tinka <mark.tinka@seacom.mu> 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. 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.

> I'm not saying it should be an SR vs. LDP debate like it was
> BGP-signaling vs. LDP-signaling for VPLS 12+ years ago. All I'm saying

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.

--
++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 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/

> From: Saku Ytti
> Sent: Thursday, June 18, 2020 6:26 AM
>
> On Thu, 18 Jun 2020 at 01:17, Mark Tinka <mark.tinka@seacom.mu> 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 faster and cheaper.
>
> I don't think it ever was relevant.
>
In 99% of cases, there are cases however where supporting 1M+ routes in IGP is one of the viable options to consider, or running multi-100k of LSPs through a core node...
But these are core MPLS networks that have no boundaries cause these literally wrap around the globe, and access to custom code.

adam

_______________________________________________
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/

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 super
area) while in IETF there is ongoing work to extend ISIS to 8 levels. There
is a lot of fundamental differences between those two (or three) IGPs and I
am sure many folks on the lists know them. Last there is a lot of
enterprise networks happily using IPv4 RFC1918 all over their global WAN
and DCs infrastructure and have no reason to deploy IPv6 there any time
soon.

If you are serious about converging to a single IGP I would rather consider
look towards OpenR type of IGP architecture with message bus underneath.

Thx,
R.

On Thu, Jun 18, 2020 at 7:26 AM Saku Ytti <saku@ytti.fi> wrote:

> On Thu, 18 Jun 2020 at 01:17, Mark Tinka <mark.tinka@seacom.mu> 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 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 them except OSPFv3 and put all NRE
> focus on there or move some of the NRE dollars to some other problems
> we have, perhaps we would have room to support some different
> non-djikstra IGP.
>
> In a half sane world, IGP code, 90% of your code would be identical,
> then you'd have adapter/ospfv2 adapter/ospfv3 adapter/isis which
> translates internal struct to wire and wire to internal struct. So any
> features you code, come for free to all of them. But no one is doing
> this, it's 300% effort, and we all pay a premium for that.
>
> In a quarter sane world we'd have some CIC, common-igp-container RFC
> and then new features like SR would be specified as CIC-format,
> instead of OSPFv2, OSPFv3, ISIS and BGP. Then each OSPFv2, OSPFv3,
> ISIS and BGP would have CIC-to-x RFC. So people introducing new IGP
> features do not need to write 4 drafts, one is enough.
>
> I would include IPv4+IPv6 my-igp-of-choice SR in my RFP. Luckily ISIS
> is supported on platforms I care about for IPV4+IPV6, so I'm already
> there.
>
> > MPLS/VPN service signaling in IPv6-only networks also has gaps in SR.
>
> I don't understand this.
>
>
> > So for networks that run OSPF and don't run Juniper, they'd need to move
> to IS-IS in order to have SR forward IPv6 traffic in an MPLS encapsulation.
> Seems like a bit of an ask. Yes, code needs to be written, which is fine by
> me, as it also does for LDPv6.
>
> And it's really just adding TLV, if it already does IPv4 all the infra
> should be in place, only thing missing is transporting the
> information. Adding TLV to IGP is a lot less work than LDPv6.
>
> > I'd be curious to understand what bugs you've suffered with LDP in the
> last 10 or so years, that likely still have open tickets.
>
> 3 within a year.
> - PR1436119
> - PR1428081
> - PR1416032
>
> I don't have IOS-XR LDP bugs within a year, but we had a bunch back
> when going from 4 to 5. And none of these are cosmetic, these are
> blackholing.
>
> I'm not saying LDP is bad, it's just, of course more code lines you
> exercise more bugs you see.
>
> But yes, LDP has a lot of bug surface compared to SR, but in _your
> network_ lot of that bug surface and complexity is amortised
> complexity. So status quo bias is strong to keep running LDP, it is
> simpler _NOW_ as a lot of the tax has been paid and moving to an
> objectively simpler solution carries risk, as its complexity is not
> amortised yet.
>
>
> > 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 faster and cheaper.
>
> I don't think it ever was relevant.
>
> > I'm not saying that if you are dealing with 100,000 T-LDP sessions you
> should not consider SR, but if you're not, and SR still requires a bit more
> development (never mind deployment experience), what's wrong with having
> LDPv6? If it makes near-as-no-difference to your control plane in 2020 or
> 2030 as to whether your 10,000-node network is running LDP or SR, why not
> have the choice?
>
> I can't add anything to the upside of going from LDP to SR that I've
> not already said. You get more by spending less, it's win:win. Only
> reason to stay in LDP is status quo bias which makes short term sense.
>
> > Routers, in 2020, still ship with RIPv2. If anyone wants to use it (as I
> am sure there are some that do), who are we to stand in their way, if it
> makes sense for them?
>
> RIP might make sense in some deployments, because it's essentially
> stateless (routes age out, no real 'session') so if you have 100k VM
> per router that you need to support and you want dynamic routing, RIP
> might be the least resistance solution with the highest scale. Timing
> wheels should help it scale and maintain great number of timers.
>
> --
> ++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 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 saying that OSPF houses that want IPv6 should just move to
IS-IS. Don't get me wrong, I support that very much as I think IS-IS is
a great IGP. That said, while it's good to convince OSPF operators to
consider IS-IS, it's not our place to force them to use it.

Also, OSPFv3-only for your dual-stack IGP needs is a supported
capability. Last time I tested it in Juniper in 2010/2011, it worked
well. I don't know if anyone is actually running IPv4 and IPv6 on OSPFv3
only, but it does work.


> Keep in mind that OSPF hierarchy is 2 (or 3 with super area) while in
> IETF there is ongoing work to extend ISIS to 8 levels. There is a lot
> of fundamental differences between those two (or three) IGPs and I am
> sure many folks on the lists know them.

15+ years ago, I'd have said that one protocol may have been suited to a
specific task than another due to the control plane limitations of the day.

In 2020, with the state-of-the-art of control planes today, it near as
makes no difference, IMHO.


> Last there is a lot of enterprise networks happily using IPv4 RFC1918
> all over their global WAN and DCs infrastructure and have no reason to
> deploy IPv6 there any time soon.

No wonder the vendors aren't seeing any LDPv6, SR-ISISv6 or SR-OSPFv3
demand :-).

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 13:28, Robert Raszuk <robert@raszuk.net> 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. Keep in mind that OSPF hierarchy is 2 (or 3 with super area) while in IETF there is ongoing work to extend ISIS to 8 levels. There is a lot of fundamental differences between those two (or three) IGPs and I am sure many folks on the lists know them. Last there is a lot of enterprise networks happily using IPv4 RFC1918 all over their global WAN and DCs infrastructure and have no reason to deploy IPv6 there any
time soon.

I view the 802.3 and CLNS as liability, not an asset. People who
actually route CLNS are a dying breed, think just DCN of a legacy
optical.

Many platforms have no facilities to protect ISIS, any connected
attacker can kill the box. Nokia handles generated packets
classification by assigning DSCP value to application then DSCP to
forwarding-class, which precludes from configuring ISIS qos. Very few
people understand how ISIS works before ISIS PDU is handed to them,
world from 802.3 to that is largely huge pile of hacks, instead of
complete CLNS stack implementation. There is no standard way to send
large frames over 802.3, so there is non-standard way to encap ISIS
for those links. Also due to lack of LSP roll-over, ISIS is subject to
a horrible attack vector which is very difficult to troubleshoot and
solve.

--
++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/

> From: NANOG <nanog-bounces@nanog.org> 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, label
> distribution state reduction is probably higher up on the agenda than
> MPLSv6 forwarding. For me, I'd like the option to have both, and decide
> whether my network is in a position to handle the additional state required
> for LDPv6, if I feel that I'd prefer to deal with a protocol that has had more
> exposure to the sun.
>
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 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 be, which is understandable considering the scope of ground to be covered. Yes you're right in acknowledging that we're not living in a perfect world and that choices are limited, but it's been like that since ever yet we managed to thrive by analysing our options and striving for optimal strategies year by year.

adam

_______________________________________________
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 13:23, adamv0025@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 still manage the
tangible and intangible costs of doing so. But that's for another
discussion.


> 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 be, which is understandable considering the scope of ground to be covered.

Which I am fine with  - if you give me a time line to say LDPv6,
SR-OSPFv3 and SR-ISISv6 will be available on X date, I can manage my
operation and expectations accordingly.

But if you say, "No LDPv6, no SR-OSPFv3, no SR-ISISv6... only SRv6",
then that's an entirely different issue.

The good news is there currently is choice on the matter, but upending
hundreds or thousands of boxes to prove that point should really be a
last resort, as there are more pressing things we all have to deal with.


> Yes you're right in acknowledging that we're not living in a perfect world and that choices are limited, but it's been like that since ever yet we managed to thrive by analysing our options and striving for optimal strategies year by year.

We can thank NAT44, CIDR, DHCP and PPPoE for that strategy over the
years :-).

IPv6 is the future, and at some point, we'll have to stop hiding from it.

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/

> From: Mark Tinka <mark.tinka@seacom.mu>
> Sent: Thursday, June 18, 2020 12:51 PM
>
> On 18/Jun/20 13:23, adamv0025@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 be, which is understandable considering the scope of ground to be
> covered.
>
> Which I am fine with - if you give me a time line to say LDPv6,
> SR-OSPFv3 and SR-ISISv6 will be available on X date, I can manage my
> operation and expectations accordingly.
>
> But if you say, "No LDPv6, no SR-OSPFv3, no SR-ISISv6... only SRv6", then
> that's an entirely different issue.
>
> The good news is there currently is choice on the matter, but upending
> hundreds or thousands of boxes to prove that point should really be a last
> resort, as there are more pressing things we all have to deal with.
>
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).

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.

>
> > Yes you're right in acknowledging that we're not living in a perfect world
> and that choices are limited, but it's been like that since ever yet we
> managed to thrive by analysing our options and striving for optimal strategies
> year by year.
>
> We can thank NAT44, CIDR, DHCP and PPPoE for that strategy over the years
> :-).
>
> IPv6 is the future, and at some point, we'll have to stop hiding from it.
>
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).

adam

_______________________________________________
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 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/

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.
_______________________________________________
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, Jun 19, 2020 at 9:05 AM 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...
>
> Mark.
>
>
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.

Silicon One looks like an interesting strategy: single ASIC for fixed,
modular, fabric. Replace multiple internal and external ASIC family,
compete with merchant, whitebox, MSDC etc.

The Cisco 8000/8200 is not branded as NCS, which is BCM. I asked the
NCS5/55k guys why they didn't use UADP. No good answer, although I suspect
some big customer(s) were demanding BCM for their own programming needs.
Maybe there were some memory bandwidth issues with UADP, which is what Q100
HBM is the answer for.

--
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 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 position in some respects, because
when BU's are presenting one company as 6,000 ones, it's difficult for
buying consistency.

Options are great, but when options have options, it starts to get ugly,
quick.

Ah well...


>
> Silicon One looks like an interesting strategy: single ASIC for fixed,
> modular, fabric. Replace multiple internal and external ASIC family,
> compete with merchant, whitebox, MSDC etc.

That is the hope. We've been to the cinema for this one before, though.
Quite a few times. So I'm not holding my breath.


>
> The Cisco 8000/8200 is not branded as NCS, which is BCM.

Not all of it - remember the big pink elephant in the room, the NCS
6000? That is/was nPower. Again, sending customers in all sorts of
directions with that box, where now ASR9000 and the new 8000 seem to be
the go-to box. Someone can't make up their mind over there.


> I asked the NCS5/55k guys why they didn't use UADP. No good answer,
> although I suspect some big customer(s) were demanding BCM for their
> own programming needs. Maybe there were some memory bandwidth issues
> with UADP, which is what Q100 HBM is the answer for.

When you're building boxes for one or two customers, things like this
tend to happen.

But like I've been saying for some time, the big brands competing with
the small brands over merchant silicon doesn't make sense. If you want
merchant silicon to reduce cost, you're better off playing with the new
brands that will charge less and be more flexible. While I do like IOS
XR and Junos, paying a premium for them for a chip that will struggle
the same way across all vendor implementations just doesn't track.

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, Jun 19, 2020 at 10:34 AM Mark Tinka <mark.tinka@seacom.mu> 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, features, licensing model etc.
>
> All this forking weakens a vendor's position in some respects, because
> when BU's are presenting one company as 6,000 ones, it's difficult for
> buying consistency.
>
> Options are great, but when options have options, it starts to get ugly,
> quick.
>
> Ah well...
>
>
> >
> > Silicon One looks like an interesting strategy: single ASIC for fixed,
> > modular, fabric. Replace multiple internal and external ASIC family,
> > compete with merchant, whitebox, MSDC etc.
>
> That is the hope. We've been to the cinema for this one before, though.
> Quite a few times. So I'm not holding my breath.
>
>
> >
> > The Cisco 8000/8200 is not branded as NCS, which is BCM.
>
> Not all of it - remember the big pink elephant in the room, the NCS
> 6000? That is/was nPower. Again, sending customers in all sorts of
> directions with that box, where now ASR9000 and the new 8000 seem to be
> the go-to box. Someone can't make up their mind over there.
>
>
> > I asked the NCS5/55k guys why they didn't use UADP. No good answer,
> > although I suspect some big customer(s) were demanding BCM for their
> > own programming needs. Maybe there were some memory bandwidth issues
> > with UADP, which is what Q100 HBM is the answer for.
>
> When you're building boxes for one or two customers, things like this
> tend to happen.
>
> But like I've been saying for some time, the big brands competing with
> the small brands over merchant silicon doesn't make sense. If you want
> merchant silicon to reduce cost, you're better off playing with the new
> brands that will charge less and be more flexible. While I do like IOS
> XR and Junos, paying a premium for them for a chip that will struggle
> the same way across all vendor implementations just doesn't track.
>
> Mark.
>
>
Yes, for sure NCS6K was a completely different beast, much as NCS1K, NCS2K.
Not sure why the NCS naming was adopted vs. ASR, and then dropped for
8000/8200. Probably lots of battles within the Cisco conglomerate.

Not defending, just observing. Either way, networks got to get built,
debugged, maintained, debugged, upgraded, debugged. All while improving
performance, managing CAPEX, reducing OPEX.

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

Hi,

On Fri, Jun 19, 2020 at 03:05:50PM +0200, Mark Tinka wrote:
> On 19/Jun/20 14:50, Tim Durack wrote:
>
> > If y'all can deal with the BU, the Cat9k family is looking
> > half-decent: MPLS PE/P, BGP L3VPN, BGP EVPN (VXLAN dataplane not MPLS)
> > etc.
> > UADP programmable pipeline ASIC, FIB ~200k, E-LLW, mandatory DNA
> > license now covers software support...
[..]
>
> I'd like to hear what Gert thinks, though. I'm sure he has a special
> place for the word "Catalyst" :-).

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 days that I haven't really looked at
all these new and shiny products from all these new and shiny BUs with
all these new and shiny operating systems in quite a while.

I've been told Merak is very nice... if all you're interested in is
"sell to Enterprise customers and make lots of cash".

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de

>
> 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 to traverse
through. Rest is the shortest path between those hops.

Then even if you place those node SIDs you have no control which interfaces
are chosen as outbound. There is often more then one IGP ECMP path in
between. You would need to insert adj. SIDs which does require pretty fine
level of controller's capabilities to start with.

I just hope that no one sane proposes that now all packets should get
encapsulated in a new IPv6 header while entering a transit ISP network and
carry long list of hop by hop adjacencies it is to travel by. Besides even
if it would it would be valid only within given ASN and had no visibility
outside.

Thx,
R.
_______________________________________________
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've been told Merak is very nice... if all you're interested in is "sell
to
> Enterprise customers and make lots of cash".

We asked the sales-person weather that meraki devices can handle ipv6
(as customer traffic) and for the cloudy management access (in an ipv4 free
world)
But they did not know this, told us they will ask, but we did not get any
answer yet ...

Juergen.


_______________________________________________
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 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 days that I haven't really looked at
> all these new and shiny products from all these new and shiny BUs with
> all these new and shiny operating systems in quite a while.

We bought the C6880-X for our core switch back in 2014. It's still
humming, running plain old IOS.

The upgrade path is Arista for this. I'm not sure what switching is
doing over at Cisco, these days.

Mark.

On 19/Jun/20 20:19, ljwobker@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 them.
> - one of them will want to terminate high speed L2VPN circuits, even though it's a "core" box.
> - one of them will need to do hierarchical shaping and granular QoS, even though it's a "core" box.
> - one of them will want to have lots of headroom in the FIB (2-3x today's global tables) ... even though it's a "core" box.
> - one of them will want to buy something that they can "migrate out to the edge" one day...
>
> Say it with me: "even though it's a "core" box"
>
> This puts me (as the vendor) in a super weird spot... I can try to create a card/PID that addresses *some subset* of this, charge a lot less for it, and hopefully sell a bunch. Or I'm left creating something that I can sell into that broader market, but then that thing has to "do all the stuff" and I'm going to charge for it appropriately.
>
> The physics dictate that "Really High Speed Silicon" does not exist which can solve all of those things. I can solve SOME with a given chip design, but not all.

Well, if I'm honest, it's the vendors who created "tiers" back in the
day, so they can sell boxes in the way they did, and still do.

Ever since Ethernet became the gold standard, what a core, edge,
peering, branch, e.t.c., box is has been meaningless. It was meaningless
before Ethernet (I mean, to some, the Cisco 3640 was a core router,
while to others it was a peering router), but it's more meaningless in
the days of Ethernet.

The reason the ASR9000 sells better than the CRS or NCS 6000, is the
same reason the MX sells better than the PTX or T-series. It's all about
Ethernet.

So now, vendors who are able to build boxes that can license Ethernet
ports will be the winners, because I don't have to pay the upfront capex
for the entire card, and can just grow as I need. The Transport boys
have been doing it for so long, why can't the IP boys do the same? The
good news is, they have started.

Secondly, and perhaps more importantly, if vendors can build around a
single ASIC across a multitude of platforms, then there is hope. If you
have to build a different ASIC for every tier of a network, you end up
with the issues you raise, above. The reason the MX does so well is
because in addition to being an Ethernet platform, it uses the same ASIC
(since Trio, to be clear), which gives Juniper and its customers plenty
of flexibility across a variety of applications.

There is a lesson, here, 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/

Hi,

On Sat, Jun 20, 2020 at 07:42:31PM +0200, Mark Tinka wrote:
> On 19/Jun/20 17:26, Gert Doering wrote:
>
> We bought the C6880-X for our core switch back in 2014. It's still
> humming, running plain old IOS.

The 6880/6840 products were promising at that time, but the pricing made
it uninteresting. So we kept our 6506Es for a time...

> The upgrade path is Arista for this. I'm not sure what switching is
> doing over at Cisco, these days.

... and then went to Arista 7050SX2/SX3 for the "edge things" (small
routing table, lots of 10G/25G ports, small power draw, EVPN/VXLAN).

Nice stuff like the JSON RPC API, which is nice to work with and
amazingly *fast* (compared to JunOS commit times...). And, most important,
a good TAC and a company interested in listening to their customers.


I'm a bit annoyed that the 7050SX* do not have MPLS-P support (because
we have MPLS PEs that basically "live behind" the 7050SX, and now need
to have vlans *through* them, to reach a MPLS P router).

I do understand that the BRCM Trident is fairly limited wrt MPLS handling,
so Arista decided "better no MPLS than something which is not enough
for people" - unfortunately for us, because we only want "LDP and
single-label swap/pop", but I can accept the technical arguments to
some extent.


(As a side note, changing our network from EIGRP to OSPF for IPv4 did
not come for free, so I would have much preferred to stay in my self-
chosen vendor lock-in with Cisco. But Cisco has gone insane these days,
and new boxes like the NCS5500 come *without* EIGRP support. So they
really do not want us customers locked in...)

gert

--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de

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, and when it's time for them
to go, the Arista kicks.


> ... and then went to Arista 7050SX2/SX3 for the "edge things" (small
> routing table, lots of 10G/25G ports, small power draw, EVPN/VXLAN).
>
> Nice stuff like the JSON RPC API, which is nice to work with and
> amazingly *fast* (compared to JunOS commit times...). And, most important,
> a good TAC and a company interested in listening to their customers.

We run the 7508E for core switching in large PoP's, and the 7280R for
data centre access aggregation in all PoP's (this replaced our Juniper
EX4550 and EX4600 platforms).

We are very happy - but these are pure Layer 2 switching use-cases.


> I'm a bit annoyed that the 7050SX* do not have MPLS-P support (because
> we have MPLS PEs that basically "live behind" the 7050SX, and now need
> to have vlans *through* them, to reach a MPLS P router).
>
> I do understand that the BRCM Trident is fairly limited wrt MPLS handling,
> so Arista decided "better no MPLS than something which is not enough
> for people" - unfortunately for us, because we only want "LDP and
> single-label swap/pop", but I can accept the technical arguments to
> some extent.

You know how I feel about Broadcom chips :-).

If Arista aren't that comfortable about them, you'd do well to take them
at their word, hehe.


> (As a side note, changing our network from EIGRP to OSPF for IPv4 did
> not come for free, so I would have much preferred to stay in my self-
> chosen vendor lock-in with Cisco. But Cisco has gone insane these days,
> and new boxes like the NCS5500 come *without* EIGRP support. So they
> really do not want us customers locked in...)

Looking at things, it's probably cheaper for you to spend money on
getting an open IGP than spending money dealing with the indecision
Cisco sometimes goes through.

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, or how possible it would be to
implement, especially for inter-domain traffic.

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 20/Jun/20 08:49, Reuben Farrelly via cisco-nsp wrote:

> Meraki doesn't currently support IPv6 in any way, shape or form.
>
> Some other things you'll find missing in Meraki products:
>
> - Zone based firewalls - Meraki MX doesn't do zones
> - Routing protocols for all but the most absolutely basic use cases
> - Client side VPN.  More specifically it does PPTP but not so many
> people are sold on the security and NAT problems that come with PPTP
> - Modern crypto - IPSec Auth is limited to MD5/SHA1 for example.
> - Any sort of xDSL, they only have Ethernet models.  If you need xDSL
> you'll need a bridge modem for the carriage circuit
> - Extremely limited NAT capabilities, no ALG, no ability to disable
> NAT between eg WAN and LAN ports which means it's almost useless for
> an MPLS circuit.  The lack of control over NAT also makes it
> impossible to run a publically addressable DMZ
> - SSL decryption which makes content filtering a bit less useful
> - Cellular is limited to not all 4G bands (notably does not support
> 700MHz here in Australia) and Cell backup is not supported in an HA setup
>
> And dare I say it, Segment Routing and MPLS definitely are not part of
> the featureset ;)
>
> There are many good things about Meraki (eg dashboard, autovpn,
> updates, ease of provisioning), but in my recent experience with MX/MS
> products you have to spend as much if not more time working out what
> Meraki products *can not* do as what they *can* do - and know the
> product limitations before you design and deploy not during (don't
> assume anything).
>
> Personally I would only recommend Meraki for a small business with
> very basic and well defined requirements.  Even then once you factor
> in the cost of licensing + hardware and compare it to a low end Cisco
> Enterprise product that does not have said limitations, you may find
> the cost is about the same over 3 or more years.

Sounds like pfSense might be a better option :-).

If I can summarize it in one sentence, is Meraki meant to be Cisco's
SD-WAN job?

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 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 datacenters where there were at least
> 10 or more layers of up to 16 way ECMP between them. Having a record of which
> path is being taken by a packet is very helpful to determine the one with a crappy
> transceiver.
>
> That work is already underway, albeit not specifically for MPLS. For example,
> I've worked with an experimental version of In-Band Network Telemetry (INT)
> as described in this draft: https://tools.ietf.org/html/draft-kumar-ippm-ifa-02
>
> I even demonstrated a very basic implementatoin during SuperCompute 19 in Denver
> last year. Most people who were interested in the demo were academics however,
> probably because it wasn't a real networking event.
>
> Note that there are several caveats that come with this draft and previous
> versions, and that it is still very much work in progress. But the potential is
> huge, at least in the DC.

Alright, we'll wait and see, then.



> That's a different story, but not entirely impossible. A probe packet can
> be sent across AS borders, and as long as the two NOCs are cooperating, the
> entire path can be reconstructed.

Yes, for once-off troubleshooting, I suppose that would work.

My concern is if it's for normal day-to-day operations. But who knows,
maybe someone will propose that too :-).

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/