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

From: The IESG <[email-masked]>
Date: Wed, 12 Aug 2020 05:55:49 -0700

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-masked] mailing lists by 2020-08-26. Exceptionally, comments may
be sent to [email-masked] 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/

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Aug 2020 10:06:08 +1200

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:
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 27 Aug 2020 05:10:31 +0000

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>
</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-masked]> 
Sent: viernes, 21 de agosto de 2020 0:06
To: [email-masked]
Cc: [email-masked]; [email-masked]; Bruno Decraene <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Last Call: <draft-ietf-spring-srv6-network-programming-17.txt> (SRv6 Network Programming) to Proposed Standard

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.

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'
> 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-masked] mailing lists by 2020-08-26. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Aug 2020 18:29:20 +1200

Thanks Pablo, that clarifies the point for me.

Regards
   Brian Carpenter

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 27 Aug 2020 13:34:33 +0000

Hi all,

We have just posted revision 18 of draft-ietf-spring-srv6-network-programming.
This revision addresses the comments received from Mirja Kühlewind (TSVART review) [1], Dan Romascanu (OPSDIR review) [2, 3] and Brian Carpenter [4, 5].

Thank you for the reviews and comments.

Regards,
Pablo.

[1] https://datatracker.ietf.org/doc/review-ietf-spring-srv6-network-programming-17-tsvart-lc-kuehlewind-2020-08-18/
[2] https://datatracker.ietf.org/doc/review-ietf-spring-srv6-network-programming-17-opsdir-lc-romascanu-2020-08-20-2/
[3] https://mailarchive.ietf.org/arch/msg/spring/j7ITsbURgg3fMjOZYz_BSEJHAsU/
[4] https://mailarchive.ietf.org/arch/msg/spring/d5uB6XK8C4cxf0jn35RwAtNx46I/
[5] https://mailarchive.ietf.org/arch/msg/spring/fLz9APwWYOsNUD-vIr5fkjZqJPU/

Name:		draft-ietf-spring-srv6-network-programming
Revision:	18
Title:		SRv6 Network Programming
Document date:	2020-08-27
Group:		spring
Pages:		42
URL:            https://www.ietf.org/internet-drafts/draft-ietf-spring-srv6-network-programming-18.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/
Htmlized:       https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-18
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-18

>> final comments on this action. Please send substantive comments to 
>> the [email-masked] mailing lists by 2020-08-26. Exceptionally, 
>> https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-progr
>> a
>> mming/
>>
>>