From nobody Tue Jul 2 09:10:46 2019 Return-Path: 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 49F5C1203C5; Tue, 2 Jul 2019 09:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 MHSlbi9NBycu; Tue, 2 Jul 2019 09:10:43 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B9612027B; Tue, 2 Jul 2019 09:10:43 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id m24so38342588ioo.2; Tue, 02 Jul 2019 09:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=JSNeqUfN2Igcd/J7dB22DugvhUCQE+/TzCGj7965Npo=; b=hrmF0ofn6ZIR7x4X/5ziAajJoplMODluhOFvdT0xteb8uNd4eIu7apORDtjtf8QDV1 X4QThRDJOi2aX6i+Or7/opKgAlKqFZCKL9HQI8tKn51YdPAXWi+KruJo6jPhvv8LrtDk vMiMdqOy5MtE+ygyM5/UuqCH4vY5NHpvA3DQ67EfXq+uq1ZJv7l8uyJLjPV9vhg1aR9+ 4Zb0ylL2gQeWdf0ea/pFAllsaR1k/HwJLvGpOUJi1i2OPE7ydQJHRRGHFhsO+mOGKZjs LwZLcqRvvcpSUX2qgzvSXQAG5UUvNaSQX5J8/w51et95w+oKdu7JXvNHnJD9RgCalOtZ FcmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=JSNeqUfN2Igcd/J7dB22DugvhUCQE+/TzCGj7965Npo=; b=DxbhsLbZD7vbvG0cvFW+ONDoXeuGlDxvsdDyVaPG6TiNN1rX/VeDAMbETghoOf5nfj YXYzzRTTR1q55+YmvUpvYVaBWkgd2d7Yr5GuAy24NImDKQ40ATISgLIzFIMshmVTB4zb ixkVgSY4+9adQUTkGu9b9eqj4+aWuHP7Tc/xRZQ5ljkUxUY/Ch3RDYBaVcMP3942he7s aao/PEZf/MA/eQEJr3NcnuXvZQRN5qee9QJVX6cWvFr6mz++cnlfHo3flsT2oJxZilpD Pwiu1T9VSWyia9ucqEAdQIYNrkIgc8juHiy+isxSS4mBXynpv/RpnVCnOr1ct7ZLwgaK G12g== X-Gm-Message-State: APjAAAVcrpxfuLUedsDWwZOSguIyH91zEkb4PaFY3xlBa/lgVCR+FKWt 6QQfhafmtfsNmA6augP0uhjKykb/ZlZRjf9Vi2/ZtA== X-Google-Smtp-Source: APXvYqx5WCuFYipzekUhU9C72u6CYxb+3lmncVXiNQikkgt0QIb4ZiKhAQ0AToBBEpbcXcUFDD+gjq0Wx7THF5W6I3A= X-Received: by 2002:a5e:9401:: with SMTP id q1mr5916608ioj.276.1562083842704; Tue, 02 Jul 2019 09:10:42 -0700 (PDT) MIME-Version: 1.0 From: Donald Eastlake Date: Tue, 2 Jul 2019 12:10:31 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [babel] Call for presentations to the Babel WG in Montreal later this month X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 16:10:46 -0000 Hi, The Babel WG meeting has been scheduled for 13:50 to 14:50 Wednesday July 24th at the IETF Montreal meeting this month. If you would like to present, please respond to the chairs or to the WG mailing list. There are facilities for presenting remotely if you are unable to attend the meeting. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com From nobody Tue Jul 2 13:37:18 2019 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F246120100; Tue, 2 Jul 2019 13:37:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156209982938.23788.348093671423841052@ietfa.amsl.com> Date: Tue, 02 Jul 2019 13:37:09 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-dtls-06.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 20:37:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : Babel Routing Protocol over Datagram Transport Layer Security Authors : Antonin Decimo David Schinazi Juliusz Chroboczek Filename : draft-ietf-babel-dtls-06.txt Pages : 9 Date : 2019-07-02 Abstract: The Babel Routing Protocol does not contain any means to authenticate neighbours or protect messages sent between them. This document specifies a mechanism to ensure these properties, using Datagram Transport Layer Security (DTLS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-dtls-06 https://datatracker.ietf.org/doc/html/draft-ietf-babel-dtls-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-dtls-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 2 14:51:10 2019 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82275120169; Tue, 2 Jul 2019 14:51:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Mike McBride via Datatracker To: Cc: draft-ietf-babel-hmac.all@ietf.org, babel@ietf.org, mmcbride7@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Mike McBride Message-ID: <156210426145.23799.16215559699319611305@ietfa.amsl.com> Date: Tue, 02 Jul 2019 14:51:01 -0700 Archived-At: Subject: [babel] Rtgdir last call review of draft-ietf-babel-hmac-07 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 21:51:02 -0000 Reviewer: Mike McBride Review result: Ready Howdy, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-babel-hmac-07 Reviewer: Mike McBride Review Date: 2 July 2019 IETF LC End Date: 5 July 2019? Intended Status: Standards Track Summary: I reviewed the -00 of this draft back in Sept. 2018. The authors addressed my suggestions. I've now reviewed the -07 version and see no issues. Comments: This document is clearly written and easy to understand and ready to go. Major Issues: No major issues found. Minor Issues: No minor issues found. Nits: I still think a terminology section would be helpful in this, and most, ietf drafts but the authors did a good job of defining acronyms throughout the draft. well done. mike From nobody Wed Jul 3 05:45:24 2019 Return-Path: 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 BFDC3120284; Wed, 3 Jul 2019 05:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 KCyDLzj1NNnT; Wed, 3 Jul 2019 05:45:14 -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 5E3DB12027D; Wed, 3 Jul 2019 05:45:14 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x63CjCDG037237; Wed, 3 Jul 2019 08:45:12 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 2tgufwhjuc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Jul 2019 08:45:12 -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 x63CjBgh031233; Wed, 3 Jul 2019 08:45:11 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x63Cj6Ag031134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 Jul 2019 08:45:06 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 40076400A0A6; Wed, 3 Jul 2019 12:45:06 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30487.vci.att.com (Service) with ESMTPS id 2A0A0400A0A2; Wed, 3 Jul 2019 12:45:06 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0439.000; Wed, 3 Jul 2019 08:45:05 -0400 From: "STARK, BARBARA H" To: "'Donald Eastlake'" , "'Babel at IETF'" CC: "'babel-chairs'" Thread-Topic: [babel] Call for presentations to the Babel WG in Montreal later this month Thread-Index: AQHVMPC+6G8Ouqu5xUy8WQ8UtUV9jKa42CDA Date: Wed, 3 Jul 2019 12:45:05 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E203ACC@GAALPA1MSGUSRBF.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.221.230] 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=2019-07-03_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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907030156 Archived-At: Subject: Re: [babel] Call for presentations to the Babel WG in Montreal later this month X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 12:45:23 -0000 Hi Donald, Since I didn't manage to finish up the info model, I would appreciate a lit= tle time to discuss a few things. I intend to post another draft before the= deadline. Barbara > -----Original Message----- > From: babel On Behalf Of Donald Eastlake > Sent: Tuesday, July 02, 2019 12:11 PM > To: Babel at IETF > Cc: babel-chairs > Subject: [babel] Call for presentations to the Babel WG in Montreal later= this > month >=20 > Hi, >=20 > The Babel WG meeting has been scheduled for 13:50 to 14:50 Wednesday > July 24th at the IETF Montreal meeting this month. If you would like to > present, please respond to the chairs or to the WG mailing list. > There are facilities for presenting remotely if you are unable to attend = the > meeting. >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_babel&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3D6YczuxTniFSRgc0soKYn7sCld7IBYf0JilMMj9EJuTo&s=3DNw > WKOjXei1-6Akd-jrZO_x3OIIEw538Ye7CP1aowHxc&e=3D From nobody Wed Jul 3 06:08:58 2019 Return-Path: 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 7914D12015C; Wed, 3 Jul 2019 06:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 YxL77P-IIuM6; Wed, 3 Jul 2019 06:08:38 -0700 (PDT) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.6]) (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 A0D45120319; Wed, 3 Jul 2019 06:08:37 -0700 (PDT) Received: from [85.158.142.101] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-6.bemta.az-a.eu-central-1.aws.symcld.net id 91/BA-10247-3D8AC1D5; Wed, 03 Jul 2019 13:08:35 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJsWRWlGSWpSXmKPExsUi9LZno+6lFTK xBl83GVlsWdTNYnHyv7PFyTk/mC0WrHnK7sDisWTJT6YAxijWzLyk/IoE1ox3J08wF0x4xljR s+QRWwNjy2PGLkYuDhaBtcwSb09NZAZxhAQmMEk0z//PBOHcY5RYsWo2WxcjJwebgK3EptV3w WwRAU2J/p5bLCBFzAJrGCWuztzMCpIQFrCUWNNxnh2iyE5i0cK7TBC2nsTueQ1gNSwCKhLnp2 9nBrF5BWIlbt7dxAhiMwqISXw/tQasnllAXOLWk/lgtoSAgMSSPeeZIWxRiZeP/7FC1CdJ3H+ 6kBEirigx494cdghbVuLS/G6ouK/E3f+LgI7mALKVJba8iAW5WULgMaPEnf3bWSFqtCS2H58B NT9H4smCyVC96hItH+dB1chI3JnTyQTRPJ1N4sunzWBFQgLJEifmfGaBKJKTWNX7kAWi6AKzx J221ywgm5kF8iROtldDPCwocXLmExaYoW+PzmGewKg5C8nPsxA6ZiHpgAhrSqzfpQ9RrSgxpf shO4StIdE6Zy47svgCRvZVjBZJRZnpGSW5iZk5uoYGBrqGhsa6RrqmxnqJVbqJeqmlusmpeSV FiUBJvcTyYr3iytzknBS9vNSSTYzAFJZSyGS6g7F31hu9Q4ySHExKoryrK2VihfiS8lMqMxKL M+KLSnNSiw8xynBwKEnwSi4HygkWpaanVqRl5gDTKUxagoNHSYS3aSlQmre4IDG3ODMdInWKM ZBjwsu5i5g53v1cDCQ/rloCJL+DyeY7IHLz3KVA8giIFGLJy89LlRLn7QHZIwAyKKM0D24NLE dcYpSVEuZlZGBgEOIpSC3KzSxBlX/FKM7BqCTMOxtkCk9mXgncNa+ADmUCOlQ+Xwrk0JJEhJR UA1PesZXTP+9gmpItmj/xj+qMv7+5DUJ/JgRkfwr4W8F4lkt2s5H1eqkttbG/8x9lsrX8bs10 Kgyw6quq31dT9Dprz261OrFXX2a+9p/QPIO//WXYrMDWpSfltD5pxd6VNAlKWrFm/86VLVH/3 ynVfn7ywuKUesK2PNndfv+t3LcxxPeIc8yZcMpynYSU2WS3dK2dIrPsWaY8PX81PnVKS7iOIM su/uvRqxeaPmr4f+D4Qo39TF2F5S8vnp8qKX+xOGlVx7G7l3/ea11Rxpe88M61RpZ9s99r3PR m+FW+T3zZLPWEF3efVSbuftOhU2p7j/E/Q8z5mA+PDput3iH/2dr9wa04x7vx0wuOBW+059+v xFKckWioxVxUnAgAkvGFBYwEAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-9.tower-226.messagelabs.com!1562159312!102957!1 X-Originating-IP: [18.237.140.177] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.43.9; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 8879 invoked from network); 3 Jul 2019 13:08:33 -0000 Received: from ec2-18-237-140-177.us-west-2.compute.amazonaws.com (HELO mail.ds.dlp.protect.symantec.com) (18.237.140.177) by server-9.tower-226.messagelabs.com with ECDHE-RSA-AES256-SHA384 encrypted SMTP; 3 Jul 2019 13:08:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ECI365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+L8nvQFu3bnolXGlG0OkUmciEew3mN0G6AXGmbBQ+gg=; b=jiiiUX+Z8seSUt816tDt4uBn1P/V00qyQ1PUu9uHHIVDTpp4p0C0YkuBfO2hSmzo0QdAaSIxdzbopy5ynEyb99BaYdKjcS4QKnt8XLGD4kG6Bgh15C5OWruomWw2itrF3LrKtf9xnZBbMbLQh7v05VSa+KqpnrrXSOxrkns5d6s= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB5843.eurprd03.prod.outlook.com (20.179.39.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.17; Wed, 3 Jul 2019 13:08:29 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::91f3:6bd1:1631:9b4a]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::91f3:6bd1:1631:9b4a%6]) with mapi id 15.20.2032.019; Wed, 3 Jul 2019 13:08:29 +0000 From: Alexander Vainshtein To: "rtg-ads@ietf.org" CC: "rtg-dir@ietf.org" , "draft-ietf-babel-applicability.all@ietf.org" , "babel@ietf.org" Thread-Topic: RtgDir review: draft-ietf-babel-applicability-06 Thread-Index: AdUvH5YiygIfUsyWQTGhUP+K9gfY2Q== Date: Wed, 3 Jul 2019 13:08:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 06fdcef6-01f6-4d27-9725-08d6ffb78b1f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR03MB5843; x-ms-traffictypediagnostic: AM0PR03MB5843: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(396003)(366004)(376002)(346002)(199004)(51444003)(189003)(66066001)(64756008)(66446008)(66476007)(450100002)(5660300002)(66556008)(7696005)(54906003)(66946007)(54896002)(6306002)(9686003)(7736002)(316002)(73956011)(4326008)(52536014)(86362001)(81156014)(26005)(74316002)(81166006)(76116006)(9326002)(8676002)(55016002)(6506007)(8936002)(5640700003)(53936002)(33656002)(186003)(71200400001)(71190400001)(486006)(6436002)(99286004)(6916009)(25786009)(102836004)(6116002)(790700001)(72206003)(3846002)(14454004)(68736007)(478600001)(14444005)(2501003)(476003)(2906002)(256004)(2351001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB5843; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: zgT4tTHYQzju2m2j3xQWdNev8pG/0ZDTiEo+YMg05XyG7d7gvfOgBoCkNDAOS5Vt1iHMhVzSg7M27tkWgjEJZrFG/YZDkWnUMRp98h3QZVJy+FgU+khVaTlD5cCpd+LGZoRUMR7c082WCXl3nbFi+tj2zdXOqhzMhHFxkrf3GYWwhwtmHIEOzGMCY+EZSFPNNnErqmKiJociH2WGatqUMSP4oDEfmlWm8ZlBsNBMGZNYvt/OO0VFMmnDjyPApq6vorjISgPlj7S2fKMN+gyJ6h7qdt8mlr6e5N3dmuIHKYhZ3ZVC83CM75ROYLtc39LPM/BuHSBX9nqpEpoQ8ukSyPSC2eVAO94EqWGIKXjyPO0MS/fLH2bqp8SK1PcuYhFk4GzNyrOkK2txT+cjzCxeJ6ZaDQCihtpniI7bJoQsu24= Content-Type: multipart/alternative; boundary="_000_AM0PR03MB38283EF2B5AEB53E24AF190D9DFB0AM0PR03MB3828eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 06fdcef6-01f6-4d27-9725-08d6ffb78b1f X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 13:08:29.6176 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: alexvain@ecitele.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB5843 X-CFilter-Loop: Reflected X-DetectorID-Processed: d8d3a2b3-1594-4c39-92fb-b8312fe65a8a Archived-At: Subject: [babel] RtgDir review: draft-ietf-babel-applicability-06 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 13:08:48 -0000 --_000_AM0PR03MB38283EF2B5AEB53E24AF190D9DFB0AM0PR03MB3828eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sCgpJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSBy ZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8g cmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNz IHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9u IHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92aWRl IGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSDigItodHRwOi8vdHJhYy50b29s cy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyCgpBbHRob3VnaCB0aGVzZSBjb21t ZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291 bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBv dGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZl IHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRy YWZ0LgoKRG9jdW1lbnQ6IGRyYWZ0LWlldGYtYmFiZWwtYXBwbGljYWJpbGl0eS0wNgpSZXZpZXdl cjogQWxleGFuZGVyICjigJxTYXNoYeKAnSkgVmFpbnNodGVpbgpSZXZpZXcgRGF0ZTogMDMtSnVs LTE5CklFVEYgTEMgRW5kIERhdGU6IDA0LUp1bC0xOQpJbnRlbmRlZCBTdGF0dXM6IEluZm9ybWF0 aW9uYWwKClN1bW1hcnk6CgpJIGhhdmUgc29tZSBtaW5vciBjb25jZXJucyBhYm91dCB0aGlzIGRv Y3VtZW50IHRoYXQgSSB0aGluayBzaG91bGQgYmUgcmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9u LgoKQ29tbWVudHM6CgpJIGhhdmUgcmV2aWV3ZWQgdGhlIC0wMSB2ZXJzaW9uIG9mIHRoZSBkcmFm dCB0d28gYW5kIGEgaGFsZiB5ZWFycyBhZ28uIFNpbmNlIHRoZW4gdGhlIGRvY3VtZW50IGhhcyB1 bmRlcmdvbmUgbWFzc2l2ZSBjaGFuZ2VzLCBzbyB0aGF0IEkgZmVlbCB0aGF0IEkgaGF2ZSBiZWVu IHJldmlld2luZyBhIG5ldyBkb2N1bWVudC4KT25lIHRoaW5nIHRoYXQgcmVtYWluZWQgdW5jaGFu Z2VkLCBob3dldmVyLCB3YXMgdGhlIHJlYWRpbmVzcyBvZiB0aGUgYXV0aG9yIHRvIGNvb3BlcmF0 ZSB3aXRoIHRoZSByZXZpZXcuICBJIHdvdWxkIGxpa2UgdG8gZXhwcmVzcyBteSBkZWVwIGdyYXRp dHVkZSB0byBKdWxpdXN6IGZvciB0aGF0LgoKVGhlIGRvY3VtZW50IGlzIHZlcnkgd2VsbCB3cml0 dGVuIGFuZCBtYXRjaGVzIG15IHVuZGVyc3RhbmRpbmcgb2Ygd2hhdCBhbiBhcHBsaWNhYmlsaXR5 IHN0YXRlbWVudCBkcmFmdCBmb3IgYSByb3V0aW5nIHByb3RvY29sIHNob3VsZCBiZS4gSXQgaXMg bm90IG9ubHkgZWFzeSBidXQgYWxzbyBpbnRlcmVzdGluZyB0byByZWFkIChhdCBsZWFzdCBmb3Ig bWUpLgoKTW9zdCBvZiB0aGUgaXNzdWVzIEkgYW0gcmFpc2luZyBpbiB0aGlzIHJldmlldyBhcmUg aW4gdGhlIGdyYXkgYXJlYSBiZXR3ZWVuIOKAnG1pbm9y4oCdIGFuZCDigJxuaXTigJ0uIE15IGNs YXNzaWZpY2F0aW9uIGluIHRoaXMgcmV2aWV3IGlzLCB0aGVyZWZvcmUsIGFyYml0cmFyeSB0byBz b21lIGV4dGVudCwgYW5kIHNob3VsZCBiZSB0YWtlbiB3aXRoIGEgZ3JhaW4gb2Ygc2FsdC4KQW5k IGF0IGxlYXN0IHNvbWUgb2YgdGhlc2UgaXNzdWVzIHJlZmxlY3QgbXkgcGVyc29uYWwgY3VyaW9z aXR5LgoKTWFqb3IgSXNzdWVzOiBOb25lIGZvdW5kCgpNaW5vciBJc3N1ZXM6CgoKMS4gICAgICAg VGhlIHRleHQgaW4gU2VjdGlvbiAyLjMgc2F5czog4oCcaW4gb3JkZXIgdG8gY2hlY2sgdGhlIGlu dGVyb3BlcmFiaWxpdHkgb2YgdHdvIGltcGxlbWVudGF0aW9ucyBvZiBCYWJlbCwgaXQgaXMgZW5v dWdoIHRvIHZlcmlmeSB0aGF0IHRoZSBpbnRlcmFjdGlvbiBvZiB0aGUgdHdvIGRvZXMgbm90IHZp b2xhdGUgdGhlIHByb3RvY29sJ3MgYXNzdW1wdGlvbnMu4oCdCgphLiAgICAgICBUaGlzIGxvb2tl ZCBqdXN0IHdyb25nIHRvIG1lIOKAkyB0d28gaW1wbGVtZW50YXRpb25zIG1heSBwcmVzZXJ2ZSBh bGwgdGhlIHByb3RvY29sIGFzc3VtcHRpb25zIGJ1dCBmYWlsIGluIHRoZSBpbnRlcm9wZXJhYmls aXR5IHRlc3QsIGUuZy4sIGJlY2F1c2UgZW5jb2Rpbmcgb2Ygc29tZSBwYXJhbWV0ZXIgaW4gb25l IG9mIHRoZSBQRFVzIGlzIGRpZmZlcmVudAoKYi4gICAgICAgVGhlIGF1dGhvciBoYXMgY29uZmly bWVkIHRoYXQgdGhpcyB3YXMgYWN0dWFsbHkgYSB0eXBvLCBhbmQgaGFzIGFncmVlZCB0byByZW1v dmUgdGhpcyB0ZXh0CgpjLiAgICAgICBUaGlzIGlzIG9uZSBvZiB0aGUgY2FzZXMgd2hlcmUgIGl0 IGlzIGRpZmZpY3VsdCB0byBzYXkgd2hldGhlciB0aGlzIGlzIGEgbWlub3IgaXNzdWUgb3IgYSBu aXQKCjIuICAgICAgIFRoZSBleHBsYW5hdGlvbiBvZiB0aGUgQkFCRUwgYmFzZSBhc3N1bXB0aW9u cyBpbiBTZWN0aW9uIDIuMi4gaXMgdmVyeSB1c2VmdWwuIEhvd2V2ZXIsIGl0IGFzc3VtZXMgdGhh dCB0aGUgcmVhZGVyIGhhcyBhdCBsZWFzdCBzb21lIGludHVpdGl2ZSB1bmRlcnN0YW5kaW5nIG9m IHRoZSDigJxyb3V0aW5nIGFsZ2VicmHigJ0gbm90YXRpb25zLgoKYS4gICAgICAgRGlzY3Vzc2Vk IHRoaXMgcG9pbnQgd2l0aCB0aGUgYXV0aG9yCgpiLiAgICAgICBXZSBoYXZlIGFncmVlZCB0aGF0 IHRoZXJlIGlzIG5vIG5lZWQgdG8gbWFrZSB0aGlzIGRvY3VtZW50IGEgZGV0YWlsZWQgdHV0b3Jp YWwgb24gdGhlIHN1YmplY3QsIG5vciB0byBpbmR1bGdlIGluIEFTQ0lJIGFydCAodGhhdCB3b3Vs ZCBiZSBpbmRpY2F0aXZlIGF0IGJlc3QgaW4gYW55IGNhc2UpCgpjLiAgICAgICBTb21lIHNob3J0 IGV4cGxhbmF0aW9uLCBwb3NzaWJseSBhdWdtZW50ZWQgd2l0aCBJbmZvcm1hdGl2ZSByZWZlcmVu Y2VzIHRvIHRoZSByZWxldmFudCByZXNlYXJjaCBwYXBlcnMsIHdvdWxkIGJlIHN1ZmZpY2llbnQg SU1ITwoKMy4gICAgICAgVGhlIGRyYWZ0IG1lbnRpb25zIDQgaW5kZXBlbmRlbnQgaW1wbGVtZW50 YXRpb25zIG9mIEJBQkVMIGluIFNlY3Rpb24gMi4xLCBidXQgZG9lcyBub3Qgc2F5IGFueXRoaW5n IGFib3V0IHRoZWlyIGludGVyb3BlcmFiaWxpdHkuIFN1Y2ggaW5mb3JtYXRpb24sIGlmIGF2YWls YWJsZSwgc2hvdWxkIGJlIHZlcnkgdXNlZnVsIGZvciB0aGUgcmVhZGVycy4gKElmIG5vIHN1Y2gg aW5mb3JtYXRpb24gaXMgYXZhaWxhYmxlIGFzIG9mIHRoaXMgbW9tZW50LCBJIHdvdWxkIGFjY2Vw dCB0aGlzKQoKNC4gICAgICAgVGhlIGNvbXBhcmlzb24gYmV0d2VlbiBCQUJFTCBhbmQgSVMtSVMv T1NQRiBpbiBTZWN0aW9uIDIuNC4xIGxhY2tzIGluZm9ybWF0aW9uIGFib3V0IHBvc3NpYmlsaXR5 IG9mIGZhc3QgbG9jYWwgcHJvdGVjdGlvbiBtZWNoYW5pc21zIChhLmsuYS4gSVAgRlJSLCBzZWUs IGUuZy4sIFJGQyA1Mjg2KQoKYS4gICAgICAgRGlzY3Vzc2VkIHRoaXMgcG9pbnQgd2l0aCB0aGUg YXV0aG9yIHNpbmNlIGZyb20gbXkgUE9WIHN1Y2ggaW5mb3JtYXRpb24gY291bGQgYmUgdmFsdWFi bGUgZm9yIHRoZSByZWFkZXJzIHRoYXQgY29uc2lkZXIgZGVwbG95aW5nIEJBQkVMIGluIHRoZWly IG5ldHdvcmtzCgpiLiAgICAgICBVbmZvcnR1bmF0ZWx5LCAgdGhlIGF1dGhvciBjb3VsZCBub3Qg cHJvdmlkZSBhbiBpbW1lZGlhdGUgYW5zd2VyIG9uZSB3YXkgb3IgYW5vdGhlcgoKNS4gICAgICAg TGFzdCBidXQgbm90IGxlYXN0LCBhIGZldyB3b3JkcyBhYm91dCBtYW5hZ2VhYmlsaXR5IG9mIEJB QkVMIHdvdWxkIGJlIHVzZWZ1bCBJTUhPLgoKTml0czoKCjEuICAgICAgIEkgZGlkIG5vdCBydW4g dGhlIG5pdHMgY2hlY2sgb24gdGhlIGRyYWZ0CgoyLiAgICAgICBJIHRoaW5rIHRoYXQgdGhlIHdv cmsg4oCcYXJndWXigJ0gIGluIHRoZSB0ZXh0IGluIFNlY3Rpb24gMSDigJx3ZSBhcmd1ZSB0aGF0 IHRoZXJlIGV4aXN0IG5pY2hlcyB3aGVyZSBCYWJlbCBpcyB1c2VmdWwgYW5kIHRoYXQgYXJlIG5v dCBhZGVxdWF0ZWx5IHNlcnZlZCBieSBtb3JlICBtYXR1cmUgcHJvdG9jb2xz4oCdIGlzIGJ5IGZh ciB0b28gd2VhayAob3IgdG9vIG1vZGVzdD8pLiBGcm9tIG15IFBPViB0aGUgZHJhZnQgZ29lcyBm YXIgYmV5b25kIGFyZ3VpbmcuCgphLiAgICAgICBEaXNjdXNzZWQgdGhpcyBwb2ludCB3aXRoIHRo ZSBhdXRob3IKCmIuICAgICAgIFRoZSBhdXRob3IgYWdyZWVzIHRvIGNoYW5nZSB0aGlzIHRleHQg dG8gYmUgbW9yZSBkZWZpbml0aXZlLAoKSG9wZWZ1bGx5IHRoZXNlIG5vdGVzIHdpbGwgYmUgdXNl ZnVsLgoKUmVnYXJkcywKU2FzaGEKCk9mZmljZTogKzk3Mi0zOTI2NjMwMgpDZWxsOiAgICAgICs5 NzItNTQ5MjY2MzAyCkVtYWlsOiAgIEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tCgoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCgpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0 aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIApDT05G SURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyAKdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5m b3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdp bmFsIAphbmQgYWxsIGNvcGllcyB0aGVyZW9mLgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K --_000_AM0PR03MB38283EF2B5AEB53E24AF190D9DFB0AM0PR03MB3828eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+CjxtZXRhIG5hbWU9IkdlbmVyYXRvciIg Y29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPgo8c3R5bGU+PCEt LQovKiBGb250IERlZmluaXRpb25zICovCkBmb250LWZhY2UKCXtmb250LWZhbWlseToiQ2FtYnJp YSBNYXRoIjsKCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQpAZm9udC1mYWNlCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsKCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30KQGZvbnQt ZmFjZQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIg NDt9Ci8qIFN0eWxlIERlZmluaXRpb25zICovCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwKCXttYXJnaW46MGNtOwoJbWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJZm9udC1z aXplOjExLjBwdDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluawoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsKCWNvbG9yOiMwNTYzQzE7 Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6Izk1NEY3MjsKCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBk aXYuTXNvUGxhaW5UZXh0Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJbXNvLXN0eWxlLWxpbms6 IlBsYWluIFRleHQgQ2hhciI7CgltYXJnaW46MGNtOwoJbWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJ Zm9udC1zaXplOjExLjBwdDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aAoJe21zby1zdHlsZS1wcmlvcml0eTozNDsKCW1hcmdpbi10b3A6MGNtOwoJbWFyZ2luLXJpZ2h0 OjBjbTsKCW1hcmdpbi1ib3R0b206MGNtOwoJbWFyZ2luLWxlZnQ6MzYuMHB0OwoJbWFyZ2luLWJv dHRvbTouMDAwMXB0OwoJZm9udC1zaXplOjExLjBwdDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMAoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsKCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOwoJbWFy Z2luLXJpZ2h0OjBjbTsKCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOwoJbWFyZ2luLWxlZnQ6 MGNtOwoJZm9udC1zaXplOjEyLjBwdDsKCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNl cmlmO30Kc3Bhbi5QbGFpblRleHRDaGFyCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hh ciI7Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7 Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9CnNwYW4uRW1haWxTdHlsZTIxCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOwoJY29sb3I6d2luZG93dGV4dDt9Ci5Nc29DaHBEZWZhdWx0Cgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7Cglmb250LXNpemU6MTAuMHB0OwoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQpAcGFnZSBXb3JkU2VjdGlvbjEKCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsKCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQpkaXYuV29yZFNlY3Rpb24x Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQovKiBMaXN0IERlZmluaXRpb25zICovCkBsaXN0IGwwCgl7 bXNvLWxpc3QtaWQ6NjQ0MzEzOTE0OwoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7Cgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MjA1MDY2MzY4MCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcw MyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9CkBsaXN0IGww OmxldmVsMQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0OwoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9CkBsaXN0IGwwOmxldmVsMgoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotMTguMHB0O30K QGxpc3QgbDA6bGV2ZWwzCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7Cglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQpAbGlzdCBsMDpsZXZlbDQKCXttc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQpAbGlzdCBsMDpsZXZlbDUKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0OwoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9CkBsaXN0IGwwOmxldmVsNgoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0OwoJdGV4dC1pbmRlbnQ6LTkuMHB0O30KQGxp c3QgbDA6bGV2ZWw3Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3QgbDA6bGV2ZWw4Cgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQpAbGlzdCBsMDpsZXZlbDkKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpy aWdodDsKCXRleHQtaW5kZW50Oi05LjBwdDt9CkBsaXN0IGwxCgl7bXNvLWxpc3QtaWQ6NzY1MTU1 MzQ3OwoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTMxODYz MDk2MiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcx NSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9CkBsaXN0IGwxOmxldmVsMQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9CkBsaXN0IGwxOmxldmVsMgoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3QgbDE6bGV2ZWwzCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7Cgl0ZXh0LWluZGVudDotOS4w cHQ7fQpAbGlzdCBsMTpsZXZlbDQKCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMTps ZXZlbDUKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsKCW1zby1sZXZlbC10 YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9CkBsaXN0IGwxOmxldmVsNgoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0OwoJdGV4dC1pbmRlbnQ6LTkuMHB0O30KQGxpc3QgbDE6bGV2ZWw3Cgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0 ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3QgbDE6bGV2ZWw4Cgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMTpsZXZl bDkKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsKCW1zby1sZXZlbC10YWIt c3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsKCXRleHQtaW5kZW50 Oi05LjBwdDt9Cm9sCgl7bWFyZ2luLWJvdHRvbTowY207fQp1bAoJe21hcmdpbi1ib3R0b206MGNt O30KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4K PC9oZWFkPgo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIi Pgo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyw8 bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5n IERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3Rv cmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0 cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFu ZCBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LgogVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmll dyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBp bmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSDigIto dHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyPG86cD48 L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZv ciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3Ug Y291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBj b21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJv dWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcKIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29O b3JtYWwiPkRvY3VtZW50OiBkcmFmdC1pZXRmLWJhYmVsLWFwcGxpY2FiaWxpdHktMDY8bzpwPjwv bzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmV2aWV3ZXI6IEFsZXhhbmRlciAo4oCcU2Fz aGHigJ0pIFZhaW5zaHRlaW48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmV2 aWV3IERhdGU6IDAzLUp1bC0xOSA8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SUVURiBMQyBFbmQgRGF0ZTogMDQtSnVsLTE5PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29O b3JtYWwiPkludGVuZGVkIFN0YXR1czogSW5mb3JtYXRpb25hbDxvOnA+PC9vOnA+PC9wPgo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+U3VtbWFyeTwvYj46PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj5JIGhhdmUgc29tZSBtaW5vciBjb25jZXJucyBhYm91 dCB0aGlzIGRvY3VtZW50IHRoYXQgSSB0aGluayBzaG91bGQgYmUgcmVzb2x2ZWQgYmVmb3JlIHB1 YmxpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+Q29tbWVudHM8L2I+OjxiPjxv OnA+PC9vOnA+PC9iPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSByZXZpZXdlZCB0aGUgLTAxIHZlcnNpb24g b2YgdGhlIGRyYWZ0IHR3byBhbmQgYSBoYWxmIHllYXJzIGFnby4gU2luY2UgdGhlbiB0aGUgZG9j dW1lbnQgaGFzIHVuZGVyZ29uZSBtYXNzaXZlIGNoYW5nZXMsIHNvIHRoYXQgSSBmZWVsIHRoYXQg SSBoYXZlIGJlZW4gcmV2aWV3aW5nIGEgbmV3IGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPgo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbmUgdGhpbmcgdGhhdCByZW1haW5lZCB1bmNoYW5nZWQsIGhvd2V2 ZXIsIHdhcyB0aGUgcmVhZGluZXNzIG9mIHRoZSBhdXRob3IgdG8gY29vcGVyYXRlIHdpdGggdGhl IHJldmlldy4mbmJzcDsgSSB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgbXkgZGVlcCBncmF0aXR1ZGUg dG8gSnVsaXVzeiBmb3IgdGhhdC4KPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZG9jdW1lbnQg aXMgdmVyeSB3ZWxsIHdyaXR0ZW4gYW5kIG1hdGNoZXMgbXkgdW5kZXJzdGFuZGluZyBvZiB3aGF0 IGFuIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IGRyYWZ0IGZvciBhIHJvdXRpbmcgcHJvdG9jb2wg c2hvdWxkIGJlLiBJdCBpcyBub3Qgb25seSBlYXN5IGJ1dCBhbHNvIGludGVyZXN0aW5nIHRvIHJl YWQgKGF0IGxlYXN0IGZvciBtZSkuPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Nb3N0IG9mIHRoZSBp c3N1ZXMgSSBhbSByYWlzaW5nIGluIHRoaXMgcmV2aWV3IGFyZSBpbiB0aGUgZ3JheSBhcmVhIGJl dHdlZW4g4oCcbWlub3LigJ0gYW5kIOKAnG5pdOKAnS4gTXkgY2xhc3NpZmljYXRpb24gaW4gdGhp cyByZXZpZXcgaXMsIHRoZXJlZm9yZSwgYXJiaXRyYXJ5IHRvIHNvbWUgZXh0ZW50LCBhbmQgc2hv dWxkIGJlIHRha2VuIHdpdGggYSBncmFpbiBvZiBzYWx0LiZuYnNwOwo8bzpwPjwvbzpwPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIGF0IGxlYXN0IHNvbWUgb2YgdGhlc2UgaXNzdWVzIHJl ZmxlY3QgbXkgcGVyc29uYWwgY3VyaW9zaXR5Lgo8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPk1h am9yIElzc3VlczwvYj46IE5vbmUgZm91bmQ8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPk1pbm9y IElzc3VlczwvYj46PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5U aGUgdGV4dCBpbiBTZWN0aW9uIDIuMyBzYXlzOiDigJxpbiBvcmRlciB0byBjaGVjayB0aGUgaW50 ZXJvcGVyYWJpbGl0eSBvZiB0d28gaW1wbGVtZW50YXRpb25zIG9mIEJhYmVsLCBpdCBpcyBlbm91 Z2ggdG8gdmVyaWZ5IHRoYXQgdGhlIGludGVyYWN0aW9uIG9mIHRoZSB0d28gZG9lcyBub3Qgdmlv bGF0ZSB0aGUgcHJvdG9jb2wncyBhc3N1bXB0aW9ucy7igJ08bzpwPjwvbzpwPjwvcD4KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZvMiI+CjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5U aGlzIGxvb2tlZCBqdXN0IHdyb25nIHRvIG1lIOKAkyB0d28gaW1wbGVtZW50YXRpb25zIG1heSBw cmVzZXJ2ZSBhbGwgdGhlIHByb3RvY29sIGFzc3VtcHRpb25zIGJ1dCBmYWlsIGluIHRoZSBpbnRl cm9wZXJhYmlsaXR5IHRlc3QsIGUuZy4sIGJlY2F1c2UgZW5jb2Rpbmcgb2Ygc29tZSBwYXJhbWV0 ZXIgaW4gb25lIG9mIHRoZSBQRFVzIGlzIGRpZmZlcmVudDxvOnA+PC9vOnA+PC9wPgo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVu dDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8yIj4KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPlRo ZSBhdXRob3IgaGFzIGNvbmZpcm1lZCB0aGF0IHRoaXMgd2FzIGFjdHVhbGx5IGEgdHlwbywgYW5k IGhhcyBhZ3JlZWQgdG8gcmVtb3ZlIHRoaXMgdGV4dDxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8yIj4KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yy48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOwo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPlRoaXMg aXMgb25lIG9mIHRoZSBjYXNlcyB3aGVyZSAmbmJzcDtpdCBpcyBkaWZmaWN1bHQgdG8gc2F5IHdo ZXRoZXIgdGhpcyBpcyBhIG1pbm9yIGlzc3VlIG9yIGEgbml0PG86cD48L286cD48L3A+CjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlz dDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPlRoZSBleHBsYW5hdGlvbiBvZiB0 aGUgQkFCRUwgYmFzZSBhc3N1bXB0aW9ucyBpbiBTZWN0aW9uIDIuMi4gaXMgdmVyeSB1c2VmdWwu IEhvd2V2ZXIsIGl0IGFzc3VtZXMgdGhhdCB0aGUgcmVhZGVyIGhhcyBhdCBsZWFzdCBzb21lIGlu dHVpdGl2ZSB1bmRlcnN0YW5kaW5nIG9mIHRoZSDigJxyb3V0aW5nIGFsZ2VicmHigJ0gbm90YXRp b25zLgo8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIg bGZvMiI+CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PmEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5EaXNjdXNzZWQgdGhpcyBwb2ludCB3aXRoIHRoZSBh dXRob3I8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIg bGZvMiI+CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PmIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5XZSBoYXZlIGFncmVlZCB0aGF0IHRoZXJlIGlzIG5v IG5lZWQgdG8gbWFrZSB0aGlzIGRvY3VtZW50IGEgZGV0YWlsZWQgdHV0b3JpYWwgb24gdGhlIHN1 YmplY3QsIG5vciB0byBpbmR1bGdlIGluIEFTQ0lJIGFydCAodGhhdCB3b3VsZCBiZSBpbmRpY2F0 aXZlIGF0IGJlc3QgaW4gYW55IGNhc2UpPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPgo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj5jLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+U29tZSBzaG9ydCBl eHBsYW5hdGlvbiwgcG9zc2libHkgYXVnbWVudGVkIHdpdGggSW5mb3JtYXRpdmUgcmVmZXJlbmNl cyB0byB0aGUgcmVsZXZhbnQgcmVzZWFyY2ggcGFwZXJzLCB3b3VsZCBiZSBzdWZmaWNpZW50IElN SE88bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3Nw YW4+VGhlIGRyYWZ0IG1lbnRpb25zIDQgaW5kZXBlbmRlbnQgaW1wbGVtZW50YXRpb25zIG9mIEJB QkVMIGluIFNlY3Rpb24gMi4xLCBidXQgZG9lcyBub3Qgc2F5IGFueXRoaW5nIGFib3V0IHRoZWly IGludGVyb3BlcmFiaWxpdHkuIFN1Y2ggaW5mb3JtYXRpb24sIGlmIGF2YWlsYWJsZSwgc2hvdWxk IGJlIHZlcnkgdXNlZnVsIGZvciB0aGUgcmVhZGVycy4gKElmIG5vIHN1Y2gKIGluZm9ybWF0aW9u IGlzIGF2YWlsYWJsZSBhcyBvZiB0aGlzIG1vbWVudCwgSSB3b3VsZCBhY2NlcHQgdGhpcyk8bzpw PjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVu dDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj40LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Cjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+VGhl IGNvbXBhcmlzb24gYmV0d2VlbiBCQUJFTCBhbmQgSVMtSVMvT1NQRiBpbiBTZWN0aW9uIDIuNC4x IGxhY2tzIGluZm9ybWF0aW9uIGFib3V0IHBvc3NpYmlsaXR5IG9mIGZhc3QgbG9jYWwgcHJvdGVj dGlvbiBtZWNoYW5pc21zIChhLmsuYS4gSVAgRlJSLCBzZWUsIGUuZy4sIFJGQyA1Mjg2KTxvOnA+ PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8yIj4KPCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+YS48c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBk aXI9IkxUUiI+PC9zcGFuPkRpc2N1c3NlZCB0aGlzIHBvaW50IHdpdGggdGhlIGF1dGhvciBzaW5j ZSBmcm9tIG15IFBPViBzdWNoIGluZm9ybWF0aW9uIGNvdWxkIGJlIHZhbHVhYmxlIGZvciB0aGUg cmVhZGVycyB0aGF0IGNvbnNpZGVyIGRlcGxveWluZyBCQUJFTCBpbiB0aGVpciBuZXR3b3Jrczxv OnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8yIj4K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yi48c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBkaXI9IkxUUiI+PC9zcGFuPlVuZm9ydHVuYXRlbHksJm5ic3A7IHRoZSBhdXRob3IgY291bGQg bm90IHByb3ZpZGUgYW4gaW1tZWRpYXRlIGFuc3dlciBvbmUgd2F5IG9yIGFub3RoZXI8bzpwPjwv bzpwPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj41LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Cjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+TGFzdCBi dXQgbm90IGxlYXN0LCBhIGZldyB3b3JkcyBhYm91dCBtYW5hZ2VhYmlsaXR5IG9mIEJBQkVMIHdv dWxkIGJlIHVzZWZ1bCBJTUhPLgo8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPk5pdHM8L2I+Ojxv OnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5J IGRpZCBub3QgcnVuIHRoZSBuaXRzIGNoZWNrIG9uIHRoZSBkcmFmdDxvOnA+PC9vOnA+PC9wPgo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5JIHRoaW5rIHRoYXQgdGhl IHdvcmsg4oCcPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVs bG93Ij5hcmd1ZTwvc3Bhbj7igJ0mbmJzcDsgaW4gdGhlIHRleHQgaW4gU2VjdGlvbiAxIOKAnHdl CjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+YXJn dWU8L3NwYW4+IHRoYXQgdGhlcmUgZXhpc3QgbmljaGVzIHdoZXJlIEJhYmVsIGlzIHVzZWZ1bCBh bmQgdGhhdCBhcmUgbm90IGFkZXF1YXRlbHkgc2VydmVkIGJ5IG1vcmUmbmJzcDsgbWF0dXJlIHBy b3RvY29sc+KAnSBpcyBieSBmYXIgdG9vIHdlYWsgKG9yIHRvbyBtb2Rlc3Q/KS4gRnJvbSBteSBQ T1YgdGhlIGRyYWZ0IGdvZXMgZmFyIGJleW9uZCBhcmd1aW5nLgo8bzpwPjwvbzpwPjwvcD4KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1p bmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDIgbGZvNCI+CjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bh bj5EaXNjdXNzZWQgdGhpcyBwb2ludCB3aXRoIHRoZSBhdXRob3I8bzpwPjwvbzpwPjwvcD4KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1p bmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDIgbGZvNCI+CjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bh bj5UaGUgYXV0aG9yIGFncmVlcyB0byBjaGFuZ2UgdGhpcyB0ZXh0IHRvIGJlIG1vcmUgZGVmaW5p dGl2ZSw8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvcGVmdWxseSB0aGVzZSBub3RlcyB3aWxsIGJl IHVzZWZ1bC48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPlNhc2hhPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PZmZpY2U6ICYj NDM7OTcyLTM5MjY2MzAyPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNlbGw6 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7OTcyLTU0OTI2NjMwMjxvOnA+PC9v OnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FbWFpbDombmJzcDsmbmJzcDsgQWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8YnIgY2xlYXI9ImJvdGgiPgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188QlI+CjxCUj4KVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3Ig dGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcyA8QlI+ CkNPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29t LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIDxCUj4KdHJhbnNtaXNzaW9uIGluIGVycm9yLCBw bGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUg dGhlIG9yaWdpbmFsIDxCUj4KYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi48QlI+Cl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxCUj4KPC9ib2R5Pgo8L2h0bWw+Cgo= --_000_AM0PR03MB38283EF2B5AEB53E24AF190D9DFB0AM0PR03MB3828eurp_-- From nobody Wed Jul 3 10:10:11 2019 Return-Path: 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 100BB120329; Wed, 3 Jul 2019 10:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 zTuwFaO7Mor2; Wed, 3 Jul 2019 10:10:07 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4412012032D; Wed, 3 Jul 2019 10:10:07 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id k8so6622419iot.1; Wed, 03 Jul 2019 10:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b5Sow97QC/90E4o81kTQESQdyKKdPqxujB+XQT+2Hz4=; b=TjlEqfj2+9uwor+snlcQLTtVtDNsh1yl1hloEOpsdMcWWI/3OshSsAMuKGtfSZ5mZs aWBgpX6IMZc0MrZdN7CG9ntSbhaGqDebo6JMhl2nNfPRyQJMvCTDlZ3TI+TWBxTNc/vw pz4iiuKICIANHF0Bgbfjwf++rsU0FTe2DQICTd37QQKhENaJPB7citUgJnTyr1XSWZrF Kc1SPyTwkNbBmvBWjf5kzI+G3WneMlVYh0WIfov9QnoO03msEhQBUC3qP9bPaac3EAos ltl+876wVOvKLmtPn/6FEYd1e82R5a7vNAbPhwDi/3uQ5uYvNyNxLWkPS99OUxLAwaCc O1kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b5Sow97QC/90E4o81kTQESQdyKKdPqxujB+XQT+2Hz4=; b=AugaNrFCinv7dRW2GwoCINJd6MForZfjqidX/fYFPTJF8uI5Tt/nFbmiWpjWGwJLzC lPwlNYgrts7BNRqO+tMGCaEoYRFwYOLmPabiuLE2CG4JB1vAnGZEkm+wokOhtRx9Ct05 QA7zEmr5ZM1j4xCPYWd1G176Jt6O1m6RwmXn5OFE9b5i4/FjoufE5L4DTaen1r93bKPd 3OBFTwq8VKmtXNDErrJkGcvdQxkjC7cDxJqpiYcApjsxYcA1c2VlTuJuoHEl5DDySnjY C9gZvVH3sygv6XI956Wy8aCOwxbKfIvh8Avb5iww2TyPR76Y42qH7ylYtB8eO3xvWnMP oiwA== X-Gm-Message-State: APjAAAX0BJ5sl+syPSewAwtoZuBz/Up+NJ+hXuzsFQA361MOojU8TbYb pTnsAkj7zK1SUwxKzW9+zRVT1ldBSaKHy2EJbMI= X-Google-Smtp-Source: APXvYqyOtFYwtxwxkHkEvBV9V/29xpKZzEO1oNIXau4JZL+b4Pu5gPdZ9VD2Ayhd2+PYMAYPr/R4uT/VFkqr0iAjMBM= X-Received: by 2002:a02:bb05:: with SMTP id y5mr42428881jan.93.1562173806369; Wed, 03 Jul 2019 10:10:06 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114E203ACC@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E203ACC@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Donald Eastlake Date: Wed, 3 Jul 2019 13:09:55 -0400 Message-ID: To: "STARK, BARBARA H" Cc: Babel at IETF , babel-chairs Content-Type: multipart/alternative; boundary="000000000000ce608f058cc9ee1a" Archived-At: Subject: Re: [babel] Call for presentations to the Babel WG in Montreal later this month X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 17:10:09 -0000 --000000000000ce608f058cc9ee1a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK, I=E2=80=99ll add you to the agenda. Thanks, Donald On Wed, Jul 3, 2019 at 08:45 STARK, BARBARA H wrote: > Hi Donald, > Since I didn't manage to finish up the info model, I would appreciate a > little time to discuss a few things. I intend to post another draft befor= e > the deadline. > Barbara > > > -----Original Message----- > > From: babel On Behalf Of Donald Eastlake > > Sent: Tuesday, July 02, 2019 12:11 PM > > To: Babel at IETF > > Cc: babel-chairs > > Subject: [babel] Call for presentations to the Babel WG in Montreal > later this > > month > > > > Hi, > > > > The Babel WG meeting has been scheduled for 13:50 to 14:50 Wednesday > > July 24th at the IETF Montreal meeting this month. If you would like to > > present, please respond to the chairs or to the WG mailing list. > > There are facilities for presenting remotely if you are unable to atten= d > the > > meeting. > > > > Thanks, > > Donald > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com > > > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.ietf.org_mailman_listinfo_babel&d=3DDwICAg&c=3DLFYZ- > > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > > 8sc8SY8Tq4vrfog&m=3D6YczuxTniFSRgc0soKYn7sCld7IBYf0JilMMj9EJuTo&s=3DNw > > WKOjXei1-6Akd-jrZO_x3OIIEw538Ye7CP1aowHxc&e=3D > --=20 Sent from Gmail Mobile --000000000000ce608f058cc9ee1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, I=E2=80=99ll add you to the agenda.
<= div dir=3D"auto">
Thanks,
Donald

On Wed, Jul 3, 2019 at 08:45 STARK, BARBARA H <bs7652@att.com> wrote:
Hi Donald,
Since I didn't manage to finish up the info model, I would appreciate a= little time to discuss a few things. I intend to post another draft before= the deadline.
Barbara

> -----Original Message-----
> From: babel <babel-bounces@ietf.org> On Behalf Of Donald Eastlake
> Sent: Tuesday, July 02, 2019 12:11 PM
> To: Babel at IETF <babel@ietf.org>
> Cc: babel-chairs <babel-chairs@ietf.org>
> Subject: [babel] Call for presentations to the Babel WG in Montreal la= ter this
> month
>
> Hi,
>
> The Babel WG meeting has been scheduled for 13:50 to 14:50 Wednesday > July 24th at the IETF Montreal meeting this month. If you would like t= o
> present, please respond to the chairs or to the WG mailing list.
> There are facilities for presenting remotely if you are unable to atte= nd the
> meeting.
>
> Thanks,
> Donald
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
>=C2=A0 Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
>=C2=A0 1424 Pro Shop Court, Davenport, FL 33896 USA=C2=A0 d3e3e3@gmail.com
>
> _______________________________________________
> babel mailing list
> babel@ietf.org=
> https://urldefense.proofpoint.com/v2/url?u= =3Dhttps-
> 3A__www.ietf.org_mailman_listinfo_babel&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC-
> 8sc8SY8Tq4vrfog&m=3D6YczuxTniFSRgc0soKYn7sCld7IBYf0JilMMj9EJuTo&am= p;s=3DNw
> WKOjXei1-6Akd-jrZO_x3OIIEw538Ye7CP1aowHxc&e=3D
--
Sent from Gmail Mobile
--000000000000ce608f058cc9ee1a-- From nobody Fri Jul 5 05:32:28 2019 Return-Path: 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 C07551201A8 for ; Fri, 5 Jul 2019 05:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 WYGJeMpmfIfy for ; Fri, 5 Jul 2019 05:32:25 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5BCE120183 for ; Fri, 5 Jul 2019 05:32:24 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id v24so9104470ljg.13 for ; Fri, 05 Jul 2019 05:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+LGtWdpc/Kdy7VzeVVwWW/1VN9oQLoX7i/SGdOxgTf0=; b=OqZGEbRflxNuYdTutDaFyiKrmo7MH7QogvQvGXh/CMGIJBexbxsoy4aJm4pmecb0AT iJSKYCt8gSPA/Ij7xj1KDs6Bszjv7DMCPon7JJGS0H+J5wqa9YNAojxbcv4amESynD1J dnb1lrI+xF9CeH/GL14Ud9d/9x/kqoisJXLDmVpFk95lEpX5uifXpuLZCIP/CViT7rmP ankhW7NBE68fMV8KiLO23L7zCe62VJvLAqvhZ2LDiUNcs9C/8AWT3h94eS35VisQwMH/ 8z2ZJW9vAo/3DzaAM5nqh1LiNOutAfy2adg9oFsZpxUZ7ndOU73mIGjWI+XHaakwvugc GDng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+LGtWdpc/Kdy7VzeVVwWW/1VN9oQLoX7i/SGdOxgTf0=; b=W8f0LfKEq/F5fPt3HarwzEpvjRcyHk3zKab8OUKZSpOsPDJ2SWPAIPR5A7HYVtS1su zPHYZmTVYaN1BRl+85+moJXM3l/O8IqSWwMYe1LPZfFVlxI84HgWEnwS3Ikcgh4za4KR rqowqUweFk1AXtoO1ZFFCiAwLKIDCKRaYUK4Qvj3V3CYaLVj8G+jABt1l3aWOdSEmiK3 ZOZ0mIK3zGVFYy+ovjxrJqiLQeJYMZpfVKTAKxndpVSoYDaR2pz9SyCUYeAcVaoxV2jH DUUfL11m5uYKxYLvMw50PS2/tx7oikc6932b+goWHNqBM/BCw/tfcUHYrvADoaaVzKPo mv5w== X-Gm-Message-State: APjAAAWibre1FTJA56oqxvQy+/1ovI5AycwtPIQ8k/QeY0nz82Dk6p77 gOPuaPsl5231zePTY7M3mmN8xAb358MrlZTLy/8= X-Google-Smtp-Source: APXvYqz73cs3EIMbL2brbO8o8s6MhO/gvLVeuXsusM/5XcAPajSPLdDwxgI99txI8ELAeMVJmRsbXH1zcPqsNB/UV6I= X-Received: by 2002:a2e:8802:: with SMTP id x2mr2021396ljh.200.1562329942914; Fri, 05 Jul 2019 05:32:22 -0700 (PDT) MIME-Version: 1.0 References: <156105440578.3118.4917846383408119793.idtracker@ietfa.amsl.com> <9C5FD3EFA72E1740A3D41BADDE0B461FCFC76069@DGGEMM528-MBX.china.huawei.com> In-Reply-To: <9C5FD3EFA72E1740A3D41BADDE0B461FCFC76069@DGGEMM528-MBX.china.huawei.com> From: Henning Rogge Date: Fri, 5 Jul 2019 14:31:56 +0200 Message-ID: To: "Yemin (Amy)" , antonin.decimo@gmail.com, dschinazi.ietf@gmail.com, jch@irif.fr Cc: Martin Vigoureux , =?UTF-8?Q?LucAndr=C3=A9_Burdet?= , babel@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] rtgdir Last Call Review requested: draft-ietf-babel-dtls X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 12:32:27 -0000 Hi, I was asked by the Routing Directorate to do a last call review of draft-ietf-babel-dtls-06. I like that the draft is quite short, which is a good thing for a security draft. I have found a few question you can consider to address in the final document. Chapter 2.3: I wonder if using DTLS protected unicast Hellos should be mandatory... using unprotected multicast to determine bidirectional reachability looks like a good way to do a cheap denial of service attack. Chapter 2.5: What happens when a node starts a new DTLS connection and there is already one in the neighbor table? This could both be an attempt to attack Babel, a reboot of a node or just a matter of misconfiguration of two nodes. Chapter 3: Different pairs of nodes could select different ciphers, resulting in different MTUs. I assume this is no problem for Babel (could be mentioned in the chapter). Some of the design decisions of regarding the three questions could be mentioned in chapter 5 (Security Implications). Henning Rogge From nobody Fri Jul 5 05:49:37 2019 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26359120094; Fri, 5 Jul 2019 05:49:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Min Ye via Datatracker To: Cc: draft-ietf-babel-dtls.all@ietf.org, ietf@ietf.org, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Min Ye Message-ID: <156233097510.22018.7107165165922007078@ietfa.amsl.com> Date: Fri, 05 Jul 2019 05:49:35 -0700 Archived-At: Subject: [babel] Rtgdir last call review of draft-ietf-babel-dtls-06 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 12:49:35 -0000 Reviewer: Henning Rogge Review result: Has Issues //resend to RTG DIR list Hi, I was asked by the Routing Directorate to do a last call review of draft-ietf-babel-dtls-06. I like that the draft is quite short, which is a good thing for a security draft. I have found a few question you can consider to address in the final document. Chapter 2.3: I wonder if using DTLS protected unicast Hellos should be mandatory... using unprotected multicast to determine bidirectional reachability looks like a good way to do a cheap denial of service attack. Chapter 2.5: What happens when a node starts a new DTLS connection and there is already one in the neighbor table? This could both be an attempt to attack Babel, a reboot of a node or just a matter of misconfiguration of two nodes. Chapter 3: Different pairs of nodes could select different ciphers, resulting in different MTUs. I assume this is no problem for Babel (could be mentioned in the chapter). Some of the design decisions of regarding the three questions could be mentioned in chapter 5 (Security Implications). Henning Rogge From nobody Fri Jul 5 18:21:16 2019 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED5C1200F7; Fri, 5 Jul 2019 18:21:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156237607432.21753.18227319541463187561@ietfa.amsl.com> Date: Fri, 05 Jul 2019 18:21:14 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-dtls-07.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 01:21:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : Babel Routing Protocol over Datagram Transport Layer Security Authors : Antonin Decimo David Schinazi Juliusz Chroboczek Filename : draft-ietf-babel-dtls-07.txt Pages : 9 Date : 2019-07-05 Abstract: The Babel Routing Protocol does not contain any means to authenticate neighbours or protect messages sent between them. This document specifies a mechanism to ensure these properties, using Datagram Transport Layer Security (DTLS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-dtls-07 https://datatracker.ietf.org/doc/html/draft-ietf-babel-dtls-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-dtls-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 5 18:21:27 2019 Return-Path: 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 09CA8120122 for ; Fri, 5 Jul 2019 18:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zbdqou5OoFIm for ; Fri, 5 Jul 2019 18:21:14 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EBD51200EC for ; Fri, 5 Jul 2019 18:21:14 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id u10so7321452lfm.12 for ; Fri, 05 Jul 2019 18:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BtQr1X1oHCcxfwBKzMUPa5ytHAzL1dK70SNpfDAFMjg=; b=s8yMXgmx88Frg7kNoB1AUTBOITeuNYOf7U9RAxT/kbxDXDDUiCwXt9rXg6SUA51h3E d2FlBWKr8BQNsq7+6bIhK9Qqwh0mXke2orku9gwGuPE6olHab3OBl3OVF1dq/hOtgmTV 7x7OFYxhxUzuVzaCzKznf3nR4KcTRjc8wucV+Qe69ANKYJh+Mksx0BysWL0PQelmVC8T us18c1yqmtCKlpm2yKNVQDlvcsfyXO+ML6Qgb8zR6aat/xRR6/P5rps8QpN+Ln+DRa0e LLqpOV90Ccya8mSx6ufFcjWoDhJmXz21xi+INjEi3tzeiIZ/pTpcYx+JbtdPrtGAGyTl DkVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BtQr1X1oHCcxfwBKzMUPa5ytHAzL1dK70SNpfDAFMjg=; b=PZ3qATUlP1gGD4MqL/+c/Pu6+6ohvKHyRA0tfff797Gu8kAli+JceVVDiF5No29RQ9 dx9qwj2oU1YYNOAngQCzmRd7pXKyFx/Fa8bQWGpC8Lb3iaCyoqYh+2hMEDVxfO5gU2o/ D9x6pjAjmQN1SNWlQONGoBD1xZGTW4T04HGfPKqLi5zZWOqprjMXcxgrjLAAtVtOba/v QLo4+F9o9+xb9gtKrswQkFiBdaY3ZLKst+1aC7+RHejIXFdh8ZYntcj9r6TJpcj93u5v um2L7/3sBdKzByuMOjjHk/H705QLX/7LWui0c+zsCOKKzWXMHv0abHQOtyscIZ6QUwsV +1XA== X-Gm-Message-State: APjAAAXk1ZKrFqyBa7MHZEIpkXLAwF1D8tD73l9zm7QvBodzJHe/7Glj dPnGt5fJW8Sx+8qOEZrUK3sxX3JWp/EP37LAwho= X-Google-Smtp-Source: APXvYqzVk+8ksS4bBAtvriEmLG7hJG6bprcpWJwylgQ8zXRo/ZOKFG1KROBEjhr9tGl92JF8rN5Vs4MVnSqTY/cB6vY= X-Received: by 2002:ac2:514b:: with SMTP id q11mr3287047lfd.33.1562376072586; Fri, 05 Jul 2019 18:21:12 -0700 (PDT) MIME-Version: 1.0 References: <156105440578.3118.4917846383408119793.idtracker@ietfa.amsl.com> <9C5FD3EFA72E1740A3D41BADDE0B461FCFC76069@DGGEMM528-MBX.china.huawei.com> In-Reply-To: From: David Schinazi Date: Fri, 5 Jul 2019 18:21:01 -0700 Message-ID: To: Henning Rogge Cc: "Yemin (Amy)" , =?UTF-8?Q?Antonin_D=C3=A9cimo?= , Juliusz Chroboczek , Martin Vigoureux , =?UTF-8?Q?LucAndr=C3=A9_Burdet?= , Babel at IETF Content-Type: multipart/alternative; boundary="000000000000cfea0f058cf9062b" Archived-At: Subject: Re: [babel] rtgdir Last Call Review requested: draft-ietf-babel-dtls X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 01:21:19 -0000 --000000000000cfea0f058cf9062b Content-Type: text/plain; charset="UTF-8" Hi Henning, and thank you for your review. Responses inline. On Fri, Jul 5, 2019 at 5:32 AM Henning Rogge wrote: > > Chapter 2.3: > I wonder if using DTLS protected unicast Hellos should be mandatory... > using unprotected multicast to determine bidirectional reachability > looks like a good way to do a cheap denial of service attack. > In Babel, bidirectional reachability is established using both Hellos and IHUs. We explicitly require DTLS protection for IHUs to prevent an attacker from tricking you into thinking you have bidirectional reachability. This reduces the protocol's attack surface by limiting what an attacker can do. Unicast Hellos are protected by the rule that all unicast traffic must be protected by DTLS. This is also there to reduce attack surface. DTLS itself contains mechanisms to prevent denial of service attacks (see section 4.2.1 of RFC 6347), and it is good practice for us to use those instead of coming up with our own. > Chapter 2.5: > What happens when a node starts a new DTLS connection and there is > already one in the neighbor table? This could both be an attempt to > attack Babel, a reboot of a node or just a matter of misconfiguration > of two nodes. > There is no reason for a node to initiate a DTLS connection if it already has one to the neighbor in question. However, you're right that receiving a new connection when we already have one wasn't explicitly discussed. I've added a sentence to Section 2.1: If a node receives a new DTLS connection from a neighbour to whom it already has a connection, the node MUST NOT discard the older connection until it has completed the handshake of the new one and validated the identity of the peer. > Chapter 3: > Different pairs of nodes could select different ciphers, resulting in > different MTUs. I assume this is no problem for Babel (could be > mentioned in the chapter). > Good point. I've added this text to section 3: Note that distinct DTLS connections can use different ciphers, which can have different amounts of overhead per packet. Therefore, the MTU to one neighbour can be different from the MTU to another neighbour on the same link. The changes above are reflected in draft -07. Thanks, David --000000000000cfea0f058cf9062b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Henning, and thank you for your review= . Responses inline.

On Fri, Jul 5, 2019 at 5:32 AM Henning Rogge <hrogge@gmail.com> wrote:

Chapter 2.3:
I wonder if using DTLS protected unicast Hellos should be mandatory...
using unprotected multicast to determine bidirectional reachability
looks like a good way to do a cheap denial of service attack.

In Babel, bidirectional reachability is established = using both Hellos and IHUs.
We explicitly require DTLS protection= for IHUs to prevent an attacker
from tricking you into thinking = you have bidirectional reachability.
This reduces the protocol= 9;s attack surface by limiting what an attacker can do.

Unicast Hellos are protected by the rule that all unicast traffic mus= t be
protected by DTLS. This is also there to reduce attack surfa= ce.

DTLS itself contains mechanisms to prevent den= ial of service attacks
(see section 4.2.1 of RFC 6347), and it is= good practice for us to use
those instead of coming up with our = own.
=C2=A0
Chapter 3:
Different pairs of nodes could select different ciphers, resulting in
different MTUs. I assume this is no problem for Babel (could be
mentioned in the chapter).

Good point. = I've added this text to section 3:
=C2=A0 =C2=A0 Note that di= stinct DTLS connections can use different ciphers, which can
=C2=A0 =C2= =A0 have different amounts of overhead per packet.=C2=A0 Therefore, the MTU= to one
=C2=A0 =C2=A0 neighbour can be different from the MTU to another= neighbour on the same link.

The changes above= are reflected in draft -07.

Thanks,
Dav= id
--000000000000cfea0f058cf9062b-- From nobody Sun Jul 7 05:15:46 2019 Return-Path: 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 5FADF12007C for ; Sun, 7 Jul 2019 05:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 ShFL1gbLCVZ7 for ; Sun, 7 Jul 2019 05:15:42 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 30A5012009C for ; Sun, 7 Jul 2019 05:15:41 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x67CFSbm031600; Sun, 7 Jul 2019 14:15:28 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5E6B66F54D; Sun, 7 Jul 2019 14:15:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id xnAJdcTTLSuZ; Sun, 7 Jul 2019 14:15:30 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3A4896F54B; Sun, 7 Jul 2019 14:15:29 +0200 (CEST) Date: Sun, 07 Jul 2019 14:15:29 +0200 Message-ID: <87bly6vy5a.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Henning Rogge , "Yemin (Amy)" , Antonin =?ISO-8859-1?Q?D=E9cimo?= , Martin Vigoureux , =?ISO-8859-1?Q?LucAndr=E9?= Burdet , Babel at IETF In-Reply-To: References: <156105440578.3118.4917846383408119793.idtracker@ietfa.amsl.com> <9C5FD3EFA72E1740A3D41BADDE0B461FCFC76069@DGGEMM528-MBX.china.huawei.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 07 Jul 2019 14:15:29 +0200 (CEST) X-Miltered: at korolev with ID 5D21E260.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D21E260.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D21E260.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] rtgdir Last Call Review requested: draft-ietf-babel-dtls X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 12:15:44 -0000 > I wonder if using DTLS protected unicast Hellos should be mandatory... > using unprotected multicast to determine bidirectional reachability > looks like a good way to do a cheap denial of service attack. > In Babel, bidirectional reachability is established using both Hellos and IHUs. > We explicitly require DTLS protection for IHUs to prevent an attacker > from tricking you into thinking you have bidirectional reachability. > This reduces the protocol's attack surface by limiting what an attacker can do. I think David's answer is clear, but I'll insist some more, since this is an important point (and we got it wrong in an earlier draft). In Babel, the equivalent of an OSPF Hello is a pair of Hello (establishes reverse reachability) and IHU (establishes direct reachability). Bidirectional reachability is only established after a successful Hello/IHU exchange. In cleartext Babel, both Hellos and IHUs can be sent over either multicast or unicast. In DTLS-protected Babel, Hellos can be sent over either (unprotected) multicast or (protected) unicast, while IHUs can only be sent over (protected) unicast and are silently ignored if sent over multicast. Hence, bidirectional reachability requires a protected IHU to be received. -- Juliusz From nobody Sun Jul 7 07:23:31 2019 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0020120018; Sun, 7 Jul 2019 07:23:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156250940970.14265.708414558208219070@ietfa.amsl.com> Date: Sun, 07 Jul 2019 07:23:29 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-applicability-07.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 14:23:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : Applicability of the Babel routing protocol Author : Juliusz Chroboczek Filename : draft-ietf-babel-applicability-07.txt Pages : 11 Date : 2019-07-07 Abstract: Babel is a routing protocol based on the distance-vector algorithm augmented with mechanisms for loop avoidance and starvation avoidance. In this document, we describe a number of niches where Babel has been found to be useful and that are arguably not adequately served by more mature protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-applicability/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-applicability-07 https://datatracker.ietf.org/doc/html/draft-ietf-babel-applicability-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-applicability-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 7 07:26:20 2019 Return-Path: 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 D2522120048; Sun, 7 Jul 2019 07:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 XDRDL9y_RSON; Sun, 7 Jul 2019 07:26:17 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 5F8F8120018; Sun, 7 Jul 2019 07:26:17 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x67EQCgP031336; Sun, 7 Jul 2019 16:26:12 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 524046FA11; Sun, 7 Jul 2019 16:26:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id FbMjHlwGv_O4; Sun, 7 Jul 2019 16:26:14 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 62DF16FA0F; Sun, 7 Jul 2019 16:26:14 +0200 (CEST) Date: Sun, 07 Jul 2019 16:26:13 +0200 Message-ID: <878st9x6nu.wl-jch@irif.fr> From: Juliusz Chroboczek To: Joel Halpern Cc: , ietf@ietf.org, babel@ietf.org, draft-ietf-babel-applicability.all@ietf.org In-Reply-To: <156142508331.17776.2290417666551756858@ietfa.amsl.com> References: <156142508331.17776.2290417666551756858@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 07 Jul 2019 16:26:12 +0200 (CEST) X-Miltered: at korolev with ID 5D220104.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D220104.003 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D220104.003 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Genart last call review of draft-ietf-babel-applicability-06 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 14:26:19 -0000 Dear Joel, Thank you very much for your kind review. > Nits/editorial comments: > In section 2.2, in talking about "metric M", if I have understood properly, > I think it would be clearer if you referred to "metric value M". This section has been expanded with human-readable text and a reference to a research paper, and should therefore now be easier to understand. I have, however, decided to follow the usual style of mathematical writing, and have therefore chosen not to follow your advice. I hope that is okay. Thanks again, -- Juliusz From nobody Sun Jul 7 07:31:44 2019 Return-Path: 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 EFC4612003E; Sun, 7 Jul 2019 07:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 BEXSHnGLIy2F; Sun, 7 Jul 2019 07:31:40 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 B2006120048; Sun, 7 Jul 2019 07:31:39 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x67EVYSa000749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 7 Jul 2019 16:31:34 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x67EVY4X024514; Sun, 7 Jul 2019 16:31:34 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 144046FA51; Sun, 7 Jul 2019 16:31:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 3SeBjQOAMoKi; Sun, 7 Jul 2019 16:31:35 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A9F686FA4E; Sun, 7 Jul 2019 16:31:34 +0200 (CEST) Date: Sun, 07 Jul 2019 16:31:34 +0200 Message-ID: <877e8tx6ex.wl-jch@irif.fr> From: Juliusz Chroboczek To: Alexander Vainshtein Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-babel-applicability.all@ietf.org" , "babel@ietf.org" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sun, 07 Jul 2019 16:31:34 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 07 Jul 2019 16:31:35 +0200 (CEST) X-Miltered: at korolev with ID 5D220246.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D220246.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D220246.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D220246.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D220246.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D220246.002 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] RtgDir review: draft-ietf-babel-applicability-06 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 14:31:42 -0000 Dear Sasha, Thank you very much for your review, which has helped me improve the document. > 1. The text in Section 2.3 says: “in order to check the interoperability > of two implementations of Babel, it is enough to verify that the interaction of > the two does not violate the protocol's assumptions.†This has been fixed. > 2. The explanation of the BABEL base assumptions in Section 2.2. is very > useful. However, it assumes that the reader has at least some intuitive > understanding of the “routing algebra†notations. This has been expanded with human-readable comments, and I've added a reference to my favourite paper on the subject (Griffin and Sobrinho, "Metarouting"). > 3. The draft mentions 4 independent implementations of BABEL in Section > 2.1, but does not say anything about their interoperability. Such information, > if available, should be very useful for the readers. (If no such information is > available as of this moment, I would accept this) I have simply added the word "interoperable" to the sentence, which reflects what the authors of the implementations have reported to me. > 4. The comparison between BABEL and IS-IS/OSPF in Section 2.4.1 lacks > information about possibility of fast local protection mechanisms (a.k.a. IP > FRR, see, e.g., RFC 5286) This is an interesting question, and I need to go educate myself on the subject. I didn't add anything on this subject. > 1. I did not run the nits check on the draft I have. > 2. I think that the work “argue†in the text in Section 1 “we argue that > there exist niches where Babel is useful and that are not adequately served by > more mature protocols†is by far too weak (or too modest?). From my POV the > draft goes far beyond arguing. We now *describe* a few niches that are *arguably* not adequately served. Thanks again, -- Juliusz From nobody Sun Jul 7 07:38:54 2019 Return-Path: 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 BCF0C120058; Sun, 7 Jul 2019 07:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 DIfkftXXa4Lb; Sun, 7 Jul 2019 07:38:51 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 5564A12001E; Sun, 7 Jul 2019 07:38:51 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x67Eckp9003130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 7 Jul 2019 16:38:46 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x67Eck9Y026261; Sun, 7 Jul 2019 16:38:47 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 39BDF6FADB; Sun, 7 Jul 2019 16:38:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 1uY5Wb71rl2Z; Sun, 7 Jul 2019 16:38:48 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3B4A86FAD9; Sun, 7 Jul 2019 16:38:48 +0200 (CEST) Date: Sun, 07 Jul 2019 16:38:48 +0200 Message-ID: <875zodx62v.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mike McBride Cc: , draft-ietf-babel-hmac.all@ietf.org, babel@ietf.org In-Reply-To: <156210426145.23799.16215559699319611305@ietfa.amsl.com> References: <156210426145.23799.16215559699319611305@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sun, 07 Jul 2019 16:38:46 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 07 Jul 2019 16:38:47 +0200 (CEST) X-Miltered: at korolev with ID 5D2203F6.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D2203F6.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D2203F6.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D2203F6.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D2203F6.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D2203F6.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Rtgdir last call review of draft-ietf-babel-hmac-07 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 14:38:53 -0000 Dear Mike, I do not recall whether I've already replied to your review, sorry if this is a duplicate. > I still think a terminology section would be helpful in this, and most, > ietf drafts but the authors did a good job of defining acronyms > throughout the draft. There are two common styles -- define each term on first use, or provide a terminology section. I happen to prefer the former style, you obviously prefer the latter. With your kind permission, I am going to stick to my preferred style, and therefore not follow your advice. Thanks, -- Juliusz From nobody Sun Jul 7 07:48:42 2019 Return-Path: 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 87D1612001E; Sun, 7 Jul 2019 07:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 0U0j-RvqEHAj; Sun, 7 Jul 2019 07:48:39 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 B382F120048; Sun, 7 Jul 2019 07:48:38 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x67EmXfU005852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 7 Jul 2019 16:48:33 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x67EmXGs028162; Sun, 7 Jul 2019 16:48:33 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 2323C6FB27; Sun, 7 Jul 2019 16:48:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id W7tGCly8L7tn; Sun, 7 Jul 2019 16:48:34 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C87FF6FB25; Sun, 7 Jul 2019 16:48:34 +0200 (CEST) Date: Sun, 07 Jul 2019 16:48:34 +0200 Message-ID: <8736jhx5ml.wl-jch@irif.fr> From: Juliusz Chroboczek To: Alexander Vainshtein Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-babel-applicability.all@ietf.org" , "babel@ietf.org" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sun, 07 Jul 2019 16:48:33 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 07 Jul 2019 16:48:33 +0200 (CEST) X-Miltered: at korolev with ID 5D220641.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D220641.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D220641.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D220641.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D220641.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D220641.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] RtgDir review: draft-ietf-babel-applicability-06 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 14:48:41 -0000 I forgot one of your points. > 5. Last but not least, a few words about manageability of BABEL would be > useful IMHO. People are working hard on monitoring and manageability: - Barbara Stark and Mahesh Jethanandani are working on manageability within the IETF framework; - Nexedi are working on dynamic reconfiguration of interfaces by an external cross-layer (2->3) monitoring agent; - a number of people are working on monitoring, both by a human operator and by an external software agent: https://github.com/kerneis/babelweb https://github.com/Vivena/babelweb2 https://github.com/tcatm/mmfd However, none of this work is finished yet, and, given the wide range of application domains of Babel, I do not feel comfortable to give any definite advice about management. I have therefore decided not to say anything in this document. -- Juliusz From nobody Sun Jul 7 07:52:23 2019 Return-Path: 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 9C891120058; Sun, 7 Jul 2019 07:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 u-_ExgRFPnvo; Sun, 7 Jul 2019 07:52:19 -0700 (PDT) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.1]) (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 A9B2F12001E; Sun, 7 Jul 2019 07:52:18 -0700 (PDT) Received: from [85.158.142.101] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-a.eu-central-1.aws.symcld.net id F1/2E-10067-E17022D5; Sun, 07 Jul 2019 14:52:14 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEJsWRWlGSWpSXmKPExsUi9LZng64cu1K sQddLVovNHRvYLLYs6maxOPnf2WJ+6zI2i5NzfjBbLFjzlN2BzaPlyFtWjyVLfjJ5LN7yljGA OYo1My8pvyKBNWPy4mPsBcv5Kt7u6mBvYHzF3cXIxcEisJZZYuPmnYwgjpBAP5PE9OcX2CCcO 4wSrz7eAHI4OdgEbCU2rb4LZosIqEgsn/aMHaSIWeATo8SPvxvZQRLCQEWPr+5mgSiyk1i08C 4ThG0l8fzDPLA4C1Dzj+8djCA2r0CsxJaDLWBDhQSqJCZPnwlWzymgIfHi3nywGkYBMYnvp9a AxZkFxCVuPZkPZksICEgs2XOeGcIWlXj5+B8rRH2SxP2nCxkh4ooSM+7NYYewZSUuze+GivtK 3FvWA2RzANnKEltexIL8IiHwmFHiY8tKqJlaEmfv7IaypSQWnv8CNSdH4s16iF8kBNQktl87D 3WPjMS2Lx/YIAbNY5N4/amFHeKxZIkTcz5DNchJrOp9yAJRdIFZ4tG+H0wTGHVnIXkOwtaRWL D7ExuErS2xbOFr5lngABOUODnzCcsCRpZVjBZJRZnpGSW5iZk5uoYGBrqGhsa6RrqmxnqJVbq JeqmlusmpeSVFiUBJvcTyYr3iytzknBS9vNSSTYzAJJVSyGS6g7F31hu9Q4ySHExKorwhqfKx QnxJ+SmVGYnFGfFFpTmpxYcYZTg4lCR4c1mVYoUEi1LTUyvSMnOACRMmLcHBoyTCKwuS5i0uS MwtzkyHSJ1itOSY8HLuImaOn7eXAMnmO0BSiCUvPy9VSpw3HKRBAKQhozQPbhwsqV9ilJUS5m VkYGAQ4ilILcrNLEGVf8UozsGoJMybCTKFJzOvBG7rK6CDmIAOmpkiB3JQSSJCSqqBKfvV9T0 GP0UaDizZwWmjaHzvVPcW671X1hm5HXBke/T6C7ds2cp/d360bPK0OmbM6l7945FDQcnuW784 pRue7F90OeYlg9TTC/1a3DYqRT9CT/6ouTkr3ya09h5n0+aMb/kZi5UeKMaLV/9R8fzixvKie eXuor51jpdyumWWXDyz3We/GWP7RI3K7X7dj+rUH+w8/e90A3d4/mfhuNSPYZNFowr/tvLYpM 5sdvWObPhtOYdvb2K6waardRHFh5vLnuS9FPmx0ezP310eH1r27Pwx/9mUqCIv5pTM9xe/nOX 1SN54PGrjlMmTV6muOjs1bnMXL9uCTQ67I925+jW32jzqW22XuDe966NeQUrKHCWW4oxEQy3m ouJEADX9DBNlBAAA X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-31.tower-226.messagelabs.com!1562511131!114094!1 X-Originating-IP: [18.237.140.176] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.43.9; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 9794 invoked from network); 7 Jul 2019 14:52:13 -0000 Received: from ec2-18-237-140-176.us-west-2.compute.amazonaws.com (HELO mail.ds.dlp.protect.symantec.com) (18.237.140.176) by server-31.tower-226.messagelabs.com with ECDHE-RSA-AES256-SHA384 encrypted SMTP; 7 Jul 2019 14:52:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ECI365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xpWO+x1q+LapCHzw8+mqrXqS157KaoJIYE2yi8vpaho=; b=WRpnf20aePKCwztk+cjZKYcGYJqxVJZrjg/kKmG4vOWQJB0wmvjc9gtlw5td9O+fbOshETg7rNgLSUlH8S4Ys9xRyg4IXM83sIVkAhY+bzHKDNzI6cumxXN3KbRXMUuk0OjC+xJ61HIpP2VXCiJEdlrkUoBzq9jX7f+C/sy5Lns= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB5825.eurprd03.prod.outlook.com (10.255.28.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Sun, 7 Jul 2019 14:52:09 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::29f2:7c6:37cb:8ea7]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::29f2:7c6:37cb:8ea7%3]) with mapi id 15.20.2052.019; Sun, 7 Jul 2019 14:52:09 +0000 From: Alexander Vainshtein To: Juliusz Chroboczek CC: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-babel-applicability.all@ietf.org" , "babel@ietf.org" , Min Ye Thread-Topic: RtgDir review: draft-ietf-babel-applicability-06 Thread-Index: AdUvH5YiygIfUsyWQTGhUP+K9gfY2QFs3b4AAAAHhHA= Date: Sun, 7 Jul 2019 14:52:08 +0000 Message-ID: References: <8736jhx5ml.wl-jch@irif.fr> In-Reply-To: <8736jhx5ml.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a8a2e8b1-30af-4482-1886-08d702eaafc8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR03MB5825; x-ms-traffictypediagnostic: AM0PR03MB5825: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0091C8F1EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39860400002)(376002)(136003)(346002)(189003)(199004)(13464003)(186003)(25786009)(53936002)(14454004)(486006)(66066001)(7736002)(72206003)(55016002)(6916009)(26005)(86362001)(476003)(11346002)(305945005)(4326008)(478600001)(8936002)(8676002)(229853002)(9686003)(413944005)(966005)(6306002)(74316002)(316002)(54906003)(71190400001)(33656002)(2906002)(71200400001)(256004)(6436002)(81156014)(66476007)(5660300002)(6116002)(6506007)(3846002)(76116006)(52536014)(102836004)(53546011)(7696005)(64756008)(73956011)(99286004)(81166006)(68736007)(66556008)(66446008)(446003)(6246003)(66946007)(76176011); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB5825; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 2V5OqYRk5/Ai9/zehMX4H594E9xVh688ce9kS6KNzYqTLg4WgL7r7d2INs+p+WlyPpWPudOpp/1BAzZbhYz7uGl7zjx0zee8Bfm3lAYH0EJIOveX6wtgdFvbxZZOJK6t/t/HtIIBLfhj/ZDePeO1bBL6hseJLu8bmKqzQ4K1pT+jQXXwHPdnGk11xPOlXwFDAOnU8vbQL0HRKEpBtTyylc56qzVVS5v9K+YcRN1xFKL4GC7qX5cOlG8DRhofC7mjt3Nbvbk4cb2Z+pIZo021cYZOkQpnF+xy94v8zE8xVh5nPqj9KCjt/JvjOgTwxoOwZ0+qGhjWNpwzKJis60ckuCobT7tLQE3+GifzvowNyRcM+BmgaXpD+fZjet7/oqtSMSVq9NSnuYDD+ZZowEeuFBgz38vJccOFiaA+CPIEEpE= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: a8a2e8b1-30af-4482-1886-08d702eaafc8 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2019 14:52:09.0174 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: alexvain@ecitele.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB5825 X-CFilter-Loop: Reflected X-DetectorID-Processed: d8d3a2b3-1594-4c39-92fb-b8312fe65a8a Archived-At: Subject: Re: [babel] RtgDir review: draft-ietf-babel-applicability-06 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 14:52:22 -0000 Dear Juliusz, Lots of thanks for addressing my review comments so quickly. I have looked up the -07 version and it addresses my review comments to th= e maximum possible extent. In particular, I accept the fact that my question about fast local protect= ion with BABEL cannot be answered without additional investigation: such i= nvestigation is clearly not part of the applicability draft. And I also accept the fact that management aspects of BABEL are still work= in progress. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Juliusz Chroboczek =20 Sent: Sunday, July 7, 2019 5:49 PM To: Alexander Vainshtein Cc: rtg-ads@ietf.org; rtg-dir@ietf.org; draft-ietf-babel-applicability.all= @ietf.org; babel@ietf.org Subject: Re: RtgDir review: draft-ietf-babel-applicability-06 I forgot one of your points. > 5. Last but not least, a few words about manageability of BABEL wo= uld be > useful IMHO.=20 People are working hard on monitoring and manageability: - Barbara Stark and Mahesh Jethanandani are working on manageability within the IETF framework; - Nexedi are working on dynamic reconfiguration of interfaces by an external cross-layer (2->3) monitoring agent; - a number of people are working on monitoring, both by a human operator= and by an external software agent: https://github.com/kerneis/babelweb https://github.com/Vivena/babelweb2 https://github.com/tcatm/mmfd However, none of this work is finished yet, and, given the wide range of a= pplication domains of Babel, I do not feel comfortable to give any definit= e advice about management. I have therefore decided not to say anything i= n this document. -- Juliusz __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ From nobody Sun Jul 7 08:06:22 2019 Return-Path: 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 28E6B120026; Sun, 7 Jul 2019 08:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 0y-ipLcIRUbl; Sun, 7 Jul 2019 08:06:11 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 3BF9012001E; Sun, 7 Jul 2019 08:06:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 45hX366p19z1Y21X; Sun, 7 Jul 2019 08:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1562511970; bh=mIeihTmDrjwOCtRhLYwj7lnf9Qj+40xfijtYOOV3H4g=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Ut3LbZIln6sz1EiTqJYGkIwvWDi1xBNeLQKxt+Q49KlJvs4s+fvUKYU9yc6aL9RW4 FuzxNaTQnkUU4NDUJJ5+qUn4Mizvs3eJQsJmYn8TPSfh8ddArXO29sAZmsoA5eGJSv kMPjtb8pWH5TriyzwnEMtRIPMsiU6x3pzjE8b8gg= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 45hX320bD4zKxM8; Sun, 7 Jul 2019 08:06:05 -0700 (PDT) To: Juliusz Chroboczek Cc: gen-art@ietf.org, ietf@ietf.org, babel@ietf.org, draft-ietf-babel-applicability.all@ietf.org References: <156142508331.17776.2290417666551756858@ietfa.amsl.com> <878st9x6nu.wl-jch@irif.fr> From: Joel Halpern Direct Message-ID: <444a37f8-52a0-eb7f-18d3-b8edb2eaabfd@joelhalpern.com> Date: Sun, 7 Jul 2019 11:06:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <878st9x6nu.wl-jch@irif.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [babel] Genart last call review of draft-ietf-babel-applicability-06 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 15:06:13 -0000 I do not consider this a show-stopper (I listed it as a nit / editorial), but at least the -07 text does not look better in this regard. In my experience, if this were indeed mathematics, one would talk about a metric (how one measures) and a distance (the result of applying the measure. E.g. Given two points in a metric space, with a distance between them of d, ... Or more verbosely, given a space with a metric M, the distance between two points a and b is M(A, b). Yours, Joel On 7/7/19 10:26 AM, Juliusz Chroboczek wrote: > Dear Joel, > > Thank you very much for your kind review. > >> Nits/editorial comments: >> In section 2.2, in talking about "metric M", if I have understood properly, >> I think it would be clearer if you referred to "metric value M". > > This section has been expanded with human-readable text and a reference to > a research paper, and should therefore now be easier to understand. > I have, however, decided to follow the usual style of mathematical > writing, and have therefore chosen not to follow your advice. I hope that > is okay. > > Thanks again, > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > From nobody Sun Jul 7 08:35:09 2019 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A961120135; Sun, 7 Jul 2019 08:35:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156251370028.14572.13763020213427103268@ietfa.amsl.com> Date: Sun, 07 Jul 2019 08:35:00 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-hmac-08.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 15:35:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : HMAC authentication for the Babel routing protocol Authors : Clara Do Weronika Kolodziejak Juliusz Chroboczek Filename : draft-ietf-babel-hmac-08.txt Pages : 20 Date : 2019-07-07 Abstract: This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance. This document obsoletes RFC 7298. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-hmac/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-hmac-08 https://datatracker.ietf.org/doc/html/draft-ietf-babel-hmac-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-hmac-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 7 08:44:02 2019 Return-Path: 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 9995012009C for ; Sun, 7 Jul 2019 08:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 Snz0PX9ffuhp for ; Sun, 7 Jul 2019 08:43:58 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 6085E120058 for ; Sun, 7 Jul 2019 08:43:58 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x67Fhrpi022159 for ; Sun, 7 Jul 2019 17:43:53 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id B0BE56FD11 for ; Sun, 7 Jul 2019 17:43:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id dY68_wrV0cud for ; Sun, 7 Jul 2019 17:43:55 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id BFD5E6FD0F for ; Sun, 7 Jul 2019 17:43:55 +0200 (CEST) Date: Sun, 07 Jul 2019 17:43:55 +0200 Message-ID: <87y319vohw.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org In-Reply-To: <156251370028.14572.13763020213427103268@ietfa.amsl.com> References: <156251370028.14572.13763020213427103268@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 07 Jul 2019 17:43:53 +0200 (CEST) X-Miltered: at korolev with ID 5D221339.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D221339.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D221339.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-hmac-08.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 15:44:01 -0000 > Filename : draft-ietf-babel-hmac-08.txt This revision does not make any protocol changes, it merely clarifies the time when a Neighbour Table entry may be created. The change was discussed on the list, please see the thread called "Minor clarification to HMAC" starting on 28 June 2019. I've added some discussion of that particular point to the Security Considerations section, as requested by Markus Stenberg, and followed Mahesh Jethanandani's suggestion to refer to TCP SYN flooding. It is my opinion that this change does not warrant restarting Last Call. -- Juliusz From nobody Mon Jul 8 15:34:27 2019 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC8C12023F; Mon, 8 Jul 2019 15:34:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156262525115.1081.12984498556876085507@ietfa.amsl.com> Date: Mon, 08 Jul 2019 15:34:11 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-information-model-06.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 22:34:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : Babel Information Model Authors : Barbara Stark Mahesh Jethanandani Filename : draft-ietf-babel-information-model-06.txt Pages : 28 Date : 2019-07-08 Abstract: This Babel Information Model can be used to create data models under various data modeling regimes. It allows a Babel implementation (via a management protocol or interface) to report on its current state and may allow some limited configuration of protocol constants. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-information-model-06 https://datatracker.ietf.org/doc/html/draft-ietf-babel-information-model-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-information-model-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 10 11:12:50 2019 Return-Path: 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 E039B1205E5 for ; Wed, 10 Jul 2019 11:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 PYpYr_BB4ymU for ; Wed, 10 Jul 2019 11:12: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 48D73120605 for ; Wed, 10 Jul 2019 11:12:47 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x6AI8ow8048837; Wed, 10 Jul 2019 14:12:46 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2tnmvbrdjw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Jul 2019 14:12:46 -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 x6AICiAt024887; Wed, 10 Jul 2019 14:12:45 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x6AICbri024749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Jul 2019 14:12:37 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 8D32E400AF5F; Wed, 10 Jul 2019 18:12:37 +0000 (GMT) Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (unknown [130.8.218.150]) by zlp30485.vci.att.com (Service) with ESMTPS id 7AF13400AE36; Wed, 10 Jul 2019 18:12:37 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0439.000; Wed, 10 Jul 2019 14:12:37 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: "'Babel at IETF'" Thread-Topic: [babel] info-model: link properties Thread-Index: AdT2F3VDc9TEBNBNR0O9GsdDvc4z+AGI9A8ADsNCs5A= Date: Wed, 10 Jul 2019 18:12:36 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E20EE7C@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E150E05@GAALPA1MSGUSRBF.ITServices.sbc.com> <87imv19ier.wl-jch@irif.fr> In-Reply-To: <87imv19ier.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.249.96] 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=2019-07-10_07:, , 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=574 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907100204 Archived-At: Subject: Re: [babel] info-model: link properties X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 18:12:49 -0000 > I was under the impression that we had decided that the classification of= link > types in wired/wireless/tunnel is an internal implementation detail of > babeld, and that what we wanted to export were the underlying properties, > which are: >=20 > - link cost estimator (ETX or 2-out-of-3); > - use split-horizon (boolean); > - use RTT (boolean). >=20 > wired means 2-out-of-3, split-horizon, no RTT. > wireless means ETX, no split-horizon, no RTT. > tunnel means 2-out-of-3, split-horizon, RTT. >=20 > It is clear to me that the interface type abstration is useful for the us= er, who > doesn't want to deal with technical details such as whether the split-hor= izon > optimisation is allowable on a given link type, but it's difficult to exp= ort from > the management interface. I recently posted an update to the information-model draft, but missed incl= uding the appropriate updates to the Link Properties registry descriptions = in IANA considerations. What I intend to do in the next revision is use Jul= iusz' proposed descriptions (above) for wired, wireless, and tunnel. What s= hould I put for "other"? Or should I have an "other"?=20 Barbara From nobody Wed Jul 10 11:32:55 2019 Return-Path: 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 5ED9F12065E for ; Wed, 10 Jul 2019 11:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 LJgGGaFmUrXB for ; Wed, 10 Jul 2019 11:32:44 -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 0FCEE12067E for ; Wed, 10 Jul 2019 11:32:44 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x6AIRiS6021712; Wed, 10 Jul 2019 14:32:43 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2tnmdk9r6u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Jul 2019 14:32:43 -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 x6AIWei9002382; Wed, 10 Jul 2019 14:32:41 -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 x6AIWZ3E002164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Jul 2019 14:32:35 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 10797400B579; Wed, 10 Jul 2019 18:32:35 +0000 (GMT) Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (unknown [130.8.218.150]) by zlp30483.vci.att.com (Service) with ESMTPS id F0E43400B574; Wed, 10 Jul 2019 18:32:34 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0439.000; Wed, 10 Jul 2019 14:32:34 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: "'Babel at IETF'" Thread-Topic: [babel] info-model: calculated and received metrics Thread-Index: AdT2IrfeBlDu4vVISWCthPLc0HSMMgGGM80ADsRlWAA= Date: Wed, 10 Jul 2019 18:32:33 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E20EEFD@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E151182@GAALPA1MSGUSRBF.ITServices.sbc.com> <87h8al9ibp.wl-jch@irif.fr> In-Reply-To: <87h8al9ibp.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.249.96] 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=2019-07-10_07:, , 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=547 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907100209 Archived-At: Subject: Re: [babel] info-model: calculated and received metrics X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 18:32:47 -0000 > > For a route to exist in the info model babel-routes object, either the > > received or calculated metric MUST be non-zero (rfc6126bis only > > mentions the received metric as being in its route table). >=20 > Zero is a perfectly fine value for a metric (actually, the very best). > Perhaps you meant defined instead of non-zero? I don't think I got the descriptions for calculated and received metrics ri= ght, given Juliusz statement that 0 is the best possible metric. What I'm s= truggling with, is what value is assigned to these parameters when they are= n't received (for the received metric) or calculated (for the calculated me= tric)? Should they be "null"? Wouldn't that be a problem in systems/languag= es that don't distinguish between 0 and null for integer types? Or are ther= e no such languages/systems? Here are the descriptions in the current draft: babel-route-received-metric: The metric with which this route was advertised by the neighbor, or maximum value to indicate the route was recently retracted and is temporarily unreachable (see Section 3.5.5 of [I-D.ietf-babel-rfc6126bis]). 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 babel-route- calculated-metric and babel-route-received-metric MUST be non- zero. Having both be non-zero is expected for a route that is received and subsequently advertised. This is a 16-bit unsigned integer. babel-route-calculated-metric: A calculated metric for this route. How the metric is calculated is implementation-specific. Maximum value indicates the route was recently retracted and is temporarily unreachable (see Section 3.5.5 of [I-D.ietf-babel-rfc6126bis]). At least one of babel-route- calculated-metric and babel-route-received-metric MUST be non- zero. Having both be non-zero is expected for a route that is received and subsequently advertised. This is a 16-bit unsigned integer. Barbara From nobody Wed Jul 10 11:48:54 2019 Return-Path: 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 B8B8512070D for ; Wed, 10 Jul 2019 11:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 gkk87yeDE5SM for ; Wed, 10 Jul 2019 11:48:50 -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 9F56F120703 for ; Wed, 10 Jul 2019 11:48:50 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x6AIdi5Q012281 for ; Wed, 10 Jul 2019 14:48:49 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2tnm6rah87-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 10 Jul 2019 14:48:46 -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 x6AIm4QL001770 for ; Wed, 10 Jul 2019 14:48:04 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x6AIlvts001621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 10 Jul 2019 14:47:58 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id BB2E9400A0A3 for ; Wed, 10 Jul 2019 18:47:57 +0000 (GMT) Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30487.vci.att.com (Service) with ESMTPS id A8CAA400A0A2 for ; Wed, 10 Jul 2019 18:47:57 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0439.000; Wed, 10 Jul 2019 14:47:57 -0400 From: "STARK, BARBARA H" To: "'Babel at IETF'" Thread-Topic: info-model: DTLS config parameters Thread-Index: AdU3Tvn3oHfePCKLQ4CJX1+/HOP9ug== Date: Wed, 10 Jul 2019 18:47:57 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E20F015@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.249.96] 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=2019-07-10_07:, , 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-1810050000 definitions=main-1907100211 Archived-At: Subject: [babel] info-model: DTLS config parameters X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 18:48:53 -0000 I was reviewing the minutes from Prague, and saw they indicated we didn't h= ave resolution on whether certain DTLS configuration parameters should be g= lobal or at the interface level. ---------------------- The current revision has the following global parameters: babel-dtls-enable: Indicates whether the DTLS security mechanism is enabled (true) or disabled (false). An implementation MAY choose to expose this parameter as read-only ("ro"). babel-dtls-cert-types: List of supported DTLS certificate types. Possible values include "X.509" and "RawPublicKey". ----------------------- And the following are at the interface level: babel-dtls-cached-info: Indicates whether the cached_info extension is included in ClientHello and ServerHello packets. The extension is included if the value is "true". An implementation MAY choose to expose this parameter as read-only ("ro"). babel-dtls-cert-prefer: List of supported certificate types, in order of preference. The values MUST be among those listed in the babel-dtls-cert-types parameter. This list is used to populate the server_certificate_type extension in a Client Hello. Values that are present in at least one instance in the babel-dtls-certs object of a referenced babel-dtls instance and that have a non- empty babel-cert-private-key will be used to populate the client_certificate_type extension in a Client Hello. Please let me know if you disagree with this set of global/interface DTLS c= onfig parameters. Barbara From nobody Thu Jul 11 12:19:04 2019 Return-Path: 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 625C9120487 for ; Thu, 11 Jul 2019 12:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 ZKRz5akjMoFA for ; Thu, 11 Jul 2019 12:19:01 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF9812035C for ; Thu, 11 Jul 2019 12:18:50 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id v24so6909769ljg.13 for ; Thu, 11 Jul 2019 12:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GzJqFZjYPdCji+tPOzaqzCEfF/ANt1PYxsvDygqudic=; b=CC3oRfjlROqSwSUpkvudMOTQCEzQyMIS2Gzag2Cow2kPV2oGr/wn6ypXDVcXzIg/8R Z5Y67kFEGdkUwS62XnKp+2eEeKrR7ZecxfmBJjM6q+G7tGZBuGGzzGCNY+j1tdFg5D+i MiYmrZrgdGiuKqwwlky59XZ61Bm7yyButdvxC3aP8Hrqmap66vFoXxgBHyM2+V6BOL19 fWpGlyKqo2oajPw2XpBY90WqfDYx7feDGZXJrUZH1KwBuOSOzRtgXkf/u0fzfBzLRC+O gzfLpNHeKaZfDlP+xoieEZkuCo8gzcDTwOD5bIvKvmDquf73SIp4bZqoT/sI3UwzlOuE 34Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GzJqFZjYPdCji+tPOzaqzCEfF/ANt1PYxsvDygqudic=; b=UTo/INSO2u8qOkE78ElsfffoioFkY1TphEgsuD4ylRUdCPrJPdLpeuCNIciX5xq28B D7zRGwH15QGWQygFeHwJcOULcfkulH8rLjD/miIGGKW+CAUueckLCdRbahPn4sFRV9PW /kFL+ojeuVUa5um0WZ62VCeO3VXzqeF5ojng2k4xXaBqO8a6qe8YKDU+moVTJQfs/o04 wpieSyct5QXsp2pLbnN8bklXIt3GT48ETZvOrwxclh2R2qhloui1BtyEDyoYjTk1tn9j Ui12Rn2Yi6c9jjxtcBApwJ1slnY722eS7FzCB3seXAir++YDR0yGIot3XdVy9OwbgLEM p+XQ== X-Gm-Message-State: APjAAAUPC+I5IBqFaX5jBWCde6LBOBf2e70KajZKHYyv5/CT04f76L2s sP70vYUrjpkNWSGfHiA58Q9/lKrIw44lYRfAbpk= X-Google-Smtp-Source: APXvYqzqJUnxm1pX0/vUik4Rlm2Nkr5feBmkmzOczEoLXVh5G95iS/BDSRnITBlhic856kKa4/cd0WenibT+sGLAWP0= X-Received: by 2002:a2e:5b0f:: with SMTP id p15mr3382160ljb.82.1562872728619; Thu, 11 Jul 2019 12:18:48 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114E20F015@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E20F015@GAALPA1MSGUSRBF.ITServices.sbc.com> From: David Schinazi Date: Thu, 11 Jul 2019 12:18:37 -0700 Message-ID: To: "STARK, BARBARA H" Cc: Babel at IETF Content-Type: multipart/alternative; boundary="000000000000d19082058d6ca9bd" Archived-At: Subject: Re: [babel] info-model: DTLS config parameters X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 19:19:03 -0000 --000000000000d19082058d6ca9bd Content-Type: text/plain; charset="UTF-8" I would personally recommend having all of these be per-interface, so you can use DTLS on a Wi-Fi interface and unencrypted Babel on a virtual IPsec tunnel interface. But I don't feel overly strongly. David On Wed, Jul 10, 2019 at 11:48 AM STARK, BARBARA H wrote: > I was reviewing the minutes from Prague, and saw they indicated we didn't > have resolution on whether certain DTLS configuration parameters should be > global or at the interface level. > ---------------------- > The current revision has the following global parameters: > > babel-dtls-enable: Indicates whether the DTLS security mechanism is > enabled (true) or disabled (false). An implementation MAY choose > to expose this parameter as read-only ("ro"). > > babel-dtls-cert-types: List of supported DTLS certificate types. > Possible values include "X.509" and "RawPublicKey". > ----------------------- > And the following are at the interface level: > > babel-dtls-cached-info: Indicates whether the cached_info extension > is included in ClientHello and ServerHello packets. The extension > is included if the value is "true". An implementation MAY choose > to expose this parameter as read-only ("ro"). > > babel-dtls-cert-prefer: List of supported certificate types, in > order of preference. The values MUST be among those listed in the > babel-dtls-cert-types parameter. This list is used to populate > the server_certificate_type extension in a Client Hello. Values > that are present in at least one instance in the babel-dtls-certs > object of a referenced babel-dtls instance and that have a non- > empty babel-cert-private-key will be used to populate the > client_certificate_type extension in a Client Hello. > > > Please let me know if you disagree with this set of global/interface DTLS > config parameters. > Barbara > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --000000000000d19082058d6ca9bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would personally recommend having all of these be per-in= terface, so you can use DTLS on a Wi-Fi interface and unencrypted Babel on = a virtual IPsec tunnel interface. But I don't feel overly strongly.
David

On Wed, Jul 10, 2019 at 11:48 AM STARK, BARBARA = H <bs7652@att.com> wrote:
I was reviewing the m= inutes from Prague, and saw they indicated we didn't have resolution on= whether certain DTLS configuration parameters should be global or at the i= nterface level.
----------------------
The current revision has the following global parameters:

=C2=A0 =C2=A0babel-dtls-enable:=C2=A0 Indicates whether the DTLS security m= echanism is
=C2=A0 =C2=A0 =C2=A0 enabled (true) or disabled (false).=C2=A0 An implement= ation MAY choose
=C2=A0 =C2=A0 =C2=A0 to expose this parameter as read-only ("ro")= .

=C2=A0 =C2=A0babel-dtls-cert-types:=C2=A0 List of supported DTLS certificat= e types.
=C2=A0 =C2=A0 =C2=A0 Possible values include "X.509" and "Ra= wPublicKey".
-----------------------
And the following are at the interface level:

=C2=A0 =C2=A0babel-dtls-cached-info:=C2=A0 Indicates whether the cached_inf= o extension
=C2=A0 =C2=A0 =C2=A0 is included in ClientHello and ServerHello packets.=C2= =A0 The extension
=C2=A0 =C2=A0 =C2=A0 is included if the value is "true".=C2=A0 An= implementation MAY choose
=C2=A0 =C2=A0 =C2=A0 to expose this parameter as read-only ("ro")= .

=C2=A0 =C2=A0babel-dtls-cert-prefer:=C2=A0 List of supported certificate ty= pes, in
=C2=A0 =C2=A0 =C2=A0 order of preference.=C2=A0 The values MUST be among th= ose listed in the
=C2=A0 =C2=A0 =C2=A0 babel-dtls-cert-types parameter.=C2=A0 This list is us= ed to populate
=C2=A0 =C2=A0 =C2=A0 the server_certificate_type extension in a Client Hell= o.=C2=A0 Values
=C2=A0 =C2=A0 =C2=A0 that are present in at least one instance in the babel= -dtls-certs
=C2=A0 =C2=A0 =C2=A0 object of a referenced babel-dtls instance and that ha= ve a non-
=C2=A0 =C2=A0 =C2=A0 empty babel-cert-private-key will be used to populate = the
=C2=A0 =C2=A0 =C2=A0 client_certificate_type extension in a Client Hello.

Please let me know if you disagree with this set of global/interface DTLS c= onfig parameters.
Barbara

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--000000000000d19082058d6ca9bd-- From nobody Thu Jul 11 16:20:02 2019 Return-Path: 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 D7259120074 for ; Thu, 11 Jul 2019 16:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 fylRTxW03i3M for ; Thu, 11 Jul 2019 16:19:59 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 A2639120041 for ; Thu, 11 Jul 2019 16:19:58 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x6BNJoif015089; Fri, 12 Jul 2019 01:19:51 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id D0100283B2; Fri, 12 Jul 2019 01:19:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id fgQd5zSeIV75; Fri, 12 Jul 2019 01:19:52 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7FEF8283AF; Fri, 12 Jul 2019 01:19:49 +0200 (CEST) Date: Fri, 12 Jul 2019 01:19:49 +0200 Message-ID: <87a7dkcg6i.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: "STARK, BARBARA H" , Babel at IETF In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114E20F015@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 12 Jul 2019 01:19:51 +0200 (CEST) X-Miltered: at korolev with ID 5D27C416.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D27C416.003 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D27C416.003 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] info-model: DTLS config parameters X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 23:20:01 -0000 > I would personally recommend having all of these be per-interface, I agree. In the protocol, they're naturally per-interface, it would be awkward if the management model weren't congruent with what the protocol naturally yields. -- Juliusz "I know what congruent means" Chroboczek From nobody Fri Jul 12 04:52:07 2019 Return-Path: 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 CC70312011E for ; Fri, 12 Jul 2019 04:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zYjCsGzweDT5 for ; Fri, 12 Jul 2019 04:52:03 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F39120099 for ; Fri, 12 Jul 2019 04:52:03 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id o101so9162603ota.8 for ; Fri, 12 Jul 2019 04:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=krlbZZufG7ijcU2SReUAPTv9MKs0RrgDNYAIw7SUnd0=; b=Sd41lsBGu8//5NXCFXUzy8Hjj9qL/se2PNXI/UHkulm/g64i8RNjBbydZJcoIxUtjG qc9YL8YwvzFc54O8nvPa2XKffwuWWc2f6XaUm+TQzEs7z8xe9e5A5kDQDKPzDsW0IX8Z 7AnNvUqQgonSmV/GUcyxu00qHX4bwwQDm+FOgRBhYQqYRO0e5TspK7yW9ei89FRkOigG NK7zUuICStO+NPvm5CFad7nst3k4le6m4CxiAd6w/iWchYZOFmbNKHcBv4U33zfEvHGC 57rTaNMUF++CZWXz7e0oQmxi9+KdDEh4+eVCaPfOcY4la3xHe5FxUxcxBRBpqPzaDvSd 6vWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=krlbZZufG7ijcU2SReUAPTv9MKs0RrgDNYAIw7SUnd0=; b=I7+4GS470SHWub68neEB/lDfj9eYqAYEo7LE8P/LnVSyvk+mJf5k9HqNdvjzlbSuhy H1eEIu4T+0pUBLQrVaJAC0xT/Jn/rziV8x+pb2FGQ5SovTDBBWlaAep2/uMUOfY/P3ST UdUVJN4wh0lF/OZaWI2JnxdiRfFDwzfioGm8tNX3xdHz5aFGJbRNctAFhLnxgaDL0fAB 0DGSA5W4uWFHPpJlt3BWBEWQJ2/zCrdla0Br8Gte2vNeH/agPtw/1OhaZPAXCVxBuuOU /F1/p/sNbhNvy2L4n4tERORkI+bdAoHtzOuqSHL7Sq7aEUN7Fi0WbGCyVGoxaEHShcJg dfLw== X-Gm-Message-State: APjAAAXbah9Qq6XA/0ScR2schFp8fUBKGyJv1NbKxtCKLIfndKalM2KE cDv99deMBG5WOCyWLo3X0s8x9fVV5LpObyxL3aM= X-Google-Smtp-Source: APXvYqxSO2pti+P6e7yMEDiuufeGLHE401skSp2WmYd6axDvdXDQEZ1rdQZ9lv+Jt57MXHKmufH36ZUhThTTcRdRuhg= X-Received: by 2002:a9d:6e8d:: with SMTP id a13mr7978741otr.303.1562932322863; Fri, 12 Jul 2019 04:52:02 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114E20F015@GAALPA1MSGUSRBF.ITServices.sbc.com> <87a7dkcg6i.wl-jch@irif.fr> In-Reply-To: <87a7dkcg6i.wl-jch@irif.fr> From: =?UTF-8?Q?Antonin_D=C3=A9cimo?= Date: Fri, 12 Jul 2019 13:51:58 +0200 Message-ID: To: Juliusz Chroboczek Cc: David Schinazi , "STARK, BARBARA H" , Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] info-model: DTLS config parameters X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 11:52:05 -0000 I fully concur with the all per-interface. It=E2=80=99s also more-or-less easy and natural to implement. Antonin From nobody Fri Jul 12 07:31:11 2019 Return-Path: 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 74F3112029A for ; Fri, 12 Jul 2019 07:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 n2hT65b5lgsd for ; Fri, 12 Jul 2019 07:31:06 -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 D52CF120299 for ; Fri, 12 Jul 2019 07:31:05 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x6CEReVF024591; Fri, 12 Jul 2019 10:31:03 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 2tpuqgrp6s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Jul 2019 10:31:03 -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 x6CEV2Fm017526; Fri, 12 Jul 2019 10:31:03 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x6CEUwtC017389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Jul 2019 10:30:58 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 194184009E87; Fri, 12 Jul 2019 14:30:58 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30488.vci.att.com (Service) with ESMTPS id 03EF04009E70; Fri, 12 Jul 2019 14:30:58 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0439.000; Fri, 12 Jul 2019 10:30:57 -0400 From: "STARK, BARBARA H" To: "'David Schinazi'" CC: "'Babel at IETF'" Thread-Topic: [babel] info-model: DTLS config parameters Thread-Index: AdU3Tvn3oHfePCKLQ4CJX1+/HOP9ugA7/2aAAB9z6KA= Date: Fri, 12 Jul 2019 14:30:57 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E2203C6@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E20F015@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.174.19.147] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114E2203C6GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-12_04:, , 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-1810050000 definitions=main-1907120157 Archived-At: Subject: Re: [babel] info-model: DTLS config parameters X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 14:31:08 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114E2203C6GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGh4IERhdmlkIChhbmQgSnVsaXVzeiBhbmQgQW50b25pbiDigJMgYnV0IEnigJltIHJlcGx5aW5n IHRvIERhdmlk4oCZcyBlbWFpbCBzaW5jZSBoZSBpbmNsdWRlZCB0aGUgY29udGV4dCBpbiBoaXMg cmVzcG9uc2UpLg0KDQpPSywgSeKAmWxsIG1vdmUgZHRscy1lbmFibGUgdG8gdGhlIGludGVyZmFj ZSBvYmplY3QuDQoNCkkgdGhpbmsgZHRscy1jZXJ0LXR5cGVzIHN0aWxsIGJlbG9uZ3MgYXQgdGhl IGdsb2JhbCBsYXllciwgc2luY2UgdGhpcyBpcyBhIG5vbi1jb25maWd1cmFibGUgc3RhdGVtZW50 IG9mIGNhcGFiaWxpdHkgKHdoaWNoIGNlcnRpZmljYXRlIHR5cGVzIGFyZSBzdXBwb3J0ZWQg4oCT IHByZXN1bWFibHkgYnkgdGhlIGltcGxlbWVudGF0aW9uKSBhbmQgSSBkb27igJl0IGVudmlzaW9u IHRoYXQgZGlmZmVyaW5nIHBlciBpbnRlcmZhY2UuIE5vdGUgdGhhdCB0aGUgaW50ZXJmYWNlLWxl dmVsIGR0bHMtY2VydC1wcmVmZXIgcGFyYW1ldGVyIGlzIHdoYXQgaWRlbnRpZmllcyB3aGljaCBv ZiB0aGVzZSBjZXJ0aWZpY2F0ZSB0eXBlcyBnZXRzIGluY2x1ZGVkIGluIGEgc2VydmVyX2NlcnRp ZmljYXRlX3R5cGUgZXh0ZW5zaW9uIGluIGEgQ2xpZW50IEhlbGxvLiBBcyBzdGF0ZWQgaW4gdGhh dCBwYXJhbWV0ZXLigJlzIGRlc2NyaXB0aW9uLCB0aGUgaW5jbHVkZWQgdmFsdWVzIGFyZSBjb25z dHJhaW5lZCBieSB0aGUgcmVxdWlyZW1lbnQgdGhhdCBhdCBsZWFzdCBvbmUgb2YgdGhlIGNlcnRp ZmljYXRlcyBhc3NvY2lhdGVkIHdpdGggdGhlIGludGVyZmFjZSBtdXN0IGhhdmUgdGhlIGNlcnRp ZmljYXRlIHR5cGUuIFRoZSBnbG9iYWwgcGFyYW1ldGVyIGlzIGludGVuZGVkIHRvIHByZXZlbnQg Y2VydGlmaWNhdGVzIGZyb20gYmVpbmcgdXNlZCB0aGF0IHRoZSBpbXBsZW1lbnRhdGlvbiBkb2Vz buKAmXQga25vdyBob3cgdG8gcGFyc2UvdXNlL3JlYWQuDQoNCldoaWxlIEkgb25seSBhc2tlZCBh Ym91dCBEVExTIHBhcmFtZXRlcnMsIEnigJltIHRoaW5raW5nIHRoZSBodG1sLWVuYWJsZSBzaG91 bGQgYWxzbyBiZSBtb3ZlZCB0byB0aGUgaW50ZXJmYWNlIG9iamVjdCwgZm9yIHRoZSBzYW1lIHJl YXNvbiBhcyBEVExTIChhbmQgdG8gcHJvdmlkZSBhIGNlcnRhaW4gZGVncmVlIG9mIHN5bW1ldHJ5 KS4gV291bGQgYW55b25lIG9iamVjdCB0byB0aGF0Pw0KDQpCYXJiYXJhDQoNCkkgd291bGQgcGVy c29uYWxseSByZWNvbW1lbmQgaGF2aW5nIGFsbCBvZiB0aGVzZSBiZSBwZXItaW50ZXJmYWNlLCBz byB5b3UgY2FuIHVzZSBEVExTIG9uIGEgV2ktRmkgaW50ZXJmYWNlIGFuZCB1bmVuY3J5cHRlZCBC YWJlbCBvbiBhIHZpcnR1YWwgSVBzZWMgdHVubmVsIGludGVyZmFjZS4gQnV0IEkgZG9uJ3QgZmVl bCBvdmVybHkgc3Ryb25nbHkuDQoNCkRhdmlkDQoNCk9uIFdlZCwgSnVsIDEwLCAyMDE5IGF0IDEx OjQ4IEFNIFNUQVJLLCBCQVJCQVJBIEggPGJzNzY1MkBhdHQuY29tPG1haWx0bzpiczc2NTJAYXR0 LmNvbT4+IHdyb3RlOg0KSSB3YXMgcmV2aWV3aW5nIHRoZSBtaW51dGVzIGZyb20gUHJhZ3VlLCBh bmQgc2F3IHRoZXkgaW5kaWNhdGVkIHdlIGRpZG4ndCBoYXZlIHJlc29sdXRpb24gb24gd2hldGhl ciBjZXJ0YWluIERUTFMgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzIHNob3VsZCBiZSBnbG9iYWwg b3IgYXQgdGhlIGludGVyZmFjZSBsZXZlbC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoZSBj dXJyZW50IHJldmlzaW9uIGhhcyB0aGUgZm9sbG93aW5nIGdsb2JhbCBwYXJhbWV0ZXJzOg0KDQog ICBiYWJlbC1kdGxzLWVuYWJsZTogIEluZGljYXRlcyB3aGV0aGVyIHRoZSBEVExTIHNlY3VyaXR5 IG1lY2hhbmlzbSBpcw0KICAgICAgZW5hYmxlZCAodHJ1ZSkgb3IgZGlzYWJsZWQgKGZhbHNlKS4g IEFuIGltcGxlbWVudGF0aW9uIE1BWSBjaG9vc2UNCiAgICAgIHRvIGV4cG9zZSB0aGlzIHBhcmFt ZXRlciBhcyByZWFkLW9ubHkgKCJybyIpLi4NCg0KICAgYmFiZWwtZHRscy1jZXJ0LXR5cGVzOiAg TGlzdCBvZiBzdXBwb3J0ZWQgRFRMUyBjZXJ0aWZpY2F0ZSB0eXBlcy4NCiAgICAgIFBvc3NpYmxl IHZhbHVlcyBpbmNsdWRlICJYLjUwOSIgYW5kICJSYXdQdWJsaWNLZXkiLg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCkFuZCB0aGUgZm9sbG93aW5nIGFyZSBhdCB0aGUgaW50ZXJmYWNlIGxldmVs Og0KDQogICBiYWJlbC1kdGxzLWNhY2hlZC1pbmZvOiAgSW5kaWNhdGVzIHdoZXRoZXIgdGhlIGNh Y2hlZF9pbmZvIGV4dGVuc2lvbg0KICAgICAgaXMgaW5jbHVkZWQgaW4gQ2xpZW50SGVsbG8gYW5k IFNlcnZlckhlbGxvIHBhY2tldHMuICBUaGUgZXh0ZW5zaW9uDQogICAgICBpcyBpbmNsdWRlZCBp ZiB0aGUgdmFsdWUgaXMgInRydWUiLiAgQW4gaW1wbGVtZW50YXRpb24gTUFZIGNob29zZQ0KICAg ICAgdG8gZXhwb3NlIHRoaXMgcGFyYW1ldGVyIGFzIHJlYWQtb25seSAoInJvIikuLg0KDQogICBi YWJlbC1kdGxzLWNlcnQtcHJlZmVyOiAgTGlzdCBvZiBzdXBwb3J0ZWQgY2VydGlmaWNhdGUgdHlw ZXMsIGluDQogICAgICBvcmRlciBvZiBwcmVmZXJlbmNlLiAgVGhlIHZhbHVlcyBNVVNUIGJlIGFt b25nIHRob3NlIGxpc3RlZCBpbiB0aGUNCiAgICAgIGJhYmVsLWR0bHMtY2VydC10eXBlcyBwYXJh bWV0ZXIuICBUaGlzIGxpc3QgaXMgdXNlZCB0byBwb3B1bGF0ZQ0KICAgICAgdGhlIHNlcnZlcl9j ZXJ0aWZpY2F0ZV90eXBlIGV4dGVuc2lvbiBpbiBhIENsaWVudCBIZWxsby4gIFZhbHVlcw0KICAg ICAgdGhhdCBhcmUgcHJlc2VudCBpbiBhdCBsZWFzdCBvbmUgaW5zdGFuY2UgaW4gdGhlIGJhYmVs LWR0bHMtY2VydHMNCiAgICAgIG9iamVjdCBvZiBhIHJlZmVyZW5jZWQgYmFiZWwtZHRscyBpbnN0 YW5jZSBhbmQgdGhhdCBoYXZlIGEgbm9uLQ0KICAgICAgZW1wdHkgYmFiZWwtY2VydC1wcml2YXRl LWtleSB3aWxsIGJlIHVzZWQgdG8gcG9wdWxhdGUgdGhlDQogICAgICBjbGllbnRfY2VydGlmaWNh dGVfdHlwZSBleHRlbnNpb24gaW4gYSBDbGllbnQgSGVsbG8uDQoNCg0KUGxlYXNlIGxldCBtZSBr bm93IGlmIHlvdSBkaXNhZ3JlZSB3aXRoIHRoaXMgc2V0IG9mIGdsb2JhbC9pbnRlcmZhY2UgRFRM UyBjb25maWcgcGFyYW1ldGVycy4NCkJhcmJhcmENCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCmJhYmVsIG1haWxpbmcgbGlzdA0KYmFiZWxAaWV0Zi5v cmc8bWFpbHRvOmJhYmVsQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9iYWJlbDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2JhYmVsJmQ9RHdNRmFRJmM9 TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPUxvR3poQy04c2M4U1k4VHE0dnJmb2cmbT1FSERKSGZL MEJtM3o5dTVUS3doeWpqTDFwMGZkeG1YUXFmNjFRYklGbjgwJnM9X0daRk1YTmZHNzlUV1dNLWtD ZjR1cUN1YmREenpfcXFwdHR4SDlRSjJmNCZlPT4NCg== --_000_2D09D61DDFA73D4C884805CC7865E6114E2203C6GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aHggRGF2aWQgKGFuZCBKdWxpdXN6IGFuZCBBbnRvbmluIOKAkyBidXQgSeKAmW0gcmVwbHlpbmcg dG8gRGF2aWTigJlzIGVtYWlsIHNpbmNlIGhlIGluY2x1ZGVkIHRoZSBjb250ZXh0IGluIGhpcyBy ZXNwb25zZSkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9LLCBJ4oCZbGwgbW92ZSBkdGxzLWVu YWJsZSB0byB0aGUgaW50ZXJmYWNlIG9iamVjdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0 aGluayBkdGxzLWNlcnQtdHlwZXMgc3RpbGwgYmVsb25ncyBhdCB0aGUgZ2xvYmFsIGxheWVyLCBz aW5jZSB0aGlzIGlzIGEgbm9uLWNvbmZpZ3VyYWJsZSBzdGF0ZW1lbnQgb2YgY2FwYWJpbGl0eSAo d2hpY2ggY2VydGlmaWNhdGUgdHlwZXMgYXJlIHN1cHBvcnRlZCDigJMgcHJlc3VtYWJseSBieSB0 aGUgaW1wbGVtZW50YXRpb24pIGFuZCBJIGRvbuKAmXQgZW52aXNpb24gdGhhdCBkaWZmZXJpbmcg cGVyIGludGVyZmFjZS4NCiBOb3RlIHRoYXQgdGhlIGludGVyZmFjZS1sZXZlbCBkdGxzLWNlcnQt cHJlZmVyIHBhcmFtZXRlciBpcyB3aGF0IGlkZW50aWZpZXMgd2hpY2ggb2YgdGhlc2UgY2VydGlm aWNhdGUgdHlwZXMgZ2V0cyBpbmNsdWRlZCBpbiBhIHNlcnZlcl9jZXJ0aWZpY2F0ZV90eXBlIGV4 dGVuc2lvbiBpbiBhIENsaWVudCBIZWxsby4gQXMgc3RhdGVkIGluIHRoYXQgcGFyYW1ldGVy4oCZ cyBkZXNjcmlwdGlvbiwgdGhlIGluY2x1ZGVkIHZhbHVlcyBhcmUgY29uc3RyYWluZWQNCiBieSB0 aGUgcmVxdWlyZW1lbnQgdGhhdCBhdCBsZWFzdCBvbmUgb2YgdGhlIGNlcnRpZmljYXRlcyBhc3Nv Y2lhdGVkIHdpdGggdGhlIGludGVyZmFjZSBtdXN0IGhhdmUgdGhlIGNlcnRpZmljYXRlIHR5cGUu IFRoZSBnbG9iYWwgcGFyYW1ldGVyIGlzIGludGVuZGVkIHRvIHByZXZlbnQgY2VydGlmaWNhdGVz IGZyb20gYmVpbmcgdXNlZCB0aGF0IHRoZSBpbXBsZW1lbnRhdGlvbiBkb2VzbuKAmXQga25vdyBo b3cgdG8gcGFyc2UvdXNlL3JlYWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIEkgb25s eSBhc2tlZCBhYm91dCBEVExTIHBhcmFtZXRlcnMsIEnigJltIHRoaW5raW5nIHRoZSBodG1sLWVu YWJsZSBzaG91bGQgYWxzbyBiZSBtb3ZlZCB0byB0aGUgaW50ZXJmYWNlIG9iamVjdCwgZm9yIHRo ZSBzYW1lIHJlYXNvbiBhcyBEVExTIChhbmQgdG8gcHJvdmlkZSBhIGNlcnRhaW4gZGVncmVlIG9m IHN5bW1ldHJ5KS4gV291bGQgYW55b25lIG9iamVjdCB0byB0aGF0PzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5CYXJiYXJhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBwZXJzb25hbGx5IHJlY29tbWVuZCBoYXZpbmcgYWxsIG9m IHRoZXNlIGJlIHBlci1pbnRlcmZhY2UsIHNvIHlvdSBjYW4gdXNlIERUTFMgb24gYSBXaS1GaSBp bnRlcmZhY2UgYW5kIHVuZW5jcnlwdGVkIEJhYmVsIG9uIGEgdmlydHVhbCBJUHNlYyB0dW5uZWwg aW50ZXJmYWNlLiBCdXQgSSBkb24ndCBmZWVsIG92ZXJseSBzdHJvbmdseS48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdmlkPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSnVsIDEwLCAyMDE5 IGF0IDExOjQ4IEFNIFNUQVJLLCBCQVJCQVJBIEggJmx0OzxhIGhyZWY9Im1haWx0bzpiczc2NTJA YXR0LmNvbSI+YnM3NjUyQGF0dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2FzIHJldmlld2luZyB0 aGUgbWludXRlcyBmcm9tIFByYWd1ZSwgYW5kIHNhdyB0aGV5IGluZGljYXRlZCB3ZSBkaWRuJ3Qg aGF2ZSByZXNvbHV0aW9uIG9uIHdoZXRoZXIgY2VydGFpbiBEVExTIGNvbmZpZ3VyYXRpb24gcGFy YW1ldGVycyBzaG91bGQgYmUgZ2xvYmFsIG9yIGF0IHRoZSBpbnRlcmZhY2UgbGV2ZWwuPGJyPg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClRoZSBjdXJyZW50IHJldmlzaW9uIGhhcyB0aGUg Zm9sbG93aW5nIGdsb2JhbCBwYXJhbWV0ZXJzOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtiYWJl bC1kdGxzLWVuYWJsZTombmJzcDsgSW5kaWNhdGVzIHdoZXRoZXIgdGhlIERUTFMgc2VjdXJpdHkg bWVjaGFuaXNtIGlzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgZW5hYmxlZCAodHJ1ZSkgb3Ig ZGlzYWJsZWQgKGZhbHNlKS4mbmJzcDsgQW4gaW1wbGVtZW50YXRpb24gTUFZIGNob29zZTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRvIGV4cG9zZSB0aGlzIHBhcmFtZXRlciBhcyByZWFkLW9u bHkgKCZxdW90O3JvJnF1b3Q7KS4uPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO2JhYmVsLWR0bHMt Y2VydC10eXBlczombmJzcDsgTGlzdCBvZiBzdXBwb3J0ZWQgRFRMUyBjZXJ0aWZpY2F0ZSB0eXBl cy48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBQb3NzaWJsZSB2YWx1ZXMgaW5jbHVkZSAmcXVv dDtYLjUwOSZxdW90OyBhbmQgJnF1b3Q7UmF3UHVibGljS2V5JnF1b3Q7Ljxicj4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPg0KQW5kIHRoZSBmb2xsb3dpbmcgYXJlIGF0IHRoZSBpbnRlcmZh Y2UgbGV2ZWw6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO2JhYmVsLWR0bHMtY2FjaGVkLWluZm86 Jm5ic3A7IEluZGljYXRlcyB3aGV0aGVyIHRoZSBjYWNoZWRfaW5mbyBleHRlbnNpb248YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyBpcyBpbmNsdWRlZCBpbiBDbGllbnRIZWxsbyBhbmQgU2VydmVy SGVsbG8gcGFja2V0cy4mbmJzcDsgVGhlIGV4dGVuc2lvbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7IGlzIGluY2x1ZGVkIGlmIHRoZSB2YWx1ZSBpcyAmcXVvdDt0cnVlJnF1b3Q7LiZuYnNwOyBB biBpbXBsZW1lbnRhdGlvbiBNQVkgY2hvb3NlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgdG8g ZXhwb3NlIHRoaXMgcGFyYW1ldGVyIGFzIHJlYWQtb25seSAoJnF1b3Q7cm8mcXVvdDspLi48YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7YmFiZWwtZHRscy1jZXJ0LXByZWZlcjombmJzcDsgTGlzdCBv ZiBzdXBwb3J0ZWQgY2VydGlmaWNhdGUgdHlwZXMsIGluPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgb3JkZXIgb2YgcHJlZmVyZW5jZS4mbmJzcDsgVGhlIHZhbHVlcyBNVVNUIGJlIGFtb25nIHRo b3NlIGxpc3RlZCBpbiB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBiYWJlbC1kdGxzLWNl cnQtdHlwZXMgcGFyYW1ldGVyLiZuYnNwOyBUaGlzIGxpc3QgaXMgdXNlZCB0byBwb3B1bGF0ZTxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBzZXJ2ZXJfY2VydGlmaWNhdGVfdHlwZSBleHRl bnNpb24gaW4gYSBDbGllbnQgSGVsbG8uJm5ic3A7IFZhbHVlczxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7IHRoYXQgYXJlIHByZXNlbnQgaW4gYXQgbGVhc3Qgb25lIGluc3RhbmNlIGluIHRoZSBi YWJlbC1kdGxzLWNlcnRzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgb2JqZWN0IG9mIGEgcmVm ZXJlbmNlZCBiYWJlbC1kdGxzIGluc3RhbmNlIGFuZCB0aGF0IGhhdmUgYSBub24tPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgZW1wdHkgYmFiZWwtY2VydC1wcml2YXRlLWtleSB3aWxsIGJlIHVz ZWQgdG8gcG9wdWxhdGUgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgY2xpZW50X2NlcnRp ZmljYXRlX3R5cGUgZXh0ZW5zaW9uIGluIGEgQ2xpZW50IEhlbGxvLjxicj4NCjxicj4NCjxicj4N ClBsZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgZGlzYWdyZWUgd2l0aCB0aGlzIHNldCBvZiBnbG9i YWwvaW50ZXJmYWNlIERUTFMgY29uZmlnIHBhcmFtZXRlcnMuPGJyPg0KQmFyYmFyYTxicj4NCjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K YmFiZWwgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmJhYmVsQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+YmFiZWxAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdf bWFpbG1hbl9saXN0aW5mb19iYWJlbCZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZWi1vOV9IVU1lTVRT UWljdmpJZyZhbXA7cj1Mb0d6aEMtOHNjOFNZOFRxNHZyZm9nJmFtcDttPUVIREpIZkswQm0zejl1 NVRLd2h5ampMMXAwZmR4bVhRcWY2MVFiSUZuODAmYW1wO3M9X0daRk1YTmZHNzlUV1dNLWtDZjR1 cUN1YmREenpfcXFwdHR4SDlRSjJmNCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JhYmVsPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2D09D61DDFA73D4C884805CC7865E6114E2203C6GAALPA1MSGUSRBF_-- From nobody Fri Jul 12 09:19:39 2019 Return-Path: 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 7B5A9120134 for ; Fri, 12 Jul 2019 09:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 EAOp24d5gDnf for ; Fri, 12 Jul 2019 09:19:36 -0700 (PDT) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8A012004E for ; Fri, 12 Jul 2019 09:19:36 -0700 (PDT) Received: by mail-oi1-x22d.google.com with SMTP id t76so7714565oih.4 for ; Fri, 12 Jul 2019 09:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MxHLTDP0eP0LcMTKLuvNL3nT93Q1VJMVFzJyZZ0QrsI=; b=ixSDTPc4e+SjGeuITycdORJdtEhy1K0LjtQu8AE4qGGaK3HCdTJ8s0Uxhic/6/EPgq 9AgEapKFzNtmGT/ndQi43kFdjgAXJMtAQLPIFgRUB1nT+9t/Vvv9cFg5VHYVJ8Ey8uYi b3sFgSIXQxE5W1peWHBur21ZEfHVCePSm7AX7h6dliwH7JpJOir55OYRxge+fi0G7Mc0 UWEAP6yGqtZpac9NZ2cUy0Y3hd5DJbIrXbDNNmQvK4W9aE9XbUfqTZPiaz4IQr+F4iNb u+mCPMJzbsI+JxdnIBvRmpJc+svLaRgntw+FftkEDid0xmQyAtgqCk65epdqO195hkfT tXeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MxHLTDP0eP0LcMTKLuvNL3nT93Q1VJMVFzJyZZ0QrsI=; b=hTKbzaD1dwdA4e4RX02O8Z5WOkGWKyGtTRBrsJYwbe7Nl1Q8zHKRWy9WX/rdjIyjSY adR2/NH2PExOj2qZmCXvlxfWzzbdzOfrh1sdKjhfQcn7bU84OzqHaVH85qdDo82Ibdgi I+YreYxH70sNNnvxX8m2FGkEuf6v0tWQ1vA/iKHdp+XvCuoJeYRLvkBRLUFs3P/L6mtw XmRAdcHXAYeO/pl/kMHdfqgpjO7GaB11MEGeguZiWpGbueMfynGE9jnOPj+cAe8ad9uu p7Ik0RkJqRxad0Lv5h5R62umZqwtmLvN4pfxhpo1hxTtvaWP5xtU0Sr3z2symHwiRn6Q 5qVQ== X-Gm-Message-State: APjAAAV/wTAGdfSB/8f7OMV0WqHIVgmT0V8EbAqaw0xuFLF7eHG2D2yP MqOzR2S5QEoErGauYgYQtoaklQ01JbWv+JS3B+Y= X-Google-Smtp-Source: APXvYqw9T5RnxwMPeiLCEHk2dI476A0LFl/ikb+yWewpL0dKTQOeTAj+tpbBpiq7I8GR3+RH83+vsACSx/xzdxqfO9g= X-Received: by 2002:aca:534d:: with SMTP id h74mr6202668oib.64.1562948375363; Fri, 12 Jul 2019 09:19:35 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114E20F015@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E2203C6@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E2203C6@GAALPA1MSGUSRBF.ITServices.sbc.com> From: =?UTF-8?Q?Antonin_D=C3=A9cimo?= Date: Fri, 12 Jul 2019 18:19:30 +0200 Message-ID: To: "STARK, BARBARA H" Cc: David Schinazi , Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] info-model: DTLS config parameters X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 16:19:37 -0000 Hello Barbara, > I think dtls-cert-types still belongs at the global layer After given some thoughts, I completely agree. dtls-cert-types is simply a superset of all supported certificate types, and dtls-cert-prefer can be a strict subset if we don=E2=80=99t want to allow a certain type of certificate on an interface. -- Antonin From nobody Fri Jul 12 09:49:02 2019 Return-Path: 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 41E5C120191 for ; Fri, 12 Jul 2019 09:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 h-Js55nDAzOH for ; Fri, 12 Jul 2019 09:48:59 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696B712007C for ; Fri, 12 Jul 2019 09:48:59 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id i21so9979045ljj.3 for ; Fri, 12 Jul 2019 09:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BEnNvGJSLSYMOOG3uG4SIoAwwo1A+hBPMs4t2lZ0fH4=; b=Lv1w2eJB3lwuELeEM6PYT27E/74lYfKpPRLL8KBT0g+3OzghjMcX7ArGHPqLjgNKkE JDzIwiFsbKoyl4hb0N8GpFr2gFOunZGgND9J1ktqW13sW+hAljm2Cd/5GKJa5gmnDL7+ +NUPHx4Nhm7psVW+V2vtwhkBObEpOww0BTHqMgfqNCEBxGjGvfPTm9SrfF8dFIzg+8IJ +dX+xN82ADBLuKmkKyG/G3OI4yjlf0Az4ZDG5/O/gKMpB2QayoKiliHsSDdEdC2A9PEX mcHR/OG1pFqQF2+5kBX1ZCBJ0vbJ7slXvRkFQWHOGtM4hEkij0s8FMy0NiZY55AjXmbD rGXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BEnNvGJSLSYMOOG3uG4SIoAwwo1A+hBPMs4t2lZ0fH4=; b=CuOUIZKN9G0G0Hk28uDEYbBkxHqfvgVDOvHD5vpqO75fXp7UhjEWVxBMR45iCG+SPV R/xBEFLJnY6FLV0ejf14tVXS8nD6z2KPF/my3BA8GMmi/0Wh/7s7hapIYhhTkKqkzvJM apmqHPKWIkvJbx5ujLTmlC5SHQa40cbiwft9bKDZz597OLTpvoELoHA2107DU/95Ilfx pJlwCmh5GlUXqKDRGbgNmB2x1jPIU9mzjXR8lI6TzYs2tqs5O+mWLw9sm5Ay3HNGJULj 6VNd/7GnmtoTW1fdn2Xctz8JR9l9NIMGSmvNE+QHiZunb34cMSi1jMviv73Iieff7Oz6 9SJg== X-Gm-Message-State: APjAAAX3mrYgdqlc2w/AvCjcxCQMtxjiqt1Iu4V4hYFlzOjVbXTvUArP he9FIYZyRw3JUpjQQO+tZhLZPatJ+zLiIaQCEwI= X-Google-Smtp-Source: APXvYqzcf+EFxURpbwedqdM56O3xQopJupboULSHMtqQQMotOC5Jz7UwspXflD/2g/hF37h4Dow5UIFXU/nJ9/dHtOE= X-Received: by 2002:a2e:7f05:: with SMTP id a5mr6402759ljd.190.1562950137606; Fri, 12 Jul 2019 09:48:57 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114E20F015@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E2203C6@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: From: David Schinazi Date: Fri, 12 Jul 2019 09:48:47 -0700 Message-ID: To: =?UTF-8?Q?Antonin_D=C3=A9cimo?= Cc: Babel at IETF , "STARK, BARBARA H" Content-Type: multipart/alternative; boundary="000000000000c0f65e058d7eaf94" Archived-At: Subject: Re: [babel] info-model: DTLS config parameters X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 16:49:01 -0000 --000000000000c0f65e058d7eaf94 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree about making cert types global and hmac per interface. David On Fri, Jul 12, 2019 at 09:19 Antonin D=C3=A9cimo wrote: > Hello Barbara, > > > I think dtls-cert-types still belongs at the global layer > > After given some thoughts, I completely agree. dtls-cert-types is > simply a superset of all supported certificate types, and > dtls-cert-prefer can be a strict subset if we don=E2=80=99t want to allow= a > certain type of certificate on an interface. > > -- Antonin > --000000000000c0f65e058d7eaf94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree about making cert types global and hmac per = interface.

David


On Fri, Jul 12, 2019 at 09:19 Antonin D=C3= =A9cimo <antonin.decimo@gmai= l.com> wrote:
Hello Barbara,=

> I think dtls-cert-types still belongs at the global layer

After given some thoughts, I completely agree. dtls-cert-types is
simply a superset of all supported certificate types, and
dtls-cert-prefer can be a strict subset if we don=E2=80=99t want to allow a=
certain type of certificate on an interface.

-- Antonin
--000000000000c0f65e058d7eaf94-- From nobody Mon Jul 15 17:51:14 2019 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E787120164; Mon, 15 Jul 2019 17:51:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner via Datatracker To: Cc: draft-ietf-babel-dtls.all@ietf.org, ietf@ietf.org, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Sean Turner Message-ID: <156323827231.27121.11323372537486026352@ietfa.amsl.com> Date: Mon, 15 Jul 2019 17:51:12 -0700 Archived-At: Subject: [babel] Secdir last call review of draft-ietf-babel-dtls-07 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 00:51:12 -0000 Reviewer: Sean Turner Review result: Ready Thanks for responding to my review of -03. I have nothing new to add on -07. From nobody Wed Jul 17 06:16:35 2019 Return-Path: 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 7F7C212022B for ; Wed, 17 Jul 2019 06:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 qTV1l6L4CVBd for ; Wed, 17 Jul 2019 06:16:31 -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 B1A81120156 for ; Wed, 17 Jul 2019 06:16:31 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6HDFtfV034037; Wed, 17 Jul 2019 09:16:30 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 2tt3vbgtm3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Jul 2019 09:16:29 -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 x6HDGScj004632; Wed, 17 Jul 2019 09:16:28 -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 x6HDGJva004344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Jul 2019 09:16:21 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 7C47C4014665; Wed, 17 Jul 2019 13:16:19 +0000 (GMT) Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (unknown [130.8.218.152]) by zlp30483.vci.att.com (Service) with ESMTPS id 68CD74014663; Wed, 17 Jul 2019 13:16:19 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0439.000; Wed, 17 Jul 2019 09:16:18 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: "'Babel at IETF'" Thread-Topic: [babel] info-model: link properties Thread-Index: AdT2F3VDc9TEBNBNR0O9GsdDvc4z+AGI9A8ADsNCs5ABVj/PYA== Date: Wed, 17 Jul 2019 13:16:18 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E22A052@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E150E05@GAALPA1MSGUSRBF.ITServices.sbc.com> <87imv19ier.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E20EE7C@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E20EE7C@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.174.19.151] 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=2019-07-17_05:, , 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=804 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907170161 Archived-At: Subject: Re: [babel] info-model: link properties X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 13:16:34 -0000 I've gotten no replies to this email. Absence of reply mean you agree with = using Juliusz' definitions for wired, wireless, and tunnel. But I'm still u= nclear as to how to define "other". Maybe "implementation specific"? Barbara > > I was under the impression that we had decided that the classification > > of link types in wired/wireless/tunnel is an internal implementation > > detail of babeld, and that what we wanted to export were the > > underlying properties, which are: > > > > - link cost estimator (ETX or 2-out-of-3); > > - use split-horizon (boolean); > > - use RTT (boolean). > > > > wired means 2-out-of-3, split-horizon, no RTT. > > wireless means ETX, no split-horizon, no RTT. > > tunnel means 2-out-of-3, split-horizon, RTT. > > > > It is clear to me that the interface type abstration is useful for the > > user, who doesn't want to deal with technical details such as whether > > the split-horizon optimisation is allowable on a given link type, but > > it's difficult to export from the management interface. >=20 > I recently posted an update to the information-model draft, but missed > including the appropriate updates to the Link Properties registry descrip= tions > in IANA considerations. What I intend to do in the next revision is use J= uliusz' > proposed descriptions (above) for wired, wireless, and tunnel. What shoul= d I > put for "other"? Or should I have an "other"? > Barbara >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_babel&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3DcLDr9j3VC6V4K9_5cjuNb9wKlkx_eIoPr1cDsX2nUEc&s=3D2 > e8o9o9q1cDVE_etpEPEh90o3fPqUvFfh5vvdRZIFrk&e=3D From nobody Wed Jul 17 07:01:04 2019 Return-Path: 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 74380120663 for ; Wed, 17 Jul 2019 07:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 4b06BNDuUKaP for ; Wed, 17 Jul 2019 07:00:59 -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 3A58B120410 for ; Wed, 17 Jul 2019 07:00:59 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6HDn8AS003527; Wed, 17 Jul 2019 10:00:56 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 2tt3vbhws8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Jul 2019 10:00: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 x6HDwuZT008528; Wed, 17 Jul 2019 09:58:56 -0400 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 x6HDwopn008452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Jul 2019 09:58:50 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 9E455400037F; Wed, 17 Jul 2019 13:58:50 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30484.vci.att.com (Service) with ESMTPS id 874664000368; Wed, 17 Jul 2019 13:58:50 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0439.000; Wed, 17 Jul 2019 09:58:50 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: "'Babel at IETF'" Thread-Topic: [babel] info-model: calculated and received metrics Thread-Index: AdT2IrfeBlDu4vVISWCthPLc0HSMMgGGM80ADsRlWAABVTbSQA== Date: Wed, 17 Jul 2019 13:58:49 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E22A14C@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E151182@GAALPA1MSGUSRBF.ITServices.sbc.com> <87h8al9ibp.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E20EEFD@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E20EEFD@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.174.19.151] 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=2019-07-17_06:, , 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=943 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907170165 Archived-At: Subject: Re: [babel] info-model: calculated and received metrics X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 14:01:02 -0000 I've heard no response to this question. I've confirmed that in TR-181 I do= have a problem (a uint with value of 0 or NULL will be transmitted in a TR= -181 data model as 0), because it defines "NULL" as: ------------- excerpt from TR-106 Data Model Template -------------------- Each primitive data type has an associated null value that is used, for exa= mple, as the expansion of the {{null}} template (A.2.2.4). These null value= s are defined as follows: * base64, hexBinary, string: an empty string * unsignedInt, unsignedLong: 0 * int, long: -1 * boolean: false * dateTime: 0001-01-01T00:00:00Z (the Unknown Time; see Section 3.2.1) A null reference indicates that a reference parameter is not currently refe= rencing anything. The value that indicates a null reference is the null val= ue for the reference parameter's base data type, i.e.: * string: an empty string * unsignedInt: 0 * int: ------------------------- But since the problem is just in the reporting and not in the Babel impleme= ntation's use of the values, maybe I should just mention that users should = be careful when interpreting 0, since it can mean the value was not receive= d / calculated? What I could do is something like: babel-route-received-metric: The metric with which this route was advertised by the neighbor, or maximum value to indicate the route was recently retracted and is temporarily unreachable (see Section 3.5.5 of [I-D.ietf-babel-rfc6126bis]). This metric will be NULL if the route was not received from a neighbor. At least one = of babel-route- calculated-metric and babel-route-received-metric MUST be non- NULL. Having both be non-NULL is expected for a route that is received and subsequently advertised. This is a 16-bit unsigned integer. Some data models may be unable to distinguish between 0 (zer= o) and NULL for unsigned integers, which will cause NULL values to be reported as 0. babel-route-calculated-metric: A calculated metric for this route. How the metric is calculated is implementation-specific. Maximum value indicates the route was recently retracted and is temporarily unreachable (see Section 3.5.5 of [I-D.ietf-babel-rfc6126bis]). At least one of babel-route- calculated-metric and babel-route-received-metric MUST be non- NULL. Having both be non-NULL is expected for a route that is received and subsequently advertised. This is a 16-bit unsigned integer. Some data models may be unable to distinguish between 0 (zer= o) and NULL for unsigned integers, which will cause NULL values to be reported as 0. Barbara > > > For a route to exist in the info model babel-routes object, either > > > the received or calculated metric MUST be non-zero (rfc6126bis only > > > mentions the received metric as being in its route table). > > > > Zero is a perfectly fine value for a metric (actually, the very best). > > Perhaps you meant defined instead of non-zero? >=20 > I don't think I got the descriptions for calculated and received metrics = right, > given Juliusz statement that 0 is the best possible metric. What I'm stru= ggling > with, is what value is assigned to these parameters when they aren't > received (for the received metric) or calculated (for the calculated metr= ic)? > Should they be "null"? Wouldn't that be a problem in systems/languages th= at > don't distinguish between 0 and null for integer types? Or are there no s= uch > languages/systems? >=20 > Here are the descriptions in the current draft: >=20 > babel-route-received-metric: The metric with which this route was > advertised by the neighbor, or maximum value to indicate the route > was recently retracted and is temporarily unreachable (see > Section 3.5.5 of [I-D.ietf-babel-rfc6126bis]). 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 babel-route- > calculated-metric and babel-route-received-metric MUST be non- > zero. Having both be non-zero is expected for a route that is > received and subsequently advertised. This is a 16-bit unsigned > integer. >=20 > babel-route-calculated-metric: A calculated metric for this route. > How the metric is calculated is implementation-specific. Maximum > value indicates the route was recently retracted and is > temporarily unreachable (see Section 3.5.5 of > [I-D.ietf-babel-rfc6126bis]). At least one of babel-route- > calculated-metric and babel-route-received-metric MUST be non- > zero. Having both be non-zero is expected for a route that is > received and subsequently advertised. This is a 16-bit unsigned > integer. >=20 > Barbara >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_babel&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3DsRdmY_yz1rFLX_CUhRDGHkslpc0QQlaKGcJIsOCpK0s&s > =3DC8UEVNQ3LdSS0-QKrh8puspZGHWfGPY65gDV-zHQbzI&e=3D From nobody Wed Jul 17 07:50:51 2019 Return-Path: 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 CD1D9120724 for ; Wed, 17 Jul 2019 07:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 mkfzwUVHPW8A for ; Wed, 17 Jul 2019 07:50:48 -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 4569A120720 for ; Wed, 17 Jul 2019 07:50:48 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x6HElQtH018596 for ; Wed, 17 Jul 2019 10:50:46 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2tt4tq9vne-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 17 Jul 2019 10:50:46 -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 x6HEojYe015904 for ; Wed, 17 Jul 2019 10:50:45 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x6HEofaK015830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 17 Jul 2019 10:50:41 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 18DCE400A0A3 for ; Wed, 17 Jul 2019 14:50:41 +0000 (GMT) Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (unknown [130.8.218.152]) by zlp30487.vci.att.com (Service) with ESMTPS id 06D0F400A0A2 for ; Wed, 17 Jul 2019 14:50:41 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0439.000; Wed, 17 Jul 2019 10:50:40 -0400 From: "STARK, BARBARA H" To: "'Babel at IETF'" Thread-Topic: info-model: question on "k out of j" Thread-Index: AdU8rjCW/9m4OsmKTYWiK5XRqLx6VQ== Date: Wed, 17 Jul 2019 14:50:40 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E22A322@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.174.19.151] 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=2019-07-17_06:, , 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=837 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907170173 Archived-At: Subject: [babel] info-model: question on "k out of j" X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 14:50:50 -0000 Currently, when reporting what metric calculation algorithms are supported,= the info model supports an enumeration of "k-out-of-j". I notice that the = only "k out of j" algorithm that really seems to be used is "2 out of 3". S= hould we replace the generic "k-out-of-j" with the more specific "2-out-of-= 3"? And if other k out of j algorithms are supported, they can be specifica= lly called out with whatever values of k and j they use? Or is it really th= e case that if any values of k and j are supported, then it would be easy t= o use whatever values of k and j make sense in some particular case? Note t= hat the proposed link type properties definitions call out "2 out of 3" ins= tead of the generic "k out of j". I think it would be good to be consistent= in which one we use. Barbara From nobody Wed Jul 17 13:50:48 2019 Return-Path: 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 6BA571200FD for ; Wed, 17 Jul 2019 13:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (2048-bit key) header.d=toke.dk 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 zm9K5FdcEx4U for ; Wed, 17 Jul 2019 13:50:44 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 763D81200C5 for ; Wed, 17 Jul 2019 13:50:44 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1563396641; bh=TxxSN5sDlDK95touq46YtBu+wTIrLFPeToBIjzM4Gk4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=wJkXDOCUOZIPd21uS1Ltg78JxPa4aQDz4BcdCYDl7xFTSIBUWIfZZlAAgFv7WNk2u wt8rlVaFontotbvIYQIs1lrfoTgm4POQjI5Jqc66mQzjcQ1EojAaYPfBxmWKbz6Ugz 2JFkcp8UP6uWYRXUz4nhrmASViBOpE9xuU2gtIiK3LjZNga0Tj1YdvvEx3c9UaM35D g+ynqhFPcBjZfBdPx/TknjsQQFgpngUC4Sm3+efZ0zLEPvjNdHUTw7KoRGJJfD6aVX z3jIaU5SuUhZ/NAjLoBRxswhmcJIZtLSbz/zObkeHWOVOrEH6bjcn5K7NnMwxs1WJv sQbNNgJV48FZg== To: "STARK\, BARBARA H" , 'Juliusz Chroboczek' Cc: 'Babel at IETF' In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E22A14C@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E151182@GAALPA1MSGUSRBF.ITServices.sbc.com> <87h8al9ibp.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E20EEFD@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E22A14C@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Wed, 17 Jul 2019 22:50:40 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87ftn475cv.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] info-model: calculated and received metrics X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 20:50:46 -0000 "STARK, BARBARA H" writes: > I've heard no response to this question. I've confirmed that in TR-181 > I do have a problem (a uint with value of 0 or NULL will be > transmitted in a TR-181 data model as 0), because it defines "NULL" > as: In this case, wouldn't NULL be signified by the value being absent? -Toke From nobody Wed Jul 17 14:42:07 2019 Return-Path: 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 C12B312011A for ; Wed, 17 Jul 2019 14:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 iWUsi0Zz5cvU for ; Wed, 17 Jul 2019 14:42:02 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7503512051D for ; Wed, 17 Jul 2019 14:42:02 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id k8so12674739plt.3 for ; Wed, 17 Jul 2019 14:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bjxwgyml2Cq36ROSD0S2smBbDPS6YqJllSGR8U0f8O8=; b=VIEcfKplDpuLLf9W3bkhZLzxo5oTymYlsDp6hiiiOVSRBZ4VjxrNk6Azi0T39rX2h6 s3vlSFSv3LEl2kJyGIKAd5v6NiYP0WUwkN8wyjTHcsOtTDmI8R4k/RoucBCSQ2BmVkdE fDAVgnPDc9kwK+yGu5mGgod8x7pO5fG4GAB6dAiwbzZ6gqy+lwo9RBhT9kS6HvA9VYvX Yk7Vyg+X70FCsAOf+OW7wJe/vxh7SQJsJJES/YK3JRRQJrml+QG+kep3nqqXqQ5EuJw6 rwI4yLaINpQkslg+AKo39pUaJ0p67vU8Uf/Hd+5eDCrMHolwLI+JiS0r2rm+vgKHzU0s 2yaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=bjxwgyml2Cq36ROSD0S2smBbDPS6YqJllSGR8U0f8O8=; b=XjOKKT7+Mf2uQ8SbSh6tYXPhLMP5xgXCKpZx3Q8pNRr1ebd0K2+Iztpa5WF/WTPNyd Ts8vcphXvnra7/fauOeIAxbkT38+j0fxLPKslTZoMcLoVuq7O00nkq71m6xnjqJPLmim 7qVN/VI3UJYeq7Ncc2adMRyo2ut4pJM8FWMtZmMyHT9K4dX4JiO2w1ZVzvnZTRT+eQLk zf9F2nwvdTcs3gILnyQLr5UalIf3+xeMTIbsptRoWQt9FHxP/4DLWW+Ytm4q/z3YUhdc ouzDlrkOEMumUxwfPEAuZ75+Og1L9hZSgOMhwQnuKKT19/oE5I0SmVY1WnoSF8V1v8+c HINw== X-Gm-Message-State: APjAAAWh7A6uP59d9XqiKPmuIzvDe0nh+u3WhJMiAPv+foptc2DfPZkr IJQITU88KtqdmgeHZYvZ2jbx1y3h X-Google-Smtp-Source: APXvYqxtAyw1dmdRsk3gXMiM/hz5eChNzAKWPksDmJsFWa0f9o+73/TKLP2zqK6+9E6V2QGhboRVLQ== X-Received: by 2002:a17:902:5c3:: with SMTP id f61mr42609793plf.98.1563399721858; Wed, 17 Jul 2019 14:42:01 -0700 (PDT) Received: from [10.33.123.117] ([66.170.99.2]) by smtp.gmail.com with ESMTPSA id r27sm29451824pgn.25.2019.07.17.14.42.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jul 2019 14:42:00 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <2A368F02-30B0-4C11-BB5B-3AD6D8AF4F3D@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3C6D3FB1-6665-40BA-BCAA-134E6B4BB6D8" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 17 Jul 2019 14:41:59 -0700 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E22A14C@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: Juliusz Chroboczek , Babel at IETF To: "STARK, BARBARA H" References: <2D09D61DDFA73D4C884805CC7865E6114E151182@GAALPA1MSGUSRBF.ITServices.sbc.com> <87h8al9ibp.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E20EEFD@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E22A14C@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] info-model: calculated and received metrics X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 21:42:06 -0000 --Apple-Mail=_3C6D3FB1-6665-40BA-BCAA-134E6B4BB6D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Any reason we cannot change = babel-route-received-metric/babel-route-calculated-metric be a int = instead of a uint, and all negative values used to signify that the = value is NULL/not set? > On Jul 17, 2019, at 6:58 AM, STARK, BARBARA H wrote: >=20 > I've heard no response to this question. I've confirmed that in TR-181 = I do have a problem (a uint with value of 0 or NULL will be transmitted = in a TR-181 data model as 0), because it defines "NULL" as: > ------------- excerpt from TR-106 Data Model Template = -------------------- > Each primitive data type has an associated null value that is used, = for example, as the expansion of the {{null}} template (A.2.2.4). These = null values are defined as follows: > * base64, hexBinary, string: an empty string > * unsignedInt, unsignedLong: 0 > * int, long: -1 > * boolean: false > * dateTime: 0001-01-01T00:00:00Z (the Unknown Time; see Section 3.2.1) > A null reference indicates that a reference parameter is not currently = referencing anything. The value that indicates a null reference is the = null value for the reference parameter's base data type, i.e.: > * string: an empty string > * unsignedInt: 0 > * int: > ------------------------- > But since the problem is just in the reporting and not in the Babel = implementation's use of the values, maybe I should just mention that = users should be careful when interpreting 0, since it can mean the value = was not received / calculated? >=20 > What I could do is something like: >=20 > babel-route-received-metric: The metric with which this route was > advertised by the neighbor, or maximum value to indicate the = route > was recently retracted and is temporarily unreachable (see > Section 3.5.5 of [I-D.ietf-babel-rfc6126bis]). This metric will > be NULL if the route was not received from a neighbor. At least = one of babel-route- > calculated-metric and babel-route-received-metric MUST be non- > NULL. Having both be non-NULL is expected for a route that is > received and subsequently advertised. This is a 16-bit unsigned > integer. Some data models may be unable to distinguish between 0 = (zero) > and NULL for unsigned integers, which will cause NULL values to = be > reported as 0. >=20 > babel-route-calculated-metric: A calculated metric for this route. > How the metric is calculated is implementation-specific. Maximum > value indicates the route was recently retracted and is > temporarily unreachable (see Section 3.5.5 of > [I-D.ietf-babel-rfc6126bis]). At least one of babel-route- > calculated-metric and babel-route-received-metric MUST be non- > NULL. Having both be non-NULL is expected for a route that is > received and subsequently advertised. This is a 16-bit unsigned > integer. Some data models may be unable to distinguish between 0 = (zero) > and NULL for unsigned integers, which will cause NULL values to = be > reported as 0. >=20 > Barbara >=20 >>>> For a route to exist in the info model babel-routes object, either >>>> the received or calculated metric MUST be non-zero (rfc6126bis only >>>> mentions the received metric as being in its route table). >>>=20 >>> Zero is a perfectly fine value for a metric (actually, the very = best). >>> Perhaps you meant defined instead of non-zero? >>=20 >> I don't think I got the descriptions for calculated and received = metrics right, >> given Juliusz statement that 0 is the best possible metric. What I'm = struggling >> with, is what value is assigned to these parameters when they aren't >> received (for the received metric) or calculated (for the calculated = metric)? >> Should they be "null"? Wouldn't that be a problem in = systems/languages that >> don't distinguish between 0 and null for integer types? Or are there = no such >> languages/systems? >>=20 >> Here are the descriptions in the current draft: >>=20 >> babel-route-received-metric: The metric with which this route was >> advertised by the neighbor, or maximum value to indicate the = route >> was recently retracted and is temporarily unreachable (see >> Section 3.5.5 of [I-D.ietf-babel-rfc6126bis]). 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 babel-route- >> calculated-metric and babel-route-received-metric MUST be non- >> zero. Having both be non-zero is expected for a route that is >> received and subsequently advertised. This is a 16-bit unsigned >> integer. >>=20 >> babel-route-calculated-metric: A calculated metric for this route. >> How the metric is calculated is implementation-specific. = Maximum >> value indicates the route was recently retracted and is >> temporarily unreachable (see Section 3.5.5 of >> [I-D.ietf-babel-rfc6126bis]). At least one of babel-route- >> calculated-metric and babel-route-received-metric MUST be non- >> zero. Having both be non-zero is expected for a route that is >> received and subsequently advertised. This is a 16-bit unsigned >> integer. >>=20 >> Barbara >>=20 >> _______________________________________________ >> babel mailing list >> babel@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- = >> 3A__www.ietf.org_mailman_listinfo_babel&d=3DDwICAg&c=3DLFYZ- >> o9_HUMeMTSQicvjIg&r=3DLoGzhC- >> 8sc8SY8Tq4vrfog&m=3DsRdmY_yz1rFLX_CUhRDGHkslpc0QQlaKGcJIsOCpK0s&s >> =3DC8UEVNQ3LdSS0-QKrh8puspZGHWfGPY65gDV-zHQbzI&e=3D >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel = Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_3C6D3FB1-6665-40BA-BCAA-134E6B4BB6D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Any = reason we cannot change = babel-route-received-metric/babel-route-calculated-metric be a int = instead of a uint, and all negative values used to signify that the = value is NULL/not set?

On Jul 17, 2019, at 6:58 AM, = STARK, BARBARA H <bs7652@att.com> wrote:

I've heard no response to this = question. I've confirmed that in TR-181 I do have a problem (a uint with = value of 0 or NULL will be transmitted in a TR-181 data model as 0), = because it defines "NULL" as:
------------- excerpt from TR-106 Data Model Template = --------------------
Each primitive data type has an associated null value that is = used, for example, as the expansion of the {{null}} template (A.2.2.4). = These null values are defined as follows:
* base64, hexBinary, string: an empty string
* unsignedInt, unsignedLong: = 0
* int, long: = -1
* boolean: = false
* dateTime: = 0001-01-01T00:00:00Z (the Unknown Time; see Section 3.2.1)
A null reference indicates that = a reference parameter is not currently referencing anything. The value = that indicates a null reference is the null value for the reference = parameter's base data type, i.e.:
* string: an empty string
* unsignedInt: 0
* int:
-------------------------
But since the problem is just in the reporting and not in the = Babel implementation's use of the values, maybe I should just mention = that users should be careful when interpreting 0, since it can mean the = value was not received / calculated?

What I could do is something like:

  babel-route-received-metric:  The metric = with which this route was
     advertised by the neighbor, or = maximum value to indicate the route
     was recently retracted and is = temporarily unreachable (see
     Section 3.5.5 of = [I-D.ietf-babel-rfc6126bis]).  This metric will
     be = NULL if the route was not received from a neighbor.  At least one = of babel-route-
     calculated-metric and = babel-route-received-metric MUST be non-
     NULL.  Having both be = non-NULL is expected for a route that is
     received and subsequently = advertised.  This is a 16-bit unsigned
     integer. Some data models may = be unable to distinguish between 0 (zero)
     and NULL for unsigned integers, = which will cause NULL values to be
     reported as 0.

  babel-route-calculated-metric:  A calculated = metric for this route.
     How the metric is calculated is = implementation-specific.  Maximum
     value indicates the route was = recently retracted and is
     temporarily unreachable (see = Section 3.5.5 of
     [I-D.ietf-babel-rfc6126bis]). =  At least one of babel-route-
     calculated-metric and = babel-route-received-metric MUST be non-
     NULL.  Having both be = non-NULL is expected for a route that is
     received and subsequently = advertised.  This is a 16-bit unsigned
     integer. Some data models may = be unable to distinguish between 0 (zero)
     and NULL for unsigned integers, = which will cause NULL values to be
     reported as 0.

Barbara

For a route to exist in the info model babel-routes object, = either
the received or calculated metric MUST be non-zero = (rfc6126bis only
mentions the received metric as being in = its route table).

Zero is a = perfectly fine value for a metric (actually, the very best).
Perhaps you meant defined instead of non-zero?

I don't think I got the = descriptions for calculated and received metrics right,
given Juliusz statement that 0 is the best possible metric. = What I'm struggling
with, is what value is assigned to = these parameters when they aren't
received (for the = received metric) or calculated (for the calculated metric)?
Should they be "null"? Wouldn't that be a problem in = systems/languages that
don't distinguish between 0 and = null for integer types? Or are there no such
languages/systems?

Here are the = descriptions in the current draft:

  babel-route-received-metric:  The metric = with which this route was
     advertised by the neighbor, or = maximum value to indicate the route
     was recently retracted and is = temporarily unreachable (see
     Section 3.5.5 of = [I-D.ietf-babel-rfc6126bis]).  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 babel-route-
     calculated-metric and = babel-route-received-metric MUST be non-
     zero.  Having both be = non-zero is expected for a route that is
     received and subsequently = advertised.  This is a 16-bit unsigned
     integer.

  babel-route-calculated-metric:  A calculated = metric for this route.
     How = the metric is calculated is implementation-specific.  Maximum
     value indicates the route was = recently retracted and is
     temporarily unreachable (see = Section 3.5.5 of
     [I-D.ietf-babel-rfc6126bis]). =  At least one of babel-route-
     calculated-metric and = babel-route-received-metric MUST be non-
     zero.  Having both be = non-zero is expected for a route that is
     received and subsequently = advertised.  This is a 16-bit unsigned
     integer.

Barbara

_______________________________________________
babel mailing list
babel@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
3A__www.ietf.org_mailman_listinfo_babel&d=3DDwICAg&c=3D= LFYZ-
o9_HUMeMTSQicvjIg&r=3DLoGzhC-
8sc8SY8Tq4vrfog&m=3DsRdmY_yz1rFLX_CUhRDGHkslpc0QQlaKGcJIsOC= pK0s&s
=3DC8UEVNQ3LdSS0-QKrh8puspZGHWfGPY65gDV-zHQbzI&e=3D

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_3C6D3FB1-6665-40BA-BCAA-134E6B4BB6D8-- From nobody Wed Jul 17 14:54:29 2019 Return-Path: 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 9CE9A1200F9 for ; Wed, 17 Jul 2019 14:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 jpdTj0P3il7f for ; Wed, 17 Jul 2019 14:54:25 -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 DD6681200E7 for ; Wed, 17 Jul 2019 14:54:24 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x6HLk0SS023348; Wed, 17 Jul 2019 17:54:23 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 2ttb54193m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Jul 2019 17:54:22 -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 x6HLsLtD013019; Wed, 17 Jul 2019 17:54:21 -0400 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 x6HLsFD8012895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Jul 2019 17:54:15 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 22A644009E7E; Wed, 17 Jul 2019 21:54:15 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30484.vci.att.com (Service) with ESMTPS id 09F594009E7D; Wed, 17 Jul 2019 21:54:15 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0439.000; Wed, 17 Jul 2019 17:54:14 -0400 From: "STARK, BARBARA H" To: "'Mahesh Jethanandani'" CC: "'Juliusz Chroboczek'" , "'Babel at IETF'" Thread-Topic: [babel] info-model: calculated and received metrics Thread-Index: AdT2IrfeBlDu4vVISWCthPLc0HSMMgGGM80ADsRlWAABVTbSQAAaAWGAAAhV/dA= Date: Wed, 17 Jul 2019 21:54:14 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E22B256@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E151182@GAALPA1MSGUSRBF.ITServices.sbc.com> <87h8al9ibp.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E20EEFD@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E22A14C@GAALPA1MSGUSRBF.ITServices.sbc.com> <2A368F02-30B0-4C11-BB5B-3AD6D8AF4F3D@gmail.com> In-Reply-To: <2A368F02-30B0-4C11-BB5B-3AD6D8AF4F3D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.225.82] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114E22B256GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-17_10:, , 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-1810050000 definitions=main-1907170242 Archived-At: Subject: Re: [babel] info-model: calculated and received metrics X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 21:54:28 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114E22B256GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I did think about that, and would be ok with it. I also considered stating = in the description that data models that don't distinguish between NULL and= 0 can use int (negative numbers can represent NULL). Otherwise use uint is= fine. Barbara From: Mahesh Jethanandani Any reason we cannot change babel-route-received-metric/babel-route-calcula= ted-metric be a int instead of a uint, and all negative values used to sign= ify that the value is NULL/not set? On Jul 17, 2019, at 6:58 AM, STARK, BARBARA H > wrote: I've heard no response to this question. I've confirmed that in TR-181 I do= have a problem (a uint with value of 0 or NULL will be transmitted in a TR= -181 data model as 0), because it defines "NULL" as: ------------- excerpt from TR-106 Data Model Template -------------------- Each primitive data type has an associated null value that is used, for exa= mple, as the expansion of the {{null}} template (A.2.2.4). These null value= s are defined as follows: * base64, hexBinary, string: an empty string * unsignedInt, unsignedLong: 0 * int, long: -1 * boolean: false * dateTime: 0001-01-01T00:00:00Z (the Unknown Time; see Section 3.2.1) A null reference indicates that a reference parameter is not currently refe= rencing anything. The value that indicates a null reference is the null val= ue for the reference parameter's base data type, i.e.: * string: an empty string * unsignedInt: 0 * int: ------------------------- But since the problem is just in the reporting and not in the Babel impleme= ntation's use of the values, maybe I should just mention that users should = be careful when interpreting 0, since it can mean the value was not receive= d / calculated? What I could do is something like: babel-route-received-metric: The metric with which this route was advertised by the neighbor, or maximum value to indicate the route was recently retracted and is temporarily unreachable (see Section 3.5.5 of [I-D.ietf-babel-rfc6126bis]). This metric will be NULL if the route was not received from a neighbor. At least one o= f babel-route- calculated-metric and babel-route-received-metric MUST be non- NULL. Having both be non-NULL is expected for a route that is received and subsequently advertised. This is a 16-bit unsigned integer. Some data models may be unable to distinguish between 0 (zero= ) and NULL for unsigned integers, which will cause NULL values to be reported as 0. babel-route-calculated-metric: A calculated metric for this route. How the metric is calculated is implementation-specific. Maximum value indicates the route was recently retracted and is temporarily unreachable (see Section 3.5.5 of [I-D.ietf-babel-rfc6126bis]). At least one of babel-route- calculated-metric and babel-route-received-metric MUST be non- NULL. Having both be non-NULL is expected for a route that is received and subsequently advertised. This is a 16-bit unsigned integer. Some data models may be unable to distinguish between 0 (zero= ) and NULL for unsigned integers, which will cause NULL values to be reported as 0. Barbara For a route to exist in the info model babel-routes object, either the received or calculated metric MUST be non-zero (rfc6126bis only mentions the received metric as being in its route table). Zero is a perfectly fine value for a metric (actually, the very best). Perhaps you meant defined instead of non-zero? I don't think I got the descriptions for calculated and received metrics ri= ght, given Juliusz statement that 0 is the best possible metric. What I'm strugg= ling with, is what value is assigned to these parameters when they aren't received (for the received metric) or calculated (for the calculated metric= )? Should they be "null"? Wouldn't that be a problem in systems/languages that don't distinguish between 0 and null for integer types? Or are there no suc= h languages/systems? Here are the descriptions in the current draft: babel-route-received-metric: The metric with which this route was advertised by the neighbor, or maximum value to indicate the route was recently retracted and is temporarily unreachable (see Section 3.5.5 of [I-D.ietf-babel-rfc6126bis]). 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 babel-route- calculated-metric and babel-route-received-metric MUST be non- zero. Having both be non-zero is expected for a route that is received and subsequently advertised. This is a 16-bit unsigned integer. babel-route-calculated-metric: A calculated metric for this route. How the metric is calculated is implementation-specific. Maximum value indicates the route was recently retracted and is temporarily unreachable (see Section 3.5.5 of [I-D.ietf-babel-rfc6126bis]). At least one of babel-route- calculated-metric and babel-route-received-metric MUST be non- zero. Having both be non-zero is expected for a route that is received and subsequently advertised. This is a 16-bit unsigned integer. Barbara _______________________________________________ babel mailing list babel@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps- 3A__www.ietf.org_mailman_listinfo_babel&d=3DDwICAg&c=3DLFYZ- o9_HUMeMTSQicvjIg&r=3DLoGzhC- 8sc8SY8Tq4vrfog&m=3DsRdmY_yz1rFLX_CUhRDGHkslpc0QQlaKGcJIsOCpK0s&s =3DC8UEVNQ3LdSS0-QKrh8puspZGHWfGPY65gDV-zHQbzI&e=3D _______________________________________________ babel mailing list babel@ietf.org https://www.ietf.org/mailman/listinfo/babel Mahesh Jethanandani mjethanandani@gmail.com --_000_2D09D61DDFA73D4C884805CC7865E6114E22B256GAALPA1MSGUSRBF_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I did think about that, and would be ok with it. I a= lso considered stating in the description that data models that don’t= distinguish between NULL and 0 can use int (negative numbers can represent= NULL). Otherwise use uint is fine.

Barbara

 

From: Mahesh Jethanandani <mjethanandani@g= mail.com>

Any reason we cannot change babel-route-received-met= ric/babel-route-calculated-metric be a int instead of a uint, and all negat= ive values used to signify that the value is NULL/not set?



On Jul 17, 2019, at 6:58 AM, STARK, BARBARA H <bs7652@att.com> wrote:

 

I've heard no response to this question. I've conf= irmed that in TR-181 I do have a problem (a uint with value of 0 or NULL wi= ll be transmitted in a TR-181 data model as 0), because it defines "NULL" as:
------------- excerpt from TR-106 Data Model Template --------------------<= br> Each primitive data type has an associated null value that is used, for exa= mple, as the expansion of the {{null}} template (A.2.2.4). These null value= s are defined as follows:
* base64, hexBinary, string: an empty string
* unsignedInt, unsignedLong: 0
* int, long: -1
* boolean: false
* dateTime: 0001-01-01T00:00:00Z (the Unknown Time; see Section 3.2.1)
A null reference indicates that a reference parameter is not currently refe= rencing anything. The value that indicates a null reference is the null val= ue for the reference parameter's base data type, i.e.:
* string: an empty string
* unsignedInt: 0
* int:
-------------------------
But since the problem is just in the reporting and not in the Babel impleme= ntation's use of the values, maybe I should just mention that users should = be careful when interpreting 0, since it can mean the value was not receive= d / calculated?

What I could do is something like:

  babel-route-received-metric:  The metric with which this r= oute was
     advertised by the neighbor, or maximum value = to indicate the route
     was recently retracted and is temporarily unr= eachable (see
     Section 3.5.5 of [I-D.ietf-babel-rfc6126bis])= .  This metric will
     be NULL if the route was not received from a = neighbor.  At least one of babel-route-
     calculated-metric and babel-route-received-me= tric MUST be non-
     NULL.  Having both be non-NULL is expect= ed for a route that is
     received and subsequently advertised.  T= his is a 16-bit unsigned
     integer. Some data models may be unable to di= stinguish between 0 (zero)
     and NULL for unsigned integers, which will ca= use NULL values to be
     reported as 0.

  babel-route-calculated-metric:  A calculated metric for th= is route.
     How the metric is calculated is implementatio= n-specific.  Maximum
     value indicates the route was recently retrac= ted and is
     temporarily unreachable (see Section 3.5.5 of=
     [I-D.ietf-babel-rfc6126bis]).  At least = one of babel-route-
     calculated-metric and babel-route-received-me= tric MUST be non-
     NULL.  Having both be non-NULL is expect= ed for a route that is
     received and subsequently advertised.  T= his is a 16-bit unsigned
     integer. Some data models may be unable to di= stinguish between 0 (zero)
     and NULL for unsigned integers, which will ca= use NULL values to be
     reported as 0.

Barbara


For a route to exist in the info model babel-route= s object, either
the received or calculated metric MUST be non-zero (rfc6126bis only
mentions the received metric as being in its route table).


Zero is a perfectly fine value for a metric (actually, the very best).
Perhaps you meant defined instead of non-zero?


I don't think I got the descriptions for calculated and received metrics ri= ght,
given Juliusz statement that 0 is the best possible metric. What I'm strugg= ling
with, is what value is assigned to these parameters when they aren't
received (for the received metric) or calculated (for the calculated metric= )?
Should they be "null"? Wouldn't that be a problem in systems/lang= uages that
don't distinguish between 0 and null for integer types? Or are there no suc= h
languages/systems?

Here are the descriptions in the current draft:

  babel-route-received-metric:  The metric with which this r= oute was
     advertised by the neighbor, or maximum value = to indicate the route
     was recently retracted and is temporarily unr= eachable (see
     Section 3.5.5 of [I-D.ietf-babel-rfc6126bis])= .  This metric will
     be 0 (zero) if the route was not received fro= m a neighbor but was
     generated through other means.  At least= one of babel-route-
     calculated-metric and babel-route-received-me= tric MUST be non-
     zero.  Having both be non-zero is expect= ed for a route that is
     received and subsequently advertised.  T= his is a 16-bit unsigned
     integer.

  babel-route-calculated-metric:  A calculated metric for th= is route.
     How the metric is calculated is implementatio= n-specific.  Maximum
     value indicates the route was recently retrac= ted and is
     temporarily unreachable (see Section 3.5.5 of=
     [I-D.ietf-babel-rfc6126bis]).  At least = one of babel-route-
     calculated-metric and babel-route-received-me= tric MUST be non-
     zero.  Having both be non-zero is expect= ed for a route that is
     received and subsequently advertised.  T= his is a 16-bit unsigned
     integer.

Barbara

_______________________________________________
babel mailing list
babel@ietf.org
https://url= defense.proofpoint.com/v2/url?u=3Dhttps-
3A__www.ietf.org_mailman_listinfo_babel&d=3DDwICAg&c=3DLFYZ-
o9_HUMeMTSQicvjIg&r=3DLoGzhC-
8sc8SY8Tq4vrfog&m=3DsRdmY_yz1rFLX_CUhRDGHkslpc0QQlaKGcJIsOCpK0s&s =3DC8UEVNQ3LdSS0-QKrh8puspZGHWfGPY65gDV-zHQbzI&e=3D


_______________________________________________
babel mailing list
babel@ietf.org
= https://www.ietf.org/mailman/listinfo/babel

 

Mahesh Jethanandani

 

 

 

--_000_2D09D61DDFA73D4C884805CC7865E6114E22B256GAALPA1MSGUSRBF_-- From nobody Wed Jul 17 14:58:56 2019 Return-Path: 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 499A91200F9 for ; Wed, 17 Jul 2019 14:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 QB8W5iL8IB_Y for ; Wed, 17 Jul 2019 14:58:53 -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 D3D1D1200E7 for ; Wed, 17 Jul 2019 14:58:53 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x6HLvLfT010919; Wed, 17 Jul 2019 17:58:51 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2ttax9sphp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Jul 2019 17:58:50 -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 x6HLwneD018811; Wed, 17 Jul 2019 17:58:49 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x6HLwfMi018700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Jul 2019 17:58:41 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 9BCC64009E71; Wed, 17 Jul 2019 21:58:41 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30486.vci.att.com (Service) with ESMTPS id 89F774009E62; Wed, 17 Jul 2019 21:58:41 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0439.000; Wed, 17 Jul 2019 17:58:41 -0400 From: "STARK, BARBARA H" To: =?iso-8859-1?Q?=27Toke_H=F8iland-J=F8rgensen=27?= , "'Juliusz Chroboczek'" CC: "'Babel at IETF'" Thread-Topic: [babel] info-model: calculated and received metrics Thread-Index: AdT2IrfeBlDu4vVISWCthPLc0HSMMgGGM80ADsRlWAABVTbSQAAYNpIAAAYbGuA= Date: Wed, 17 Jul 2019 21:58:40 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E22B2C2@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E151182@GAALPA1MSGUSRBF.ITServices.sbc.com> <87h8al9ibp.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E20EEFD@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E22A14C@GAALPA1MSGUSRBF.ITServices.sbc.com> <87ftn475cv.fsf@toke.dk> In-Reply-To: <87ftn475cv.fsf@toke.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.225.82] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-17_10:, , 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=556 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907170244 Archived-At: Subject: Re: [babel] info-model: calculated and received metrics X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 21:58:55 -0000 > > I've heard no response to this question. I've confirmed that in TR-181 > > I do have a problem (a uint with value of 0 or NULL will be > > transmitted in a TR-181 data model as 0), because it defines "NULL" > > as: >=20 > In this case, wouldn't NULL be signified by the value being absent? There's a difference between "the parameter doesn't exist within the data m= odel" or "you don't have permission to read this parameter" (both are signi= fied by absence of the parameter in TR-181) and "the parameter exists and y= ou're allowed to read it but its value is NULL". Barbara From nobody Fri Jul 19 06:48:10 2019 Return-Path: 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 2043B1200C3 for ; Fri, 19 Jul 2019 06:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 TOCR9TFL98uE for ; Fri, 19 Jul 2019 06:48:06 -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 C107E12001E for ; Fri, 19 Jul 2019 06:48:06 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x6JDZsqY039125 for ; Fri, 19 Jul 2019 09:48:03 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 2tudgn2agx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 19 Jul 2019 09:48:03 -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 x6JDlwKQ022264 for ; Fri, 19 Jul 2019 09:47:58 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x6JDliRO021947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 19 Jul 2019 09:47:53 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id E3D774009E90 for ; Fri, 19 Jul 2019 13:47:44 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30488.vci.att.com (Service) with ESMTPS id D39BB4009E91 for ; Fri, 19 Jul 2019 13:47:44 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0439.000; Fri, 19 Jul 2019 09:47:44 -0400 From: "STARK, BARBARA H" To: "'Babel at IETF'" Thread-Topic: info-model: babel-interface-metric-algorithm Thread-Index: AdU+OAfuO4WI388dSZq8MEU6L3Ftag== Date: Fri, 19 Jul 2019 13:47:44 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E22EAEB@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.216.137] 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=2019-07-19_09:, , 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=536 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907190156 Archived-At: Subject: [babel] info-model: babel-interface-metric-algorithm X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2019 13:48:08 -0000 Since the metric algorithm used for an interface is now explicitly just one= of the properties of the link properties (babel-link-properties =3D one of= wired, wireless, tunnel, other) associated with the interface, is it usefu= l to have the babel-interface-metric-algorithm identifying the algorithm be= ing used? Or is it sufficient to just indicate the link properties? Barbara From nobody Sun Jul 21 06:46:56 2019 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13EA412016D; Sun, 21 Jul 2019 06:46:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156371680803.20605.16415320733500451468@ietfa.amsl.com> Date: Sun, 21 Jul 2019 06:46:48 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-information-model-07.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 13:46:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : Babel Information Model Authors : Barbara Stark Mahesh Jethanandani Filename : draft-ietf-babel-information-model-07.txt Pages : 28 Date : 2019-07-21 Abstract: This Babel Information Model can be used to create data models under various data modeling regimes. It allows a Babel implementation (via a management protocol or interface) to report on its current state and may allow some limited configuration of protocol constants. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-information-model-07 https://datatracker.ietf.org/doc/html/draft-ietf-babel-information-model-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-information-model-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 21 06:55:56 2019 Return-Path: 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 F01F8120020 for ; Sun, 21 Jul 2019 06:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 sMbfWy-F3Ppn for ; Sun, 21 Jul 2019 06:55:53 -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 58ACD120019 for ; Sun, 21 Jul 2019 06:55:53 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x6LDtq3E021486 for ; Sun, 21 Jul 2019 09:55:53 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2tvfw500d6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 21 Jul 2019 09:55:52 -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 x6LDtpmZ028858 for ; Sun, 21 Jul 2019 09:55:51 -0400 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 x6LDtb4X028616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 21 Jul 2019 09:55:46 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id E3B924009E6C for ; Sun, 21 Jul 2019 13:55:37 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30484.vci.att.com (Service) with ESMTPS id D16B84000351 for ; Sun, 21 Jul 2019 13:55:37 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0439.000; Sun, 21 Jul 2019 09:55:37 -0400 From: "STARK, BARBARA H" To: "'babel@ietf.org'" Thread-Topic: [babel] I-D Action: draft-ietf-babel-information-model-07.txt Thread-Index: AQHVP8rUdaEs4ywxpESlJxeW9+OqhqbVFo/w Date: Sun, 21 Jul 2019 13:55:36 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E23224D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <156371680803.20605.16415320733500451468@ietfa.amsl.com> In-Reply-To: <156371680803.20605.16415320733500451468@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.230.184] 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=2019-07-21_11:, , 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=885 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907210169 Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-07.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 13:55:55 -0000 Hi Babel, Assuming (which is always dangerous) that no one other than me and Mahesh l= ooked at the -06 draft, I went ahead and uploaded an -07 version that fixed= a few things that he and I identified, made some changes according to disc= ussions on the list, and fixed some things I'd forgotten to fix in -06. Barbara What was changed (-06 to -07): * babel-dtls-enable and babel-hmac-enable moved to interfaces and ma= de rw * renamed babel-dtls and babel-hmac to babel-dtls-cert-sets and babe= l-hmac-key-sets and references to them from interfaces are babel-if-dtls-ce= rt-sets and babel-if-hmac-key-sets * https://github.com/bhstark2/babel-information-model/issues/16 with= nits * https://github.com/bhstark2/babel-information-model/issues/14 addr= essing parameters not allowed to be empty/null * https://github.com/bhstark2/babel-information-model/issues/18 on I= ANA link properties table > -----Original Message----- > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Babel routing protocol WG of the IETF. >=20 > Title : Babel Information Model > Authors : Barbara Stark > Mahesh Jethanandani > Filename : draft-ietf-babel-information-model-07.txt > Pages : 28 > Date : 2019-07-21 >=20 > Abstract: > This Babel Information Model can be used to create data models under > various data modeling regimes. It allows a Babel implementation (via > a management protocol or interface) to report on its current state > and may allow some limited configuration of protocol constants. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/=20 From nobody Sun Jul 21 12:03:32 2019 Return-Path: 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 70D7112004E for ; Sun, 21 Jul 2019 12:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 O9n9wsPI0E07 for ; Sun, 21 Jul 2019 12:03:23 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 304ED120127 for ; Sun, 21 Jul 2019 12:03:23 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x6LJ3EKn000642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 21 Jul 2019 21:03:15 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x6LJ3Fgm017844; Sun, 21 Jul 2019 21:03:15 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 82301687CC; Sun, 21 Jul 2019 21:03:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id MCkjU1vqVVem; Sun, 21 Jul 2019 21:03:16 +0200 (CEST) Received: from pirx.irif.fr (91-169-167-30.subs.proxad.net [91.169.167.30]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 58B96687CA; Sun, 21 Jul 2019 21:03:16 +0200 (CEST) Date: Sun, 21 Jul 2019 21:03:17 +0200 Message-ID: <87y30rb47e.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'Babel at IETF'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E22A052@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E150E05@GAALPA1MSGUSRBF.ITServices.sbc.com> <87imv19ier.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E20EE7C@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E22A052@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sun, 21 Jul 2019 21:03:15 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 21 Jul 2019 21:03:15 +0200 (CEST) X-Miltered: at korolev with ID 5D34B6F2.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D34B6F3.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D34B6F2.003 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D34B6F3.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D34B6F2.003 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D34B6F3.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] info-model: link properties X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 19:03:26 -0000 > I've gotten no replies to this email. Absence of reply mean you agree > with using Juliusz' definitions for wired, wireless, and tunnel. But I'm > still unclear as to how to define "other". Maybe "implementation > specific"? Sorry, Barbara, but that is not what I suggested. The underlying properties are what is fundamental to the protocol, and I believe they are what should be exported by the management interface. The link classification is just something that appears in the user interface, and gets translated into the underlying properties. The inverse transformation is not always possible: 2-out-of-3 with split horizon disabled does not correspond to any currently defined link type (that particular combination would be useful for e.g. ATM networks). -- Juliusz From nobody Sun Jul 21 12:23:58 2019 Return-Path: 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 2E37F1200A3 for ; Sun, 21 Jul 2019 12:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 I1OV3zu27YCm for ; Sun, 21 Jul 2019 12:23:56 -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 EC6B7120110 for ; Sun, 21 Jul 2019 12:23:55 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x6LJFRD8001020; Sun, 21 Jul 2019 15:23:53 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 2tvsjsv9p5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 21 Jul 2019 15:23:52 -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 x6LJNqve027537; Sun, 21 Jul 2019 15:23:52 -0400 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 x6LJNjt1027512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 21 Jul 2019 15:23:48 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id B3D454009E6D; Sun, 21 Jul 2019 19:23:45 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30484.vci.att.com (Service) with ESMTPS id A107B4009E6C; Sun, 21 Jul 2019 19:23:45 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0439.000; Sun, 21 Jul 2019 15:23:45 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: "'Babel at IETF'" Thread-Topic: [babel] info-model: link properties Thread-Index: AdT2F3VDc9TEBNBNR0O9GsdDvc4z+AGI9A8ADsNCs5ABVj/PYADdyvSAAAf6vVA= Date: Sun, 21 Jul 2019 19:23:44 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E232EB5@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E150E05@GAALPA1MSGUSRBF.ITServices.sbc.com> <87imv19ier.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E20EE7C@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E22A052@GAALPA1MSGUSRBF.ITServices.sbc.com> <87y30rb47e.wl-jch@irif.fr> In-Reply-To: <87y30rb47e.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.230.184] 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=2019-07-21_13:, , 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=743 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907210224 Archived-At: Subject: Re: [babel] info-model: link properties X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 19:23:57 -0000 > > I've gotten no replies to this email. Absence of reply mean you agree > > with using Juliusz' definitions for wired, wireless, and tunnel. But > > I'm still unclear as to how to define "other". Maybe "implementation > > specific"? >=20 > Sorry, Barbara, but that is not what I suggested. >=20 > The underlying properties are what is fundamental to the protocol, and I > believe they are what should be exported by the management interface. > The link classification is just something that appears in the user interf= ace, and > gets translated into the underlying properties. >=20 > The inverse transformation is not always possible: 2-out-of-3 with split > horizon disabled does not correspond to any currently defined link type (= that > particular combination would be useful for e.g. ATM networks). Oh! I think maybe I understand what you're saying. Let me try to paraphrase= : We don't need to define "link property" names like wired, wireless, or tunn= el. Which means we don't need an IANA registry of such things, and don't need p= arameters based on such an IANA registry. All we really need to do is identify, per interface: (1) the metric calculation algorithm used (2) whether or not split horizon optimization is used (3) whether RTT is used in metric computation (default: in the absence of a= ny mention of RTT by the implementation, RTT is not used) Did I finally get this right? If yes, then my question is whether these 3 items should be individually co= nfigurable on an interface? I actually don't want to include RTT right now, and would prefer for any WG= RTT draft to identify what config (info model) parameters it would need. I= want to avoid a dependency on a RTT draft. Which would leave me with just = algorithm and split horizon parameters. Barbara From nobody Sun Jul 21 13:00:56 2019 Return-Path: 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 9507B120134 for ; Sun, 21 Jul 2019 13:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 yi8Sja8dgCnX for ; Sun, 21 Jul 2019 13:00:52 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 38E7C120135 for ; Sun, 21 Jul 2019 13:00:51 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x6LK0ivB016687; Sun, 21 Jul 2019 22:00:44 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3386D68A50; Sun, 21 Jul 2019 22:00:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Jzo7oxq4Orlb; Sun, 21 Jul 2019 22:00:46 +0200 (CEST) Received: from pirx.irif.fr (91-169-167-30.subs.proxad.net [91.169.167.30]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 47FF268A4D; Sun, 21 Jul 2019 22:00:46 +0200 (CEST) Date: Sun, 21 Jul 2019 22:00:47 +0200 Message-ID: <87tvbfb1jk.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'Babel at IETF'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E232EB5@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E150E05@GAALPA1MSGUSRBF.ITServices.sbc.com> <87imv19ier.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E20EE7C@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E22A052@GAALPA1MSGUSRBF.ITServices.sbc.com> <87y30rb47e.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E232EB5@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 21 Jul 2019 22:00:44 +0200 (CEST) X-Miltered: at korolev with ID 5D34C46C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D34C46C.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D34C46C.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] info-model: link properties X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 20:00:54 -0000 > Which means we don't need an IANA registry of such things, and don't > need parameters based on such an IANA registry. Right. > All we really need to do is identify, per interface: > (1) the metric calculation algorithm used > (2) whether or not split horizon optimization is used > (3) whether RTT is used in metric computation (default: in the absence of any mention of RTT by the implementation, RTT is not used) Right. > If yes, then my question is whether these 3 items should be individually > configurable on an interface? Yes. > I actually don't want to include RTT right now, and would prefer for any > WG RTT draft to identify what config (info model) parameters it would > need. I want to avoid a dependency on a RTT draft. Which would leave me > with just algorithm and split horizon parameters. Agreed. From nobody Sun Jul 21 13:03:42 2019 Return-Path: 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 C9E31120134 for ; Sun, 21 Jul 2019 13:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 UeRAcrdcCDTc for ; Sun, 21 Jul 2019 13:03:33 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 4627712001B for ; Sun, 21 Jul 2019 13:03:33 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x6LK3QAY017493; Sun, 21 Jul 2019 22:03:26 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 1304468A68; Sun, 21 Jul 2019 22:03:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id qQqD-OsoB_wo; Sun, 21 Jul 2019 22:03:28 +0200 (CEST) Received: from pirx.irif.fr (91-169-167-30.subs.proxad.net [91.169.167.30]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id DB9F568A65; Sun, 21 Jul 2019 22:03:27 +0200 (CEST) Date: Sun, 21 Jul 2019 22:03:29 +0200 Message-ID: <87sgqzb1f2.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'Babel at IETF'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E22A322@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E22A322@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 21 Jul 2019 22:03:26 +0200 (CEST) X-Miltered: at korolev with ID 5D34C50E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D34C50E.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D34C50E.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] info-model: question on "k out of j" X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 20:03:36 -0000 > Currently, when reporting what metric calculation algorithms are > supported, the info model supports an enumeration of > "k-out-of-j". I notice that the only "k out of j" algorithm that really > seems to be used is "2 out of 3". Should we replace the generic > "k-out-of-j" with the more specific "2-out-of-3"? Yes. From nobody Mon Jul 22 11:18:18 2019 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6FD120089; Mon, 22 Jul 2019 11:18:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156381949081.11438.10601535195530278878@ietfa.amsl.com> Date: Mon, 22 Jul 2019 11:18:10 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-yang-model-02.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 18:18:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : YANG Data Model for Babel Authors : Mahesh Jethanandani Barbara Stark Filename : draft-ietf-babel-yang-model-02.txt Pages : 34 Date : 2019-07-22 Abstract: This document defines a data model for the Babel routing protocol. The data model is defined using the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-yang-model-02 https://datatracker.ietf.org/doc/html/draft-ietf-babel-yang-model-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-yang-model-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 24 08:59:08 2019 Return-Path: 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 6691812013B for ; Wed, 24 Jul 2019 08:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1dvFuU94aUjt for ; Wed, 24 Jul 2019 08:59:04 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 C91261200B3 for ; Wed, 24 Jul 2019 08:59:03 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x6OFwxwe028319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 24 Jul 2019 17:58:59 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x6OFwxnB029876; Wed, 24 Jul 2019 17:58:59 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 18B80367F8; Wed, 24 Jul 2019 17:59:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Pt1lzbT4o7Do; Wed, 24 Jul 2019 17:59:00 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B8B61367F6; Wed, 24 Jul 2019 17:59:00 +0200 (CEST) Date: Wed, 24 Jul 2019 17:59:02 +0200 Message-ID: <87lfwn77ax.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel-users@lists.alioth.debian.org CC: babel@ietf.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 24 Jul 2019 17:58:59 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 24 Jul 2019 17:58:59 +0200 (CEST) X-Miltered: at korolev with ID 5D388043.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D388043.006 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D388043.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D388043.006 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D388043.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D388043.006 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: [babel] IETF-105: Babel session tonight, remote participation possible X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 15:59:07 -0000 Dear all, This is to remind you that the Babel session at IETF-105 is today at 15:50 Montréal time 21:50 CEST Remote participation is easy -- just go to the IETF-105 agenda: https://datatracker.ietf.org/meeting/agenda/ then search for the Babel session, and click on the camera icon on the right. They will ask you to register, but it's a simple matter of giving your real name and your e-mail. See you tonight, -- Juliusz From nobody Wed Jul 24 14:37:35 2019 Return-Path: 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 CF537120159 for ; Wed, 24 Jul 2019 14:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 l28KZoGHMszF for ; Wed, 24 Jul 2019 14:37:29 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 4A3FB1202EC for ; Wed, 24 Jul 2019 14:37:28 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x6OLapEj020808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 24 Jul 2019 23:36:51 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x6OLapan021996; Wed, 24 Jul 2019 23:36:52 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 58D68377FF; Wed, 24 Jul 2019 23:36:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Y-nCEvBWCwjW; Wed, 24 Jul 2019 23:36:53 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 2773D377FD; Wed, 24 Jul 2019 23:36:53 +0200 (CEST) Date: Wed, 24 Jul 2019 23:36:54 +0200 Message-ID: <87lfwn5d3d.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org CC: Mahesh Jethanandani , Barbara Stark User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 24 Jul 2019 23:36:51 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 24 Jul 2019 23:36:52 +0200 (CEST) X-Miltered: at korolev with ID 5D38CF73.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D38CF73.004 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D38CF73.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D38CF73.004 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D38CF73.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D38CF73.004 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Babel filtering: routing policies X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 21:37:33 -0000 Dear Barbara, dear Mahesh, All distance-vector routing protocols, including BGP and Babel, intrinsically support flexible routing policies. In the Babel community, we consider the way of defining such policies as an implementation feature, and they are not part of the protocol definition. The following therefore applies to babeld, the "reference" implementation. In babeld, we speak about filter chains. A route goes through each filter in a filter chain at four points in Babel: "in" chain, when the route is learnt from a neighbour; "install" chain, when the route is installed in the kernel; "redistribute" chain, when the route is learnt from the kernel; "out" chain, when the route is announced to a neighbour. When a filter chain is applied, the individual filters in a chain are checked, and the first filter that applies to the route is executed. A filter can perfrom the following actions: "allow" -- pass the route unchanged, equivalent to "metric 0"; "deny" -- drop the route; "metric nnn" -- add nnn to the metric value. There exist other actions, more specialised -- see the manual page for details. Babeld implements a rich language for matching routes -- it can match on next-hop address, on destination prefix, on destination prefix length, on the router-id of the originating router, etc. Again, see the manual page for details. Examples ======== ## Default filters in allow out allow redistribute local allow redistribute deny install allow These are the default chains if no filters are defined, and are suitable for a mesh node with no attached prefixes. They say that babeld is promiscuous (it learns all routes and announces all routes), it only redistributes local node addresses, and installs any routes that it learns unchanged. ## Traditional router redistribute proto 2 allow redistribute deny This overrides the default to not redistribute any local addresses, but to redistribute any locally attached prefixes. This is the default behaviour or a traditional router. ## Traditional router with redistribution redistribute proto 2 allow redistribute proto 11 metric 32384 redistribute deny This says to additionally redistribute any routes learned from Zebra/Quagga/FRR, but to attach them with a higher metric -- Babel routes will thus be preferred to FRR routes. ## Stub router redistribute proto 2 allow redistribute deny out ip 192.168.42.0/24 allow out ip 2001:db8:4242::/48 allow out deny This says to learn routes promiscuously, but to only reannounce routes in the given prefixes. This is typical of a stub router, that only announces routes in the local prefixes. ## Default router out ip 0.0.0.0/0 le 0 allow out ip ::/0 le 0 allow out deny This router only announces default routes. ## IPv6 border router in ip ::/0 allow in deny out if eth0 ip 2001:db8:4242::/48 le 48 allow out if eth0 deny out if eth1 ip 2001:db8:5757::/48 le 48 allow out if eth1 deny This router sits at the interface between two networks, and only announces a route summarising a whole network to the other network. This reduces the amount of traffic, at the cost of non-optimal routing. ## Ignoring bad routers in if eth0 nh fe80::1 deny in router-id 12:34:56:78:9a:bc deny in allow This router ignores routes from a given next hop as well as routes originated by a given router-id. This can be used to temporarily blackhole a mis-configured router, before it is fixed. -- Juliusz From nobody Wed Jul 24 14:46:46 2019 Return-Path: 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 721DB120689 for ; Wed, 24 Jul 2019 14:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 MJaBuEdfiSu9 for ; Wed, 24 Jul 2019 14:46:39 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 32D3C120690 for ; Wed, 24 Jul 2019 14:46:39 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x6OLkYOx023066; Wed, 24 Jul 2019 23:46:34 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 8E1983786D; Wed, 24 Jul 2019 23:46:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id jRPpTOwaMsLo; Wed, 24 Jul 2019 23:46:36 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 8C99F3786B; Wed, 24 Jul 2019 23:46:36 +0200 (CEST) Date: Wed, 24 Jul 2019 23:46:38 +0200 Message-ID: <87k1c75cn5.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org CC: Baptiste Jonglez User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 24 Jul 2019 23:46:34 +0200 (CEST) X-Miltered: at korolev with ID 5D38D1BA.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D38D1BA.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D38D1BA.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Open issues with draft-ietf-babel-rtt-extension X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 21:46:45 -0000 Here's my personal take on the issues outlined during Baptiste's talk. 1. Nanosecond granularity Originally, Baptiste's extension used centiseconds in a 16-bit field, which gave a granularity of 10ms. Under Dave Taht's pressure, who was at the time interested in measuring bufferbloat, Baptiste switched to microseconds in a 32-bit field. We still don't have a good example of why this increased prefision is needed -- in the networks that use this extension in production, the time scales under consideration are on the order of tens or hundreds of milliseconds. Switching to nanoseconds would require switching to 48-bit fields, since the timestamps must not wrap between two successfully received Hello or IHU TLVs. Not a big deal, but a slight implementation issue -- I'd like to be convinced that this is necessary. We will be able to switch formats without a flag day. We first define a new sub-TLV with nanosecond granularity, and start sending both. We wait for a year or so, until most deployed implementations understand the new format, then we deprecate the old format. If any old implementations remain, they will ignore the new sub-TLV, and simply fail to perform any RTT estimation, falling back to the base protocol. 2. Decoupling timestamps from Hello Currently, the timestamp data is sent in two pieces: - Hello contains the transmit timestamp, which is the same for all neighbours; - IHU contains the receive timestamp and the timestamp echo, which are per-neighbour. This makes a lot of sense -- after all, IHUs contain per-neighbour data, while sender data is contained in Hellos. OTOH, it means that an IHU's timestamp can only be interpreted if it is sent in a packet that contains a Hello TLV. Baptiste outlined two solutions: (a) require that all IHUs be sent in packets with a Hello; (b) define a new TLV that contains just a timestamp. In RFC 6126bis, we defined Unicast Hellos and Unscheduled Hellos, which should in principle make approach (a) easy to implement. I'd be very grateful if people could look very carefully at the new kinds of Hello, and decide whether these mechanisms are enough, or whether we need a new kind of TLV so we can avoid sending spurious Hellos. -- Juliusz From nobody Thu Jul 25 03:56:10 2019 Return-Path: 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 D70D412002F for ; Thu, 25 Jul 2019 03:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (2048-bit key) header.d=toke.dk 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 q6i71ADDx00W for ; Thu, 25 Jul 2019 03:56:05 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [IPv6:2a00:7660:6da:2001::664]) (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 3B6C0120139 for ; Thu, 25 Jul 2019 03:56:05 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1564052161; bh=NPqYv6VfCt+hgRA2gzdpLPHH9D41adCwH4lIdFhcILs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=PXsrg1uiVQlse1qBGrKby1e9n4KhsY3h+AuO9v2tT2yjulAPIm+j5aQRv4gge32jb dZ4CNYjAEn7tokiSNvgNrsJ1pThKGOOQZLLOtObDxFfmge/fvHK6OaLGMFwbuyjFNn pHVUw5alQbRWoza8p6Qm/s8OC3Kg08TEdouPXkMX67sjT2kGTANqqhS9VSi5aXE2yX 02wpiJNjVU9E8M75X2+vjLcFVGwyY8fUhUGJii3aYvAErY2f/BMPbrgy5MNbJtnhQz 6FfFR1SAou89Gn4NZeM60kz5Hca3lZECrGPIfulQO4mAQi6fma2pzTg5OpaVW7TgGT nlw2EE9QnGKrA== To: Juliusz Chroboczek , babel@ietf.org Cc: Mahesh Jethanandani , Barbara Stark In-Reply-To: <87lfwn5d3d.wl-jch@irif.fr> References: <87lfwn5d3d.wl-jch@irif.fr> Date: Thu, 25 Jul 2019 12:56:00 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87blxiz8lb.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Babel filtering: routing policies X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 10:56:08 -0000 Juliusz Chroboczek writes: > Dear Barbara, dear Mahesh, > > All distance-vector routing protocols, including BGP and Babel, > intrinsically support flexible routing policies. In the Babel community, > we consider the way of defining such policies as an implementation > feature, and they are not part of the protocol definition. > > The following therefore applies to babeld, the "reference" > implementation. I'll add that the Bird implementation uses Bird's filtering language, which allows filtering similar to that but has a whole different syntax and semantics. See https://bird.network.cz/?get_doc&v=20&f=bird-5.html for details. -Toke From nobody Thu Jul 25 04:06:42 2019 Return-Path: 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 3EDC81200E6 for ; Thu, 25 Jul 2019 04:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (2048-bit key) header.d=toke.dk 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 bHfzVYfuFaQ8 for ; Thu, 25 Jul 2019 04:06:38 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 05E481200DE for ; Thu, 25 Jul 2019 04:06:38 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1564052795; bh=9on86+vfqANdlWgooFGcIoUki3FZIcqR8e2HnWVU3bs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=N7WBXmC+pqVJYsvkOHArz29P1+OsXlC0TZhIfDCFZ8ose46iaiuivATmZE+iFDAzC FHolijuTEQ+Ng8/uRY5R9saAoM7wUzBsBeFT6Q5XxOMA2nGu4JNfWsxgfVgjreGnQz WlDabmsxUL400P+YlwRBnAOulpC5GCQGWlE0+HzSaQJSrwFT/lBwg/2wtkM71tdNJ2 fhbM8E/NXJnhplfHDCo/VRxwizKMyTJjvWWxlkWzZ0YgwWtHk0xB8MeUcLPgkq74CS RjQE7qCbN2wYFIuV558MgC1sHgwZAiOID5kR/+80cLBgoXKoIe5RoDYlRParv9TFSx XA/iBeX9EHmKQ== To: Juliusz Chroboczek , babel@ietf.org Cc: Baptiste Jonglez In-Reply-To: <87k1c75cn5.wl-jch@irif.fr> References: <87k1c75cn5.wl-jch@irif.fr> Date: Thu, 25 Jul 2019 13:06:34 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <878ssmz83p.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Open issues with draft-ietf-babel-rtt-extension X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 11:06:40 -0000 Juliusz Chroboczek writes: > Here's my personal take on the issues outlined during Baptiste's talk. > > 1. Nanosecond granularity > > Originally, Baptiste's extension used centiseconds in a 16-bit field, > which gave a granularity of 10ms. Under Dave Taht's pressure, who was at > the time interested in measuring bufferbloat, Baptiste switched to > microseconds in a 32-bit field. > > We still don't have a good example of why this increased prefision is > needed -- in the networks that use this extension in production, the time > scales under consideration are on the order of tens or hundreds of > milliseconds. > > Switching to nanoseconds would require switching to 48-bit fields, since > the timestamps must not wrap between two successfully received Hello or > IHU TLVs. Not a big deal, but a slight implementation issue -- I'd like > to be convinced that this is necessary. > > We will be able to switch formats without a flag day. We first define > a new sub-TLV with nanosecond granularity, and start sending both. We > wait for a year or so, until most deployed implementations understand the > new format, then we deprecate the old format. If any old implementations > remain, they will ignore the new sub-TLV, and simply fail to perform any > RTT estimation, falling back to the base protocol. We could also just define a new sub-TLV with the added precision, couldn't we? I.e., keep the usecs and add 10 additional bits with the sub-usec fraction. Either way I'm fine with holding off on defining this until we have demonstrated that it's useful. > 2. Decoupling timestamps from Hello > > Currently, the timestamp data is sent in two pieces: > > - Hello contains the transmit timestamp, which is the same for all > neighbours; > - IHU contains the receive timestamp and the timestamp echo, which are > per-neighbour. > > This makes a lot of sense -- after all, IHUs contain per-neighbour data, > while sender data is contained in Hellos. OTOH, it means that an IHU's > timestamp can only be interpreted if it is sent in a packet that contains > a Hello TLV. > > Baptiste outlined two solutions: > > (a) require that all IHUs be sent in packets with a Hello; > (b) define a new TLV that contains just a timestamp. > > In RFC 6126bis, we defined Unicast Hellos and Unscheduled Hellos, which > should in principle make approach (a) easy to implement. I'd be very > grateful if people could look very carefully at the new kinds of Hello, > and decide whether these mechanisms are enough, or whether we need a new > kind of TLV so we can avoid sending spurious Hellos. I haven't looked very carefully, but I think you are probably right that we *can* make do with this. A separate timestamp TLV seems architecturally cleaner to me, though, although I can't really explain why... -Toke From nobody Thu Jul 25 04:34:34 2019 Return-Path: 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 EEFE612013C for ; Thu, 25 Jul 2019 04:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 QEryjkNs85uJ for ; Thu, 25 Jul 2019 04:34:30 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 E87A5120025 for ; Thu, 25 Jul 2019 04:34:29 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x6PBYPfP024793; Thu, 25 Jul 2019 13:34:25 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 42BD53ABF9; Thu, 25 Jul 2019 13:34:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id KAZdG6_7_g12; Thu, 25 Jul 2019 13:34:27 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0C2C03ABF7; Thu, 25 Jul 2019 13:34:27 +0200 (CEST) Date: Thu, 25 Jul 2019 13:34:28 +0200 Message-ID: <878ssmuz3v.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: babel@ietf.org, Baptiste Jonglez In-Reply-To: <878ssmz83p.fsf@toke.dk> References: <87k1c75cn5.wl-jch@irif.fr> <878ssmz83p.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 25 Jul 2019 13:34:25 +0200 (CEST) X-Miltered: at korolev with ID 5D3993C1.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D3993C1.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D3993C1.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Open issues with draft-ietf-babel-rtt-extension X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 11:34:32 -0000 > I haven't looked very carefully, but I think you are probably right that > we *can* make do with this. A separate timestamp TLV seems > architecturally cleaner to me, though, although I can't really explain > why... I have the same feeling. From nobody Thu Jul 25 06:06:27 2019 Return-Path: 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 3B2AE12015F for ; Thu, 25 Jul 2019 06:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 LFhctI9iYnwI for ; Thu, 25 Jul 2019 06:06:23 -0700 (PDT) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0053A12002E for ; Thu, 25 Jul 2019 06:06:22 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id j6so21891238ioa.5 for ; Thu, 25 Jul 2019 06:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Q5bR1jZX22Ex78+7hJjUk27/Z5iC6RLWpKPuj1Ds0g0=; b=kGr8gWSKqZHEOMjHDsWQ6yjkIs8TlKXfbjSz7k97dnzFXuW+CfJX6iqmyaHXSzVsfD ZJEnp9on7l5aI6x6yskX54X8lHiSEkQaxoX5+VAuOAWBQjdXk2M2U0FVt/0crb07cPqZ VM745zlw/wcTEY0MQRL4JyhNqCbZWq59Q6XgJr9wQVwm4tsNTawKKG7mMO8mWlwpDSlN cUzKDLW/u3Oxwg2bmq7d5WjYDTDIQeH6fUqbz7nVhKVxSwjMdCjH8S2iBaYygUqgYRBg WhQcI4hWrqi5GM255RFJaV3KiRQrJfeQ+alrq8FUtHRPteJedfBdyLIzVUu9eGZNWpKD Ywdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Q5bR1jZX22Ex78+7hJjUk27/Z5iC6RLWpKPuj1Ds0g0=; b=kfdqlEhn6lRwouYbBD5zIrO7njGYKIPp65eHoAvbH9ktk1/k3Z7Us8EAvl8ArZ9uRi 3nRQlLhwxbPFNZoNfwezBsv+qSqY9vtBZQ4/gJs5djvoBcXPPEXCkc5yTP71RW9iiO/V BQYOFwGu256SLQzBnHnGDlM17QQ231byKNT2D+D2Uw42U6dWxQ7usoDEGPcmaL5hr0Z/ PuaH37QMI9oUxqv+FX5W3vi/tymS2oOwN5XjS71sE9EJjLkpjcY8VpOfLx8RYd37SPEz ewUgRmE5eI2UPiLGuarQKkvt3RTJNLCu2lqWeAuFVWDwtzSzDQRpdoHmYCuqsDjiJ+Cw Rzjw== X-Gm-Message-State: APjAAAXw37Rly8DLndo441yg8vaxOpgOe27D4jzqRjcIC98XSRLf6jhM AFVclcfaKwNimgPjETcNJADg9WLjcEI5gYcyFic= X-Google-Smtp-Source: APXvYqyiXAtLwS3bSfTcYV6PX2wjH5jOu5IFqH4LRvvADBpx28qWccYccrLpbntc/EdMGY53Ir8yhFJthm+ZZq9xeyc= X-Received: by 2002:a05:6602:2183:: with SMTP id b3mr69975512iob.249.1564059982048; Thu, 25 Jul 2019 06:06:22 -0700 (PDT) MIME-Version: 1.0 References: <87k1c75cn5.wl-jch@irif.fr> In-Reply-To: <87k1c75cn5.wl-jch@irif.fr> From: Dave Taht Date: Thu, 25 Jul 2019 06:06:10 -0700 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF , Baptiste Jonglez Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Open issues with draft-ietf-babel-rtt-extension X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 13:06:25 -0000 I had had a chance to buttonhole baptiste at battlemesh, and also tried to get a test up and running. A couple points. A) Packet loss is not much of a thing on modern wifi networks, particularly with unicast B) As you have larger numbers of routes (1000s), congestion control becomes a problem My "solution" for some congestion control issues is to start dynamically increasing the route announcement interval for stabler routes, while still announcing the most important ones (like defaults) in the hello. the protocol has an underused feature where we can announce a per route interval larger than the default. i long ago patched out CS6 as it lands in the VO queue which cannot aggregate on wireless-n in favor of ecn. I've had a variant that just ecn's the hello, also. Most of my babel routing failures were congestive in nature before I did this. (I also, in the end dramatically reduced the size of my route table and the size of the babel network, at one point it was 100+ nodes with ~10 route announcements each which became rather unreliable. Now, it's < 20 with ~3). I do wish more folk would do the kind of experiments teco did to test larger babel networks, and I did with the rtod tool on github. Until more core folk start pushing the protocol (and daemons) to larger numbers of routes we're not going to have mutually clear insights here. On Wed, Jul 24, 2019 at 2:46 PM Juliusz Chroboczek wrote: > > Here's my personal take on the issues outlined during Baptiste's talk. > > 1. Nanosecond granularity > > Originally, Baptiste's extension used centiseconds in a 16-bit field, > which gave a granularity of 10ms. Under Dave Taht's pressure, who was at > the time interested in measuring bufferbloat, Baptiste switched to > microseconds in a 32-bit field. I have largely been waiting for all the other stuff to land before pursuing these ideas again. Needed SS routing, thought unicast would change the game on wifi entirely. > We still don't have a good example of why this increased prefision is > needed -- in the networks that use this extension in production, the time > scales under consideration are on the order of tens or hundreds of > milliseconds. It certainly was my hope at the time to be able to extend this to real networks, on wifi. nsec resolution is not required there either, but 10s of usec precision seemed feasible at the time. nsec might buy some better ability to detect (when coupled with the increasingly common hw timestamping and/or hw pacing techniques) - 1gigE+ networks. > Switching to nanoseconds would require switching to 48-bit fields, since > the timestamps must not wrap between two successfully received Hello or > IHU TLVs. Not a big deal, but a slight implementation issue -- I'd like > to be convinced that this is necessary. > > We will be able to switch formats without a flag day. We first define > a new sub-TLV with nanosecond granularity, and start sending both. We > wait for a year or so, until most deployed implementations understand the > new format, then we deprecate the old format. If any old implementations > remain, they will ignore the new sub-TLV, and simply fail to perform any > RTT estimation, falling back to the base protocol. I don't presently see a need for nsec. > 2. Decoupling timestamps from Hello > > Currently, the timestamp data is sent in two pieces: > > - Hello contains the transmit timestamp, which is the same for all > neighbours; > - IHU contains the receive timestamp and the timestamp echo, which are > per-neighbour. > > This makes a lot of sense -- after all, IHUs contain per-neighbour data, > while sender data is contained in Hellos. OTOH, it means that an IHU's > timestamp can only be interpreted if it is sent in a packet that contains > a Hello TLV. > > Baptiste outlined two solutions: > > (a) require that all IHUs be sent in packets with a Hello; > (b) define a new TLV that contains just a timestamp. > > In RFC 6126bis, we defined Unicast Hellos and Unscheduled Hellos, which > should in principle make approach (a) easy to implement. I'd be very > grateful if people could look very carefully at the new kinds of Hello, > and decide whether these mechanisms are enough, or whether we need a new > kind of TLV so we can avoid sending spurious Hellos. Generically I had looked as this as a path forward to getting congestive controls to start working, leveraging the must-ack tlv also, whatever it's called. So being able to include a timestamp at the end of a route burst seemed helpful. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel -- Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Thu Jul 25 07:57:22 2019 Return-Path: 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 3EE6A1200E3 for ; Thu, 25 Jul 2019 07:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 e5K7t7Y3lsza for ; Thu, 25 Jul 2019 07:57:18 -0700 (PDT) Received: from zm-mta-out-1.u-ga.fr (zm-mta-out-1.u-ga.fr [152.77.200.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CDB912006D for ; Thu, 25 Jul 2019 07:57:15 -0700 (PDT) Received: from zm-mta-out.u-ga.fr (zm-mta-out.u-ga.fr [152.77.200.58]) by zm-mta-out-1.u-ga.fr (Postfix) with ESMTP id 1A01CA0385; Thu, 25 Jul 2019 16:57:13 +0200 (CEST) Received: from smtps.univ-grenoble-alpes.fr (smtps.univ-grenoble-alpes.fr [152.77.1.30]) by zm-mta-out.u-ga.fr (Postfix) with ESMTP id 0C993E00A3; Thu, 25 Jul 2019 16:57:13 +0200 (CEST) Received: from imag.fr (blaine.imag.fr [129.88.55.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jonglezb@univ-grenoble-alpes.fr) by smtps.univ-grenoble-alpes.fr (Postfix) with ESMTPSA id 0877C125EB7; Thu, 25 Jul 2019 16:57:13 +0200 (CEST) Date: Thu, 25 Jul 2019 16:57:11 +0200 From: Baptiste Jonglez To: Toke =?iso-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: Juliusz Chroboczek , babel@ietf.org Message-ID: <20190725145711.vwklw4epew3tkxgo@imag.fr> References: <87k1c75cn5.wl-jch@irif.fr> <878ssmz83p.fsf@toke.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zsup3qazi7dajz3x" Content-Disposition: inline In-Reply-To: <878ssmz83p.fsf@toke.dk> User-Agent: NeoMutt/20170113 (1.7.2) X-Greylist: Whitelist-UGA SMTP Authentifie (jonglezb@univ-grenoble-alpes.fr) via smtps-465 ACL (112) Archived-At: Subject: Re: [babel] Open issues with draft-ietf-babel-rtt-extension X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 14:57:21 -0000 --zsup3qazi7dajz3x Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 25, 2019 at 01:06:34PM +0200, Toke H=F8iland-J=F8rgensen wrote: > Juliusz Chroboczek writes: > > 2. Decoupling timestamps from Hello > > > > Currently, the timestamp data is sent in two pieces: > > > > - Hello contains the transmit timestamp, which is the same for all > > neighbours; > > - IHU contains the receive timestamp and the timestamp echo, which are > > per-neighbour. > > > > This makes a lot of sense -- after all, IHUs contain per-neighbour data, > > while sender data is contained in Hellos. OTOH, it means that an IHU's > > timestamp can only be interpreted if it is sent in a packet that contai= ns > > a Hello TLV. > > > > Baptiste outlined two solutions: > > > > (a) require that all IHUs be sent in packets with a Hello; > > (b) define a new TLV that contains just a timestamp. > > Thank you for summarizing. You apparently didn't like my "Solution 1" because you don't even mention it, but I agree it's a bad idea anyway :) The slides of my presentation are here: https://datatracker.ietf.org/meetin= g/105/materials/slides-105-babel-delay-based-metric-extension-for-the-babel= -protocol-00 > > In RFC 6126bis, we defined Unicast Hellos and Unscheduled Hellos, which > > should in principle make approach (a) easy to implement. I'd be very > > grateful if people could look very carefully at the new kinds of Hello, > > and decide whether these mechanisms are enough, or whether we need a new > > kind of TLV so we can avoid sending spurious Hellos. > > I haven't looked very carefully, but I think you are probably right that > we *can* make do with this. A separate timestamp TLV seems > architecturally cleaner to me, though, although I can't really explain > why... I also think unicast/unscheduled Hellos can make (a) work without further hacks, but indeed it feels somewhat uncomfortable that Hello messages are used for several roles (neighbour discovery and maintenance, link quality estimation, RTT estimation). It works if these roles don't conflict, but it's walking on a tightrope, as the Unscheduled Hello "hack" shows. The main issue is that we lack practical experience on this: I didn't check all implementations, but it seems that nobody actually implemented unicast Hellos yet? --=20 Baptiste Jonglez PhD student Univ. Grenoble Alpes LIG lab Drakkar team | Polaris team at INRIA --zsup3qazi7dajz3x Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEktPR7/7QieSQeRfBok0RNW6j3zkFAl05w0MACgkQok0RNW6j 3znGkA/9G2GRVmmV9HudGrqLYtLkO9YM8bd4bRD++T3q16LvUfoyNT4Ia85qIYPO akHPVvif66jpVFsMuvlSeCK98Y9zu1RW+HyM0UzLiHPEGfB6C+6w9PSXcNmopR4S v9unBLx9zsYMJXSrSy/ZwkkgO+/i4YcIC9/y45XXifN1ZHKJMp8v1TfuI4oQOSEG ppkT7pcPLbtXD/OYn2c2W78kljCMcJrUK6T+8pQz0LQKfOmAcVzdsJNCU1j7PN9m GVWJXZAq1Lxyl/AxRpDtAJDdrcUkxXsvnOtsGLSvChpT4Yd9Rth2au9wJX9K+nmV otp63l/VYjD7dgY5ZmjfOvgfP2ya2kPThI2NbSW/KGZnJU2zrNh4ao+SfQMOWWLj hGaX9cb5lmoTnUukVo+4FT5tx/a8yhHP+Z3/g8zlVuV+4Oe/eD0HUaNzZwmAvALc HoP0JrcHftbU6gipysp/+8e3q5gEVEo+2+fUJJijxTXlNNYZgTfvl2wzObMjaphv cmqvydKVDzIzjKCmlShnLrj9nFKX4VBGe68JZ3TOvNSgwdNUVC9RI6zZvyWDtI1n rDhd22ulZ0u+33prmlWJ36tVvdQt5DDlkS2IPUmBaBNzV7W8/zJ4xcQ+qrMETUNi slqXvv+dnnx82/Jxbr1MMWtcFjGmvzF+gbih9dub+xiuiTPx/nY= =Ou5t -----END PGP SIGNATURE----- --zsup3qazi7dajz3x-- From nobody Thu Jul 25 08:13:54 2019 Return-Path: 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 9FBB9120398 for ; Thu, 25 Jul 2019 08:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 CnDqCwOH0Vrz for ; Thu, 25 Jul 2019 08:13:44 -0700 (PDT) Received: from zm-mta-out-1.u-ga.fr (zm-mta-out-1.u-ga.fr [152.77.200.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C352C120319 for ; Thu, 25 Jul 2019 08:13:34 -0700 (PDT) Received: from zm-mta-out.u-ga.fr (zm-mta-out.u-ga.fr [152.77.200.58]) by zm-mta-out-1.u-ga.fr (Postfix) with ESMTP id 29E94A02EB; Thu, 25 Jul 2019 17:13:33 +0200 (CEST) Received: from smtps.univ-grenoble-alpes.fr (mailhost.u-ga.fr [152.77.1.30]) by zm-mta-out.u-ga.fr (Postfix) with ESMTP id 2518CE00A3; Thu, 25 Jul 2019 17:13:33 +0200 (CEST) Received: from imag.fr (blaine.imag.fr [129.88.55.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jonglezb@univ-grenoble-alpes.fr) by smtps.univ-grenoble-alpes.fr (Postfix) with ESMTPSA id 1FDE7125EB9; Thu, 25 Jul 2019 17:13:33 +0200 (CEST) Date: Thu, 25 Jul 2019 17:13:32 +0200 From: Baptiste Jonglez To: Barbara Stark , Mahesh Jethanandani Cc: babel@ietf.org Message-ID: <20190725151332.ywxjpxpxoritx4ql@imag.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ijfacgroonlkdlm5" Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) X-Greylist: Whitelist-UGA SMTP Authentifie (jonglezb@univ-grenoble-alpes.fr) via smtps-465 ACL (112) Archived-At: Subject: [babel] Babel-RTT information model and example parameters X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 15:13:50 -0000 --ijfacgroonlkdlm5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Barbara, Mahesh, The discussion about the information model yesterday and Juliusz' email on policies got me thinking about the parameters of the babel-rtt extension. Should the information model specify parameters that are not really part of the spec? I'm thinking of the example function for metric computation and its 3 parameters rtt-min, rtt-max, max-rtt-penalty: https://tools.ietf.org/html/draft-ietf-babel-rtt-extension-00#section-2.2= =2E1 This metric function is just an example: an implementation is free to do something totally different. So, does it make sense to add the corresponding parameters (as ro or rw) to the information model? Sorry if this is a dumb question, I'm quite new to this information model /= YANG thing. Thanks, --=20 Baptiste Jonglez PhD student Univ. Grenoble Alpes LIG lab Drakkar team | Polaris team at INRIA --ijfacgroonlkdlm5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEktPR7/7QieSQeRfBok0RNW6j3zkFAl05xxgACgkQok0RNW6j 3zkf0g//Zo1wdFkMazWRDlwv75q2/YDIt0WT231H3qR6pb7EAVHxTfFyIhwvmJov VNRfcWZYqOhac57roL2h8RO/xJQ1dsAZXDn9gkgO2I5y3gkB3VV9VEf4Q12p4E08 wsBJ1tJTzS7wk9ZhIn+02erjKHBhgV5PtpfsQ8FCpufmsaPlav5QSzxNQ93BnJ7W ySEYHDgpSPeMMQHxQDXOxLUjqM8MREmJ0Jk2OD1xgP0WTBkER49ndu7f7b/0y9c0 joFg4L2s1BRkebZrb+nJfrUVz3/wJoFkMKaxRl6TwaMTiOmfd2siRAuOI2tL2c+d RJSlM8VDAoOQ3FuFTScKBsfP9ex6+/cG0sYpfCqvrZkfgmcQE5hi/jg2ee9U+U9n jh/owr2B3XUFdkwHqO6UrKNIlLJV/tNMkF3SaJ/XNhYytoue9UDGI9SXG6H6/A+i iOtCsBAI5LHw3BfPnsSGArlGJug8mfsxk94XkWA9zGM01Gz/IbITPDVDEZXLuiAc 95JNPtjcgQU/iFcw9V6a5JTt4JvLBhE8LTTQ5PR9oBbZe3TbGLC61IQavCjpGYFy NRohhaRo3L8rXrHOaOF+HUO9Zhauk2GVIKHouQL7XnUKCxd3ry8E24RHMn5zqXng 9XaDJ8jfM40zByzOiAPU6pgtlFiJGXP2+fX6Ml67pIwH0WMzdbg= =Yw8w -----END PGP SIGNATURE----- --ijfacgroonlkdlm5-- From nobody Thu Jul 25 09:52:25 2019 Return-Path: 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 21235120155 for ; Thu, 25 Jul 2019 09:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 2MWEinAL7UG9 for ; Thu, 25 Jul 2019 09:52:21 -0700 (PDT) Received: from zm-mta-out-1.u-ga.fr (zm-mta-out-1.u-ga.fr [152.77.200.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874CC12013E for ; Thu, 25 Jul 2019 09:52:09 -0700 (PDT) Received: from zm-mta-out.u-ga.fr (zm-mta-out.u-ga.fr [152.77.200.58]) by zm-mta-out-1.u-ga.fr (Postfix) with ESMTP id BE953A03C2; Thu, 25 Jul 2019 18:52:07 +0200 (CEST) Received: from smtps.univ-grenoble-alpes.fr (smtps1.u-ga.fr [152.77.1.30]) by zm-mta-out.u-ga.fr (Postfix) with ESMTP id BA933E00AF; Thu, 25 Jul 2019 18:52:07 +0200 (CEST) Received: from imag.fr (blaine.imag.fr [129.88.55.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jonglezb@univ-grenoble-alpes.fr) by smtps.univ-grenoble-alpes.fr (Postfix) with ESMTPSA id B82BA125EB7; Thu, 25 Jul 2019 18:52:07 +0200 (CEST) Date: Thu, 25 Jul 2019 18:52:06 +0200 From: Baptiste Jonglez To: babel-users@lists.alioth.debian.org, babel@ietf.org Message-ID: <20190725165206.m6xj4kjcfo42xmqb@imag.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fwi3f2lcpllsusts" Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) X-Greylist: Whitelist-UGA SMTP Authentifie (jonglezb@univ-grenoble-alpes.fr) via smtps-465 ACL (112) Archived-At: Subject: [babel] Accuracy of timestamps for babel-rtt: userspace vs kernel timestamps X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 16:52:23 -0000 --fwi3f2lcpllsusts Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, A recent discussion with Dave convinced me to start looking at whether very short RTTs make any sense in Babel, and whether they could be used to infer link speed. If only to settle theses questions for good. Since the related subject of nanosecond-resolution timestamps was brought up by Toke at the IETF session yesterday, I made a quick test with kernel timestamps today. I'll talk about the implementation and shortcomings of using kernel timestamps below, but here are some rough timing results. I just used a veth pair on my laptop (4.17 kernel) with a babeld on each side of the pair, and didn't do any serious statistics. - regular babeld: average measured RTT ~320 =B5s (quite variable) - babeld with kernel RX timestamps: average measured RTT ~120 =B5s (quite v= ariable) - ping through the same veth pair (link-local IPv6, 1000 packets): average = 105 =B5s, minimum 16 =B5s The observant reader will notice that the current resolution (1 =B5s) is more than enough in that case. Also, using kernel timestamps improves accuracy by about 100 =B5s on each host, a somewhat significant improvement. Now, regarding the implementation of kernel timestamps in babeld, my test c= ode is here: https://github.com/jonglezb/babeld/commit/56756a8cbe9a0b8a168c78873dd77e4= 8e5770278 Thank you Dave for your first draft of this code, I borrowed a bit from it = ;) As explained in the commit message, it suffers from a number of issues that would need some serious work before it's really usable: - kernel timestamps use the realtime clock, and it's not configurable. This is really annoying because babeld uses the monotonic clock (for good reasons). Using kernel timestamps forces us to fall back to the realtime clock elsewhere in babeld, and it would require some work to do it cleanly. - kernel timestamps are only used for received packets. The sending side (timestamp in Hello) still uses userspace timestamps, with the ensuing accuracy issue. It does not seem possible to tell the kernel to embed a timestamp at a specified location in a packet just before sending it, unless maybe playing with eBPF. Takeaway: at least on Linux, I don't see a use-case for nanosecond resolution timestamps. If somebody ever writes an implementation of Babel for specialized hardware and runs a datacenter with ultra-low-latency network equipments, it could possibly still make sense. --=20 Baptiste Jonglez PhD student Univ. Grenoble Alpes LIG lab Drakkar team | Polaris team at INRIA --fwi3f2lcpllsusts Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEktPR7/7QieSQeRfBok0RNW6j3zkFAl053jAACgkQok0RNW6j 3zn/dg/9GyZPofu3igqBlHLPpWZcy4WsXK0HYLP3mO5UFVQKUKCy6tBmrR+4q4yF 0Q4/4yBRYSeFrP35AXqj9YluvvvSYGb/EC/mgHTGTG2CEBD0S0SlozU/p2BS8G/e 9fA+C4mB9Z7jQmu5XcQXZZY9IMrrt6qouOF+3N/qrbO/9cg4ExgO6R7iZIDL9ZfC 237MrjcRC9O/D12hx49mHVl3/SGioQoPFTN53ae5Kv6HYPtf64Lj9V1Cd5j6Eu9l uXcxUIXDAZtYwEQ9LAjgJEq0gXm3FEbYFttfKI65pHpMjZp+seei3H5ppttoeDT4 809FkDb9bnoCe7sH1bZ44Mt//qBwJ0HIqB2SlcQREkKuU01axrQZZeQ5jiqMYl++ KUgCo7ycPxFiSkbfSUcFx+jtnzU3mrh7IpJphWXX1txWWzxuVg9N/9+jRayzggM8 J3hmoSHwP4aKQVtqkwMHqq7L4JKR3+iWq5Mp7x24WbX7Txkld+UTu3HbMC5Sxphw WFLorbNf4wB6J2xIGxZdbX3fmeLQb7vAnJXckUsr3+kAfnZvGHMP2cX0Qnl7QgMD 8WvS6f7Hm83wqhOBAokTAbt+j+jlKoNb5C5dHZdBejI3K+lgnvzbhFYl7tQ111/r qrkEDmKzeYE+w2kUfJN8Kwk5yU4WaXlPAalbq4bLbTB7seV2HAQ= =x/Iq -----END PGP SIGNATURE----- --fwi3f2lcpllsusts-- From nobody Thu Jul 25 11:52:26 2019 Return-Path: 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 0A8301201B8 for ; Thu, 25 Jul 2019 11:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 sFWwX79gUf7B for ; Thu, 25 Jul 2019 11:52:22 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 0CAD01201B0 for ; Thu, 25 Jul 2019 11:52:21 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x6PIqHq3021158; Thu, 25 Jul 2019 20:52:17 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 245133DC68; Thu, 25 Jul 2019 20:52:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Fd3Q5BWamJFw; Thu, 25 Jul 2019 20:52:19 +0200 (CEST) Received: from pirx.irif.fr (unknown [109.190.253.14]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7EACA3DC66; Thu, 25 Jul 2019 20:52:17 +0200 (CEST) Date: Thu, 25 Jul 2019 20:52:18 +0200 Message-ID: <87h87arlp9.wl-jch@irif.fr> From: Juliusz Chroboczek To: Baptiste Jonglez Cc: babel-users@lists.alioth.debian.org, babel@ietf.org In-Reply-To: <20190725165206.m6xj4kjcfo42xmqb@imag.fr> References: <20190725165206.m6xj4kjcfo42xmqb@imag.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 25 Jul 2019 20:52:17 +0200 (CEST) X-Miltered: at korolev with ID 5D39FA61.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D39FA61.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D39FA61.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Accuracy of timestamps for babel-rtt: userspace vs kernel timestamps X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 18:52:24 -0000 > - regular babeld: average measured RTT ~320 µs (quite variable) > - babeld with kernel RX timestamps: average measured RTT ~120 µs (quite variable) Interesting. Is the variance similar, or is it smaller with kernel timestamps? -- Juliusz From nobody Thu Jul 25 13:29:01 2019 Return-Path: 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 BBD101201F2 for ; Thu, 25 Jul 2019 13:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 d9HPADMPMvtZ for ; Thu, 25 Jul 2019 13:28:57 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00AF61201EF for ; Thu, 25 Jul 2019 13:28:56 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id h6so13479282iom.7 for ; Thu, 25 Jul 2019 13:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tfB+xW97ZeFgpXv3LLOiGjW62Y6vqRVjYgkMpfNfAq4=; b=mF2eFXsskmJO3SA9zZCE4eo7+HcsJhcHsXS3HScMRBj7VPBvO45H4mxU2dXla7kPHY coX1MCu0aqSRJW8RoxeUg+QHCwy3YMnzRsxAMG/JAV7IkqIRrcUtTZMqqJZDMG+pfYDN 6HPUzAMNISm6MVMiJP33gRwsORZg8Md0DisJD5lXcyGQGh2d952mu3U0+6232uk6MXs5 BbGde31sr2pU7i1x75bWXj/WUYOomg+4Y8kvxOVLz2Ce9zQLDzPN6kznSIhD3LvizaCf MEyRsubPZ1p7Ck9ZwRfirWXeDb239GNuuLTkO70bmPXOwHhplcl15ugC4R4vkCC3k3nb PABA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tfB+xW97ZeFgpXv3LLOiGjW62Y6vqRVjYgkMpfNfAq4=; b=CpP3lWsb78nPjjuIps0ECWzNfynAaoC+HemxDWX52xaDwe2CagQEi83rvYr3bTpB0a fOsthFXvwDG1Wzlq0HtbDR/4P8ngI1owQitUJdXOA+WNsGY9Kd/JbHaPCkB40mlqVG0v iTvQrQFyXwLGAZ2JHaBtk9wEJN5rHHaGJUBhEhciqISFl+Khc7pe4Wwsh3lixGBtnUVk RAKUFBAT1SBiMDnMUx4724oqcBaXh7sLt+7oSkka8nMZ41I3jGr7DIP0bmEFd74++rz+ BD0MbUWb7lJ1zfZWHxVSPsz3gJ40i0xBM2/brbSAqRbN/gxBEZh2Lh+fvpg29MtRaMJk fXeg== X-Gm-Message-State: APjAAAXkadKFARsBsyngpfbH+bcBHTugxyUEDnpdwidN3W4vL0u8jDAP NMR8NdchAlR6dpmNA3kxsAPnvpeJfN3EjEqtaq1/HQ== X-Google-Smtp-Source: APXvYqwnC4IMsScIhgvto8AD+Ta8Ws+PQuz6Z0b3fw8j8Vs19LlDU24LEXH3z4z4SQ4C7CPj0Q0+hQ7yofLL4cU0sBw= X-Received: by 2002:a02:c9d8:: with SMTP id c24mr40153123jap.38.1564086536021; Thu, 25 Jul 2019 13:28:56 -0700 (PDT) MIME-Version: 1.0 References: <20190725165206.m6xj4kjcfo42xmqb@imag.fr> In-Reply-To: <20190725165206.m6xj4kjcfo42xmqb@imag.fr> From: Dave Taht Date: Thu, 25 Jul 2019 13:28:44 -0700 Message-ID: To: Baptiste Jonglez Cc: babel-users , Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Accuracy of timestamps for babel-rtt: userspace vs kernel timestamps X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 20:29:00 -0000 Thx very much for taking a look at this. Another interesting test is to put a workload on the box (flent's rrul test is what I use, but a couple netperf or iperf's in both directions is sufficient) and see what happens with fifo and fq_codel. Now that you got my (crappy) first try working... The measurements you get are about what I got using different methods ages ago - that we cannot trust a kernel to userspace transition, on bare x86 metal - to much below 250us. Containers/vms are worse, you can do mildly better with a R/T kernel, and I expect mips to be abysmal. But I can go try that to see what happens. Arm (particularly multicore arm), I have no idea, the context switch overhead pre-speculation arm chips was demonstrably lower than x86, and context switch overhead got much worse on everything post the spectre CVEs. There's another kernel setsockopt nowadays that might be useful to set a pacing rate, so far as I recall that got made to work with udp around 4.12 in support of quic and bb= r. Regardless, I don't think nanosec resolution is needed, but I still think the usec resolution could be useful on short-rtt metrics, partially as a measurement of congestive or cpu overl= oad. A full size packet is 13ms at 1mbit, 13us at a gbit to transit the link. Wifi is 700us to grab the media, and we typically have two txops of up to 5.3ms in size stacked up. So some differentiation as to quality here is possible... On Thu, Jul 25, 2019 at 9:52 AM Baptiste Jonglez wrote: > > Hello, > > A recent discussion with Dave convinced me to start looking at whether > very short RTTs make any sense in Babel, and whether they could be used t= o > infer link speed. If only to settle theses questions for good. Since th= e > related subject of nanosecond-resolution timestamps was brought up by Tok= e > at the IETF session yesterday, I made a quick test with kernel timestamps > today. > > I'll talk about the implementation and shortcomings of using kernel > timestamps below, but here are some rough timing results. I just used a > veth pair on my laptop (4.17 kernel) with a babeld on each side of the > pair, and didn't do any serious statistics. > > - regular babeld: average measured RTT ~320 =C2=B5s (quite variable) > > - babeld with kernel RX timestamps: average measured RTT ~120 =C2=B5s (qu= ite variable) > > - ping through the same veth pair (link-local IPv6, 1000 packets): averag= e 105 =C2=B5s, minimum 16 =C2=B5s > > The observant reader will notice that the current resolution (1 =C2=B5s) = is > more than enough in that case. Also, using kernel timestamps improves > accuracy by about 100 =C2=B5s on each host, a somewhat significant improv= ement. > > > Now, regarding the implementation of kernel timestamps in babeld, my test= code is here: > > https://github.com/jonglezb/babeld/commit/56756a8cbe9a0b8a168c78873dd77= e48e5770278 > > Thank you Dave for your first draft of this code, I borrowed a bit from i= t ;) > > As explained in the commit message, it suffers from a number of issues > that would need some serious work before it's really usable: > > - kernel timestamps use the realtime clock, and it's not configurable. > This is really annoying because babeld uses the monotonic clock (for > good reasons). Using kernel timestamps forces us to fall back to the > realtime clock elsewhere in babeld, and it would require some work to d= o > it cleanly. > > - kernel timestamps are only used for received packets. The sending side > (timestamp in Hello) still uses userspace timestamps, with the ensuing > accuracy issue. It does not seem possible to tell the kernel to embed = a > timestamp at a specified location in a packet just before sending it, > unless maybe playing with eBPF. > > > Takeaway: at least on Linux, I don't see a use-case for nanosecond > resolution timestamps. If somebody ever writes an implementation of Babe= l > for specialized hardware and runs a datacenter with ultra-low-latency > network equipments, it could possibly still make sense. > > > -- > Baptiste Jonglez > PhD student > Univ. Grenoble Alpes > LIG lab > Drakkar team | Polaris team at INRIA > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Thu Jul 25 13:53:40 2019 Return-Path: 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 4040E1201F1 for ; Thu, 25 Jul 2019 13:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0Ud6J1iLFOwV for ; Thu, 25 Jul 2019 13:53:36 -0700 (PDT) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78ABE1201DB for ; Thu, 25 Jul 2019 13:53:36 -0700 (PDT) Received: by mail-oi1-x229.google.com with SMTP id q4so9509007oij.3 for ; Thu, 25 Jul 2019 13:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=SeT3p0hVvVB1u+qXtvAAgW+WsAkRunheMrFkD9xXTI0=; b=ixr9eEr3aFavVTfDrE474kvyHmw8R9KI7ojH6iWFkSyB07KqlZhx00KljO/80J+h5w Vuvq9y9EMsyxyvHI22VntwArVval+t+JU918YHaolQNqnsmASluZVma5KDcaLaI7L/9p p5KWpCMbAKnZZ4yLAL+ohnLyehWEA/zafBNeobzALcJep98OqOhXd1K5C4TIgq1FcWas kgmN9TrOr2woo9sdi5NNta47ctAIxsuJk1rBeE96O+AGdjoPPrvmucyLuDZmkSvdgXdM /p8TT7b71YWGuNAAcKLQ74FBbqlEEfmmWhQrRChUGWn+mbhBSRHBBbrKnMce6pvA50Bu G99A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=SeT3p0hVvVB1u+qXtvAAgW+WsAkRunheMrFkD9xXTI0=; b=kF5Os+zE7/jTUM79z/sGlDhsAhPQD3ztCy/OfBErnPNwnMbHmjcS91tQEs16pShrow nV7fTo9CzozODATvXCPbKO3FWla4ttTRD5FPiPpK0rPh7hmAVVqe2OjrKP6zgRTnXl4V FjJUcAWAj2B6hgRSf3S8s4AuRHqFM+5xAARCTDazPPuDv6tFpRNg0UEx4klp9KgtTs0l Qnr8Iv6PWlSp+oPXw+ah4NQztNAtgz5ylb02y6iCBMLY/IRiA3A65BQm4y6eKcnxXgcF 2FYA07xOl7L30nSAfyWhUACc3ogjmJ/LH5hXeLdtLmrnt1shidQivpada/ELuUzZ34Mo Iv2A== X-Gm-Message-State: APjAAAWksazSf/6kv8Ix0LNEoaY5B5d2dDQfC/7/dtbp5QSlhSaoHz7u QYhawynMSkwhup1El67z4cKiOdNO469/Tw== X-Google-Smtp-Source: APXvYqwnG9OZdU8V1PrvjPcWsQaoqjeISwaEE4+4wEZBuWFMk+XoF2ft2zhOI+MMwar9W44U4TMfQA== X-Received: by 2002:aca:b107:: with SMTP id a7mr43110720oif.83.1564088015665; Thu, 25 Jul 2019 13:53:35 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:2460:3312:ae04:6d53? ([2001:67c:1232:144:2460:3312:ae04:6d53]) by smtp.gmail.com with ESMTPSA id c21sm16409756oib.4.2019.07.25.13.53.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jul 2019 13:53:35 -0700 (PDT) From: Mahesh Jethanandani Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Thu, 25 Jul 2019 16:53:33 -0400 To: Babel at IETF X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [babel] Example configuration X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 20:53:39 -0000 Hi Babel, In my presentation on the YANG model for Babel, I asked for help in = trying to improve the example configuration of Babel. The example was = shown in XML, but that does not mean I am expecting anyone to help me = improve the example in XML. You can describe what you see as a potential configuration of Babel. If = you feel even more motivated you can use the attribute names from the = information model to describe which parameters you see configured. If = you feel even more motivated, you can use the attribute names from the = YANG data model, but by now I am really pushing the boundary, so I will = stop. Thanks in advance.=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Thu Jul 25 14:51:59 2019 Return-Path: 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 7ED2B1202C9 for ; Thu, 25 Jul 2019 14:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 jT-lrzXgUHBk for ; Thu, 25 Jul 2019 14:51:50 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 80F7F120274 for ; Thu, 25 Jul 2019 14:51:50 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x6PLpjIl006209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Jul 2019 23:51:45 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x6PLpjXD009844; Thu, 25 Jul 2019 23:51:45 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 4EA1B3E733; Thu, 25 Jul 2019 23:51:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id KJ2sl_2VjMAu; Thu, 25 Jul 2019 23:51:42 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6BF7C3E730; Thu, 25 Jul 2019 23:51:40 +0200 (CEST) Date: Thu, 25 Jul 2019 23:51:39 +0200 Message-ID: <8736itu6j8.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mahesh Jethanandani Cc: Babel at IETF In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 25 Jul 2019 23:51:45 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 25 Jul 2019 23:51:45 +0200 (CEST) X-Miltered: at korolev with ID 5D3A2471.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D3A2471.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D3A2471.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D3A2471.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D3A2471.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D3A2471.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Example configuration X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 21:51:58 -0000 > In my presentation on the YANG model for Babel, I asked for help in > trying to improve the example configuration of Babel. The example was > shown in XML, but that does not mean I am expecting anyone to help me > improve the example in XML. I'll use the syntax of the babeld configuration file. Here's a pretty minimal config: interface eth0 interface wlan0 This says to run Babel on interfaces eth0 and wlan0. Babeld will automatically detect that eth0 is wired and wlan0 is wireless, and will configure the right parameters automatically. Here's a slightly less minimal configuration: interface eth0 interface eth1 type wireless interface tun0 type tunnel Here, interface eth1 is an Ethernet bridged to a wireless radio, so babeld's autodetection fails, and the interface type needs to be configured manually. Tunnels are not detected automatically, so this needs to be specified. This is equivalent to the following: interface eth0 interface eth1 link-quality true split-horizon false interface tun0 enable-timestamps true max-rtt-penalty 96 Here's another configuration: interface eth0 interface ppp0 hello-interval 30 update-interval 120 in if ppp0 metric 1024 out if ppp0 metric 1024 Here, ppp0 is a metered 3G link used for fallback connectivity. It runs with much higher than default time constants in order to avoid control traffic as much as possible, and the metric of routes through that link are increased so that they are not used unless all other options fail. Here's a configuration for David: interface eth0 interface wlan0 unicast true This requests that all control traffic other than Hellos on the wlan0 interface be sent as unicast. This can be useful when wlan0 uses a technology on which multicast is prohibitively expensive. Another one: interface atm0 split-horizon false unicast true Here, atm0 is an NBMA interface. Transitive connectivity is not guaranteed, so we disable the split-horizon optimisation. Unicast is to be preferred to multicast whenever possible. Here is a configuration that is not yet implemented, but planned for a future version: interface wg0 unicast-only true neighbour fe80::1234 if wg0 Here, wg0 is a Wireguard tunnel, and doesn't support multicast at all. All traffic over that interface is sent as unicast, so automatic discovery is not possible. Thus, we need to specify the link-local addresses of neighbours manually. Hope this helps, -- Juliusz From nobody Fri Jul 26 04:07:45 2019 Return-Path: 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 230F012024F for ; Fri, 26 Jul 2019 04:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 5vkDsalEvlTu for ; Fri, 26 Jul 2019 04:07:42 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 074A11202F9 for ; Fri, 26 Jul 2019 04:07:41 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x6QB7bde015853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Jul 2019 13:07:37 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x6QB7bGD012503; Fri, 26 Jul 2019 13:07:37 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 1AC5F42C6C; Fri, 26 Jul 2019 13:07:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id TA0IcE6csAUY; Fri, 26 Jul 2019 13:07:38 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7ED3942C68; Fri, 26 Jul 2019 13:07:37 +0200 (CEST) Date: Fri, 26 Jul 2019 13:07:37 +0200 Message-ID: <87r26df406.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org Cc: Baptiste Jonglez User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 26 Jul 2019 13:07:37 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 26 Jul 2019 13:07:37 +0200 (CEST) X-Miltered: at korolev with ID 5D3ADEF9.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D3ADEF9.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D3ADEF9.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D3ADEF9.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D3ADEF9.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D3ADEF9.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: [babel] RTT consensus X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 11:07:44 -0000 1. There appears to be consensus that we keep the current µs granularity. Good. 2. There is some misgivings about attaching transmit timestamps to Hello packets The alternative is to define a new TLV that contains just a transmit timestamp and deprecate (but not obsolete -- no flag day) the current transmit timestamp sub-TLV (attached to a Hello). We need more thought. From nobody Fri Jul 26 10:41:09 2019 Return-Path: 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 0AFFD120047 for ; Fri, 26 Jul 2019 10:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 w6NSplnW0sHa for ; Fri, 26 Jul 2019 10:41:06 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF88812003F for ; Fri, 26 Jul 2019 10:41:05 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id v24so52348100ljg.13 for ; Fri, 26 Jul 2019 10:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CFRo7cTHc0Pq29Hg5eJAkoUy1PGm2Sze0M696aBQDmY=; b=UTd59gBBMlrX/Sp21KFUE7N9vKxWKtlQ//BkYPHWdDBKN7d3I1MREvcIdeYZYRjuyU MPN+IWHFMf7fiEnXAfT0FJfwJwwTxDsFA7n3iF0WIGpgxNQN774XWZ+P2Mdz1SkQ0Xx1 wTgnhzm1NtGu+QS1bWnQ4IkHMES5A8AW2Qh7L0YIWnvvC6gglAm4nuSKRD1XSUS879NG JKmIkFOBZi4+n1jJ5DqmiPMrRCJShRtw5uIeedmwFQrIw2CUsJxNh0md+oe0V98l2I7k htdnqI+fc4QTYjwYd0Bl+SGw8YfUTNNABhMOrJiQZ+xAYOxaIEzlkPuXd4//Le9y2Wte Jshg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CFRo7cTHc0Pq29Hg5eJAkoUy1PGm2Sze0M696aBQDmY=; b=omV7XDnxoHzEuK6pkEH7luOV+15BzEPuXor3qv+hraPfnCsYHf8uFrwSlk9f8583O5 tN6kv6k9tVrdXRRlrVpA/T+UdNWrvE9RoIfS1Dxp60NdwY4KIRYmNSurqdU5VRLpdhkZ 9LCs3xfMGEpRroNlbQxQs2uQMVgxo30F8h4olVLhz/CstZUaPB9t6Fv6mlc00g0teO1M tHMEMOCcC9kacbsseJa0qyVQCvOZMt7oxe/NtH2ezWX2WFIBJyT/QveraQog8YOcfdeZ CBH/nz59c5u/jGULHStX82p4e2WPt5IFFpPfMwKCQsRU3DJq1feAXQ408z6YuTP8PzZE n7Tg== X-Gm-Message-State: APjAAAWs7VmyByASwgwLLxtHyxZgsJA5ADcFaO7L/oMLKUY/131aOMXD m1sjqMfr9xQGurrIKGAFgMQPozA9uKbWYgQ2opg= X-Google-Smtp-Source: APXvYqxs71oHtnG3yp24oD2J99+X9OlXztZDzO9UhyUKGR9EJVFEXn3Kfn4Q/O24axJ7dPSIyvFrxpe0zx7WmMrYKso= X-Received: by 2002:a2e:7f05:: with SMTP id a5mr49551817ljd.190.1564162864077; Fri, 26 Jul 2019 10:41:04 -0700 (PDT) MIME-Version: 1.0 References: <87r26df406.wl-jch@irif.fr> In-Reply-To: <87r26df406.wl-jch@irif.fr> From: David Schinazi Date: Fri, 26 Jul 2019 13:40:53 -0400 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF , Baptiste Jonglez Content-Type: multipart/alternative; boundary="000000000000e260ac058e990b68" Archived-At: Subject: Re: [babel] RTT consensus X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 17:41:08 -0000 --000000000000e260ac058e990b68 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 1. I also prefer keeping microseconds for now 2. I'd recommend keeping this as is and leveraging unscheduled hellos, since that should work and is backwards compatible. But I don't have a strong opinion here since I haven't implemented the RTT extension. David On Fri, Jul 26, 2019 at 7:07 AM Juliusz Chroboczek wrote: > 1. There appears to be consensus that we keep the current =C2=B5s granula= rity. > > Good. > > 2. There is some misgivings about attaching transmit timestamps to Hello > packets > > The alternative is to define a new TLV that contains just a transmit > timestamp and deprecate (but not obsolete -- no flag day) the current > transmit timestamp sub-TLV (attached to a Hello). > > We need more thought. > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --000000000000e260ac058e990b68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
1. I also prefer keeping microseconds for now

2. I'd recommend keeping this as is and leveraging unscheduled h= ellos,
since that should work and is backwards compatible. But I = don't have a strong
opinion here since I haven't implemen= ted the RTT extension.

David

On Fri, Jul 26, = 2019 at 7:07 AM Juliusz Chroboczek <jch@i= rif.fr> wrote:
1. There appears to be consensus that we keep the current =C2=B5s gra= nularity.

Good.

2. There is some misgivings about attaching transmit timestamps to Hello =C2=A0 =C2=A0packets

The alternative is to define a new TLV that contains just a transmit
timestamp and deprecate (but not obsolete -- no flag day) the current
transmit timestamp sub-TLV (attached to a Hello).

We need more thought.

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--000000000000e260ac058e990b68-- From nobody Fri Jul 26 13:13:16 2019 Return-Path: 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 69F43120359 for ; Fri, 26 Jul 2019 13:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 kKlI3iAWYoeS for ; Fri, 26 Jul 2019 13:13:13 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 D1925120351 for ; Fri, 26 Jul 2019 13:13:12 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x6QKD7v7031666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Jul 2019 22:13:07 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x6QKD72v024170; Fri, 26 Jul 2019 22:13:07 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5CA8745456; Fri, 26 Jul 2019 22:13:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id mDlIogGU_25Z; Fri, 26 Jul 2019 22:13:09 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1A75A45454; Fri, 26 Jul 2019 22:13:06 +0200 (CEST) Date: Fri, 26 Jul 2019 22:13:06 +0200 Message-ID: <877e84ftbh.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org Cc: Baptiste Jonglez In-Reply-To: <87r26df406.wl-jch@irif.fr> References: <87r26df406.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 26 Jul 2019 22:13:07 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 26 Jul 2019 22:13:08 +0200 (CEST) X-Miltered: at korolev with ID 5D3B5ED3.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D3B5ED3.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D3B5ED3.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D3B5ED3.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D3B5ED3.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D3B5ED3.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] RTT consensus X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 20:13:16 -0000 > 2. There is some misgivings about attaching transmit timestamps to Hello > packets As an additional data point, I've just implemented sending unscheduled Hellos whenever an IHU is sent in a packet without a regular Hello. My conclusion is that a new TLV is unnecessary if we can assume that everyone implements receiving of unscheduled Hellos correctly. (In particular, if the Hello history is empty, then we must be careful to set a tiny timeout if we receive an unscheduled Hello, since the sender's Hello rate is unknown.) For the interested bodies, here's the detail. There are two main patches: https://github.com/jech/babeld/commit/0db7e63b976643dc9b943772ab50473ee4db74bf This restructures the Hello formatting code so that it knows how to format unicast and unscheduled Hellos (previously, babeld could parse such Hellos but couldn't send them). It also adds a flag to the send_*_hello functions that tells them what to do if there already is a Hello in the packet (either split the packet or ignore the new Hello). https://github.com/jech/babeld/commit/bc26b858c27fa535ee4507970bb3957f2a2b9b06 This inserts an unscheduled Hello whenever we ship out an IHU in a packet without a Hello. Additionally, the following patch fixes the loss estimator to handle the case where a neighbour only sends unscheduled Hellos of a given kind (unicast or multicast). In that case, we must expire the history quickly, since we don't know the sender's sending rate, and might underestimate the loss rate otherwise (and therefore spuriously select a bad link). https://github.com/jech/babeld/commit/928454f51e80caf8f16fb5b01b8c8b53fe245bec -- Juliusz From nobody Fri Jul 26 14:11:39 2019 Return-Path: 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 4034312006E for ; Fri, 26 Jul 2019 14:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 4dN3oDdF0abe for ; Fri, 26 Jul 2019 14:11:35 -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 5E93C120047 for ; Fri, 26 Jul 2019 14:11:35 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x6QL9JoD040309; Fri, 26 Jul 2019 17:11:33 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 2u08n7ryp8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Jul 2019 17:11:33 -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 x6QLBWM7020413; Fri, 26 Jul 2019 17:11:33 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x6QLBPcx020192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Jul 2019 17:11:25 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 3CD0C400A011; Fri, 26 Jul 2019 21:11:25 +0000 (GMT) Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (unknown [130.8.218.152]) by zlp30488.vci.att.com (Service) with ESMTPS id 291E9400A010; Fri, 26 Jul 2019 21:11:25 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0439.000; Fri, 26 Jul 2019 17:11:19 -0400 From: "STARK, BARBARA H" To: Baptiste Jonglez CC: Mahesh Jethanandani , "babel@ietf.org" Thread-Topic: Babel-RTT information model and example parameters Thread-Index: AQHVQvuPaANjEbh89UaQNFKB91p2lKbdZ2D4 Date: Fri, 26 Jul 2019 21:11:19 +0000 Message-ID: <59AF71F0-DFD6-40D4-8A2F-AD7068D28107@att.com> References: <20190725151332.ywxjpxpxoritx4ql@imag.fr> In-Reply-To: <20190725151332.ywxjpxpxoritx4ql@imag.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-26_15:, , 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=813 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907260238 Archived-At: Subject: Re: [babel] Babel-RTT information model and example parameters X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 21:11:37 -0000 Hi Baptiste, I think you ask an excellent question. We have one case in the current info= model of an implementation-specific parameter (the Hello history). After m= uch discussion, we agreed it was useful and easy enough for others to imple= ment =97 so we kept it.=20 But in general =97 you=92re absolutely right that we want to avoid implemen= tation-specific parameters.=20 I also think it=92s unlikely that people will want to be configuring such p= arameters (assuming this is all wildly successful and being used by =93aver= age=94 people).=20 The only parameter I think is definitely needed is one to enable/disable us= e of RTT in metric calculations.=20 If we ended up with just that, I wouldn=92t be upset. But if there is more,= that=92s fine. I do like the idea of not introducing implementation-specif= ic parameters.=20 Thx, Barbara=20 > On Jul 25, 2019, at 11:13 AM, Baptiste Jonglez = wrote: >=20 > Hi Barbara, Mahesh, >=20 > The discussion about the information model yesterday and Juliusz' email o= n > policies got me thinking about the parameters of the babel-rtt extension. >=20 > Should the information model specify parameters that are not really part > of the spec? I'm thinking of the example function for metric computation > and its 3 parameters rtt-min, rtt-max, max-rtt-penalty: >=20 > https://tools.ietf.org/html/draft-ietf-babel-rtt-extension-00#section-2.= 2.1 >=20 > This metric function is just an example: an implementation is free to do > something totally different. So, does it make sense to add the > corresponding parameters (as ro or rw) to the information model? >=20 > Sorry if this is a dumb question, I'm quite new to this information model= / YANG thing. >=20 > Thanks, >=20 > --=20 > Baptiste Jonglez > PhD student > Univ. Grenoble Alpes > LIG lab > Drakkar team | Polaris team at INRIA From nobody Fri Jul 26 14:24:50 2019 Return-Path: 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 5051C12006E for ; Fri, 26 Jul 2019 14:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 kVBFVFa02o_h for ; Fri, 26 Jul 2019 14:24:44 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 889D3120047 for ; Fri, 26 Jul 2019 14:24:44 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x6QLOEPS011747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Jul 2019 23:24:14 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x6QLOEV3002775; Fri, 26 Jul 2019 23:24:14 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 2350A456F8; Fri, 26 Jul 2019 23:24:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id aIeMMXEpiK7j; Fri, 26 Jul 2019 23:24:16 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9F57A456F6; Fri, 26 Jul 2019 23:24:13 +0200 (CEST) Date: Fri, 26 Jul 2019 23:24:13 +0200 Message-ID: <87wog4ebgi.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: Baptiste Jonglez , Mahesh Jethanandani , "babel@ietf.org" In-Reply-To: <59AF71F0-DFD6-40D4-8A2F-AD7068D28107@att.com> References: <20190725151332.ywxjpxpxoritx4ql@imag.fr> <59AF71F0-DFD6-40D4-8A2F-AD7068D28107@att.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 26 Jul 2019 23:24:14 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 26 Jul 2019 23:24:14 +0200 (CEST) X-Miltered: at korolev with ID 5D3B6F7E.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D3B6F7E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D3B6F7E.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D3B6F7E.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D3B6F7E.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D3B6F7E.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Babel-RTT information model and example parameters X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 21:24:48 -0000 > The only parameter I think is definitely needed is one to enable/disable > use of RTT in metric calculations. Unfortunately not. In a congested and bufferbloated network, tuning of the saturation value (rtt-max) is necessary in order to avoid oscillations. This mail has the full approval of the Commission for Truth in Advertising. -- Juliusz From nobody Fri Jul 26 14:38:32 2019 Return-Path: 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 35AB912006E for ; Fri, 26 Jul 2019 14:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 38YASTzE3wU9 for ; Fri, 26 Jul 2019 14:38:29 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 682AA120047 for ; Fri, 26 Jul 2019 14:38:29 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x6QLcO7G014328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Jul 2019 23:38:24 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x6QLcO6I004895; Fri, 26 Jul 2019 23:38:25 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 676D94573F; Fri, 26 Jul 2019 23:38:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id DOA57s7pf4PJ; Fri, 26 Jul 2019 23:38:26 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id AD71A4573D; Fri, 26 Jul 2019 23:38:24 +0200 (CEST) Date: Fri, 26 Jul 2019 23:38:24 +0200 Message-ID: <87v9voeasv.wl-jch@irif.fr> From: Juliusz Chroboczek To: Baptiste Jonglez Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , babel@ietf.org In-Reply-To: <20190725145711.vwklw4epew3tkxgo@imag.fr> References: <87k1c75cn5.wl-jch@irif.fr> <878ssmz83p.fsf@toke.dk> <20190725145711.vwklw4epew3tkxgo@imag.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 26 Jul 2019 23:38:24 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 26 Jul 2019 23:38:25 +0200 (CEST) X-Miltered: at korolev with ID 5D3B72D0.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D3B72D0.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D3B72D0.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D3B72D0.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D3B72D0.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D3B72D0.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Open issues with draft-ietf-babel-rtt-extension X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 21:38:31 -0000 >>> Baptiste outlined two solutions: >>> >>> (a) require that all IHUs be sent in packets with a Hello; >>> (b) define a new TLV that contains just a timestamp. >>> > Thank you for summarizing. You apparently didn't like my "Solution 1" > because you don't even mention it, but I agree it's a bad idea anyway :) Right, I missed that. Baptiste's "Solution 1" is to duplicate the transmit timestamp in all IHUs. While it yields a somewhat cleaner packet format, it complicates the implementation somewhat. The transmit timestamp must be computed as close as possible to packet transmission, so it gets patched in into the packet at the very last moment. In the current packet format, there's just one transmit timestamp per packet, so we just keep one pointer to the space reserved for the timestamp. If the transmit timestamp gets duplicated, then we need to either maintain a list of places to patch, or reparse the packet just before we ship it out. -- Juliusz From nobody Fri Jul 26 14:41:41 2019 Return-Path: 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 84D2A12012D for ; Fri, 26 Jul 2019 14:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 IAfRr_0vPsU1 for ; Fri, 26 Jul 2019 14:41:37 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 6E5E212006E for ; Fri, 26 Jul 2019 14:41:37 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x6QLfWbb014914; Fri, 26 Jul 2019 23:41:32 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 7B35845750; Fri, 26 Jul 2019 23:41:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id eO0l7omx4W2Q; Fri, 26 Jul 2019 23:41:34 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 8E9E94574C; Fri, 26 Jul 2019 23:41:34 +0200 (CEST) Date: Fri, 26 Jul 2019 23:41:34 +0200 Message-ID: <87tvb8eanl.wl-jch@irif.fr> From: Juliusz Chroboczek To: Dave Taht Cc: Babel at IETF In-Reply-To: References: <87k1c75cn5.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 26 Jul 2019 23:41:32 +0200 (CEST) X-Miltered: at korolev with ID 5D3B738C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D3B738C.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D3B738C.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Congestion control [was: Open issues...] X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 21:41:40 -0000 > B) As you have larger numbers of routes (1000s), congestion control > becomes a problem I'm pretty sure that packet pacing (spreading the announcements over the update interval rather then sending them all as a burst as we currently do) would solve your issues, Dave. This won't happen for 1.9, which I'd like to release before the summer ends. > My "solution" for some congestion control issues is to start dynamically > increasing the route announcement interval for stabler routes, while > still announcing the most important ones (like defaults) in the > hello. the protocol has an underused feature where we can announce a per > route interval larger than the default. Indeed. This can be done in addition to packet pacing. -- Juliusz From nobody Fri Jul 26 14:54:05 2019 Return-Path: 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 CA5E11201D6 for ; Fri, 26 Jul 2019 14:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 msUboIKa4UM6 for ; Fri, 26 Jul 2019 14:53:54 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 4B2D212019C for ; Fri, 26 Jul 2019 14:53:54 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x6QLrnBN016964; Fri, 26 Jul 2019 23:53:49 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A1E16457CD; Fri, 26 Jul 2019 23:53:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id UzgysfYKQl3j; Fri, 26 Jul 2019 23:53:51 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A9B4E457C9; Fri, 26 Jul 2019 23:53:51 +0200 (CEST) Date: Fri, 26 Jul 2019 23:53:51 +0200 Message-ID: <87r26cea34.wl-jch@irif.fr> From: Juliusz Chroboczek To: Baptiste Jonglez Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , babel@ietf.org In-Reply-To: <20190725145711.vwklw4epew3tkxgo@imag.fr> References: <87k1c75cn5.wl-jch@irif.fr> <878ssmz83p.fsf@toke.dk> <20190725145711.vwklw4epew3tkxgo@imag.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 26 Jul 2019 23:53:49 +0200 (CEST) X-Miltered: at korolev with ID 5D3B766D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D3B766D.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D3B766D.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Babel Hellos [was: Open issues with draft-ietf-babel-rtt-extension] X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 21:54:04 -0000 > I also think unicast/unscheduled Hellos can make (a) work without further > hacks, but indeed it feels somewhat uncomfortable that Hello messages are > used for several roles (neighbour discovery and maintenance, link quality > estimation, RTT estimation). The logic is that: - Hello TLVs carry link-local information about the sending peer; - IHU TLVs carry link-local information about the receiving peer. =46rom that point of view, the local timestamp belongs in the Hello packet. The apparent complication is that Hello packets are also used to carry negative information: missing enough Hellos indicates that the sending node has died or moved away. Hence the need to carry a timeout. An unscheduled Hello is simply a Hello that opts out from the timeout subprotocol. -- Juliusz From nobody Fri Jul 26 16:30:34 2019 Return-Path: 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 C4116120181 for ; Fri, 26 Jul 2019 16:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 4Q3BKDV7iJHr for ; Fri, 26 Jul 2019 16:30:30 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AAC51201DB for ; Fri, 26 Jul 2019 16:30:28 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id h6so21589908iom.7 for ; Fri, 26 Jul 2019 16:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5IQ7BQlf4Xd66DZ6nGGiDERnY7A2+UtwRdxl0+w6Nhk=; b=mkUMM6+avkBu7Z0cOv/0mZc0ukh3ArXzRg6QdKrtSR3p5wHOLoKx4xR4KCmVWHmiKB 3RPTgzltCNyJjG97rXYT9lWPxcpdnpkt4jiheEpSNEDzs8lCG/MnaNBzqrNkOzJgdzSz AA56Jw3buh7Svtw4ewFlrfHh79aGqP+BOjti4gScpXtBTkz2bjThl4Rb5dQnKk2Ig3fK UzJ8C6jUDqSS/eWZvzUv0qYxaaxh25ghSyuDVk056OcXXpR+JzIgj/DB1nWcNcjGmMAa yfyJ8o8Bs9OnAmumY/mOHmpEA8YHMc2Aoq1GotImJo+Uyl8JruWz8LeFiqKDtU3DyH5I KSeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5IQ7BQlf4Xd66DZ6nGGiDERnY7A2+UtwRdxl0+w6Nhk=; b=nh4qQ/IUNKFipekXctRCQ9Ef6avxcVVOnfw+rQnzl0TRVwVoqUx9Gr0/AwkxwXfX+d F1YumiYvWRqEEOS08EJIMD0NulEU9WoBwM8NinAE2BGMpgbtBn346M+Q/rSN8znhYnSb oTvDIlB8GCTedbxOSxevbO208LerN6xHHPRVyBF5MqOQAG4nqZSMDOGkIIcAIb3HbRZv YLF+3obTprubUX1xreiQ5hEWPMXJcc7veLDuRdeS4DolgfvMEF8yNI1CqnjBgm3ZzdDm 4rPa+YzPvjnsv6Biy3SHZFFisWS4wRX6JIvTMryU8hLkxqcXzFcth7j9uIBQmkqU7fS5 if/Q== X-Gm-Message-State: APjAAAU6DyCFwjqlysLVXrasAz+oFEHklU26cgMcB4hqBxg8wvcfxnP3 mCBQPN0lMX6DgZXmQ+qJL5TUAgpHdK5KwmKJvoU= X-Google-Smtp-Source: APXvYqzgOKfx8qergQjUZQ27tKW4FbZdNyQsJTnzq9iwfv7labarZa1TkioAz/d7GOTCLddv29PrmBEP0Olvh5RBf74= X-Received: by 2002:a02:b713:: with SMTP id g19mr99815391jam.77.1564183827385; Fri, 26 Jul 2019 16:30:27 -0700 (PDT) MIME-Version: 1.0 References: <87k1c75cn5.wl-jch@irif.fr> <87tvb8eanl.wl-jch@irif.fr> In-Reply-To: <87tvb8eanl.wl-jch@irif.fr> From: Dave Taht Date: Fri, 26 Jul 2019 16:30:19 -0700 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Congestion control [was: Open issues...] X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 23:30:33 -0000 On Fri, Jul 26, 2019 at 2:41 PM Juliusz Chroboczek wrote: > > > B) As you have larger numbers of routes (1000s), congestion control > > becomes a problem > > I'm pretty sure that packet pacing (spreading the announcements over the > update interval rather then sending them all as a burst as we currently d= o) > would solve your issues, Dave. I think it would make a big difference yes. Ain't a lot of code, either, and the upcoming release of openwrt is mostly 4.14 based. I can go toss the patch together a= gain. > This won't happen for 1.9, which I'd like to release before the summer en= ds. Would love to see that make this openwrt release. > > > My "solution" for some congestion control issues is to start dynamicall= y > > increasing the route announcement interval for stabler routes, while > > still announcing the most important ones (like defaults) in the > > hello. the protocol has an underused feature where we can announce a pe= r > > route interval larger than the default. > > Indeed. This can be done in addition to packet pacing. I think this is a good long term solution to larger numbers of routes on stabler networks. In either case the "fitting" algorithm for these two approaches either separate or combined has to somehow stay below the allocated bandwidth, and we need more experience with unicast and real networks than we have as yet. It's not enough though, to get to my (personal) goal of being able to carry a full ipv6 route table (64k routes); too many scalability issues in the code itself. > > -- Juliusz I also keep hoping somehow someday we'll get to atomic updates. The nexthop code finally landed in 5.2? (3?) netlink, so that can safely wait til after 1,9. --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Fri Jul 26 16:39:58 2019 Return-Path: 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 732B71201CF for ; Fri, 26 Jul 2019 16:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 HwGqFblNMSDM for ; Fri, 26 Jul 2019 16:39:55 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF37120181 for ; Fri, 26 Jul 2019 16:39:55 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id k8so25307374plt.3 for ; Fri, 26 Jul 2019 16:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=mRumDVT/DQxbGlpu0xZkIpvlAuaJKzp21MFSPtEzv6o=; b=GOItSLAm0RzMh8VncoPrhS973xhBRa2whMGkS1gdHj8F32XvMkvK9WLuTqjDlbehbe yPYXBuWTO680XI9YU2ZkM/GAvQNUH7ggVCgPuNEhzN5zetR6oQiHCBk4t3yeiPyiSfXv WTvwWwWO2BHSLv1Dv6tLTGZsuUH2ZaVXtTE836CuMwcCDVhYP02ypPn11UqC+Z2hdMaE Wg+9HfuuiXMKHHAaKqXgFW8Le+mFFrIaLyG2kPHWlPIkJr7pq6HRA2tfX94twe4/8rjy ScMSJ0FcFKqohNWCoM1Wr40u+cu/jh3tUVWWsEsrT8LzhEJju5+6hOlHutmekuk5oVry FYdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=mRumDVT/DQxbGlpu0xZkIpvlAuaJKzp21MFSPtEzv6o=; b=YgoaS53Sfv65iFPtkn2C/ckf+U00BtKc0ro5Sz2q+E2Piz7nEpQVyLX0Q3HiQT8Ut6 xsf0sUynsBJ6miJZUPeFC/LpxQrkbjQuDEO5dU+G18kQnYkrsTDpjeXQy/SV87wK8iTF N2uelIJHr49NoLYMKP4cZANUeU7GF8FDJ1TQlmS1BcYBXAjmHH47QEgsSNQKzOd3uX7z kCuHKyuLMN5O7maH5ZC+rY9WCXEq5cUH6Z4a1rp+vMOjXQjvr05CCErfYaKLDhSiWkW/ dCnTALVpYCHFBDoVru3uQahE/BS1ygZkrHeAUmvn3Eitbydc/8G8l8xCX5lYqXDDWC1F nRkw== X-Gm-Message-State: APjAAAVBsouh2Zd35Hiea2gYp08sk5uDeFD7PUcJX0nOkEL7Y9uXg2uL 8UR4yvBISZ5lYPpdF0wDZTsEsu5hrU8= X-Google-Smtp-Source: APXvYqzghDY4QPtXTdMu1GFgnE+CHT0v3szzpRhjLb0kk587q8RoFN6EbuLp+FHoZbxuiE1DKrA9Hw== X-Received: by 2002:a17:902:59c3:: with SMTP id d3mr95917556plj.22.1564184394413; Fri, 26 Jul 2019 16:39:54 -0700 (PDT) Received: from [192.168.1.149] (c-73-93-49-153.hsd1.ca.comcast.net. [73.93.49.153]) by smtp.gmail.com with ESMTPSA id q1sm63429973pfg.84.2019.07.26.16.39.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jul 2019 16:39:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Mahesh Jethanandani Mime-Version: 1.0 (1.0) Date: Fri, 26 Jul 2019 14:08:52 -0400 Message-Id: <22B67FC8-3FCE-48CE-B27D-FD4BC0E87C2A@gmail.com> References: <8736itu6j8.wl-jch@irif.fr> Cc: Babel at IETF In-Reply-To: <8736itu6j8.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: iPad Mail (16A404) Archived-At: Subject: Re: [babel] Example configuration X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 23:39:57 -0000 Hi Juliusz, Yes, this is very helpful. Let me get back to you if I have any questions ab= out any of these examples. Thanks. Mahesh Jethanandani mjethanandani@gmail.com On Jul 25, 2019, at 5:51 PM, Juliusz Chroboczek wrote: >> In my presentation on the YANG model for Babel, I asked for help in >> trying to improve the example configuration of Babel. The example was >> shown in XML, but that does not mean I am expecting anyone to help me >> improve the example in XML. >=20 > I'll use the syntax of the babeld configuration file. >=20 > Here's a pretty minimal config: >=20 > interface eth0 > interface wlan0 >=20 > This says to run Babel on interfaces eth0 and wlan0. Babeld will > automatically detect that eth0 is wired and wlan0 is wireless, and will > configure the right parameters automatically. >=20 > Here's a slightly less minimal configuration: >=20 > interface eth0 > interface eth1 type wireless > interface tun0 type tunnel >=20 > Here, interface eth1 is an Ethernet bridged to a wireless radio, so > babeld's autodetection fails, and the interface type needs to be > configured manually. Tunnels are not detected automatically, so this > needs to be specified. >=20 > This is equivalent to the following: >=20 > interface eth0 > interface eth1 link-quality true split-horizon false > interface tun0 enable-timestamps true max-rtt-penalty 96 >=20 > Here's another configuration: >=20 > interface eth0 > interface ppp0 hello-interval 30 update-interval 120 > in if ppp0 metric 1024 > out if ppp0 metric 1024 >=20 > Here, ppp0 is a metered 3G link used for fallback connectivity. It runs > with much higher than default time constants in order to avoid control > traffic as much as possible, and the metric of routes through that link > are increased so that they are not used unless all other options fail. >=20 > Here's a configuration for David: >=20 > interface eth0 > interface wlan0 unicast true >=20 > This requests that all control traffic other than Hellos on the wlan0 > interface be sent as unicast. This can be useful when wlan0 uses > a technology on which multicast is prohibitively expensive. >=20 > Another one: >=20 > interface atm0 split-horizon false unicast true >=20 > Here, atm0 is an NBMA interface. Transitive connectivity is not > guaranteed, so we disable the split-horizon optimisation. Unicast is to > be preferred to multicast whenever possible. >=20 > Here is a configuration that is not yet implemented, but planned for > a future version: >=20 > interface wg0 unicast-only true > neighbour fe80::1234 if wg0 >=20 > Here, wg0 is a Wireguard tunnel, and doesn't support multicast at all. > All traffic over that interface is sent as unicast, so automatic discovery= > is not possible. Thus, we need to specify the link-local addresses of > neighbours manually. >=20 > Hope this helps, >=20 > -- Juliusz >=20 >=20 From nobody Mon Jul 29 14:12:26 2019 Return-Path: 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 6C53D120045 for ; Mon, 29 Jul 2019 14:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 IHULHpTu8bzb for ; Mon, 29 Jul 2019 14:12:22 -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 5ABA3120043 for ; Mon, 29 Jul 2019 14:12:22 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x6TL6UBJ028952; Mon, 29 Jul 2019 17:12:17 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 2u27g4hhhx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Jul 2019 17:12:16 -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 x6TLBjbc007035; Mon, 29 Jul 2019 17:11:45 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x6TLBdNJ006946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 29 Jul 2019 17:11:39 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 533A24009E77; Mon, 29 Jul 2019 21:11:39 +0000 (GMT) Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30486.vci.att.com (Service) with ESMTPS id 4062A4005C24; Mon, 29 Jul 2019 21:11:39 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0439.000; Mon, 29 Jul 2019 17:11:38 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: "'Baptiste Jonglez'" , "'Mahesh Jethanandani'" , "'babel@ietf.org'" Thread-Topic: [babel] Babel-RTT information model and example parameters Thread-Index: AQHVQvuPaANjEbh89UaQNFKB91p2lKbdZ2D4gABGqICABG4pkA== Date: Mon, 29 Jul 2019 21:11:38 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E248BD3@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20190725151332.ywxjpxpxoritx4ql@imag.fr> <59AF71F0-DFD6-40D4-8A2F-AD7068D28107@att.com> <87wog4ebgi.wl-jch@irif.fr> In-Reply-To: <87wog4ebgi.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.209.102] 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=2019-07-29_10:, , 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=511 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907290231 Archived-At: Subject: Re: [babel] Babel-RTT information model and example parameters X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2019 21:12:24 -0000 > > The only parameter I think is definitely needed is one to > > enable/disable use of RTT in metric calculations. >=20 > Unfortunately not. In a congested and bufferbloated network, tuning of t= he > saturation value (rtt-max) is necessary in order to avoid oscillations. >=20 > This mail has the full approval of the Commission for Truth in Advertisin= g. >=20 > -- Juliusz I see the draft says "In addition, in order to enhance stability (Section 2= .3), the mapping should be bounded -- above a certain RTT, all links are eq= ually bad." Is this what you mean by rtt-max? To me, this would indicate it= would be ok to define a parameter rtt-max, because it's suggested in the b= ase spec that all implementations have it. Would it be the same rtt-max for= all interfaces, or defined per interface? Additionally... Should this "should" be "SHOULD"? I see no normative language in the draft.= Should there be some normative requirements? It seems a bit weird to me to= have a specification that doesn't tell you what MUST be done to be complia= nt with the spec. Barbara From nobody Mon Jul 29 21:02:09 2019 Return-Path: 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 E5F4712000F; Mon, 29 Jul 2019 21:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 mJ-uc6NuUbTr; Mon, 29 Jul 2019 21:02:06 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D05120025; Mon, 29 Jul 2019 21:02:06 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id q22so5253027iog.4; Mon, 29 Jul 2019 21:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=gnuMK761viBLVUeuJG9ZFcos0FOobfhwtzlEh0kclh0=; b=T0QeFaSR2devwl7N4xyvEujqrCnSITvEVlSJsjZXpjJgfgRhq5huJvNXmq5bCg3sSx sImpjZH4hwHYtuJdwmfOCowTP+If2Q86ZA0Yv74uBptsw6+7lhbvxs2Q67pKFot//FJm a8S50hXUqMnHHdJAkQlPofUl5aPz/AygogLFbz4ymI4xN+bFubZmVOl3IXpCZe0mkKOP wpfPP+6ZwSVx1CFHM1K5O98Kb68l4B79TlsAM6FasSD6xNqeWgDu4r1hOEWHf+b9f+s1 oFKS3Ey9JXOM8svI5oDOEODi1DzqANXIvijH7C98hbXNYBxQ5kzoJGs+lBQiibnjmFxn Z8iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=gnuMK761viBLVUeuJG9ZFcos0FOobfhwtzlEh0kclh0=; b=pr2jmrKgv2FL0Xbmr/Md74rB+Q4+0gHlPGWzjcLAJg+wMQJPiG6ilshf/t849bNYG4 q7L0X3KJpacrl3kUPZdHBO/dVVCM+M6iMPEMRks9/h0ijqH5xZ4BQVH+PT+Ya08zvri7 mVooaMa8rRvBrtLh6t8z89Kt9lcp0YFZZ6MymlzwKadjUzX8O/EwUilL0cZJhSDX+PBN E0h8Tkcqji/MCn2s7fR0z2KJxwGCJkWuKvO6js6LA9Fsi6VUSVGOwokBodyCAkXSStnY yjHKfuK6Ra8Id8gKzUC0ow9Lwdj2+hFzryLUL4Ae5GzrKoI+8GxINvkPhhlzPaCsEXF+ DZYw== X-Gm-Message-State: APjAAAUzdrGvns5M310/YGK1X84iOG2ZrvDuGmVxLQSbTHHJ2xdLxH1F RCqrRUoqlyK+bh7I0ef1SYSvSfRXPlj9+3Hmbncc/vIJ X-Google-Smtp-Source: APXvYqwenYK7qwKo30XLlmOw9aMa1c5L1GYVhpfjCRyCAOxsvOxXL3Vv9k7k0MCpwOS9dkYdZGnuv1ErorHgrt9Jwi4= X-Received: by 2002:a05:6638:81:: with SMTP id v1mr66127851jao.72.1564459325189; Mon, 29 Jul 2019 21:02:05 -0700 (PDT) MIME-Version: 1.0 From: Donald Eastlake Date: Tue, 30 Jul 2019 00:01:53 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [babel] draft BABEL minutes X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 04:02:08 -0000 Hi, Draft minutes of the Babel meeting in Montreal are at https://datatracker.ietf.org/meeting/105/materials/minutes-105-babel-00 Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com From nobody Tue Jul 30 13:44:16 2019 Return-Path: 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 16BC3120281 for ; Tue, 30 Jul 2019 13:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 EWcJxqPDEfyy for ; Tue, 30 Jul 2019 13:44:06 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9498B120159 for ; Tue, 30 Jul 2019 13:44:06 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id i10so17971284iol.13 for ; Tue, 30 Jul 2019 13:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gVQcUqW/SRZtZn4JOe3vM4WOVlJCC+0L3Ajhm5aBX1o=; b=TRW+gkmENlQSLL7/qq7pc/3rk+rQPJkX+UzvGhu57517P1vmKqz/vqFomH6cKoWQVC LPWbHNu8q3qemKVJz+6zoR+Ja8Pi/CxwUZO2NGTukjCDXONx/juRIn2lP5+dKDCScBPb NiNmPN/cLFUh6dXyEq7Tu1v9nTHLLsDrJ52v7KRP/n9O9njGZSmYB+MbWt0MAPQalj15 j/M4u07KMnAKCKU6Rs7LjKMUb1FrUZcb24dQ8EMnPKzbl34oeRyMIpm//jNKNo4zGlex 7MiMI0SWlVZBh+EVnTLxArZLYNCfQ7VCSPEZqeGKYJI4M9rJtyB4G32csu1GpVr0Kqi6 WTgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gVQcUqW/SRZtZn4JOe3vM4WOVlJCC+0L3Ajhm5aBX1o=; b=qu0MO0bw/2aNdvBbYNf6JRnFMeQnNWaUdVDVC/a/cv8FvZuDxgBqwOigTH1sP8noXo 8fCvbaJ5ySVfalYW3S2tZ7AuHTQaY3Ju6+dCeByWjaz45oNZj1+8PqkiyvyNvcAwn4mk EwoF2ylzhsspkw29pdkm/13gk4BCAg8Ot5zZM0AGAeow0adP44lUjCI2Vqo952w94hZu AO+/ZEdMdEDa/5WUAkxzD6z++e8RtD7fdJmrmAdNzG91Cj2bzoTCt7Q5BX+hHbhY2EqE 5pkVxwX365m3BLnHrVvcOFfi9gQ3z1DHNIYmsbhEEo1uFUdeNOt42EVgXYXNs5uCjWsP bwrA== X-Gm-Message-State: APjAAAXNFMI9Ra1qfCbmw1f3g869LBwv7nL1YhM6O64D+4wzbu2JjLjm 4bpkccQ0m1nk1FCIR9/zDQ/fZi4OctPH6de0/V7362pK X-Google-Smtp-Source: APXvYqyAz123LTINjbwGGuhMlAk24nrGk3+rmfcS4h/1w9M8ZF2132wMc3zVoW7qRsel2uPkR+vt7KQFGrfhNaSGlBs= X-Received: by 2002:a6b:f80b:: with SMTP id o11mr100084249ioh.40.1564519445267; Tue, 30 Jul 2019 13:44:05 -0700 (PDT) MIME-Version: 1.0 References: <87r26df406.wl-jch@irif.fr> In-Reply-To: <87r26df406.wl-jch@irif.fr> From: Donald Eastlake Date: Tue, 30 Jul 2019 16:43:52 -0400 Message-ID: To: Babel at IETF Cc: Baptiste Jonglez , Juliusz Chroboczek Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] RTT consensus X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 20:44:15 -0000 On Fri, Jul 26, 2019 at 7:07 AM Juliusz Chroboczek wrote: > > 1. There appears to be consensus that we keep the current =C2=B5s granula= rity. > > Good. This was the consensus in the room in Montreal and I haven't seen any opposition to it but to be sure it's confirmed on this mailing list, I'll wait until this coming Saturday to formally declare consensus on that point. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com > 2. There is some misgivings about attaching transmit timestamps to Hello > packets > > The alternative is to define a new TLV that contains just a transmit > timestamp and deprecate (but not obsolete -- no flag day) the current > transmit timestamp sub-TLV (attached to a Hello). > > We need more thought. > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Wed Jul 31 02:50:29 2019 Return-Path: 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 3533312008C for ; Wed, 31 Jul 2019 02:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 obzDR_7MwDEo for ; Wed, 31 Jul 2019 02:50:25 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 D93C7120033 for ; Wed, 31 Jul 2019 02:50:24 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x6V9oJvM008865; Wed, 31 Jul 2019 11:50:19 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 40C043A39C; Wed, 31 Jul 2019 11:50:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id k0jUwh3NqpZU; Wed, 31 Jul 2019 11:50:21 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A69123A39A; Wed, 31 Jul 2019 11:50:18 +0200 (CEST) Date: Wed, 31 Jul 2019 11:50:18 +0200 Message-ID: <87lfwe1qjp.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake Cc: Babel at IETF , Baptiste Jonglez In-Reply-To: References: <87r26df406.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 31 Jul 2019 11:50:19 +0200 (CEST) X-Miltered: at korolev with ID 5D41645B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D41645B.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D41645B.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] RTT consensus X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 09:50:27 -0000 > This was the consensus in the room in Montreal and I haven't seen any > opposition to it but to be sure it's confirmed on this mailing list, > I'll wait until this coming Saturday to formally declare consensus on > that point. Oh, sorry Donald, the title of the mail was badly chosen -- I was merely attemtping to summarise the Montréal meeting, in order to prompt people to react if they disagree, not to declare consensus, which is obviously not my job. Apologies for the misunderstanding. -- Juliusz From nobody Wed Jul 31 06:39:25 2019 Return-Path: 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 E1C271200CC for ; Wed, 31 Jul 2019 06:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 OiNVxzS7kS1g for ; Wed, 31 Jul 2019 06:39:22 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB8F120020 for ; Wed, 31 Jul 2019 06:39:22 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id k8so136349457iot.1 for ; Wed, 31 Jul 2019 06:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=evE1ujLXCfx/oN7tj8fePfr+SE6HJd4pY+Pz0XkexJI=; b=bagwjD2CEz4QgR1DXJDBbkXFl7SxK/vReAZ10ZOMCit4h+ir+tDeyaab+hZRAoWaJB xlKoh2qTDh6SDS+fs1z2Se38FaCl2KPA+K1xqi7HJtsNn0E6lf+On0js5RR13xF/Gbnj YB0P5oKNrX3FqUzzt72zTCGJxjDAx+pqzO5LPB6XXbzQLu9Mmc3Lgup9NlH6XMlMD9Cf piO1Imlf2fW6CVPW++qHLkB6mq4VarzyWXAvYNELEsWFvwWiMp0cX/tV0QKY0SP5imuU 3l+AbWGc9+XhvSFcDX+mRExiQ/QUEdWY7fWUFnhnH88D4BhYG8lQZMSsPHxg21PiBe8z sh6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=evE1ujLXCfx/oN7tj8fePfr+SE6HJd4pY+Pz0XkexJI=; b=DGARuxNjP0GEj+lRlPIEiZAwYsuYcZb8QNc0z0maGeTReH04+PLsmRvChArrziRqRC oRLlCd0Mp7zcAaj6plS8lR+vqFi+4Qtl/QfzWjEksYCIlukVlKY6lsduNGgy0F1BaAV7 sO4BIJGjJTn868lXVerzCxuPxCIFll3Ui7iAS2wrDQtpyZCIMp9U6xO8LdoedGni2CXU Q68Xzf2n/pRwS/Ptuew0FiAbqBwu5nyvHLY1/PaTa/5qCl1eArjogBc1FfivM1qluPm7 hqTWHD0L68mMM/Tpcmv/vtLAohCGZtTr5pkrN8/285nIjzxLbFz264msHKQa5p6nLCpv AuGA== X-Gm-Message-State: APjAAAXKhdURClFTt8R+W1fbpA9pCTUlH+J410wOcrDPGp0OPjKf38+2 lwFyUQkUp/2R901N+NhS/DSEmcMxuyFpPBZwGBY= X-Google-Smtp-Source: APXvYqzCkBLjwTBPEi5AhFSpfF1ijgYUixSLzU7I5fkC07MlZxcS1VbrZ8ggaBlTEFsQJdA+/lpdh6p96MocTtl+76I= X-Received: by 2002:a5e:c30f:: with SMTP id a15mr68661592iok.246.1564580361416; Wed, 31 Jul 2019 06:39:21 -0700 (PDT) MIME-Version: 1.0 References: <87r26df406.wl-jch@irif.fr> <87lfwe1qjp.wl-jch@irif.fr> In-Reply-To: <87lfwe1qjp.wl-jch@irif.fr> From: Dave Taht Date: Wed, 31 Jul 2019 06:39:07 -0700 Message-ID: To: Juliusz Chroboczek Cc: Donald Eastlake , Baptiste Jonglez , Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] RTT consensus X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 13:39:24 -0000 Well, I think we do have consensus. On Wed, Jul 31, 2019 at 2:50 AM Juliusz Chroboczek wrote: > > > This was the consensus in the room in Montreal and I haven't seen any > > opposition to it but to be sure it's confirmed on this mailing list, > > I'll wait until this coming Saturday to formally declare consensus on > > that point. > > Oh, sorry Donald, the title of the mail was badly chosen -- I was merely > attemtping to summarise the Montr=C3=A9al meeting, in order to prompt peo= ple to > react if they disagree, not to declare consensus, which is obviously not > my job. > > Apologies for the misunderstanding. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Wed Jul 31 15:01:18 2019 Return-Path: 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 AFE4512006D for ; Wed, 31 Jul 2019 15:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nIW8cHKFcxHb for ; Wed, 31 Jul 2019 15:01:14 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8927A1200C7 for ; Wed, 31 Jul 2019 15:01:14 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id k20so139733848ios.10 for ; Wed, 31 Jul 2019 15:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xXuy34cSmwXsy7UvZC0tMjNeD+XQz7SbV/B6hUMFM7o=; b=sK9OFexGsajTAeDB+rrJj8l+21ZVOE+d3WmMIpUhJyg1MkTzqFKeWSMEiiiVxsiKhG uQlwb+CPpZZSLQkNgrlWQbCA+6c6cTNBgU2t+qbKFxAaFxE91GWcRtMf2WDdHgXHANE4 eqgSoTYVYE5+D/lw/CyvzL3FNKHch1mAoprTT/iEaTTaulXXImzqudE/SzpHR5Cz4nQl AYbOYoCC5WtSD3YQ2bVCWBe043lZIQGcceqJaq3O7ZW1eMJ1nDzqoJ46woX2skW0XI2d hTlF84mTnlNQ9zBVJ3jbIRM84RAeZj2da+9tW4ruLjOfetjrXuTCuRrATs4hVPomS0m2 /mEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xXuy34cSmwXsy7UvZC0tMjNeD+XQz7SbV/B6hUMFM7o=; b=TYlW3cLHxHULC9kFoNCmc3yLUBON1eg+PX0QqHDua5wfiN4Z8sXRm9Z10RRdJzo4Dc jfqONfzrFpirHuvecupjB9HoiVoKWFswNkibxb9A5UgB4Pe5wuckChJONh+03ZOoN9s1 aTIsP5LtqrtE6ILGOXOV0DAUiSAiaNdMK3LMT9u7lPDklRm2AVaopSdtb0jY1OLl46ax slv9u4REDDSstmAARcp1APioITzwnd4PoQUuObPBI821Lx6AOYXwVvPAakFIsUBynNdm t59sVJE39Kz15vbb+1zQFO8RwKfPsMIyuer3bfc5R3d6SBN/pjP9l7QVrBZnMqxF3/9E Rv1A== X-Gm-Message-State: APjAAAUiTQtqDgxzmhimRjXsB5ntAxR+I2LC81zZlEtvpVzQBhw5Dr/2 9kBm3Lw6eU0e++hcJoIlQTa4VSXpONv2qkzL3qQ= X-Google-Smtp-Source: APXvYqxj72TAoxObFe+DpGVZ3ni7hpTOqGDizoeOg1MU6WnDLewpPKWq6VXRVQ+COagVQDQmt6NZvIkJ8+ZI533Z7dY= X-Received: by 2002:a6b:c98c:: with SMTP id z134mr1586485iof.276.1564610473760; Wed, 31 Jul 2019 15:01:13 -0700 (PDT) MIME-Version: 1.0 References: <87r26df406.wl-jch@irif.fr> <87lfwe1qjp.wl-jch@irif.fr> In-Reply-To: <87lfwe1qjp.wl-jch@irif.fr> From: Donald Eastlake Date: Wed, 31 Jul 2019 18:01:02 -0400 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF , Baptiste Jonglez Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] RTT consensus X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 22:01:16 -0000 No problem. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com On Wed, Jul 31, 2019 at 5:50 AM Juliusz Chroboczek wrote: > > > This was the consensus in the room in Montreal and I haven't seen any > > opposition to it but to be sure it's confirmed on this mailing list, > > I'll wait until this coming Saturday to formally declare consensus on > > that point. > > Oh, sorry Donald, the title of the mail was badly chosen -- I was merely > attemtping to summarise the Montr=C3=A9al meeting, in order to prompt peo= ple to > react if they disagree, not to declare consensus, which is obviously not > my job. > > Apologies for the misunderstanding. > > -- Juliusz