Re: [spring] Last Call: <draft-ietf-spring-srv6-network-programming-17.txt> (SRv6 Network Programming) to Proposed Standard

Thanks Pablo, that clarifies the point for me.

Regards
   Brian Carpenter

On 27-Aug-20 17:10, Pablo Camarillo (pcamaril) wrote:
> 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 <brian.e.carpenter@gmail.com> 
> Sent: viernes, 21 de agosto de 2020 0:06
> To: last-call@ietf.org
> Cc: spring@ietf.org; spring-chairs@ietf.org; Bruno Decraene <bruno.decraene@orange.com>; jmh@joelhalpern.com; draft-ietf-spring-srv6-network-programming@ietf.org
> 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 
>> last-call@ietf.org mailing lists by 2020-08-26. Exceptionally, 
>> comments may be sent to iesg@ietf.org 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
>> IETF-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>
> 