Re: [j-nsp] ACX5448 & ACX710 - Update!

2020-07-30 Thread Mark Tinka


On 30/Jul/20 12:53, Luis Balbinot wrote:
> I work with telecom companies for years and DC is the standard for pretty
> much all of them. If you have a small shelter or container you can deploy
> an UPS DC system with a handful of batteries that will last for hours and
> will not take much space. Look inside a mobile node B station and you’ll
> only find DC power.
>
> All major IDCs will provide you -48VDC too.
>
> And to save a bit of money on power efficiency during the years.

We run cable landing stations across Africa, so yes, we do use DC for
those as well. Very familiar with the use-case.

We just find AC simpler and easier to work with at 3rd party data
centres as well as Metro commercial buildings, for routers, switches,
servers and such appliances. Dropping a UPS at those sites is far
simpler than deploying DC.

Mobile networks use DC heavily, this is well-known. Which is why I said,
this box was made for them.

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


Re: [j-nsp] ACX5448 & ACX710 - Update!

2020-07-30 Thread Mark Tinka



On 30/Jul/20 12:35, Baldur Norddahl wrote:

> To be fair there are more than two Juniper customers world wide that
> are using 48V DC. To my knowledge DC power is very common in the telco
> world.

DC is common, agreed. I just tend to avoid it.

During my Malaysia days, I found the company running kit on DC. When we
did the revamp of the network, we moved all of that to AC. Saved plenty
of space, simplified wiring and troubleshooting, and we were more native
with the data centres we housed in.

Same thing happened when I moved down to South Africa. Everything was on
DC, including the servers. Moved all that to AC, much to the delight of
our Facilities manager. Adding a UPS to support AC backup vs. adding
batteries and rectifiers, was good news.

More and more carrier-neutral data centres are now preferring AC. They
still do offer DC, but it's a whole thing that can cost extra depending
on where you are. I suppose it makes sense given that the cloud bags
need space, and they don't generally run their servers on DC.

There are some carrier-neutral DC's that don't offer any DC at all. All
they'll give you is footprint to deploy your own rectifier.


>
> What is special about ACX710 is probably the price point. They want a
> device for a certain market without loosing the ability to sell a
> higher priced device for another market.

I actually found out the reason why the ACX710 exists the way it does.
It's not what any of us think it is.

Suffice it to say, this box was built for mobile operators. 5G and what-not.

Mark.

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


Re: [j-nsp] ACX5448 & ACX710 - Update!

2020-07-30 Thread Luis Balbinot
I work with telecom companies for years and DC is the standard for pretty
much all of them. If you have a small shelter or container you can deploy
an UPS DC system with a handful of batteries that will last for hours and
will not take much space. Look inside a mobile node B station and you’ll
only find DC power.

All major IDCs will provide you -48VDC too.

And to save a bit of money on power efficiency during the years.

Luis

On Thu, 30 Jul 2020 at 07:38 Baldur Norddahl  wrote:

>
>
> On 30.07.2020 10.29, Mark Tinka wrote:
> > The ACX710 was clearly built for one or two mobile network operators.
> > There is no doubt about that.
> >
> > Juniper have been making boxes that support both AC and DC for yonks.
> > Hardened and regular. What's so special about the ACX710? In 2020?
> >
>
> To be fair there are more than two Juniper customers world wide that are
> using 48V DC. To my knowledge DC power is very common in the telco world.
>
> What is special about ACX710 is probably the price point. They want a
> device for a certain market without loosing the ability to sell a higher
> priced device for another market.
>
> Regards,
>
> Baldur
>
> ___
> 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


Re: [j-nsp] ACX5448 & ACX710 - Update!

2020-07-30 Thread Baldur Norddahl




On 30.07.2020 10.29, Mark Tinka wrote:

The ACX710 was clearly built for one or two mobile network operators.
There is no doubt about that.

Juniper have been making boxes that support both AC and DC for yonks.
Hardened and regular. What's so special about the ACX710? In 2020?



To be fair there are more than two Juniper customers world wide that are 
using 48V DC. To my knowledge DC power is very common in the telco world.


What is special about ACX710 is probably the price point. They want a 
device for a certain market without loosing the ability to sell a higher 
priced device for another market.


Regards,

Baldur

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


Re: [j-nsp] ACX5448 & ACX710 - Update!

2020-07-30 Thread Mark Tinka



On 30/Jul/20 10:19, Baldur Norddahl wrote:

> Not going to claim what is or is not a small issue for anyone here.
> Just saying that one rack unit external power supplies are plentiful
> and cheap. Like this one (just the first result on Google):
>
> https://www.simplypowersupply.com/Rack-Mount-Power-Supply/RCP-1000-48-Meanwell-48Vdc-1000W-Rack-Mount-Power-Supply.aspx
>
>
> We only have two datacentre locations and for those two location I
> would consider getting something like that. But I am probably going to
> go with the ACX5448 anyway because I could find a use for the extra
> 100G ports.
>
> The 20 locations are at the incumbents CO locations where 48 volt DC
> with battery and sometimes generator backup is what you get. You could
> get 230V AC at these locations but it would be without backup.
>
> In the future I might also get some locations in street cabinets,
> where I would put a standard DC UPS of the kind where you have a
> couple 12V batteries in series to make up the 48 volt, the equipment
> connected directly to the battery bank and a charger continuously
> charging the batteries. This is very cheap and extremely stable. The
> ACX710 device is environmentally hardened and clearly made for exactly
> that kind of deployment.

We considered all possible powering options before deciding that the
ACX710 is a show-stopper.

Rectifiers. UPS's. Solar. Solar + batteries. The works.

Over hundreds of sites dealing with thousands of devices, it's not going
to work. We'll spend too much time and money maintaining power, it
doesn't make sense.


>
> I see that ACX710 is not as much made for a specific customer as it is
> NOT made for a group of customers: the datacenter customers are
> supposed to buy the more expensive ACX5448. But said datacenter
> customers can spend one rack unit on an external DC powersupply and go
> with it anyway.

The ACX710 was clearly built for one or two mobile network operators.
There is no doubt about that.

Juniper have been making boxes that support both AC and DC for yonks.
Hardened and regular. What's so special about the ACX710? In 2020?

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


Re: [j-nsp] ACX5448 & ACX710 - Update!

2020-07-30 Thread Baldur Norddahl




On 29.07.2020 23.18, Mark Tinka wrote:

On 29/Jul/20 20:18, Baldur Norddahl wrote:

I am also going to get a few ACX5448 for our datacentre locations. I am
still considering getting some AC to DC powersupplies for the ACX710
because the cost saving is considerable. It is not like finding AC to DC
devices is hard - every laptop comes with one (yea I know too little
voltage).

If you are deploying 20, not a major issue.

If you're deploying several-hundred or several-thousands units, this is
not a small issue.



Not going to claim what is or is not a small issue for anyone here. Just 
saying that one rack unit external power supplies are plentiful and 
cheap. Like this one (just the first result on Google):


https://www.simplypowersupply.com/Rack-Mount-Power-Supply/RCP-1000-48-Meanwell-48Vdc-1000W-Rack-Mount-Power-Supply.aspx

We only have two datacentre locations and for those two location I would 
consider getting something like that. But I am probably going to go with 
the ACX5448 anyway because I could find a use for the extra 100G ports.


The 20 locations are at the incumbents CO locations where 48 volt DC 
with battery and sometimes generator backup is what you get. You could 
get 230V AC at these locations but it would be without backup.


In the future I might also get some locations in street cabinets, where 
I would put a standard DC UPS of the kind where you have a couple 12V 
batteries in series to make up the 48 volt, the equipment connected 
directly to the battery bank and a charger continuously charging the 
batteries. This is very cheap and extremely stable. The ACX710 device is 
environmentally hardened and clearly made for exactly that kind of 
deployment.


I see that ACX710 is not as much made for a specific customer as it is 
NOT made for a group of customers: the datacenter customers are supposed 
to buy the more expensive ACX5448. But said datacenter customers can 
spend one rack unit on an external DC powersupply and go with it anyway.


Regards,

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


Re: [j-nsp] ACX5448 & ACX710 - Update!

2020-07-30 Thread Mark Tinka



On 30/Jul/20 08:33, Daniel Verlouw wrote:

>
> which Nokia platform are you looking at? 7250 IXR is also
> Qumran/Jericho, Nokia is just hiding it everywhere they can...

All of Nokia's revised Metro-E platforms are Broadcom-based. It appears
to be the gentleman's handshake amongst all the equipment vendors that
Metro-E be cheap & cheerful, so they are all doing Broadcom.

We are looking at all of them:

  * IXR-e = Qumran UX
  * IXR-E = Qumran AX
  * IXR-s = Qumran MX
  * IXR-R4 = Qumran AX
  * IXR-R6 = Qumran MX
  * IXR-Xs = Jericho 2
  * IXR-X1 = Jericho 2

The Qumran units probably won't go anywhere with us. There is better
hope with the Jericho 2 unit, but even then, we are already seeing
fundamental issues on paper.

It's like I've been saying for some time now... if all the vendors are
going to be using the same chip for a platform in the same area of the
network, then the only differentiator is going to be what code customers
like to work with. Within the traditional vendors, I don't think that
matters much because their code is mature and well understood within the
networking community.

What you hear from the traditional vendors is that they "have the best
relationship with Brodacom vis-a-vis how they work with their SDK to
make the chip do what they want better than their competitors". If they
are all saying the same thing in that regard, not sure how true it is.

Ultimately, if you are going to end up with the same hardware issues
across all vendor platforms (unless some vendors decide to do clever but
costly things like recirculation, e.t.c.), what is the real value, then?

Mark.

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


Re: [j-nsp] ACX5448 & ACX710 - Update!

2020-07-30 Thread Mark Tinka



On 30/Jul/20 00:53, mt wrote:
> Exactly!!!
>
> my SE confirmed that there the ACX710 will be shipped with only DC
> power supply.
>
> I really don't know what the Juniper engineering team are thinking,
> they are forgetting the basic things. They're focusing on a unique
> customer requirement, and for me this is a absurd.

They are clearly envying the model of the other vendor right down the
road in San Jose...

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


Re: [j-nsp] ACX5448 & ACX710 - Update!

2020-07-30 Thread Daniel Verlouw
Hi Mark,

On Wed, Jul 29, 2020 at 4:24 PM Mark Tinka  wrote:
> I'm not sure I can be that patient, so I'm sniffing at Nokia's new
> Metro-E product line. The problem is so far, as with Juniper and Cisco,
> they've gone down the Broadcom route (some boxes shipping with Qumran,
> others with Jericho 2, and on-paper, they are already failing some of
> our forwarding requirements.

which Nokia platform are you looking at? 7250 IXR is also
Qumran/Jericho, Nokia is just hiding it everywhere they can...

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


Re: [j-nsp] ACX5448 & ACX710 - Update!

2020-07-29 Thread Shamen Snyder
Heads up on the ACX5448. There is a major LDP bug in the recommend code
19.3R2-S3.

LDP hellos are punted to the RE In queue rx-unknown-mc instead of
rxq-l3-nc-hi.

A major shift in multicast on our network dropped LDP neighbors.

The issue doesn’t happen in 20.2R1 if you find it’s stable (I haven’t). I
believe the PR is PR1503469 and should be going into 19.3R3.




On Wed, Jul 29, 2020 at 2:20 PM Baldur Norddahl  wrote:

> I am planning to deploy ACX710 with maybe 20 units (which for us is a huge
> number). We would have ordered DC in any case, so that is a non issue. We
> will have them at CO buildings were DC is what you get and maybe in the
> future in road side cabinets, where DC is the easy way to have some battery
> backup.
>
> I am also going to get a few ACX5448 for our datacentre locations. I am
> still considering getting some AC to DC powersupplies for the ACX710
> because the cost saving is considerable. It is not like finding AC to DC
> devices is hard - every laptop comes with one (yea I know too little
> voltage).
>
> Our purpose is to replace our MPLS core with new gear that has deep buffers
> and better support for traffic engineering etc. These will be P and PE
> routers mostly doing L2VPN. We will have a 100G ring topology of ACX710
> devices moving MPLS packets and terminating L2VPN.
>
> Seems to be a perfect fit to me. I am not interested in the older ACX
> devices which lacks buffers and is probably not much better than the gear
> we want to replace.
>
> Regards
>
> Baldur
>
>
> ons. 29. jul. 2020 16.25 skrev Mark Tinka :
>
> >
> >
> > On 29/Jul/20 15:49, Eric Van Tol wrote:
> > > We ran into this, too. We signed up to beta test at the beginning of
> > this year and nowhere, not even in discussions with our SE (who also
> wasn't
> > told by Juniper), was it mentioned it was a DC-only device. Imagine my
> > surprise when I received the box and it was DC only. Such a
> disappointment.
> >
> > The messaging we got from them earlier in the year about trying out
> > their new Metro-E box was that we would be happy with it, considering
> > that every Metro-E solution they've thrown at us since 2008 has fallen
> > flat, splat!
> >
> > Come game-time, even our own SE was blindsided by this DC-only support
> > on the ACX710. Proper show-stopper.
> >
> > At any rate, the story is that they should be pushing out some new
> > ACX7xxx boxes from next year, which should have AC support (to you
> > psych. majors: more for the general public, and not the custom-built
> > ACX710).
> >
> > I'm not sure I can be that patient, so I'm sniffing at Nokia's new
> > Metro-E product line. The problem is so far, as with Juniper and Cisco,
> > they've gone down the Broadcom route (some boxes shipping with Qumran,
> > others with Jericho 2, and on-paper, they are already failing some of
> > our forwarding requirements.
> >
> > It's not easy...
> >
> > 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


Re: [j-nsp] ACX5448 & ACX710 - Update!

2020-07-29 Thread Shamen Snyder
The Juniper Bolan architecture is suppose to have an AC variant.

 Hardened (-40C to 65C), compact (445m x 221mm x 250mm) form factor –
suitable for cabinets in pre-aggregation network layer
• 2 Routing Engine slots, 1:1 redundant control and forwarding/switching
plane
• 320Gb/s and 2.4 Tb/s RP Variants; Full FIB with 2.4Tb/s RP – 1.5M FIB
• Flexibility of 7 (DC versions) or 6 (AC versions) line card slots
• 8x1GE/10GE
• 8 x 10/25GE
• 2x40GE/100GE
• 4x40/100GE (C-Temp)

I haven’t been following it much, but may be worth poking your SE on.

On Wed, Jul 29, 2020 at 9:43 AM Mark Tinka  wrote:

> So an update on this thread...
>
> Juniper went ahead and made the ACX710 a DC-only box. So if you are an
> AC house, you're in deep doo-doo (which is us).
>
> DC, for large scale deployment in the Metro? Makes zero sense to me.
>
> Apparently, no way around this; which, to me, smells of the box being
> built for some larger operator (like mobile), who primarily have DC
> plants. And that's it - no other options for anyone else.
>
> Oh, these vendors...
>
> I haven't yet seen an ACX710 outside of a PDF, but deep scouring on the
> Internet led me to this:
>
>
>
> https://portal.nca.org.gh/search_type_approval_view_details.php?typeApproveDetailID=2244
>
> Some kind of type approval with National Communications Authority of Ghana.
>
> 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


Re: [j-nsp] ACX5448 & ACX710 - Update!

2020-07-29 Thread mt

Exactly!!!

my SE confirmed that there the ACX710 will be shipped with only DC power 
supply.


I really don't know what the Juniper engineering team are thinking, they 
are forgetting the basic things. They're focusing on a unique customer 
requirement, and for me this is a absurd.


mt

Em 29/07/2020 18:18, Mark Tinka escreveu:


On 29/Jul/20 20:18, Baldur Norddahl wrote:

I am also going to get a few ACX5448 for our datacentre locations. I am
still considering getting some AC to DC powersupplies for the ACX710
because the cost saving is considerable. It is not like finding AC to DC
devices is hard - every laptop comes with one (yea I know too little
voltage).

If you are deploying 20, not a major issue.

If you're deploying several-hundred or several-thousands units, this is
not a small issue.

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


Re: [j-nsp] ACX5448 & ACX710 - Update!

2020-07-29 Thread Mark Tinka



On 29/Jul/20 20:18, Baldur Norddahl wrote:
> I am also going to get a few ACX5448 for our datacentre locations. I am
> still considering getting some AC to DC powersupplies for the ACX710
> because the cost saving is considerable. It is not like finding AC to DC
> devices is hard - every laptop comes with one (yea I know too little
> voltage).

If you are deploying 20, not a major issue.

If you're deploying several-hundred or several-thousands units, this is
not a small issue.

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


Re: [j-nsp] ACX5448 & ACX710 - Update!

2020-07-29 Thread Baldur Norddahl
I am planning to deploy ACX710 with maybe 20 units (which for us is a huge
number). We would have ordered DC in any case, so that is a non issue. We
will have them at CO buildings were DC is what you get and maybe in the
future in road side cabinets, where DC is the easy way to have some battery
backup.

I am also going to get a few ACX5448 for our datacentre locations. I am
still considering getting some AC to DC powersupplies for the ACX710
because the cost saving is considerable. It is not like finding AC to DC
devices is hard - every laptop comes with one (yea I know too little
voltage).

Our purpose is to replace our MPLS core with new gear that has deep buffers
and better support for traffic engineering etc. These will be P and PE
routers mostly doing L2VPN. We will have a 100G ring topology of ACX710
devices moving MPLS packets and terminating L2VPN.

Seems to be a perfect fit to me. I am not interested in the older ACX
devices which lacks buffers and is probably not much better than the gear
we want to replace.

Regards

Baldur


ons. 29. jul. 2020 16.25 skrev Mark Tinka :

>
>
> On 29/Jul/20 15:49, Eric Van Tol wrote:
> > We ran into this, too. We signed up to beta test at the beginning of
> this year and nowhere, not even in discussions with our SE (who also wasn't
> told by Juniper), was it mentioned it was a DC-only device. Imagine my
> surprise when I received the box and it was DC only. Such a disappointment.
>
> The messaging we got from them earlier in the year about trying out
> their new Metro-E box was that we would be happy with it, considering
> that every Metro-E solution they've thrown at us since 2008 has fallen
> flat, splat!
>
> Come game-time, even our own SE was blindsided by this DC-only support
> on the ACX710. Proper show-stopper.
>
> At any rate, the story is that they should be pushing out some new
> ACX7xxx boxes from next year, which should have AC support (to you
> psych. majors: more for the general public, and not the custom-built
> ACX710).
>
> I'm not sure I can be that patient, so I'm sniffing at Nokia's new
> Metro-E product line. The problem is so far, as with Juniper and Cisco,
> they've gone down the Broadcom route (some boxes shipping with Qumran,
> others with Jericho 2, and on-paper, they are already failing some of
> our forwarding requirements.
>
> It's not easy...
>
> 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


Re: [j-nsp] ACX5448 & ACX710 - Update!

2020-07-29 Thread Mark Tinka



On 29/Jul/20 15:49, Eric Van Tol wrote:
> We ran into this, too. We signed up to beta test at the beginning of this 
> year and nowhere, not even in discussions with our SE (who also wasn't told 
> by Juniper), was it mentioned it was a DC-only device. Imagine my surprise 
> when I received the box and it was DC only. Such a disappointment.

The messaging we got from them earlier in the year about trying out
their new Metro-E box was that we would be happy with it, considering
that every Metro-E solution they've thrown at us since 2008 has fallen
flat, splat!

Come game-time, even our own SE was blindsided by this DC-only support
on the ACX710. Proper show-stopper.

At any rate, the story is that they should be pushing out some new
ACX7xxx boxes from next year, which should have AC support (to you
psych. majors: more for the general public, and not the custom-built
ACX710).

I'm not sure I can be that patient, so I'm sniffing at Nokia's new
Metro-E product line. The problem is so far, as with Juniper and Cisco,
they've gone down the Broadcom route (some boxes shipping with Qumran,
others with Jericho 2, and on-paper, they are already failing some of
our forwarding requirements.

It's not easy...

Mark.

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


Re: [j-nsp] ACX5448 & ACX710 - Update!

2020-07-29 Thread Eric Van Tol
We ran into this, too. We signed up to beta test at the beginning of this year 
and nowhere, not even in discussions with our SE (who also wasn't told by 
Juniper), was it mentioned it was a DC-only device. Imagine my surprise when I 
received the box and it was DC only. Such a disappointment.

-evt

On 7/29/20, 9:43 AM, "juniper-nsp on behalf of Mark Tinka" 
 wrote:

So an update on this thread...

Juniper went ahead and made the ACX710 a DC-only box. So if you are an
AC house, you're in deep doo-doo (which is us).

DC, for large scale deployment in the Metro? Makes zero sense to me.

Apparently, no way around this; which, to me, smells of the box being
built for some larger operator (like mobile), who primarily have DC
plants. And that's it - no other options for anyone else.

Oh, these vendors...

I haven't yet seen an ACX710 outside of a PDF, but deep scouring on the
Internet led me to this:



https://portal.nca.org.gh/search_type_approval_view_details.php?typeApproveDetailID=2244

Some kind of type approval with National Communications Authority of Ghana.

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


Re: [j-nsp] ACX5448 & ACX710 - Update!

2020-07-29 Thread Mark Tinka
So an update on this thread...

Juniper went ahead and made the ACX710 a DC-only box. So if you are an
AC house, you're in deep doo-doo (which is us).

DC, for large scale deployment in the Metro? Makes zero sense to me.

Apparently, no way around this; which, to me, smells of the box being
built for some larger operator (like mobile), who primarily have DC
plants. And that's it - no other options for anyone else.

Oh, these vendors...

I haven't yet seen an ACX710 outside of a PDF, but deep scouring on the
Internet led me to this:

   
https://portal.nca.org.gh/search_type_approval_view_details.php?typeApproveDetailID=2244

Some kind of type approval with National Communications Authority of Ghana.

Mark.

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


Re: [j-nsp] ACX5448 & ACX710

2020-01-25 Thread Mark Tinka


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


Re: [j-nsp] ACX5448 & ACX710

2020-01-24 Thread Colton Conor
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  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


Re: [j-nsp] ACX5448 & ACX710

2020-01-23 Thread Mark Tinka



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


Re: [j-nsp] ACX5448 & ACX710

2020-01-23 Thread Saku Ytti
On Thu, 23 Jan 2020 at 22:52, Mark Tinka  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


Re: [j-nsp] ACX5448 & ACX710

2020-01-23 Thread Mark Tinka


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


Re: [j-nsp] ACX5448 & ACX710

2020-01-23 Thread Mark Tinka



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


Re: [j-nsp] ACX5448 & ACX710

2020-01-23 Thread adamv0025
> From: Mark Tinka 
> Sent: Thursday, January 23, 2020 9:21 AM
> 
> On 23/Jan/20 10:55, adamv0...@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


Re: [j-nsp] ACX5448 & ACX710

2020-01-23 Thread quinn snyder
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 | snyd...@gmail.com 

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

> On Jan 23, 2020, at 14:03, Colton Conor  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  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


Re: [j-nsp] ACX5448 & ACX710

2020-01-23 Thread Colton Conor
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  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


Re: [j-nsp] ACX5448 & ACX710

2020-01-23 Thread Mark Tinka



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


Re: [j-nsp] ACX5448 & ACX710

2020-01-23 Thread Shamen Snyder
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  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


Re: [j-nsp] ACX5448 & ACX710

2020-01-23 Thread Thomas Scott
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.sc...@gmail.com  


On Thu, Jan 23, 2020 at 4:21 AM Mark Tinka  wrote:

>
>
> On 23/Jan/20 10:55, adamv0...@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


Re: [j-nsp] ACX5448 & ACX710

2020-01-23 Thread Mark Tinka



On 23/Jan/20 10:55, adamv0...@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


Re: [j-nsp] ACX5448 & ACX710

2020-01-23 Thread adamv0025
> 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


Re: [j-nsp] ACX5448 & ACX710

2020-01-23 Thread adamv0025
> 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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Mark Tinka



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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Mark Tinka



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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Saku Ytti
On Wed, 22 Jan 2020 at 20:46, Mark Tinka  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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Mark Tinka



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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Tim Durack
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  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.guimar...@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-boun...@puck.nether.net em nome de mark.ti...@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=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s=TU6hC3CmliVPupj04_YNYHTF5VVsspISdyOjUEnr2TM=r-fSdwLUay6e6rXEc7nibhLO1FNxOw1U62KPIFpFeF4=
> >
> >
> > ___
> > 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
> 

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Colton Conor
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.guimar...@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-boun...@puck.nether.net em nome de mark.ti...@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=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s=TU6hC3CmliVPupj04_YNYHTF5VVsspISdyOjUEnr2TM=r-fSdwLUay6e6rXEc7nibhLO1FNxOw1U62KPIFpFeF4=
>
>
> ___
> 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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Mark Tinka


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.



signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Gert Doering
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 g...@greenie.muc.de


signature.asc
Description: PGP signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Rob Foehl

On Wed, 22 Jan 2020, Saku Ytti wrote:


On Wed, 22 Jan 2020 at 11:48, Rob Foehl  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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Alexandre Guimaraes
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" 
 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=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s=TU6hC3CmliVPupj04_YNYHTF5VVsspISdyOjUEnr2TM=r-fSdwLUay6e6rXEc7nibhLO1FNxOw1U62KPIFpFeF4=


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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Mark Tinka



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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Eric Van Tol
On 1/22/20, 10:08 AM, "juniper-nsp on behalf of Mark Tinka" 
 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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Mark Tinka



On 22/Jan/20 16:01, adamv0...@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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Saku Ytti
On Wed, 22 Jan 2020 at 16:09, Robert Raszuk  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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Robert Raszuk
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  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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Saku Ytti
On Wed, 22 Jan 2020 at 16:01,  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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread adamv0025
> 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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Saku Ytti
On Wed, 22 Jan 2020 at 11:48, Rob Foehl  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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Rob Foehl

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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Giuliano C. Medalha
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  on behalf of Saku Ytti 

Sent: Wednesday, January 22, 2020 5:49:50 AM
To: Mark Tinka 
Cc: Juniper List 
Subject: Re: [j-nsp] ACX5448 & ACX710

On Wed, 22 Jan 2020 at 10:06, Mark Tinka  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-nspdata=02%7C01%7Cgiuliano%40wztech.com.br%7C4e373f01744e438c535208d79f1835b6%7C584787b077bd4312bf8815412b8ae504%7C1%7C0%7C637152798679559514sdata=KyXYR5LrmaEQJ30ILxsvV2wftgd3dG2%2F1I%2Fo1qRZOvc%3Dreserved=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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Saku Ytti
On Wed, 22 Jan 2020 at 10:06, Mark Tinka  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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Mark Tinka



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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Mark Tinka



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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Mark Tinka



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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Mark Tinka



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


Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread Giuliano C. Medalha
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 
Sent: Wednesday, January 22, 2020 3:26:38 AM
To: Giuliano C. Medalha 
Cc: jnsp list 
Subject: Re: [j-nsp] ACX5448 & ACX710

On Tue, 21 Jan 2020 at 22:24, Giuliano C. Medalha
 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


Re: [j-nsp] ACX5448 & ACX710

2020-01-21 Thread Saku Ytti
On Tue, 21 Jan 2020 at 22:24, Giuliano C. Medalha
 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


Re: [j-nsp] ACX5448 & ACX710

2020-01-21 Thread Giuliano C. Medalha
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  On Behalf Of Luis 
Balbinot
Sent: terça-feira, 21 de janeiro de 2020 16:59
To: Aaron Gould 
Cc: jnsp list 
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  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
> data=02%7C01%7Cgiuliano%40wztech.com.br%7Cf47f0378dce54349a9d208d
> 79eac77dd%7C584787b077bd4312bf8815412b8ae504%7C1%7C1%7C637152335925921
> 914sdata=O6x7rQJ2OdQeVpdjsWEeWW%2BbUfvLWShaDrb0itRc%2FRk%3Dr
> 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.pdfdata=02%7C01%7Cgiuliano%40wztech.com.br
> %7Cf47f0378dce54349a9d208d79eac77dd%7C584787b077bd4312bf8815412b8ae504
> %7C1%7C1%7C637152335925921914sdata=kaF077Ymm7a4T4QDuI6Y2R8KRZnyuc
> s0lDGH838NJ%2F0%3Dreserved=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-nspdata=02%7C01%7Cgiul
> iano%40wztech.com.br%7Cf47f0378dce54349a9d208d79eac77dd%7C584787b077bd
> 4312bf8815412b8ae504%7C1%7C1%7C637152335925921914sdata=bQ7iLaxJOi
> Gj730LNO2u4gH64TpYWJMYC5exorh69bI%3Dreserved=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-nspdata=02%7C01%7Cgiuliano%40wztech.com.br%7Cf47f0378dce54349a9d208d79eac77dd%7C584787b077bd4312bf8815412b8ae504%7C1%7C1%7C637152335925921914sdata=bQ7iLaxJOiGj730LNO2u4gH64TpYWJMYC5exorh69bI%3Dreserved=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, s

Re: [j-nsp] ACX5448 & ACX710

2020-01-21 Thread Luis Balbinot
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  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
> 
> 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


Re: [j-nsp] ACX5448 & ACX710

2020-01-21 Thread Aaron Gould
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


[j-nsp] ACX5448 & ACX710

2020-01-21 Thread Mark Tinka
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