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

Robert Raszuk <robert@raszuk.net> Fri, 06 December 2019 16:15 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 9DB9A120833 for <spring@ietfa.amsl.com>; Fri, 6 Dec 2019 08:15:24 -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, HTML_MESSAGE=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=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 1tPjmpC8eFDR for <spring@ietfa.amsl.com>; Fri, 6 Dec 2019 08:15:22 -0800 (PST)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 70E971200B1 for <spring@ietf.org>; Fri, 6 Dec 2019 08:15:22 -0800 (PST)
Received: by mail-qk1-x729.google.com with SMTP id d202so6946012qkb.1 for <spring@ietf.org>; Fri, 06 Dec 2019 08:15:22 -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=brwqoCk49s9BH9vUgAiONeAaWFX/KOg6k+8VLKbNLHM=; b=Tx6O5brTu5t8L5U4kHZfFojSQJ3THfp31LtsXKNBGuy9RID4nxNle3+B4f4Tg+NxqR 8oB/H61Nm7CAW3OuixwHal4ErRLx9mAA7Zt47lKPT1/+XXlAD5Hqkpa7KwatrVzKfL6X 88vhnHDxT4L7eOdAPSeXMuIq5KdyMjVTRdZLuBBAI6d0Jc+Z4PpsHivUX2KDI10MzxcC YlaJuF2kgFAqBEYGet7+gJG1Pf+l/EPMmI6AJkTUvskwoBb6GUl3NzUTPiqUS7cmAmAA GFSUrIe271FybbndOal78QxB5fk3844Fy58xT3uovQV6nYlkx1YL19M/yxACUULuNunW uVfA==
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=brwqoCk49s9BH9vUgAiONeAaWFX/KOg6k+8VLKbNLHM=; b=Go8XpccuZ367Ip2lvoaEDIQdHJ1jE4jxoV5LBra8CLCNnvcFm8ONc65Rx0PpWZTIw6 2H5wucKkFTMxLphrgj2pYBHetuMuawLvoxwIOI4RTqFkvTSofJa/BeZ2+0toN4ft8chV RvmfG7jI4njCacpljwSroSsZFstjzVBizC1+XIy79YerzaIQaYI+r1J+CAMziyl5VJSU wAnTfjlA1zO7QEQi56IMhbKo8L0D0Jp7hYVksz8QKymFWnurYMa8yHnkBO6iXt0Qk2RG w3qC82nZ4LizK8Bi9dKef0NZdZrSnzJ0gjthMs0ti0i2lrDSLOy1hxppryHP18l5jkE9 Ee9A==
X-Gm-Message-State: APjAAAWRVyW4eSrkDZCyfuHDuraHk1JtMZGQ1Vp61X4ZRimXG/qDYGtG ejAOe8OzKakr00vKmhNCaYWNRISHCCajbb5XSSTgJOLa4vw=
X-Google-Smtp-Source: APXvYqyFxZJHbhTKXWKLzah8T1VJakHPC+vGnF/vToQwwRky5mPxbOVAp9o+AhgUjmGjQUPqI6Av2KFHVevO6ona9BE=
X-Received: by 2002:a37:4a0a:: with SMTP id x10mr7715727qka.302.1575648921425; Fri, 06 Dec 2019 08:15:21 -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> <8DEDE597-B7B0-48F5-959E-69757315C2AC@employees.org> <BN7PR05MB56996FFC117F512EEA04AFC8AE5C0@BN7PR05MB5699.namprd05.prod.outlook.com> <4FAB68A3-C533-471D-94D0-3F6EB1F32FC1@employees.org> <1e36a492-5931-02de-cf85-63339522b13a@si6networks.com> <F6DD2C7C-DBBF-4B48-B890-3C86005FB9CF@employees.org> <bb3be82d-8ea7-6c29-ad0a-61b491ee997d@si6networks.com> <8A9BC46E-A018-41C0-BE47-4BABC30EFE79@employees.org> <20191205222740.GA9637@ernw.de> <C7BCB0CF-1CA3-4CA8-9E71-13A013955938@employees.org> <E3C0E460-9329-40B1-ACF6-B9D8F6E2B3DF@steffann.nl>
In-Reply-To: <E3C0E460-9329-40B1-ACF6-B9D8F6E2B3DF@steffann.nl>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 06 Dec 2019 17:15:12 +0100
Message-ID: <CAOj+MMHEb4c_bGH-sV9LC+baHJZisTsXUMpTJNbR1j-YEcyqwA@mail.gmail.com>
To: Sander Steffann <sander@steffann.nl>
Cc: SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>, "int-ads@ietf.org" <int-ads@ietf.org>, rtg-ads <rtg-ads@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000040b0a505990b5a6b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/9nn2VKK8NNz2nDOrOyCMyBF46vM>
Subject: Re: [spring] 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: Fri, 06 Dec 2019 16:15:24 -0000

Hi Sander,

To your specific first question this is very popular deployment model ..
just look at SDWANs. So Internet is just a L3 transport for all routers in
your administrative domain or global WAN. Spot on. I do sincerely hope that
whatever the result be of this debate all features will be legal to run on
my boxes regardless how I choose to interconnect them.

As (Internet) transit boxes would never be destination addresses of the
outermost header what problem do you see running anything one likes on R1
or R2 or R3 and transporting it via open Internet or perhaps some third
party networks ?

Just pls limit the answer to technical points if at all possible.

And if your first point is MTU then assume I have this solved by code
running between my routers in the overlay even including making sure that
my probe is inline with the data - hence identical ECMP hashing.

Best,
R.


On Fri, Dec 6, 2019 at 4:13 PM Sander Steffann <sander@steffann.nl> wrote:

> Hi Ole,
>
> > If I own and manage three routers, R1 -- R2 -- R3.
> > You are saying that if R1 sends a packet to R3, it is not allowed to
> off-load some functions to R2?
> > Going to be difficult to do stuff like service chaining then.
>
> This bit I don't mind that much, but what about:
>
> R1 -- R2 -- [open internet] -- R3
> or
> R1 -- [open internet] -- R2 -- R3
> or even
> R1 -- [open internet] -- R2 -- [open internet] -- R3
>
> And what if you're an ISP and R1 is your customer's device? It is in your
> routing domain but not in your administrative domain. What then?
>
>