Re: Who is the design ultimate authority over IPv6? (Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming)
Tom Herbert <tom@herbertland.com> Fri, 06 March 2020 21:00 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 D3BD63A0A86 for <ipv6@ietfa.amsl.com>; Fri, 6 Mar 2020 13:00:40 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 AFcSEzq4Fwdv for <ipv6@ietfa.amsl.com>; Fri, 6 Mar 2020 13:00:39 -0800 (PST)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 CE5853A0A85 for <6man@ietf.org>; Fri, 6 Mar 2020 13:00:38 -0800 (PST)
Received: by mail-ed1-x52d.google.com with SMTP id g19so4054287eds.11 for <6man@ietf.org>; Fri, 06 Mar 2020 13:00:38 -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=bN2TKOGd2FKGlWQgovG/8GufeHia3gWuKIUZ1We3uUU=; b=G0DxU7goKSoWX4tVy4QtMI/AW8A9AKwpFoSvYzU2+RRA0oP/lX9yLg2G4E436j6c0Y YZzaWyDDty4UIV4DBLOOd6J0QYhuaaqqOhNgGfHFicRj9qw8fm9v/ha5fihvLjpuaqsK VeNbEmCnCdtR/qBKjBjohxD/QW7XgpzUlaX65McbR6nnQyRJZgMjzuQ+j54i7tZiPZFA cMBUJhwjlwT0BMOQW5WQO7vZK9j85IsTwMhNLn4aT+kRhedukihlGEthX3LYCuQURkMK AWfrPhr9XJZ+dan0U4tt0x9kk8QWB0xppBayOk4HGG7B2xfV/fC5+Y4NcjJNbWWScehi ii+g==
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=bN2TKOGd2FKGlWQgovG/8GufeHia3gWuKIUZ1We3uUU=; b=Tla+3Lo6MK+ZFunSG2208T700Vz75JUjtGHJ+3xyExDVhY73qtVpXJ5AXV7tebhxbM +/D8Ty1lKgN02EECJxufRi/SzNY2mC8//E9nBVVVsKxNujdx7zEtNaENm4NyZfy86dGM Ir7ZXcMlEH6ZihVLEfgOVEdksPk1nCJjknl1upcqrz8YONoibHCHXIbbOGO9fqHo1wML hfKt/cTOQ23vxjBFklccUEYpr0cOdjtf917lJ4QbFTCtIqGC9n+Lbhc2nz4d2AB3jTt2 u1ZwgB4y+ig4SWSYmCZqeuT2P+oUIzYAEHsrK6cmesBohnHZSY04pgDsIYjMeMCgr+ZR F13g==
X-Gm-Message-State: ANhLgQ3Qs6qfvZwx6IRm4W/W7zLhRGJagontIdUNTMaEbFj35oe2AII8 b2QpMgn1fse3/sHpGClZVD0caJtrNJ+Wer7aKb0FmA==
X-Google-Smtp-Source: ADFU+vtreCPA4AXDEKP3+cVSRPKqi6jbz60rtnuFX/plSrI/uVViBTA+qtBMM+KVSWA1i+peHev8K1wbx2Z1IOImauI=
X-Received: by 2002:a05:6402:951:: with SMTP id h17mr2810069edz.79.1583528437084; Fri, 06 Mar 2020 13:00:37 -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> <16536_1576089460_5DF13774_16536_366_1_53C29892C857584299CBF5D05346208A48D273AD@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CAO42Z2z2s92yitCC0eLrNO3dXe_EarRSUZq8GmJ=QRdZ59d0ag@mail.gmail.com> <64E8151B-DF45-4F30-A4AD-673E37A482DD@employees.org> <738133cf-1b87-90b3-614f-470b5546eedf@gmail.com>
In-Reply-To: <738133cf-1b87-90b3-614f-470b5546eedf@gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 06 Mar 2020 13:00:25 -0800
Message-ID: <CALx6S35=NWNu9iV7FU=zhmOwjB5T_WswyS13skpqfDfvL=G_jQ@mail.gmail.com>
Subject: Re: Who is the design ultimate authority over IPv6? (Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming)
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Ole Troan <otroan@employees.org>, Mark Smith <markzzzsmith@gmail.com>, "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/pQFKsPpC_YxjDBf9-SOq62xbDu4>
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: Fri, 06 Mar 2020 21:00:41 -0000
On Fri, Mar 6, 2020 at 12:17 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > > Ole, > > On 07-Mar-20 02:24, otroan@employees.org wrote: > > [spring cross posting deleted] > > > >>> - Read the mailing list and you will see that everyone do not share your opinion. So at least one person is wrong. I think that it would help if everyone, including you, could consider that they/you _may_ be wrong, at least to better understand the comments been made by others. And possibly the text from RFC 8200 is not clear, but this is what we have. And this is the text to use to support the claim that this text is violated. > >> > >> The final interpretation and intent of text in RFC8200 should be up to > >> 6man, not SPRING, when there is ambiguity and dispute, as 6man is the > >> ultimate design authority for IPv6. > >> > >> RFC5704, "Uncoordinated Protocol Development Considered Harmful": > >> > >> " In particular, the > >> IAB considers it an essential principle of the protocol development > >> process that only one SDO maintains design authority for a given > >> protocol, with that SDO having ultimate authority over the allocation > >> of protocol parameter code-points and over defining the intended > >> semantics, interpretation, and actions associated with those code- > >> points." > >> > >> IETF WGs would qualify as standards development organisations. > >> > >> Those of us in 6man during the clarifications in this area of RFC8200 > >> know the intent. It was specifically about modification of the EH > >> chain, and was in response to the > >> 'draft-voyer-6man-extension-header-insertion' Internet Draft. > > > > No, it is the IETF that is the SDO and has that authority through IETF consensus. > > Not the working group. > > Absolutely. And that means: IETF consensus as judged by the IESG, subject to the RFC 2026 appeal process. > > Let me summarize my take on this from a 6man perspective: > > > > 1) PSP violates RFC8200. > > I also object to any statement in SR PGM that it is in "compliance with 8200". It specifies it's own unique EH handling. > > It doesn't use the word "compliance" which is rather loaded in standards-speak. It now says: > > "This behavior does not contravene Section 4 of [RFC8200] because the > current destination address of the incoming packet is the address of > the node executing the PSP behavior." > > Like it or not, that's what we published. Whether it's what we meant is another question. > > > As I state below that's perfectly fine. > > > > 2) A premise for the work on tightening extension header processing rules leading up to 8200, was that new specifications can specify different behaviour than what's defined in 8200. > > That is what the SR PGM document does. Any specification that changes EH processing must specify how that processing is done, and must be technically sound, in that it is shown not to break anything (interoperability, PMTUD, end to end security etc). > > The SR PGM document has been terse in it's description and how it deals with identified technical issues. But it is also clear, that it is specified to only work within a limited domain, where the source, destination and in-path nodes are all within the same domain of control. > > I see no outstanding technical issues with that mechanism. > > After a lot of thought, I agree with that. It's known not to work with AH, but AH is optional. It cannot break PMTUD because it only makes the packet smaller. And I am told it doesn't break OAM. Brian, I don't understand what you mean by "AH is optional" in this context. AH is certainly optional to send by source nodes, however if it is in a packet then I don't see how intermediate nodes have the option to knowingly break AH. This is precisely why declaring what data in header fields is mutable in flight is so important. This isn't just to make AH work, but enforcing that the network doesn't arbitrarily modify packets in random ways is one of the reasons why AH is needed. (If you were to say that AH isn't a problem because it will never be in the same packet as and SRH, then I will have to point that SRH does not preclude that possibility. IMO, until the combination is expressly prohibited, intermediate nodes are subject to "be liberal in what you receive" in this regard) Tom > > > 3) It is also clear that what is specified in SR PGM does not work across administrative domain or on the general Internet. > That's the limited domain argument which as pointed out several times is not a normatively defined construct in IETF. Without such a definition I don't see how requirements pertaining to IPv6 can take this into account (i.e. we can't update RFC8200 with requirements that would only be applicable in a limited domain without defining limited domain). > In fact, the whole of SRH is intra-domain, as specified by RFC8402. > > > For that reason I would object to any modification to 8200. Be it erratum, updated by pointer or bis document. > > I think there's an established weakness in RFC 8200. We could decide to live with it, as we live with weaknesses in RFC 791. > > > Is is possible to come to some agreement and consensus on the above points? > > That beats me ;-) > > Brian > > -------------------------------------------------------------------- > 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)