Re: [babel] proposed info model change

"STARK, BARBARA H" <bs7652@att.com> Thu, 18 February 2021 19:11 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 4124A3A15C6 for <babel@ietfa.amsl.com>; Thu, 18 Feb 2021 11:11:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.496
X-Spam-Level:
X-Spam-Status: No, score=-2.496 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 (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 OUttibVsVp-r for <babel@ietfa.amsl.com>; Thu, 18 Feb 2021 11:11:46 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 2B2A73A15C7 for <babel@ietf.org>; Thu, 18 Feb 2021 11:11:46 -0800 (PST)
Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 11IJ5MMe043994; Thu, 18 Feb 2021 14:11:45 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 36sscepn81-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Feb 2021 14:11:44 -0500
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 11IJBgsR032508; Thu, 18 Feb 2021 14:11:42 -0500
Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 11IJBdpt032430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Feb 2021 14:11:40 -0500
Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id EA3464009E65; Thu, 18 Feb 2021 19:11:39 +0000 (GMT)
Received: from GAALPA1MSGEX1DC.ITServices.sbc.com (unknown [135.50.89.116]) by zlp30484.vci.att.com (Service) with ESMTP id C79214009E64; Thu, 18 Feb 2021 19:11:39 +0000 (GMT)
Received: from GAALPA1MSGEX1DE.ITServices.sbc.com (135.50.89.118) by GAALPA1MSGEX1DC.ITServices.sbc.com (135.50.89.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 18 Feb 2021 14:11:38 -0500
Received: from GAALPA1MSGETA02.tmg.ad.att.com (144.160.249.124) by GAALPA1MSGEX1DE.ITServices.sbc.com (135.50.89.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2 via Frontend Transport; Thu, 18 Feb 2021 14:11:38 -0500
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.108) by edgeal2.exch.att.com (144.160.249.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2176.2; Thu, 18 Feb 2021 14:10:59 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j+iruY8PbzGHp4tYu7i11Lp9TxCziNR1gohIprwvzSEDQcHydTd5RTjxdRR5LlBpfOOx7w771o25TCTLkTDWyrPqYcFvV0AERg0mtnVC6KQwJc9mV2IOFtcuN63teP7DyyKarjy5gP1PwGpzCQF0fzor6Z0NbuntobY++CnzHt2vW3qGcSdX9Ww7RZTfeOqJ/riuNWjYyWxsJHZ5+HqFdaxejxyRPlgXYe9yAv+bPWU1wUmxLlPFVm2P/9vMwi9z3COVlXo9CMAZh+1K3zR166915ffAA+8uzHSq6NQAa5viw1RRlKx6T87QRKadXyxd6ijCaj3zcqpH8P50ahGliA==
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=e80sxUotYQGCju54swikU2tDt1XWFqygNtG0xZpzgh4=; b=jMJDG0duo2pQ1+bxNTzm8l+ZFF7bZn2h4Cb3nzO8cBGx4KXrIv2FE30Drq7dfmQ1tyRL1/UI5HU/FbA4ONhC2GcM2iMxgyPOZi+OW0Dulo8RGiT6hbhqmhSiA9WYucqusqdVxDVIPfbnKZ4DcKijTuXMzFhx8Xg0PzbY++Ji3BVViGd4ir7yTS4F/ZQlSuMEECfjtw4ONJJFMxzV9BNzSVFIwaukT4Cd/lG5YoOqsIrd9LdS3RCaMI2KDfW+yfv9fWrrRLb3FhxMGWvcDJdGRyizjxh9it7Zh13jn9er2Q7aO8sS/nnYiHNzaIjp5aCEWhtd1KJ0nTPwXQNGhHg9Vg==
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=e80sxUotYQGCju54swikU2tDt1XWFqygNtG0xZpzgh4=; b=MtW8dVD57XYGrdNM1e+rgk0kw0UJrPfn3sDqb7KS2ry4Xb5MMKnp64E9XA6cw+zyUVUb51W5UXy0HnEVLeg9FKOt8Ok5srP+GOrRnmFiXPaFp2hhFtuQrxUrOhbmn81KiePnlCh58bPFkiESpUnZ5yqf64qk1OrBSTx5EIN33Hw=
Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM5PR0201MB3446.namprd02.prod.outlook.com (2603:10b6:4:78::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.41; Thu, 18 Feb 2021 19:10:58 +0000
Received: from DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d9c0:4a62:170b:b925]) by DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d9c0:4a62:170b:b925%6]) with mapi id 15.20.3846.043; Thu, 18 Feb 2021 19:10:58 +0000
From: "STARK, BARBARA H" <bs7652@att.com>
To: 'Mahesh Jethanandani' <mjethanandani@gmail.com>
CC: 'David Schinazi' <dschinazi.ietf@gmail.com>, 'Toke Høiland-Jørgensen' <toke=40toke.dk@dmarc.ietf.org>, "'babel@ietf.org'" <babel@ietf.org>
Thread-Topic: [babel] proposed info model change
Thread-Index: AdcAt7RXNVd/4GG3Sr6eZ25X+veoLAAAvs0AAABUpAAAAVQxgAAKytMAAAXOZYAAEdtlkABB3f0AAMe/uMAAKmIhAAAAHHOAAAH8cYAAATDUwA==
Date: Thu, 18 Feb 2021 19:10:58 +0000
Message-ID: <DM6PR02MB69249AC774F6ED5661E1727CC3859@DM6PR02MB6924.namprd02.prod.outlook.com>
References: <DM6PR02MB6924E3E2DD5568E247859E18C38C9@DM6PR02MB6924.namprd02.prod.outlook.com> <87blcqpau7.fsf@toke.dk> <E5F69D0C-7130-42D3-9080-C2EE5786D917@gmail.com> <878s7up8n0.fsf@toke.dk> <CAPDSy+6YWPr81uKHrWYoY=TZ0A18A_Ui3=CyLP=1K-ezwmgF-g@mail.gmail.com> <DBBE09E1-F407-4B5A-A096-669E74F25FB4@gmail.com> <DM6PR02MB69249CEAAB32A391274A8ED3C38B9@DM6PR02MB6924.namprd02.prod.outlook.com> <CAPDSy+4uor1P_HiKGEMOTihq+0gb_wuQU21shpgDmVQHNnfv3w@mail.gmail.com> <DM6PR02MB6924B3EDD46D9AD542CA06A8C3869@DM6PR02MB6924.namprd02.prod.outlook.com> <0E5484EE-1465-4E22-B021-AF430B6DA2C7@gmail.com> <DM6PR02MB69247E8F3F7499A524847D8EC3859@DM6PR02MB6924.namprd02.prod.outlook.com> <486C100B-CA66-4B47-9733-3291BA96543C@gmail.com>
In-Reply-To: <486C100B-CA66-4B47-9733-3291BA96543C@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: 40fcb5ca-fa52-49a0-db63-08d8d440ec91
x-ms-traffictypediagnostic: DM5PR0201MB3446:
x-microsoft-antispam-prvs: <DM5PR0201MB34465DFF44F3C59E24DD8BD4C3859@DM5PR0201MB3446.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: 7g/jTk1NbaB7MbGswg+mY+HqQPm6fp99Gc0b9wcZBXXl2GECTvqwi4eHFnSVyfNs5cfau1rmYMTObPfmQ/AtLOIpVJWXbrMXofJC3BpvkDkL5EhdblSJRj12hskx4pPdeMgIS4jwf6H4p7ZfoUl6FYuuOtAKeeikfDmIowXc6SCU5oVCUudHacS72FbQQ79eXEykaSqfX91bg0Efe7mCa3Gz0JnI9zdbyMRXj7nRvLtDNXyPPiLHtHUPhZ9vX/PIJzpwiGU5T7KMWGGeL5D5tT6YAzxqwuXdeovHUkiSgIdjDhdnhWaOorgguWUfyaA8Caivlhe8W9zDje3OqOfR24aU+90vx5PgOQkQtUqgYmVuLs3idCXAw1fK0e7fBDpULKYHEQCBcwcS1aKc6wozdOkYvUAkRhXJvQBiZ71aKuYdfWh/1W6ONA4Gc/nvKvjoniZ/ucm68FOWIRm2iZiN5AJbkCb4K0GLX3i+2Y0MTNabBzsjoCiADwXl5T0IJFCCqURGNa+/DqaQTsmY7RPiAMz8jHtJyGWhTijKqUy3LwDWCKG2H4iyIAbaCxu1+8DF2wWA17cmrugCKs1kXgJf21TGTJpJQNv3ZVeiYd60L7I=
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)(39860400002)(366004)(376002)(136003)(396003)(2906002)(966005)(6916009)(71200400001)(316002)(54906003)(33656002)(86362001)(186003)(9686003)(66556008)(66574015)(8676002)(26005)(478600001)(82202003)(76116006)(166002)(66476007)(8936002)(6506007)(55016002)(66446008)(53546011)(5660300002)(4326008)(64756008)(52536014)(66946007)(7696005)(559001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: SSDSYaoavhJRKJAMGwSCo8smE2BzmOBbZY98XehXFPk3Dz31qHQTtBC3dJjrylN7k8/ZqCyi2fEXHQ7/4nZCCqDFPZ+W85eh360TaiRiR00ivgcpN6KAZhNBlhRNkndm2MgOVM5i399nM3np/34c9oBn0srpwq6nNNnEbXkFbbqkAbO8nsvQykVY8jEEl8WfhfYFVkCOkaGbr6iV258ASONG00TkUPBzN0iYerr+w6SbErsYOebyRIJ8yiGOOh4PthA2CUqbNHUSnM3SesZ0b9o6in9I10USyNOXXoWeyA0d0kpnQO96Dmjec9ocBiGd9CHnrU/ctoZH+gC9dhXYqWxz7klzFfJFTTPGIYAHr54/+u8oCbMfjAjd0cpFa7q7K01OWWNmZql5AJwe9Atquz3M5zR4cyzLplej6HGTLpcrNAVyeLGnaGH5zhUNCOzIKMMy5Y+ppqnSsdX2M4V8kxZpj3TFJP3oMvxa4QQtrzmxrtSDS5oqCQJ6fhthc0+OQey9NTJZlrmjBa8lytaxhZp5wtRlunZZh110ReCwmq488jT92ZnqWS0pDVzUtcFHJgrCU93jP6+JWOJOlNIuTnlubBQpuhHJpzVD1vsv9lnx5CQ8MS/urGNRYX2D4Y0MRITCRlbZVqbRgbl3MKdEMXj14r8rongk8OqNAvUmoGx7lOdiHxyJ0rA/nWEPHoswyR+nNoR5Jyb1x7/klqXYqHLFi/9+jy7VPU5WjqMXv8LDTevcSXM5OsEM27bvxXMOXF+0nr2TBnX0CxygVxj3hAmqyVZoiFqxLehriSp2S0QP/j/7a7uu+YnpP8QU5XpUyP0AJUChiqTIbiWeYfXMmeNDIgKnS6FzX2y2ydLN+3C63/tWfdBFN43huBMBCJ0LXkcNC51u9ESxzHagiWyq4UEhk2gfkPVrDaPKPOA3h0nePMZ6nj/I/U/YMs94yE/UoXLoiVmDXCOKBJotINdF4YR8Gvfij8cQWA1Cl2YKzmJ8PQsKH3QH44/dSeXzwHMGohvl8zm51EYL1O1k8e2DZDG3gYb6ZRdfuiPNac5PfFOM0bSNdu6uc0Ee0aec44GKPZL8x5hIMQ6dQxrrYxh8u8KgBLh5SALW4ZZPkxF3df8Jhu6WO6cAKflyDVaisgzdPuydZ+6mH0ubqAOMQ+lNIcdHVSuHefQPUy5KEreFP2UMYG7F7l9klS1PfYpphaxdpyijjKkoTbFqB/iKKs1tp93IhwXHu1kixGSUIGxpi0GQfwkw9UGjwD8GfwdlzqVqCD0znc0GlZmN1weeTj5T7kEgRbg9yA2tLVcAW98WldE3I/lkxb2EBlCyV0NUkRJo
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR02MB69249AC774F6ED5661E1727CC3859DM6PR02MB6924namp_"
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: 40fcb5ca-fa52-49a0-db63-08d8d440ec91
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2021 19:10:58.4573 (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: PRptBc9CbmXXnmbVZYXMVvusRQBVKLUxkLE3ft7pMDztwX+IUGlShZ3UHF5goG48
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0201MB3446
X-OriginatorOrg: att.com
X-TM-SNTS-SMTP: 3B32FA4CAB3119FA3175180DD4DC7F43B59EE5EB9D1FF2ABA408E0AA8CAE8D492
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-02-18_09:2021-02-18, 2021-02-18 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 suspectscore=0 mlxlogscore=999 mlxscore=0 lowpriorityscore=0 malwarescore=0 phishscore=0 priorityscore=1501 clxscore=1015 impostorscore=0 adultscore=0 bulkscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102180157
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/GXKeFG_tDD0OjfRSpnhu5-EoTkc>
Subject: Re: [babel] proposed info model change
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: Thu, 18 Feb 2021 19:11:49 -0000

The info model only defines what a single instance looks like. In TR-181 I have the choice of supporting multiple instances (of this single instance) or not at the hierarchical level above where I put the Babel objects. I’ve chosen not to, consistent with how other routing protocols are modeled in TR-181 and because it doesn’t seem particularly valuable to support multiple instances on a single device.

So I’m quite OK with the YANG model supporting just a single instance and not needing to index on the router-id.


But this brings me to my next question. Since the router-id is read-only and its value is completely controlled by normative behavior defined in RFC 8966, do we need to say anything in the info model? Can we simplify the router-id to description to just be “The router-id used by this instance of the
      Babel protocol to identify itself.  [RFC8966<https://tools.ietf.org/html/draft-ietf-babel-information-model-12#ref-I-D.ietf-babel-rfc6126bis>] describes this as an arbitrary string of 8 octets.”  ?

Barbra

Hi Barbara,

Good question.

First a correction. Looking at the info-model, it is clear that there is support for one instance, i.e. one “router-id" on a given router at any particular time, and that there will NOT be multiple instances running on a router at the same time. I am specifically looking at the following line in the info-model.


binary                    ro babel-self-router-id;

I was therefore wrong in implying that the “router-id” acts as a key, as there is only one instance of the protocol on a given router.

If that is the case, the only thing we need from a modeling perspective is to make sure the “router-id” is valid, which is what the must statement allows us to do.

HTH. Thanks.


On Feb 18, 2021, at 9:30 AM, STARK, BARBARA H <bs7652@att.com<mailto:bs7652@att.com>> wrote:

Hi Mahesh,
Would this still allow the YANG model to use the router-id as a unique key?
Barbara

Hi Barbara,

Thanks for circling back on the question of router-id and its impact on the YANG model.

Based on the discourse on this thread, it is clear that the “router-id” has meaning when the protocol is enabled. The YANG model can therefore add a conditional statement, i.e. a must statement, that allows the read of the “router-id” only if the protocol is enabled via the “enable” flag.

Is the WG acceptable of the change?



On Feb 17, 2021, at 1:17 PM, STARK, BARBARA H <bs7652@att.com<mailto:bs7652@att.com>> wrote:

I’d like to circle back around to Mahesh, then, to see if this change is really a good idea from his perspective. If we do this change, then it means an implementation could start with an all-zero router-id before its enabled and then generate a “real” router-id when enabled. Which was what the original all-zero prohibition was trying to prevent. If this is acceptable for YANG (to have a changing router-id), then I see no need for any prohibition in the info model (because the protocol spec will ensure uniqueness when the “real” router-id is generated).  If not acceptable, then it seems to me we need to keep the current info model all-zero prohibition.
Barbara

Ah I see, thanks for the explanation! I'm fine with the change then.

David

On Fri, Feb 12, 2021 at 6:43 AM STARK, BARBARA H <bs7652@att.com<mailto:bs7652@att.com>> wrote:
Just to be clear ...
An enabled Babel instance (that is sending and receiving Babel packets) already has a requirement for unique non-zero router-id. Where we were having a problem was with not-enabled Babel instances that weren’t actively running the protocol (had maybe just been installed). I think it was babeld that was just using a default of all zeroes until it was enabled; at which time it generated its unique router-id. With this not-enabled “zero” default, the possibility exists for multiple not-enabled Babel instances to be defaulted to zero, which would lead to YANG having a problem with having a unique router-id to identify them by.

The fact that the Babel protocol forbids zero valued router-ids doesn’t mean not-enabled instances can’t have that as a default; and it doesn’t prevent there from being multiple not-enabled instances with a default value.

TR-181 doesn’t have a problem with this, because it uses a unique key distinct from the router-id. The Babel protocol spec already has what it needs to make sure the router-id for enabled instances are unique (and the data/info model doesn’t need to be involved in policing this). So this really is just about making sure the language is suitable to ensure YANG can use this parameter as a unique key, without putting constraints on the protocol. If YANG were fine with a Babel instance that started with router-id zero and then changed to something else once the protocol started running, then zero wouldn’t be a problem if there is just a single instance with that zero value.
Barbara

From: Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>
Sent: Thursday, February 11, 2021 11:56 PM
To: David Schinazi <dschinazi.ietf@gmail.com<mailto:dschinazi.ietf@gmail.com>>
Cc: Toke Høiland-Jørgensen <toke=40toke.dk@dmarc.ietf.org<mailto:40toke.dk@dmarc.ietf.org>>; STARK, BARBARA H <bs7652@att.com<mailto:bs7652@att.com>>; babel@ietf.org<mailto:babel@ietf.org>
Subject: Re: [babel] proposed info model change

Hi David,

On Feb 11, 2021, at 7:09 PM, David Schinazi <dschinazi.ietf@gmail.com<mailto:dschinazi.ietf@gmail.com>> wrote:

We banned all-zeroes and all-ones between draft-ietf-babel-rfc6126bis-00 and draft-ietf-babel-rfc6126bis-01. If memory serves, the idea was to reserve them for future extensibility. Also, banning all-zeroes allows using that as a sentinel value in software.

Adding the uniqueness requirement sounds good to me, but removing the ban on all-zeroes/all-ones could lead to problems. If the core protocol doesn't allow it, why should the informational model allow it?

If the protocol banned it, that is a different question, and info model can reflect that. I just wanted to point out that it is not because of the data model.

Cheers.


David

On Thu, Feb 11, 2021 at 2:00 PM Toke Høiland-Jørgensen <toke=40toke.dk@dmarc.ietf.org<mailto:40toke.dk@dmarc.ietf.org>> wrote:
Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>> writes:

> Hi Toke,
>
> The rational has to do with what a data model like YANG does with
> router-id. To it the router-id is a key, in the form of a string. That
> string has to be unique. YANG does not prevent it being a string of
> zeros or ones, provided that string is unique. Thus the dropping of
> the "MUST NOT” and the addition of “MUST”.

Right. I seem to recall there being some other reason why it shouldn't
be 0, but can't find the discussion now, and looking at the code that
doesn't seem to care. So no objection from me I guess :)

-Toke

_______________________________________________
babel mailing list
babel@ietf.org<mailto:babel@ietf.org>
https://www.ietf.org/mailman/listinfo/babel<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/babel__;!!BhdT!3HjRHugiRwRBmxjH7eRjssZBgzbBm5snhzyvT2apBtscBdcCqo2THFENFjzZoA$>

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

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

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