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
> [email protected] mailing lists by 2020-08-26. Exceptionally, comments may
> be sent to [email protected] 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
