On Oct 21, 2015, at 3:34 PM, Saku Ytti <[email protected]> wrote:
> Hey Chad,
>
>> Please don't go the IOS/EOS/non-Junos method for rpd where each protocol is 
>> completely independent and isolated from the others.  It is extremely 
>> helpful to be able to do things like put communities on static routes.  Even 
>> protocols that don't use communities can leverage them in the export policy, 
>> the community just isn't announced.  Ditto for import policies.
>>
>> Sacrificing that flexibility and simplicity to multithread rpd and shifting 
>> to explicit route redistribution with limited route attributes per protocol 
>> would be a huge loss.
>
> You don't need to worry, these two issues have nothing in common. What
> you're talking about is very high level concept and it implies nothing
> about the underlaying architecture.

True, but I also know a good bit about the underlying architecture and have a 
good grasp of general system and programming concepts.  Definitely not a 
developer though so I don't typically know the specifics on how something is 
implemented.

>From a general view it seems that the simplest and fastest method to get rpd 
>to leverage multicore systems better is splitting apart the different 
>protocols.  That opens up having to deal with contention amongst the different 
>protocols trying to access a single global route table simultaneously.  It can 
>be done but it could also be sidestepped entirely by having per protocol 
>tables rather than a single global table.  I would hope that isn't the path 
>taken, but I've already dealt with various groups within Juniper and elsewhere 
>that have made design decisions ranging from fantastic to questionable to 
>absolutely horrible.  My request is just trying to prevent seeing Junos core 
>do something really bad, either inadvertently or on purpose.

> Having said that, why on earth no tags/communities on direct/connected
> routes on any(?) platform. It dilutes usefulness in static routes as
> well, as you're still going to need to have logic to provision
> prefix-lists, so might as well do it same way for statics and directs.

Adding that would be on the fantastic side of design decisions.

As would getting the group that handles spd to adhere to the same standards as 
the rest of Junos with regard to naming conventions, inheritance, and 
prefix-list expansions.  And finally putting commas in the monitor interface 
traffic output.

-Chad

________________________________

This message may contain confidential information and is intended for specific 
recipients unless explicitly noted otherwise. If you have reason to believe you 
are not an intended recipient of this message, please delete it and notify the 
sender. This message may not represent the opinion of Intercontinental 
Exchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a 
contract or guarantee. Unencrypted electronic mail is not secure and the 
recipient of this message is expected to provide safeguards from viruses and 
pursue alternate means of communication where privacy or a binding message is 
desired.
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp

Reply via email to