Re: [babel] proposed info model change

"STARK, BARBARA H" <bs7652@att.com> Wed, 17 February 2021 21:19 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 D7BB43A1D5B for <babel@ietfa.amsl.com>; Wed, 17 Feb 2021 13:19:08 -0800 (PST)
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_H4=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 TsWUtlwQuTc5 for <babel@ietfa.amsl.com>; Wed, 17 Feb 2021 13:19:06 -0800 (PST)
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 81A073A1D61 for <babel@ietf.org>; Wed, 17 Feb 2021 13:19:06 -0800 (PST)
Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 11HL5JMi035150; Wed, 17 Feb 2021 16:19:02 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 36rx2spbj2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Feb 2021 16:19:01 -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 11HLJ0vx021138; Wed, 17 Feb 2021 16:19:01 -0500
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 11HLIvIO021104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Feb 2021 16:18:58 -0500
Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 9B48D40145A4; Wed, 17 Feb 2021 21:18:57 +0000 (GMT)
Received: from GAALPA1MSGEX1DB.ITServices.sbc.com (unknown [135.50.89.115]) by zlp30483.vci.att.com (Service) with ESMTP id 7468740145A3; Wed, 17 Feb 2021 21:18:57 +0000 (GMT)
Received: from GAALPA1MSGED2BA.ITServices.sbc.com (135.50.89.126) by GAALPA1MSGEX1DB.ITServices.sbc.com (135.50.89.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 17 Feb 2021 16:18:56 -0500
Received: from GAALPA1MSGETA02.tmg.ad.att.com (144.160.249.124) by GAALPA1MSGED2BA.ITServices.sbc.com (135.50.89.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2 via Frontend Transport; Wed, 17 Feb 2021 16:18:56 -0500
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.102) 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; Wed, 17 Feb 2021 16:17:36 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h6F5dzhgXDsdtzHNT7QCujHlkHn+RlYf2XIwTP92qN1OaOMw50EPxdaSpaCb7AWyVdqyu7Oc41uGhNJYcV3/LMAOmc4i4hKVFcwhJeDZBu2wmdzhGBIFU48e4Q0jDDt2Q+B/gf8c8jwnilgHfKAG32EBymqZ3iUvX2oq7LYiMdIL5W9bjtFTt3RkH+6Kpprj65JVLJt0dPRNfNZqEufEQwD92Yc/O+voMzBFfFy6Wuwr7pnoV9n33Aj5mDhbcM1qb3D14J3kjhUeKxZ74BTiqZGm5iLnqSnEyzisu0zb6+y44Vlmd+K1Pq+WDBRiCUndRCDm+bUQqCGLJkiDKr/iEA==
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=y4vIAkE0OLcn3NyLI/TmqlGAeF79Hq+nsFnjBOoyXMk=; b=WpSSuaXvl0owT/YylmbdD6osJoNs7AfdOqw8DXVRVwu6+El6Z1Q0J64ZCwfxF48QKh64U4Tq3AINRy81qwO1jAcpA9C0ugmaErbIfutXyI5b2fSuGlxSt7E9pfcJa35eXm8yx6Suv9GUNv3ld5GLNNdlaKbKofuimF/RjWZi8K/xaXNT8/xRkprAeOuvVOtjvsSjhbgaZ6Uzh4FhLxGEUrPGz0cNRZzVaP6tc15mCBKC9rESYZTcjY3A49MWaBEda8UZeXtctLgHi3h7gOXy4H4sbI+RighX+lEegg2WVvpkBWYtP5OMxbcZqYBq2f790FnKOwrhmK0s2wTmJNok3Q==
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=y4vIAkE0OLcn3NyLI/TmqlGAeF79Hq+nsFnjBOoyXMk=; b=MVw/yGpITR5zvclicmRluSCJJXqgaauRPFq8T+g85UHhUk6qVPKHgHRdx64rkcaw7TGtWOxYlx/+/a5WCrW746EuIu3YIkMAG17lZxYjQL+Y9ouAxxSwyETanxX+9rAUq7+SjFDjxK/6eOIgZDair7T9sJQUlitE91914Ohf3V4=
Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM5PR02MB2684.namprd02.prod.outlook.com (2603:10b6:3:106::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.25; Wed, 17 Feb 2021 21:17:35 +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; Wed, 17 Feb 2021 21:17:35 +0000
From: "STARK, BARBARA H" <bs7652@att.com>
To: 'David Schinazi' <dschinazi.ietf@gmail.com>
CC: 'Mahesh Jethanandani' <mjethanandani@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/uMA=
Date: Wed, 17 Feb 2021 21:17:34 +0000
Message-ID: <DM6PR02MB6924B3EDD46D9AD542CA06A8C3869@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>
In-Reply-To: <CAPDSy+4uor1P_HiKGEMOTihq+0gb_wuQU21shpgDmVQHNnfv3w@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: cb4778b0-b54a-4ad4-9c0b-08d8d389720c
x-ms-traffictypediagnostic: DM5PR02MB2684:
x-microsoft-antispam-prvs: <DM5PR02MB268423D14748E28573E748B7C3869@DM5PR02MB2684.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: CwbZJWZWylMrdELZxmL8jnNLbjt1xyV4TOsbcJpt2VXje71hQt7JI8QRa2JsCOeeoyxKD8xWTTDIwoOZdwsT1o2ofa1QtaSO9eyRhMygW96nmqeY9Wm9sjUOrubeUWLaV4tSqBJC5cbRjaSBbilNi3NjtNwAd/QQJNe5VKemgGrt+V9vQkP3Xw8qNHpEmuPtLuF8+H1ZggI+1taP+R73nmLzxQCwB2GjBDT0xIu2h0UYdEHgEIuWnIhHRK6UyIq6FAu1qZBVlEl0s++BSal43trFwpkh3vmR4dL2/ViBlr7CuxOe6vti0t5taAnhv0DnOJs+1MNy9RhIOqEklsxy4wwzTMMDnuhp4casy+YM5g++oCcw2Nt7ba8dVLGO4GliikMbFQCt5SR4Cp+FvpRbzHBCPPLThdl8IFTCodfFi8U64wNhZn+3hLCcgjapF0w0a/Y136WESfe+SJYi57+RhY19hbaObyY2ZaxZNMX2p3SGeSaGbpw7Mr8zqApqSIJG3KOfIH5GI9VuMjId60D25M1q9g41hC9xl7GMs7RJn6k2iBO1YM6qwt2ozUlGkw9rHD0UgpqT9Fo0A2YzBH5AlhJdGCDPbHVyuRUg6XUGLM4=
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)(396003)(346002)(136003)(366004)(376002)(39860400002)(71200400001)(186003)(53546011)(5660300002)(316002)(6506007)(54906003)(66476007)(66446008)(82202003)(9686003)(66556008)(6916009)(66574015)(52536014)(66946007)(76116006)(86362001)(478600001)(64756008)(8936002)(7696005)(2906002)(966005)(4326008)(8676002)(33656002)(166002)(55016002)(26005)(559001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: LqXpmCCLnIOKCX06I0JSLXfK5MWSDki7GZSmcCAL7dvnz3t7T8OlSp1LlqBGi5LXVYahZ7j4AsDw7iMKSG0Q/JDBBvP83oILSicjS+h0BvBOTdJjvPLvBBSbbo0AlPp8sacfCorIxFi/95ND1US+iqouzUDWZJUt9w+6fABZsCTkBCHKiTAnSoWboEWK6bUnfjdTDEsfO0w8FZ0Gs2KWdZw6xGqERRPOa1fxY1A5YDKcEsNJQ4+ZeuLAonr2WbQypGrkWoZV6LIPjRbT9EISiP+7Uxo8bT2SVJKwcZrpwLi0xERi1hKZBF99eXf2z0l24As05IlCXvJ5TeY+8dxeaNDXAr71G4xkTVZMFmEHoJTXMqGCQawnjVHJRgO9+ELbaR1054NDwzD8rKegP8pbYPdtn/fvQqnPYbFxPCQOHQq304lXjizrQ5EXUCNINsShbtEDscO978yBOjupB/5mqD+yFOZ5JtaTSlBc/vvTfwOGYD/emLObPc/3zZGled9V8fjzJ6nybJoEwtvkR0GoqvUtoPSEoTG9W5JnWkp/SVhbHiU8oIU9idvUaZfspruEn+aGB8favlnwLrkJCCx3sKVBvAI72Sg/jwGy6y/TOeVm8+JqxMivCgO/nsv/XtnSZGqEGQWFssAXa5DXmQLrfkEIOBT6ay0S0i82ck0s0YkMobfeVh7h9sFHN2deGs99mLVj7IcO8XTg8b7yUZWkxIJCRDuUSweT/8Wh9AookCX+F1QwfkZiygZxipgoeQNMePwTnR2TEj2KXgi4bkXOFYMkUL5nSbP9a9u8oZDVa+1fi21//73qVQzjqt0ltm2JqECQCH7mixBTr7C1C6sW/yV2Ecppl/jZUkNiBMBiyl1SVnDMPF/qSe6AC1+FdxnUyH6IAPl8UsAsVianBljaDirPPodn+Gn1mYj7GnlUE0l5ovE8eeg9Fx+juIGaT+hy4p49F06ZN+EyewXEfDhvgTksOd5nQDYcmu0JIRfcoyNkUZqH3nMl8a3yyuK4Nvmf4C+C3DiszbYyX2lhRqFNGwogYWNvvDP78uz+vChFxwEYypfPgFQq+kDVNgw2+3VsCTwKOV8ddSn9DdkbVYSaQXxZBu1v5UtCaZVolxa1sw/Wz3hJQ7cRbVatNeEXWWTb1DSZCs/+9xZRY0pG7+v3RIisuvi5AYmLW3K6DnaHXWBLgKEkoqLvCvdOhF4Jiidb559nk5q+kK5mxvllOii35cR9Jz4XV/IwWoTW5x49xroeJGl8GPsovcNMGOEqLtqZcTfhTuZ/qpNUhwe+DGXYvUwfkGG7RrYwPv1DNpJon83TRVDjrlb9eLte6RxPw9z9
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR02MB6924B3EDD46D9AD542CA06A8C3869DM6PR02MB6924namp_"
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: cb4778b0-b54a-4ad4-9c0b-08d8d389720c
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2021 21:17:34.8990 (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: 4Lrh1T2/wI4lFLSCNWMZkkKNehEp2a+EzWi84k856Tci2tZe3ZxgX1te30XR5Qnv
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR02MB2684
X-OriginatorOrg: att.com
X-TM-SNTS-SMTP: 6FA7CAEE1162B00CDA570A7A37FB4DE57852527418B52D15FFC5A9FE3CF42A5B2
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-02-17_19:2021-02-16, 2021-02-17 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 mlxlogscore=999 spamscore=0 priorityscore=1501 adultscore=0 clxscore=1015 mlxscore=0 phishscore=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 malwarescore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102170159
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/WWc7moa1mJ97z8qpoWH78lqKkFo>
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: Wed, 17 Feb 2021 21:19:09 -0000

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>