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 11:33 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 B06D41201DE for <ipv6@ietfa.amsl.com>; Sat, 7 Dec 2019 03:33:28 -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 QpFk7O_hztOO for <ipv6@ietfa.amsl.com>; Sat, 7 Dec 2019 03:33:26 -0800 (PST)
Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 6E4AF1200F1 for <ipv6@ietf.org>; Sat, 7 Dec 2019 03:33:26 -0800 (PST)
Received: by mail-oi1-x22b.google.com with SMTP id i1so2248357oie.8 for <ipv6@ietf.org>; Sat, 07 Dec 2019 03:33:26 -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=mCBxK8UhDfD7TMT2+w7mBhzbORNMSUb0lp52mbvmdiQ=; b=J/G/Y9nb/c3wcJoxTofxvPC88Fl7PlW+q/Xb6k3Wmdl93guBnIKjH51d8LsMbjo/D4 ZzIjDkGfcq4L5gJsayFliYnLUDSnTn/6gT9zdolEZC8yUEOIUpBkzglTEUDhGtpl3Eqp W2APycJXmrSPwAVmqNM6bsnuy4Kh9XC0hv6bmsmqf+iDcjYaMJIFyzarKOCOoBlJfihW 60Y6VAJSWgraZ1LwQsjqyE3bv43YHX6G7G1MkXxa+CliWWTKSRkWecAjuKzsO6Rrq15f 3xUz82yf4v9sQM+NlmYtZdzezkg0K6aHesh/MzBpkIkdRQduQtCeSXdOWQGcwpDNHctH S3Mg==
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=mCBxK8UhDfD7TMT2+w7mBhzbORNMSUb0lp52mbvmdiQ=; b=MzW/TduC/CnBf9ZwaAMhHHd9jipcE3XsBPXYaq1vD2IXXgyxvPchfoimt+S3Ra2sKu L/JXFihiNGQFrYnEOqQ45lJ6SF2pFeMDgWMeaGx7aUUDRS1H4lDUHV4dHtNzq6KLCBbV afJ4g+8Xi4mR9eleKZ2FHWKtpGP0nh7Rdo5+ljps7wYwjLFFYdy+3Fl1rnRhPZAjQudZ Vdc0sQVPOFvUKoEFsdLCw+OGmo8xE+RDLCPQFlnQYOvxDefxQbvD5IaYX4YeAOrq4cIA Y9PPQBbJYfhz4WXHQA/ILJ7PY4N6h+uJuha4/IFzy8GMZBDaIheQNi8mztv656Bz6Shn DXfw==
X-Gm-Message-State: APjAAAXEmGB6KTUDAeuWXdXAi7nKmQWp76IhOFB190MLuijJ9ki3hYpf NYDmM5cVqPiE7NzVPZX1B/qI6CDxL71S9gKe5YgjAA==
X-Google-Smtp-Source: APXvYqwhAxd2E1cnoZEEwiF4R5ou89Q95l0Q0hy2i7ddceK2c/ymP4VL0vyfn7Vo7Es7MZHdBh4+O0RWX7yJdOI28Ds=
X-Received: by 2002:aca:ef85:: with SMTP id n127mr16979300oih.54.1575718405671; Sat, 07 Dec 2019 03:33:25 -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>
In-Reply-To: <4E76C386-FB1E-4E48-814D-BB626466BEE3@employees.org>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sat, 07 Dec 2019 22:33:14 +1100
Message-ID: <CAO42Z2ze7tmkGh=E-YrPuJHMeD8V6EuxgjjaJ33iz+Ms3abNsA@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="000000000000d60f4205991b8732"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/yeWZbnEcL7A-au_pOwmbFrfS34o>
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 11:33:29 -0000

On Sat, 7 Dec 2019, 21:30 , <otroan@employees.org> wrote:

> Joel,
>
> > The TI-LFA task can clearly be done with encapsulation.  That the
> proponents do not desire to do so is clear and understood.  Not desiring to
> do so is not a reason to violate a Full Standard RFC.
> >
> > That is why I asked what the purpose was for header insertion.  And
> citing the TI-LFA draft does not answer the quesiton.
>
> The point I tried to make was that propopents of EH insertiona had a
> slightly more nuanced motivation for doing what they are doing,
> than what Fernando portray in this paragraph:
>
> >> 3) Besides the technical arguments against EH insertion (which have been
> >> codified in draft-smith-6man-in-flight-eh-insertion-harmful, I have
> >> asked *lots* of times what's the technical motivation for doing EH
> >> insertion. It boils down to "to save 40 bytes", which doesn't seem to me
> >> as a compelling argument to violate the spec -- even less in a design
> >> that employs 128-bit waypoints and is claimed to be operated in a
> >> limited domain.
>
> I see it necessary to speak up when I see participants consistently
> arguing against strawman.
> And call upon higher deities (RFC8200).
>
> Strawman #1:
> The proponents of EH insertion proposes to do insertion/deletion directly
> on user (Internet) traffic.
>
> => There may be a suspicion that this is what they want, but it is not
> what they have written down, nor claim.
> Take an example of 3 routers A, B and C that is under the same control.
> Traffic travels from left to right.
>
> A -- B -- C
>
> A has a tunnel to C using ULA source and destination.
> A packet ingresses on A, is encapsulated and forwarded towards C.
> A has for reasons unknown to us outsourced a function to B. Where B insert
> an extension header in the packet originated by A.
> C is also in on the game, being a tunnel end-point, removing the
> encapsulating header and extension header.
>
> If you can leave the nuances of SR and the whatever they propose on the
> shelf for a minute.
>
> 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?

LLAs are required for all IPv6 interfaces per RFC4291. IGPs already
discover and use them as next hops. The tunnels to carry the added EHs
between SR routers do not need to be configured, they're implicit in the
universal availability of interfaces Link Local Addresses. These will be
single hop tunnels between SR routers to carry the added EHs.

This is the same processing MPLS uses. MPLS doesn't preserve link-layer
frames through an LSR, it replaces them at each LSR, with new SA and DA at
LSR egress, even when the ingress LSR encapsulation is the same as the
egress encapsulation.

So, just to be clear, if A, B and C were MPLS LSRs, the link-layer frame
used between A and B is a different and unrelated one to the link-layer
frame used between B and C, with the main difference being the frame's SAs
and DAs. MPLS labels aren't inserted into existing link-layer frames,
they're  inserted into a label stack at the time a new link-layer frame is
created to send to the next LSR. The label stack might be modified through
insertion, but the link-layer frames aren't - they're replaced at each and
every LSR hop.

Swap Ethernet for IPv6 tunnelling using Link-Local Addresses, and you are
now following the MPLS model, with your "link-layer" being IPv6.

Using Link Local Addresses creates an even more controlled domain, limited
to a link.

It complies with RFC8200, because the egress outer IPv6 tunnel packet is a
new one, with a new SA and DA, that can have a new set of EHs. Originating
a new tunnel packet is the opportunity to assemble a new set of EHs, some
copied, some copied and modified, and some new.

At B, there is no looking past the IPv6 fixed header to determine if there
is a EH to process - that deeper EH processing is explicitly indicated and
encoded in B's Link Local address, in the outer tunnel header packet's DA.

To functionally compare MPLS over Ethernet and IPv6, LSRs are IPv6 hosts
(anything not an IPv6 router), and Ethernet bridges/switches are IPv6
routers (forwarding frames/packets with non-local addresses).

MPLS over Ethernet isn't typically deployed with bridges/switches between
LSRs, so perhaps that's why people might be thinking that IPv6 routers are
the equivalent of MPLS LSRs, and therefore EH insertion at an IPv6 router
is the same sort of operation that occurs at an MPLS LSR.

Regards,
Mark.


> Ole
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>