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

Robert Raszuk <robert@raszuk.net> Tue, 10 December 2019 23:39 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 CBB96120059 for <spring@ietfa.amsl.com>; Tue, 10 Dec 2019 15:39:33 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 zq4Pn2Fol6-b for <spring@ietfa.amsl.com>; Tue, 10 Dec 2019 15:39:30 -0800 (PST)
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 249BF120113 for <spring@ietf.org>; Tue, 10 Dec 2019 15:39:30 -0800 (PST)
Received: by mail-qv1-xf35.google.com with SMTP id t7so4965437qve.4 for <spring@ietf.org>; Tue, 10 Dec 2019 15:39:30 -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=tChW8E1v15jzUASGrY75qLdpJ/tfEA7Y3eXODiHgkAE=; b=AnzUV9oKrcKQqm9rtGJMIpUKMJ/zq+BIb2xF7JJLxK3qtm0ifxWhq3HBbKGHrZuhY9 RJf+J9jZxOG6MhxNoBsg3WFg2pJOpbeJ4xlW0fTh3JvCabyS8IbwcSZ83ApsZLTx3Q87 FTz7J2caurZpM0KFqxarGtWlh9xJRgzv2sELwa9WejbTaJrqqM/DdXmpzBUNLK7dqDbO JF2InhaUfP2ZzEEO2zA/D/44DmVn+FDfF40vtW1mjtVCDZAY/ffbM2vfqgNUxKXCx3pd 1PL9gYVsW1qCXz79wdE/WoCVNGpgf/VB+DFobZXU/2W/6xzyoTt5Pn7XbNedjBa0aDnB U8kA==
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=tChW8E1v15jzUASGrY75qLdpJ/tfEA7Y3eXODiHgkAE=; b=O8HF9PkrckxKKj7MaYegCuINSNB0fZCmylMx2yL1bIODCPNgdtoBPxPpFUlN4ptDnA lbChhTdIYB4bImX5zM3TcT7I+8hi6NvAbmO5g1i/YAl7CJ9Vc/If/3MtVsA5a01pwYDH C1MvPrtjoiHqTRTztBVtlNiaFKOz+tUrBeJpVaB1RpjIhxK5J0SEYy55DTpKjp2jEhKB aCXxt+FDupg605p1hXMPMHu3kshY/9tB6ZGT9W4TbiOZSulTVFA3lEjdGsOckAtx06ja EF8HRB6O9Ah260NfOnfE1hGLDEe5EEfP1tiFEAs63dVh4I/EfPWGwbQRQl4pmjndfb+z 2KCw==
X-Gm-Message-State: APjAAAUg1vmN4sC83hgmJlzgwlgSL6tz4yuhwmISQiEbRuieJ7CsEVYh V+jPnTDW7GhHvtOfv3VkKDOFuqGQlRBzxaVnDeN2nQ==
X-Google-Smtp-Source: APXvYqyVL+0cYsGQugVH/kMHzhZRXw8Yi1ivRWIZ67d0XQNJHD+uPwbKp8ZYKthYE4dIGny024tnVuH85DlOSIR5WJM=
X-Received: by 2002:a0c:e84d:: with SMTP id l13mr424057qvo.53.1576021169073; Tue, 10 Dec 2019 15:39:29 -0800 (PST)
MIME-Version: 1.0
References: <f2a0ad13-0eba-6f5a-1d3c-e45e2780f201@si6networks.com> <D666EA6E-E8E9-439A-9CDE-20857F03CB65@employees.org> <4255AD3B-379C-45BF-96E1-D3D9141A684F@liquidtelecom.com> <d59de54e-c7f8-be67-1e77-b051735d40a6@gmail.com> <3bce7b18-ea45-d29f-5dfb-1d3258b07d1e@si6networks.com> <c6e1f690-b0bf-9f45-8fa7-92ed182c5b04@gmail.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>
In-Reply-To: <5b0f37d2-56a3-5f7f-ab29-7d6ebc2367d5@si6networks.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 11 Dec 2019 00:39:18 +0100
Message-ID: <CAOj+MMHoAap_7XZs5HSO+a1C18guFzkg1fkov8Wo6ZqHj=xeHQ@mail.gmail.com>
To: 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>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Ole Troan <otroan@employees.org>, Suresh Krishnan <Suresh@kaloom.com>
Content-Type: multipart/alternative; boundary="000000000000f1088f05996205f2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/5B0PnFpt3lfZ5AMyyHfbiDVA4Dk>
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: Tue, 10 Dec 2019 23:39:34 -0000

Dear Fernando,

Allow me to make something very clear here.

And, since we are at it, please let me know if IPv6 is and end to end
> protocol. And, if it is, how does that e2e-ness work with inserting and
> removing EHs on the path to the ultimate destination of a packet.
>

The dream of IPv6 flat end to endless is long gone if it ever was
even real.

There is no end to end IPv6 or for that matter IPv4 delivery today across
any network. Regardless if this is private or public network of any
reasonable size and service portfolio.

Some form of encapsulation or tunneling is used in enterprises, in ISPs, in
SPs or even in largest public clouds.

So if you think that you can send an IPv6 packet and that this packet will
be delivered to its final destination without any encapsulation on the way
- this is just unreal. And the sooner you and others like you realize this
the better for everyone.

Think about L3VPNs reachability segmentation, think about SFC/NSH, think
about L2 transport emulation of your circuits, think about seamless
mobility, LISP  ...

Just a tiny reality check,

Thx,
R.