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 <[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
