Fwd: New Version Notification for draft-iurman-6man-generic-id-00.txt

Justin Iurman <justin.iurman@uliege.be> Sat, 06 August 2022 14:24 UTC

Return-Path: <justin.iurman@uliege.be>
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 6378CC14F74F; Sat, 6 Aug 2022 07:24:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.125
X-Spam-Level:
X-Spam-Status: No, score=-2.125 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uliege.be
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 ft7mj6gAh8Jq; Sat, 6 Aug 2022 07:24:12 -0700 (PDT)
Received: from serv108.segi.ulg.ac.be (serv108.segi.ulg.ac.be [139.165.32.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437B5C14CF1D; Sat, 6 Aug 2022 07:24:09 -0700 (PDT)
Received: from [192.168.1.62] (148.24-240-81.adsl-dyn.isp.belgacom.be [81.240.24.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by serv108.segi.ulg.ac.be (Postfix) with ESMTPSA id 5758A200DFA0; Sat, 6 Aug 2022 16:24:05 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 serv108.segi.ulg.ac.be 5758A200DFA0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uliege.be; s=ulg20190529; t=1659795845; bh=Wkrl7fbKElvyslWZ/3hiuyG5/iURyDdW0r1y2exkQ3I=; h=Date:Subject:References:From:Cc:To:In-Reply-To:From; b=OiF34/KBoU3BkgVv5hWjwC4+uqHQ4rNdn48nSh5FgF6JshCWjpSyzss1H5VYF2aUU ocr9WVj3bMwDnLvXcRk+omMCT2QFuTaLd9e0AWvv2s58BGkIdirntBiWaO2bfVINfb sOZpAqBwrei7TPfB72twbiTQWHVLA3ouNaWSEnbidjKQhUYmcBu2+tEiSSdSYLmeLr pWEOITIlLQAD5JQu9s+n/iPEMuYUaYvhubCntpvTtQOOHHGyxPfN6CIQDGAYVKFXgO 7qDy3Z3qRFVsWvAoI0xR0v/7PZWbbxcQll6uzL284AVM5wqbx3N06RJl1C1jfmdjCP 0TpM0md+dYREA==
Message-ID: <b46323c1-198e-4d8b-03d1-92ceeb1c18c5@uliege.be>
Date: Sat, 06 Aug 2022 16:24:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Subject: Fwd: New Version Notification for draft-iurman-6man-generic-id-00.txt
References: <165979333181.56337.7726192776637775272@ietfa.amsl.com>
Content-Language: en-US
From: Justin Iurman <justin.iurman@uliege.be>
Cc: draft-ietf-6man-enhanced-vpn-vtn-id@ietf.org, draft-li-6man-topology-id@ietf.org
To: ipv6@ietf.org
In-Reply-To: <165979333181.56337.7726192776637775272@ietfa.amsl.com>
X-Forwarded-Message-Id: <165979333181.56337.7726192776637775272@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vg2rGRYeOUBLNOyx79aSWaibUXg>
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: Sat, 06 Aug 2022 14:24:17 -0000

Hi 6man,

During our last WG meeting in Philly, we had two controversial 
presentations (i.e., [I-D.draft-ietf-6man-enhanced-vpn-vtn-id] and 
[I-D.draft-li-6man-topology-id]) mainly due to the fact that these 
drafts both create a new option to carry an identifier. We heard quite 
often the "generic" word coming back at the mic, as people in the room 
(or remote) seemed to be worried to waste options that way, for such 
similar options.

And that's exactly why this draft (see below) proposes a new solution to 
carry IDs generically. For that purpose, two new Hop-by-Hop and 
Destination options are defined, called "Generic ID Option" and "Generic 
Context-ID Option". There are some explanations of what both drafts 
mentioned above should do to adapt to this new solution. Comments and 
suggestions are welcome.

Thanks,
Justin

-------- Forwarded Message --------
Subject: New Version Notification for draft-iurman-6man-generic-id-00.txt
Date: Sat, 06 Aug 2022 06:42:11 -0700
From: internet-drafts@ietf.org
To: Justin Iurman <justin.iurman@uliege.be>


A new version of I-D, draft-iurman-6man-generic-id-00.txt
has been successfully submitted by Justin Iurman and posted to the
IETF repository.

Name:		draft-iurman-6man-generic-id
Revision:	00
Title:		Carrying a Generic Identifier in IPv6 packets
Document date:	2022-08-06
Group:		Individual Submission
Pages:		7
URL: 
https://www.ietf.org/archive/id/draft-iurman-6man-generic-id-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-iurman-6man-generic-id/
Html: 
https://www.ietf.org/archive/id/draft-iurman-6man-generic-id-00.html
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-iurman-6man-generic-id


Abstract:
    Some recent use cases seem to have a need for carrying IDs within
    packets.  Two examples are _I-D.draft-ietf-6man-enhanced-vpn-vtn-id_
    and _I-D.draft-li-6man-topology-id_. While they might perfectly make
    sense on their own, each document requires IANA to allocate a new
    code point for a new option, which could quickly exhaust the
    allocation space if similar designs are proposed in the future.  As
    an example, one might need an 8-bit ID, while another one might need
    a 24-bit, 32-bit, or 64-bit ID.  Or, even worse, one might need a
    32-bit ID in a specific context, while someone else might also need a
    32-bit ID in another context.  Therefore, allocating a new code point
    for each similar option is probably not the way to go.

 


The IETF Secretariat