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

Mark Smith <markzzzsmith@gmail.com> Sat, 07 December 2019 23:40 UTC

Return-Path: <markzzzsmith@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 ACF6C120090 for <ipv6@ietfa.amsl.com>; Sat, 7 Dec 2019 15:40:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Level:
X-Spam-Status: No, score=-0.497 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 T4KGNhLxRg4x for <ipv6@ietfa.amsl.com>; Sat, 7 Dec 2019 15:40:08 -0800 (PST)
Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 5E4CF12004A for <ipv6@ietf.org>; Sat, 7 Dec 2019 15:40:08 -0800 (PST)
Received: by mail-oi1-x229.google.com with SMTP id j22so3178202oij.9 for <ipv6@ietf.org>; Sat, 07 Dec 2019 15:40:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sGW5/uVu2POoAh/6dFPv9IRdNuYPntJKKMJ6ZeBlIt0=; b=V0OGHMKhT8+u6t/KUH9o7+XH0WjX8Srl+3ApiysVOoTXrxMYp+de6afv7XLqi8DCYm 427RZy3L7RyC4ibHvaP0Xy+DRUwMG9/pnYv6Ythp5vm9kaoaqE8+xoOCyCrEHs5NND0K VchRda6DMqCEs05rbPAqgzLlegdhrWurNS0SDcxMoMYQNuUf3vGOOoL0P5svhjNxtUbn ATwtliaMGDa8b1OlNh80fVyARNKrQj77bWkHzTVoC9BVN68m1vU9gWfb9bE598eqIC++ tWCZU9P3FVtDhWrTOIYzemPJV3gkhjA+HuY4xitvR6jfgQ9K3irXFPvceXgl6zbc6iar WnJQ==
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=sGW5/uVu2POoAh/6dFPv9IRdNuYPntJKKMJ6ZeBlIt0=; b=jtkx7EjW5rIc++yjN6hUMGIZ+Xe9WoxOdABLt4RhG+88HGOx++X2h3h68CiNVZRhXe mfZ2n5zzi5ax7pG1UopuC5cFquJ5ZZwMXpMhl71ZpRCqcuYrOXn7y/rXL/5D1GYQQ/TV /0GuKxlprmAQNxgHC0v+20D/cHCFIo8UkaVeVrZW/Oi9ghl8OtM00IT8V/byyY+15gjz KqTzH9ucTiii4FXDR71ASATx/7l+wpyeZTF7je83myfkNGa7y8u8SGpR5sU5E0/u22mH V34q/IVxX40Y8lAQVpAM1M8CsRvo9/c5rxmU/moIjtZUoIduz9h1rZjro81b0LF0KFZF oCrg==
X-Gm-Message-State: APjAAAW/7yStRIAkZBvUTCNlRlrLdnHVnD2DE65mO2kyk2qaVCB9ngi/ hHH6Y2VC1dW2NU8pftJuT+/1ZBxc6P4M8cghY40=
X-Google-Smtp-Source: APXvYqzv+CC0LYD3zObTMEvd2Mj0Y7UMClXnNjX2QIXlsirRlNn/HgGKL0rhlo2YFIPkqHuhKVJrT8lG7p+JZTkUIE0=
X-Received: by 2002:aca:ef85:: with SMTP id n127mr19144394oih.54.1575762007631; Sat, 07 Dec 2019 15:40:07 -0800 (PST)
MIME-Version: 1.0
References: <CALx6S3588ja9AZzBQ0dqwx0j-ki6A5tusye+odQKPyAyF+hEww@mail.gmail.com> <10E890EA-3278-44EE-881E-EBC91D419587@employees.org> <88287cb0-c0c3-f990-4dd7-338df87c7fb2@joelhalpern.com> <4E76C386-FB1E-4E48-814D-BB626466BEE3@employees.org> <CAO42Z2ze7tmkGh=E-YrPuJHMeD8V6EuxgjjaJ33iz+Ms3abNsA@mail.gmail.com> <FDD7B5F4-B60D-425A-96C1-979BE647C0DA@employees.org>
In-Reply-To: <FDD7B5F4-B60D-425A-96C1-979BE647C0DA@employees.org>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sun, 08 Dec 2019 10:39:56 +1100
Message-ID: <CAO42Z2xMF5TM3BT=tA63A7QmiYRChPJywb1pSJquy_i5K_h=iA@mail.gmail.com>
Subject: Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)
To: Ole Troan <otroan@employees.org>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b72d7b059925ae00"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mCSIefhA8b3eCUtcHcDkAWh8l0M>
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: Sat, 07 Dec 2019 23:40:10 -0000

On Sat, 7 Dec 2019, 22:43 , <otroan@employees.org> wrote:

> Mark,
>
> > Do you agree in principle that this approach of "header insertion in a
> controlled domain" can be made to work,
> > and should be indiscernible from A inserting the extension header itself?
> >
> > Why can't they use Link-Local Addresses to tunnel between each hop,
> i.e., between A and B, and then B and C?
>
> There are of course many alternative approaches, depending on use case.
> But that isn't an answer to the question I asked.
>
> In the example I gave, "do you in principle see any reason why it could
> not be made to work"?
>


Sure, it could be made to work. Anything that can be implemented in
software or hardware can be made to work.

However, that's a low success threshold.

It is ignoring other factors like if the mechanism is efficient (doing
things right) and effective (doing the right things).

It is ignoring whether the mechanism is the best performing for the least
cost (efficient restated).

It is ignoring how the mechanism fits within an existing architecture.

It is ignoring how obvious the mechanism's operation is, and how well it
utilises and aligns with existing, proven and well known mechanisms.

It is ignoring how easy and quickly it is to rectify faults when they
inevitably occur, a critical factor in production commercial networks.

It is ignoring how consistent the mechanism is with existing specifications
and existing knowledge.

Showing something works doesn't really prove anything other than it can be
made to work with software or hardware.

Something working well expects all these other factors are used as
judgement criteria.

In my experience there is a big gap between working* and working well.

These other "works well" factors are ones that matter the more when the
mechanism is deployed operationally, because operators can automatically
assume it works when they buy it as it has become a commercial product.

Regards,
Mark.




* This works, but I wouldn't say it works well by the above criteria.
Notice the recommendation at the end.

"A dirty trick to save a couple of IPv4
addresses on a LAN link"
https://www.ausnog.net/sites/default/files/ausnog-2018/presentations/2.10.2_Mark_Smith_AusNOG2018_Lightning.pdf


> Best regards,
> Ole
>
>
>