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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Sun, 08 December 2019 17:54 UTC

Return-Path: <alexandre.petrescu@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 AC6E41200A4 for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 09:54:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.63
X-Spam-Level:
X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, MAY_BE_FORGED=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 WXC6D9UGUeHN for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 09:54:20 -0800 (PST)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC9D0120020 for <ipv6@ietf.org>; Sun, 8 Dec 2019 09:54:19 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xB8HsG0D004552 for <ipv6@ietf.org>; Sun, 8 Dec 2019 18:54:16 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 90C2C202226 for <ipv6@ietf.org>; Sun, 8 Dec 2019 18:54:16 +0100 (CET)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 86343200C99 for <ipv6@ietf.org>; Sun, 8 Dec 2019 18:54:16 +0100 (CET)
Received: from [10.8.112.11] (is224374-002.intra.cea.fr [10.8.112.11] (may be forged)) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xB8HsF5Z026768 for <ipv6@ietf.org>; Sun, 8 Dec 2019 18:54:16 +0100
Subject: Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)
To: ipv6@ietf.org
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>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <271f5b1b-166f-3138-983c-263c4385ed67@gmail.com>
Date: Sun, 08 Dec 2019 18:54:15 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0
MIME-Version: 1.0
In-Reply-To: <CAO42Z2ze7tmkGh=E-YrPuJHMeD8V6EuxgjjaJ33iz+Ms3abNsA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/RyiyYRaSVvFEqPfqm8bijHH_-YE>
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: Sun, 08 Dec 2019 17:54:23 -0000


Le 07/12/2019 à 12:33, Mark Smith a écrit :
> 
> 
> On Sat, 7 Dec 2019, 21:30 , <otroan@employees.org 
> <mailto: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?

A tunnel is defined by around 6 addresses, and the scope requirements
between these addresses are relatively clear.  The 6 addresses are
configured on precisely two computers (never 3, nor 1).  The addresses
are called 'local' and 'remote' (on the virtual interface), and
'next-hop' (in the rt entry).

To answer the question, I think it is possible to use LL addresses as
the 'local' address on each one of the interfaces on A and C, but then
there would be a need of another tunnel.  Also possile for the 'remote' 
addresses.

Alex

> 
> 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 <mailto:ipv6@ietf.org>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>