Change Details

This is one of the long awaited features in VRF terms. Support for per VRF routing should be added for: * BGP * OSPF * OSPFv3 * IS-IS This task is dedicated as an umbrella task for all forther actions and mainly used to discuss the CLI design. # CLI Options ## Option 1 Use the routing protocol below the VRF tree * `set protocols vrf <vrf> ospf` * `set protocols vrf <vrf> ospfv3` * `set protocols vrf <vrf> bgp <asn>` **PROS:** - matches the current CLI design for static routing - all contained under one, per vrf tagNode **CONS:** - Adjustment of XML and Python helpers required - make entire protocols re-includable ## Option 2 Make the VRF inline of the current routing protocol * `set protocols ospf vrf <vrf> default-information` * `set protocols ospf vrf <vrf> area` * `set protocols ospf vrf <vrf> ...` * `set protocols ospfv3 vrf <vrf> default-information` * `set protocols ospfv3 vrf <vrf> area` * `set protocols ospfv3 vrf <vrf> ...` * `set protocols bgp <asn> vrf <vrf>neighbor x.x.x.x` * `set protocols bgp <asn> vrf <vrf>address-family ipv4-unicast ...` **PROS:** - matches the current CLI design for dynamic routing - all contained under one, per protocol node **CONS:** - to many nesting levels ## Option 3 No per VRF dynamic routing Just kidding - this is no option at all! # Summary From a programmers point of view option 2 should be preferred as it's less invasive. Given the fact that this will happen on the 1.4 current unstable branch invasive changes are totally fine given the current level of smoketests available. From a user point of view I feel option 1 should be the option of choice. Please comment and help with the CLI design and wishes. Given the fact that now all protocols are in good XML/Python shape implementation is rather easy now.

This is one of the long awaited features in VRF terms. Support for per VRF routing should be added for: * BGP * OSPF * OSPFv3 * IS-IS This task is dedicated as an umbrella task for all forther actions and mainly used to discuss the CLI design. # CLI Options ## Option 1 Use the routing protocol below the VRF tree * `set protocols vrf <vrf> ospf` * `set protocols vrf <vrf> ospfv3` * `set protocols vrf <vrf> bgp <asn>` **PROS:** - matches the current CLI design for static routing - all contained under one, per vrf tagNode **CONS:** - Adjustment of XML and Python helpers required - make entire protocols re-includable ## Option 2 Make the VRF inline of the current routing protocol * `set protocols ospf vrf <vrf> default-information` * `set protocols ospf vrf <vrf> area` * `set protocols ospf vrf <vrf> ...` * `set protocols ospfv3 vrf <vrf> default-information` * `set protocols ospfv3 vrf <vrf> area` * `set protocols ospfv3 vrf <vrf> ...` * `set protocols bgp <asn> vrf <vrf> neighbor x.x.x.x` * `set protocols bgp <asn> vrf <vrf> address-family ipv4-unicast ...` **PROS:** - matches the current CLI design for dynamic routing - all contained under one, per protocol node **CONS:** - to many nesting levels ## Option 3 No per VRF dynamic routing Just kidding - this is no option at all! # Summary From a programmers point of view option 2 should be preferred as it's less invasive. Given the fact that this will happen on the 1.4 current unstable branch invasive changes are totally fine given the current level of smoketests available. From a user point of view I feel option 1 should be the option of choice. Please comment and help with the CLI design and wishes. Given the fact that now all protocols are in good XML/Python shape implementation is rather easy now.

This is one of the long awaited features in VRF terms. Support for per VRF routing should be added for: * BGP * OSPF * OSPFv3 * IS-IS This task is dedicated as an umbrella task for all forther actions and mainly used to discuss the CLI design. # CLI Options ## Option 1 Use the routing protocol below the VRF tree * `set protocols vrf <vrf> ospf` * `set protocols vrf <vrf> ospfv3` * `set protocols vrf <vrf> bgp <asn>` **PROS:** - matches the current CLI design for static routing - all contained under one, per vrf tagNode **CONS:** - Adjustment of XML and Python helpers required - make entire protocols re-includable ## Option 2 Make the VRF inline of the current routing protocol * `set protocols ospf vrf <vrf> default-information` * `set protocols ospf vrf <vrf> area` * `set protocols ospf vrf <vrf> ...` * `set protocols ospfv3 vrf <vrf> default-information` * `set protocols ospfv3 vrf <vrf> area` * `set protocols ospfv3 vrf <vrf> ...` * `set protocols bgp <asn> vrf <vrf> neighbor x.x.x.x` * `set protocols bgp <asn> vrf <vrf> address-family ipv4-unicast ...` **PROS:** - matches the current CLI design for dynamic routing - all contained under one, per protocol node **CONS:** - to many nesting levels ## Option 3 No per VRF dynamic routing Just kidding - this is no option at all! # Summary From a programmers point of view option 2 should be preferred as it's less invasive. Given the fact that this will happen on the 1.4 current unstable branch invasive changes are totally fine given the current level of smoketests available. From a user point of view I feel option 1 should be the option of choice. Please comment and help with the CLI design and wishes. Given the fact that now all protocols are in good XML/Python shape implementation is rather easy now.