[{"author": "Cheng Li", "text": "

Ni hao

", "time": "2026-03-20T06:02:00.000Z"}, {"author": "Joel Halpern", "text": "

Are we confident that either this is the only use case that will need the last SID entry, or that all the use cases for that are mutually exclusive?

", "time": "2026-03-20T06:10:25.000Z"}, {"author": "Bruno Decraene", "text": "

very good point. Could you raise it to the list for tracking this dicussion?

", "time": "2026-03-20T06:12:06.000Z"}, {"author": "Joel Halpern", "text": "

Yeah, I can send the question to the list.

", "time": "2026-03-20T06:12:45.000Z"}, {"author": "Cheng Li", "text": "

nice\uff01good question\uff01

", "time": "2026-03-20T06:14:18.000Z"}, {"author": "Zafar Ali", "text": "

Why PSID needs a special treatment - Why can it not rely solely on the END.PSID behavior code (like any other SID we have defined thus far).

", "time": "2026-03-20T06:14:18.000Z"}, {"author": "Yao Liu", "text": "

@zafar, because PSID is carried in the last entry ,if there's no indication of the presence of the data in the last entry , nodes won't look at last entry to get the SID to know it's a PSID

", "time": "2026-03-20T06:19:32.000Z"}, {"author": "Andrew Stone", "text": "

I thought Path segment was always for egress/terminating node - is there use cases of using psid on transit nodes?

", "time": "2026-03-20T06:19:37.000Z"}, {"author": "Andrew Stone", "text": "

like is a transit node actually going to dig into the stack looking for this for ___ reasons__ ?

", "time": "2026-03-20T06:20:03.000Z"}, {"author": "Zafar Ali", "text": "

Why is it carried in the last entry? It has a LOC which is the Egress node.

", "time": "2026-03-20T06:20:13.000Z"}, {"author": "Adrian Farrel", "text": "

AFAICS 9545 does not mandate PSID is BoS

", "time": "2026-03-20T06:21:41.000Z"}, {"author": "Zafar Ali", "text": "

There must not be a usecase for transit nodes to look at the PSID. SRv6 runs on IPv6 data plane, which provide other routing headers (like HBH).

", "time": "2026-03-20T06:22:11.000Z"}, {"author": "Adrian Farrel", "text": "

There would, surely, be cases where you want the BoS LSE to be indicating what to do wih the payload (a la VPN)

", "time": "2026-03-20T06:22:13.000Z"}, {"author": "Zafar Ali", "text": "

Why the PSID and VPN SIDs can be back to back (two local SIDs)

", "time": "2026-03-20T06:23:49.000Z"}, {"author": "Andrew Stone", "text": "

yeah so if it's only for the end node and not the transit, that node is already reading that full SID anyways so does the flag-add-a-shortcut to identify really save a lot ?

", "time": "2026-03-20T06:30:21.000Z"}, {"author": "Nat Kao", "text": "

Can we put PSID at SRH[n] and we set SL=n-1 at the ingress PE?

", "time": "2026-03-20T06:31:51.000Z"}, {"author": "Zafar Ali", "text": "

It does not - it just breaks the architecture

", "time": "2026-03-20T06:31:58.000Z"}, {"author": "Cheng Li", "text": "

yes\uff0c a flag can save the cosf of procession. Because the intermediate endpoint.l nodes do not know if a PSID is included

", "time": "2026-03-20T06:32:15.000Z"}, {"author": "Andrew Stone", "text": "

but why does the intermediate nodes need to know/care if this is still only for egress

", "time": "2026-03-20T06:32:34.000Z"}, {"author": "Zafar Ali", "text": "

@chengli why intermediate nodes need to look into the PSID?

", "time": "2026-03-20T06:32:55.000Z"}, {"author": "Joel Halpern", "text": "

Speaking personally, it seems to me that if intermediate nodes may need to see this, that would argue strongly for using a TLV instead.

", "time": "2026-03-20T06:33:12.000Z"}, {"author": "Zafar Ali", "text": "

@joel Alternatively: SRv6 runs on IPv6 data plane, which provide other routing headers (like HBH) for transit node processing.

", "time": "2026-03-20T06:34:33.000Z"}, {"author": "Cheng Li", "text": "

we explained it in the draft. For the current stage, we will not define it in this draft. But we do open the opportunity for future use cases

", "time": "2026-03-20T06:35:00.000Z"}, {"author": "Cheng Li", "text": "

This is not a solution comparing with HBH. It is more like a fixed length, fixed location of a SRH TLV.

", "time": "2026-03-20T06:35:50.000Z"}, {"author": "Andrew Stone", "text": "

is that cart before horse? We need transit nodes to read this fast, so we want it in the flags. But, we are not defining the transit use case solution right now (?)

", "time": "2026-03-20T06:35:52.000Z"}, {"author": "Cheng Li", "text": "

In my understanding, transit is not an appropriate word in our discussion. Intermediate endpoint node should be more appropriate

", "time": "2026-03-20T06:36:47.000Z"}, {"author": "Cheng Li", "text": "

This is not an new draft, I assume that we are familiar with the content:grinning:

", "time": "2026-03-20T06:37:49.000Z"}, {"author": "Andrew Stone", "text": "

fair enough, i'm guilty of not reading it all but in general zafars comments about no other SID needing this really does raise the eye brow

", "time": "2026-03-20T06:38:22.000Z"}, {"author": "Zafar Ali", "text": "

What is \"Intermediate endpoint node\" you mean endpoint node

", "time": "2026-03-20T06:38:40.000Z"}, {"author": "Andrew Stone", "text": "

if the node(s) involved already deal with existing Srv6SIDs today, and didn't need a fast-to-read-flag, then considering all of the different SID types already why this one needs it is unclear to me

", "time": "2026-03-20T06:39:15.000Z"}, {"author": "Cheng Li", "text": "

the endpoint nodes associated with the SID in the segment list(except the last one)

", "time": "2026-03-20T06:39:27.000Z"}, {"author": "Guanming Zeng", "text": "

draft for the first pre: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-path-segment/

", "time": "2026-03-20T06:39:39.000Z"}, {"author": "Zafar Ali", "text": "

This discussion happened in 6man with similar comments.

\n

I do not have any record of how this made to draft-ietf at Spring?

", "time": "2026-03-20T06:40:30.000Z"}, {"author": "Zafar Ali", "text": "

6man doc was an individual doc and it remained at that state

", "time": "2026-03-20T06:40:56.000Z"}, {"author": "Yao Liu", "text": "

endpoints

", "time": "2026-03-20T06:42:42.000Z"}, {"author": "Andrew Stone", "text": "

\"Some use cases may require all the segment nodes along the path to process the PSID.\"

\n

it seems to me the \"some use cases\" is currently a bit too wide

", "time": "2026-03-20T06:46:08.000Z"}, {"author": "Andrew Stone", "text": "

perhaps that might help figure out if the fast-flag lookup is really needed

", "time": "2026-03-20T06:46:36.000Z"}, {"author": "Andrew Stone", "text": "

the last 2 lines in section 4 also make it sounds like its being added but may not actually be used

", "time": "2026-03-20T06:47:31.000Z"}, {"author": "Yao Liu", "text": "

When monitoring the srv6 traffic flows in some of the intermediate endpoints,and exporting the flow records, path segment may help with the identifying the path

", "time": "2026-03-20T06:47:53.000Z"}, {"author": "Cheng Li", "text": "

@yao Liu :+1:

", "time": "2026-03-20T06:48:31.000Z"}, {"author": "Zafar Ali", "text": "

what is an \"intermediate endpoints\" - you mentioned it is endpoint above.

\n

So its a local SID for the endpoint.

", "time": "2026-03-20T06:49:12.000Z"}, {"author": "Zafar Ali", "text": "

If there is a need to export flow records, we have methods already available (iOAM, HBH)

", "time": "2026-03-20T06:50:46.000Z"}, {"author": "Andrew Stone", "text": "

am i correct that in MPLS case (for example), there's also no special identifier? like for an entropy label we can identify it but not in the MPLS case? so wouldn't this be similar here anyways (Except it's the 128 bits)

", "time": "2026-03-20T06:51:13.000Z"}, {"author": "Andrew Stone", "text": "

*** but can't identify path segment in mpls

", "time": "2026-03-20T06:51:31.000Z"}, {"author": "Yao Liu", "text": "

one of the usecase https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-path-segment/

", "time": "2026-03-20T06:51:58.000Z"}, {"author": "J\u00e1nos Farkas", "text": "

We hear you fine remote Ketan

", "time": "2026-03-20T06:52:57.000Z"}, {"author": "Ketan Talaulikar", "text": "

To answer Dhruv. This is related to the SPRING SRv6/MPLS interworking and the SRv6OPS migration/interworking draft .... both WG drafts. There is a BGP extension to make that happen waitig for adoption in IDR. So Sue is pushing that since there is an operator ask/push to do that. I hope it clarifies the point.

", "time": "2026-03-20T06:54:10.000Z"}, {"author": "Yao Liu", "text": "

@zafar you're right with the terminology , it should be Segment Endpoint Node not \"intermediate endpoints

", "time": "2026-03-20T06:55:54.000Z"}, {"author": "Andrew Stone", "text": "

For the ipfix draft, skimming it -> as it says for MPLS interpretation that a given label is a PSID (or a node sid, adj sid, bsid for that matter) - the collector needs to interpret and correlate that.

\n

But for SRv6 it's explicitly trying to tag it the metering process.

\n

So an implementation doing MPLS needs to do more gymnastics, but for SRv6 it's giving it shortcut.

\n

is that a fair summary ?

", "time": "2026-03-20T06:58:32.000Z"}, {"author": "Dhruv Dhody", "text": "

thanks for clarifying ketan

", "time": "2026-03-20T06:58:33.000Z"}, {"author": "Yao Liu", "text": "

@andrew yes, and exporting the whole segment list in SRH is not always the best way

", "time": "2026-03-20T07:01:45.000Z"}, {"author": "Martin Horneffer", "text": "

I think Sue hits a very good point: aren't we having too many intended protocol extensions?
\nReminds me of a recent LinkedIn posting that related Braess's paradox from road building to product development. Could this also be true for protocol development?

", "time": "2026-03-20T07:03:34.000Z"}, {"author": "Tony Przygienda", "text": "

what's the paradox?

", "time": "2026-03-20T07:03:51.000Z"}, {"author": "Martin Horneffer", "text": "

https://en.wikipedia.org/wiki/Braess%27s_paradox and https://www.linkedin.com/posts/activity-7437120520661331969-GHVB

", "time": "2026-03-20T07:04:14.000Z"}, {"author": "Ketan Talaulikar", "text": "

Sue is talking about the discussion on the SPRING WG on whether SLs are scoped to a specific CP under a specific Policy or are shared across SR Policies.

", "time": "2026-03-20T07:04:22.000Z"}, {"author": "Martin Horneffer", "text": "

building a new road _can_ make overall traffic worse.

", "time": "2026-03-20T07:04:26.000Z"}, {"author": "Martin Horneffer", "text": "

@Ketan: yes, just her list made me thin further.

", "time": "2026-03-20T07:04:54.000Z"}, {"author": "Tony Przygienda", "text": "

yepp, that one. funny but true

", "time": "2026-03-20T07:04:55.000Z"}, {"author": "Ketan Talaulikar", "text": "

@Martin we miss you coming up to the mike and saying this :-)

", "time": "2026-03-20T07:05:14.000Z"}, {"author": "Martin Horneffer", "text": "

couldn't put this into words fast enough.

", "time": "2026-03-20T07:05:28.000Z"}, {"author": "Tony Przygienda", "text": "

I see it more as basically pumping unstructured complexity into the whole control plane w/o strong architecture holding the stuff together. to understand what that means one has to be familiar with ISO31000 and some graphs on mission failures by NASA and correlation with unmanaged complexity ;-)

", "time": "2026-03-20T07:06:51.000Z"}, {"author": "Martin Horneffer", "text": "

it's definitely about whether the sum of proton extension create too much overall complexity.can this be broken down into the cost in terms of complexity that each proposal brings, and relate this to its individual benefit?

", "time": "2026-03-20T07:08:17.000Z"}, {"author": "Joel Halpern", "text": "

This strongly reminds me of the NSH proof-of-transit taht was rejected as far too complex for the benefit. Even when the operator was a financial backbone.

", "time": "2026-03-20T07:09:40.000Z"}, {"author": "Zafar Ali", "text": "

remote can hear well

", "time": "2026-03-20T07:12:32.000Z"}, {"author": "Ketan Talaulikar", "text": "

@meetecho the voice from remote to room is low

", "time": "2026-03-20T07:12:35.000Z"}, {"author": "J\u00e1nos Farkas", "text": "

Hear Greg remote

", "time": "2026-03-20T07:12:41.000Z"}, {"author": "Greg Mirsky", "text": "

https://datatracker.ietf.org/doc/draft-ietf-sfc-proof-of-transit/08/

", "time": "2026-03-20T07:13:39.000Z"}, {"author": "Adrian Farrel", "text": "

IIRC the problem was not the trace element but the proof

", "time": "2026-03-20T07:15:49.000Z"}, {"author": "Joel Halpern", "text": "

is this a request to explicitly violate the trust domain boundary requirement?

", "time": "2026-03-20T07:15:51.000Z"}, {"author": "Joel Halpern", "text": "

Does the draft state that the multi-domain is within one operator? Or is this intended for itner-operator usage?

", "time": "2026-03-20T07:25:58.000Z"}, {"author": "Adrian Farrel", "text": "

+1 Joel. Jeff T and I were just whispering that to each other

", "time": "2026-03-20T07:33:32.000Z"}, {"author": "Ketan Talaulikar", "text": "

@Dhruv is this SRv6OPS ?

", "time": "2026-03-20T07:38:03.000Z"}, {"author": "Adrian Farrel", "text": "

Alvaro who?

", "time": "2026-03-20T07:38:45.000Z"}, {"author": "Dhruv Dhody", "text": "

Booking my ferry tickets

", "time": "2026-03-20T07:38:57.000Z"}, {"author": "Dhruv Dhody", "text": "

oops

", "time": "2026-03-20T07:39:05.000Z"}, {"author": "Feng Yang", "text": "

@Zafar, Thanks for your quesion. We suggest to use the SID as source address, such as ping, trace. a quick look at your draft, I guess you propose use VPN SID as well?

", "time": "2026-03-20T07:39:11.000Z"}, {"author": "Ketan Talaulikar", "text": "

everyone is booking their ferry tickets :rolling_on_the_floor_laughing:

", "time": "2026-03-20T07:39:30.000Z"}, {"author": "Adrian Farrel", "text": "

Or paying the ferryman?

", "time": "2026-03-20T07:39:41.000Z"}, {"author": "Zafar Ali", "text": "

No, use of VPN SID as a source address has an issue with ICMP error processing.

", "time": "2026-03-20T07:40:41.000Z"}]