Apologies for the late review, some comments from my side (maybe some have been addressed already earlier, I didn't check, the thread was quite lengthy)
cheers, Eduard Introduction "In SRv6, SR source nodes initiate packets with a segment identifier in the Destination Address of the IPv6 header, and SR segment endpoint nodes that process a local segment present the Destination Address of an IPv6 header." Suggestion for the last part of this sentence:".. SR segment endpoints process local segments present in the Destination Address field of the IPv6 header." Chapter 3 For clarity I would start with SID and explain SRH / SR list later. Chapter 3 discusses two main topics: SRv6 SIDs in relation to RFC4291 and forwarding of packets with SRv6 SID in the DA field, by non-SRv6 router or SRv6 router for which the SID is not local. I would split these topics more clearly, currently they are somewhat interleaved. With regard to RFC4291 I assume the main observation is that the SRv6 SID structure does not match with the structure of RFC4291, in particular the interface ID part. A small discussion on the other aspects of RFC4291 could be added to further clarify this (as done for the subnet-router anycast address). In theory, if the SRv6 SID would start with "000" the interface ID would not even be a problem. Some specific points in the draft-01 text: [RFC8754] defines the Segment List of the SRH as a contiguous array of 128-bit IPv6 addresses, and that each of the elements in this list are SIDs. But all of these elements are not necessarily made equal. Some of these elements may represent a local interface as described in Section 4.3 of [RFC8754] <https://datatracker.ietf.org/doc/html/rfc8754#section-4.3> as "A FIB entry that represents a local interface, not locally instantiated as an SRv6 SID". From this it follows that all the SIDs that appear in the SRH are not SRv6 SIDs as defined by [RFC8402 <https://datatracker.ietf.org/doc/html/rfc8402>]. This paragraph starts with stating that each of the elements in an SR list of the SRH are SIDs (first sentence) and ends with that all the SIDs in the SRH are not SRv6 SIDs. This is contradicting. "Some of these elements may represent a local interface as described in Section 4.3 of [RFC8754] <https://datatracker.ietf.org/doc/html/rfc8754#section-4.3> as "A FIB entry that represents a local interface, not locally instantiated as an SRv6 SID"" Section 4.3 describes the potential outcomes of an LPM lookup on IPv6 DA address on a packet in an SRv6 capable node, it does not describe the SRH. "It is also fairly clear that the non-SRv6-SID elements that appear in the SRH SID list are simply IPv6 addresses assigned to local interfaces annd MUST conform to [RFC4291 <https://datatracker.ietf.org/doc/html/rfc4291>]. " Having non-SRv6-SID elements in the SRH list seems an error condition? See also RFC8745, section 4.3.2. Non SRv6 SID in DA field of packet with SRH is an error condition here. " While looking at the transit nodes it becomes apparent that these addresses are used purely for routing and not for packet delivery to end hosts. …" I would remove the part "and not for packet delivery to end hosts", the forwarding could also be the delivery to a SRv6 function in a neighbouring node - this is conceptually the same as delivery to an end node. Would it be fair to say the forwarding behavior of an IPv6 router would be defined by lookup results 2/3/4 as described in RFC8754 section 4.3? Chapter 4 "One key thing to note in here is that the Locator Block at the beginning of the address does not get modified by the operations needed for supporting compressed SIDs." It is not instantaneously clear that not modifying the locator block is key. Maybe first explain that with compressed SIDs the DA field is still an IPv6 address and then add it remains so even with CSID operations. Section 4.1 The first issue is one of the CSID document, but is it relevant to the discussion on the IPv6 addressing architecture? If so, what is the relevance? If not, it may be removed here. The fail close "issue" seems general for SRv6, not specific for compressed SID The ICMP issue refers to logic needed on SR source nodes, shouldn't this be logic needed on SR nodes to determine the address of the source? Not sure if this issue is relevant to the discussion on SRv6 vs IPv6 addressing architecture. If so, I would have expected it already earlier in the document. So, fail close could be the only open issue / operational consideration? Chapter 5 Shouldn't some high level guidelines on the use of the address block be included in this draft? It would be good to add some considerations on use of existing address space, GUA, ULA. The title of the chapter states a Global Unicast prefix for SIDs. Does this suggest GUA? Chapter 6 states IETF reserved, suggestion non GUA. Chapter 6 The size of the block seems possibly small. How is it sized? Wouldn't the to be defined guidelines and conventions also determine the required block size? I would suggest to reserve a block that is sufficiently large and include at least some high-level guidelines regarding its use. For example is it intended to be ULA alike, or globally unique? Is use of the block for SRv6 mandatory, or optional? I assume SRv6 implementation must support use of this block and may use other blocks if seen fit. On Sat, Sep 17, 2022 at 10:00 AM Jen Linkova <furr...@gmail.com> wrote: > Hello, > > This email starts the 6man Working Group Last Call for the "Segment > Identifiers in SRv6" draft > (https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids). > > The WGLC ends on Tue, Oct 4, 23:59:59 UTC. > > As the document is closely related to the work in the SPRING WG, we'd > like the SPRING WG to review the document and discuss the following > questions: > > - the action items required from SPRING (Section 4.1 and 4.2 of the > draft, > https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids-01#section-4) > [*]. Would it make sense to merge those open issues with the 'Open > Issues' section of > the SPRING document? > - whether the document needs more guidance regarding routability of > /16 or such requirements shall belong to some other document? In > particular, shall we specify that it MUST NOT be in the DFZ? Or > setting 'Globally Reachable = false' in the registry should be > sufficient? The current idea is that the prefix needs to fail closed > and not be routable by default. > > [*] The draft currently refers to the individual submission instead of > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/ > - the link will be updated in the next revision. > > Please review the draft and send your comments to the list/ > > -- > SY, Jen Linkova aka Furry > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
