Hi Bruno and WG, This is the discussion with Adrian on draft-ietf-spring-srv6-path-segment. If you have any question, please feel free to ask.
Best regards, Guanming From: Adrian Farrel <[email protected]> Sent: Saturday, August 29, 2026 9:44 PM To: zengguanming <[email protected]>; Cheng Li <[email protected]> Cc: zhangli (CE) <[email protected]>; [email protected]; Dongjie (Jimmy) <[email protected]> Subject: RE: Plans for Spring docs Hello Guanming, Thanks for chasing me. Answers in line. From: zengguanming <[email protected]<mailto:[email protected]>> Sent: 29 August 2026 03:25 To: [email protected]<mailto:[email protected]>; Cheng Li <[email protected]<mailto:[email protected]>> Cc: zhangli (CE) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Dongjie (Jimmy) <[email protected]<mailto:[email protected]>> Subject: RE: Plans for Spring docs Hi Adrian, Perhaps you have missed this response email. And I am sorry that I was so busy in the past several months doing some research project, and could not response some email in time. Could you please have a check on the response? And if there are still some problems, I will appreciate if we have further discussion. Best regards, Guanming From: zengguanming Sent: Wednesday, June 17, 2026 9:39 PM To: '[email protected]' <[email protected]<mailto:[email protected]>>; Cheng Li <[email protected]<mailto:[email protected]>> Cc: zhangli (CE) <[email protected]<mailto:[email protected]>>; '[email protected]' <[email protected]<mailto:[email protected]>>; Dongjie (Jimmy) <[email protected]<mailto:[email protected]>> Subject: RE: Plans for Spring docs Hi Adrian, Thank you for bringing us with so many critical issues. I have went through the main part of questions except nits and have written some response. I think we can have further discussion based on my response, and your valuable advised may help with our work. = Puzzling Question = In section 5 you have When a PSID is allocated on the egress, it MUST be distributed to the ingress node of the path that identified by the PSID. I can accept that the means of doing this could be out of scope for this document, but I think there is something curious. I can see how the PSID identifies which path is which at a node that knows the mapping, but I don't know how that gets conveyed to other nodes. The path is otherwise indicated by the full SID list, so is the assumption that egress will communicate with other nodes sending the whole SID list along with the PSID? Otherwise, I don't see how the distributed PSID is of any use. [Guanming] You are absolutely right: a PSID by itself is just an opaque identifier-it only becomes meaningful when bound to a specific SRv6 path (i.e., a segment list). I'm pleased to clarify that the mechanism for distributing this binding is indeed defined, and it's precisely the subject of the companion document, draft-ietf-pce-sr-path-segment. This PCEP (Path Computation Element Communication Protocol) extension draft explicitly defines how the (segment list, PSID) tuple is communicated between network elements. In the typical stateful PCE model described in Section 5.1.1: 1.The ingress PCC requests a path with a PSID from the PCE. 2.The PCE then sends a PCInitiate message to the egress PCC, requesting it to allocate a PSID for the given path. 3.The egress PCC allocates the PSID and reports it back to the PCE via a PCRpt message. 4.Finally, the PCE sends a PCUpd message to the ingress PCC, which contains both the full segment list and the allocated PSID. Therefore, your intuition-that the egress must communicate the whole SID list along with the PSID-is correct, and this coordination is facilitated by the PCE using the protocol mechanisms standardized in draft-ietf-pce-sr-path-segment. Our SPRING draft focuses on the data-plane definition of the PSID, while the PCE draft handles the control-plane distribution. We will revise our text to clearly reference this companion document and emphasize that the PSID's value is derived from its association with a known path, not from the identifier alone. [AF] This is all good, and it is great that it is covered in the companion document. Maybe the reference to draft-ietf-pce-sr-path-segment just needs to say a little but more about what the document includes, so that the reader (me :-) can be confident that the issues are covered. = Minor = Section 3 You have... [RFC8754] states that the SR segment endpoint node creates Forwarding Information Base (FIB) entries for its local SIDs (without constraining the details of implementation). In order to provide a new independent 128-bit ID space for PSID, the PSID is required to be stored separating from the other SIDs (for example in a different table from the FIB). I am not sure why you find it necessary to constrain the implementation about how it stores PSIDs, immediately after you note that 8754 does not constrain the implementation. Further, is a PSID a local SID or not? If it is not, why is the first sentence in any way relevant? If it is, then your second sentence means you are making an Update to RFC 8754. It is clear that PSIDs MUST NOT be used for routing (it is less clear why not!), and I think you have said this well. So why is the storage mechanism any of your business? Indeed, a FIB lookup of a PSID could return a "do not forward" indication, or a special null interface, or "not found". I would suggest deleting these two sentences. However, there may be something hiding here which you have not made clear: Is it required that a PSID value must also not be the same as any other SID value. I think this is the case (but if it is not the case then you have work to do!). Now, this issue resurfaces at the top of 3.1 where you have: As mentioned above, an SRv6 PSID is stored independent from the FIB, so that the total 128-bit can be programmed in use. I think this could be deleted as well. [Guanming] You are absolutely correct that the two sentences in question introduce an unnecessary and inconsistent constraint on implementation. Our intention was not to dictate how a node should store PSIDs internally, but rather to emphasize a key semantic property: a PSID is not a routable SID and must not be treated as one by the data plane. Your observation about RFC 8754 is spot-on. Since RFC 8754 deliberately avoids constraining the internal implementation of local SIDs, our draft should not impose its own storage requirements. Furthermore, your point that a FIB lookup for a PSID could simply return a "do not forward" result is a perfect illustration of how this can be handled flexibly by an implementation. Upon reflection, the core requirement we were trying (and failing) to express is this: The value space for PSIDs MUST be distinct from the value space of all other locally instantiated, routable SIDs to prevent any ambiguity. This is a requirement on the value assignment, not on the physical storage mechanism. The current wording conflates these two concepts, leading to the confusion you rightly identified. Therefore, we will: 1.Delete the two problematic sentences in Section 3. 2.Delete the related sentence at the beginning of Section 3.1. 3.Add clear text stating that PSID values must be allocated from a space that does not overlap with any routable local SID values, to ensure unambiguous processing. [AF] This is good. 3.1 To avoid the value conflict, the value of a PSID MUST be global unique within the SRv6 domain. This is important! But there are some things missing: - What does "global" mean? (SR domain? AS? The world?) - How is this achieved? (If you use the encoding in 3.1.1 this is easy) - What happens if there is a clash? [Guanming] 1.What is the scope of "global"? an SRv6 domain refers to a single administrative or routing domain under coordinated SID allocation policy (e.g., an AS or a multi-AS network managed by a single controller). [AF] OK. So this is best described as "domain unique" rather than "global unique". 2. How is uniqueness achieved? By allocating PSIDs from the structured format defined in Section 3.1.1, which uses a dedicated locator block, uniqueness within the SRv6 domain is ensured by centralized or coordinated assignment. [AF] Good. So, a forward pointer using roughly this text. 3. What happens in case of a clash? A PSID value collision within an SRv6 domain is a protocol violation that may result in incorrect path association and MUST be avoided by proper provisioning. Implementations SHOULD detect such conflicts and log an error. [AF] All good and, again, the use of 3.1.1 makes clashes very much an issue on the one node. 3.1 A use case can define its specific structure of the PSID. Presumably all nodes participating in that use case must agree on the structure of the PSID. But what happens if a PSID from one use case is seen by a router that also participates in another use case - how can it tell the structures apart? [Guanming] All PSID definitions should conform to a common baseline format, such as the structured encoding outlined in Section 3.1.1 (e.g., using a dedicated locator block). This ensures that even if payload formats differ, the type or namespace of the PSID can be recognized consistently across implementations. [AF] Hmmm. Saying "should conform to a common baseline format, such as..." is OK, but not very helpful. I think you need to be more definite in defining *the* baseline format and requiring all PSIDs to conform. 4. You have... The SRv6 PSID MUST appear only once in the segment list. Do you mean... The SRv6 PSID MUST NOT appear more than once in the segment list. And, per RFC 8754 as updated by draft-ietf-6man-sidlist-clarification, the Segment List contains entries that are mapped to SIDs, but are not necessarily SIDs. So, in the case of Segment List compression, presumably the PSID does not appear explicitly in the SID list. BTW, the whole issue of segment list compression seems to be forgotten throughout the document apart from one short mention buried in the middle of 4.1. It's mainly a problem of use of language. [Guanming] First, you are absolutely correct about the phrasing: "The SRv6 PSID MUST appear only once in the segment list" should indeed be clarified as "The SRv6 PSID MUST NOT appear more than once in the segment list." PSID is carried in segment list[n], (n=last_entry) and SL ranges from n-1 to 0. That means SL would never point to PSID. So PSID may be out of the scope of compression. [AF] OK 4.1 I like the description of the G Flag as indicating that the final entry in the Segment List contains (i.e., is mapped to) a 128 bit meta data value. However, this opens up uses beyond PSID and that leaves the question of how one would distinguish between different metadata cases: when does the G Flag indicate the presence of a PSID and when does it indicate some other metadata? [Guanming] We acknowledge that without a disambiguation mechanism (e.g., a type field within the 128-bit payload or an IANA registry for metadata types), true generality is not viable. To support multiple generic metadata types, future extensions SHOULD define a type field within the 128-bit metadata object or use distinct flag bits. But that means the PSID structure may be changed and a type filed should be added. I am not sure whether it is a good idea to add a type filed in PSID. How do you think? Although later you have... When the SRH.G-flag is set, it indicates that a PSID is encoded in ...which suggests that, perhaps, the generality of the G Flag is not intended. [Guanming] The correct expression should be "When the SRH.G-flag is set, it indicates that a metadata is encoded in..." Then I see: * Set (1): Indicates that Segment List[n] (the last entry) contains a Generic Metadata object. The content of this 128-bit field is not treated as a standard IPv6 destination address for routing lookup but as an opaque identifier or data payload defined by the specific application (e.g., a Path Segment Identifier). * Unset (0): Indicates that Segment List[n] is not valid. Surely 0 indicates the Segment List[n] is (mapped to) a normal (routable) SID? Otherwise you've broken backward compatibility etc. 2. Incorrect semantics for G-flag = 0 [Guanming] Perhaps there is some misunderstanding. PSID is carried in segment list[n], (n=last_entry) and SL ranges from n-1 to 0. That means SL would never point to PSID. G-flag = 1 means the special location segment list[n] is valid, while G-flag = 0 means the special location segment list[n] is invalid. [AF] This all makes sense, but (as you note) it leaves us the problem of how to demultiplex the different metadata types. I think you can safely assign a few bits of the Arg as the "metadata type identifier" with 0 defined to mean "the Funct contains the local ID of the path". Then future metadata types can set the G-flag and define new Arg values. It is probably safe to allocate 8 bits for this purpose. 6. What happens if the G Flag is clear, but a PSID is at the bottom of the SID list. I think that the PSID is easily identified by the egress node, but is it allowed to process the PSID? [Guanming] An egress node MUST only interpret the last entry of the Segment List as a PSID if the SRH G-flag is set to 1. [AF] That's clear. Maybe use "MUST NOT interpret the last entry of the Segment List as a PSID if the SRH G-flag is not set to 1" 6. What happens if the end of a segment advances to the next SID and that SID is a PSID, but not a locally assigned PSID? Yes, this is not supposed to happen, but there is no protection. If the G Flag is set, the node will know that: - it is at the bottom of the SID list - the final SID is a PSID - the PSID was not locally allocated ...so it will not forward the packet If the G flag is not set, the node will not know that this is not a routable SID. So won't it try to forward the packet which is routable based on the Loc part of the PSID? [Guanming] PSID is carried in segment list[n], (n=last_entry) and SL ranges from n-1 to 0. That means SL would never point to PSID. So "the end of a segment advances to the next SID and that SID is a PSID" will never happen. Nevertheless, I want to raise another question here: maybe the location of segment list[n] is somewhat special, do you think it is suitable to use such a location? Since this is the previous designed by Cheng Li, maybe we should discuss it together. [AF] Yes, I have repeatedly missed the list[n] thing. It's just a terminology thing... I get caught up with list[n-1]...list[0] is the Segment List, and list[n] is part of the list of SIDs, but not the Segment List. OK? Adrian
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
