1. Introduction

Purpose of the document

  • Blueprint/Feature Lead: Mahesh Sivakumar
  • Core team: contacts to the core team members
  • Jira epic ticket: Unable to locate Jira server for this macro. It may be due to Application Link configuration.

2. Problem statement

Service-Chaining between a Source VN (SVN) and Destination VN (DVN) works by re-originating interested DVN routes into the SVN using a Service Instance Interface (SVI) as the next-hop. This causes traffic to be steered through the service chain as desired. These service-chain routes are classic inet[6] routes that get replicated into bgp.l3vpn[6].0 table and then into remote inet[6] tables using the bgp inet[6]-vpn address-family.

Today, when we set up a service chain between two virtual networks and re-originate the interested DVN routes, we reset the AS Path attribute of the service-chain routes. That is not the case for other BGP attributes (such as community tags). 

This is expected and is default behavior. The customer here, however, wants to have the flexibility to not follow the default behavior and instead retain the AS Path attribute across the service chain. Accordingly, the requirement is to provide a knob that will allow AS Path to be maintained through a service chain. 

3. Proposed solution

The solution to the problem is to provide a knob to control the reset of AS Path attribute in the service-chain routes.

3.1 Affected Modules

  • Configuration System (schema transformer)
  • Control Plane (Control Node)
  • UI

3.2 Alternatives considered

There are two options when it comes to the granularity at which a knob can be provided.

  1. At global level 
    1. this will apply to re-originated paths in all service-chains
    2. simpler solution but generic and does not allow some service-chains to have a different behavior
  2. Knob per service-chain - this can be tuned to apply to a specific set of service-chains
    1. This is a bit more involved and will need changes in schema, config (schema-transformer), control-node and UI
    2. However, this will provide the ability to change the behavior at the granularity of a service-chain

Given that the second option gives more flexibility that can be achieved at a relatively increase in complexity, we’ll go with it as the chosen solution.

Having decided on the granularity of the knob, the next task is to identify where in the schema the capability will be added. There are three potential options here.

  1. Knob as part of the service-template configuration
    1. Having a knob in the service template will enable all service instances using this template to have this knob enabled
    2. This would mean that to have a service chain use this knob, we will need to have all the service instances in the service-chain to use a service template that has the knob enabled
  2. Knob as part of the service-instance configuration
    1. This will enable all service chains using the service-instance to enable the capability
    2. To achieve the end goal the user will have to configure the knob in all the service instances used by a service chain
  3. Knob as part of the network-policy configuration
    1. The above two cases would not work when two service chains share one or more service instances and each of those service chains need a different behavior with respect to the newly introduced knob. To overcome this, the user will have to configure separate service instances for the two service chains.
    2. Further, in the second solution, the user will need to configure the knob on all service instances used by the service chain needing the capability
    3. The third option allows the knob to be enabled at the granularity of a service-chain by providing the capability in the network policy that defines the service chain

Given the advantages of option 3, we’ll go ahead with this option and allow the capability to be enabled as part of the network-policy definition.

3.3 API schema changes

Schema changes are required at two levels

A new knob will be introduced as part of the actions that can be taken on a network policy defining a service chain to indicate the need to retain the AS Path. Currently, the action allows a list of service instances to be added representing the list of instances that will be traversed when a packet is sent from the source VN to the destination VN.

As part of the service-chain-info defined for each service-instance, the above knob will translate into a boolean to indicate to the control-node whether the capability is enabled. This is the actual information that is consumed by the control-node.

3.4 User workflow impact

Describe how users will use the feature.

3.5 UI changes

‘Retain AS Path’ should show up under Advanced Options only when an input is provided in ‘Services’. 

As defined in the network policy schema above, this property, if set, should be sent as part of action-list under service-properties.

3.6 Operations and Notification impact

Describe how to operate the feature, describe the operational impact, describe any log, UVE, alarm changes

4. Implementation

4.1 Assignee(s)

List dev and test assignments

4.2 Work items

In order to implement the solution and provide a knob per service-chain, changes are required to the following components and are described below.

Control-Node

In order to allow communication between the VNs but require that traffic between the VNs go through, for instance, a firewall, we’ll need to create a service-chain by enabling a Service Instance (SI) (that hosts the firewall) and directing all traffic between the VNs to traverse the service chain.

In this case, there is no link created between the VNs. Instead,  in addition to the default RI, ST also creates one or more Service-RIs (S-RIs) in each VN. The number of S-RIs in the VN will correspond to the number of SIs in the service-chain. In the above example, since we only have one SI (for enabling a firewall) in the service-chain there will only be one S-RI (RIred’ for VN-Red and RIgreen’ for VN-Green) created for each VN. To this S-RI, it also attaches a Service Chain Info (SCI) property which contains a bunch of information including the Source RI, Destination RI and the SI (next-hop IP address of the Left IF) to be traversed among other things. The purpose of the SCI is to enable control-nodes to re-originate all routes from the Destination VN into the Source VN RI and steer traffic from the Source VN to the Destination VN through the service-chain.

In the control-node, the following changes are required

  • Config handling for new knob

The knob introduced in the network policy will translate into a capability in the service routing-instances of a service chain in the form of a bit in the service RIs created for the service chain.

With the introduction of the knob, we need changes in the config handling module to handle the new information coming as part of the service RIs and store it locally for each service chain.

  • Route re-origination module changes

In order to provide the new capability, the service chain re-origination module will be enhanced to not reset the AS Path attribute when re-originating routes from the destination VN to the source VN. This needs to be done for every service instance in the service-chain. If the knob is not enabled, the module will retain the default behavior and reset the AS Path attribute of the service chain routes. When the knob is configured, the control-node will not reset the AS Path attribute when re-originating a route from the destination VN to the source VN.


Config Node (Schema Transformer)

Schema Transformer will retrieve retain_as_path from Policy rule object and update it in the service-chain info so Controller can further process the info.

From:

Service Name → Virtual Network → Network Policy → Policy Rule → action_list → service-properties → retain_as_path

To:

Service Name → Virtual Network → Routing Instance → Service Chain Info → retain_as_path

Assumption: Since the retain_as_path attribute is available in a Policy Rule, we’re assuming that there will be only one policy-rule per service per virtual-network. This is to ensure that retain_as_path does not get overwritten by other policy-rules.


5. Performance and scaling impact

5.1 API and control plane

Scaling and performance for API and control plane

5.2 Forwarding performance

N/A

6. Upgrade 

Describe the upgrade impact of the feature. Schema migration/transition

7. Deprecations

If this feature deprecates any older feature or API then list it here.

8. Dependencies

Describe dependent features or components.


9. Testing

9.1 Unit tests

9.2 Dev tests

9.3 System tests

10. Documentation Impact

11. References


  • No labels