IETF Logo Mail Archive

Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 11 December 2019 19:37 UTC

Return-Path: <brian.e.carpenter@gmail.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 A93801200E7; Wed, 11 Dec 2019 11:37:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 xuN6dWHGX6oe; Wed, 11 Dec 2019 11:37:00 -0800 (PST)
Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) (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 35826120052; Wed, 11 Dec 2019 11:37:00 -0800 (PST)
Received: by mail-pl1-x642.google.com with SMTP id x17so1823827pln.1; Wed, 11 Dec 2019 11:37:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tt1hWDyrDkdfbamu1NgM5ODCRYuC4ezK/JC33BcwmvM=; b=J955EdIfP0K2T4S+2OwN1cEOo4YNr68ObvoNr7JmZPKgk4IxOVA728CuelFQOBZ5e7 9gJ8yma1077FymiKMaJDDwS/HqBzp+D36EWrDRb2RKXvwVZp13+VFELztSYA3xYTFhm4 4KP0dc6Jo7SzxF+4ujylIdQ7yOiMafVcT8dIeoxgU8w3wCzD09hGO8+sFklz8Pn9mFst j+1rLnjxIizBhkcd/UnmkuoXFmR2S3AJXnQa0EMbYt9WqvWuXlD8lX0yrz7ZRWq9mznH k2focv216z6kP94/vsvM2y4CIf8u5AHqe0t7HNThOO4YDSK0LoqcT8bG4Vjesrx4W/N3 i8xA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tt1hWDyrDkdfbamu1NgM5ODCRYuC4ezK/JC33BcwmvM=; b=d6x2Zknw/XbJwfV5ZjasgPUhUpjALq+Iu/Nyjhnqly1bCCX+PSi0DZgoZchiZT8Qsa L6D8nr8hFmHS0PSONlXXCNnO9mzKaDcROey8pW3Dt6EUyv2jdep3IZjN0LjbTDZjuAYy ICwoMODyg7X5bJfOuXjxgc6CKtwvySx0jnk9YJWKmkuJwsy4jXlRvQqSJF0/T29ll/4c lrgh9FFc03tqpHtVVu3plpqfR99ok7GYagKpAk9kDkDrhSqF/w+8RR+NqSrVC4p5QgSh nZC9x6w6XLIuYrPfRbiG8DA+eXepJFr+jJZ8T+lpvuUK2sVy3qqIrc2FB8gtFiCF51Sj zbqA==
X-Gm-Message-State: APjAAAXskbOm0/6e61W5r++8PO4R0zpGgwruir4zg0F1OlMb8sAVUDDc Q2zy9YVgyI+Km5mVu8TA/M0=
X-Google-Smtp-Source: APXvYqxhTUcEAPHss5RBeUy5hSJUvhx4HILEAB1YQaqrqp+ophcxYN8nGJQlLIGx8+guDkxCz/o/DQ==
X-Received: by 2002:a17:90a:778a:: with SMTP id v10mr5149763pjk.26.1576093019637; Wed, 11 Dec 2019 11:36:59 -0800 (PST)
Received: from [192.168.178.30] (228.147.69.111.dynamic.snap.net.nz. [111.69.147.228]) by smtp.gmail.com with ESMTPSA id w200sm3969379pfc.93.2019.12.11.11.36.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Dec 2019 11:36:58 -0800 (PST)
To: Robert Raszuk <robert@raszuk.net>, Fernando Gont <fgont@si6networks.com>
Cc: Bruno Decraene <bruno.decraene@orange.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, SPRING WG <spring@ietf.org>, "int-ads@ietf.org" <int-ads@ietf.org>, Andrew Alston <Andrew.Alston@liquidtelecom.com>, rtg-ads <rtg-ads@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, Ole Troan <otroan@employees.org>, Suresh Krishnan <Suresh@kaloom.com>
References: <f2a0ad13-0eba-6f5a-1d3c-e45e2780f201@si6networks.com> <a2cc5cbd-ac06-e193-307c-3ffe5b21b0b1@si6networks.com> <80A78F48-9802-4DA9-B264-1A8920C1DDF9@kaloom.com> <c727fb5e-015d-90e2-9860-6c48ce021ac4@si6networks.com> <CAOj+MMEyMDHULL7Pr=QmucTJy9b=3ph9TgTZ7koi9BBLkFCJ6g@mail.gmail.com> <bb767aff-8737-a749-2f99-ac350f66def5@si6networks.com> <CAOj+MMEjzxrEbmKbUn11EsTSnVOZC0cKZhAeXapV2vW++g0ZdA@mail.gmail.com> <885c9ad6-ddd2-392a-7e9f-722509753e2d@si6networks.com> <27448_1575983799_5DEF9AB7_27448_30_1_53C29892C857584299CBF5D05346208A48D245CD@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <5b0f37d2-56a3-5f7f-ab29-7d6ebc2367d5@si6networks.com> <CAOj+MMHoAap_7XZs5HSO+a1C18guFzkg1fkov8Wo6ZqHj=xeHQ@mail.gmail.com> <603cbb85-3b68-5c93-e7c5-3768e6310f48@si6networks.com> <CAOj+MMH2rO_YSLrJDEA5G97ad1jMsJHtZDZ-xP+b==smk-J8Dg@mail.gmail.com> <26f2fff6-f6c8-0e9f-29e6-a180896f5a05@si6networks.com> <CAOj+MMHDOgA54mMWq+ko72e9kW7jk=ut8M31c_XNvAx-hXt6qg@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <fc55e064-5657-21b6-79e3-6785e0c4c03c@gmail.com>
Date: Thu, 12 Dec 2019 08:36:53 +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: <CAOj+MMHDOgA54mMWq+ko72e9kW7jk=ut8M31c_XNvAx-hXt6qg@mail.gmail.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/spring/oZTjNudiJTvgmIHF-A7YYJY2hVc>
Subject: Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))
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: Wed, 11 Dec 2019 19:37:02 -0000

Robert,
On 11-Dec-19 21:29, Robert Raszuk wrote:
> 
> RFC 2473  
> 
> Quotes have been already provided to the lists. 
> 
> When encapsulating a packet I can put whatever EH is defined and when decapsulating the packet I can remove any EH I inserted before. I "own" the new IPv6 header. Very simple. It is like taking the cars on a ferry. 
> 
> Your original packet (call it end to end ... call it original src going to final/ultimate destination) is just a payload. 
> 
> I can not believe that anyone can not grasp such basic concept. 

I think everyone grasps it. I think the problem is that the SRH proponents
use the word "insert" a little ambiguously. In IPv6-land, it's been assumed
to mean "insert an SRH header in the middle of an existing IPv6 packet header".
I suspect that in SRH-land, and in the IPv6 data plane context, it's mainly
being used to mean "encapsulate an IPv6 packet in a new IPv6 packet that includes
an SRH header." And in the MPLS data plane context it means "prepend an additional
MPLS label."

Right or wrong?

   Brian

> 
> 
> 
> On Wed, Dec 11, 2019 at 3:29 AM Fernando Gont <fgont@si6networks.com <mailto:fgont@si6networks.com>> wrote:
> 
>     On 10/12/19 18:50, Robert Raszuk wrote:
>     >
>     > By your books does RFC 2473 or RFC 4798 or 100s of other RFCs which
>     > encapsulate IPv6 packets all violate Internet Standard I presume IPv6
>     > spec ? 
>     >
>     > One of us clearly is missing the point. I will let list members judge
>     > which one :)
> 
>     Could you please point at any RFC that inserts EHs or deletes EHs at any
>     place in the network other than the source or the ultimate destination?
> 
>     -- 
>     Fernando Gont
>     SI6 Networks
>     e-mail: fgont@si6networks.com <mailto:fgont@si6networks.com>
>     PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
>

v2.23.0 | Report a Bug | By Email