Re: WGLC - draft-ietf-spring-srv6-network-programming
Tom Herbert <tom@herbertland.com> Wed, 11 December 2019 01:44 UTC
Return-Path: <tom@herbertland.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 8113B120059 for <ipv6@ietfa.amsl.com>; Tue, 10 Dec 2019 17:44:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 Lto0o-zFHHF9 for <ipv6@ietfa.amsl.com>; Tue, 10 Dec 2019 17:44:04 -0800 (PST)
Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) (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 5ECE412008C for <6man@ietf.org>; Tue, 10 Dec 2019 17:44:04 -0800 (PST)
Received: by mail-ed1-x542.google.com with SMTP id c26so17872740eds.8 for <6man@ietf.org>; Tue, 10 Dec 2019 17:44:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CfiD/xHKRjZcRXAN8zxkP5gZSWW19eNfrNwloTH1KDk=; b=YVxrbC+mtxk8lTdm89BiLBcNifm1GiOVkhVGtRxCvPebZ3U0g2tzQGeAsozqZmZCk2 zyr65PpO4WOaQU5bMazXHmFQPF28n9oJyWXaJuu1E0m8Ycfv+LC3tbD2bgfcTJUcxTbg CcUpUQ0jaWtGVWO+S4T/CW1Bj/5cdwkJh6Dn8E0BL+TeNU6h0LghqJIf7GVjVnNIUv9f zhxlulnAHn/jnr1hLHLot57Gyp93evhRT1A/Pk38FdPoJe5bTa7OwUnIZbLH46JAHni6 J6CbG+5+zX3HKN48gZz+/N9EGMTDqyZqv3q+CMFzOzDFB6l7AONJb7Wmgj+ji0AkL+0/ n9EQ==
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:content-transfer-encoding; bh=CfiD/xHKRjZcRXAN8zxkP5gZSWW19eNfrNwloTH1KDk=; b=mdKrlx0QL4uZ9yOpwNCiSH4+AtiHVzmpp9QR2YzZIUWicitEIK59JG7j3BmNMdVUyx 2BGyK59ma6IoukHUdfjIyvjTw218vi8i9l609FZ6H1f3IOIibqKp/x36dCBIQXHygpcr EEFGlT6ragVB3HgtCWDlsTf2Iqv3OIuHfTxhDYd+Ii8vEb5igaEHRne6Hsw31Avca3Mt qpMPLYKB5kHl6PjgfVQOUYPPPxMdBnV/n+p7KmBfUAhq8mpqQnhqfuyVoVpjryVCYMvf Wi54r4hjBpI/a5+EJ0YGk/Sz6lW1lMYI+9rTt/zVGFeaDzFfMWiJxRT4tdwd/j01fuDj tK6A==
X-Gm-Message-State: APjAAAX7iShkWfwYe7AgAeeAigbV8xZLpHsgZoPGa+CotdLifqWC+bwH 6hCqRicdXo5U4Da1aRtlxIMQFpRE9AkKlA52/6zDuV+4Fz8=
X-Google-Smtp-Source: APXvYqyP6vezWBP5JuAwYxvi6unupqyZVcljj2FKUX/dGYSMbvWu91G6ljRxaArMuSiX5I6O8esLCE99x7i3sZwVty4=
X-Received: by 2002:a17:906:5e4d:: with SMTP id b13mr603024eju.266.1576028642618; Tue, 10 Dec 2019 17:44:02 -0800 (PST)
MIME-Version: 1.0
References: <17421_1575566127_5DE93B2F_17421_93_1_53C29892C857584299CBF5D05346208A48D1A3DA@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <6c674995-8cc7-c024-4181-60b160910f75@si6networks.com> <29345_1576001884_5DEFE15C_29345_229_5_53C29892C857584299CBF5D05346208A48D250B7@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <89402a30-129b-314f-90f1-ba6efcdd6a88@si6networks.com> <795b498c-39b9-a3d8-e9f8-77fd53f48e6a@joelhalpern.com>
In-Reply-To: <795b498c-39b9-a3d8-e9f8-77fd53f48e6a@joelhalpern.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 10 Dec 2019 17:43:51 -0800
Message-ID: <CALx6S36anj=Eo0gsePxXNX_YHcYQBOA5cfhdsqUtS5khx3xPQg@mail.gmail.com>
Subject: Re: WGLC - draft-ietf-spring-srv6-network-programming
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Fernando Gont <fgont@si6networks.com>, SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/X6pMR-fFxNkLlNYRPsWCKJoa3bU>
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: Wed, 11 Dec 2019 01:44:08 -0000
On Tue, Dec 10, 2019 at 4:49 PM Joel M. Halpern <jmh@joelhalpern.com> wrote: > > Fernando, I really wish I could agree with you. > But I can't. > > In 8200, it is clear that the meaning fo "Destination Address" for an > IPv6 packet is the value placed in the IPv6 destination address field. > the fact that if we had looked ahead we might have said something > different does not change what words we chose to use. If I am going to > insist (as I have in other contexts) that other folks live with the > words we compromised on in 8200, then I have to live myself with the > words we compromised on in 8200. > Joel, That might be the wording, but don't believe that was the intent. The real intent is revealed by some of the earlier text that said (draft-ietf-6man-rfc2460bis-07): "The insertion of Extension Headers by any node other than the source of the packet breaks PMTU-discovery and can result in ICMP error messages being sent to the source of the packet that did not insert the header." That is true, and breaking ICMP is an issue that has been raised repeatedly. It also breaks AH as pointed out. Furthermore, if RFC8200 allows SRH insertion to occur, then we'd have to accept that it allows ANY type EH insertion (except maybe fragmentation?) to occur at any destination address! Not only that, we also need to accept that this would allow NAT devices to insert EH when the destination address is the NAT address. So the possibility that destination address wasn't spelled out as being final destination seems to be an unfortunate omission, but even so, that omission doesn't somehow magically make EH insertion robust or mitigate the problems of EH insertion that have already been discussed. Neither does it provide the rationale why encapsulation with the EH can't be used instead which is clearly the option that most closely adheres to the Robustness principle. Tom > I have concerns about whether PSP is a good design. I am trying to > write a useful note on the topic. (And without such a note, I can not > expect anyone to care about thoughts in my head.) But I can not and > will not claim that PSP violates RFC 8200. > > Yours, > Joel > > On 12/10/2019 6:16 PM, Fernando Gont wrote: > > Bruno, > > > > On 10/12/19 13:18, bruno.decraene@orange.com wrote: > >> Fernando, > >> > >> Thank you for spelling out your comment, plus on the WGLC thread. > >> More in-line > >> > >>> Bruno, > >>> > >>> On 5/12/19 12:15, bruno.decraene@orange.com wrote: > >>> [....]> > >>>> This email starts a two weeks Working Group Last Call on > >>>> draft-ietf-spring-srv6-network-programming [1]. > >>>> > >>>> > >>>> > >>>> Please read this document if you haven't read the most recent version, > >>>> and send your comments to the SPRING WG list, no later than December 20. > >>>> > >>>> > >>>> > >>>> You may copy the 6MAN WG for IPv6 related comment, but consider not > >>>> duplicating emails on the 6MAN mailing list for the comments which are > >>>> only spring specifics. > >>>> > >>>> > >>>> > >>>> If you are raising a point which you expect will be specifically debated > >>>> on the mailing list, consider using a specific email/thread for this point. > >>>> > >>>> This may help avoiding that the thread become specific to this point and > >>>> that other points get forgotten (or that the thread get converted into > >>>> parallel independent discussions) > >>> > >>> Penultimate Segment Popping describes/specifies the removal of a SRH at > >>> a place other than the final destination of the packet. > >>> > >>> Such behavior violates RFC8200, which specifies: > >>> > >> > Extension headers (except for the Hop-by-Hop Options header) are not > >> > processed, inserted, or deleted by any node along a packet's delivery > >> > path, until the packet reaches the node (or each of the set of nodes, > >> > in the case of multicast) identified in the Destination Address field > >> > of the IPv6 header. > >>> > >>> Note, of course, that the reference of "Destination Address" in RFC8200 > >>> is clearly the final destination of the packet -- for instance, RFC8200 > >> > >> I hear and can understand your reading of RFC8200. > > > > Could you please check RFC8200, and tell me what other possible > > interpretation of "Destination Address" you might have, in the context > > of RFC8200. > > > > RFC8200 does not even specify any routing header types. SO...where's the > > ambiguity? > > > > > > > >> At minimum, I think that we can agree that there is another reading, as expressed by other WG participants, and hence I disagree with "of course". > > > > No, I argue that there is not. IN fact, I argue that folks have been > > following that strategy for way too long, and that's quite frustrating. > > > > > > > >> Personally, I understand "Destination Address" as "Destination Address field of the IPv6 header." as indicated explicitly in the text quoted. > > > > The quoted text is from RFC8200. In the context of RFC8200 the > > Destination Address can only contain the ultimate destination of the > > packet. Where's the ambiguity? > > > > And let me ask you, as chair, another question, that will lead you to > > the same place: is IPv6 and end to end protocol? > > > > > > The fact that I may claim that RFC8200 contains a receipe for BBQ does > > not actually mean that that's the case. > > > > > > > >> I'm fine with having this clarified with 6MAND chairs and AD. That been said, the Internet AD would have an opportunity to DISCUSS this. > > > > For the record, I think this is a major issue that should be cleared > > before it can be claimed that there is consensus to request publication > > of this document. > > > > > > > >> > >>> does not specify any routing header type, and hence the meaning is > >>> unambiguous (there's no destination other than the final destination of > >>> the packet). > >>> > >>> This is of course in line with IPv6 being and end-to-end protocol, and > >>> crucial for other related mechanisms to work as expected (such as IPsec > >>> AH). Please also check: draft-smith-6man-in-flight-eh-insertion-harmful. > >>> > >>> So, in order to proceed with the document, there are multiple options > >>> forward: > >>> > >>> 1) Just remove the corresponding text/behavior > >> > >> That is indeed one option. But as of today, this is not my assumption. > >> > >>> 2) Implement a similar mechanism in an RFC8200-compliant manner (e.g., > >>> re-encap) > >> > >> SRH insert is out of scope of this specification. So yes, IPv6 encaps is used. > >> We are talking SRH removal. I'm assuming that you are referring to PSP. My understanding is that this function (PSP) is to distribute the (forwarding plane) load between the PSP and the USP. In a way similar to MPLS PHP. But in all cases, this is not about SRH insertion. > > > > It's about SRH removal, which is also forbiden by RFC8200. > > > > > > > > > >>> 3) Do the necessary standards work to update RFC8200, such that it > >>> allows this sort of behavior, and only ship the network-programming > >>> draft for publication when at least 6man has consensus to proceed on > >>> that path. > >> > >> Not the preferred path as of today. > > > > Yes, it should be evident that it seems the preferred path has been > > (starting with EH insertion at the time) to circumvent existing > > specifications. > > > > > > > >> > >>> P.S.: I will go through the document once again... but the same > >>> reasoning should be applied to any EH-insertion/removal at a place other > >>> than the source of the packet or its final destination. > >> > >> It looks to me that SRH insertion and SRH removal are to be treated differently. > > > > I don't see how or why. Both violate the same requirement in RFC8200. > > > > > > Thanks, > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
- WGLC - draft-ietf-spring-srv6-network-programming bruno.decraene
- RE: WGLC - draft-ietf-spring-srv6-network-program… Ron Bonica
- Re: WGLC - draft-ietf-spring-srv6-network-program… li_zhenqiang@hotmail.com
- RE: [spring] WGLC - draft-ietf-spring-srv6-networ… Andrew Alston
- Re: WGLC - draft-ietf-spring-srv6-network-program… Sander Steffann
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Fernando Gont
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Fernando Gont
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Pablo Camarillo (pcamaril)
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Andrew Alston
- Re: WGLC - draft-ietf-spring-srv6-network-program… Fernando Gont
- Re: WGLC - draft-ietf-spring-srv6-network-program… Warren Kumari
- RE: WGLC - draft-ietf-spring-srv6-network-program… bruno.decraene
- RE: WGLC - draft-ietf-spring-srv6-network-program… bruno.decraene
- Re: WGLC - draft-ietf-spring-srv6-network-program… Fernando Gont
- Re: WGLC - draft-ietf-spring-srv6-network-program… Joel M. Halpern
- Re: WGLC - draft-ietf-spring-srv6-network-program… Warren Kumari
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Robert Raszuk
- RE: [spring] WGLC - draft-ietf-spring-srv6-networ… Xiejingrong (Jingrong)
- Re: WGLC - draft-ietf-spring-srv6-network-program… Tom Herbert
- Re: WGLC - draft-ietf-spring-srv6-network-program… jmh.direct@joelhalpern.com
- Re: WGLC - draft-ietf-spring-srv6-network-program… Fernando Gont
- Re: WGLC - draft-ietf-spring-srv6-network-program… Fernando Gont
- RE: WGLC - draft-ietf-spring-srv6-network-program… bruno.decraene
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Pablo Camarillo (pcamaril)
- Re: WGLC - draft-ietf-spring-srv6-network-program… Greg Mirsky
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Sander Steffann
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Fernando Gont
- Fwd: [spring] WGLC - draft-ietf-spring-srv6-netwo… Gyan Mishra
- RE: [spring] WGLC - draft-ietf-spring-srv6-networ… bruno.decraene
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Martin Vigoureux
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Brian E Carpenter
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Andrew Alston
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Sander Steffann
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Sander Steffann
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Fernando Gont
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Fernando Gont
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Mark Smith
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Mark Smith
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… S Moonesamy
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Fernando Gont
- RE: [spring] WGLC - draft-ietf-spring-srv6-networ… bruno.decraene
- RE: [spring] WGLC - draft-ietf-spring-srv6-networ… bruno.decraene
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Sander Steffann
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Fernando Gont
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Warren Kumari
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… S Moonesamy
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Pablo Camarillo (pcamaril)
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Pablo Camarillo (pcamaril)
- RE: [spring] WGLC - draft-ietf-spring-srv6-networ… Xiejingrong (Jingrong)
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Fernando Gont
- RE: [spring] WGLC - draft-ietf-spring-srv6-networ… Andrew Alston
- Who is the design ultimate authority over IPv6? (… Mark Smith
- Re: Who is the design ultimate authority over IPv… otroan
- RE: Who is the design ultimate authority over IPv… James Guichard
- Re: Who is the design ultimate authority over IPv… Brian E Carpenter
- Re: Who is the design ultimate authority over IPv… Tom Herbert
- Re: Who is the design ultimate authority over IPv… otroan
- Re: Who is the design ultimate authority over IPv… Brian E Carpenter
- Re: Who is the design ultimate authority over IPv… Joel M. Halpern
- Re: Who is the design ultimate authority over IPv… Mark Smith
- Re: Who is the design ultimate authority over IPv… Mark Smith
- Re: Who is the design ultimate authority over IPv… Joel M. Halpern
- Re: Who is the design ultimate authority over IPv… Tom Herbert
- Re: Who is the design ultimate authority over IPv… Joel M. Halpern
- Re: Who is the design ultimate authority over IPv… Mark Smith
- Re: Who is the design ultimate authority over IPv… Brian E Carpenter
- Re: Who is the design ultimate authority over IPv… Fernando Gont
- Re: Who is the design ultimate authority over IPv… Brian E Carpenter
- Re: Who is the design ultimate authority over IPv… Andrew Alston
- Re: Who is the design ultimate authority over IPv… S Moonesamy
- Re: Who is the design ultimate authority over IPv… Suresh Krishnan
- Re: Who is the design ultimate authority over IPv… Brian E Carpenter
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Pablo Camarillo (pcamaril)
- RE: [spring] WGLC - draft-ietf-spring-srv6-networ… Andrew Alston
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Pablo Camarillo (pcamaril)
- RE: [spring] WGLC - draft-ietf-spring-srv6-networ… Andrew Alston
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Pablo Camarillo (pcamaril)
- RE: [spring] WGLC - draft-ietf-spring-srv6-networ… bruno.decraene
- RE: [spring] WGLC - draft-ietf-spring-srv6-networ… Andrew Alston
- RE: [spring] WGLC - draft-ietf-spring-srv6-networ… Ketan Talaulikar (ketant)
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Sander Steffann
- RE: [spring] WGLC - draft-ietf-spring-srv6-networ… Ketan Talaulikar (ketant)
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Sander Steffann
- RE: [spring] WGLC - draft-ietf-spring-srv6-networ… Ketan Talaulikar (ketant)
- Re: [spring] WGLC - draft-ietf-spring-srv6-networ… Sander Steffann
- RE: [spring] WGLC - draft-ietf-spring-srv6-networ… Ketan Talaulikar (ketant)