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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 30 July 2021 21:48 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 29E9A3A122D; Fri, 30 Jul 2021 14:48:55 -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 J_MS39CFI328; Fri, 30 Jul 2021 14:48:50 -0700 (PDT)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 B876A3A1230; Fri, 30 Jul 2021 14:48:50 -0700 (PDT)
Received: by mail-pl1-x635.google.com with SMTP id t3so10565190plg.9; Fri, 30 Jul 2021 14:48:50 -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=FLRow4UBr/LPLHGBpDG4PMHeYXuTJJMsoChWw+fM8NY=; b=vBPl3A/pjoH0rzPB3QjSedccAnVCSxeqB1vDn0aOLpObaWuTmAfqWb5kN1MN8LH+pW +JkD+So/AAYu99Lihgvto1TQSD2RUmQyfHtIljLRqbhSYNFBwIIPxT86zVo6b4G/8R/k NGKRoSZMNhEtgw7mZTs5YaqIU6uwi+l599kQcDok/6pS4rK3ZNTHjyy/1jGRPXWmV+hW mPYs9oJAWM4g26EauQ1uSuLzsiQpM7Y3Ja6rWfG67iAgNVLF0AJDPDl7NYn9EYXyGFWw mTKigjos7RiR19ZIpGGtH37yFPgIv81Ka+TWWayWJ/hL57JCVd/rp6PzfI1H7F2PRh8x goRA==
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=FLRow4UBr/LPLHGBpDG4PMHeYXuTJJMsoChWw+fM8NY=; b=GH8gx29biIavELgtZ6djtZSiv40tRkL5jkjBpOYjwQYebZreUqzCp5p53y93u0Iz0s fCNNIBMwjpLrAe4LvpOyRoxNT9ujpPQEIe8kP9rBcx3/fDrc+YJT5bSEPFOipjs4uh0J vad/A8wDMQpo9siNxE+SeXENZcPC+sjXmUNEmPQieHy43gX5WEnJjjB1x9BaXLmJMn+F XCqzWHBMuROCdQCyIhewqfxnKevnx/SToI/Of5UaWxfPq5A1S1N3vkgzy8dLmjbLqVFP 2yFssxY0fgeCffaGCMZ8mR0HYhUl3MjZTjwMNVaXZQNoKUDWwkSULhE8yAHicnLVlXny aDtw==
X-Gm-Message-State: AOAM533nrBbo6wgxtviAsS7XSbMo92G42e5XZD2hqpOgGLICNFPm5ybj LOr2QapuPhHh8w0JFi7daR+KDTzxZTWG2Q==
X-Google-Smtp-Source: ABdhPJy+obBMJ+CSQTHf8rFVwtpaNcvOIGmrXmMFqtJ8taEQa/lu9iJ+i0OtJCBbWQUalcYUsenbbw==
X-Received: by 2002:a65:4342:: with SMTP id k2mr4039120pgq.138.1627681729532; Fri, 30 Jul 2021 14:48:49 -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 p11sm3157890pju.20.2021.07.30.14.48.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Jul 2021 14:48:49 -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> <e889a219-26b2-2a2e-6d05-bb6c7db1f89d@gmail.com> <AM7PR07MB624861D6476085FC7665A9ECA0EC9@AM7PR07MB6248.eurprd07.prod.outlook.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <fba60f20-69d8-0cd4-fc18-3b33bc5bbe09@gmail.com>
Date: Sat, 31 Jul 2021 09:48:46 +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: <AM7PR07MB624861D6476085FC7665A9ECA0EC9@AM7PR07MB6248.eurprd07.prod.outlook.com>
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/9BR_ghvbh00uPKNUBi-Eif5vm_I>
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: Fri, 30 Jul 2021 21:48:55 -0000

On 30-Jul-21 21:22, tom petch wrote:
> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
> Sent: 27 July 2021 23:00
> 
> 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".
> 
> <tp>
> 
> I am not Juergen but ..
> The few zones that I have seen have been alphanumeric and not numeric so making the numeric form canonical has always puzzled me.

You should widen your horizons and look at Windows. The index is more fundamental than the identifier, exactly as RFC4007 says. Portable code needs to dig out the index (an integer).

It normally doesn't matter since the zone is meaningless outside the host; it only matters in the management plane. You need to be very clear then 
whether you are transmitting the name or the number. Making the number canonical is more portable across operating systems.

    Brian

> 
> I agree with Juergen that for Problem or  Performance, then zone is helpful.  My concern was more about Configuration.  Thus draft-ietf-opsawg-l3sm-l3nm, currently in IETF LC, configures DHCPv6 customer-addresses as ipv6-address, ie with zone, while the protocol specification, RFC8415, has 
128 bit fields for addresses i.e. no zone.  This implies that all YANG servers must accept addresses in the zone format and strip the zone before using them.  I do not know if that is what YANG servers do in practice.
> 
> Tom Petch
> 
> 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
>>
>