srv6: better json format for seg6_segs

[dmytroshytyi-6WIND]

Previous Json output contained lists of srv6 segments in the "segs" field. Now we do the "json struct in the json struct", i.e. "seg6->segs"

Before...
When we had 1 segment :

      "seg6local":{
        "action":"unspec"
      },
      "seg6":{
        "segs":"2001:db8:1:1:1::2"
      }

When we had multiple segments :

      "seg6local":{
        "action":"unspec"
      },
      "seg6":[
        "2001:db8:aaaa::7",
        "2002::2",
        "2003::3",
        "2004::4"
      ]

Now...
When we have multiple segments:

      seg6":{"segs":["fc00:0:3::","fc00:0:5::","fc00:0:6::"]}}]}

[ton31337]

Isn't this a breaking change?

[dmytroshytyi-6WIND]

ci:rerun

[dmytroshytyi-6WIND]

Isn't this a breaking change?

Hi @ton31337 , This changes only json for seg6 segs. No cli configuration impact. Is it considered as breaking change? As iproute has:

ENCAP_SEG6 := seg6 mode [ encap | encap.red | inline | l2encap | l2encap.red ] segs SEGMENTS [ hmac KEYID ]

In future new parameters might be added, like described above.
For example:
seg6":{"mode": inline, "segs":["fc00:0:3::","fc00:0:5::","fc00:0:6::"]}}]}

This change will prepare for future extensions.

[riw777]

looks good

[ton31337]

I meant that JSON breaking change. If it had a structure the people used for automation, and now it's different, then it's not good.

[choppsv1]

Is there an exisitng IETF yang model that we should be taking direction from? Also is the structure changing based on there being 1 vs N? This seems wrong, or are we switching to only use an array (which seems good)?

[dmytroshytyi-6WIND]

Is there an exisitng IETF yang model that we should be taking direction from? Also is the structure changing based on there being 1 vs N? This seems wrong, or are we switching to only use an array (which seems good)?

Hello, Thank you for your review.

I'm not aware of IETF RFC standardized YANG model for this behavior.

Let me give one more example.
Before

"seg6local":{
"action":"unspec"
},
"seg6":[
"2001:db8:aaaa::7",
"2002::2",
"2003::3",
"2004::4"
]

After

"seg6local":{
"action":"unspec"
},
"segs": { <<< this is added.
"seg6":[
"2001:db8:aaaa::7",
"2002::2",
"2003::3",
"2004::4"
],
"mode": "inline", <<<<< the above added section allows to set more parameters like this
}

Does this explain what this PR is intented to do better?

[pguibert6WIND]

The array is moved into a segs json entry.
maybe we can keep the original array, and copy it in the new segs json entry.
We run deprecation on the original array for one year. At this date, we will remove it.

[choppsv1]

Is there an exisitng IETF yang model that we should be taking direction from? Also is the structure changing based on there being 1 vs N? This seems wrong, or are we switching to only use an array (which seems good)?

Hello, Thank you for your review.

I'm not aware of IETF RFC standardized YANG model for this behavior.

Is this data represented in https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-yang-03

?

That's still a draft but it would be good to know we compared what we are doing to what is on the path to being standardized.

Thanks,
Chris.

[choppsv1]

Let me give one more example. Before

"seg6local":{ "action":"unspec" }, "seg6":[ "2001:db8:aaaa::7", "2002::2", "2003::3", "2004::4" ]

After

"seg6local":{ "action":"unspec" }, "segs": { <<< this is added. "seg6":[ "2001:db8:aaaa::7", "2002::2", "2003::3", "2004::4" ], "mode": "inline", <<<<< the above added section allows to set more parameters like this }

Does this explain what this PR is intented to do better?

Given the structure is completely changing are you also getting rid of the union of singleton vs array of SIDs? Are theese really "seg6"s or are they "SID"s?

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.