[j-nsp] Suggestions for Edge/Peering Router..

[Nikolas Geyer]

I have to play devils advocate around “Right this inconsistency between configured and operational state in my opinion is THE biggest problem of XR”

Have had this problem occur multiple times in Junos, as recently as Junos 17, where what was being advertised did not reflect configured policy. Worse still, the only recovery was complete deletion of the policy (and any peers using it) then re-adding it.

So it’s definitely not a XR only problem. 

Sent from my iPhone

On Sep 19, 2019, at 8:11 AM, "adamv0025 at netconsultings.com" <adamv0025 at netconsultings.com> wrote:

>> From: Saku Ytti <saku at ytti.fi>
>> Sent: Thursday, September 19, 2019 12:33 PM
>> 
>>> On Thu, 19 Sep 2019 at 14:22, <adamv0025 at netconsultings.com> wrote:
>>> 
>>> Just a few examples when you change export policy it resets the peer
>>> or the cockup with RR clearing all sessions or the fact BGP is part of
>>> very complex RDP monolith -to me that's not really "carrier grade"
>>> implementation
>> 
>> This happens when export policy breaks update-group. It may sometimes be
>> difficult for operator to understand if it will do that or not, so it's fair concern.
>> Perhaps system should not clear, but tell manual clear is needed for policy
>> change to take effect.
>> 
> Ideally I'd like to see equivalent of Cisco's dynamic update peer-groups in Junos.
> 
>> If monolith is good or bad, I'm not sure. If you thread you have high
>> performance with some risk. If you have process separation you have IPC
>> problem, and you have low performance and many will solve this by
>> duplicating state. Junos is moving towards multi process model with Junos
>> Evolved, if this will be positive or negative direction remains to be seen.
>> 
> I like where XR and Junos Evolved is heading, 
> In future I'd like to have the option to install only stuff I need on a particular type of node/deployment and not worry about the rest all the way to being able to mix and match protocols of different vendors.  
> Although cRPD is also interesting development pathway, but again cBGP would be even better :) 
> 
>> Operationally speaking, BGP in JunOS for us works great, on IOS-XR right now
>> we have sessions where policy isn't what is configured and there is no way to
>> verify which one, and we've propagated leaks because acting configuration
>> isn't the one we've configured. We've not had similar problems in JunOS. This
>> is anecdote, not data.
>> 
> Right this inconsistency between configured and operational state in my opinion is THE biggest problem of XR, I'm afraid it has to be something fundamental since they haven't been able to consistently address these inconsistencies across the board for years now (or ASR9k HW? Not sure if these types of issues can be experienced on other platforms).
> Though usually it's CP state does not trickle down to DP correctly/completely where what you described seems to be CP only. 
> 
> adam
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp