On Oct 9, 2015, at 10:08 AM, Jeff Haas <jh...@juniper.net> wrote:

> Adam,
>
>> On Oct 9, 2015, at 9:45 AM, Adam Chappell <adam.chapp...@gmail.com> wrote:
>>>
>> I can imagine that making rpd MT is probably hard to the point of almost
>> not being worth the benefit (with current REs), unless one can adequately
>> break down the problem into divisable chunks of work that are insensitive
>> to execution order.  BGP peer route analysis, comparison against import
>> policy and current RIB might fall into that category, but not without a lot
>> of locking and potential for races.
>
> It is non-trivial work.  But it is also somewhat easier to incrementally 
> introduce threading than it is to split large hunks of code and workflow into 
> multiple processes.
>
> We're not going into deep technical detail on mailing lists such as these at 
> the moment.  The work is in progress.

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.

-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 juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Reply via email to