Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de> Thu, 14 April 2022 19:38 UTC

Return-Path: <J.Schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6243A0EE4; Thu, 14 Apr 2022 12:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.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 CFjfCHGp5uEV; Thu, 14 Apr 2022 12:38:43 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on20606.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1b::606]) (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 193F53A0ED6; Thu, 14 Apr 2022 12:38:43 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HZsUGBU9aeUSdglp3FMDdGD3cszKwtbgzZDy+TmQfO3CO0P2WibVH1jvP9++nGr+H4FURUwUDaYf5TK/M6hmTW3BbUMBbu9E7A1ClP+be6WQ1ainIvYRLUjrpWm8wCn+7fRakciBTev0khNMxRVgYDbvkzDjX2GvJo9ZtS5xHTsXLxrzvu6g8lcBZLD/q/K+r9iuWIWOInQ3JZ9Xzd8ChKDtu3b2oUU6eFRlBkN4t/pvqE6e+MgFjlOr2VEGBGt9q32gk/8rJO0FC4cWkmSKcj7/RZfEX9sdbV7TNxkS2x6+RXA53NNcqUDJYWWEE2VFL/RDB83KMYGFLRJtLjplXQ==
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=xuq9e5gxIIolNnM6q8DCiVtxaTSSM+AlZpyfaYPtIFQ=; b=Dv8QSxycq2Tbt0VXDtFoOKRihGShhqns92XkYA+YQpzjJqWmXGlAD4fdeHkmN1X2hOBl5M4IHPXoDjNaab6M2QJ4MjLg6X0FDE0q8Yg6MWC6wbq34jg9iICWbyqHUxNrnEXw5AjZ9WTqp6HuX3ZTnEWIEMxDb2Kh+zTpmSEiXFogX6+9auQqqIrxfOaGUgzNgu4SLi6q4w/yCYFN1sC3Xl3cKRhOhDE19NbCHYgNtyq73E2BXAy/GZKGqdL+hFrt9POU3mefdP+BQ5asEDOP45SYe391evJddKmXKzvEZGzqW0QWyD5Ayf7NsqObzaPkGg96jNysVcCmvDm18Gp4xA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xuq9e5gxIIolNnM6q8DCiVtxaTSSM+AlZpyfaYPtIFQ=; b=IHz380/xVVucyMhwj9I8gS3k6PUXqJd/3bODbkFiZN3o1veNh/JlIXXihlBYfPYCzSK2d9+MFozNngmXwazwT5zQwoxaljyjLj/IbovESmHiFnWb/w2njXf6GVdZsEr/AHh5840mo5ywyoIFk7vkXejxiOaaNOkGsdqSMqs51Qk=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=jacobs-university.de;
Received: from GVXP190MB1991.EURP190.PROD.OUTLOOK.COM (2603:10a6:150:3::6) by AM9P190MB1283.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:272::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.20; Thu, 14 Apr 2022 19:38:37 +0000
Received: from GVXP190MB1991.EURP190.PROD.OUTLOOK.COM ([fe80::5929:c22b:95d2:40a2]) by GVXP190MB1991.EURP190.PROD.OUTLOOK.COM ([fe80::5929:c22b:95d2:40a2%5]) with mapi id 15.20.5144.029; Thu, 14 Apr 2022 19:38:37 +0000
Date: Thu, 14 Apr 2022 21:38:36 +0200
From: Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andy@yumaworks.com>
Cc: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, Martin Björklund <mbj+ietf@4668.se>, "lsr@ietf.org" <lsr@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <20220414193836.ufqzfhnitb5l5w3h@anna>
Reply-To: Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Andy Bierman <andy@yumaworks.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, Martin Björklund <mbj+ietf@4668.se>, "lsr@ietf.org" <lsr@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
References: <BY5PR11MB41966C83474B52949C2B660FB5EF9@BY5PR11MB4196.namprd11.prod.outlook.com> <20220414.152331.1522036488630734842.id@4668.se> <20220414134730.62e3fyhl7e4pvuz4@anna> <20220414.160345.1807693114840953491.id@4668.se> <1347E93F-F193-4677-8070-5E28EDB2F14F@cisco.com> <CABCOCHTPZ+ieLeNRhDR7AmyYYhEgq2bjyHsW-ARM3_9sAip0vQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABCOCHTPZ+ieLeNRhDR7AmyYYhEgq2bjyHsW-ARM3_9sAip0vQ@mail.gmail.com>
X-ClientProxiedBy: AM0PR06CA0082.eurprd06.prod.outlook.com (2603:10a6:208:fa::23) To GVXP190MB1991.EURP190.PROD.OUTLOOK.COM (2603:10a6:150:3::6)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: ca92ec37-decb-4374-3274-08da1e4e5ed1
X-MS-TrafficTypeDiagnostic: AM9P190MB1283:EE_
X-Microsoft-Antispam-PRVS: <AM9P190MB12839D9EC3CCE35CE20BE1E4DEEF9@AM9P190MB1283.EURP190.PROD.OUTLOOK.COM>
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: ditdqK/i89ueni3zkoi5yOYMRuYPD2eyr2f8j6yTbWR0kr8wHccyf59u/KJGg4a6/l6NE6ByLVxJV9pwXuEBIC0q7jljEJQJMXsRjJKJ1Pya5QWDWaICR9Xh3Ad9INUyVnzjvqvJ3GFZE94RE9qPqyyCi7r8Q9uMkEu0K41cfpzKCXEa1MX6xPZZI1Mto6Myg3D7pip18kpDDQabNh2C1vO64V58SpTqZOXkdqYctPWYWKVpOjr9agYJ2LKMnSUfq4Ynv6Vj3DBe99Hew6wdIgwh7dDAWr1FUGBr7QHL0ogdjDWQFL8CjqCzxGRU/N2BjpKRFQiHH7JkqYGPq4ubivzYfVebYR8iQHYDZao5KxYVc+ld0L2QX4ZXpJtRUA7hZts+IrbAwrEUTv/2RrDqux0uhQPX8J+2AUnpCkT3v4s+1zt7YE1bvUcNg/prPfkjvL4QfRrmNyQQTARUOJtgjDTMtA467m5v7x5UOVWn9dNcffwL5eHoFfvA1rFZtNKLEim+5nx17jF4wASMQ0qn6xtWsgyDQcCxrtE/vqIYPzQ64J/lY3RoeCirDxZ0KrpoJ9EdIL2m3zT8YZjK/dd9dLD7WXqDwfJODdkmqmjBv6gtDKp7rnQt123peV0aBXjGrJZYvWNepsbfqr0GI13AoGEUjgAYcZNLxiHkCfkE90PcN26Zw82Yu+GQZRzoC6f68rLP4NXDmYzsO0TQLp3+vjFdMYNipZ6Cio1RbSXVvDrblnwPJOxcbH3OMefq5sgpSG3/BaQ/DjxtkIchVT8Hc1H8WNsOV/JUNv7SK/jWSac=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:GVXP190MB1991.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(7916004)(366004)(54906003)(52116002)(38100700002)(38350700002)(85182001)(85202003)(6512007)(6506007)(1076003)(66574015)(26005)(83380400001)(33716001)(186003)(40140700001)(8936002)(9686003)(6486002)(3450700001)(5660300002)(2906002)(4326008)(86362001)(498600001)(66946007)(66556008)(66476007)(6916009)(8676002); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: geoNPzTdYO3x3Ul1QGZ2/OHouuZmAkqQGNTMJ9GE/+SnjJj9DOiA+iBP5YUsUfbPOm/yjZ2kVOFug7iUUKSsW0i1H0/AOGnQarsu7FxQpsmREvD3ZNCN1t2bP1UKRq9OwchVUe/d9mk14SfAoKXFn0xqGI3pQO4xf8UnAuAlm7w6qcFcZ4h7XY1EMboyhjpWotDAmXIwoOAyloE9Yq8FQejnUny5lGkasnbFUrsEGCdvPUA8wK0as2hVw3lZ+RNbVNSF8h6GV8bdJ0OSwBfKNZP/gIuI3J/rAQVjwyOzzWZ7cmUWjrhVA4eN3wy8FJvzAe3vjPowzMAnTYfXmJwLV4SGwF0ubK5ee4c2oKfhjC3GYhIzhJyBfzxJyiFpVKXifO09MGOXu1iJlf+Lvt8BuumOAHOCdeGR2qxuHlPFjEyMgSy3uYGrgXVNXAHTH1s9lF1K1vALbuCw71y8h3tQPRUnS8Kw1spNC+VmxAiRhnVVghCy6lTjRw12H289DUWHRM0qIFr50+sEurG6Y5XalVYiYuVDPtQkEhE9PUNwSxNPvnDtWr0kV636ZCgFpXLJl30VtnXWWDmXxanlyqo2643RvBd2+iaa7GDdx3odhwI/ojQRf5hIKklblCNfr9L7AQzAjDEh0J7xH/I7A73dtBe3R91mUdWUiRl2ZKd4OWVLcExED5fTWxYhhSCKno/ll6i378GgqXIRUWgD81SFIv+faKPf1I1qiEKaRjPrULmnDjA6J+X366BeF884JAkRK5HBvJeILlIXFU7EAbSxSk6z5jsPionyXuDc7DDetinnTJh42ZF/wr6yzUvEfnsUKdQ6bwBv4p+d0TWL/NtZvOkQREnihKygrLWIuF6iHJWNIFRacELBLwL91qSx6rDiblTyRZl5FxYIyJdAbFV9F9y6tMyiYjnXSg2rMg+4FnTL/G05OwgbePrgrAdvJ2HUI8EezjfuCAYJ3QqfmYAlG9WlJiANcOKHiZFJopb4Vcdkfp6sB57lMUwy2/Er0DhtF+BrygJFP865++JCrUA8x3tOgTid6DwJI4stvPxpW5BOaC4+PoDWeldSZaImXjAqkCGDpEFAeWXX/9I/sLqQl/IX6+DLTnarQrVBy6lz+RP+m6r18EDxGmMFjUpjAdJGJP7ewbtNV5CNUKAwO7vZD+Heqia7SW0OMs/MIliJLkpFqTn4zv2vCizPKvNepj0J/V5cXfBswj76q6ShYLNrONXBJ764VBX9IiDkWx9iJL/GX7AR+e92yX4ouOX95fO/X+7uIALq/k20K/YL2rivG7D53RcnqEU3rY2suRWtsgZ+y/D4htYpzsDFgkcrBW3kittg1aNL0sdHjKYxqkENW7nilMJYDg8bpC9LAC630uhOUJrEO0nC47G4+1rJLTE0g1IKr1Dvr9viqKuksBrfdBgMLViE75oODYC78jgRdKkKAO6wKLR6l53AK3rMbmIrFkxoIF88KwO3/xCPR/upRQ+3Nu29kb1oWZDgvNbfJ6Mptfa/Z6MjMsSPa8xOkLU6BBcrnvVvGDHxAsat4SgFaKEYSPt8ReI/U6YNcsW+4FCa676bOP+hh9V/++/WL4E7alVPWCJFXB9mlwXsSMsCmrWqc1bKfIOnGU0lK3bS6EpJANf0EUAEv5NU9mfRhc0sDwHa/LwUTmKw1W+6N3+GFV86gVYQO1VldKFOk2qzzH3Sy8AS/x/4sprCn02rEEigx6yIa2Vmli/dOqjD9rDaTUIVEZpWQnx3hSYBR1iPcnz+V4qfAdk4DYCtR5N3AbOO
X-OriginatorOrg: jacobs-university.de
X-MS-Exchange-CrossTenant-Network-Message-Id: ca92ec37-decb-4374-3274-08da1e4e5ed1
X-MS-Exchange-CrossTenant-AuthSource: GVXP190MB1991.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Apr 2022 19:38:37.5584 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: NOhMxmSgH7u91NEgTrl+M97cRUpFNJwSTpjuPAE0OgiT0XFF7dAa1KfcMzPBHCMtRUx2LlnX3SXwxfkJS+35RjAEBdFCjhDvbI+qBwZHZ+k=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1283
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/AJWtD7lm2AC4PDaxs4V7vjtW1SE>
Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2022 19:38:50 -0000

On Thu, Apr 14, 2022 at 09:23:38AM -0700, Andy Bierman wrote:
> >
> So is this a correct summary:
> 
>  - zone index is not used in IPv4 at all

There are link-local IPv4 addresses, they are less wide-spread since
IPv4 stacks generally do not auto-configure IPv4 link-local addresses.
Nobody will be able to confirm "not used at all", this questions is
somewhat rhetoric since nobody can answer it.

>  - zone index is not configured by a client in IPv6 at all

Configuring zone indexes is required in many cases to reach services
that are only reachable via link-local addresses. I mentioned the DNS
resolver example and this applies to pretty much any transport layer
endpoint. This is why by design (and not by accident) the with zone
version of ip-address is used in the inet:host typedef.

>  - zone index is assigned by the system (as needed) to IPv6 link-local
> addresses

A link-local address exists on a link and as such does not need a zone
index as long it is used on the link. However, when you want to refer
to a link-local address on a system with more than one link, then the
link-local address is ambiguous and to disambiguate things you either
specify in adding the interface to be used or you embed the zone index
in the address. Since application code usually assumes that a
transport address is an (ip-address, port) tuple, people converged on
adding the zone to the ip address (instead of rewriting all APIs to
use (ip-address, port, interface) tuples. The zoned IP address
notation is meanwhile widely supported. This is why we have, for
example, RFC 6874 (but the IPv6 folks have a reoccuring debate about
the question whether the % needs to be percent encoded or not,
draft-carpenter-6man-rfc6874bis-03).

> I want to add a server option in our code to always reject (or alter)
> an edit that contains a zone index.  I need to know the consensus on
> whether it is OK to ignore a zone index from a client.

It is your choice to design a product that will not work with
link-local addresses. For IETF data models, I expect that the bar is
higher and that people can expect that IETF data models are written to
also work with link-local addresses. If implementers than decide that
their users do not need to work with link-local addresses, so be it,
you can make your server reject the optional zone index. But others
can decide that they customers can also work with link-local
addresses. If we blindly remove the zone index from ip-address, then
the IETF would break data models for those who consider link-local
addresses a first class citizen.

> Nothing in RFC 6241 suggests that this is OK for <edit-config>.

I have no clue what you mean. If your server recceives a value that
your server does not support, you reject the value.

/js

PS: I recall the side meetings with IPv6 people to sort out how we add
    proper IPv6 support to MIB modules, which led to RFC 4001, which
    later influenced the YANG typedefs. Almost 20 years later (and
    IPv6 deployed at a much larger scale) I find myself in a
    discussion where people question that we need to support
    link-local addresses. This is very irritating.

    Apparently, getaddrinfo() implementations tend to handle zoned
    link-local addresses just fine and any code that passes a zoned ip
    address string to getaddrinfo() will likely return you a socket
    address with the sin6_scope_id filled in properly. You actually
    have to do extra work to prevent the right thing to happen if your
    code passes strings on to getaddinfo(). I am puzzled why people
    want to do this.

-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>