IETF Logo Mail Archive

Re: PSP and a logical application of RFC8200

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 02 March 2020 19:33 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A1B3A0FCB; Mon, 2 Mar 2020 11:33:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 eVapTuxnHpaX; Mon, 2 Mar 2020 11:33:57 -0800 (PST)
Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B283A0FCC; Mon, 2 Mar 2020 11:33:57 -0800 (PST)
Received: by mail-pf1-x441.google.com with SMTP id s1so191511pfh.10; Mon, 02 Mar 2020 11:33:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=BbDO6dbMukEbYPoctBxcAuxpzM2IxXos8NE/yOfCtE4=; b=E93IUxhFeZAvrwPaCJgRsH0fzn4oGQN1qrern2R51AK3iyy7cnl5ypWUyHZt7u/7lK UKPPEkCENW1doBR2JQpm90v+kDZ6XUeGGyzQM44gbR4pTIstasQWT+WauD6q7tAyQ1Ou F/bCExqzpWaQ2Z+AZzWpuigth5zXmRzMy3jraVaKSJv4PuXZC5bHtZ79A/v3ukTfgKbs q7m+e4fbOoSBkUaF5/AO3ZomIkXmdN2OFaMH58pL/WC/Gywrd5wCvo+qABetO+1Tuto9 gv9oFv4JVQIrbg6a9H/G7LBkE4Ld01AXSA1HANDLGrQfCGiyaivj58XBMqYzC0H1HQDZ +3qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BbDO6dbMukEbYPoctBxcAuxpzM2IxXos8NE/yOfCtE4=; b=RUHhs1+qtPMvYSfUbRKrEEjMms5zw/N35AsmX6bOSjDvmYITvwVI5/2u4yRC545TlW V36CGe9bwg8sISsCPras2T6Dqsub8l7ulChFyrVoxvP6TaN87JqUA0zpgOmGoW2gPnqw 9J6op2G7Gm4O8YLNMD4+XsypoW7BtdpGVJjeDXD9m2n/czdVD12tWdfPAm/UsR/4Cnrc omw12l0OXmg1HHdJC/Z6EQs/uLvAOCutk/EKtpQWdRWZi6UiDvmokBMWvTJkCEMBxSz6 hAAQV+xLa+IW4Xdsc6az2m3kD6gyTJ2uO9Oe8fseSD90POKvOAbmrDbX6nhi6vybzw8M lLPw==
X-Gm-Message-State: ANhLgQ25L1KU0qA76RpdniZDGRe8v5w2iXFuV7O8UQj1ikwIhWIZudDI fXP+jecH6ynq0sHsZ5AoOcCFMDau
X-Google-Smtp-Source: ADFU+vu2wgB8JXd2wpaHnUDBoiPmVhvrMsH3kprPB/++49tMRIvPwPsDidS30H6P0nvukQyG0mBy4w==
X-Received: by 2002:a63:af58:: with SMTP id s24mr444073pgo.15.1583177636769; Mon, 02 Mar 2020 11:33:56 -0800 (PST)
Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id l62sm8737042pgd.82.2020.03.02.11.33.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2020 11:33:56 -0800 (PST)
Subject: Re: PSP and a logical application of RFC8200
To: "Darren Dukes (ddukes)" <ddukes=40cisco.com@dmarc.ietf.org>, 6man WG <ipv6@ietf.org>, SPRING WG List <spring@ietf.org>
References: <39544C17-1AD0-412E-A8BD-E17376537FCF@cisco.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <bf9d68e6-cbae-2b19-11e0-1e452f0bf654@gmail.com>
Date: Tue, 03 Mar 2020 08:33:54 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <39544C17-1AD0-412E-A8BD-E17376537FCF@cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/slbvORte0AfnsYaigT02VSRyq8E>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2020 19:33:59 -0000

Darren,

Regardless of whether you accept Fernando's comment about the intention of RFC 8200, there is also the fact that the description of the PSP flavor cheats by considering 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)
or
 (Segments Left == 0 and Destination Address == the final node's address)

OK, maybe it's not cheating, maybe it's only a side effect of the pseudocode, but the fact is that the test "S14.1.   If (Segments Left == 0) {" in section 4.16.1 is very confusing because it's applied to a packet that is half way through processing of the routing header (Segments Left has been updated, but Destination Address has not been updated). This makes it very unclear how the spec is claiming to interpret RFC 8200.

Regards
   Brian Carpenter

On 03-Mar-20 03:52, Darren Dukes (ddukes) wrote:
> What follows has been made clear on the list for a while, 
> I am re-stating it.
> 
> The draft-ietf-spring-srv6-network-programming PSP behavior 
> strictly follows the letter of RFC 8200.
>  
>      RFC8200 section 4 says:
>  
>      Extension headers (except for the Hop-by-Hop Options header) are not
>      *processed, inserted, or deleted* by any node along a packet's delivery
>      path, until the packet reaches *the node* (or each of the set of nodes,
>      in the case of multicast) *identified in the Destination Address field*
>     * of the IPv6 header.*
>   
> 
> The processing, insertion and deletion restrictions only apply 
> “until the packet reaches the node identified in the Destination
> Address field of the IPv6 header”.
>  
> At the penuptimate segment of the segment list, the endpoint IS
> “the node identified in the Destination Address field of the IPv6
> header” and hence the PSP operation programmed by the source SR 
> node strictly follows the letter of RFC 8200.
> 
> 
> Thanks,
>   Darren
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

v2.23.0 | Report a Bug | By Email