Hi Jen, all, I've done a review of this document as part of working group last call. I found quite a few nits and so on, so I think the document needs some more work before escaping from the working group and being present for publication.
Cheers, Adrian ====== I find it odd that this is an Informational document but its use of BCP14 language appears to constrain and direct implementations. So either you need to drop down to normal lowercase usage, or change the document to Standards Track. There is only one use (a MUST in Section 3) that could easily be resolved. --- Section headers need to be in header case --- You seem to freely interchange "Segment List" and "SID list". It would help to pick a term and stick with it since the change suggests there is a difference in meaning. If you are happy that they are the same, you could: - fix the text to use one term consistently - mention that the terms are equivalent in Section 2 --- Please select "Destination Address" or "destination address field" or "Destination address field" or "Destination address" and use it consistently. --- Abstract No citations in the Abstract This document "intends"? Probably just state that it does. --- Section 3 From this it follows that all the SIDs that appear in the SRH are not SRv6 SIDs as defined by [RFC8402]. I'm hoping you didn't intend what is written (because that would pretty much mean that SRv6 is dead!). Perhaps... From this it follows that not all the SIDs that appear in the SRH are SRv6 SIDs as defined by [RFC8402]. Maybe, it is also better to keep the context of the Segment List which is how you introduced these SIDs. Something like... From this it follows that not all the SIDs that appear in the SRH Segment List are SRv6 SIDs as defined by [RFC8402]. --- 3. "It is also fairly clear" Well, that is illuminating :-) Perhaps you want to make statements about the SID elements and not about the clarity of the referenced documents? --- 3. s/annd/and/ --- 3. the following discussions are intended to be applicable Maybe s/are intended to be/are/ --- 3. Section 3.1. of [RFC8986] describes the format of an SRv6 SID as composed of three parts LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most significant bits of the SID, followed by F bits of function (FUNCT) and A bits of arguments (ARG). Would it be helpful to qualify L+F+A = 128 in all cases? --- 3. When an SRv6 SID occurs in the IPv6 destination address field of an IPv6 header, only the longest match prefix corresponding to the locator is used to forward the packet to the node identified by the Locator. Possibly you mean s/is used/should be used/ Or maybe s/used/used by an SRv6-capable node/ --- 3. 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. The distinction between "end host" and "destination" is a fine one. When you are a transit node, you can't tell the difference. When the DA identifies the end of a segment, it is (from a network point of view) exactly like identifying an end host. Maybe, in fact, you mean "packet delivery at end hosts" (at not to). I think you should also be careful with the term "routing" as well. 4129 is pretty careful about not using it (except in the Anycast section), but says "forwarding" instead. 7608 also prefers the term "forwarding". --- 3. Hence the relevant standard to apply here is [RFC7608] that allows the use of variable length prefixes in forwarding I think 7608 is not a standard. Maybe say specification? But also, I don't think that 7608, as a BCP, "allows" anything. --- 4. The C-SID document [I-D.filsfilscheng-spring-srv6-srh-compression] I don't think you can say "The C-SID document" because, well, definite articles are a bit limiting. Anyway, that draft was replaced by draft-ietf-spring-srv6-srh-compression a while ago. Why don't you turn this around as... [I-D.ietf-spring-srv6-srh-compression] introduces an SRH encoding for compressed segment lists (C-SIDs), describes how to use a single entry in the SRH list as a container for multiple SIDs, and defines a ways to do so. --- 4. A node taking part in this mechanism accomplishes this by using the ARG part [RFC8986] of the Destination address field of the IPv6 header to come up with a new Destination address in some of these flavors. "to come up with" and "flavors" are a bit colloquial. Maybe say "derive" and "mechanisms". --- 4. s/i.e. The/I.e., the/ s/note in here/note here/ --- 4. One key thing to note in here is that the Locator Block at the This is the first time you have used "Locator Block". Is this "LOC" as previously described? --- 4.1. There are a few issues that need to be addressed in the C-SID draft prior to its publication as RFC: Erm, no! You can't have an RFC that chats about the current state of another draft, or that claims it is going to be published as an RFC. Perhaps the best solution is to compress sections 4, 4.1, and 4.2 into a very short note that "Many approaches to SID list compression have been proposed. It is important that any solution preserves the properties of the LOC as described in Section 3." --- 5. All of the SRv6 related specifications discussed above are intended to be applicable to a contained SR Domain or between collaborating SR Domains. Hence the behavior of SRv6 SIDs is visible purely within the SR domain and they would be treated solely as IPv6 routing prefixes by nodes that are not SR aware. What is meant by a behavior being visible? I know that the permeability of SR domain boundaries is something that really worries at least one of the current ADs, and it might be good to spend some time discussing what happens when things go wrong and a packet with a SID in the DA field escapes from the domain (this is distinct from the behavior of a non-SR node within the domain). --- 5. As an added factor of safety, it might be prudent to allocate some "It might be prudent"? Are you asking to allocate this address space or not? address space that explicitly signals that the addresses within that space are not intended to comply with [RFC4291]. As described in "are not intended to comply" means "do not comply"? Section 3 above, there is precedent for mechanisms that use IPv6 addresses in a manner different from that specified in [RFC4291]. This would be useful in identifying and potentially filtering packets at the edges of the SR Domains as described in Section 4.1. The SRv6 operational community, which is the first intended user of this block, is requested to come up with conventions and guidelines for the use of this newly allocated address block in line with their requirements. This sounds like you are: - not proposing any specific use - allocating the address space on the off-chance that someone might find a use for it - not suggesting that deployments (or implementations) actually change their current behavior --- 6. Obviously, there are many ranges in the registry marked as "Reserved by IETF" and IANA will need help selecting one. Also, since this registry is "IESG Approval" it would be timely to approach the IESG and determine whether they are likely to say "yes" or will need further changes to the document. Those changes should happen while the document is still in the working group. --- I'm surprised that section 7 doesn't point back to the "additional safety" described in section 5. In particular, not using that safety would appear to be a risk. On 17-Sep-22 20:00, Jen Linkova 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/ > -------------------------------------------------------------------- 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
