Re: [spring] Network Programming - Penultimate Segment Popping
Robert Raszuk <robert@raszuk.net> Sat, 07 December 2019 16:49 UTC
Return-Path: <robert@raszuk.net>
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 A7A1512004F for <spring@ietfa.amsl.com>; Sat, 7 Dec 2019 08:49:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 IeR6nFxppfog for <spring@ietfa.amsl.com>; Sat, 7 Dec 2019 08:49:09 -0800 (PST)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 22EB012002E for <spring@ietf.org>; Sat, 7 Dec 2019 08:49:09 -0800 (PST)
Received: by mail-qk1-x72f.google.com with SMTP id s25so4377937qks.3 for <spring@ietf.org>; Sat, 07 Dec 2019 08:49:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U2TmFU7Nk2V0Qa9yoFAYCvDuNttUk62TIKW08T0rVjY=; b=a0S7wWGQ2Gvl0SL9FOoQQYKvCd8SuDH2ktZuY0PGulcI8oLHPILo+9p1AsjDt9i4BD I0rdWqRFPD2JqNBLacLdQq8phBE2IEiUet0dKKxZ9vLaTp2BZmjGeKMrlBCMUmerScHM +kUaxoffjgQKph17JURUtTmsObRWXYWsV3h9DOQYbg/QWIlEjcFbpVV+izIhYALZUSTc 9DcOUk18wtH1ay3i+J0KT8Dh4Oa0Vy9P5WoKgxrAxTpgph0bBDfb6/h4WSN01ieGGCIG Egbzi0fnw0NSxMf/L6LO1X+sqoBoDpDv9L+XuaQiwzAhoR+nd01MBRxo+yPMXhWqhrcn KGcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U2TmFU7Nk2V0Qa9yoFAYCvDuNttUk62TIKW08T0rVjY=; b=KXRhjPVyDfPQPJK6i+b2K7hoyQG4nlY4R/pO0+pNM/qbqUDpAhT7DIPAp1dmwjTpi5 F2yNOW7w2GUbv4KlQwLJHJdO68ux5DLw6YGH5ljVX2KARlyCoiJYHZDXi1auiDeJgM9A F2tyhHrZoy4F4j6Vw5cGPG0UaZXPfNV3jjTD0iMoCoqiFCnlNQhUcdpevue6fvHHayVH jIWvwf5FnheB1xfCu0qeqNq+asJAZMApDqA4xFRP7YrR0KRterFNFaAxVk/1FvbynHCA KaAFJfWyh3/DYXwxSk9mdZLyHWVGROtwzVflGZ2o0uQTjP7zUSxswi3BoGRuqMWCXHva lVKg==
X-Gm-Message-State: APjAAAXAmnz67HKeW4ZRTLuw6VCtSzaX/KjbuajHx03ytr6Upduy/PJg xiXJn2Qy0F3CYNZJNSfN6AFgwtK7hBECMwa/9bezsw==
X-Google-Smtp-Source: APXvYqwy54yAqmKK1jH4omaEAGBeZCWN8/stWT5YiuQS3sYtpeVrnZRI5knOKp7lB+GKttDV1GDqTLwgsGRfykuEirU=
X-Received: by 2002:ae9:e887:: with SMTP id a129mr2290872qkg.465.1575737347043; Sat, 07 Dec 2019 08:49:07 -0800 (PST)
MIME-Version: 1.0
References: <BN7PR05MB56998A05469327E759B5B671AE5D0@BN7PR05MB5699.namprd05.prod.outlook.com> <3AD3BD11-8C34-41FE-B88F-49A9F2561D78@cisco.com> <BN7PR05MB569946D6AA5C6B78AFC05F6BAE5C0@BN7PR05MB5699.namprd05.prod.outlook.com> <D6B1AED6-0AB2-4394-9503-7A1885BC8B40@cisco.com> <BN7PR05MB5699C73EF0EE1F8E7A96C738AE5F0@BN7PR05MB5699.namprd05.prod.outlook.com> <7B7CFEB8-80F0-4690-9BE3-8D5F935E148A@cisco.com> <CALx6S375sPG3jNybNbyA5eAUKTefGy_=LKBcmhfEhc5-B4e1OQ@mail.gmail.com>
In-Reply-To: <CALx6S375sPG3jNybNbyA5eAUKTefGy_=LKBcmhfEhc5-B4e1OQ@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 07 Dec 2019 17:48:59 +0100
Message-ID: <CAOj+MMGFwr62x3Grnmjd+3zn1-duQUDiVESa2hLGpWHscmFHxg@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
Cc: "Darren Dukes (ddukes)" <ddukes@cisco.com>, Ron Bonica <rbonica@juniper.net>, SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d4828f05991ff0af"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/hT-cK-IO0oi_euWbXXZ-IqO-MUA>
Subject: Re: [spring] 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: Sat, 07 Dec 2019 16:49:11 -0000
Tom, > If intermediate hosts in the routing list are able to add or remove SRH per RFC8200 "Routing list" contained in SRH does not matter at all here in terms of compliance with RFC8200. At each segment midpoint the outer IPv6 destination is *rewritten*. For illustrative purposes you may visualize like outer IPv6 header is removed and new IPv6 header is added with new destination address at each segment midpoint. It is this principal of SRv6 operation which is being used and which in no way contradicts nor stretches RFC8200 as it is written today. Besides it is basic thing that SR segment may end in the middle of the network then native routing will take the packet to the dst. Is that also being considered violation of something ? Your analogy to NAT is pretty false as NAT box is never an intended destination of the packet. All the best, R. On Sat, Dec 7, 2019 at 5:27 PM Tom Herbert <tom@herbertland.com> wrote: > On Sat, Dec 7, 2019 at 7:10 AM Darren Dukes (ddukes) <ddukes@cisco.com> > wrote: > > > > Ron, you say > > >> RFC 8200 addresses extension header insertion and deletion > identically, in the same sentence. > > > > This sentence you refer to clearly permits PSP as defined in network > programming: > > 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. > > > > Clearly we process the SRH at the node identified in the destination > address field of the IPv6 header. > > With PSP we remove the SRH at the node identified in the destination > address field of the IPv6 header. > > > Darren, > > I believe you are assuming a very liberal interpretation of the > wording in RFC8200. If intermediate hosts in the routing list are able > to add or remove SRH per RFC8200, then they are allowed to add or > remove any and all extension headers per the same interpretation. I do > not believe that is at all the intent of RFC8200. Also note that the > liberal interpretation it would validate other cases of arbitrary > extension header manipulation like in NAT devices for instance. > > Tom > > > I think it’s clear we can conclude this thread. > > > > Darren > > > > > > > > On Dec 6, 2019, at 5:01 PM, Ron Bonica <rbonica@juniper.net> wrote: > > > > >> I have observed, in your original post, the conflation of SRH > insertion within an SR Domain with the PSP behavior defined in network > programming. > > >> Whether this was intentional or not, I do not know. > > >> Regardless, it is wrong. > > > > Darren, > > > > We clearly disagree. RFC 8200 addresses extension header insertion and > deletion identically, in the same sentence. > > > > > > Ron > > > > > > > > > > > > > > Juniper Business Use Only > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
- [spring] Network Programming - Penultimate Segmen… Ron Bonica
- Re: [spring] Network Programming - Penultimate Se… Fernando Gont
- Re: [spring] Network Programming - Penultimate Se… Darren Dukes (ddukes)
- Re: [spring] Network Programming - Penultimate Se… Ron Bonica
- Re: [spring] Network Programming - Penultimate Se… Fernando Gont
- Re: [spring] Network Programming - Penultimate Se… otroan
- Re: [spring] Network Programming - Penultimate Se… Ron Bonica
- Re: [spring] Network Programming - Penultimate Se… otroan
- Re: [spring] Network Programming - Penultimate Se… Fernando Gont
- [spring] We don't seem to be following our proces… Fernando Gont
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Tom Herbert
- Re: [spring] We don't seem to be following our pr… Ron Bonica
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Enno Rey
- Re: [spring] We don't seem to be following our pr… Enno Rey
- Re: [spring] We don't seem to be following our pr… Ron Bonica
- Re: [spring] We don't seem to be following our pr… Bob Hinden
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Joel M. Halpern
- Re: [spring] We don't seem to be following our pr… Sander Steffann
- Re: [spring] We don't seem to be following our pr… Tom Herbert
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Sander Steffann
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Bob Hinden
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Tom Herbert
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Andrew Alston
- Re: [spring] We don't seem to be following our pr… Andrew Alston
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Ron Bonica
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Ron Bonica
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] Network Programming - Penultimate Se… Darren Dukes (ddukes)
- Re: [spring] Network Programming - Penultimate Se… Ron Bonica
- Re: [spring] We don't seem to be following our pr… Ole Troan
- Re: [spring] We don't seem to be following our pr… Andrew Alston
- Re: [spring] We don't seem to be following our pr… Sander Steffann
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- [spring] Separating issues (was Re: We don't seem… Suresh Krishnan
- [spring] Penultimate Segment Popping and RFC8200 … Suresh Krishnan
- Re: [spring] Separating issues (was Re: We don't … Ketan Talaulikar (ketant)
- Re: [spring] Penultimate Segment Popping and RFC8… Ketan Talaulikar (ketant)
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Alexandre Petrescu
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Network Programming - Penultimate Se… Darren Dukes (ddukes)
- Re: [spring] Network Programming - Penultimate Se… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Darren Dukes (ddukes)
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: [spring] Network Programming - Penultimate Se… Tom Herbert
- Re: [spring] Network Programming - Penultimate Se… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Brian E Carpenter
- Re: [spring] Penultimate Segment Popping and RFC8… Adrian Farrel
- Re: [spring] We don't seem to be following our pr… Brian E Carpenter
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] We don't seem to be following our pr… bruno.decraene
- Re: [spring] Penultimate Segment Popping and RFC8… bruno.decraene
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Mark Smith
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Brian E Carpenter
- Re: [spring] Penultimate Segment Popping and RFC8… bruno.decraene
- Re: [spring] Penultimate Segment Popping and RFC8… Pablo Camarillo (pcamaril)
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- [spring] Non-final destination address (was Re: P… Suresh Krishnan
- Re: [spring] Non-final destination address (was R… Fernando Gont
- Re: [spring] Non-final destination address (was R… Suresh Krishnan
- Re: [spring] Non-final destination address (was R… Fernando Gont