Hi Adrian,
Thanks for the update, we really need a document to clarify the subtle changes
of some concepts in SRv6.
A few comments/questions tagged with [Yao] after reading it.
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 represts:
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
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.
Thanks,
Yao
Original
From: AdrianFarrel <adr...@olddog.co.uk>
To: spring@ietf.org <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: internet-dra...@ietf.org <internet-dra...@ietf.org>
Sent: 30 March 2025 18:51
To: 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 -- i-d-annou...@ietf.org
To unsubscribe send an email to i-d-announce-le...@ietf.org
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
