IETF Logo Mail Archive

Re: [babel] information model open issues

"STARK, BARBARA H" <bs7652@att.com> Thu, 02 August 2018 12:57 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 4CC14130E55 for <babel@ietfa.amsl.com>; Thu, 2 Aug 2018 05:57:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 0WHr7NhUxzNa for <babel@ietfa.amsl.com>; Thu, 2 Aug 2018 05:57:47 -0700 (PDT)
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 D9CF4130E39 for <babel@ietf.org>; Thu, 2 Aug 2018 05:57:47 -0700 (PDT)
Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w72CtTpx018778; Thu, 2 Aug 2018 08:57:47 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2kks7dgca0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 02 Aug 2018 08:57:47 -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 w72CvjIf025422; Thu, 2 Aug 2018 08:57:45 -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 w72Cvgqf025382; Thu, 2 Aug 2018 08:57:42 -0400
Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 6D8B340002B1; Thu, 2 Aug 2018 12:57:42 +0000 (GMT)
Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30483.vci.att.com (Service) with ESMTPS id 5B16B40002A5; Thu, 2 Aug 2018 12:57:42 +0000 (GMT)
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0408.000; Thu, 2 Aug 2018 08:57:41 -0400
From: "STARK, BARBARA H" <bs7652@att.com>
To: 'Juliusz Chroboczek' <jch@irif.fr>
CC: Babel at IETF <babel@ietf.org>
Thread-Topic: [babel] information model open issues
Thread-Index: AdQpvguYwHH3NQYTQdev//suP86yMQATSk8AABSHJmA=
Date: Thu, 02 Aug 2018 12:57:41 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DE6390D@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <2D09D61DDFA73D4C884805CC7865E6114DE63655@GAALPA1MSGUSRBF.ITServices.sbc.com> <87600tsnzb.wl-jch@irif.fr>
In-Reply-To: <87600tsnzb.wl-jch@irif.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.10.244.33]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-02_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1808020135
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/3qKdfs3IifDvS8cBmPntshBt-UI>
Subject: Re: [babel] information model open issues
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.27
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, 02 Aug 2018 12:57:50 -0000

> > All of these timer intervals are too ephemeral to be useful. I think they
> should all go.
> 
> I'm not sure.  The protocol leaves a lot of latitude wrt. sending all of these
> kinds of packets, but actual implementetions tend to follow a regular
> schedule augmented with occasional triggered updates.  These values are
> intended to reflecct the regular schedule.
> 
> > But maybe instead of trying to track intervals, would it be possible
> > to get a count of hello, ihu, and update TLVs sent (multicast and
> > unicast) -- kind of like the counts interfaces provide of Ethernet
> > frames transmitted and received?
> 
> That's an excellent idea if these values are read-only.  It's not useful if they
> are meant to be read-write.
> 
> (I can envision a node that decreases its Hello interval when it becomes
> mobile, and increases its interval when it becomes fixed.  Is that a legitimate
> application of a management interface?)

OK. So Toke also says it may not be reasonable to get rid of all the interval parameters. But it sounds like adding some statistics may be good, too.
I checked, and all the intervals were already defined as read-only. Statistics (counts) are always read-only. So I think we're ok on that front.
[IMO: The beauty of Babel is its lack of need for configuration -- an implementation should automatically adjust to changes in link characteristics. These parameters can be used in troubleshooting and debugging; the correct action after identifying undesirable behavior is a new revision of the implementation for improved automatic adjustment to changes in conditions and not manual tweaking.]

What intervals make sense to be able to report?
It sounds like ones that are simply a reaction to (or the value of) an interval sent by a neighbor do not make sense. I think that would get rid of the babel-neighbor-ihu-interval that Toke initially challenged.
But maybe it makes sense to keep the (optional) Hello interval parameters (multicast and unicast)?
What about the update interval?
Barbara

v2.23.0 | Report a Bug | By Email