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 > -------------------------------------------------------------------- >
- Network Programming - Penultimate Segment Popping Ron Bonica
- Re: Network Programming - Penultimate Segment Pop… Fernando Gont
- Re: Network Programming - Penultimate Segment Pop… Darren Dukes (ddukes)
- RE: Network Programming - Penultimate Segment Pop… Ron Bonica
- Re: Network Programming - Penultimate Segment Pop… Fernando Gont
- Re: Network Programming - Penultimate Segment Pop… otroan
- RE: Network Programming - Penultimate Segment Pop… Ron Bonica
- Re: Network Programming - Penultimate Segment Pop… otroan
- Re: Network Programming - Penultimate Segment Pop… Fernando Gont
- We don't seem to be following our processes (Re: … Fernando Gont
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… Tom Herbert
- RE: We don't seem to be following our processes (… Ron Bonica
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… Enno Rey
- Re: We don't seem to be following our processes (… Enno Rey
- RE: We don't seem to be following our processes (… Ron Bonica
- Re: We don't seem to be following our processes (… Bob Hinden
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… Joel M. Halpern
- Re: We don't seem to be following our processes (… Sander Steffann
- Re: We don't seem to be following our processes (… Alexandre Petrescu
- Re: We don't seem to be following our processes (… Tom Herbert
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Sander Steffann
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: We don't seem to be following our processes (… Bob Hinden
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… Tom Herbert
- Re: We don't seem to be following our processes (… otroan
- Re: [spring] We don't seem to be following our pr… Andrew Alston
- Re: We don't seem to be following our processes (… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… otroan
- RE: [spring] We don't seem to be following our pr… Ron Bonica
- Re: [spring] We don't seem to be following our pr… Andrew Alston
- Re: [spring] We don't seem to be following our pr… otroan
- RE: [spring] We don't seem to be following our pr… Ron Bonica
- Re: We don't seem to be following our processes (… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: Network Programming - Penultimate Segment Pop… Darren Dukes (ddukes)
- Re: We don't seem to be following our processes (… Fernando Gont
- RE: Network Programming - Penultimate Segment Pop… Ron Bonica
- Re: [spring] We don't seem to be following our pr… Ole Troan
- Re: [spring] We don't seem to be following our pr… Andrew Alston
- Re: [spring] We don't seem to be following our pr… Sander Steffann
- Re: We don't seem to be following our processes (… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: We don't seem to be following our processes (… Joel M. Halpern
- Re: We don't seem to be following our processes (… Tom Herbert
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: [spring] We don't seem to be following our pr… otroan
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: We don't seem to be following our processes (… Tom Herbert
- Re: We don't seem to be following our processes (… Ole Troan
- Re: We don't seem to be following our processes (… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Brian E Carpenter
- Re: We don't seem to be following our processes (… Joel M. Halpern
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: We don't seem to be following our processes (… Fernando Gont
- Separating issues (was Re: [spring] We don't seem… Suresh Krishnan
- RE: Separating issues (was Re: [spring] We don't … Ketan Talaulikar (ketant)
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… Joel M. Halpern
- Re: We don't seem to be following our processes (… Mark Smith
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… otroan
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Alexandre Petrescu
- Re: Network Programming - Penultimate Segment Pop… Darren Dukes (ddukes)
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: Network Programming - Penultimate Segment Pop… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Darren Dukes (ddukes)
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: We don't seem to be following our processes (… Tom Herbert
- Re: Network Programming - Penultimate Segment Pop… Tom Herbert
- Re: [spring] Network Programming - Penultimate Se… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Brian E Carpenter
- Re: We don't seem to be following our processes (… Mark Smith
- IPv6 header insertion in a controlled domain otroan
- IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain Fernando Gont
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain Sander Steffann
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain Joel M. Halpern
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain Tom Herbert
- Re: IPv6 header insertion in a controlled domain jmh.direct@joelhalpern.com
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain otroan
- Re: We don't seem to be following our processes (… Alexandre Petrescu
- Re: IPv6 header insertion in a controlled domain Sander Steffann
- Re: IPv6 header insertion in a controlled domain Brian E Carpenter
- Re: IPv6 header insertion in a controlled domain Warren Kumari
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- RE: We don't seem to be following our processes (… Ron Bonica
- RE: IPv6 header insertion in a controlled domain Ron Bonica
- Re: IPv6 header insertion in a controlled domain Sander Steffann
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- RE: IPv6 header insertion in a controlled domain Ron Bonica
- Re: IPv6 header insertion in a controlled domain otroan
- RE: [spring] We don't seem to be following our pr… bruno.decraene
- Re: IPv6 header insertion in a controlled domain Fernando Gont
- Re: IPv6 header insertion in a controlled domain Tom Herbert
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- Re: IPv6 header insertion in a controlled domain Fernando Gont
- RE: IPv6 header insertion in a controlled domain Ron Bonica
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- Re: IPv6 header insertion in a controlled domain Fernando Gont
- Re: topics to circulate Alexandre Petrescu
- Re: topics to circulate Gyan Mishra
- Re: topics to circulate Erik Kline
- Re: topics to circulate Alexandre Petrescu
- Re: topics to circulate Alexandre Petrescu
- Re: IPv6 header insertion in a controlled domain Alexandre Petrescu
- Re: IPv6 header insertion in a controlled domain Alexandre Petrescu