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

["Zafar Ali (zali)" <[e-mail]>]

Hi Guanming

Please see [ZA] in-line
Thanks
Regards … Zafar
From: zengguanming <[e-mail]>
Date: Thursday, March 12, 2026 at 10:53 PM
To: Zafar Ali (zali) <zali=[e-mail]>, SPRING WG List <[e-mail]>
Cc: Cheng Li <[e-mail]>, [e-mail] <[e-mail]>, DHRUV DHODY <[e-mail]>, chengweiqiang <[e-mail]>, [e-mail] <[e-mail]>, Zafar Ali (zali) <[e-mail]>
Subject: RE: Seeking WG Consensus on PSID Encoding Options for draft-ietf-spring-srv6-path-segment

Dear Zafar, Chairs, and WG,
Thank you for your detailed feedback and for highlighting the importance of alignment with [RFC8986] and [RFC8754]. We fully agree that any extension to the SRv6 data plane must be consistent with the established network programming model.

“The only option which is consistent with the SR network programming and data plane [RFC8986, 8754] is the following. ”
We respectfully disagree with the assertion that the Flag-less approach (Option 3B) is the "only option which is consistent" with these RFCs. While Option 3B is functional, we believe that introducing a dedicated flag (e.g., G-flag) does not violate the principles of RFC 8986 or 8754, and offers superior architectural benefits regarding  generality, and compatibility.

[ZA] Why do you need an additional flag to go with it (when encoding PSID)? What is so special about the PSID from other SIDs we have defined so far (and there are many)?


“Also, SRv6 runs on IPv6 data plane, which provide other routing headers (like HBH).

We do not want to add functionality in SRH that overloads functionality achievable by other RH (e.g., the HBH). ”
From my perspective, there is difference between HBH and segment list[last entry] in SRH: the data carried by HBH is processed by slow path(CPU/software processing).

[ZA] This is incorrect statement; there are vendors who have implemented HBH in fast-path/ HW. If you have an implementation limitation, please address the limitation.

While segment list[last entry]  is designed for high-frequency, per-packet operations (e.g., loss measurement at line rate). Also, HBH header is processed by each IPv6 node, PSID is processed by each SRv6 Endpoint node.

[ZA] If "PSID is processed by each SRv6 Endpoint node” why do you need a special flag in SRH?

Using HBH header will introduce unnecessary and extra processing by IPv6 node.

“Other options, especially, Option 2 must be discussed with the 6man WG.”
Actually discussion has been taken by Cheng Li with 6man WG before, probably we can talk about it with Cheng Li on IETF125 Shenzhen face to face.

[ZA] I recall 6man discussion in the context of https://datatracker.ietf.org/doc/draft-li-6man-srv6-path-segment-encap/ However, that draft remains an individual document and has been expired since 2021.

[ZA] The https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-path-segment/00/ referenced the 6man individual draft when it was adopted.
I do recall any WG discussion when the 6man individual draft reference was changed into bringing in the content in the draft-ietf-spring-

[ZA] n.b.: Unfortunately, due to some personal reasons, I had to cancel my trip and will attend IETF remotely.

Best regards,
Guanming


From: Zafar Ali (zali) <zali=[e-mail]>
Sent: Saturday, March 7, 2026 9:04 AM
To: zengguanming <[e-mail]>; SPRING WG List <[e-mail]>
Cc: Cheng Li <[e-mail]>; [e-mail]; DHRUV DHODY <[e-mail]>; chengweiqiang <[e-mail]>; [e-mail]; Zafar Ali (zali) <[e-mail]>
Subject: Re: Seeking WG Consensus on PSID Encoding Options for draft-ietf-spring-srv6-path-segment

Dear chairs and the WG,

Re: Which direction best meets operational and architectural needs?

The only option which is consistent with the SR network programming and data plane [RFC8986, 8754] is the following.


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.



All existing features are developed using this model.

There have use-cases deployed in the network where SRH is not needed.



Re: Any strong objections to the proposed options.



Also, SRv6 runs on IPv6 data plane, which provide other routing headers (like HBH).

We do not want to add functionality in SRH that overloads functionality achievable by other RH (e.g., the HBH).

Other options, especially, Option 2 must be discussed with the 6man WG.



Thanks
Regards … Zafar
From: zengguanming <zengguanming=[e-mail]<mailto:zengguanming=[e-mail]>>
Date: Friday, January 23, 2026 at 3:17 AM
To: SPRING WG List <[e-mail]<mailto:[e-mail]>>
Cc: Cheng Li <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, DHRUV DHODY <[e-mail]<mailto:[e-mail]>>, chengweiqiang <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[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