Re: [Cbor] changes in draft-ietf-cbor-network-addresses-05.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 27 July 2021 22:00 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CC53A0A99; Tue, 27 Jul 2021 15:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GerLdFkU0oy; Tue, 27 Jul 2021 15:00:30 -0700 (PDT)
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 9AB4F3A0A97; Tue, 27 Jul 2021 15:00:30 -0700 (PDT)
Received: by mail-pj1-x1036.google.com with SMTP id j1so2021848pjv.3; Tue, 27 Jul 2021 15:00:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=tfWonmk5hNQLoc0PeJsnkPVwl2Ryd9gEXXED8Iok3iU=; b=MlLELRNoPTp8qBgYckzdvlZWfJmXxOxswjQ4heypc7g2iFobxklw+vo8DIkvkqiyKJ 3mZA2uCHeGNHXHxlVZj+7Ryiiv6Yu7o5AnSELOt7CHzV4s6wH2gAjvqIamZ+F44qHL/n 2ErbyUuqOfTHhA2YBqnMafKV/MLCjgEsEFB5AvBJNDhIQ+Wo0f7GdyraQSSOon0nelop ShcFxpv8/hNttQPVKLSQwMyum6nY3d8nH+cmljNywSuF/68VywbpywavxoTdDROTLLAu yuXwT1vEWwcMIAtP1CgNZolQooZWXZ+tb6i/xc6gbTLx6DGnaidBGaVrdPylnLO5Rmsn n9Ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tfWonmk5hNQLoc0PeJsnkPVwl2Ryd9gEXXED8Iok3iU=; b=ZSvEx0KLHtHR0UZfsTnr8oVyYC4nJqeGqLF+2LKX4nPa0AgdtX8Z2LE6AhvzIskZ6h JFoidacMDPekJUfe6BhvJ1m9bPeVpqS1txr/zk1SyLDaPbVM4jezguXOGsMBkgjv7cej u6cmGBFWa/PkF6FwhhA7Tif8GylIZb872DA+S52ixP7tnwzliwS2tabjDaoqRxflfD4n r7vF15g2nz0JONVwE8frAFBthsoKtSiTVCN5Ytokc7FRRo9FcYiz+NpuYD3C6mpDhENy OvSebmyXSp7yBhzV57pbmx25ljFWpStRfLeHyAUjhbU7ENkhRTibqM+OeJsKu0kml56y KlRw==
X-Gm-Message-State: AOAM533TaSKwB6AjEIqTywKZyGcsHmT9xbwZrlzHzVs0vlIH+O6b4uIq cdJlwr4rKTLqBleAe0/PeSZiwgU6TYhybA==
X-Google-Smtp-Source: ABdhPJyHQ2bwoRoNbmhdtyynm5EIZDdMwkCBvOwTApenHspU81GZcFVSwKB8fQB5l2ZOS3AQP1va4g==
X-Received: by 2002:a17:902:c40a:b029:12b:45c1:21b5 with SMTP id k10-20020a170902c40ab029012b45c121b5mr20152653plk.17.1627423228882; Tue, 27 Jul 2021 15:00:28 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id w23sm4817274pfc.60.2021.07.27.15.00.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jul 2021 15:00:28 -0700 (PDT)
To: tom petch <ietfc@btconnect.com>, Erik Kline <ek.ietf@gmail.com>, "cbor@ietf.org" <cbor@ietf.org>, 6MAN <6man@ietf.org>
References: <162608928922.11086.12172415971165753394@ietfa.amsl.com> <29067.1626090045@localhost> <CAMGpriUnfMjhk7teAN-A0j5SCK=BpyJEDC+NOCJtHzmF1BFeow@mail.gmail.com> <aa9884b5-fd58-60cb-fa1d-b2d76f5a09a1@gmail.com> <VI1PR07MB6256E2C9CC9565FF2F080B5DA0E89@VI1PR07MB6256.eurprd07.prod.outlook.com> <c2c7a576-e138-1364-5ed0-a2987c1c1974@gmail.com> <20210727210706.buavt5nwairrjblf@anna.jacobs.jacobs-university.de>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <e889a219-26b2-2a2e-6d05-bb6c7db1f89d@gmail.com>
Date: Wed, 28 Jul 2021 10:00:23 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <20210727210706.buavt5nwairrjblf@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/ldMm4Zz6wgPJa-c8q33yhfbNP8w>
Subject: Re: [Cbor] changes in draft-ietf-cbor-network-addresses-05.txt
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jul 2021 22:00:32 -0000

Jürgen,

We are not disagreeing. These are exactly the sort of use cases that also
motivate RFC6874 and RFC6874bis. 

But I have a question. In the management plane, do you think that the
zone index (an integer) is the item of interest, or a zone identifier
(a string)? The description at
https://datatracker.ietf.org/doc/html/rfc6991#page-20
only says that the numerical format is "canonical".

Regards
   Brian

On 28-Jul-21 09:07, Jürgen Schönwälder wrote:
> On Wed, Jul 28, 2021 at 08:04:16AM +1200, Brian E Carpenter wrote:
>> On 26-Jul-21 23:49, tom petch wrote:
>>> From: ipv6 <ipv6-bounces@ietf.org> on behalf of Brian E Carpenter <brian.e.carpenter@gmail.com>
>>> Sent: 25 July 2021 00:44
>>>
>>> There's an "interesting" issue there, especially for IPv6, which is that the interface ID (or "zone index", per RFC4007) has no meaning outside the host. So it really shouldn't need to be sent on the wire in normal circumstances.
>>>
>>> (The conversation around RFC6874bis is slightly relevant.)
>>>
>>> <tp>
>>> Brian
>>>
>>> As I may have said before, the YANG Types RFC6991 provides types for IPv4 and IPv6 addresses both with a zone index.  It also provides no-zone 
types with a suffix 'no-zone' on the type name.  I see evidence that most 
authors of YANG modules do not realise that a reference to 'ip-address' per se is a reference to the format that includes the zone and so have specified that format in many if not most cases.  Thus it seems likely that many of the addresses on the wire are in the zone format, even if the zone is rarely present.  With hindsight, it might have been better to have specified 'ip-address' and 'ip-address-zone' rather than ip-address' and io-address-no-zone'.
>>
>> Makes sense. The reply I just sent to Christian Amsüss probably applies to YANG too. Sending a zone index to another host is rarely meaningful or useful.
>>
> 
> YANG was designed for network management purposes and there are quite
> some use cases where communicating the zone index is somewhat essential:
> 
> - If you want to debug a problem, you likely need to know to which
>   link a link-local address belongs.
> - If you want to generate statistics for protocols using link-local
>   addresses, you likely need to know to which links the link-local
>   addresses belongs.
> - If you want to configure a service to use a certain link-local
>   address on a certain link, you may have to include the proper zone
>   index.
> - If an IP address is used to index lists, things can fall apart if
>   you end up with duplicate link-local addresses on different links.
> 
> Whether we should have picked different names for the types may be
> debatable but at the end it is the YANG module author's responsibility
> to pick the appropriate types.
> 
> In other words, network management applications often need to be aware
> of zone indexes in order to do the right thing. This is different from
> end user applications (that usually have no topological awareness).
> 
> /js
>