[OPSAWG] [IANA #1240167] IANA question regarding draft-ietf-opsawg-ipfix-srv6-srh-01

Sabrina Tanamal via RT <iana-issues@iana.org> Tue, 27 September 2022 22:09 UTC

Return-Path: <iana-shared@icann.org>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F393C15271B; Tue, 27 Sep 2022 15:09:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.657
X-Spam-Level:
X-Spam-Status: No, score=-6.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 MNSDAo5oVEpe; Tue, 27 Sep 2022 15:09:44 -0700 (PDT)
Received: from smtp.lax.icann.org (smtp.lax.icann.org [IPv6:2620:0:2d0:201::1:81]) (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 B1CCFC152714; Tue, 27 Sep 2022 15:09:43 -0700 (PDT)
Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp.lax.icann.org (Postfix) with ESMTP id 42027E389E; Tue, 27 Sep 2022 22:09:43 +0000 (UTC)
Received: by request4.lax.icann.org (Postfix, from userid 48) id 3F5C8209DA; Tue, 27 Sep 2022 22:09:43 +0000 (UTC)
RT-Owner: sabrina.tanamal
From: Sabrina Tanamal via RT <iana-issues@iana.org>
Reply-To: iana-issues@iana.org
In-Reply-To: <9aec7aa2-e654-9976-befe-c19730759877@huawei.com>
References: <RT-Ticket-1240167@icann.org> <ZRAP278MB01766F8AD29CF2DBB567AD4A89519@ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM> <9aec7aa2-e654-9976-befe-c19730759877@huawei.com>
Message-ID: <rt-4.4.3-17226-1664316583-1257.1240167-37-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #1240167
X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/)
X-RT-Originator: sabrina.tanamal@icann.org
To: benoit.claise@huawei.com
CC: mohamed.boucadair@orange.com, opsawg@ietf.org, ie-doctors@ietf.org
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Tue, 27 Sep 2022 22:09:43 +0000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/klz2Lmg-H6MSGDTrC_DFehw1ydM>
Subject: [OPSAWG] [IANA #1240167] IANA question regarding draft-ietf-opsawg-ipfix-srv6-srh-01
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Sep 2022 22:09:48 -0000

Hi Benoit, 

We will review the IANA Considerations section of this document and get back to you soon. 

Thanks,

Sabrina Tanamal
Lead IANA Services Specialist

On Mon Sep 26 10:03:12 2022, benoit.claise@huawei.com wrote:
> Dear IPFIX doctors, (IANA),
> 
> We would like to get your feedback regarding the IANA section in
> draft-ietf-opsawg-ipfix-srv6-srh-01.
> Especially, the two following information elements:
> srhFlagsIPv6:
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-
> srh-01#section-5.1
> srhSegmentEndpointBehavior:
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-
> srh-01#section-5.11
> 
> I went to the IANA table in Philly and we discussed those. Hence I
> copied IANA here.
> In the currentdraft-ietf-opsawg-ipfix-srv6-srh-01
> <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-
> srh-01>
> version, we created two IPFIX subregistries, which mimic existing
> Segment Routing registries.
> The main reason is that we are in favor of having a self contained
> IPFIX
> IANA registry, which we can download as a cron job in the collector.
> We
> discussed such a project with Michelle Cotton in the past (I know that
> Michelle moved on). On top of that, it might be beneficial for the
> IPFIX
> experts to review any changes coming from a registry we mimic, just to
> see if there are no new inconsistencies from an IPFIX point of view.
> 
> However, Med, in cc., has a valid point that the current IPFIX IANA
> entries are inconsistencies already.
> Ex: destinationTransportPort points to a different registry
> Ex: tcpControlBit. See
> https://datatracker.ietf.org/doc/draft-boucadair-opsawg-rfc7125-
> update/
> So he advocated that we don't duplicate, with an IPFIX subregistry,
> information stemming from a different source. Pointing to the existing
> registry (ex: "Segment Routing Header Flags") + a RFC reference is
> sufficient for him. Solving the self-contained IPFIX registry issue
> would be a (too) huge job at this point in time.
> 
> This is what we currently have in the draft:
> 
> 5.1
> <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-
> srh-01#section-5.1>.
> srhFlagsIPv6
> 
> Name:  srhFlagsIPv6
> 
> ElementID:  TBD1
> 
> Description:  This Information Element identifies the 8-bit flags
>    defined in the SRH.  Values for this Information Element are
>    listed in the "IPFIX IPv6 SRH Flags" registry, see [IANA-IPFIX
> <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-
> srh-01#ref-IANA-IPFIX>].
>    srhFlagsIPv6 values must not be directly added to this "IPFIX IPv6
>    SRH Flags" registry.  They must instead be added to the "Segment
>    Routing Header Flags" registry.  Both the "IPFIX IPv6 SRH Flags"
>    and the "Segment Routing Header Flags" registries must be kept in
>    synch.  Initial values in the registry are defined by the table
>    below.
> 
> +--------+-------------------+--------------------------------------+
> | Value  |    Description    |              Reference               |
> +--------+-------------------+--------------------------------------+
> | 0-1    | Unassigned        |                                      |
> +--------+-------------------+--------------------------------------+
> | 2      | O-flag            |  [RFC-ietf-6man-spring-srv6-oam-13]  |
> +--------+-------------------+--------------------------------------+
> | 3-7    | Unassigned        |                                      |
> +--------+-------------------+--------------------------------------+
> 
> Table 2: "IPFIX IPv6 SRH Flags" registry
> 
> 
> Note to IANA:  Add a note to the "IPFIX SRV6 Endpoint Behavior"
>    registry so that new values are echoed in the new "IPFIX SRv6
>    EndPoint Behavior
> 
> Abstract Data Type:  unsigned8
> 
> Data Type Semantics:  flags
> 
> Reference:  [RFC-to-be],RFC8754
> <https://datatracker.ietf.org/doc/html/rfc8754>
> 
> This is what Med proposes:
> 
> 5.1
> <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-
> srh-01#section-5.1>.
> srhFlagsIPv6
> 
> Name:  srhFlagsIPv6
> 
> ElementID:  TBD1
> 
> Description:  This IE identifies the 8-bit flags defined in the SRH.
>       Assigned flags and their meanings are provided in the "Segment
> Routing
>       Header Flags" registry.
> 
> Abstract Data Type:  unsigned8
> 
> Data Type Semantics:  flags
> 
> Reference:  [RFC-to-be],RFC8754
> <https://datatracker.ietf.org/doc/html/rfc8754>
> 
> 
> We basically agree that a registry lookup is required for the IPFIX
> Collector.
> An IPFIX Exporter will export what he sees, regardless of the semantic
> or an IANA registry. The IPFIX Collector will report a potential
> problem
> if the observed value is not in the IANA registry (bug, IANA entry
> hijacked, another convention => if value not observed, I'll send an
> error code instead, etc)
> 
> Bottom line: we have two different ways to model the srhFlagsIPv6 and
> srhSegmentEndpointBehavior in IANA, with or without an IPFIX
> subregistry.
> Can you share your views on the best way to register those IEs.
> 
> Thanks and regards, Benoit