Hi Yao, Looking through the archive, I see that Suresh and I agreed on some text to send to you, but we don’t appear to have actually sent it. Well, it is not in the archive for the SPRING mailing list.
Sorry about that fumble. Anyway… > 3.2. Segment List in Section 2 of RFC 8754 > The text in RFC 8754 reads: > Segment List[0..n]: > 128-bit IPv6 addresses representing the nth segment in the Segment > List. The > Segment List is encoded starting from the last segment of the SR > Policy. That is, > the first element of the Segment List (Segment List[0]) contains > the last segment > of the SR Policy, the second element contains the penultimate > segment of the SR > Policy, and so on. > This is updated as follows to clarify that the entries in the Segment List > are 128 bit entries, but > not necessarily IPv6 addresses. > Segment List[0..n]: > 128-bit entities representing the nth segment in the Segment List. The > Segment > List is encoded starting from the last segment of the SR Policy. > That is, the first > element of the Segment List (Segment List[0]) contains the last > segment of the > SR Policy, the second element contains the penultimate segment of > the SR Policy, > and so on. > > [Yao] A little bit not quite sure about the definition of "segment" here. > From my reading, in > the text above, segment is a 128-bit element carried in Segment List field > of SRH. While in > RFC8402 section 1, it says > "A node steers a packet through an SR Policy instantiated as an ordered > list of instructions > called "segments" > "an instruction is associated with a segment and encoded as an IPv6 > address" > "When an SRv6 SID is completed, the SL is decremented and the next segment > is copied to the DA". > > So it may need to be clarified whether a segment represents: > a) an instruction. In this case, now it doesn't have to be an IPv6 address > and doesn't have to > be 128-bit. So "128-bit entities representing the nth segment in the > Segment List" above is not > very accurate, and RFC8402 needs to be updated. > b) a 128-bit entry that may contain many instructions(e.g, compressed SIDs), > then RFC8402 needs > to be updated as well > c) or other meanings RFC8402 defines a Segment in Section 2 and it is generic without any specific references to IPv6 at all since MPLS is also covered. "Segment: an instruction a node executes on the incoming packet (e.g., forward packet according to shortest path to destination, or, forward packet through a specific interface, or, deliver the packet to a given application/service instance).” Hence we do not think an update is needed for RFC8402. Of course, RFC8754 moves from the general discussion of SR into the definition of the SRH (and is therefore specific to SRv6). That's why we update that RFC. > 3.5. ICMP Processing in Section 5.4 of RFC 8754 > The method for deriving the destination address of the invoking packet in RFC > 8574 > reads as: > The SID at Segment List[0] may be used as the destination address of the > invoking > packet. > To allow for the 0th entry in the Segment List to be mapped rather than > copied to > a destination address, this is updated to: > The SID at Segment List[0] may be mapped to derive the destination address > of the > invoking packet. > > [Yao]It is a little bit vague here by saying "The SID at Segment List[0]". As > in RFC8402 > section 2, the definition of SRv6 SID is "an IPv6 address explicitly > associated with the > segment." , if we follow this definition, the SID is the mapping result > instead of > something carried in Segment List[0] that may need to be processed to get the > 128-bit IPv6 address. RFC9602 Section 3 provides a longer explanation about SRv6 SIDs and the IPv6 Addressing Architecture (especially the relationship between SRv6 SIDs and the Segment List). Can you please take a look and let us know if there are still things that need to be clarified further. Cheers, Adrian and Suresh Original From: AdrianFarrel <mailto:adr...@olddog.co.uk> To: mailto:spring@ietf.org <mailto:spring@ietf.org>; Date: 2025年03月31日 02:08 Subject: [spring] Please (please, please) review draft-farrel-6man-sidlist-clarification Hi SPRING, This draft was discussed in 6man in Bangkok. That meeting thought that the draft was worthwhile, but that it should formally update 8754. This new revision: - Formally updates 8754 - Is on the Standards Track (a necessity for an update of 8754) - Includes specific text for the updates While 8754 is "owned" by 6man, SR is clearly what SPRING works on. So a review here would be very welcome. In summary: - This does not seek to change the SR architecture - It clarifies the SID list in the SRH in line with draft-ietf-spring-srv6-srh-compression - It may be an enabler for future things Cheers, Adrian -----Original Message----- From: mailto:internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> Sent: 30 March 2025 18:51 To: mailto:i-d-annou...@ietf.org Subject: I-D Action: draft-farrel-6man-sidlist-clarification-02.txt Internet-Draft draft-farrel-6man-sidlist-clarification-02.txt is now available. Title: Clarifying SRv6 SID List Processing Authors: Adrian Farrel Suresh Krishnan Name: draft-farrel-6man-sidlist-clarification-02.txt Pages: 6 Dates: 2025-03-30 Abstract: Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 data plane. Segments are indicated by Segment Identifiers (SIDs). SRv6 utilizes the Segment Routing Header (SRH), an IPv6 extension header, that includes a SID list indicating the sequence of segments and any additional processing to be performed. This document updates RFC 8754 by clarifying the processing of SID list entries. It does not change any elements of the SRv6 architecture. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-farrel-6man-sidlist-clarification/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-farrel-6man-sidlist-clarification-02.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-farrel-6man-sidlist-clarification-02 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ I-D-Announce mailing list -- mailto:i-d-annou...@ietf.org To unsubscribe send an email to mailto:i-d-announce-le...@ietf.org _______________________________________________ spring mailing list -- mailto:spring@ietf.org To unsubscribe send an email to mailto:spring-le...@ietf.org _______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
