Add Srv6 static config HLD #1860

BYGX-wcr · 2024-12-04T01:31:33Z

This PR proposes to add a High-level Design document for changes in SONiC to support static configuration of Segment-routing over IPv6. Besides, a YANG model specification for the new table in CONFIG_DB is also defined.

Implementation PRs:

Module	PR link
sonic-bgpcfgd	sonic-net/sonic-buildimage#21156
FRR	FRRouting/frr#16894
sonic-yang-models	sonic-net/sonic-buildimage#21175
sonic-swss-common	sonic-net/sonic-swss-common#962
sonic-swss	sonic-net/sonic-swss#3414
sonic-swss	sonic-net/sonic-swss#3443

doc/srv6/srv6_static_config_hld.md

abdosi · 2024-12-05T18:21:51Z

doc/srv6/srv6_static_config_hld.md

+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
+vrf = VRF_TABLE.key          ; Optional, VRF name for decapsulation actions


Let add comment applicable only for UDT46. If not define default VRF will be used.

doc/srv6/srv6_static_config_hld.md

abdosi · 2024-12-05T18:25:05Z

doc/srv6/srv6_static_config_hld.md

+arg_len = alen               ; bit length of argument portion in address, default 0
+action = behavior            ; behaviors defined for the SID
+vrf = VRF_TABLE.key          ; Optional, VRF name for decapsulation actions
+adj = address,               ; Optional, list of adjacencies for cross-connect actions


we can remove this as we are not planning to test it anyways. This can be extended. in future as needed.

doc/srv6/srv6_static_config_hld.md

dgsudharsan · 2024-12-10T05:24:39Z

doc/srv6/sonic-srv6.yang

+            }
+
+            leaf action {
+                type enumeration {


This might restrict the static configuration only for the 3 types below. Is the plan to support only these 3 types for now and later extend it?

Yes, currently we only plan to support these 3 types of action.

dgsudharsan · 2024-12-10T05:25:34Z

doc/srv6/srv6_static_config_hld.md

+
+
+## 3.2 Bgpcfgd changes
+


Can you please capture the FRR configuration sample. It would be good if you can provide sonic field to FRR configuration mapping.

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.

dgsudharsan · 2024-12-10T05:26:40Z

doc/srv6/srv6_static_config_hld.md

+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.


Need to mention about the sonic specific patch to support action field in FRR as by default FRR doesn't support it.

I added a note

abdosi · 2024-12-11T03:00:54Z

@dgsudharsan : Regarding supporting below requirement for DT46 End behavior do we need something like this in Config DB schema for MY_SID_TABLE ? We need OA to read this to create tunnel with the correct attribute. What do you suggest ?

                        TTL/DSCP/ECN Decap tunnel mode(pipe, uniform).

venkatmahalingam · 2024-12-11T04:16:13Z

doc/srv6/srv6_static_config_hld.md

+```
+
+
+## 3.2 Bgpcfgd changes


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.

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.

@eddieruan-alibaba FYI.

Should we discuss it in Routing WG? @BYGX-wcr @venkatmahalingam @lguohan

Yes, it would be helpful for the WG to understand/aware the new changes coming in for static SRv6.

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?

[email protected]

@eddieruan-alibaba
Has static SRv6 meeting happened? Is there a recording

https://lists.sonicfoundation.dev/g/sonic-wg-routing/wiki/38324

Recording: https://zoom.us/rec/play/4sa90QBJt9cpcjO1jAM6X-9BRH-ERgMQSDAk8LZEXsRRHmn9AIs_QnO7WB02cil2Hdr0Cn3AfdaZbyRT.-S6Tl6oAPV-kFHF5?canPlayFromShare=true&from=share_recording_detail&continueMode=true&componentName=rec-play&originRequestUrl=https%3A%2F%2Fzoom.us%2Frec%2Fshare%2FDnFbtO1WyAmfKtTn0S68frJvAKMoK3dBAzUfc0_TAsX_AaolkaBLfil_6639MG_o.2LvhKP2AmovknzBz

venkatmahalingam · 2024-12-11T04:24:11Z

doc/srv6/srv6_static_config_hld.md

+  +--rw sonic-srv6
+     +--rw SRV6_MY_SID
+     |  +--rw SRV6_MY_SID_LIST* [ip-address]
+     |     +--rw ip-address    inet:ipv6-address


Can't we have same ipv6 address exist across VRFs? should use VRF as a key instead of field in the table?

This table defines the MY_SID_LIST which should only have one instance in the current system. The VRF field is used to specify which VRF should be used for look up after the SRv6 functions decapsulates the packet. It is not used to specify which VRF the SID belongs to.

venkatmahalingam · 2024-12-11T04:35:18Z

doc/srv6/srv6_static_config_hld.md

+
+# 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).


Are we adding support only for end-point behaviors? how about steering the traffic to SRv6 at the head-end?

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.

venkatmahalingam · 2024-12-11T04:43:51Z

doc/srv6/sonic-srv6.yang

+
+            leaf action {
+                type enumeration {
+                    enum uN;


This means that you support only uSID not regular end.dt6, end.dt46..etc, correct?, we should mention clearly in the HLD that static SRv6 supports only uSID based handling now.

I added a table for the current list of supported behaviors. Feel free to extend the list after you add the necessary support and tests.

ahsalam · 2024-12-12T12:31:42Z

doc/srv6/srv6_static_config_hld.md

+# 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.


Hi @BYGX-wcr, thanks for the HLD to support SRv6 uSID static configuration.

The static SRv6 uSID configuration model in FRR as follows:

Configure an SRv6 locator and identify its parameters (name, prefix, block-len, node-len, func-bits). The CLI for this is already in FRR mainline.

Configure a static SRv6 SID under the SRv6 locator and identify its parameters (behavior, vrf, etc.). The CLI for this is being added in this FRR PR (staticd: Add support for SRv6 Static SIDs FRRouting/frr#16894)

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:

Create a new table (SRV6_MY_LOCATOR) for the SRv6 locator config and its parameters (name, prefix, block-len, node-len, func-bits).

In the SRV6_MY_SID_TABLE, you add the locator as new parameter for the SID. The locator parameter points to one of the locators in SRV6_MY_LOCATOR via the locator’s name. This way you can map the config to FRR config.

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.

The locator PR is added via sonic-net/sonic-buildimage#20954 to frrcfgd.

The sample config db json could be found at

https://github.com/sonic-net/sonic-mgmt/blob/master/ansible/vars/configdb_jsons/7nodes_cisco/PE3.json#L435

@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 prefix to FRR. Keeping one table in synch with APP_DB format is easier for us.

@ahsalam / @eddieruan-alibaba : We also planning to remove vrf from config db schema as our current use case is to use SAI_MY_SID_ENTRY_ATTR_TUNNEL_ID for uDT46 usecase. Currently Tunnel Decap Schema

SONiC/doc/decap/subnet_decap_HLD.md

Line 149 in 56a689c

### TUNNEL_DECAP_TERM_TABLE

does not support vrf for overlay interface so their is no point of specifying VRF as needed by SAI_MY_SID_ENTRY_ATTR_VRF.

DT46 will use default VRF. Our use case is not a typical L3VPN use case.

mssonicbld · 2025-01-04T00:19:28Z

/azp run

azure-pipelines · 2025-01-04T00:19:34Z

No pipelines are associated with this pull request.

dgsudharsan · 2025-01-04T00:32:36Z

@BYGX-wcr The addition of prefix field in the SRV6_MY_LOCATORS is for the completeness of locator definition and being consistent with FRR.

The reason why we decided to abandon Alibaba's single table design was because people complaint about the implicit semantics in the "opcode_data" field and difficulty in YANG validation. You can revisit the recording of Routing WG discussion to confirm that.

Yes, I'm aware of what we discussed in the last WG meeting, after looking at the pull requests you have created for this feature, I'm thinking we should not over-complicate the existing schema unless it provides some value, I have created following options; we can briefly discuss this if needed in the next WG call.

I was one the mentioning about "the difficulty in YANG validation" in the WG meeting, after looking at the changes you have made, I think, either we can continue to use the existing SRV6_LOCATOR table (Alibaba proposed) for static SRV6 as well (option1) and clean up later for easy YANG validation (option2) or do the option2 now itself.

Option1: (Short term) - Only if we think, Option 2 is not possible now given the timeline for this static SRv6 activity (yes, we are aware of the YANG validation issues, if needed, we can try custom YANG validation for time being)
 "SRV6_LOCATOR": {
        "lsid1": {
            "argu_len": "48",
            "block_len": "32",
            "func_len": "32",
            "node_len": "16",
            "opcode_prefix": [
                "::fff1:1:0:0:0",
                "::fff1:11:0:0:0"
            ],
            "opcode_act": [
                "end-dt46",
                "end-dt46"
            ],
            "opcode_data": [
                "vrf Vrf1",
                "vrf Vrf2"
            ],
            "prefix": "fd00:201:201::/48"
        }
    },
Option2: (Long term) -> This is aligned with IETF YANG (https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-yang#section-3.4.1) and we can do YANG validation better. We can choose appropriate table names if the below ones are not correct.
"SRV6_LOCATOR": {
       "lsid1": {
           "argu_len": "48",
           "block_len": "32",
           "func_len": "32",
           "node_len": "16",
           "sids":  sid1
           "prefix": "fd00:201:201::/48"
       },
   },
   SRV6_MY_SIDS_TABLE|sid1: {
   },
   "SRV6_MY_SIDS_OPCODE_TABLE": {
      "sid1|::fff1:1:0:0:0:" {
          "action" : end-dt46
          "vrf" : Vrf1
       },
      "sid1|::fff1:11:0:0:0" {
         "action" : end-dt46
         "vrf" : Vrf2
    },
  }
Option3: My understanding from the last WG meeting,
"SRV6_LOCATOR": {
        "lsid1": {
            "argu_len": "48",
            "block_len": "32",
            "func_len": "32",
            "node_len": "16",
            "prefix": "fd00:201:201::/48"
        },
    },
    "SRV6_MY_SIDS_TABLE": {
       "::fff1:1:0:0:0:" {
           "locator": lsid1
            "action" : end-dt46
           "vrf" : Vrf1
        },
       ":fff1:11:0:0:0:" {
           "locator": lsid1
            "action" : end-dt46
           "vrf" : Vrf2
        },
   }
but I see the below updates in the HLD. So, I see a problem (in general for option3) when any changes to the lsid1 entry can cause to remove the entire locator from FRR and re-add with updated locator and all its opcode commands (we may need to loop entire SRV6_MY_SIDS_TABLE as locator is not the key, also when anyone removes lsid1, we should make sure no stale entries in SRV6_MY_SIDS_TABLE pointing to lsid1, this is not possible with direct YANG validation, we may need custom validation). However, this is not a cleaner solution IMO. I prefer option2, if not, option1 for time being. Option3, not only inconsistent with current LOCATOR table (Alibaba proposed), also not a good long-term solution for a proper YANG validation.
"SRV6_LOCATOR": {
        "lsid1": {
            "argu_len": "48",
            "block_len": "32",
            "func_len": "32",
            "node_len": "16",
            "prefix": "fd00:201:201::/48"
        },
    },
    "SRV6_MY_SIDS_TABLE": {
       "fd00:201:201::fff1:1:0:0:0:" {
           "locator": lsid1
            "action" : end-dt46
           "vrf" : Vrf1
        },
       "fd00:201:201:fff1:11:0:0:0:" {
           "locator": lsid1
            "action" : end-dt46
           "vrf" : Vrf2
        },
   }

@venkatmahalingam Can you clarify why yang can't support back ref? Currently when locator table is removed the yang validation for my_sid table will fail as it points to a locator without reference. I believe option#3 aligns with other tables ACL rule has a reference to ACL table https://github.com/sonic-net/sonic-buildimage/blob/cb85ddb33f0a9e54e0e6a11635e04af489ee4d9e/src/sonic-yang-models/yang-templates/sonic-acl.yang.j2#L56

dgsudharsan · 2025-01-04T02:28:21Z

@BYGX-wcr @abdosi @venkatmahalingam The concern that Venkat raises whether the key of SRV6_MY_SID_TABLE is a unique key across locators or not. If not unique, it may lead to problems that you cannot have two locators pointed by the same my_sid entry. Please clarify if this is a valid use case or not.
If valid it makes sense to use option #2 but if this is not a valid use case option #3 makes sense.

@eddieruan-alibaba

mssonicbld · 2025-01-06T23:42:04Z

/azp run

azure-pipelines · 2025-01-06T23:42:09Z

No pipelines are associated with this pull request.

BYGX-wcr · 2025-01-06T23:43:36Z

Hi @dgsudharsan @venkatmahalingam ,

I have fixed the inconsistencies in the document per our discussions. I also added an example for the MY_LOCATORS table.

eddieruan-alibaba · 2025-01-07T17:21:03Z

@BYGX-wcr @venkatmahalingam @dgsudharsan I saw all parties have approved this PR. Do we still need to discuss three options listed in this week's WG?

eddieruan-alibaba · 2025-01-07T17:23:14Z

@BYGX-wcr @abdosi @venkatmahalingam The concern that Venkat raises whether the key of SRV6_MY_SID_TABLE is a unique key across locators or not. If not unique, it may lead to problems that you cannot have two locators pointed by the same my_sid entry. Please clarify if this is a valid use case or not. If valid it makes sense to use option #2 but if this is not a valid use case option #3 makes sense.

@eddieruan-alibaba

MY_SID is used similar as vpn label in MPLS logically. it should be unique at the local device.

venkatmahalingam · 2025-01-07T17:31:38Z

@BYGX-wcr @venkatmahalingam @dgsudharsan I saw all parties have approved this PR. Do we still need to discuss three options listed in this week's WG?

No, we're good @eddieruan-alibaba

eddieruan-alibaba · 2025-01-07T17:34:20Z

I merged this PR based on all the approval.

abdosi · 2025-01-07T18:32:26Z

@dgsudharsan : Please add OA PR in this PR description.

Yakiv-Huryk · 2025-01-08T18:50:00Z

@dgsudharsan : Please add OA PR in this PR description.

The PRs:
sonic-net/sonic-swss-common#962
sonic-net/sonic-swss#3414
sonic-net/sonic-swss#3443

BYGX-wcr · 2025-01-08T18:53:15Z

@dgsudharsan : Please add OA PR in this PR description.

The PRs: sonic-net/sonic-swss-common#962 sonic-net/sonic-swss#3414 sonic-net/sonic-swss#3443

Added

Adding FRR CLI to support SRv6 static. The HLD for the feature is available at sonic-net/SONiC#1860 Signed-off-by: Carmine Scarpitta <[email protected]>

#### Why I did it There is a motivation to add capabilities in SONiC that allows static configuration of SRv6 network. ##### Work item tracking - Microsoft ADO **(number only)**: 30251795 #### How I did it I added a SRv6 manager in Bgpcfgd that subscribes to SRV6_MY_LOCATORS and SRV6_MY_SIDS in CONFIG_DB and programs the changes to FRR's configuration. Note: this change depends on the availability and implementation details of the following FRR patch [FRR SRv6 Static SID CLI](sonic-net/sonic-buildimage#21380) #### How to verify it - Run unit tests - Build an image that contains this change and the relevant FRR CLI support. - Test the Image on a virtual device or physical device  #### Which release branch to backport (provide reason below if selected)  - [ ] 201811 - [ ] 201911 - [ ] 202006 - [ ] 202012 - [ ] 202106 - [ ] 202111 - [ ] 202205 - [ ] 202211 - [ ] 202305 #### Tested branch (Please provide the tested image version)  - [ ]  - [ ]  #### Description for the changelog   #### Link to config_db schema for YANG module changes  [SRv6 static config HLD](sonic-net/SONiC#1860) #### A picture of a cute animal (not mandatory but encouraged)

Adding FRR CLI to support SRv6 static. The HLD for the feature is available at sonic-net/SONiC#1860 Signed-off-by: Carmine Scarpitta <[email protected]>

Adding FRR CLI to support SRv6 static. The HLD for the feature is available at sonic-net/SONiC#1860

#### Why I did it There is a motivation to add capabilities in SONiC that allows static configuration of SRv6 network. ##### Work item tracking - Microsoft ADO **(number only)**: 30251795 #### How I did it I added a SRv6 manager in Bgpcfgd that subscribes to SRV6_MY_LOCATORS and SRV6_MY_SIDS in CONFIG_DB and programs the changes to FRR's configuration. Note: this change depends on the availability and implementation details of the following FRR patch [FRR SRv6 Static SID CLI](sonic-net/sonic-buildimage#21380) #### How to verify it - Run unit tests - Build an image that contains this change and the relevant FRR CLI support. - Test the Image on a virtual device or physical device  #### Which release branch to backport (provide reason below if selected)  - [ ] 201811 - [ ] 201911 - [ ] 202006 - [ ] 202012 - [ ] 202106 - [ ] 202111 - [ ] 202205 - [ ] 202211 - [ ] 202305 #### Tested branch (Please provide the tested image version)  - [ ]  - [ ]  #### Description for the changelog   #### Link to config_db schema for YANG module changes  [SRv6 static config HLD](sonic-net/SONiC#1860) #### A picture of a cute animal (not mandatory but encouraged)

Adding FRR CLI to support SRv6 static. The HLD for the feature is available at sonic-net/SONiC#1860 Signed-off-by: Carmine Scarpitta <[email protected]>

BYGX-wcr added 8 commits November 28, 2024 11:06

init draft of srv6_static_config_hld.md

ed6c1c2

add description for bgpcfgd changes and enrich the high-level picture

cb0a83d

add doc/srv6/images/SRv6_bgpcfgd.png

2301048

refine YANG model definition and add UT test cases

100b3fc

update contents

7758034

enrich UT cases and bgpcfgd changes' description

906d87a

add arg_len back for completeness and add one more UT case

793e255

add standard YANG model for srv6

633fae3

BYGX-wcr requested review from lguohan, rlhui, abdosi and kperumalbfn December 4, 2024 01:31

change uint16 to uint8 in YANG model

c6f49cb

abdosi reviewed Dec 5, 2024

View reviewed changes

doc/srv6/srv6_static_config_hld.md Outdated Show resolved Hide resolved

abdosi reviewed Dec 5, 2024

View reviewed changes

doc/srv6/srv6_static_config_hld.md Outdated Show resolved Hide resolved

abdosi reviewed Dec 5, 2024

View reviewed changes

doc/srv6/srv6_static_config_hld.md Outdated Show resolved Hide resolved

BYGX-wcr added 2 commits December 5, 2024 15:23

remove uA; define enum for actions; set default vrf value

13720b9

remove uA test cases

bd92ca2

dgsudharsan suggested changes Dec 10, 2024

View reviewed changes

add a note about the new FRR CLI

098a038

venkatmahalingam reviewed Dec 11, 2024

View reviewed changes

BYGX-wcr added 2 commits December 11, 2024 10:43

add a table for supported behaviors

5fb2d75

add dscp mode field in the SRV6_MY_SID_TABLE

833483b

ahsalam reviewed Dec 12, 2024

View reviewed changes

replace vrf with locator in the key combo of SRV6_MY_SIDS

11ac46c

fix typos and add an example for my locators table

c5b1b06

dgsudharsan approved these changes Jan 7, 2025

View reviewed changes

venkatmahalingam approved these changes Jan 7, 2025

View reviewed changes

eddieruan-alibaba approved these changes Jan 7, 2025

View reviewed changes

eddieruan-alibaba merged commit 589aca6 into sonic-net:master Jan 7, 2025
1 check passed

zhangyanzhao assigned BYGX-wcr Jan 8, 2025

cscarpitta mentioned this pull request Jan 10, 2025

FRR CLI for SRv6 static sonic-net/sonic-buildimage#21380

Merged

mssonicbld mentioned this pull request Jan 18, 2025

[action] [PR:21380] FRR CLI for SRv6 static Azure/sonic-buildimage-msft#527

Merged

mssonicbld added a commit to mssonicbld/sonic-buildimage-msft that referenced this pull request Jan 18, 2025

FRR CLI for SRv6 static

30c20cf

Adding FRR CLI to support SRv6 static. The HLD for the feature is available at sonic-net/SONiC#1860

mssonicbld mentioned this pull request Jan 20, 2025

[action] [PR:21156] Add SRv6 support in Bgpcfgd Azure/sonic-buildimage-msft#533

Open

11 tasks


		# 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).

Add Srv6 static config HLD #1860

Add Srv6 static config HLD #1860

Conversation

BYGX-wcr commented Dec 4, 2024 • edited Loading

abdosi Dec 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dgsudharsan Dec 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abdosi commented Dec 11, 2024

venkatmahalingam Dec 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

venkatmahalingam Dec 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

venkatmahalingam Dec 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abdosi Dec 12, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mssonicbld commented Jan 4, 2025

azure-pipelines bot commented Jan 4, 2025

dgsudharsan commented Jan 4, 2025

The reason why we decided to abandon Alibaba's single table design was because people complaint about the implicit semantics in the "opcode_data" field and difficulty in YANG validation. You can revisit the recording of Routing WG discussion to confirm that.

dgsudharsan commented Jan 4, 2025

mssonicbld commented Jan 6, 2025

azure-pipelines bot commented Jan 6, 2025

BYGX-wcr commented Jan 6, 2025

eddieruan-alibaba commented Jan 7, 2025

eddieruan-alibaba commented Jan 7, 2025

venkatmahalingam commented Jan 7, 2025

eddieruan-alibaba commented Jan 7, 2025

abdosi commented Jan 7, 2025

Yakiv-Huryk commented Jan 8, 2025

BYGX-wcr commented Jan 8, 2025

BYGX-wcr commented Dec 4, 2024 •

edited

Loading

abdosi Dec 5, 2024 •

edited

Loading

dgsudharsan Dec 10, 2024 •

edited

Loading

venkatmahalingam Dec 11, 2024 •

edited

Loading

venkatmahalingam Dec 11, 2024 •

edited

Loading

venkatmahalingam Dec 11, 2024 •

edited

Loading

abdosi Dec 12, 2024 •

edited

Loading