Mailing List Archive

I've had an ACX5448 in my lab on loaner for over a year. I need to refresh
myself on how well it performed. I have the little-brother ACX5048,
probably 50 of them all over my network doing quite well. Pretty sure those
are not Trio based.

Never heard of the ACX710, but see it in slide 22 here ...
https://senetsy.ru/upload/juniper-summit-2019/5G-ready_Transport_Networks_Ev
genii_Bugakov_Juniper.pdf
ACX710 and ACX753. I'm curious about interfaces and modules and
capabilities of both of them.

-Aaron


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

The 5448 and the 5048 are quite different. I have several 5048 in my plant
and when we questioned Juniper about a replacement with 100G interfaces
their engineers compared the config template from our 5048s and said the
5448 wasn't capable of doing some of the RSVP and RPM stuff we were doing
on the 5048. This was about 6 months ago.

Luis

On Tue, Jan 21, 2020 at 4:45 PM Aaron Gould <aaron1@gvtc.com> wrote:

> I've had an ACX5448 in my lab on loaner for over a year. I need to refresh
> myself on how well it performed. I have the little-brother ACX5048,
> probably 50 of them all over my network doing quite well. Pretty sure
> those
> are not Trio based.
>
> Never heard of the ACX710, but see it in slide 22 here ...
>
> https://senetsy.ru/upload/juniper-summit-2019/5G-ready_Transport_Networks_Ev
> genii_Bugakov_Juniper.pdf
> <https://senetsy.ru/upload/juniper-summit-2019/5G-ready_Transport_Networks_Evgenii_Bugakov_Juniper.pdf>
> ACX710 and ACX753. I'm curious about interfaces and modules and
> capabilities of both of them.
>
> -Aaron
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Hello

We did some initial lab teste using 5448 for a client and we have checked with JUNIPER.

The major problems we found for our client environment:

- No support for FAT (no roadmap);
- No support for Entropy Label (no roadmap);
- No support for Output Policer or HQOS for VPLS / L2Circuit (no roadmap);
- ACX does not support load balance parsing the payload on lag interface (no roadmap);
- Some problems with arp flooding for the main CPU (initial JUNOS releases but I think they have solve it);
- IRB on VPLS is not supported;
- Not possible to monitor the real-time traffic on sub-interfaces using CLI (only with SNMP)

It is good to check with them to see if those functions would work ate some new releases (some day ...).

Att,

Giuliano

-----Original Message-----
From: juniper-nsp <juniper-nsp-bounces@puck.nether.net> On Behalf Of Luis Balbinot
Sent: terça-feira, 21 de janeiro de 2020 16:59
To: Aaron Gould <aaron1@gvtc.com>
Cc: jnsp list <juniper-nsp@puck.nether.net>
Subject: Re: [j-nsp] ACX5448 & ACX710

The 5448 and the 5048 are quite different. I have several 5048 in my plant and when we questioned Juniper about a replacement with 100G interfaces their engineers compared the config template from our 5048s and said the
5448 wasn't capable of doing some of the RSVP and RPM stuff we were doing on the 5048. This was about 6 months ago.

Luis

On Tue, Jan 21, 2020 at 4:45 PM Aaron Gould <aaron1@gvtc.com> wrote:

> I've had an ACX5448 in my lab on loaner for over a year. I need to
> refresh myself on how well it performed. I have the little-brother
> ACX5048, probably 50 of them all over my network doing quite well.
> Pretty sure those are not Trio based.
>
> Never heard of the ACX710, but see it in slide 22 here ...
>
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsene
> tsy.ru%2Fupload%2Fjuniper-summit-2019%2F5G-ready_Transport_Networks_Ev
> &amp;data=02%7C01%7Cgiuliano%40wztech.com.br%7Cf47f0378dce54349a9d208d
> 79eac77dd%7C584787b077bd4312bf8815412b8ae504%7C1%7C1%7C637152335925921
> 914&amp;sdata=O6x7rQJ2OdQeVpdjsWEeWW%2BbUfvLWShaDrb0itRc%2FRk%3D&amp;r
> eserved=0
> genii_Bugakov_Juniper.pdf
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsen
> etsy.ru%2Fupload%2Fjuniper-summit-2019%2F5G-ready_Transport_Networks_E
> vgenii_Bugakov_Juniper.pdf&amp;data=02%7C01%7Cgiuliano%40wztech.com.br
> %7Cf47f0378dce54349a9d208d79eac77dd%7C584787b077bd4312bf8815412b8ae504
> %7C1%7C1%7C637152335925921914&amp;sdata=kaF077Ymm7a4T4QDuI6Y2R8KRZnyuc
> s0lDGH838NJ%2F0%3D&amp;reserved=0>
> ACX710 and ACX753. I'm curious about interfaces and modules and
> capabilities of both of them.
>
> -Aaron
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck
> .nether.net%2Fmailman%2Flistinfo%2Fjuniper-nsp&amp;data=02%7C01%7Cgiul
> iano%40wztech.com.br%7Cf47f0378dce54349a9d208d79eac77dd%7C584787b077bd
> 4312bf8815412b8ae504%7C1%7C1%7C637152335925921914&amp;sdata=bQ7iLaxJOi
> Gj730LNO2u4gH64TpYWJMYC5exorh69bI%3D&amp;reserved=0
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fjuniper-nsp&amp;data=02%7C01%7Cgiuliano%40wztech.com.br%7Cf47f0378dce54349a9d208d79eac77dd%7C584787b077bd4312bf8815412b8ae504%7C1%7C1%7C637152335925921914&amp;sdata=bQ7iLaxJOiGj730LNO2u4gH64TpYWJMYC5exorh69bI%3D&amp;reserved=0

WZTECH is registered trademark of WZTECH NETWORKS.
Copyright © 2018 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos eventuais documentos anexos são confidenciais e para conhecimento exclusivo do destinatário. Se o leitor desta mensagem não for o seu destinatário, fica desde já notificado de que não poderá divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das informações e do conteúdo dos documentos anexos. Neste caso, favor comunicar imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida apague-o.

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any review, transmission, dissemination or other use of this information is prohibited. If you have received this communication in error, please notify the sender immediately and delete the material from any computer, including any copies.

WZTECH is registered trademark of WZTECH NETWORKS.
Copyright © 2018 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos eventuais documentos anexos são confidenciais e para conhecimento exclusivo do destinatário. Se o leitor desta mensagem não for o seu destinatário, fica desde já notificado de que não poderá divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das informações e do conteúdo dos documentos anexos. Neste caso, favor comunicar imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida apague-o.

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any review, transmission, dissemination or other use of this information is prohibited. If you have received this communication in error, please notify the sender immediately and delete the material from any computer, including any copies.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Tue, 21 Jan 2020 at 22:24, Giuliano C. Medalha
<giuliano@wztech.com.br> wrote:

> - No support for FAT (no roadmap);
> - No support for Entropy Label (no roadmap);
> - No support for Output Policer or HQOS for VPLS / L2Circuit (no roadmap);
> - ACX does not support load balance parsing the payload on lag interface (no roadmap);
> - Some problems with arp flooding for the main CPU (initial JUNOS releases but I think they have solve it);
> - IRB on VPLS is not supported;
> - Not possible to monitor the real-time traffic on sub-interfaces using CLI (only with SNMP)

When were you communicated these? They differ significantly from what
was communicated to me.

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Hello

Good morning

We did the tests last year in our lab

The roadmap position for some features must be changed from there.

It is a good think ... to check again with juniper sales rep ... to have a better view about these features and new roadmaps and new dates

We are going to ask for an update again because all these features are so important to us.

Thanks



Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Saku Ytti <saku@ytti.fi>
Sent: Wednesday, January 22, 2020 3:26:38 AM
To: Giuliano C. Medalha <giuliano@wztech.com.br>
Cc: jnsp list <juniper-nsp@puck.nether.net>
Subject: Re: [j-nsp] ACX5448 & ACX710

On Tue, 21 Jan 2020 at 22:24, Giuliano C. Medalha
<giuliano@wztech.com.br> wrote:

> - No support for FAT (no roadmap);
> - No support for Entropy Label (no roadmap);
> - No support for Output Policer or HQOS for VPLS / L2Circuit (no roadmap);
> - ACX does not support load balance parsing the payload on lag interface (no roadmap);
> - Some problems with arp flooding for the main CPU (initial JUNOS releases but I think they have solve it);
> - IRB on VPLS is not supported;
> - Not possible to monitor the real-time traffic on sub-interfaces using CLI (only with SNMP)

When were you communicated these? They differ significantly from what
was communicated to me.

--
++ytti

WZTECH is registered trademark of WZTECH NETWORKS.
Copyright ? 2018 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informa??es deste e-mail e o conte?do dos eventuais documentos anexos s?o confidenciais e para conhecimento exclusivo do destinat?rio. Se o leitor desta mensagem n?o for o seu destinat?rio, fica desde j? notificado de que n?o poder? divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das informa??es e do conte?do dos documentos anexos. Neste caso, favor comunicar imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida apague-o.

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any review, transmission, dissemination or other use of this information is prohibited. If you have received this communication in error, please notify the sender immediately and delete the material from any computer, including any copies.

WZTECH is registered trademark of WZTECH NETWORKS.
Copyright ? 2018 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informa??es deste e-mail e o conte?do dos eventuais documentos anexos s?o confidenciais e para conhecimento exclusivo do destinat?rio. Se o leitor desta mensagem n?o for o seu destinat?rio, fica desde j? notificado de que n?o poder? divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das informa??es e do conte?do dos documentos anexos. Neste caso, favor comunicar imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida apague-o.

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any review, transmission, dissemination or other use of this information is prohibited. If you have received this communication in error, please notify the sender immediately and delete the material from any computer, including any copies.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 21/Jan/20 21:44, Aaron Gould wrote:
> I've had an ACX5448 in my lab on loaner for over a year. I need to refresh
> myself on how well it performed. I have the little-brother ACX5048,
> probably 50 of them all over my network doing quite well. Pretty sure those
> are not Trio based.

If memory serves, the ACX5048 is based on the Trident II. So it should
be markedly different from the ACX5448, which is Jericho 2-based.


> Never heard of the ACX710, but see it in slide 22 here ...
> https://senetsy.ru/upload/juniper-summit-2019/5G-ready_Transport_Networks_Ev
> genii_Bugakov_Juniper.pdf
> ACX710 and ACX753. I'm curious about interfaces and modules and
> capabilities of both of them.

Let me see if I can remember this - the ACX710 should be 24x 1/10Gbps
ports + 2x 100Gbps uplinks (could be double that).

The ACX753 is chassis-based, and built for hardened requirements in the
Metro and RAN.

Both are shipping middle of 2020.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 21/Jan/20 21:58, Luis Balbinot wrote:

> The 5448 and the 5048 are quite different. I have several 5048 in my
> plant and when we questioned Juniper about a replacement with 100G
> interfaces their engineers compared the config template from our 5048s
> and said the 5448 wasn't capable of doing some of the RSVP and RPM
> stuff we were doing on the 5048. This was about 6 months ago.

We are not an RSVP house, but these are things I'd like to know.

Thanks for the feedback.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 22/Jan/20 08:26, Saku Ytti wrote:

>
> When were you communicated these? They differ significantly from what
> was communicated to me.

Saku, would you mind sharing what issues you know about these (and others)?

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 22/Jan/20 10:03, Giuliano C. Medalha wrote:

> Hello
>
> Good morning
>
> We did the tests last year in our lab
>
> The roadmap position for some features must be changed from there.
>
> It is a good think ... to check again with juniper sales rep ... to have a better view about these features and new roadmaps and new dates
>
> We are going to ask for an update again because all these features are so important to us.

Would be most grateful if you can let us know when you hear back from
Juniper on these, Giuliano. Thanks.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Wed, 22 Jan 2020 at 10:06, Mark Tinka <mark.tinka@seacom.mu> wrote:

> > When were you communicated these? They differ significantly from what
> > was communicated to me.
>
> Saku, would you mind sharing what issues you know about these (and others)?

I've not tested nor paid much attention, but the information I have is
that FAT is roadmapped, unsure of the other stuff as much of it is not
relevant to me.

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Thanks a lot

Forgot to put the following on the list:

TE / TE++ and auto-bandwidth

We will ask them the roadmap for these features too.



Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: juniper-nsp <juniper-nsp-bounces@puck.nether.net> on behalf of Saku Ytti <saku@ytti.fi>
Sent: Wednesday, January 22, 2020 5:49:50 AM
To: Mark Tinka <mark.tinka@seacom.mu>
Cc: Juniper List <juniper-nsp@puck.nether.net>
Subject: Re: [j-nsp] ACX5448 & ACX710

On Wed, 22 Jan 2020 at 10:06, Mark Tinka <mark.tinka@seacom.mu> wrote:

> > When were you communicated these? They differ significantly from what
> > was communicated to me.
>
> Saku, would you mind sharing what issues you know about these (and others)?

I've not tested nor paid much attention, but the information I have is
that FAT is roadmapped, unsure of the other stuff as much of it is not
relevant to me.

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fjuniper-nsp&amp;data=02%7C01%7Cgiuliano%40wztech.com.br%7C4e373f01744e438c535208d79f1835b6%7C584787b077bd4312bf8815412b8ae504%7C1%7C0%7C637152798679559514&amp;sdata=KyXYR5LrmaEQJ30ILxsvV2wftgd3dG2%2F1I%2Fo1qRZOvc%3D&amp;reserved=0

WZTECH is registered trademark of WZTECH NETWORKS.
Copyright ? 2018 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informa??es deste e-mail e o conte?do dos eventuais documentos anexos s?o confidenciais e para conhecimento exclusivo do destinat?rio. Se o leitor desta mensagem n?o for o seu destinat?rio, fica desde j? notificado de que n?o poder? divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das informa??es e do conte?do dos documentos anexos. Neste caso, favor comunicar imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida apague-o.

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any review, transmission, dissemination or other use of this information is prohibited. If you have received this communication in error, please notify the sender immediately and delete the material from any computer, including any copies.

WZTECH is registered trademark of WZTECH NETWORKS.
Copyright ? 2018 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informa??es deste e-mail e o conte?do dos eventuais documentos anexos s?o confidenciais e para conhecimento exclusivo do destinat?rio. Se o leitor desta mensagem n?o for o seu destinat?rio, fica desde j? notificado de que n?o poder? divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das informa??es e do conte?do dos documentos anexos. Neste caso, favor comunicar imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida apague-o.

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any review, transmission, dissemination or other use of this information is prohibited. If you have received this communication in error, please notify the sender immediately and delete the material from any computer, including any copies.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Wed, 22 Jan 2020, Giuliano C. Medalha wrote:

> TE / TE++ and auto-bandwidth

Still broken? Been hearing excuses about why these don't work on merchant
silicon boxes since the EX3200...

-Rob


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Wed, 22 Jan 2020 at 11:48, Rob Foehl <rwf@loonybin.net> wrote:

> TE / TE++ and auto-bandwidth
>
> Still broken? Been hearing excuses about why these don't work on merchant
> silicon boxes since the EX3200...

Excuses seems strong word, it implies you know what merchant silicon
EX3200 has and it implies you know it can push two and swap, which it
can't.

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

> Giuliano C. Medalha
> Sent: Tuesday, January 21, 2020 8:24 PM
>
> Hello
>
> We did some initial lab teste using 5448 for a client and we have checked with
> JUNIPER.
>
> The major problems we found for our client environment:
>
> - No support for FAT (no roadmap);
> - No support for Entropy Label (no roadmap);
> - No support for Output Policer or HQOS for VPLS / L2Circuit (no roadmap);
> - ACX does not support load balance parsing the payload on lag interface (no
> roadmap);
> - Some problems with arp flooding for the main CPU (initial JUNOS releases
> but I think they have solve it);
> - IRB on VPLS is not supported;
> - Not possible to monitor the real-time traffic on sub-interfaces using CLI
> (only with SNMP)
>
> It is good to check with them to see if those functions would work ate some
> new releases (some day ...).
>
And no " TE / TE++ and auto-bandwidth"?

-seems like ACX5448 is targeted as a CPE box or a L2 switch,

...unsubscribe....

adam


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Wed, 22 Jan 2020 at 16:01, <adamv0025@netconsultings.com> wrote:

> And no " TE / TE++ and auto-bandwidth"?
>
> -seems like ACX5448 is targeted as a CPE box or a L2 switch,

It's metro box but appetite for more. There is no reason why it
wouldn't do TE/autoBW, if you wave bags of money at JNPR, you'll get
it.

> ...unsubscribe....

Remember how it took >5years to get EoMPLS on ASR1k? 19.4 was RLS2 for
ACX5448. What is right way to release boxes

- release with the features the customer who buys them wanted
- release after you have feature parity


--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

CPE with its datasheet not even mentioning IPSec/DTLS hardware support ...
LOL what year do we have ?

On Wed, Jan 22, 2020 at 3:01 PM <adamv0025@netconsultings.com> wrote:

> > Giuliano C. Medalha
> > Sent: Tuesday, January 21, 2020 8:24 PM
> >
> > Hello
> >
> > We did some initial lab teste using 5448 for a client and we have
> checked with
> > JUNIPER.
> >
> > The major problems we found for our client environment:
> >
> > - No support for FAT (no roadmap);
> > - No support for Entropy Label (no roadmap);
> > - No support for Output Policer or HQOS for VPLS / L2Circuit (no
> roadmap);
> > - ACX does not support load balance parsing the payload on lag interface
> (no
> > roadmap);
> > - Some problems with arp flooding for the main CPU (initial JUNOS
> releases
> > but I think they have solve it);
> > - IRB on VPLS is not supported;
> > - Not possible to monitor the real-time traffic on sub-interfaces using
> CLI
> > (only with SNMP)
> >
> > It is good to check with them to see if those functions would work ate
> some
> > new releases (some day ...).
> >
> And no " TE / TE++ and auto-bandwidth"?
>
> -seems like ACX5448 is targeted as a CPE box or a L2 switch,
>
> ...unsubscribe....
>
> adam
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Wed, 22 Jan 2020 at 16:09, Robert Raszuk <robert@raszuk.net> wrote:

> CPE with its datasheet not even mentioning IPSec/DTLS hardware support ...
> LOL what year do we have ?

It is not CPE, it's metrobox. Jericho doesn't do IPsec in year 2020.

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 22/Jan/20 16:01, adamv0025@netconsultings.com wrote:

> And no " TE / TE++ and auto-bandwidth"?
>
> -seems like ACX5448 is targeted as a CPE box or a L2 switch,

According to Juniper, it's targeted as an IP/MPLS router for the Metro
and similar applications.

It is meant to compete with Cisco's ASR920 and NCS540 boxes, as Juniper
have no plans to develop a lite version of the MX204.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 1/22/20, 10:08 AM, "juniper-nsp on behalf of Mark Tinka" <juniper-nsp-bounces@puck.nether.net on behalf of mark.tinka@seacom.mu> wrote:
According to Juniper, it's targeted as an IP/MPLS router for the Metro
and similar applications.

It is meant to compete with Cisco's ASR920 and NCS540 boxes, as Juniper
have no plans to develop a lite version of the MX204.

Which is something many of us smaller providers have been begging them for YEARS to make. Hopefully it doesn't have restrictions on port configurations like the MX204 or weird filtering limitations like the original ACX boxes. The ASR920 is popular for a reason - they are rock-solid, offered decent port configurations, sensible and reasonably priced licensing, small form-factor and features decent enough for an access MPLS device.

Trying to get more info from my SE, but likely will not be able to share it due to NDA, as it's not yet a released product.

-evt

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 22/Jan/20 17:17, Eric Van Tol wrote:

>
> Which is something many of us smaller providers have been begging them for YEARS to make. Hopefully it doesn't have restrictions on port configurations like the MX204 or weird filtering limitations like the original ACX boxes. The ASR920 is popular for a reason - they are rock-solid, offered decent port configurations, sensible and reasonably priced licensing, small form-factor and features decent enough for an access MPLS device.

And, custom silicon that does, pretty much, what you're used to seeing
on IOS XE boxes.

Juniper, I've realized, are really not interested in the Metro-E space.
I know it's great to think merchant silicon is the answer to get into
that space, but it doesn't look to me like they will be bother the
ASR920 anytime soon.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Mark and gents.

Juniper really doesn't care about Metro services, since ACX5048, "The Promissed" equipment that was ready to solve our problems regarding port density and functions, but... ACX5048 doesn't work as expected as Giuliano said(Giuliano is my SE), We brought some ACX5048... in less than a month of operation, we remove those box from network, they became a layer2 switch only. So Juniper release the new ACX, but the problems still the same.

From my perspective, they don't have time to develop a good software and they just release anything for us thinking that someday, they will correct the software of the new hardwar, and we will be happy, but they just forget that we provide services and we have SLA. I have my personal cents about this subject...

MX, maybe, is the most stable hardware/software that they had in this moment. But there is no good density of ports, or we had to choose what type of ports we had to work on with, I can't accept this, a MPC7E-MRATE working with only 4 100Gb ports... (aahhh this is because de backplane bla bla bla bla....) hardware release with bad development to run against market... to not lose the market.

Other problem that I have here, is with QFX5100 platform, using a functionality(version 14.1X53-D35.3), that they remove at the newest release software, and, they(Juniper) don't had solution for that and, they really don't care....

Now I have a big problem in large scale, since I have hundreds of QFX5100, can't upgrade due that, and JTAC don't support that old release anymore.

And, I don't want to talk about QFX5120.... deception...


This is my cent, and my feelings about.


Att
Alexandre


?Em 22/01/2020 12:41, "juniper-nsp em nome de Mark Tinka" <juniper-nsp-bounces@puck.nether.net em nome de mark.tinka@seacom.mu> escreveu:



On 22/Jan/20 17:17, Eric Van Tol wrote:

>
> Which is something many of us smaller providers have been begging them for YEARS to make. Hopefully it doesn't have restrictions on port configurations like the MX204 or weird filtering limitations like the original ACX boxes. The ASR920 is popular for a reason - they are rock-solid, offered decent port configurations, sensible and reasonably priced licensing, small form-factor and features decent enough for an access MPLS device.

And, custom silicon that does, pretty much, what you're used to seeing
on IOS XE boxes.

Juniper, I've realized, are really not interested in the Metro-E space.
I know it's great to think merchant silicon is the answer to get into
that space, but it doesn't look to me like they will be bother the
ASR920 anytime soon.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s&m=TU6hC3CmliVPupj04_YNYHTF5VVsspISdyOjUEnr2TM&s=r-fSdwLUay6e6rXEc7nibhLO1FNxOw1U62KPIFpFeF4&e=


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Wed, 22 Jan 2020, Saku Ytti wrote:

> On Wed, 22 Jan 2020 at 11:48, Rob Foehl <rwf@loonybin.net> wrote:
>
>>> TE / TE++ and auto-bandwidth
>>
>> Still broken? Been hearing excuses about why these don't work on merchant
>> silicon boxes since the EX3200...
>
> Excuses seems strong word, it implies you know what merchant silicon
> EX3200 has and it implies you know it can push two and swap, which it
> can't.

autobw never worked on EX3200 and similar vintage because they'd
periodically dump impossible values into the statistics files and then try
to do reservations near integer-width limits. Who implied anything about
needing more than one label?

-Rob


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Hi,

On Wed, Jan 22, 2020 at 05:41:19PM +0200, Mark Tinka wrote:
> but it doesn't look to me like they will be bother the ASR920 anytime soon.

If you do more than "basic packet switching" the ASR920 is so
amazingly buggy... so having an alternative in this space for
"basic IP/IPv6/MPLS routing for little money" would be certainly
welcome.

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 22/Jan/20 18:48, Gert Doering wrote:

>
> If you do more than "basic packet switching" the ASR920 is so
> amazingly buggy... so having an alternative in this space for
> "basic IP/IPv6/MPLS routing for little money" would be certainly
> welcome.

This is what I've been saying since 2009.

Cisco had the ME3600X/3800X, and the only real competitor at the time
was the Brocade CES/CER2000 NetIron.

Juniper missed the mark.

Fast forward to 2020, Cisco have the ASR920 and there is no real
competitor from any vendor that can challenge them, really.

Again, Juniper missed the mark.

One thing Juniper have been certain about telling me - they do not plan
to create a MX204-Lite.

Not. Going. To. Happen.

For them, their Metro-E solution is the ACX - and judging from past
performance, my level of faith is very low. When a vendor tells me that,
"Well, the new Broadcom chip is miles better than the old Broadcom
chip", I get the feeling that in 2030, they will still be using that
very same line.

If Cisco can develop a custom chip for the ASR920 that can be sold for a
decent price and still do the work in the field, Juniper's refusal, to
me, is rooted in their bedrock internal principles... the same ones that
made them famous for, "A single Junos for all our boxes". We know how
well that turned out.

Mark.

We too have the ACX5048 and QFX5100's, and have been unhappy with them
both. They both have the same Trident II chip set, but run different code
which is annoying to say the least. Not to mention these aren't really
built for Metro-E deployments. They are not hardened, so datacenter only.
Plus, the don't support 23 inch racks nor 2 post racks. Makes them hard to
put in a customers site.

I looked at the ASR920 just now, it has too few 10G ports on it. The NCS
540 seems to be more ideal for our needs. Does the NCS 540 fit the bill?

On Wed, Jan 22, 2020 at 10:05 AM Alexandre Guimaraes <
alexandre.guimaraes@ascenty.com> wrote:

> Mark and gents.
>
> Juniper really doesn't care about Metro services, since ACX5048,
> "The Promissed" equipment that was ready to solve our problems regarding
> port density and functions, but... ACX5048 doesn't work as expected as
> Giuliano said(Giuliano is my SE), We brought some ACX5048... in less than a
> month of operation, we remove those box from network, they became a layer2
> switch only. So Juniper release the new ACX, but the problems still the
> same.
>
> From my perspective, they don't have time to develop a good
> software and they just release anything for us thinking that someday, they
> will correct the software of the new hardwar, and we will be happy, but
> they just forget that we provide services and we have SLA. I have my
> personal cents about this subject...
>
> MX, maybe, is the most stable hardware/software that they had in
> this moment. But there is no good density of ports, or we had to choose
> what type of ports we had to work on with, I can't accept this, a
> MPC7E-MRATE working with only 4 100Gb ports... (aahhh this is because de
> backplane bla bla bla bla....) hardware release with bad development to run
> against market... to not lose the market.
>
> Other problem that I have here, is with QFX5100 platform, using a
> functionality(version 14.1X53-D35.3), that they remove at the newest
> release software, and, they(Juniper) don't had solution for that and, they
> really don't care....
>
> Now I have a big problem in large scale, since I have hundreds of
> QFX5100, can't upgrade due that, and JTAC don't support that old release
> anymore.
>
> And, I don't want to talk about QFX5120.... deception...
>
>
> This is my cent, and my feelings about.
>
>
> Att
> Alexandre
>
>
> ?Em 22/01/2020 12:41, "juniper-nsp em nome de Mark Tinka" <
> juniper-nsp-bounces@puck.nether.net em nome de mark.tinka@seacom.mu>
> escreveu:
>
>
>
> On 22/Jan/20 17:17, Eric Van Tol wrote:
>
> >
> > Which is something many of us smaller providers have been begging
> them for YEARS to make. Hopefully it doesn't have restrictions on port
> configurations like the MX204 or weird filtering limitations like the
> original ACX boxes. The ASR920 is popular for a reason - they are
> rock-solid, offered decent port configurations, sensible and reasonably
> priced licensing, small form-factor and features decent enough for an
> access MPLS device.
>
> And, custom silicon that does, pretty much, what you're used to seeing
> on IOS XE boxes.
>
> Juniper, I've realized, are really not interested in the Metro-E space.
> I know it's great to think merchant silicon is the answer to get into
> that space, but it doesn't look to me like they will be bother the
> ASR920 anytime soon.
>
> Mark.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s&m=TU6hC3CmliVPupj04_YNYHTF5VVsspISdyOjUEnr2TM&s=r-fSdwLUay6e6rXEc7nibhLO1FNxOw1U62KPIFpFeF4&e=
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

We have a very small deployment of ASR920 running 16.12. Work well for us,
and we do some pretty kinky/exotic stuff: small scale BNG, Internet in VRF,
selective FIB, port-based DHCPv4/v6/PD, IP unnumbered, IPoDWDM...

If you can stomach the BU wars, UADP is a nice ASIC - I think the Cat9k has
legs, but the Enterprise BU is definitely in a parallel universe. I asked
about porting XR to run on UADP. That didn't really go over well.

I am wary of NCS due to the merchant silicon and general uncertainty - why
announce the Cisco 8000 with no family loyalty? Looks like a replacement to
me.

Tim:>

On Wed, Jan 22, 2020 at 1:18 PM Colton Conor <colton.conor@gmail.com> wrote:

> We too have the ACX5048 and QFX5100's, and have been unhappy with them
> both. They both have the same Trident II chip set, but run different code
> which is annoying to say the least. Not to mention these aren't really
> built for Metro-E deployments. They are not hardened, so datacenter only.
> Plus, the don't support 23 inch racks nor 2 post racks. Makes them hard to
> put in a customers site.
>
> I looked at the ASR920 just now, it has too few 10G ports on it. The NCS
> 540 seems to be more ideal for our needs. Does the NCS 540 fit the bill?
>
> On Wed, Jan 22, 2020 at 10:05 AM Alexandre Guimaraes <
> alexandre.guimaraes@ascenty.com> wrote:
>
> > Mark and gents.
> >
> > Juniper really doesn't care about Metro services, since ACX5048,
> > "The Promissed" equipment that was ready to solve our problems regarding
> > port density and functions, but... ACX5048 doesn't work as expected as
> > Giuliano said(Giuliano is my SE), We brought some ACX5048... in less
> than a
> > month of operation, we remove those box from network, they became a
> layer2
> > switch only. So Juniper release the new ACX, but the problems still the
> > same.
> >
> > From my perspective, they don't have time to develop a good
> > software and they just release anything for us thinking that someday,
> they
> > will correct the software of the new hardwar, and we will be happy, but
> > they just forget that we provide services and we have SLA. I have my
> > personal cents about this subject...
> >
> > MX, maybe, is the most stable hardware/software that they had in
> > this moment. But there is no good density of ports, or we had to choose
> > what type of ports we had to work on with, I can't accept this, a
> > MPC7E-MRATE working with only 4 100Gb ports... (aahhh this is because de
> > backplane bla bla bla bla....) hardware release with bad development to
> run
> > against market... to not lose the market.
> >
> > Other problem that I have here, is with QFX5100 platform, using a
> > functionality(version 14.1X53-D35.3), that they remove at the newest
> > release software, and, they(Juniper) don't had solution for that and,
> they
> > really don't care....
> >
> > Now I have a big problem in large scale, since I have hundreds of
> > QFX5100, can't upgrade due that, and JTAC don't support that old release
> > anymore.
> >
> > And, I don't want to talk about QFX5120.... deception...
> >
> >
> > This is my cent, and my feelings about.
> >
> >
> > Att
> > Alexandre
> >
> >
> > ?Em 22/01/2020 12:41, "juniper-nsp em nome de Mark Tinka" <
> > juniper-nsp-bounces@puck.nether.net em nome de mark.tinka@seacom.mu>
> > escreveu:
> >
> >
> >
> > On 22/Jan/20 17:17, Eric Van Tol wrote:
> >
> > >
> > > Which is something many of us smaller providers have been begging
> > them for YEARS to make. Hopefully it doesn't have restrictions on port
> > configurations like the MX204 or weird filtering limitations like the
> > original ACX boxes. The ASR920 is popular for a reason - they are
> > rock-solid, offered decent port configurations, sensible and reasonably
> > priced licensing, small form-factor and features decent enough for an
> > access MPLS device.
> >
> > And, custom silicon that does, pretty much, what you're used to
> seeing
> > on IOS XE boxes.
> >
> > Juniper, I've realized, are really not interested in the Metro-E
> space.
> > I know it's great to think merchant silicon is the answer to get into
> > that space, but it doesn't look to me like they will be bother the
> > ASR920 anytime soon.
> >
> > Mark.
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s&m=TU6hC3CmliVPupj04_YNYHTF5VVsspISdyOjUEnr2TM&s=r-fSdwLUay6e6rXEc7nibhLO1FNxOw1U62KPIFpFeF4&e=
> >
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


--
Tim:>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 22/Jan/20 20:39, Tim Durack wrote:

> If you can stomach the BU wars, UADP is a nice ASIC - I think the Cat9k has
> legs, but the Enterprise BU is definitely in a parallel universe. I asked
> about porting XR to run on UADP. That didn't really go over well.

Personally, I think IOS XR is too heavy for the Metro.


> I am wary of NCS due to the merchant silicon and general uncertainty - why
> announce the Cisco 8000 with no family loyalty? Looks like a replacement to
> me.

Just like the PTX, Cisco will target-sell the NCS6000 to specific large
carriers, predominantly in the U.S. Those will be specific deals behind
closed doors. They will continue to build the box in small numbers for
those customers, but they'll rely on the "edge" routers for the majority
of their business, just like Juniper do with the MX.

So the Cisco 8000 is their attempt, I feel, to lure customers that need
something larger than an MX or ASR9000 in the core or dense edge, but
are not large enough to justify the PTX or NCS6000. I could be wrong,
but that's my 1+1.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Wed, 22 Jan 2020 at 20:46, Mark Tinka <mark.tinka@seacom.mu> wrote:

> Personally, I think IOS XR is too heavy for the Metro.

The new Cisco 8000 series ships with new, thinner variant of IOS-XR
(it is not same IOS-XR 7 that ASR9k will run). Potentially this
thinner IOS-XR could find home in Catalyst and ISR. As a customer, I'm
not sure if that is what I want. I think I may actually just want
monolithic IOS-XEd with _proper_ commit and BGP-API (so I can
implement policy language in language of my choice)

> So the Cisco 8000 is their attempt, I feel, to lure customers that need
> something larger than an MX or ASR9000 in the core or dense edge, but
> are not large enough to justify the PTX or NCS6000. I could be wrong,
> but that's my 1+1.

I suspect long term they intend to replace ASR9k with 8k series. But
GSR is still sold, by the time 8k is replaced, there probably still
are few ASR9k customers, so overlap will be thing for long long time.


--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 23/Jan/20 08:38, Saku Ytti wrote:

>
> The new Cisco 8000 series ships with new, thinner variant of IOS-XR
> (it is not same IOS-XR 7 that ASR9k will run). Potentially this
> thinner IOS-XR could find home in Catalyst and ISR. As a customer, I'm
> not sure if that is what I want. I think I may actually just want
> monolithic IOS-XEd with _proper_ commit and BGP-API (so I can
> implement policy language in language of my choice)

I'm with you on this.


> I suspect long term they intend to replace ASR9k with 8k series. But
> GSR is still sold, by the time 8k is replaced, there probably still
> are few ASR9k customers, so overlap will be thing for long long time.

It does make sense to converge a lot of IP/MPLS functionality around a
single box that is versatile enough to support it. Juniper have had wild
success with the MX since 2007, and you see it doing a lot of things in
many areas of the network to a point of making all their other (larger)
platforms almost irrelevant.

If Cisco feel converging a lot of stuff into the 8000 makes sense, I'd
say they should do it. I'm not sure the market still wants too many
boxes doing too many things in an era where operators are struggling to
keep equipment spending at levels where they were 10, 15, 20 years ago.

This is one of the reasons operators with enough in-house coding skill
are seriously looking to build (or already building) their own routers
with DPDK on white boxes + friends, even if those solutions may be
proprietary and used in targeted deployments, e.g., distributed
low-scale edge, e.t.c. Vendors need to wake up and realize they can't be
the only ones not willing to feel the impact of an age where the kids
don't want to pay for data.

Mark.

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 23/Jan/20 08:38, Saku Ytti wrote:

> The new Cisco 8000 series ships with new, thinner variant of IOS-XR
> (it is not same IOS-XR 7 that ASR9k will run). Potentially this
> thinner IOS-XR could find home in Catalyst and ISR. As a customer, I'm
> not sure if that is what I want. I think I may actually just want
> monolithic IOS-XEd with _proper_ commit and BGP-API (so I can
> implement policy language in language of my choice)

I'm with you on this.


> I suspect long term they intend to replace ASR9k with 8k series. But
> GSR is still sold, by the time 8k is replaced, there probably still
> are few ASR9k customers, so overlap will be thing for long long time.

It does make sense to converge a lot of IP/MPLS functionality around a
single box that is versatile enough to support it. Juniper have had wild
success with the MX since 2007, and you see it doing a lot of things in
many areas of the network to a point of making all their other (larger)
platforms almost irrelevant.

If Cisco feel converging a lot of stuff into the 8000 makes sense, I'd
say they should do it. I'm not sure the market still wants too many
boxes doing too many things in an era where operators are struggling to
keep equipment spending at levels where they were 10, 15, 20 years ago.

This is one of the reasons operators with enough in-house coding skill
are seriously looking to build (or already building) their own routers
with DPDK on white boxes + friends, even if those solutions may be
proprietary and used in targeted deployments, e.g., distributed
low-scale edge, e.t.c. Vendors need to wake up and realize they can't be
the only ones not willing to feel the impact of an age where the kids
don't want to pay for data.

Mark.


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

> Mark Tinka
> Sent: Thursday, January 23, 2020 7:01 AM
>
> This is one of the reasons operators with enough in-house coding skill are
> seriously looking to build (or already building) their own routers with
DPDK
> on white boxes + friends, even if those solutions may be proprietary and
> used in targeted deployments, e.g., distributed low-scale edge, e.t.c.
> Vendors need to wake up and realize they can't be the only ones not
willing
> to feel the impact of an age where the kids don't want to pay for data.
>
I think they are getting the message, nowadays you can run your custom
in-house built routing protocols in their SW or run their NOS on a custom
box, or skip the Control-Plane altogether while programming the FIBs
directly.

adam

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

> Mark Tinka
> Sent: Wednesday, January 22, 2020 6:46 PM
>
> On 22/Jan/20 20:39, Tim Durack wrote:
>
> > If you can stomach the BU wars, UADP is a nice ASIC - I think the
> > Cat9k has legs, but the Enterprise BU is definitely in a parallel
> > universe. I asked about porting XR to run on UADP. That didn't really go
> over well.
>
> Personally, I think IOS XR is too heavy for the Metro.
>
But it's gonna be your only choice if you want to do any sensible automation
(or Junos).

adam

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 23/Jan/20 10:55, adamv0025@netconsultings.com wrote:

> But it's gonna be your only choice if you want to do any sensible automation
> (or Junos).

Over the past 10 years of hearing about all the buzz words, it's very
safe to say that "automation" is whatever it means to you :-).

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

I had that conversation the again other day - someone said they were
working on "automation" and when I probed deeper it revealed some (very
useful, albeit not scalable) scripting. 'You keep using that word. I do not
think it means what you think it means' seems to be the gist of most
"automation" conversations, and I'm guilty often as not - 'automate it'
seems to be a catch all for most of our operations issues.

- Thomas Scott | mr.thomas.scott@gmail.com <mr.thomas.scott@gmail.com>


On Thu, Jan 23, 2020 at 4:21 AM Mark Tinka <mark.tinka@seacom.mu> wrote:

>
>
> On 23/Jan/20 10:55, adamv0025@netconsultings.com wrote:
>
> > But it's gonna be your only choice if you want to do any sensible
> automation
> > (or Junos).
>
> Over the past 10 years of hearing about all the buzz words, it's very
> safe to say that "automation" is whatever it means to you :-).
>
> Mark.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

I have been following the ACX 710 for a while now. We have a use case in
rural markets where we need a dense 10G hardened 1 RU box.

Looks like a promising box, hope the price is right. If not we may have to
jump to Cisco ASR920s

4 100/40G (can be channelized to 4x25G or 4x10G) interfaces, 24 1/10G
interfaces. Broadcom QAX chipset. 320Gbps of throughput. 3GB buffer.

On Tue, Jan 21, 2020 at 11:38 AM Mark Tinka <mark.tinka@seacom.mu> wrote:

> Hi all.
>
> My Juniper SE is pressuring me to test the ACX boxes per subject.
>
> These are shipping with Jericoh 2c and Qumran 2c chip sets.
>
> For anyone that has deployed these, are you happy, particularly if you
> have previous Trio experience?
>
> As some of you know, I generally shy away from merchant silicon,
> especially from traditional equipment vendors such as Juniper and Cisco.
>
> All feedback is much appreciated. Thanks.
>
> Mark.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 23/Jan/20 16:00, Shamen Snyder wrote:

> I have been following the ACX 710 for a while now. We have a use case
> in rural markets where we need a dense 10G hardened 1 RU box.
>
> Looks like a promising box, hope the price is right. If not we may
> have to jump to Cisco ASR920s

If I'm honest, what I've noticed with most traditional vendors selling
Broadcom-based boxes is they are touting "price" as the killer use-case
for those boxes. For me, I'm not unwilling to spend a little bit more if
I can sleep at night knowing I have data plane parity between a
Broadcom-based box and an in-house-based box from the same traditional
vendor.

But time and time again, almost like clockwork, Broadcom-based boxes are
being marketed as "Multi-Gigabit" and "Multi-Terabit" platforms with a
gazillion ports at half the price of the "normal" box. What good is all
that hardware if a simple feature doesn't work as I've known it to
before "enhancing my network"?


>
> 4 100/40G (can be channelized to 4x25G or 4x10G) interfaces, 24 1/10G
> interfaces. Broadcom QAX chipset. 320Gbps of throughput. 3GB buffer.

What I saw about the ACX710 is it has a small FIB. Since we are used to
filtering what enters our ASR920 FIB (and the ACX710 has about 12.8
times that), that's not a show-stopper.

Mark.

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

What is Cisco's upgrade path from the ASR920 if you need more 10G ports?

On Thu, Jan 23, 2020 at 2:52 PM Mark Tinka <mark.tinka@seacom.mu> wrote:

>
>
> On 23/Jan/20 16:00, Shamen Snyder wrote:
>
> > I have been following the ACX 710 for a while now. We have a use case
> > in rural markets where we need a dense 10G hardened 1 RU box.
> >
> > Looks like a promising box, hope the price is right. If not we may
> > have to jump to Cisco ASR920s
>
> If I'm honest, what I've noticed with most traditional vendors selling
> Broadcom-based boxes is they are touting "price" as the killer use-case
> for those boxes. For me, I'm not unwilling to spend a little bit more if
> I can sleep at night knowing I have data plane parity between a
> Broadcom-based box and an in-house-based box from the same traditional
> vendor.
>
> But time and time again, almost like clockwork, Broadcom-based boxes are
> being marketed as "Multi-Gigabit" and "Multi-Terabit" platforms with a
> gazillion ports at half the price of the "normal" box. What good is all
> that hardware if a simple feature doesn't work as I've known it to
> before "enhancing my network"?
>
>
> >
> > 4 100/40G (can be channelized to 4x25G or 4x10G) interfaces, 24 1/10G
> > interfaces. Broadcom QAX chipset. 320Gbps of throughput. 3GB buffer.
>
> What I saw about the ACX710 is it has a small FIB. Since we are used to
> filtering what enters our ASR920 FIB (and the ACX710 has about 12.8
> times that), that's not a show-stopper.
>
> Mark.
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

That would be something like the NCS540.
Its not an apples-to-apples comparison — as the 540 runs XR and the usual things that come with that. There were some threads about it in [c-nsp] — might be something to explore. I feel its a bit heavyweight for the metro, but it gives you environmentally hardened 10GE with a variety of options for uplink.

q.

—
Quinn Snyder | snyderq@gmail.com

-= Sent via iPad. Please excuse grammar, spelling, and brevity =-

> On Jan 23, 2020, at 14:03, Colton Conor <colton.conor@gmail.com> wrote:
>
> ?What is Cisco's upgrade path from the ASR920 if you need more 10G ports?
>
>> On Thu, Jan 23, 2020 at 2:52 PM Mark Tinka <mark.tinka@seacom.mu> wrote:
>>
>>
>>
>>> On 23/Jan/20 16:00, Shamen Snyder wrote:
>>>
>>> I have been following the ACX 710 for a while now. We have a use case
>>> in rural markets where we need a dense 10G hardened 1 RU box.
>>>
>>> Looks like a promising box, hope the price is right. If not we may
>>> have to jump to Cisco ASR920s
>>
>> If I'm honest, what I've noticed with most traditional vendors selling
>> Broadcom-based boxes is they are touting "price" as the killer use-case
>> for those boxes. For me, I'm not unwilling to spend a little bit more if
>> I can sleep at night knowing I have data plane parity between a
>> Broadcom-based box and an in-house-based box from the same traditional
>> vendor.
>>
>> But time and time again, almost like clockwork, Broadcom-based boxes are
>> being marketed as "Multi-Gigabit" and "Multi-Terabit" platforms with a
>> gazillion ports at half the price of the "normal" box. What good is all
>> that hardware if a simple feature doesn't work as I've known it to
>> before "enhancing my network"?
>>
>>
>>>
>>> 4 100/40G (can be channelized to 4x25G or 4x10G) interfaces, 24 1/10G
>>> interfaces. Broadcom QAX chipset. 320Gbps of throughput. 3GB buffer.
>>
>> What I saw about the ACX710 is it has a small FIB. Since we are used to
>> filtering what enters our ASR920 FIB (and the ACX710 has about 12.8
>> times that), that's not a show-stopper.
>>
>> Mark.
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

> From: Mark Tinka <mark.tinka@seacom.mu>
> Sent: Thursday, January 23, 2020 9:21 AM
>
> On 23/Jan/20 10:55, adamv0025@netconsultings.com wrote:
>
> > But it's gonna be your only choice if you want to do any sensible
> > automation (or Junos).
>
> Over the past 10 years of hearing about all the buzz words, it's very safe to
> say that "automation" is whatever it means to you :-).
>
Hahaha fair enough :)

adam

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 23/Jan/20 23:02, Colton Conor wrote:
> What is Cisco's upgrade path from the ASR920 if you need more 10G ports?

NCS540, which for me, is a broken path.

We are pushing for other considerations, but I'm not holding my breath.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 23/Jan/20 23:17, quinn snyder wrote:
> That would be something like the NCS540.
> Its not an apples-to-apples comparison — as the 540 runs XR and the usual things that come with that. There were some threads about it in [c-nsp] — might be something to explore. I feel its a bit heavyweight for the metro, but it gives you environmentally hardened 10GE with a variety of options for uplink.

Comes with Broadcom too, so definitely not apples-to-apples.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Thu, 23 Jan 2020 at 22:52, Mark Tinka <mark.tinka@seacom.mu> wrote:

> If I'm honest, what I've noticed with most traditional vendors selling
> Broadcom-based boxes is they are touting "price" as the killer use-case

When we asked JNPR why Jericho instead of Paradise, as we see these
chips for the same market, JNPR told that main motivation was OAM
features which they lack in Paradise but need in metro.

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 24/Jan/20 08:49, Saku Ytti wrote:

>
> When we asked JNPR why Jericho instead of Paradise, as we see these
> chips for the same market, JNPR told that main motivation was OAM
> features which they lack in Paradise but need in metro.

The OAM story came up as well, as being the major improvements from
Trident to Jericho.

If I'm honest, given that everything has gone IP + Cloud, the demand for
VPN's - as we've known them - is no longer there, really. Well, at least
in our market anyway. At which point we introduce the fresh buzzword for
2020 - "SD-WAN". Oooh, but don't forget, we now have "SD-LAN" and
"SD-WLAN". Just keeps getting better and better.

In short, we don't really have a huge OAM demand simply because our
customers just want simple IP. They just want to get to their Instagram.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Mark,

So which box is best to just get customers a simple IP, but has all the
management and metro-e requirements you need?



On Fri, Jan 24, 2020 at 1:53 AM Mark Tinka <mark.tinka@seacom.mu> wrote:

>
>
> On 24/Jan/20 08:49, Saku Ytti wrote:
>
> >
> > When we asked JNPR why Jericho instead of Paradise, as we see these
> > chips for the same market, JNPR told that main motivation was OAM
> > features which they lack in Paradise but need in metro.
>
> The OAM story came up as well, as being the major improvements from
> Trident to Jericho.
>
> If I'm honest, given that everything has gone IP + Cloud, the demand for
> VPN's - as we've known them - is no longer there, really. Well, at least
> in our market anyway. At which point we introduce the fresh buzzword for
> 2020 - "SD-WAN". Oooh, but don't forget, we now have "SD-LAN" and
> "SD-WLAN". Just keeps getting better and better.
>
> In short, we don't really have a huge OAM demand simply because our
> customers just want simple IP. They just want to get to their Instagram.
>
> Mark.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 24/Jan/20 19:24, Colton Conor wrote:

> Mark,
>
> So which box is best to just get customers a simple IP, but has all
> the management and metro-e requirements you need?

Well, anything sold for a Metro-E application nowadays, whether it
supports MPLS or not, will always have some kind of OAM capability. This
is just vendors building what the industry asked for years ago, and
thinks the industry still needs today.

For us, 98% of the customers on our Metro-E network are simple IP
customers, i.e., DIA or IP Transit. They don't care about OAM. They just
want a connection they can use to access their cloud services.

Of the remaining 2% who buy only EoMPLS services, 0.5% of those ask
about OAM.

To put it another way - if vendors could build boxes and price them
cheaper because they had little or no OAM features (either by design or
via licenses), I'd buy them in an African minute.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp