[j-nsp] conditional route import

[Alexander Arseniev]

My idea is based on what is working in JUNOS today, it is called 
"conditional EXPORT".

Yes, unmodified route would be visible only on RR and not used for 
actual forwarding, that's the purpose of modifying it in 1st place, 
isn't it?

Your idea to make route attribute change to work conditionally on IMPORT 
requires adding code to JUNOS.

Your choice what You want to use and when :-)

Thx

Alex


On 15/03/2017 10:23, adamv0025 at netconsultings.com wrote:
>
> Although I’d prefer that the router which introduces the route X to a 
> local AS performs the desired attribute changes to the route X, it 
> doesn’t matter whether it’s the PE or a RR –still the same requirement 
> holds true.
>
> PE or RR(in your example) needs to look into its routing table to see 
> if route Y exist and based on that change attributes of an _incoming 
> _route X.
>
> Yes I could change attributes of route X while I advertise it to RRs 
> (on export from VRF).
>
> -but that would make the PE which introduced route X to a local AS 
> oblivion to routing change that’s apparent to everyone else in the AS, 
> which is not desirable
>
> adam
>
> netconsultings.com
>
> ::carrier-class solutions for the telecommunications industry::
>
> *From:*Alexander Arseniev [mailto:arseniev at btinternet.com]
> *Sent:* Tuesday, March 14, 2017 5:57 PM
> *To:* adamv0025 at netconsultings.com; juniper-nsp at puck.nether.net
> *Subject:* Re: [j-nsp] conditional route import
>
> Hello,
>
> If You pass this route to BGP RR and do modifications there before 
> advertising it to target PE, where it is installed with modified 
> parameters then You'd achieve Your objective.
>
> BGP RR in this case plays the role of "external controller".
>
> You can even have interface peering extended to BGP RR via L2circuit 
> so PE does not even learn the original route, it installs modified 
> one. This avoids the complexities with sending the modified route back 
> to originator PE I mentioned earlier.
>
> Hope this makes sense.
>
> Thx
>
> Alex
>
> On 14/03/2017 11:23, adamv0025 at netconsultings.com 
> <mailto:adamv0025 at netconsultings.com> wrote:
>
>     Hi Alexander,
>
>     No in my example I need to modify parameters of route X, based on
>     parameters of route Y.
>
>     That seem to be impossible in current versions of network codes
>     (other than via external controller)
>
>     adam
>
>     netconsultings.com
>
>     ::carrier-class solutions for the telecommunications industry::
>
>     *From:*Alexander Arseniev [mailto:arseniev at btinternet.com]
>     *Sent:* Monday, March 13, 2017 12:28 PM
>     *To:* adamv0025 at netconsultings.com
>     <mailto:adamv0025 at netconsultings.com>; juniper-nsp at puck.nether.net
>     <mailto:juniper-nsp at puck.nether.net>
>     *Subject:* Re: [j-nsp] conditional route import
>
>     Hello,
>
>     You can do it easily in BGP Route Reflector export policy coupled
>     with other features like ORR and NH rewriting.
>
>     There could be complexities with PE config (obviously, the PE
>     would prefer eBGP route direct from CE vs iBGP from RR) but they
>     can be overcome with routing-instances.
>
>     HTH
>     Thx
>     Alex
>
>     On 12/03/2017 10:32, adamv0025 at netconsultings.com
>     <mailto:adamv0025 at netconsultings.com> wrote:
>
>         Hi folks,
>
>           
>
>         Anyone tried to use "if-route-exists" or the "rib has route" condition for
>
>         route import as opposed to the more usual route export or default route
>
>         origination respectively?
>
>         Can't find it documented anywhere and it's not working, but I'm just curious
>
>         what are your thoughts on the concept of general routing behaviour
>
>         programmability using routing information.
>
>         I need the network to reprogram itself based on routing events without the
>
>         YANG/NETCONF complexity.
>
>         And for that I'd need a route and it's specific parameter or a set of
>
>         parameters to be used as an instruction or a trigger.
>
>         I'd like to be able to use a more general from of condition in
>
>         routing-policies (or even forwarding filters or QOS-policies).
>
>           
>
>         Example:
>
>           
>
>         condition_1
>
>         if (route = x.x.x.x/x in VRF A) AND (igp metric to NH < 100)
>
>         then
>
>         condition_1 == TRUE
>
>           
>
>         route-policy 1
>
>         if
>
>         route = y.y.y.y/y AND if condition_1 == TRUE
>
>         then
>
>         set local-preference 120 AND accept
>
>           
>
>         bgp
>
>         VRF A neighbour z.z.z.z route-policy 1 in
>
>           
>
>           
>
>           
>
>         Options:
>
>         The trigger route can be constructed at the trigger router and advertised
>
>         into an intended VRF or to a separate "instructions-VRF", dedicated to
>
>         contain these special purpose routes if we don't want to mix these
>
>         instruction routes with regular routing information.
>
>         Or the trigger route could be a regular routing info with a specific set of
>
>         attributes that we intend to use as a marker of a specific network event
>
>         that we want to act upon in case it happens.
>
>           
>
>           
>
>         I'd appreciate any feedback.
>
>           
>
>           
>
>         adam
>
>           
>
>         netconsultings.com
>
>         ::carrier-class solutions for the telecommunications industry::
>
>           
>
>           
>
>         _______________________________________________
>
>         juniper-nsp mailing listjuniper-nsp at puck.nether.net <mailto:juniper-nsp at puck.nether.net>
>
>         https://puck.nether.net/mailman/listinfo/juniper-nsp
>