IETF Logo Mail Archive

Re: [spring] PSP and a logical application of RFC8200

Fernando Gont <fgont@si6networks.com> Mon, 02 March 2020 21:16 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0237B3A11CB; Mon, 2 Mar 2020 13:16:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcfSQiP2-_xU; Mon, 2 Mar 2020 13:16:01 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A58F3A11C8; Mon, 2 Mar 2020 13:16:01 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id D6E9C8321D; Mon, 2 Mar 2020 22:15:56 +0100 (CET)
To: "Darren Dukes (ddukes)" <ddukes=40cisco.com@dmarc.ietf.org>
Cc: SPRING WG List <spring@ietf.org>, 6man WG <ipv6@ietf.org>, "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <39544C17-1AD0-412E-A8BD-E17376537FCF@cisco.com> <bf9d68e6-cbae-2b19-11e0-1e452f0bf654@gmail.com> <FD806998-8218-4C70-B383-332C5F934A73@cisco.com> <cd7cbeef-d502-20d8-fdd6-ba8473acb6fd@si6networks.com> <404D363B-57F7-44E8-93C2-461955E02043@cisco.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <23fff68d-ab08-f9a7-428f-c2ec72a189a1@si6networks.com>
Date: Mon, 02 Mar 2020 18:15:37 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <404D363B-57F7-44E8-93C2-461955E02043@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/ZmLsZp3oSeUIJckUJodj_AVwITo>
Subject: Re: [spring] PSP and a logical application of RFC8200
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2020 21:16:10 -0000

On 2/3/20 18:09, Darren Dukes (ddukes) wrote:
> Fernando, you are wrong.  SRH processing only occurs at the segment endpoint, there is no "processing the routing header again”.

Does the fact that PSP stands for "Penultimate Segment Pop" ring any bells?

PSP specifies en-route removal of IPv6 extension headers. This violated 
RFC8200 that prohibits such behaviour, and also violates the 
specification of routing headers.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

v2.23.0 | Report a Bug | By Email