Hi Brian,
The PSP behavior is only applied to received packets when (Segments Left =1 &
Destination Address = PSP SID).
The PSP behavior pseudocode describes the local processing of this packet, and
the check for Segments Left == 0 is an intermediate step of that local
processing. This local processing might be implemented in different ways as
long as the externally observable wire protocol is preserved.
In order to clarify this, we propose the diff below.
Thank you,
Pablo.
<OLD>
The following sub-sections detail the behaviors, introduced in this
document, that a node (N) binds to a SID (S).
Section 4.16 defines flavors of some of these behaviors.
4.1. End: Endpoint
</OLD>
<NEW>
The following sub-sections detail the behaviors, introduced in this
document, that a node (N) binds to a SID (S).
The pseudocode describing these behaviors detail local processing at a
node. An implementation of the pseudocode is compliant as long as the
externally
observable wire protocol is as described by the pseudocode.
Section 4.16 defines flavors of some of these behaviors.
4.1. End: Endpoint
</NEW>
<OLD>
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.
</OLD>
<NEW>
The End, End.X and End.T behaviors with PSP do not contravene
Section 4 of [RFC8200] because the destination address of the incoming
packet is the
address of the node executing the behavior.
</NEW>
-----Original Message-----
From: Brian E Carpenter <[email protected]>
Sent: viernes, 21 de agosto de 2020 0:06
To: [email protected]
Cc: [email protected]; [email protected]; Bruno Decraene
<[email protected]>; [email protected];
[email protected]
Subject: Re: Last Call: <draft-ietf-spring-srv6-network-programming-17.txt>
(SRv6 Network Programming) to Proposed Standard
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-progra
> mming/
>
>
> 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
