IMHO there is still a logical defect in the description of the PSP flavor at https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-17#section-4.16.1 The description of the PSP flavor considers the packet to have (Segments Left == 0 and Destination Address == the PSP node's address). In fact that is *never* the state of the packet on the wire, which is either (Segments Left == 1 and Destination Address == the PSP node's address) when the packet arrives, or (Segments Left == 0 and Destination Address == the final node's address) when the packet departs. So the text does not refer a packet on the wire, whereas RFC8200 only refers to packets on the wire. Thus the test "S14.1. If (Segments Left == 0) {" in section 4.16.1 is confusing because it's applied to a packet that is half way through processing of the routing header inside the node (Segments Left has been updated, but Destination Address has not been updated). This makes it unclear how the spec is claiming to interpret RFC 8200. (This was pointed out a long time ago: https://mailarchive.ietf.org/arch/msg/spring/Xrcclo0s4pnug9upG9rUinYMv1I/ ) The text: > This behavior does not contravene Section 4 of [RFC8200] because the > current destination address of the incoming packet is the address of > the node executing the PSP behavior. is being applied to a packet that never exists on the wire, but only inside the PSP node. Regards Brian Carpenter On 13-Aug-20 00:55, The IESG wrote: > > The IESG has received a request from the Source Packet Routing in Networking > WG (spring) to consider the following document: - 'SRv6 Network Programming' > <draft-ietf-spring-srv6-network-programming-17.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@xxxxxxxx mailing lists by 2020-08-26. Exceptionally, comments may > be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > > The SRv6 Network Programming framework enables a network operator or > an application to specify a packet processing program by encoding a > sequence of instructions in the IPv6 packet header. > > Each instruction is implemented on one or several nodes in the > network and identified by an SRv6 Segment Identifier in the packet. > > This document defines the SRv6 Network Programming concept and > specifies the base set of SRv6 behaviors that enables the creation of > interoperable overlays with underlay optimization (Service Level > Agreements). > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ > > > The following IPR Declarations may be related to this I-D: > > https://datatracker.ietf.org/ipr/3464/ > > > > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf-announce > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
