[spring] Re: A review of draft-ietf-spring-srv6-path-segment

[zengguanming <[e-mail]>]

Hi Adrian,

Sorry for delaying the response for your questions on draft-ietf-spring-srv6-path-segment. Since something has taken over the time.
Nevertheless, we would discuss about the questions and give you feedback as soon as possible.

Best regards,
Guanming


-----Original Message-----
From: Adrian Farrel <[e-mail]> 
Sent: Friday, June 12, 2026 8:23 PM
To: [e-mail]
Cc: [e-mail]
Subject: RE: A review of draft-ietf-spring-srv6-path-segment

Hi there,

Wondering whether anyone has a response to this review.

Thanks,
Adrian

-----Original Message-----
From: Adrian Farrel <[e-mail]>
Sent: 13 May 2026 19:56
To: '[e-mail]'
<[e-mail]>
Cc: '[e-mail]' <[e-mail]>
Subject: A review of draft-ietf-spring-srv6-path-segment

Hi,

I'm catching up on some of the SPRING drafts, and thought I would have a look at this one to see how it has progressed since I last reviewed it.

It is so refreshing to see a draft that is not too long - thanks!

I found a whole pile of minor issues and nits, but nothing very big. And everything should be easy to fix. Once that is done, I would consider the draft ready to progress.

Thanks for the work.

Adrian

= 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.

= 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.

---

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?

---

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?

---

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.

---

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?

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.

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.

---

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? 

---

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?



= Nits =

Abstract

OLD
   The SR architecture can be implemented over an MPLS data plane as
   well as an IPv6 data plane.
NEW
   The SR architecture can be implemented over an MPLS data plane
   (SR-MPLS) as well as an IPv6 data plane (SRv6).
END

---

Abstract

OLD
   Currently, Path Segment Identifier (PSID) has been defined to
   identify an SR path in SR-MPLS networks, and is used for various use- NEW
   The Path Segment Identifier (PSID) was defined to
   identify an SR path in SR-MPLS networks, and is used for various use- END

---

1.

OLD
   To identify an SR-MPLS path, a Path Segment Identifier
   is defined in [RFC9545].
NEW
   To identify an SR-MPLS path, a Path Segment Identifier (PSID)
   is defined in [RFC9545].
END

---

1.

s/384-bits value and a 1280-bits/384-bit value and a 1280-bit/

---

1.

s/are merged/is merged/

---

1. 

OLD
  distinguish the path in different SR policy NEW
  distinguish the paths in different SR policies END

---

1.

OLD
   However, an SRv6 policy may need to measure a
   segment list in its own candidate path, where the packets statistics
   associated with this segment list is independent with other segment
   lists in other SRv6 policies even if the same segment list is used.
NEW
   However, an SRv6 policy may require that the
   traffic is measured for a specific segment list in its own candidate
   path, where the packet statistics associated with this segment list 
   are independent from the traffic for segment lists in other SRv6
   policies even if the same segment list is used.
END

---

1.

OLD
   Without a Path ID to specify the path will cause the statistic of the
   traffic from multiple paths using the same segment list under
   different SRv6 policies merge into an aggregated result on the egress
   endpoint node.
NEW
   Without a Path ID to specify the path, the traffic statistic from
   multiple paths using the same segment list under different SRv6 
   policies will be merged into an aggregated result on the egress
   endpoint node.
END

---

1.

s/a new SRv6 segment/a new SRv6 segment identifier/

s/which in total is an 128-bits value,/which i a 128-bit value,/

s/has the better processing/has better processing/

s/Using an SRv6 PSID is used in reduced/Using an SRv6 PSID in reduced/

---

1.

OLD
   can solve the problem of cannot identifying a
   segment list by the reduced segment list, NEW
   can solve the problem of not being able to identify a
   segment list from the reduced segment list, END

---

1.2

If you are going to include "SR-MPLS" and "SRv6 path", I think you also need to include "SRv6".

---

Outside the term "SRv6 Path Identifier" you use "SRv6 Path" and "SRv6 path". Pick one and make sure section 1.2 is consistent.

---

2.

OLD
packets counts/timestamps
NEW
packet counts/timestamps
END

---

3.

s/A PSID is used for identify/A PSID is used to identify/

---

3.

OLD
   In normal cases, each segment list will have
   a its own PSID with different value.  However, depending on the use
   case, different segment list might use the same value PSID, causing
   the statistics of these SRv6 path are merged on the egress node.  For
   example, a use case may use the same PSID for some or all the segment
   list under a Candidate path, or even some or all Candidate Path
   within an SRv6 policy.
NEW
   In normal cases, each segment list will have
   its own PSID with a different value.  However, depending on the use
   case, different segment lists might use the same PSID, causing the
   statistics of these SRv6 paths to be merged on the egress node.  For
   example, a use case may use the same PSID for some or all the segment
   lists under a Candidate path, or even all Candidate paths within an 
   SRv6 policy.
END

---

Within the document you have:
Candidate Path
Candidate path
candidate path

Pick one.

---

3.

OLD
   For example, the same segment list in different Candidate
   Path or SR policy may use different PSIDs for identifying its path to
   distinguish the statistics data of other SRv6 path in other SRv6
   policies using the same segment list.
NEW
   For example, the same segment list in different Candidate
   Paths or SR policies may use different PSIDs to identify its path to
   distinguish the statistics data of other SRv6 paths in other SRv6
   policies using the same segment list.
END

---

3.1

Does Figure 1 add anything to the document? I see you don't reference it and it doesn't seem to make anything clearer.

---

3.1

s/A future document MAY/A future document may/ s/further new formats/further formats/

---

3.1.1

s/suggested to follows/suggested to follow/

---

3.1.1

Does Figure 2 add anything to the document? You have already referenced RFC 8986, and there is no actual change from what that RFC defines.

---

4. and Figure 3

I think you should...
OLD
   As depicted
   in figure.3, PSID MUST be placed at SegmentList[n] in the SRH, where
   n equals SRH.LastEntry.
NEW
   The PSID, if present, MUST be placed to be mapped from the final 
   entry in the Segment List in the SRH.
END

And that would mean that Figure 3 contains no new information and can safely be deleted.

---

4.1

The pseudocode has ref1 and ref2
The text has Ref1 and Ref2

---

You have
performance measurement
Performance measurement
Performance Measurement

Make a choice.

---

6. (similar to 4)

Probably replace...

   *  The SRv6 PSID MUST appear only once in a segment list

...with...

   *  The SRv6 PSID MUST NOT appear more than once in a segment list

---

6.

Expand SL on first use.

---

7.

   This document also requests IANA to allocate bit position TBA1 within
   the "Segment Routing Header Flags" registry defined in [RFC8402].

I think that should be RFC 8754

---

8.

A bit odd that the first paragraph says "no additional security considerations" and then you have quite a lot of text describing security considerations.

---

It's not a requirement, but it might be really nice to include an Operational Considerations section per draft-ietf-opsawg-rfc5706bis.