Re: Who is the design ultimate authority over IPv6? (Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming)

Mark Smith <markzzzsmith@gmail.com> Sat, 07 March 2020 03:05 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 9921E3A10F6 for <ipv6@ietfa.amsl.com>; Fri, 6 Mar 2020 19:05:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.598
X-Spam-Level:
X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 sqHXeCZPf2z9 for <ipv6@ietfa.amsl.com>; Fri, 6 Mar 2020 19:05:00 -0800 (PST)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 012FD3A10F3 for <6man@ietf.org>; Fri, 6 Mar 2020 19:05:00 -0800 (PST)
Received: by mail-ot1-x333.google.com with SMTP id j16so4501906otl.1 for <6man@ietf.org>; Fri, 06 Mar 2020 19:04:59 -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:content-transfer-encoding; bh=Br5CmAZJ2JmnEIrYUG0eVypfFrFwyJ+9euO+jk8dRuU=; b=qIkSjYwpW3RSgdcWaYAoC1pkIc+QevjsyEwT8c6PFVFbSBFyA2rD4On4az2mMo+QEy qqztWo48c9zNK4MG2AltyU0gweCEZVg6AlXfhJTw+vyO93Aq44GLT07PEG4wDnuWbcpT xAXPELbkrQvzxSzq5fPA3b1KQOKY0LMxnuo145bfcS+rv9zEKxkHMUiRyaLKiy0kIt5m UlITFNMnIVG8D0R/FItQMF6+ONyINS83RNvE37IKrdrXiTmlUQ8m8J05R1aXFUmhIDHh sE69NWPWCvAGXGB9Ci31P97iLK7WXmmcsQmH+MUY38LDmMPv9F0TgebcFk0uo3LaOacR vvAQ==
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=Br5CmAZJ2JmnEIrYUG0eVypfFrFwyJ+9euO+jk8dRuU=; b=HDhRmj9LE6EPlUTBvejRuf5gDAFHKppE1TVtuf0kVW/X7fiwBXwcI2LhL1k54wX76n cR+qdDks3z+YMhZa+gsOR5NImB5ayFqMHL4XSG285eMBrruKwdhZ6P9wyKmA1ygdAfCb +as0wstbCA+S+LbaAzGp8obWvtjFyo7JTKV1BKZs2kf6ruVu7kE88yREJPc0jLKGouKX w7MhRHBeBJJ5E8bjVnyME+hq2AUNz8ccFJvTB+5vGQRytRwzg2A0oB3ZU6um+MAnqNxL rIOB0ULkpK6q8gXxUK+uzZCyV9+XfG8hjc5UhT7EqFxbfZORm6ZU7vPH1kdXvx3M3t3n w9fQ==
X-Gm-Message-State: ANhLgQ0fJFgB9BZEK5fzPejBFggc6JCA26uSh77+qA7/BmHb/Pvh61Vw MIRVPdJKcq58tLtwNUfeYjcSk2th+gnopJSBRzQ=
X-Google-Smtp-Source: ADFU+vsHO+4mWm/HiD3DBS7NC7y5Z5vbYOO/im1HEiyNfxwFvIh729DgIPWZv/vyR9UP2uBaYw+DhHAmTs6IQeJVlnk=
X-Received: by 2002:a9d:6205:: with SMTP id g5mr5275845otj.153.1583550298869; Fri, 06 Mar 2020 19:04:58 -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> <CALx6S35=NWNu9iV7FU=zhmOwjB5T_WswyS13skpqfDfvL=G_jQ@mail.gmail.com> <1ea7ab65-7a07-5c78-aac7-bf202051a43a@gmail.com> <d1f32cb2-9f43-46cb-8585-319726e750b9@joelhalpern.com> <CAO42Z2wvCuj4YxBhmBAeh2yZdxi8uYy45o5gQNyEbHVGqu+_Eg@mail.gmail.com> <03a72a64-f7b7-e21a-b4b1-904fdec46203@joelhalpern.com>
In-Reply-To: <03a72a64-f7b7-e21a-b4b1-904fdec46203@joelhalpern.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sat, 07 Mar 2020 14:04:32 +1100
Message-ID: <CAO42Z2yY=KRbNjHwEofyGEFEYKcz0bEg73mjG=+c+RyRF8JRPw@mail.gmail.com>
Subject: Re: Who is the design ultimate authority over IPv6? (Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming)
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: "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/oXLUX7ohjYIKrrFt9OjeWFRGCpQ>
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 Mar 2020 03:05:03 -0000

Hi Joel,

On Sat, 7 Mar 2020 at 13:30, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>
> Mark, it has been approved by the IESG for publication.  We had a WG
> last call.  An IETF last call.  An IESG review.  It is in the RFC EDitor
> queue for publication.

Ok, I've missed that.

 While we could theoretically call it back, there
> would have to be an overwhelming reason.
>

It only occurred to me yesterday that SRH/SRv6 might also be violating
RFC 4291, as it seems that when SIDs are transformed into IPv6
addresses, those IPv6 addresses aren't assigned to interfaces but
rather nodes:

RFC 4291:

"2.1.  Addressing Model

 IPv6 addresses of all types are assigned to interfaces, not nodes.
   An IPv6 unicast address refers to a single interface.  Since each
   interface belongs to a single node, any of that node's interfaces'
   unicast addresses may be used as an identifier for the node."


draft-ietf-6man-segment-routing-header-26:

"4.3.  SR Segment Endpoint Node

 When an SRv6-capable node receives an IPv6 packet, it performs a
   longest-prefix-match lookup on the packets destination address.  This
   lookup can return any of the following:

       * A FIB entry that represents a locally instantiated SRv6 SID
       * A FIB entry that represents a local interface, not locally
                                       instantiated as an SRv6 SID
       * A FIB entry that represents a non-local route
       * No Match"

It would seem to me that the first match bullet point is effectively a
node IPv6 address match.

Regards,
Mark.

> Yours,
> Joel
>
> On 3/6/2020 9:17 PM, Mark Smith wrote:
> > Hi Joel,
> >
> > On Sat, 7 Mar 2020 at 13:12, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> >>
> >> I think there is a difference between
> >> AH Is optional in all IPv6 implementations and deployments
> >>       and
> >> A standard may be incompatible with AH.
> >>
> >> Having said ath, we approved SRH knowing it was incompatible with AH.
> >
> > I don't think 6man or the IETF have "approved" it. It's still a 6man
> > WG Internet Draft.
> >
> > https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26
> >
> > 6man could abandon it just like "IPv6 Router Advertisement IPv6-Only
> > Flag" was, due to lack of consensus during WG last call.
> >
> > Regards,
> > Mark.
> >
> >
> >> So whether I think that makes sense or not, we live with it.  (In this
> >> context, we is both 6man and the IETF as a whole.)
> >>
> >> Yours,
> >> Joel
> >>
> >> On 3/6/2020 9:04 PM, Brian E Carpenter wrote:
> >>> Tom,
> >>>
> >>>> I don't understand what you mean by "AH is optional" in this context.
> >>>
> >>> AH is optional in *every* context. So it's completely legitimate for
> >>> the SRH architecture to state that AH is not used in SRH domains. It
> >>> might be used in packets that are encapsulated for transit across an
> >>> SRH domain, but that's fine.
> >>>
> >>> I thought this was clear when we persuaded the SRH community to drop
> >>> insertion and specify encapsulation.
> >>>
> >>>       Brian
> >>> On 07-Mar-20 10:00, Tom Herbert wrote:
> >>>> 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
> >>>>> --------------------------------------------------------------------
> >>>>
> >>>
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list
> >>> 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
> >> --------------------------------------------------------------------