[j-nsp] Opinions on fusion provider edge

[Antti Ristimäki]

Hi,

We also went with the Fusion with MX10k routers, just because we need 1GE interfaces and also 10GE interfaces with e.g. colored optics. In my opinion traditional L2 aggregation style would have been the preferred and probably more robust way, but then depending on the satellite device it might be harder to do L2 protocol tunneling, which is fairly trivial with Fusion and CCC connections.

Wrt the original question about possible issues with Fusion, we have faced quite a many. Currently one of the biggest pains is to get CoS configured properly on Fusion ports. We have a case open, where any CoS scheduler change stops traffic forwarding out from the cascade port, if one has explicitly configured schedulers for the cascade port logical control (32769) and data (32770) units. This is pretty irritating, as traffic between the extended customer facing port and the CE device works just fine, keeping e.g. BGP up and running, but traffic to/from the core does not work.

I'm also somewhat concerned about the fact that the whole Fusion thing is more or less a black box and as such much more difficult to debug than traditional technologies. 

>From monitoring point of view it also a bit challenge that not all information related to satellite ports is not available via SNMP. E.g. queue specific counters are not available but have to be queried via CLI command, and IIRC also ifOutDiscards is not recorded for the extended ports.

Antti

----- On 6 Nov, 2018, at 20:39, Saku Ytti saku at ytti.fi wrote:

> Hey Richard,
> 
> I think there are two separate issues here. Lot of people looking at
> Fusion aren't choosing it for technology, they are choosing it for
> media, as 1GE L3 ports are not available. So options are
> 
> a) L2 aggregation
> b) Fusion
> c) Wait for JNPR to release some MX244 with 4xQSFP28 + 40xSFP+ box,
> which has attractive pay-as-you-go for 1GE deployments.
> 
> I'm sure there is another set of problems where EVPN and Fusion are
> competition options, but for service providers fusion's value proposal
> mainly is low rate ports, ports which Cisco and Juniper do not really
> offer anymore on L3 devices.
> 
> 
> On Tue, 6 Nov 2018 at 19:21, Richard McGovern <rmcgovern at juniper.net> wrote:
>>
>> I might suggest you look at an EVPN based design instead.  This is going to be
>> Juniper's #1 go to in the future.  I believe things like Junos Fusion and
>> MC-LAG, etc. may still be supported, but secondary to EVPN and associated
>> features.
>>
>> What is your planned SD devices?  QFX5???
>>
>> Richard McGovern
>> Sr Sales Engineer, Juniper Networks
>> 978-618-3342
>>
>>
>> On 11/5/18, 8:32 PM, "Eldon Koyle" <ekoyle+puck.nether.net at gmail.com> wrote:
>>
>>     What kind of experiences (good or bad) have people had with Juniper's
>>     Fusion Provider edge?  Are there any limitations I should be aware of?
>>
>>     I'm looking at it to simplify management in a campus network environment
>>     and to use features that are only available on the MX currently.
>>
>>     --
>>     Eldon
>>     --
>>     I don't think the universe wants me to send this message
>>
>>
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 
> 
> --
>  ++ytti
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 
> --