-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Srv6 static config HLD #1860
base: master
Are you sure you want to change the base?
Changes from 18 commits
ed6c1c2
cb0a83d
2301048
100b3fc
7758034
906d87a
793e255
633fae3
c6f49cb
13720b9
bd92ca2
098a038
5fb2d75
833483b
3a8f49b
d0fcc74
21420cc
078dd6e
53c80e0
41d0cf2
81cc67d
fb20b35
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
@@ -0,0 +1,165 @@ | ||||
# Static Configuration of SRv6 in SONiC HLD | ||||
|
||||
# Table of Contents | ||||
|
||||
- [Revision](#revision) | ||||
- [Definition/Abbreviation](#definitionabbreviation) | ||||
- [About This Manual](#about-this-manual) | ||||
- [1 Introuduction and Scope](#1-introuduction-and-scope) | ||||
- [2 Feature Requirements](#2-feature-requirements) | ||||
- [2.1 Functional Requirements](#21-functional-requirements) | ||||
- [2.2 Configuration and Managment Requirements](#22-configuration-and-management-requirements) | ||||
- [2.3 Warm Boot Requirements](#23-warm-boot-requirements) | ||||
- [3 Feature Design](#3-feature-design) | ||||
- [3.1 New Table in ConfigDB](#31-new-table-in-configdb) | ||||
- [3.2 Bgpcfgd Changes](#32-bgpcfgd-changes) | ||||
- [3.3 YANG Model](#33-yang-model) | ||||
- [4 Unit Test](#4-unit-test) | ||||
- [5 References ](#5-references) | ||||
|
||||
# Revision | ||||
|
||||
| Rev | Date | Author | Change Description | | ||||
| :--: | :-------: | :------------------------: | :---------------------: | | ||||
| 0.1 | 12/5/2024 | Changrong Wu | Initial version | | ||||
|
||||
|
||||
# Definition/Abbreviation | ||||
|
||||
### Table 1: Abbreviations | ||||
|
||||
| ****Term**** | ****Meaning**** | | ||||
| -------- | ----------------------------------------- | | ||||
| BGP | Border Gateway Protocol | | ||||
| SID | Segment Identifier | | ||||
| SRv6 | Segment Routing IPv6 | | ||||
| SDN | Software Defined Network | | ||||
| uSID | Micro Segment | | ||||
| VRF | Virtual Routing and Forwarding | | ||||
|
||||
# About this Manual | ||||
|
||||
This document provides general information about the design of the enhancements in SONiC to support static configuration of Segmentation Routing over IPv6 protocol, which is crucial for SRv6 SDN deployment (without usage of BGP). | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit: |
||||
|
||||
# 1 Introuduction and Scope | ||||
|
||||
This document describes the high-level design of the new features in SONiC to support SRv6 SDN. | ||||
The new features include the addtion of a new table in CONFIG_DB to allow static configuration of SRv6 and the enhancement of bgpcfgd to program FRR with input from CONFIG_DB. | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hi @BYGX-wcr, thanks for the HLD to support SRv6 uSID static configuration. The static SRv6 uSID configuration model in FRR as follows:
In the current HLD, the configuration model is different and hence can’t be mapped to the current SRv6 uSID configuration model in FRR. To resolve this, I would propose the following:
FRR inherits the (block-len, node-len, func-bits) of the locator and install the static SID into SONiC APPL_DB via fpm-sonic-dplane. This is already mainline in FRR and SONiC. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The locator PR is added via sonic-net/sonic-buildimage#20954 to frrcfgd. The sample config db json could be found at There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @ahsalam: I understand the logic being used by SRV6_MY_LOCATOR. However our current config db schema is good enough to program FRR. We do not want indirection logic using 2 different config tables. If you see in below example we have all the information to program frr. We will parse ipv6 address and extract the opcode There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @ahsalam / @eddieruan-alibaba : We also planning to remove SONiC/doc/decap/subnet_decap_HLD.md Line 149 in 56a689c
SAI_MY_SID_ENTRY_ATTR_VRF .
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. DT46 will use default VRF. Our use case is not a typical L3VPN use case. |
||||
Besides, this document also define new YANG model specification and unit-test cases used to validate the aforementioned features. | ||||
|
||||
|
||||
# 2 Feature Requirements | ||||
|
||||
## 2.1 Functional Requirements | ||||
|
||||
Provide ability to statically configure SRv6 SIDs for block IDs, locators and local functions from CONFIG_DB. | ||||
|
||||
## 2.2 Configuration and Management Requirements | ||||
|
||||
1. User should be able to statically configure block length, locator length and function length for SRv6. | ||||
|
||||
2. User should be able to statically configure a number of SIDs/uSIDs for the local functions of the switch. | ||||
|
||||
## 2.3 Warm Boot Requirements | ||||
|
||||
Warm reboot is intended to be supported for planned system warm reboot. | ||||
|
||||
|
||||
|
||||
# 3 Feature Design | ||||
|
||||
At the time of writing this document, FRR has been able to program the SRv6 related tables in APPL_DB through fpmsyncd. | ||||
However, there is still one gap preventing SONiC being utilized for SRv6 SDN deployment. | ||||
Specifically, there is no mechamism in SONiC allowing SDN controllers or users to directly add configuration for SRv6 without involving BGP. | ||||
|
||||
In this document, we first define a new **SRV6_MY_SID_TABLE** table in CONFIG_DB that serves as the configuration source of SRv6 in SONiC. | ||||
Then, we design a new SRv6 Manager module in bgpcfgd to subscribe to the **SRV6_MY_SID_TABLE** table and compile changes in CONFIG_DB to changes in the configurations of FRR (Note: the new SRv6 Manager relies on the new configuration CLI brought in by [FRR PR#16894](https://github.com/FRRouting/frr/pull/16894)). | ||||
To verify the correctness of the aforementioned flow, we also define the relevant YANG model specification. | ||||
The workflow of the new mechanism is shown in the following diagram. | ||||
|
||||
![Static SRv6 Config flow](images/SRv6_bgpcfgd.png) | ||||
|
||||
The design details of each step is described in the following subsections. | ||||
|
||||
## 3.1 New Table in ConfigDB | ||||
|
||||
|
||||
**SRV6_MY_SID_TABLE** | ||||
|
||||
Description: New table to hold local SID definition and SID to behavior mapping. (A simplified redefinition of SRV6_MY_SID_TABLE in [SRv6_HLD](./srv6_hld.md)) | ||||
|
||||
Schema: | ||||
|
||||
``` | ||||
; New table | ||||
; holds local SID to behavior mapping, allow 1:1 or n:1 mapping | ||||
|
||||
key = SRV6_MY_SID_TABLE|ipv6address | ||||
; field = value | ||||
block_len = blen ; bit length of block portion in address, default 32 | ||||
node_len = nlen ; bit length of node ID portion in address, default 16 | ||||
func_len = flen ; bit length of function portion in address, default 16 | ||||
arg_len = alen ; bit length of argument portion in address, default 0 | ||||
action = behavior ; behaviors defined for the SID, default uN | ||||
vrf = VRF_TABLE.key ; Optional, VRF name for decapsulation actions, default "default", only applicable to uDT4/uDT46/uDT6 actions | ||||
dscp_mode = dscp_decap_mode ; Optional, the parameter that specifies how the node should handle DSCP bits when it performs decapsulation, default "uniform", only applicable to uDT4/uDT46/uDT6 actions | ||||
|
||||
For example: | ||||
"SRV6_MY_SID_TABLE" : { | ||||
"FCBB:BBBB:20::" : { | ||||
"action": "uN" | ||||
}, | ||||
"FCBB:BBBB:20:F1::" : { | ||||
"action": "uDT46", | ||||
} | ||||
} | ||||
``` | ||||
|
||||
Since SONiC and SAI do not have full support for every SRv6 behaviors, we plan to add supported SRv6 behaviors in the system gradually. | ||||
The current list of supported SRv6 behaviors allowed to be define in CONFIG_DB is as follows: | ||||
|
||||
| Alias | SRv6 Behaviors | | ||||
| :------ | :----- | | ||||
| uN | End with NEXT-CSID | | ||||
| uDT46 | End.DT46 with CSID | | ||||
|
||||
## 3.2 Bgpcfgd changes | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We're already using frrcfgd for SRv6, I would suggest to use frrcfgd for static SRv6 also for consistency, if there is any reason to use bpgcfgd, please state here. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hi Venkatsen, The primary reason is that we don't use frrcfgd in our daily operations. Since bgpcfgd has been leveraged to do static route configuration, we think it is not inappropriate to use bgpcfgd for static SRv6 configuration. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @eddieruan-alibaba FYI. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we discuss it in Routing WG? @BYGX-wcr @venkatmahalingam @lguohan There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, it would be helpful for the WG to understand/aware the new changes coming in for static SRv6. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Azure Networking has an event tonight starting at 6pm so I am unable to join this week's routing WG meeting. May we discuss this in next week's routing WG meeting? I can start an email thread about this topic. @venkatmahalingam, may you share your email address with me? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||||
|
||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you please capture the FRR configuration sample. It would be good if you can provide sonic field to FRR configuration mapping. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There is still some ongoing discussion on the details of the new FRR configuration CLI. We'd better add the config sample and mapping later. |
||||
To enable automatic programming SRv6 configurations from CONFIG_DB to FRR, we need to add a new module in bgpcfgd to watch changes in **SRV6_MY_SID_TABLE** and compile the corresponding changes in FRR's configurations. | ||||
Following the naming convention of modules in bgpcfgd, we call this new module SRv6 Manager. | ||||
The new SRv6 Manager are supposed to verify the validity of the configuration entries coming from the CONFIG_DB. | ||||
If it gets an invalid configuration input, it should log the event in the syslog and not compile the configuration into FRR. | ||||
|
||||
## 3.3 YANG Model | ||||
The simplified version of the YANG model is defined below. | ||||
``` | ||||
module: sonic-srv6 | ||||
+--rw sonic-srv6 | ||||
+--rw SRV6_MY_SID_TABLE | ||||
+--rw SRV6_MY_SID_TABLE_LIST* [ip_address] | ||||
+--rw ip_address inet:ipv6-address | ||||
+--rw block_len? uint8 | ||||
+--rw node_len? uint8 | ||||
+--rw func_len? uint8 | ||||
+--rw arg_len? uint8 | ||||
+--rw action? enumeration | ||||
+--rw vrf? -> /vrf:sonic-vrf/VRF/VRF_LIST/name | ||||
+--rw dscp_mode? enumeration | ||||
``` | ||||
Refer to [sonic-yang-models](https://github.com/sonic-net/sonic-buildimage/tree/master/src/sonic-yang-models) for the YANG model defined with standard IETF syntax. | ||||
|
||||
## 4 Unit Test | ||||
|
||||
|Test Cases | Test Result | | ||||
| :------ | :----- | | ||||
|add config for a SID with uN action in CONFIG_DB | verify the locator config entry is created in FRR config| | ||||
|add config for a SID with uDT46 action in CONFIG_DB | verify the opcode config entry is created in FRR config with default VRF| | ||||
|(Negative case) add config for a SID without action in CONFIG_DB | verify that the configuration did not get into FRR config | | ||||
|(Negative case) add config for a SID with an unsupported action in CONFIG_DB | verify that the configuration did not get into FRR config | | ||||
|delete config for a SID with uN action in CONFIG_DB | verify the locator config entry is deleted in FRR config| | ||||
|delete config for a SID with uDT46 action in CONFIG_DB | verify the opcode config entry for the uDT46 action is deleted in FRR config| | ||||
|
||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @BYGX-wcr : can we add some failure UT case also. What will happen if bgpcfgd gets exception and exited ? I assume bgp/swss/syncd docker restart and everything should get reprommed but lets add the test case to confirm. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you mean when bgpcfgd restarts, the SRv6 manager should retrieve all existing MY_SID config from CONFIG_DB and program them to FRR? |
||||
|
||||
## 5 References | ||||
|
||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we adding support only for end-point behaviors? how about steering the traffic to SRv6 at the head-end?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. Right now, we only intend to add support for end-point behaviors because the traffic steering is done on the NICs in our use scenarios.