Re: [IPv6] [IANA #1273836] [Errata Verified] RFC8754 (7102)

Erik Kline <ek.ietf@gmail.com> Mon, 29 May 2023 18:18 UTC

Return-Path: <ek.ietf@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 A0002C1519B2 for <ipv6@ietfa.amsl.com>; Mon, 29 May 2023 11:18:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0gkfFAHOS6d for <ipv6@ietfa.amsl.com>; Mon, 29 May 2023 11:18:45 -0700 (PDT)
Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86492C1519AB for <ipv6@ietf.org>; Mon, 29 May 2023 11:18:45 -0700 (PDT)
Received: by mail-ua1-x931.google.com with SMTP id a1e0cc1a2514c-786e637f06dso792864241.2 for <ipv6@ietf.org>; Mon, 29 May 2023 11:18:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685384324; x=1687976324; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=SGc6RbeVy+c4tvt4IfGKiMXpcIe76+7Uo0GPz4HqpYs=; b=KLwmDBjEWQiLESyaxUZkYBQXxQ1HIfsO8yHrVL20B/OxrPxp+a7SBBm+KuoXLcuQj+ bT/+IP4nluhI53E3yXvgySfQ0lQgOkob2dIXnCFvNkvP2uM+xoRR0PoF7jbJJnxMS7Ol OVPd/0CNdpwy0hBTUtvNbV6qjqs4Kreh7WOZlFpg39n4V45FbTLxFx7JJrZcjvXU0NJt OXBuzVU73tOpYNTI0sbZdYk6/FqIw0Hc2qFsPegj+7j3dS19gHmOWxPZ+sT4/6Skeegq M/JUdkWb3kZtXH5WcUmijZ+YRQu3A69JaYYLkpWDARx5EMuJhxx3F3RNmiHB8ntZ0v87 IFJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685384324; x=1687976324; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SGc6RbeVy+c4tvt4IfGKiMXpcIe76+7Uo0GPz4HqpYs=; b=I8bNfciJUwMn0bWT4dx2WV6UCkoprkE724tu9q88x2cbN4tuBm8DItu8zADxYo21gy e9tKsVTeowT7pvn2WB/h/Ox5mR306jz2SsSktP9DB8dZEruR6IoDST+a2k0Ru2K1BF4q jABxB27+qNSOfYqL84S6IwxNfp216pfMCQ79Y4WrvrwNb49UXct5t9q/txHP3LyieJTS LfScGdXb6WegNLq+jhlPxsn+CTNXKAMUChHA5jt633UKEQCcmv1KCMoyxEzULZWRnLkY odRAANeMNwzWm8PPOBXS7FRQbQ5KSos2rNbHLkA33Y3c5cC2XBtsPNHs8MXaEMJb3BAK /brw==
X-Gm-Message-State: AC+VfDxpnbyA7tnPjec5x3/gY7Ejf1FOPWwBPTWNxHTEc5P1M6xVkNs1 KmMW83jAbq+gItj+B8dtQXtCQlM7z72hrd59KsA=
X-Google-Smtp-Source: ACHHUZ5HPFcFCXVlI6e9iloTj/adAzvzlHb/f4paaa2ksQ1wdS58adCQ6vb3lQXlUtgcq6WWoXZlMzNJRAMwCsVaJbM=
X-Received: by 2002:a1f:3f83:0:b0:456:a834:1757 with SMTP id m125-20020a1f3f83000000b00456a8341757mr2784536vka.4.1685384324144; Mon, 29 May 2023 11:18:44 -0700 (PDT)
MIME-Version: 1.0
References: <RT-Ticket-1273836@icann.org> <20230529043131.D67F17FDC5@rfcpa.amsl.com> <rt-5.0.3-841803-1685383657-1519.1273836-37-0@icann.org>
In-Reply-To: <rt-5.0.3-841803-1685383657-1519.1273836-37-0@icann.org>
From: Erik Kline <ek.ietf@gmail.com>
Date: Mon, 29 May 2023 11:18:33 -0700
Message-ID: <CAMGpriXZ9bCE8ZneA=C4yBAXLKP4giCTKnx_11Zhf0JPmQ_WXg@mail.gmail.com>
To: iana-matrix@iana.org
Cc: rfc-editor@rfc-editor.org, stefano@previdi.net, satoru.matsushima@g.softbank.co.jp, john@leddy.net, ipv6@ietf.org, iana@iana.org, ddukes@cisco.com, daniel.voyer@bell.ca, cfilsfil@cisco.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/I89ArB95n1LtiOmFffzEWmLCtUE>
Subject: Re: [IPv6] [IANA #1273836] [Errata Verified] RFC8754 (7102)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 29 May 2023 18:18:49 -0000

I don't personally think that's required.

This erratum clarifies that Segments Left means "segments in the
segment list", not some "logical segments left where the SIDs might
actually be compressed and hold many segments."

This is really how implementations treated it in the first place.  My
understanding is that it's the compressed SID work that raised the
notion of "segments in the vs. 'logical' segments which might be
compressed".

If others care to argue otherwise I've no strong objection.

On Mon, May 29, 2023 at 11:07 AM Amanda Baber via RT
<iana-matrix@iana.org> wrote:
>
> Hi all,
>
> Should the "Segment Routing Header (SRH)" entry in the Routing Types registry include a reference to this errata report (in addition to the existing reference to RFC 8754)?
>
> You can see the registration here:
>
> https://www.iana.org/assignments/ipv6-parameters
>
> thanks,
>
> Amanda Baber
> IANA Operations Manager
>
> On Mon May 29 04:31:55 2023, rfc-editor@rfc-editor.org wrote:
> > The following errata report has been verified for RFC8754,
> >  "IPv6 Segment Routing Header (SRH)".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid7102
> >
> > --------------------------------------
> > Status: Verified
> > Type: Technical
> >
> > Reported by: Darren Dukes <ddukes@cisco.com>
> > Date Reported: 2022-08-23
> > Verified by: Erik Kline (IESG)
> >
> > Section: 2
> >
> > Original Text
> > -------------
> > Segments Left:  Defined in [RFC8200], Section 4.4.
> >
> > Corrected Text
> > --------------
> > Segments Left:  Defined in [RFC8200], Section 4.4.
> >  Specifically, for the SRH, the number of segments
> > remaining in the Segment List.
> >
> > Notes
> > -----
> > RFC8754 describes “The encoding of IPv6 segments in the SRH” where
> > IPv6 segments are defined in RFC8402.  RFC8402 describes binding SIDs
> > and adjacency SIDs for SRv6. Both these SID types identify more than a
> > single explicitly listed intermediate node to be visited.
> > The current definition of Segments Left only indicates it is defined
> > in RFC8200, and RFC8200 defines it as “Number of route  segments
> > remaining, i.e., number of explicitly listed intermediate nodes still
> > to be visited before reaching the final destination”.
> >
> > Previous versions of draft-ietf-6man-segment-routing-header (0-11)
> > referenced RFC2460/RFC8200 and described the Segments Left field by
> > use in the SRH; as an index into the Segment List. This was removed in
> > later versions (12/13) to consolidate the use of segments left to be
> > specific to the segment processed (now section 4.3.1).  However, that
> > removed the definition of its meaning in the SRH which led to the
> > current issue.
> >
> > The corrected text restores the meaning of Segments Left for the SRH
> > in relation to Segment List (which is not defined in RFC8200), while
> > still leaving its use during segment processing to the segment
> > definition (section 4.3.1 or future documents).
> >
> > --------------------------------------
> > RFC8754 (draft-ietf-6man-segment-routing-header-26)
> > --------------------------------------
> > Title               : IPv6 Segment Routing Header (SRH)
> > Publication Date    : March 2020
> > Author(s)           : C. Filsfils, Ed., D. Dukes, Ed., S. Previdi, J.
> > Leddy, S. Matsushima, D. Voyer
> > Category            : PROPOSED STANDARD
> > Source              : IPv6 Maintenance
> > Area                : Internet
> > Stream              : IETF
> > Verifying Party     : IESG
>