Hi Rajesh,
The extension header chain is processed as defined in RFC8200. If you get to the upper layer header, it is indeed processed as per section 4.1.1. This is no different than any other behavior, hence there is no reason to call this out explicitly on this one and not the others. Thanks Regards … Zafar From: Rajesh M <mraj...@juniper.net> Date: Monday, September 14, 2020 at 5:36 AM To: "Zafar Ali (zali)" <z...@cisco.com>, "Ketan Talaulikar (ketant)" <ket...@cisco.com>, "Pablo Camarillo (pcamaril)" <pcama...@cisco.com> Cc: "G. Sri Karthik Goud" <gkart...@juniper.net>, Deepti Rathi <deep...@juniper.net>, SPRING WG <spring@ietf.org> Subject: SRV6 OAM (USP SID) When ingress pings a USP SID, at the egress below code is executed. 4.16.2<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-18#section-4.16.2>. USP: Ultimate Segment Pop of the SRH The SRH processing of the End, End.X and End.T behaviors are modified: the instructions S02-S04 are substituted by the following ones: S02. If (Segments Left == 0) { S03.1. Update the Next Header field in the preceding header to the Next Header value of the SRH S03.2. Decrease the IPv6 header Payload Length by the Hdr Ext Len value of the SRH S03.3. Remove the SRH from the IPv6 extension header chain S03.4. Proceed to process the next header in the packet S04. } May be we should explicitly state here “if next header is Upper layer header then execute section 4.1.1” Juniper Business Use Only
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
