[spring] Re: Seeking WG Consensus on PSID Encoding Options for draft-ietf-spring-srv6-path-segment

[linchangwang <[e-mail]>]

Hi WG，
Option 1: Dedicated P-flag (Current Draft Approach)
It is recommended to adopt Option 1, as it is simple and clear, and this draft has always been stable.

Moreover, as a vendor, we have already implemented Option 1 and have deployed it in practice.
Currently, only one flag is being used. Is it too early to consider the issue of insufficient flags?


Thanks,
Changwang

发件人: zengguanming <zengguanming=[e-mail]>
发送时间: 2026年3月15日 15:27
收件人: [e-mail]
抄送: spring Chairs <[e-mail]>; [e-mail]; Cheng Li <[e-mail]>; [e-mail]
主题: [spring] Re: Seeking WG Consensus on PSID Encoding Options for draft-ietf-spring-srv6-path-segment


Hi all,

Sorry for being late for uploading the new version of draft for draft-ietf-spring-srv6-path-segment<https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-path-segment/>, which corresponds to the presentation slot “Path Segment Identifier (PSID) in SRv6 (Segment Routing in IPv6)” in IETF125 spring meeting. Mainly, the version-15 delivers the option 2 (G-flag) to replace the option 1(P-flag). And the attached file highlights the difference between the latest version-15 and version-14.
Best regards,
Guanming


发件人: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
发送时间: 2026年3月11日 17:39
收件人: zengguanming <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Cheng Li <[e-mail]<mailto:[e-mail]>>
抄送: spring Chairs <[e-mail]<mailto:[e-mail]>>
主题: RE: Re:[spring] Seeking WG Consensus on PSID Encoding Options for draft-ietf-spring-srv6-path-segment

Dear Guanming & Cheng,

Many thanks for your effort to bring the WG in the loop, and for considering and opening multiple options. This is extra work, but I believe WG discussion and input may benefit the document/solution and help progressing the document.
Plan looks good to me.

May I suggest sending an email on the list when the new draft is published, highlighted the changes made?
Indeed, in the rush of the meeting, some people may have read the current (-14) version in the plane and miss reading the revised one.

Best regards,
CU in Shenzhen.
--Bruno
From: zengguanming <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, March 10, 2026 8:09 AM
To: DECRAENE Bruno INNOV/NET <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: spring Chairs <[e-mail]<mailto:[e-mail]>>; Cheng Li <[e-mail]<mailto:[e-mail]>>
Subject: RE: Re:[spring] Seeking WG Consensus on PSID Encoding Options for draft-ietf-spring-srv6-path-segment

Dear Bruno,

Thank you for your effort and help in this work group discussion.

We have prepared a new version of the draft mainly focused on option2, which will be uploaded to IETF website on 3.14. In addition, we have successfully requested a slot in IETF125 spring meeting to continue this discussion. We look forward to seeing you in Shenzhen next week. :)

Best regards,
Guanming & Cheng

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 17, 2026 7:18 PM
To: [e-mail]<mailto:[e-mail]>
Cc: spring Chairs <[e-mail]<mailto:[e-mail]>>
Subject: RE: Re:[spring] Seeking WG Consensus on PSID Encoding Options for draft-ietf-spring-srv6-path-segment

Dear Guanming, Cheng, authors

Thank you for your below email bringing the question to the SPRING WG, though a clear well-defined set of options. Much useful step in my opinion.
It triggered interest and replies from WG participants which is very good.
On top of that, all responders seem to be aligned on what they believe is the best option.
Couldn’t be better from my perspective.

At some point (this point?) I guess that the next step could be:

-          To update the draft (either with this option or a couple of options, depending on how much you believe WG feedback is strong enough). FYI, on my side, only keeping a single option in the draft would work and probably help in getting more and better reviews. But up to you.

-          Present the below options and the proposed path/solution to the WG during a SPRING meeting. Indeed, this is a SPRING WG document, and this represent a significant change to the document. And SPRING meeting are primarily for progressing WG documents. I would have a preference for the draft to be updated before such presentation such that the WG can read, review and discuss the latest specification.

Timing is up to you. If you believe this could be done for next meeting in March, please ask for a meeting slot and we would likely prioritize your slot request. If not, no problem on my side, and July meeting could also work. (I very much prefer good work and real progress than hurrying and noise)

Thanks,
Best regards,
--Bruno



---- Replied Message ----
From

zengguanming<zengguanming=[e-mail]> <mailto:zengguanming=[e-mail]>

Date

01/23/2026 16:16

To

SPRING WG List<[e-mail]> <mailto:[e-mail]>

Cc

Cheng Li<[e-mail]> ,
<mailto:[e-mail]>[e-mail]<[e-mail]> ,
<mailto:[e-mail]>DHRUV DHODY<[e-mail]> ,
<mailto:[e-mail]>chengweiqiang<[e-mail]> ,
<mailto:[e-mail]>[e-mail]<[e-mail]> <mailto:[e-mail]>

Subject

[spring] Seeking WG Consensus on PSID Encoding Options for draft-ietf-spring-srv6-path-segment

Dear SPRING WG,
As part of our ongoing effort to finalize the encoding mechanism for the SRv6 Path Segment Identifier (PSID) in https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-path-segment/, we would like to present three high-level approaches—along with their sub-options—for community review and consensus. Thanks to Bruno’s constructive review, comments and thorough discussion, we finally come up with the following options and present to the WG:

________________________________
Option 1: Dedicated P-flag (Current Draft Approach)
Mechanism: Introduce a new SRH flag (e.g., P-flag) solely to indicate that SRH. SegmentList[Last Entry] carries a PSID.
Pros: Simple, unambiguous, and enables per-packet fast-path processing for precise OAM (e.g., loss measurement).
Cons: Consumes one of only eight SRH flags for a single function.

Option 2: Generic Metadata Flag (Recommended Evolution)
Mechanism: Define a generic SRH flag (e.g., G-flag) that signals the presence of a structured 128-bit sid in SegmentList[Last Entry]. The opcode is defined to distinguish different use cases, for example:
•    OpCode=0x01: Path Segment ID (PSID)
•    OpCode=0x02: In-situ OAM trace data
•    OpCode=0x03: Custom telemetry payload
Pros:
•    One generic flag supports multiple future extensions, thus addresses “resource waste” concern by making the flag generically useful.
•    Maintains high-performance, per-packet processing.
Cons: Slightly more complex: requires defining opcode semantics and extensibility model.

Option 3: No New Flag
This has three sub-options:
3A: Reuse O-flag
Mechanism: Use the existing OAM flag to signal PSID presence.
Pros:
•     No SRH flags consumption.
Cons:
•     O-flag implies slow-path, sampled OAM treatment (per RFC 8754), but PSID often requires fast-path, per-packet handling for accurate end-to-end metrics. Mismatch in processing model risks under-serving key use cases.

3B: Flag-less (Pure SID Convention)
Mechanism: Rely solely on the END.PSID behavior code (Function = 0x0064); no flag needed. PSID is placed at SegmentList[n] where n = SRH.LastEntry.
Pros:
•    Minimalist design; No SRH flags consumption.
Cons:
•    No visibility for intermediate nodes—limits future telemetry or policy enforcement.
•    Functionally restricted to egress-only use cases (e.g., basic path binding), losing the full programmability advantage of SRv6.

3C: Flag-less with Dedicated PSID Prefix
Mechanism:
·         Reserve a well-known, non-routable IPv6 prefix (e.g., ::/32) for PSIDs.
·         Intermediate SR Endpoint nodes inspect SegmentList[n] and recognize PSID by prefix match.
Pros:
·         No SRH flag consumption.
·         Enables intermediate node visibility without a flag.
Cons:
·         SR nodes on the path needs one more mechanism to read PSID at Segment List[n], which introduces more complexity
________________________________
Next Steps
We believe Option 1(Dedicated P-flag) is simple, unambiguous, and enables per-packet fast-path processing for precise OAM, and Option 2 (Generic Flag) offers the best long-term balance: it conserves scarce flag space, supports future extensions (beyond PSID), and maintains performance.
And we kindly ask the WG to share your views on:
1.    Which direction best meets operational and architectural needs?
2.    Any strong objections to the proposed options.
Depending on feedback, we will update the draft accordingly and aim to request WGLC soon.
Thank you for your engagement!

Best regards,
Guanming Zeng & Cheng Li
Huawei




____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出的个人或群组。
禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。
如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above.
Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited.
If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!