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

Andrew Feren <andrew.feren@plixer.com> Fri, 14 October 2022 22:05 UTC

Return-Path: <andrew.feren@plixer.com>
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 CFF28C1522D2; Fri, 14 Oct 2022 15:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=plixer.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 9hyhbQ6VAvLm; Fri, 14 Oct 2022 15:05:13 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1anam02on2132.outbound.protection.outlook.com [40.107.96.132]) (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 465FBC14F73A; Fri, 14 Oct 2022 15:05:13 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Lk45rY2uL3Pycz67oomUsJFDzppgfQ/eHUkDW9WxenlOYu56OIuPB3j5xvtE/L2KLUce7vwnJ2jJRDeHMqZkjWR7/cJCRMvaA8GJvP862YKTuJXpT23i4u48y7CYwq+NNpP1eDOvs7syZaJL9njWa20tMy77BagwGmnbskajv8sfUk8gddPplEFguzZoOyCkcY9RtQ0vV0T9hEOuRXdZvZI2j4T4Z4m4yniBPT4nlF8LDdFnF9SVG6LVW99WcfzGQuHvffd2kh4UtqtGFnZwTqoyLzKe57ulGRM/oDb9UbrFo/6+TtspEknBwkPujB7OWOQ5Dy1AP7sKl2ycHkxCGw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=L9NzYlTFIOGuCjiJnlZHmydLBetfgcF7G+mZr+gCJFI=; b=A+eygkVM+Gj6iTXrj5hNZkj2dAgzUk2wIYIed7inrCxrZuWHDp2Hd4aZcGk6tU/eOvCQ4YR6oEkBHP53kPbWsODi9TnJmziX8I3rA41RI7YKdTyPA6I5Npjr6G7Spqj72xRzdaekmdO2qXc+PSjpUumvS3ffrQ88yByc/HcF4M/NQajFQ7LCPtw5w4P+gYuDhfpFrzv7eJrB/zHOAZFrfHKFso81xfA4FXFc9Xn+HuWnNjOQmY5iYWP3WH3M/ceBvQO2s9ftS5w++GiBm42gAwjX+Be9UMGwGv97aDUX13eUMxZ+Hsfx/OG+B26J52Nux57211AAjGWLwPMs1OMbvg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=plixer.com; dmarc=pass action=none header.from=plixer.com; dkim=pass header.d=plixer.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=plixer.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L9NzYlTFIOGuCjiJnlZHmydLBetfgcF7G+mZr+gCJFI=; b=H2+ycR6e8YDAsolNZJXQbYsdaThxDmF2WY0FZ9KikUfUoO5/Jw482oK8la8dXybHnSn6TjoNlTFIEMkAcfxPrCM55Rh4Djlt5OW3gMEe6ahq5+ekbDJgq7GNnAOahYzSqueZscSUZzhd/vPjmaBpoI1Sdzhxf5BvBP963U5HPkg=
Received: from MN2PR19MB3709.namprd19.prod.outlook.com (2603:10b6:208:190::10) by DS7PR19MB5976.namprd19.prod.outlook.com (2603:10b6:8:81::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5709.15; Fri, 14 Oct 2022 22:05:06 +0000
Received: from MN2PR19MB3709.namprd19.prod.outlook.com ([fe80::f166:1db5:d8cb:e191]) by MN2PR19MB3709.namprd19.prod.outlook.com ([fe80::f166:1db5:d8cb:e191%5]) with mapi id 15.20.5723.026; Fri, 14 Oct 2022 22:05:05 +0000
From: Andrew Feren <andrew.feren@plixer.com>
To: Benoit Claise <benoit.claise=40huawei.com@dmarc.ietf.org>, "iana-issues@iana.org" <iana-issues@iana.org>
CC: "opsawg@ietf.org" <opsawg@ietf.org>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "ie-doctors@ietf.org" <ie-doctors@ietf.org>, Paolo Lucente <paolo@pmacct.net>
Thread-Topic: [Ie-doctors] [IANA #1240167] IANA question regarding draft-ietf-opsawg-ipfix-srv6-srh-01
Thread-Index: AQHY2ZiejYS1kqlghEK4z6Kj8MDgG64OYU4k
Date: Fri, 14 Oct 2022 22:05:05 +0000
Message-ID: <MN2PR19MB3709F2E3D699AE1C85AE04DDF0249@MN2PR19MB3709.namprd19.prod.outlook.com>
References: <RT-Ticket-1240167@icann.org> <ZRAP278MB01766F8AD29CF2DBB567AD4A89519@ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM> <9aec7aa2-e654-9976-befe-c19730759877@huawei.com> <rt-4.4.3-591-1664506716-768.1240167-37-0@icann.org> <0e55d3c0-c72a-728b-5176-59ede08eb6eb@huawei.com>
In-Reply-To: <0e55d3c0-c72a-728b-5176-59ede08eb6eb@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=plixer.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: MN2PR19MB3709:EE_|DS7PR19MB5976:EE_
x-ms-office365-filtering-correlation-id: b4a72a0d-c2ad-45ad-bf58-08daae3026d3
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: gcOdZTRZv8m70Ry3dXyrOFmYr+Q7tkFS7T8+qUGOEkxniRjEDPqd+anDiKXBKC3dXplvUWOyvnQ7d/eMtT0F6nHhvNOpX3pU/5Ca5gNthTcd7VQH9DfVNNlb6QX+4QEbFFCfYFLTr++67DZ7CnNn1MprCS4jiIjvXjl2zLUaLK7hyd0J2gJrH/zDAi+o5zLObwK8r3ScvxCZ2Qcm4MDWaUH/n6PFg2Og6xyuczjTKXCXxtNR4W9Atw7UJdmX/V1x+9ExP76n+9YF21dw1IlfRyqWJsEnNUdQMu0J/E3I9e+IVQ6jOGzegLJ0cpze22hAeJHjiANB672RxBtA+g0v02ayl/jfW5yoYHqE6VKoOech0Pg3JRXDAQYSc14/kadBbSUlrxJKVT0WsVHDyrj8XkLbTH1VVA1BHR3pv2cnBb1cCIxWZfqdStJ3z0Gsk8Yil3ZDL7W6IYC02+a/XBVB+l3qeEQacYQEvgrgiWNDK1Maxol1jBjS2/PrijPJoCi753Y0hDs+dhx2Mpvx0Vm0l75Y8QEfvCdnIF9HQaPgH71nhEZvaW1P+1KDPK8w/3LFeuF3C32D5CUWz7XmtF/H3/Fan4rCy4/6Z4uMDF37CR15TukVQYjj4KF730Y2aOs/3T7unk0551+EeHv55JUfybGFe90OcQKcAGXWYadTcuwaPaAlQH4pKx3wUNCJ/R2g/hZP/z3VJ/PJAR2BHqvhm1GnZpJZxrBRGOESJanLVL4k47W2dfYdc/w8OOjphjSHVSiGEIz1Ec+Udpxz996bdPncmXDSo1qcVvs4U5teGRU=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR19MB3709.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(396003)(366004)(39840400004)(346002)(136003)(376002)(451199015)(52536014)(44832011)(9326002)(41300700001)(30864003)(66899015)(5660300002)(8676002)(38100700002)(110136005)(54906003)(122000001)(4326008)(6506007)(478600001)(26005)(33656002)(76116006)(7696005)(71200400001)(66446008)(66946007)(9686003)(966005)(8936002)(86362001)(38070700005)(66556008)(64756008)(316002)(53546011)(66476007)(55016003)(19273905006)(83380400001)(166002)(186003)(2906002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: MJZbbkCyODmMgtJFCUtDbgjFO/UIHymcKiKoGd+QUMFw2eTfJi6q0Ff5dHLXy/4EbZOqyRRIeKcIiFVAdVdrLNvENvvTxmfI0BlqCOYW3XSSf4PUuFtblYFgy2Sw5Y8BNmUm5UOeaeRm3MlLgFfA/KjW6b0ZuZuGyUaZHP5UQhEK1QZj5nbCBtPP5KpzJ3tO4ALDrXX/vwuzYyCMSH503GGxfu5XrTPjCyuqFXi9niNdLjKhCYXuV9G7WMkrPF9wz+DEbTGdINCFzHy1CJn1cj7w8s7sUczIHape/2yIppSb5nxZnjxzppHZ0fUyjb7ObevPbWC6azHoFy59RAQKcEDe5Hh99a1un/kIngRspak4iWRa/Pl184BH9BpFNLs9NkgH5HmOWxdXYHgjFQi1X1R/ahGQyPW7pNFNjIChiSO40ZQkndOVxUhGVk0CTkht6iG8RIzQC8g1CzXqZJM4Q/RLIVn8QGvm2Btz/q9dsxQkqGGCCqQ/nimOkx6MJAudptPUFa80IqhtHWqDRU2dl65th8FVuKC5nE/04NYUced396b2NHDAS1DE7Dkfu45WxkIGYCjoo4jaaTt7r2zGITqKN9CmOzs6XVFdHitKzoGX3akACb5v+VCFEwFAEqANLSJPzfwW7CEuuwjaPKXI17yGjnVz+aQ/uGGYBFh7YiiysXwWTGx/H86t3lRyrM9G/R11dTrwamMjf+A91KkzJGmT/UYSfYL2gB7A/0Nb0wcP6sGkvB9FCzeNodAaFYTh8/9AdyniwamT6xnx+1lEYxanRk+D7AMWRVRaUIjnIlD1MpjVGtxJRSbSBaLB9DIhG7d5Gbv2cxuOYfmo5mFCNZ6sGdzziPklyPnWnmx5napLsTiDP046I9ta3Rx9ljt2rWO+4Ga9ftE+LuxdvBc0idRawJ7SAhK7wY2UTyVvuwl4Are9VEURhYq8/ts6HNFymoEzbLpBUHHXtbgJcp9O/Y42hHe8x7RCnpuF0sC7v5MBXQNKNORFKYlfUc3HlsDe7XfVQ/gjYdfsLR5+hhtNQdj1HKO/jEUtReXONCe1x/HtFOwPVxKtMwlWIlO9cH5TtuI7OQQjKd9m+is6zVzJ3zQdrmTndpi0OJn2RJ74z7KRRqMQtdl2hCARIwWdLr+7oK4kZhNnKyBmCDi6c5YJ0IipWd4/QdQ2sYpEWUp9mqSE0VtE8rwCYDmygAAmogbmhyxK956gcSwxcUXrs0A71qxSyCudJmRsfvORrwV+01MmKiW6N6niju+eyLTbQI5vhnfybqEZikoww1v+DIYZoKUnzmZqn38/4TcqgspVLxUjk/dSW/tToRuJ77GeQghn+cl7Fro6ICyGm4dfkvfKhghJE8Ev5xMgDPwGEU0epHVKD3xjV6mwsXY0Aalp16R5EZWzLHqLmNTaPbvWZdFPnaJBdzfD5Ddub7M+i9EXpt/mWJCPgc+W6YOZE8n+taEwOKnTEDr6EP/hQvG3eFBcmpUxQOdttZbTXooYXetlFCPQkJax8ZIyZS7qdQuKdNXyNktiCAM5umiSK26IJke/VnR8c/1kMM8sTB2E/Q4uyiGQ2rUbUZK0vB2wcIe0GmKkqoktHB2ZjAZOX7kQSgqj9A==
Content-Type: multipart/alternative; boundary="_000_MN2PR19MB3709F2E3D699AE1C85AE04DDF0249MN2PR19MB3709namp_"
MIME-Version: 1.0
X-OriginatorOrg: plixer.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR19MB3709.namprd19.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b4a72a0d-c2ad-45ad-bf58-08daae3026d3
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2022 22:05:05.9108 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: dc941f2d-c470-4728-8910-fb11111d215f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Ne3JHPARINNwLzeZ6qJEMOLHwWYleBey8Fi+gtldj03wX1iLACI/kPIDgbBp3OOOtbkV+AXz4x0UqEZ4Xebgzw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR19MB5976
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/QAEuPQXgXy09v4C687qlkeKCiZk>
Subject: Re: [OPSAWG] [Ie-doctors] [IANA #1240167] IANA question regarding draft-ietf-opsawg-ipfix-srv6-srh-01
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
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: Fri, 14 Oct 2022 22:05:17 -0000

Hi All,

First the easy part I didn’t have any problems with the IEs.

Now for the registries.

To Benoit’s 3 use cases.

1. A new IPFIX IE is added in the registry
    A collector now knows the name, type, and semantics of a new a new IE.  This allows the value to be named and stored, but actually doing something interesting with a novel IE would require additional intervention.

2. A new value is added for one of the IPFIX sub-registries
3. A new value is added for in the external (non-IPFIX) registry
    I know these aren’t quite the same, but for me they are close enough that I’m going to lump them together.   This is maybe a little better than a finding a new IE, but it still isn’t clear to me what I can really do with this information other than give something a nice name.  For example looking at “SRv6 Endpoint Behaviors” my hypothetical cron job could learn 158 is now defined as “Andrew FUBAR”.  I know it is an endpoint behavior and I can name it, but what else can I do with it?

I’d love to see a database or something that I could reliably pull information from.  Parsing the registry is already pretty finicky.  Getting a notification when registries and subregistries are updated so I can act on them would be much more useful to me.  For IPFIX and IPFIX subregistries this list tends to work for me, but that probably doesn’t help the broader community of implentors.

Adding an embedded link in the “Additional Information” column may be the best we can do today.  I think it should be tagged in a way that differentiates it from any other links in that column to facilitate parsing.  I’m skeptical of how useful this is in the short term, but I don’t see a reason to oppose it.  Also if we don’t try new things then nothing changes.

-Andrew

From: ie-doctors <ie-doctors-bounces@ietf.org> on behalf of Benoit Claise <benoit.claise=40huawei.com@dmarc.ietf.org>
Date: Thursday, October 6, 2022 at 11:30 AM
To: iana-issues@iana.org <iana-issues@iana.org>
Cc: opsawg@ietf.org <opsawg@ietf.org>, mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>, ie-doctors@ietf.org <ie-doctors@ietf.org>, Paolo Lucente <paolo@pmacct.net>
Subject: Re: [Ie-doctors] [IANA #1240167] IANA question regarding draft-ietf-opsawg-ipfix-srv6-srh-01
[EXTERNAL] CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Amanda, IPFIX IE doctors,

See inline.
On 9/30/2022 4:58 AM, Amanda Baber via RT wrote:

Hi Benoit, all,



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



We can keep separate registries in sync (although we don't currently have automation to ensure this), but is the intention for the IPFIX IPv6 SRH Flags and IPFIX SRV6 Endpoint Behavior registries to be contained within each IPFIX IE registration's Description field?



In 2020, with IE Doctor approval, all IPFIX IE Description field tables that constituted sub-registries were replaced with links to separate sub-registries located outside of the IPFIX Information Elements registry. You can see the list of sub-registries under the heading "Registries included below":



https://www.iana.org/assignments/ipfix





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-<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-01>

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).



I'm afraid we don't have any of Michelle's notes on this topic. What will you need IANA to do? We may need to put you in touch with IANA's technical director. In the future, the registries will be moved from an XML-based to a database-based registry system.
Regarding the argument of "having a self having a self contained IPFIX IANA registry, which we can download as a cron job in the collector", what we need is the ability to retrieve either the entire registry in one go, or have pointers to other (registries) the IPFIX collector has to take into account ... in an automatic manner
The former, with subregistries duplication (and synchronization) might be beyond repair at this point in time (at least, I don't have the courage to engage), on top of pushing much administration to IANA for the synchronization/maintenance

Looking closer at the IFPIX registry, let me provide a logic that might work, without too much changes IMO.

Let's say I take care of a IPFIX collector, which I need to update on regular basis, there are different cases:
1. A new IPFIX IE is added in the registry
    Ex: Let's say I specify in IANA the IPFIX IE 492 = "my-new-field"
    I download the entire registry as a cronjob, install it in my collector, and I can now understand all flow records that contain the new IPFIX IE 492
2. A new value is added for one of the IPFIX sub-registries
    Ex: Let's say I add value 25 = "my-new-classification-engine-id" at https://www.iana.org/assignments/ipfix/ipfix.xhtml#classification-engine-ids
    What is the logic?
    I download the entire registry as a cronjob, parse the file, when I arrive at IPFIX field 101 (classificationEngineId) => I do a lookup on  [https://www.iana.org/assignments/ipfix/ipfix.xhtml#classification-engine-ids] in the Description field , read the new value 25,  install it in my collector, and I can now understand all flow records that contain a classificationEngineId value 25.
3. A new value is added for in the external (non-IPFIX) registry
    Ex: a new port is added to https://www.iana.org/assignments/service-names-port-numbers].
    The following IPFIX IEs refer to this registry: sourceTransportPort, destinationTransportPort, udpSourcePort, udpDestinationPort, udpDestinationPort, etc.
    What is the logic?
    I download the entire registry as a cronjob, parse the file, when I arrive at any of those IPFIX IEs => I do a lookup on https://www.iana.org/assignments/service-names-port-numbers in the Addition Information field, read the new port value,  install it in my collector, and I can now understand all flow records that contain the new port value

At least the logic could work (even if looking up two fields is not ideal from a logic point of view)
I checked all http links in the IPFIX registry and found 3 "exceptions"
- [http://standards.ieee.org/regauth/ethertype/eth.txt], will not work, but we might consider this one as an exception.
- portRangeStart and portRangeEnd point to https://www.iana.org/assignments/service-names-port-numbers. Not to sure how to treat this one in an automatic way
- [https://www.iana.org/assignments/ianaiftype-mib] should be treated differently, but that's fine.

One conclusion is that there are different treatments whether the links are in the Description field or the Additional Information field.
Interestingly, RFC 7102 doesn't mention this Additional Information field :-) And this is precisely this one that I would like to use below, since we speak about non-IPFIX registries in draft-ietf-opsawg-ipfix-srv6-srh.
If we don't pay attention to that detail, here is a proposal (combining Med proposal with the logic above)


5.1

<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-01#section-5.1>

srh-01#section-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><https://datatracker.ietf.org/doc/html/rfc8754>



Additional reference:

https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segment-routing-header-flags





Note: and similarly for 5.9<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-01#section-5.9>.  srhActiveSegmentIPv6Type

Note: as you can see, I have a different opinion that Med on this one => we need to point to the specific registry within the group, for automatic treatment



Would that work, or IANA/IPFIX doctors will frown upon because the "additional information" field is not mentioned in RFC7102?



Regards, Benoit







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-<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-01#section-5.1>

srh-01#section-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-<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-01#ref-IANA-IPFIX>

srh-01#ref-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><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-<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-01#section-5.1>

srh-01#section-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><https://datatracker.ietf.org/doc/html/rfc8754>



When IANA links to this registry, will the link have to point to, e.g., https://www.iana.org/assignments/segment-routing/segment-routing#the-specific-registry, or would it be sufficient to point to https://www.iana.org/assignments/segment-routing (the registry group, rather than the specific registry within it)?



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



thanks,



Amanda Baber

IANA Operations Manager





This email message and any attachments are confidential. If you are not the intended recipient, please immediately reply to the sender and delete the message from your email system. Thank you.