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

[[e-mail]]

Hi Yao, all,

Speaking as individual contributor.

Many thanks Yao for your review and feedback.

  *   And another concern on option 2 is that, if the last entry is used to carry different types of metadata, only one of them can be carried in the same SRH, they can never be used together.
This is a valid point.
But this seems a concern related to the choice of encoding the info in the last entry of the SRH, more than related to the SRH flag question.
By definition, there is a single “last entry” so using it for this use-case exclude other uses cases.

If your requirement is to not exclude other uses cases, the use of a more generic tool, e.g., SRH TLV might be a better fit. Has this been considered?

Regards,
--Bruno
From: [e-mail] <[e-mail]>
Sent: Wednesday, February 25, 2026 8:45 AM
To: zengguanming=[e-mail]
Cc: [e-mail]; [e-mail]; DECRAENE Bruno INNOV/NET <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [spring] Seeking WG Consensus on PSID Encoding Options for draft-ietf-spring-srv6-path-segment


Hi Guanming,



Thank you for putting this out.

I prefer the original option 1, it's simple and implementation friendly.

About option 2, I was wondering is there any strong usecase besides PSID that has to carry a 128-bit metadata at last entry? For the In-situ OAM trace data, RFC 9486 already defines HBH/DOH options for it, and for the custom telemetry payload, existing IOAM mechanism in RFC9197 also supports carry self-defined data.

And another concern on option 2 is that, if the last entry is used to carry different types of metadata, only one of them can be carried in the same SRH, they can never be used together.



Regards,

Yao




Original
From: zengguanming <zengguanming=[e-mail]<mailto:zengguanming=[e-mail]>>
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]>>;
Date: 2026年01月23日 16:17
Subject: [spring] Seeking WG Consensus on PSID Encoding Options for draft-ietf-spring-srv6-path-segment
_______________________________________________
spring mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
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.