Re: [babel] Martin Duke's No Objection on draft-ietf-babel-yang-model-10: (with COMMENT)

"STARK, BARBARA H" <bs7652@att.com> Tue, 18 May 2021 18:48 UTC

Return-Path: <bs7652@att.com>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056823A1D10; Tue, 18 May 2021 11:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level:
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.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 fKkI3ALJUQfy; Tue, 18 May 2021 11:48:03 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 D5C893A1CF2; Tue, 18 May 2021 11:48:02 -0700 (PDT)
Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 14IIObhX044649; Tue, 18 May 2021 14:48:01 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 38m0nytqk9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 May 2021 14:48:00 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 14IIlxas020098; Tue, 18 May 2021 14:47:59 -0400
Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 14IIluNQ020019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 May 2021 14:47:56 -0400
Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id E6A5E40145A6; Tue, 18 May 2021 18:47:55 +0000 (GMT)
Received: from GAALPA1MSGED2BC.ITServices.sbc.com (unknown [135.50.89.128]) by zlp30483.vci.att.com (Service) with ESMTP id 8C6CA40145A4; Tue, 18 May 2021 18:47:55 +0000 (GMT)
Received: from GAALPA1MSGEX1AA.ITServices.sbc.com (135.50.89.96) by GAALPA1MSGED2BC.ITServices.sbc.com (135.50.89.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Tue, 18 May 2021 14:47:48 -0400
Received: from GAALPA1MSGETA01.tmg.ad.att.com (144.160.249.126) by GAALPA1MSGEX1AA.ITServices.sbc.com (135.50.89.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4 via Frontend Transport; Tue, 18 May 2021 14:47:48 -0400
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.57.47) by edgeal1.exch.att.com (144.160.249.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.4; Tue, 18 May 2021 14:47:45 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hPeoYRAvQSHROD8N1KDEbukrmjwaj091ohYS7+ORVKMSBO2bsXdWzH/QnN2At9p2dfu+DZuIaido4VPGy4Z4TE6WPB2sR5Nyk/jHGesg9F5cyybCpJoAhUZLjWEOYlwtwubAOzcNNxNsVyGrRRtE+Tl81uptq3vsWp8W7cLIPul5a/UgZSiiSodAYPMsEaCaxKgjgYjSaucdwWKwWAaMWSWudxoDPExHRHBS2TM3kCtL8xQb58VB9Cfo9eOKE/7pu8WCj5b4ZkcN5qGE4slkYkRg6dHzqHQFG75SBIOnFKWv/fgVAnlmOrbOP54o6yb/xQj8rCm3FyMC3gcku5u0DQ==
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-SenderADCheck; bh=/yCs8wl/dFdYMy22eQGqzHftFO4SePyP0D/3goujNG0=; b=XAntSa8NIlOKQYcUs+4cYy/nC3ojFcRyv5AYCtfmTkV96suCSS6E9QXKdJstZzvoiszspLtb0zFTM4Jz/6j17ln2/aDdKiu8JXF6G+Pc2fo7zpuHH+16ssz6yRP6G3HLZAcW3+aRxf54y/dHVJoeAW2jtYNT90G2QAjesHwL6UA1GyykpXoy30hJvq3VXnHpCk1o/znghfCrTr+CIYrLfX8cyax78+iC3M81ynDS30JWT5bBizYfA9RDERbOecgELHXiKiKfc/pRijY01pR1DXx962OKNhSEmGwkVgtIiMV0PteSKGji/rgS/VbHJ5KBeOa4XxwzuZI2VqrGqKkMBQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/yCs8wl/dFdYMy22eQGqzHftFO4SePyP0D/3goujNG0=; b=GM3WL5Wwh6BKfCit0Wc5hy2DMWt4W9eBxhE7famdw+iclx14jlQrIrNzXvqXCrMTXftsK6duhOzcOGmdDwZtwf6KkhZkYmDWvPE7KBDroa8bFWl1D2FkQeKv2kZmx5iSAUBUJnrdfHsdtJNigiJ+kfwFzsmtywBwS9RQE4zC9HI=
Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM5PR02MB3209.namprd02.prod.outlook.com (2603:10b6:4:64::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.26; Tue, 18 May 2021 18:47:43 +0000
Received: from DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d09:83cc:18fe:ab1d]) by DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d09:83cc:18fe:ab1d%9]) with mapi id 15.20.4129.032; Tue, 18 May 2021 18:47:43 +0000
From: "STARK, BARBARA H" <bs7652@att.com>
To: "'Martin Duke'" <martin.h.duke@gmail.com>, "'Mahesh Jethanandani'" <mjethanandani@gmail.com>
CC: "'The IESG'" <iesg@ietf.org>, "'draft-ietf-babel-yang-model@ietf.org'" <draft-ietf-babel-yang-model@ietf.org>, "'babel-chairs'" <babel-chairs@ietf.org>, "'Babel at IETF'" <babel@ietf.org>, "'Donald Eastlake'" <d3e3e3@gmail.com>
Thread-Topic: Martin Duke's No Objection on draft-ietf-babel-yang-model-10: (with COMMENT)
Thread-Index: AQHXTA/YfEAK5FlCCkWqGthi9aIBe6rpidgAgAABkuA=
Date: Tue, 18 May 2021 18:47:43 +0000
Message-ID: <DM6PR02MB692424BDA3D24B163D1E37F4C32C9@DM6PR02MB6924.namprd02.prod.outlook.com>
References: <162128583297.9778.8228421381328520899@ietfa.amsl.com> <260E6E49-BB6D-4195-BD12-673A946FF346@gmail.com> <CAM4esxQLR-ULMf-RRT5_7y0U55zy+EqCqi7FhFhDtGitRz7LxA@mail.gmail.com>
In-Reply-To: <CAM4esxQLR-ULMf-RRT5_7y0U55zy+EqCqi7FhFhDtGitRz7LxA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=att.com;
x-originating-ip: [45.18.123.63]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a3d2e3a9-caec-4c04-9c38-08d91a2d6c1c
x-ms-traffictypediagnostic: DM5PR02MB3209:
x-microsoft-antispam-prvs: <DM5PR02MB3209185E9C888FE74767113BC32C9@DM5PR02MB3209.namprd02.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6aAd0oO8G8ltLRFyaaouFFEYUGKcDY6GYUsGgD5JpUfyIjIWGpn7SEwcDilany274jhHAeWIv6/KTQqAZ3RMFrlcEscaZeH6sp2oybfHJy81EIAQbFIrblENTOMJotgzCKQujavfHymTooxrY/JpFSW1UyZ5G6xvJKwWiBIaHHQ4Hj7Mm4S1l1w8dFJ5tpJUeVz9DtsVR1livxelP+VOH2N4k49eg595zbHd6RyZPFbdic1EAUvk0C/J91fGKiqzRJNDOvZLCsfY54OplWz7MmqgEUN4uoFkJ9+YKrp/a3QqlpF98RLHFdbmhOn/+y8ILVXz/tW8V2q/cFpoMfllb05RnWxax6YlhDDz635oQtlE6qdavnT5ObOPOUMCUQ2lpPgpwCbibBzZO6nhOtAYI8OCWHlDzd8l2uKPQyDtYBV/tT59bbeGWKvYwXHze8/gNJ9PkpEMXXIQZTSGkZd4au1aq6d2Kz0ndWbsb5z5T94vxlFoNHFp/ri/8+011nlED80Rwz9Qd5TqefWOYBgsdoazfrU6tmOxawzXpDUR3kDhYjBIovUa4VltvT04IpwekvXSQGjlWBKNt5ZUuck5RKl8mCUl8LORkbLZ//sIIShJ2uvjsY95RR89PD7duw3eBOcO0mE+8M5RsAPxA1fnMWKGFKQgjWvYiCU3LWdyCKUWw2LFFYaEeJm9oTOjigBxheY8Mj46CGtGDheS5XeK0g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR02MB6924.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(39860400002)(376002)(366004)(136003)(82202003)(55016002)(71200400001)(38100700002)(6506007)(53546011)(33656002)(122000001)(7696005)(26005)(186003)(8676002)(54906003)(64756008)(2906002)(66946007)(86362001)(66556008)(76116006)(66476007)(966005)(66446008)(110136005)(8936002)(478600001)(316002)(166002)(5660300002)(9686003)(66574015)(83380400001)(4326008)(52536014)(579004)(559001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?fx6om1tuSF8rI6dyWhHxWe+SbMqoKwvvqROcCuunypVnFBedQjy8umdUInaJ?= =?us-ascii?Q?2bxw538it+0DpL180aZiBzzEFt8L3hO9ltNIPcHj0v0ZqGxmSOaGVK19ytds?= =?us-ascii?Q?zphPf1q79BmhqMsI9VfoYluSkIJHniMK6JsC5mk/Cayhi7RLIFMtbv7yY8xD?= =?us-ascii?Q?nGrvg77VGTis2dwZ2/Q1XYsOQ9biBwM11DUvHygPJ+Csus7P8EhXvh9VYBPk?= =?us-ascii?Q?PxNjx1uovivaKF3Z0gT6aAuNgmBrni3pqUtChC3A7hEVqfNKhEtSCo6RcNiI?= =?us-ascii?Q?CGqr4rwrtw3deAWjdVCRJmWV1q88IsAHGJ30+j8iLTuS2ai4qF7X7WRhpobE?= =?us-ascii?Q?iFKZZPv308ogmB+PPWFmgEQFVJUdeeLPZlBhKLYpANgjzi/C3+xGN2IA4RQd?= =?us-ascii?Q?IA8/kgERbKltwuRZRrgLakrS0D7l2hWbjRuITQoyp+CAxKwDkBSOelkHU8jj?= =?us-ascii?Q?HF2lnAvqbSBf6L0RyplKd5jQXk1bEDuvJq/zebLTjQnhbd0pbiwhxA2VbD+O?= =?us-ascii?Q?MnlhNXPSvrr+rRJIoVdvU3IF994i5QIrclh+rHnw3cP5+v1100hg9HrNDshD?= =?us-ascii?Q?hKS4yPRhBnxpLqA5KuAiMAH9NN4qg3Vt9iFrinOtk0U4ZQdWuY0iSGPrw27D?= =?us-ascii?Q?0i5cVcKWFWxYmFCj4+Ct+OrJA0ZW85BnoTCKqePuWtDU0/fnUUDTCPvRR5nO?= =?us-ascii?Q?Cyc05QR60+cQpbqwKZEFRD2D/yu9hBkgUCb6rK7pVs0b8kq9aU5iSj3/Occ4?= =?us-ascii?Q?UeY/Rsh1/2O1DexEgupRuqNlrFzLmvlXS4D4KqXngx4drAIT7IFKcxvVk5bg?= =?us-ascii?Q?Hi7KK/p9G5hh928Pf98JQceQh/VWCKJxlZqayJNzJZ8f5CcvNMASxtdlXIhL?= =?us-ascii?Q?zUA2f2Ey1V/L78F3TYZR3IYeSCH40txf7ZCl+hI/moOt66dlTXPSIdpPRntK?= =?us-ascii?Q?GSjyZW+dwfJ6/NO/BMu/uRXs5RVGxSv5MPKoe8i0MhX3eMgIhVXOGKjX3z0n?= =?us-ascii?Q?oSZ1dgUl8hguZCybNAPL1/x7OvBi/Z7kASruIFgNmz27/yt40Jvy8MPQVxhu?= =?us-ascii?Q?EVZNmmUF4r7rNq0CSvFJbpqRuh5Mr7zcPfNo+/lPIjDTnaGGMA/WnAMpBmWj?= =?us-ascii?Q?4aRJl/O0HAsCxWvLvdFHksF8FH2ChpUqsnnrWSJ/wcUjStNEtqa/IXMa2ch3?= =?us-ascii?Q?QYAYcYLkw7165v2kFoJuv3n+OXeskjCosVtHEV5oeoIzKxa8vIRmljjOUyeO?= =?us-ascii?Q?dulk4iRvKMXEQnp1BI1QZIJzpOEiutgiy7UyDdEzN27z6zUsDQahHp28i56C?= =?us-ascii?Q?Qp0=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR02MB692424BDA3D24B163D1E37F4C32C9DM6PR02MB6924namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR02MB6924.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a3d2e3a9-caec-4c04-9c38-08d91a2d6c1c
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2021 18:47:43.8683 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: giQGWrXpR1SGlrNfDz35OiQMvc+Q/uia2J8v7Dw9YpO5MgcYyjIduoLnPbKnId31
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR02MB3209
X-OriginatorOrg: att.com
X-TM-SNTS-SMTP: F16B9A97950147A08E39FC3CF2D132D74799A67E8E86DA74D36255883C8C45AD2
X-Proofpoint-ORIG-GUID: 3fjY0D6JhyqreEtxRLMrcrqPm9lpu46e
X-Proofpoint-GUID: 3fjY0D6JhyqreEtxRLMrcrqPm9lpu46e
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-18_09:2021-05-18, 2021-05-18 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 mlxlogscore=999 phishscore=0 adultscore=0 clxscore=1011 impostorscore=0 spamscore=0 suspectscore=0 lowpriorityscore=0 mlxscore=0 bulkscore=0 priorityscore=1501 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105180128
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/E36ikpE3wUWwyUwyh_DBMkSMC3c>
Subject: Re: [babel] Martin Duke's No Objection on draft-ietf-babel-yang-model-10: (with COMMENT)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2021 18:48:08 -0000

The received-metric and calculated-metric are read-only parameters. They come from the babel implementation and are never provided from the data model to the implementation. Their calculation and use (by the implementation) is governed fully by RFC 8966. For the Babel routing protocol implementers, NULL (a variable of zero-length) and zero (a value of zero) are separate and distinct values. Various computer languages allow for this distinction - even when passing around integers. Data models (and relational databases like sql and such) often struggle with this distinction because they don't allow zero-length integer fields.

If the route is originated by this router, advertised by this router, and never advertised by another router in the network, then the received-metric (per the implementation) will be NULL. If the router is going to advertise a route that it originates, it will have to generate a calculated-metric. It may calculate the calculated-metric for itself to be zero - thus ensuring, if it subsequently receives an advertisement from another router for the same route, the received-metric supplied by the other router will never be less than the calculated-metric it has.

Anyway, this is why "This metric will be NULL if the route was not received from a neighbor but was generated through other means." Note that this sentence is about the *route* being received from a neighbor (or the *route* being generated through other means). The received-metric is never "generated". It is populated by the neighbor-supplied metric for an advertised route. And when an entry in the route table is locally originated and there is no received value, then it needs to be properly noted that there is no value. An absence of received value is NULL, and not a value of zero.

What happens when both values are non-zero, is a matter of local implementation policy, as described in RFC 8966 3.5.2 and some of RFC 8966's Appendices that provide examples for how metrics and costs can be computed and used. The data model has absolutely no say over what values are passed to it. But it is an error if it has no metric at all (received or calculated) for a route that is in the route table.
Barbara

From: Martin Duke <martin.h.duke@gmail.com>
Sent: Tuesday, May 18, 2021 1:10 PM
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: The IESG <iesg@ietf.org>rg>; draft-ietf-babel-yang-model@ietf.org; babel-chairs <babel-chairs@ietf.org>rg>; Babel at IETF <babel@ietf.org>rg>; Donald Eastlake <d3e3e3@gmail.com>
Subject: Re: Martin Duke's No Objection on draft-ietf-babel-yang-model-10: (with COMMENT)

That's fine. In the original text, you refer to zero and NULL as if they're separate quantities. As these are uints, I think s/NULL/zero would solve the problem.

It would be helpful to clarify what happens when both values are nonzero.

On Tue, May 18, 2021 at 11:01 AM Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>> wrote:
Hi Martin,

You bring up a point that I have been struggling with.


On May 17, 2021, at 2:10 PM, Martin Duke via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:

Martin Duke has entered the following ballot position for
draft-ietf-babel-yang-model-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html<https://urldefense.com/v3/__https:/www.ietf.org/iesg/statement/discuss-criteria.html__;!!BhdT!1VEP6dtIBxS8iSbw9v3eXWj6dKDVxmAJwtD6CK8WYDmdULfjXSa496wEIOefq9NP$>
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-babel-yang-model/__;!!BhdT!1VEP6dtIBxS8iSbw9v3eXWj6dKDVxmAJwtD6CK8WYDmdULfjXSa496wEIOvbIEVE$>



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(2.3)

leaf received-metric {
          type uint16;
          description
            "The metric with which this route was advertised by the
             neighbor, or maximum value (infinity) to indicate the
             route was recently retracted and is temporarily
             unreachable. This metric will be 0 (zero) if the route
             was not received from a neighbor but was generated
             through other means. At least one of
             calculated-metric or received-metric MUST be non-NULL.";
          reference
            "RFC ZZZZ: Babel Information Model, Section 3.6,
             RFC 8966: The Babel Routing Protocol, Section 2.1.";
        }

        leaf calculated-metric {
          type uint16;
          description
            "A calculated metric for this route. How the metric is
             calculated is implementation-specific. Maximum value
             (infinity) indicates the route was recently retracted
             and is temporarily unreachable. At least one of
             calculated-metric or received-metric MUST be non-NULL.";
          reference
            "RFC ZZZZ: Babel Information Model, Section 3.6,
             RFC 8966: The Babel Routing Protocol, Section 2.1.";
        }

I don't understand the relationship between these two. If the metric was
calculated rather than received, why would the value be zero instead of NULL?
Isn't a zero metric dangerous in a routing algorithm?

How do you represent NULL? By definition, NULL means there is no value, that we are looking at an empty leaf. A 'received-metric' per my reading, cannot be empty. It is either received from a neighbor, or is a generated value, and therefore cannot be empty. Same is the case for 'calculated-metric'. Combine this with the fact that the info model defines the leaf of type unsigned int 16, and thus the value of 0. Would it help to add something to this effect?

"A value of 0 implies a NULL value, and SHOULD NOT be used in metric calculation".

Alternatively, one could change the type to signed int 16, something the TR-181 model does. In that case the value has two meanings. If the value is less than 0, it means the value is NULL, but if the value is greater than 0, then it carries the actual metric value??

In either case, an implementor cannot take the value of the metric as is and use it, without checking if it is 0 or -1.



(4) "config true perspective"

Dropped the phrase from the sentence.

Thanks

Mahesh Jethanandani
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>