Hi, This is a bit of a "fly-by" review. I happened to need to read the draft to check on the use of SRH flags, so here are a few quick comments. I hope they are useful.
Best, Adrian ==Medium== General Some of my points below are cleared up when I finally got to Section 7 and discovered that you are asking for a new Endpoint Behavior to be assigned. I think that means it *is* possible to detect that a PSID is present at the wrong place in the stack *if* the processing node knows enough to look at the endpoint behaviour and understand it. However, the only (clear) mention of the new endpoint behaviour is in Section 7: TBA1 should be mentioned in the text somewhere! --- 4.1 Here you are attempting to state which bit is used as the P-flag. But there is a registry for the SRH Header flags (at https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segme nt-routing-header-flags) so you should leave this as bit number TBD, and specifically ask IANA to assign *a* bit. You do actually do this in Section 7 but it is in conflict with 4.1. Note that the registry is IETF review which does allow early assignment if you want to get the flag agreed for early implementation and interop etc. ==Minor== Section 1 In an SR-MPLS network, when a packet is transmitted along an SR path, the labels in the MPLS label stack will be swapped or popped, so no label or only the last label may be left in the MPLS label stack when the packet reaches the egress node. Thus, the egress node can not determine from which ingress node or SR path the packet came from. Therefore, to identify an SR-MPLS path, a Path Segment is defined in [I-D.ietf-spring-mpls-path-segment]. Likewise, a path needs to be identified in an SRv6 network for several use cases such as binding bidirectional paths [I-D.ietf-pce-sr-bidir-path] and end-to-end performance measurement [I-D.gandhi-spring-udp-pm]. This all reads like the main use case in SR-MPLS is source identification, and that bidirectional path binding and PM are special for SRv6. I suggest reversing the order of the paragraphs so... In SR, a path needs to be identified for several use cases such as binding bidirectional paths [I-D.ietf-pce-sr-bidir-path] and end-to- end performance measurement [I-D.gandhi-spring-udp-pm]. Additionally, in an SR-MPLS network, when a packet is transmitted along an SR path, the labels in the MPLS label stack will be swapped or popped, so no label or only the last label may be left in the MPLS label stack when the packet reaches the egress node. Thus, the egress node can not determine from which ingress node or SR path the packet came from. To identify an SR-MPLS path, a Path Segment is defined in [I-D.ietf-spring-mpls-path-segment]. --- 1. An SRv6 Path Segment MUST NOT be copied to the IPv6 destination address, so it is not routable. I think this is back-to-front... An SRv6 Path Segment is not routable (it is just an abstract 128 bit identifier) so it MUST NOT be copied to the IPv6 destination address. --- Usually, we don't use BCP 14 language (you have MAY and MUST NOT) in the Introduction. It is supposed to be introducing the concepts not defining behaviour. There are ways around this: - use lower case (and sometimes reword) - reduce the Introduction and move the normative language to later --- 4.1 o P-bit: set when SRv6 Path Segment is inserted. It MUST be ignored when a node does not support SRv6 Path Segment processing. Well, some nodes not supporting SRv6 Path Segment processing don't understand the P flag and have never read this document. So you can't tell them in this document what to do! You have to refer them back to 8754 with something like o P-bit: set when SRv6 Path Segment is inserted. A node that does not understand the P-bit will ignore it as described in [RFC8754]. A node that understands the P-flag but does not support SRv6 Path Segment processing MUST ignore the P-bit. However, what is missing, I think is what happens at an egress node when the P-flag is set and the egress either doesn't understand or doesn't support SRv6 Path Segments. In this case, the P-flag will be ignored, but what will happen to the PSID? Will processing be attempted? You might argue that "A Path Segment is a local segment allocated by an egress node, so this situation cannot happen." But I would say that is "should not happen" because there are ingress errors, and there are timing windows. So you need to describe this edge case. --- 5. When a Path Segment is allocated by the egress, it MUST be distributed to the ingress node of the path that identified by the path segment. In this case, only the egress will process the Path Segment, and other nodes specified by SIDs in the segment list do not know how to process the Path Segment. Depending on the use case, a Path Segment may be distributed to the SRv6 nodes along the SRv6 path. In this case, the SRv6 nodes that learned the Path Segment may process the Path Segment depending on the use case. This is pretty unclear about how the distribution happens. I think you either need to describe or reference the mechanisms, or you have to be clear that the distribution mechanisms are for future study (although, in that case, it is debatable whether there is any value to this document!) --- 6. An SRv6 Path Segment that appears at any other location in the SID list will be treated as an error. Will it, though? Or will an attempt be made to treat it as some other form of SID causing unpredictable behaviour? That is, regardless of the P-flag, if a PSID is inserted into the middle of a SID stack, an attempt will be made to process it (possibly resulting in an error, or possibly resulting in the packet being forwarded on an address that should not be treated as routable). But is there any way to know that the PSID is at the wrong location (or present multiple times)? So, I think you are fine to say "MUST be bottom of stack" and "MUST NOT appear at other locations." But all that you can say beyond that is that "placing a PSID at any location in the SID list will result in unpredictable forwarding behavior." --- ==Nits== Section 1 OLD from which ingress node or SR path the packet came from. NEW from which ingress node or SR path the packet came. END --- 1. s/called "SRv6 Path Segment"/called the "SRv6 Path Segment"/ --- 1.2 You don't need to include terms that appear at in the RFC Editor's list at https://www.rfc-editor.org/materials/abbrev.expansion.txt marked with an asterisk (*). In this case, that's "MPLS" --- 3.1 This document proposes two types of SRv6 Path Segment format. Be future-proof! "This document defines..." --- 3.1.1 Here you appear to say that the SRv6 Path Identifier can be routable (i.e., is built with as LOC:FUNCT), but in the Introduction you are adamant that it is not routable. --- 4.1 Nothing wrong with Figure 1 (except the alignment of the bit counters) but it seems overkill to draw what the text says. --- Please decide "P-flag" or "P-bit". Probably flag. --- _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
