Thanks Cheng.
It has been a while, but as you say, we talked about this back around -04. I just ran through your resolution of my comments and everything looks good. Cheers, Adrian From: Cheng Li <c...@huawei.com> Sent: 02 September 2024 20:56 To: spring@ietf.org; adr...@olddog.co.uk Cc: draft-ietf-spring-srv6-path-segm...@ietf.org Subject: [Re][spring] Some comments on draft-ietf-spring-srv6-path-segment This is a thread to discuss the comments from Adrian. Thanks to Adrian! I made a mistake that only discuss with co-authors and Adrian( who kindly reviewed the draft and provided his valuable comments), and then submitted the draft revision 04 directly. I copied the content of Adrian's original email below, since the email was too long ago and cannot be found locally. Hi Adrian, please review the revision 04 or the latest revision to see if your comments are addressed. If you have further comments(since this is a fly-by review), you are welcome to share for sure! I also attach the latest revision(10, to be uploaded), please review. Thanks, Cheng ==================================================== 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! [Cheng]You are correct. I added a simple sentence in section 3.1.1 as below. __OLD__ SRv6 Path Segment can follow the format, where the LOC part identifies the egress node that allocates the Path Segment, and the FUNCT part is a unique local ID to identify an SRv6 Path and its endpoint behavior, which is END.PSID (End Function with Path Segment Identifier). __NEW__ SRv6 Path Segment can follow the format, where the LOC part identifies the egress node that allocates the Path Segment, and the FUNCT part is a unique local ID to identify an SRv6 Path and its endpoint behavior, which is END.PSID (End Function with Path Segment Identifier). The code point of END.PSID is 100. The code point has been registered cause the value is FCFS, please see https://www.iana.org/assignments/segment-routing/segment-routing.xhtml 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#segm e> 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. [Cheng]Ok, Bruno also suggested to remove the bit from the figure, so I will do it in the next revision. Please see the diff. My another mistake is that I mistakenly deleted one more paragraph in IANA in revision 05, which is about the P-flag, oh my god, how it could happen. https://author-tools.ietf.org/iddiff?url1=draft-ietf-spring-srv6-path-segmen t-04 <https://author-tools.ietf.org/iddiff?url1=draft-ietf-spring-srv6-path-segme nt-04&url2=draft-ietf-spring-srv6-path-segment-05&difftype=--html> &url2=draft-ietf-spring-srv6-path-segment-05&difftype=--html I have added back the text. ==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]. [Cheng]updated accordingly. --- [] 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 [Cheng]Thank you, updated already, please check --- 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. [Cheng]Ack, please see the update --- 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!) [Cheng]Please see the update, we leave this to other drafts. --- 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." [Cheng]Ack please see the update --- ==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 [Cheng]OK --- 1. s/called "SRv6 Path Segment"/called the "SRv6 Path Segment"/ --- [Cheng]OK 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> https://www.rfc-editor.org/materials/abbrev.expansion.txt marked with an asterisk (*). In this case, that's "MPLS" [Cheng]Deleted --- 3.1 This document proposes two types of SRv6 Path Segment format. Be future-proof! "This document defines..." [Cheng]OK --- 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. [Cheng]We do not prevent the operator to allocate a routable value to it, but we do not use it in routing. --- 4.1 Nothing wrong with Figure 1 (except the alignment of the bit counters) but it seems overkill to draw what the text says. [Cheng]Already updated. Please see the latest revison. https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-path-segment-09 --- Please decide "P-flag" or "P-bit". Probably flag. [Cheng]OK, P-flag --- * <https://mailarchive.ietf.org/arch/msg/spring/AsRF1-XMAbT3yu3GUbvnnU2dyBk/> [spring] Some comments on draft-ietf-spring-srv6-. Adrian Farrel https://mailarchive.ietf.org/arch/msg/spring/AsRF1-XMAbT3yu3GUbvnnU2dyBk/
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
