Re: [babel] info model: configurability of intervals

"STARK, BARBARA H" <bs7652@att.com> Fri, 26 February 2021 18:23 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 50D663A144E for <babel@ietfa.amsl.com>; Fri, 26 Feb 2021 10:23:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ojKFtlNWkHcS for <babel@ietfa.amsl.com>; Fri, 26 Feb 2021 10:23:37 -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 B7D223A144D for <babel@ietf.org>; Fri, 26 Feb 2021 10:23:37 -0800 (PST)
Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 11QIDp6k023694; Fri, 26 Feb 2021 13:23:36 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049287.ppops.net-00191d01. with ESMTP id 36y1uknuy0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Feb 2021 13:23:36 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 11QINZOP021849; Fri, 26 Feb 2021 13:23:35 -0500
Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [135.66.87.38]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 11QINTeK021720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Feb 2021 13:23:29 -0500
Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [127.0.0.1]) by zlp27130.vci.att.com (Service) with ESMTP id 617C04009E91; Fri, 26 Feb 2021 18:23:29 +0000 (GMT)
Received: from MISOUT7MSGEX2CA.ITServices.sbc.com (unknown [135.66.184.193]) by zlp27130.vci.att.com (Service) with ESMTP id 4507E4009E84; Fri, 26 Feb 2021 18:23:29 +0000 (GMT)
Received: from MISOUT7MSGED1CB.ITServices.sbc.com (135.66.184.203) by MISOUT7MSGEX2CA.ITServices.sbc.com (135.66.184.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 26 Feb 2021 13:23:28 -0500
Received: from MISOUT7MSGETA01.tmg.ad.att.com (144.160.12.221) by MISOUT7MSGED1CB.ITServices.sbc.com (135.66.184.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2 via Frontend Transport; Fri, 26 Feb 2021 13:23:28 -0500
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (104.47.37.59) by edgeso1.exch.att.com (144.160.12.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2176.2; Fri, 26 Feb 2021 13:23:17 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ejv4z928rMhODOKoYk1K+YmIkpQjJKvXsFdnzYVT+pLPrH5SrMMK+IT7cIz+dUBMG1KrH1I3BLS3WJy53V6FREtXmxkuYyYxd/TAU0HCSv7LLYk4kgQV7b3eJhoK53s0gqXTdPWEZ+FQbSAbg5rc0TVehwuT9ZWoIOQUitEcixUm9VczYuyTBQtJcX/hFregvXxVVWa2x6wBEf3dHzn8BiZP1PbhRVB0Gs8fFRSBhwCmJbuSZtvA40/qEe8XrtHsCMT+heEorN9gxbzJZ/1TpkiAKhEkYCLSf5eWWwFYo5b+UosGHIbGXrbDTeO3T6JRSF7jdRSF8CnLsp0OVoMrtQ==
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=jj7HC8VVAArM4J9PB6jwFxbIBUKui0SK0tjkI0suXl8=; b=PfvutUoxcssabqgIvSEQTTR5b2V5xpJ+AwYlqyz6hIJgWPZz3oXqxcsXEX/BLIudxHyq9lEC1O7R1UZO/nnBoXg3lbjl9+Y/uVlX7SHz5w0g/S3MWcb0zqpu9Q3itdCQ4Z2SJM8AJWYzdA9YdXF80Gu9Et6EjmQFEtvRbSNPHTYG1vxqtLFVDt3Br7pGsWWLNd1QywZWvbt8e1Qzx91wGSoLzNdcJNhN4C+O9bIMuaC4ehAZ66JyilJh6ubk3huFhAroTT7RRy8rZw/3mGvYQenwFbSkMFBNxqCKhIta6qrh/++WrzpPae+2xDbwOVlzHYUxbE+LxAIdwzdq01ZjlQ==
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=jj7HC8VVAArM4J9PB6jwFxbIBUKui0SK0tjkI0suXl8=; b=CwcMJTHlQt3CVJBY08mBvHgWbV39HPn9oZpwVNn1/1b6uk3qh/J+cPiYeGK9bJzHDFdF7dK4OXOURTS5XbOV9QbSPYct9msP1OkGoY7awxdWZqLwVrh46nNG04AS5pj2SbHPPeXpEGGkMtPzgwIlcqITYXLq+5SPJKvMZwOag7k=
Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM6PR02MB6379.namprd02.prod.outlook.com (2603:10b6:5:1d4::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.32; Fri, 26 Feb 2021 18:23:16 +0000
Received: from DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d9c0:4a62:170b:b925]) by DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d9c0:4a62:170b:b925%8]) with mapi id 15.20.3868.034; Fri, 26 Feb 2021 18:23:16 +0000
From: "STARK, BARBARA H" <bs7652@att.com>
To: 'Toke Høiland-Jørgensen' <toke@toke.dk>, "'babel@ietf.org'" <babel@ietf.org>
Thread-Topic: [babel] info model: configurability of intervals
Thread-Index: AdcKyywIznJnYehDTTyLrcx9qlC5KwAA17UAAGaQoZA=
Date: Fri, 26 Feb 2021 18:23:16 +0000
Message-ID: <DM6PR02MB69249A7022428C82F1532467C39D9@DM6PR02MB6924.namprd02.prod.outlook.com>
References: <DM6PR02MB6924C2CF2ACCCFD1FDBE0C23C39F9@DM6PR02MB6924.namprd02.prod.outlook.com> <87im6h2yfr.fsf@toke.dk>
In-Reply-To: <87im6h2yfr.fsf@toke.dk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: toke.dk; dkim=none (message not signed) header.d=none;toke.dk; 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: b6d66d43-7e70-40c7-cb26-08d8da839624
x-ms-traffictypediagnostic: DM6PR02MB6379:
x-microsoft-antispam-prvs: <DM6PR02MB6379FAE43373FD9DA89964DEC39D9@DM6PR02MB6379.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: 617yknu15XNMeloeHX06hJNyzBmLT41DVsm8pBook/hGmnCPliBHR1Tm8NhhoTuVYIP+PDYAhC16pTnNxk616B4iPi9UhTR4lGaWwfzkW4Ev9qOSlPCcG9Y1d+mmbb0jiP2SsCOHNIgR0tQVYqxmdc1uMyjTYOPHpm2L+VwrhGOiJvNcFmP/W3l07SOqJ4kegzORT9yGNMRkPzIQm1HKlIP+nXwok/pUGShDJBj/Si5YHlkJwuMsnmSMJTRQjJt+u6k/S0hT9EzNL0b0gxROOQbiU0QEJG0GMVk7v3NR8//u02gP3CddrLncdcRKklWV0KPlyerP0A/OifyDpQjhLQuv4eUzxOmsnczk36qDfxg1N+JolqOfdXqISpnyKJUZ1Qk1okD/aRetonHUJkLzU6VsFc+vtN02qRsnYxB9knPqG+2hemnpv8MSry8bC1mbsZL27NZ3fY51oo1j1BuW+X8+awsDV+ZUNVSxinCdaRbcF1QYx1l5tmL/xOZNFbP3KM2J6vuioIas61PYaY3pmoThOgOYg6qNyh5yGoUOYHo/VxauBmbvbD9a1Yaiej2R
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)(376002)(366004)(39860400002)(136003)(396003)(66476007)(478600001)(66556008)(76116006)(82202003)(33656002)(66446008)(9686003)(5660300002)(26005)(316002)(186003)(6506007)(8936002)(2906002)(71200400001)(52536014)(8676002)(110136005)(86362001)(83380400001)(66946007)(64756008)(55016002)(7696005)(491001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: boXq+JIwYL/hHLx2N4LHgFEyUfDh3iAaCJEOjCmgw6m+lBfTP836uginm1UZ2noZzOOBMHLjE/kh40oYo0NWtjUU7DVCck9VkVyKgsOHjsRkwLwf2rf2VPz553T8NCHlzBuRcwBL46Gtoxvy/vcCOiG5y8eKibdsrL9mCbuCHS4BhRLtqnll8n5LwWeee+wRjukuQHv8Gll13QA6Eu+KFV7V0t8DW9sDsDDexIVPFqVGJiCnWPhIYhrPBWXZtpPJnli1F0lIJ5P2WJTfinKgQuRdLiVLTVrTFKsquQ3tZWSPZY9KMVV1Q9IjH6LRZGWdZDbPxOfGsS2tBDaNsNx4U4p7ZI9tGw+cPtDPwCGHK7qgyGIyKyTf5jLg3PjcUpaPobdcEDbMGoS+aXw6VNPg2YJz66VFhHeuv+RqEZETxVF7PnLtZrM5xd7JcfurEdHJ4kmlwFAkwvqhIsH5n0t5Ek+0Y/Qkp/nXiRiZG8Knu8m+1jNdbSp7lb25gtQyBjE1O+ZsxEnWcONKXFnb3gwYHYatbRdxpjudO5/r/wEMg9GANw6T1lO7xM+J8ahodaNMDStqqIO55J/wwDZfwdtA/eW1hRh+JTyGrtojmJ1UgKBmxZ7GxsZ8CjnloD7U3R0hwErMvHSNRZj7Sp4gLCaCQXKeepLNUnug1870nBoWmWogwPVNzX1+nwOY5TWQSDKAPJy+1PwLnzk8UYkK09ZRvbMtlLAfJlYCwygg8Oz/vtTVSsRMhPrY3yiiN9d1PFicwY/FOrQPlYj/lKM9sWL7dWlQhUC/51utwGEJD1skin1y3jZoE9StgbBvxoupbpMb2RwaQCL1hEdCQWSJygvQ7QP4kTmYub8ve9pZ99vwXZjVCGkWun3XCJMjwX6YDpB9XQLzIgpIPjD3dNT4hpHhoNFPPp0taQoPHhsOf+mU5Pe5foeTiMWGHcy9/k0Ghe6uGnZN2VLE+hdEijzCOC2VTKtF1QvxLC1AaIndkHB7XYFqcVOBjSjX09Sp1H16X9c2ATLqDd61YlzPbIObpztOK7JuiFdMHIlEucEYVIHBDhZxvzYrB3Jv2xqJkfInNaleuHWWvPvteJIsQpIBWf0JyxhKXjhlLO2LxLAnAd9NFPnX6GjuC08VAte1+QfJusBKK3V5IJilow4x2w8q1fJkUC28sX/G8qXZM4ywrLUR466JU0rhBAW0QH3ZlG943+MfNnbOLMkPp97l/sLTW6Kzj7PKuK5yO4Hvr6tTBjl/6A6RsEBwUhjHBboEY2jnTVk0ukGyvhck1ikBDIUcO4d8omArbs++1sPaI6wdfb6ZaCc=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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: b6d66d43-7e70-40c7-cb26-08d8da839624
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2021 18:23:16.6902 (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: Qop5tJaSHIPT9qEfBpZqi4hCFWchSEzbFJi5y5sNYNdTtaC2h1b/yE8FCGIBbbEL
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB6379
X-OriginatorOrg: att.com
X-TM-SNTS-SMTP: A0E2C14D29A0AF7592BE778C19C76784CFE4B1C20E5E18AE57CE124C40AF43982
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-02-26_07:2021-02-26, 2021-02-26 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 phishscore=0 spamscore=0 adultscore=0 clxscore=1015 impostorscore=0 suspectscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 priorityscore=1501 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102260135
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/rjGcw6MYP5vfJ1FUaM467ZtVPFo>
Subject: Re: [babel] info model: configurability of intervals
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: Fri, 26 Feb 2021 18:23:39 -0000

Thanks Toke. I wanted to wait to see if anyone else expressed thoughts, before I replied. My reply is at the bottom.

> > Hi Babel,
> >
> > There's a question about the need to support configurability of
> > interval parameters. Right now, they're all read-only. RFC 8966
> > indicates they can change, and back in August 2018, we discussed
> > intervals:
> >
> >
> < URL mauled by email system>
> >
> > That particular email says:
> > ===============
> > [Toke]>>> Both Hello and Update intervals are configurable in Bird,
> >
> > [Barbara]>> Cool. Do you make them configurable per interface, or globally?
> >
> > [Toke]> Per interface.
> >
> > [Juliusz]Same thing in babeld.  (There's also a global value, but it's only used to
> > configure interfaces that don't have specific values configured.)
> >
> > (As to IHUs, babeld dynamically computes an interval from the Hello
> > interval and the estimated loss rate.)
> > ==================
> > Juliusz indicates in this that IHU intervals are dynamically computed.
> > I can't find it in any of the emails, but I think somehow there was a
> > determination that configuration of all intervals was done by the
> > implementation based on costs/metrics, and that no *external*
> > configuration of intervals was supported (or desirable). Is that
> > accurate, or should intervals be configurable via the info/data
> > models?
> 
> I think there can be some value in making them configurable. I.e., if
> you know you network is really stable and never drops packets, you can
> set a really high interval and rely on triggered updates for the
> in-between stuff, thus saving some overhead. Conversely, if you know
> devices have a tendency to drop off the network with no warning you can
> set a really low interval to quickly flush out disappearing devices by
> timeout, at the cost of more signalling overhead. Doing such things
> require operational knowledge, so setting them by the management
> interface seems reasonable.
> 
> On the other hand, we also want implementations to be able to make
> decisions about things on their own: e.g., babeld will try to detect if
> an interface is wireless, and if so automatically apply different
> parameters to it, which includes changing the intervals (IIRC). That
> should also be allowed, so the information model should leave room for
> implementations to pick their own settings as well...
> 
> -Toke

Designing an unambiguously behaving model in a world where some implementations would want to allow for interval configuration and others wouldn't, and where implementations reserve the right to change the interval based on calculations using metrics (though some may allow disabling of this changing -- which might not be great if the admin doesn't know what they're doing) could be done; I'm just not sure I want to do it at this point in the info model (all DISCUSSES are cleared and there are enough IESG positions to proceed). IIRC, Juliusz had suggested human admins were likely to have little understanding of what was needed and the implementation was in a better position to adjust values appropriately based on metrics.

If I were to do this, I'd separate out the current value of an interval from the configured value (which YANG does, anyway; but which we've only lightly touched on in the info model). That would allow flexibility as to whether an implementation could change intervals even if it had a configured value. That is, the configured value would just be a starting point and would not be immutable during execution. If we were to allow the code the change away from a configured value, we would probably also need a parameter to allow/disallow the code from changing away from a configured value.

So if configuration were supported, it would mean the current parameter (read-only of the current value) would stay and other parameters would be added.

But based WG list traffic, there doesn't seem to be a strong WG belief that we need to support human configuration of intervals at this time. 

Would it be ok if we left these read-only current-value interval parameters as is and didn't add any other parameters to support configuration, at this time? We don't have to be completely perfect.
Barbara