[spring] Re: draft-ietf-spring-srv6-path-segment-16.txt

[zengguanming <[e-mail]>]

Hi Bruno,



Sorry for being late for summarizing the points raised in IETF125, since I was really busy the past several months and Cheng Li had moved to another department.



Nevertheless, in this email I will summarize some of the questions, and put forward our ideas.



As for Adrian's review, actually we have raised discussion before. And I have forwarded the email to the WG.





Q1: how the egress identifies metadata format when PSID acts as a generic metadata container

The G-flag only marks the final SRH segment as metadata; it does not carry format type. Instead, we add an 8-bit `Metadata-Type` sub-TLV in PCEP/BGP SR-Policy extensions, bound per SR Policy and pushed by the control plane to ingress and egress, e.g.:

- `0x01`: standard LOC:FUNCT:ARG END.PSID

- `0x02–0xFF`: reserved for domain-local custom metadata formats



Packet processing workflow:

1. Ingress: lookup SR Policy, fill the last SRH segment with PSID/metadata and set G-flag; no format info is placed in the packet.

2. Transit nodes: unchanged standard SRv6 forwarding. Since SL < Last Entry, they ignore the metadata segment entirely, no upgrade needed.

3. Egress:

   - Trigger metadata handling only when `SL==0` (egress is path endpoint) AND G-flag=1.

   - Map the received 128-bit metadata value to the corresponding SR Policy entry, read the associated `Metadata-Type`, then parse the payload accordingly.





Q2: 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)?

[Guanming] Here are our specific considerations:

1. Forwarding Plane Efficiency

From a data plane implementation perspective, the presence of a Flag fundamentally optimizes the processing pipeline.

•      Current Flag-less Flow: Generally, when receiving a packet, an SR node processes according to these steps:

1.    Read the SRH Flags field.

2.    Read and Parse Segment List[n] (regardless of whether it will be used immediately).

Issue: The node is forced to fetch and potentially validate the metadata value even if it's not the active segment, adding unnecessary memory access and logic overhead.

•      Proposed Flag-based Flow: If a G-flag is defined, the processing logic becomes more efficient:

1.    Read the SRH Flags field.

2.    Check the G-flag:

     If Unset: The node knows Segment List[n] does not contain a routing SID. It skips reading/parsing that specific entry entirely for forwarding decisions.

     If Set: The node proceeds to process the entry as a PSID or other meta data.

Benefit: This allows the hardware to bypass unnecessary memory reads and validation logic for metadata entries, streamlining the fast path.

Q3: “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 extension headers (e.g., the HBH). ”



Q3.1 why we do not place PSID inside SRH TLV, instead of using the last segment entry with G-flag

1. The primary rationale is forwarding efficiency and hardware complexity.

PSID processing can be enabled for intermediate endpoints or limited to the egress node, selected via configuration. When PSID is placed in the final segment slot, its location is **fixed**: hardware can access it in O(1) constant time without scanning the TLV chain. In contrast, SRH TLVs reside in a variable sequence; to locate a specific TLV, the node must walk through the entire TLV list, which yields O(N) lookup complexity.

2. PSID has a fixed 128-bit payload, matching the native width of an SRH segment slot. TLVs carry extra Type/Length headers and have variable length, introducing overhead and alignment handling. Using the last segment slot avoids TLV header cost and variable-length processing logic.



Q3.2 why we avoid HBH header for PSID

1. HBH is examined by every router along the path. While PSID can be configured to be processed by intermediate SR endpoints, HBH semantics force all transit routers to parse the HBH header unconditionally. Even if we only want selected SR endpoints to consume PSID, placing PSID in HBH would impose mandatory HBH parsing on every hop in the domain, requiring widespread hardware upgrades and increasing per-packet load.





Best regards,

Guanming





-----Original Message-----
From: [e-mail] <[e-mail]>
Sent: Wednesday, October 14, 2026 8:56 PM
To: [e-mail]
Cc: [e-mail]
Subject: [spring] draft-ietf-spring-srv6-path-segment-16.txt



Hi authors,



Could you please share a status on this draft?



Indeed -16 has just been published and is identical to -15, while

- the draft had a slot at IETF 125 with multiple points raised, and significantly different options discussed. There is a need to progress these discussions on the list with the SPRING WG. Nothing happened on the list nor in the draft since then.

- Adrian has provided a review 5 months ago [1] (thank you Adrian). Idem, no answer from the authors on the list and no update to the draft.



[1] https://mailarchive.ietf.org/arch/msg/spring/eJGPX4kqEi9xKA0Rm50O4DtqPCw/



Thank you,

--Bruno



-----Original Message-----

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>

Sent: Wednesday, October 14, 2026 2:06 PM

To: [e-mail]<mailto:[e-mail]>

Cc: [e-mail]<mailto:[e-mail]>

Subject: I-D Action: draft-ietf-spring-srv6-path-segment-16.txt



Internet-Draft draft-ietf-spring-srv6-path-segment-16.txt is now available. It is a work item of the Source Packet Routing in Networking (SPRING) WG of the IETF.



   Title:   Path Segment Identifier (PSID) in SRv6 (Segment Routing in IPv6)

   Authors: Cheng Li

            Weiqiang Cheng

            Guanming Zeng

            Dhruv Dhody

            Yongqing Zhu

   Name:    draft-ietf-spring-srv6-path-segment-16.txt

   Pages:   15

   Dates:   2026-10-14



Abstract:



   Segment Routing (SR) allows for a flexible definition of end-to-end

   paths by encoding an ordered list of instructions, called "segments".

   The SR architecture can be implemented over an MPLS data plane as

   well as an IPv6 data plane.



   Currently, Path Segment Identifier (PSID) has been defined to

   identify an SR path in SR-MPLS networks, and is used for various use-

   cases such as end-to-end SR Path Protection and Performance

   Measurement (PM) of an SR path.  This document defines the PSID to

   identify an SRv6 path in an IPv6 network.



The IETF datatracker status page for this Internet-Draft is:

https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-path-segment/



There is also an HTMLized version available at:

https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-path-segment-16



A diff from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-spring-srv6-path-segment-16



Internet-Drafts are also available by rsync at:

rsync.ietf.org::internet-drafts





_______________________________________________

I-D-Announce mailing list -- [e-mail]<mailto:[e-mail]> To unsubscribe send an email to [e-mail]<mailto:[e-mail]> ____________________________________________________________________________________________________________

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.



_______________________________________________

spring mailing list -- [e-mail]<mailto:[e-mail]>

To unsubscribe send an email to [e-mail]<mailto:[e-mail]>