From nobody Mon Sep 12 08:01:37 2016 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 0FBF412B553; Mon, 12 Sep 2016 08:01:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147369249602.8929.12166006350517098601.idtracker@ietfa.amsl.com> Date: Mon, 12 Sep 2016 08:01:36 -0700 Archived-At: Cc: babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org, akatlas@gmail.com Subject: [babel] babel - New Meeting Session Request for IETF 97 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 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, 12 Sep 2016 15:01:36 -0000 A new meeting session request has just been submitted by Donald E. Eastlake 3rd, a Chair of the babel working group. --------------------------------------------------------- Working Group Name: Babel routing protocol Area Name: Routing Area Session Requester: Donald Eastlake Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 65 Conflicts to Avoid: First Priority: manet ospf homenet trill saag lpwan isis idr rtgwg 6man v6ops i2rs netmod netconf Second Priority: dnsop dnssd Special Requests: --------------------------------------------------------- From nobody Mon Sep 26 14:56:52 2016 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 4522F12B356 for ; Mon, 26 Sep 2016 14:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 45TlvhdLGggv for ; Mon, 26 Sep 2016 14:56:48 -0700 (PDT) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC6A12B2FF for ; Mon, 26 Sep 2016 14:56:48 -0700 (PDT) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1474927001454701.8546634675243; Mon, 26 Sep 2016 14:56:41 -0700 (PDT) Date: Mon, 26 Sep 2016 22:56:41 +0100 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <157687fff6c.125ec972130971.6990802801298137948@ovsienko.info> In-Reply-To: <147369249602.8929.12166006350517098601.idtracker@ietfa.amsl.com> References: <147369249602.8929.12166006350517098601.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] babel - New Meeting Session Request for IETF 97 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 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, 26 Sep 2016 21:56:51 -0000 ---- On Mon, 12 Sep 2016 16:01:36 +0100 "IETF Meeting Session Request Tool" wrote ---- > > >A new meeting session request has just been submitted by Donald E. Eastlake 3rd, a Chair of the babel working group. Hello group. I would like to progress the suggested change to spell the neighbour state machine and its valid transitions in RFC 6126-bis. Besides being useful on its own this addition should make it one step closer to the RFC 7298 problem solution as discussed before. If it would be notably better to review the problem in person at IETF, please let me know soonest possible so I can prepare some slides and try to book the trip. Otherwise I would be equally happy with a diff to the .xml file and a mailing list discussion. Let's just try to see what works better so long as it's not too late to make plans. -- Denis Ovsienko From nobody Mon Sep 26 15:50:54 2016 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 7CEDC12B350 for ; Mon, 26 Sep 2016 15:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 K7FlD1j1CA7q for ; Mon, 26 Sep 2016 15:50: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 E458A12B03A for ; Mon, 26 Sep 2016 15:50:49 -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/56228) with ESMTP id u8QMoleZ008478; Tue, 27 Sep 2016 00:50: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 8884ED7ACB; Tue, 27 Sep 2016 00:50: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 BNR7J-kt1E3h; Tue, 27 Sep 2016 00:50:46 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 330FDD7A55; Tue, 27 Sep 2016 00:50:46 +0200 (CEST) Date: Tue, 27 Sep 2016 00:50:49 +0200 Message-ID: <87intil1h2.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Denis Ovsienko In-Reply-To: <157687fff6c.125ec972130971.6990802801298137948@ovsienko.info> References: <147369249602.8929.12166006350517098601.idtracker@ietfa.amsl.com> <157687fff6c.125ec972130971.6990802801298137948@ovsienko.info> 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]); Tue, 27 Sep 2016 00:50:48 +0200 (CEST) X-Miltered: at korolev with ID 57E9A647.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57E9A647.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 : 57E9A647.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: Cc: Babel at IETF Subject: Re: [babel] babel - New Meeting Session Request for IETF 97 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 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, 26 Sep 2016 22:50:52 -0000 > I would like to progress the suggested change to spell the neighbour > state machine and its valid transitions in RFC 6126-bis. Could you please clarify? Babel doesn't have a state machine -- it's described as a stateless protocol, with received TLVs causing changes to the data structures and scheduling actions to happen. It's not at all clear to me whether it can be described as a finite state automaton (I strongly doubt it). > Otherwise I would be equally happy with a diff to the .xml file and > a mailing list discussion. Sorry for my silence -- I've been lecuting 18 hours a week. My teaching load drops to 12 hours this week, I'll hopefully find some energy to make a github project and set up things up. > Let's just try to see what works better so long as it's not too late to > make plans. I will not be going to Seoul, sorry, too much teaching. I'll definitely be getting down to work as soon as I recover from September. (I'm not complaining, mind you -- September at university is a lot of fun, but it's also very hard work). Sorry for that, -- Juliusz From nobody Tue Sep 27 14:40:20 2016 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 859C212B043 for ; Tue, 27 Sep 2016 14:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 vI3SUk6uLItU for ; Tue, 27 Sep 2016 14:40:18 -0700 (PDT) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EB9812B00D for ; Tue, 27 Sep 2016 14:40:17 -0700 (PDT) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 14750124120155.1421970942061535; Tue, 27 Sep 2016 14:40:12 -0700 (PDT) Date: Tue, 27 Sep 2016 22:40:12 +0100 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <1576d97426a.e42fe53c13650.1872477973631904352@ovsienko.info> In-Reply-To: <87intil1h2.wl-jch@pps.univ-paris-diderot.fr> References: <147369249602.8929.12166006350517098601.idtracker@ietfa.amsl.com> <157687fff6c.125ec972130971.6990802801298137948@ovsienko.info> <87intil1h2.wl-jch@pps.univ-paris-diderot.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] babel - New Meeting Session Request for IETF 97 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 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, 27 Sep 2016 21:40:19 -0000 ---- On Mon, 26 Sep 2016 23:50:49 +0100 Juliusz Chroboczek wrote ---- >> I would like to progress the suggested change to spell the neighbour >> state machine and its valid transitions in RFC 6126-bis. > >Could you please clarify? Babel doesn't have a state machine -- it's >described as a stateless protocol, with received TLVs causing changes to >the data structures and scheduling actions to happen. It's not at all >clear to me whether it can be described as a finite state automaton (I >strongly doubt it). One specific part of the protocol is already a finite automata. An AckReq, Update, RouteReq or SeqnoReq TLV cannot be actioned before the neighbour has a 2-way connectivity (IHU TLV), which implies a 1-way connectivity (Hello TLV). Spelling the already existing transitions through a FSM is what I mean here and in the previous messages. >> Otherwise I would be equally happy with a diff to the .xml file and >> a mailing list discussion. > >Sorry for my silence -- I've been lecuting 18 hours a week. My teaching >load drops to 12 hours this week, I'll hopefully find some energy to make >a github project and set up things up. I was going to ask exactly that. >> Let's just try to see what works better so long as it's not too late to >> make plans. > >I will not be going to Seoul, sorry, too much teaching. I'll definitely >be getting down to work as soon as I recover from September. (I'm not >complaining, mind you -- September at university is a lot of fun, but it's >also very hard work). > >Sorry for that, > >-- Juliusz -- Denis Ovsienko From nobody Tue Sep 27 16:01:41 2016 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 1692B12B50C for ; Tue, 27 Sep 2016 16:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.618 X-Spam-Level: X-Spam-Status: No, score=-6.618 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_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 4Tp9HgZFSkx1 for ; Tue, 27 Sep 2016 16:01:38 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EBFB12B50D for ; Tue, 27 Sep 2016 16:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1475017298; x=2338930898; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/0YBZLFYDQXxNOLIx6ISC4zDJmhETjWrUSDUtGJxEBU=; b=2dLW1sTwB2OUO6EzylkCZDG/zpobYvsQjE5JNk8hbeBRlhTu5oB5aClSmB12q797 xoKIeOX5dsbJj6EK7QZV+NH3CDSftIbSi4S1/z2i/jfW3sodyaCMHGXVj365byeD Xn0W2EPf6/Wum7tGsCc4+DiaSHWRxnZR/jS9eg+X3w/pbAnAaw2TtFf8+SOJytWQ Al4sI8IKYmSB7XtAHCH6/LYTr5E7KUVQaxrywyFQ1vOs1a3p+2cm91RW0IzFOHUu uDBcXkGFAYtQYEn1/j4EIIkCswxPqDRm24Tq3fFfJHiez66BWMrMsra5WOMzEzia ZjXxg/9hNjWQS9pRIdaU1g==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id AC.4B.07433.25AFAE75; Tue, 27 Sep 2016 16:01:38 -0700 (PDT) X-AuditID: 11973e12-f79b16d000001d09-02-57eafa52cf37 Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay6.apple.com (Apple SCV relay) with SMTP id 71.7D.23613.25AFAE75; Tue, 27 Sep 2016 16:01:38 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from dschinazi.apple.com (dschinazi.apple.com [17.226.40.22]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OE6005RJQMPCT30@nwk-phonehomebzp-sz01.apple.com> for babel@ietf.org; Tue, 27 Sep 2016 16:01:38 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Content-transfer-encoding: quoted-printable Message-id: <32E33FB4-2785-4220-9C4D-F4097645D243@apple.com> Date: Tue, 27 Sep 2016 16:01:37 -0700 To: babel@ietf.org X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUi2FAYpRv061W4QetzEYsti7pZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8XPdAvaChSoVS1+vYW9gXCLbxcjJISFgIvF21nl2CFtM4sK9 9WxdjFwcQgJ7GSWmtFxkgila9O8uE0TiGKPE7OZORpAEr4CgxI/J91i6GDk4mAXUJaZMyYWo 2cMkseTrWbCpwgLSEl0X7rKC1LAJaEkcWGMEEmYW0JZ48u4CK0SJrETn/eUsECNtJCY2N7KB 2CwCqhINW/+xgbSKCAhJtPYoQZwjK/Hk5CIWkFUSAndZJR58es4+gVFwFpKLZiFcNAvJtgWM zKsYhXITM3N0M/NM9BILCnJS9ZLzczcxgkJyup3QDsZTq6wOMQpwMCrx8DIUvQoXYk0sK67M PcQozcGiJM5bcwAoJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbG9dLeJ+BbBlSLzskuO/n5x YsaTrJyOrh632vQbdcsKE7ZUXGxvt/is8Tagqi5Zg2dl6pE3y+Qi52n5eur/mu/H7r99smbn 4yMVMtsubVaukHR71xtwNfKWzvQcUWX5wzYXlWIqVkr/8PXY29Gs9U88XqSkb0FgnKZ1yYS0 +OSnDEu4WlumK7EUZyQaajEXFScCANkglb4qAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupiluLIzCtJLcpLzFFi42IRnG7noBv061W4wYYnghZbFnWzODB6LFny kymAMYrLJiU1J7MstUjfLoEr4+e6BewFC1Uqlr5ew97AuES2i5GTQ0LARGLRv7tMELaYxIV7 69m6GLk4hASOMUrMbu5kBEnwCghK/Jh8j6WLkYODWUBdYsqUXIiaPUwSS76eZQepERaQlui6 cJcVpIZNQEviwBojkDCzgLbEk3cXWCFKZCU67y9ngRhpIzGxuZENxGYRUJVo2PqPDaRVREBI orVHCeIcWYknJxexTGDkm4XkiFkIR8xCsmABI/MqRoGi1JzESjO9xIKCnFS95PzcTYygEGoo jNrB2LDc6hCjAAejEg8vQ9GrcCHWxLLiytxDjBIczEoivEt+AIV4UxIrq1KL8uOLSnNSiw8x SnOwKInzruN9EC4kkJ5YkpqdmlqQWgSTZeLglGpgNDwXeDxpjoLlO7bNwvr1+wTO7ddYd+P7 ycbOEw3vvR44pJyefyL1stPTxo9/Dz99Pzt0QtMx9WnR/Sv/e7Iw9SwO7tTWj//a+V3leKZM 1kXj74lX3n6e9OL54jfxl3dnOPzsWbDvYcy9T7c2vpE0baqXdJ8Zf7x+Qtj76ka1BVZp078w 1EjmPldiKc5INNRiLipOBAAptyjcHQIAAA== Archived-At: Subject: [babel] Comments on RFC 6126 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 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, 27 Sep 2016 23:01:40 -0000 Fellow Babel enthusiasts, As a fun research project, I have built a fully independent = implementation of Babel, exclusively from specification. While it still = has some rough edges, it works well enough for a demo and interoperates = with devices running babeld. In the process of building it, I took notes = on what parts of RFC 6126 were confusing to me, and also have written = down random thoughts for parts of the document (and protocol) that I = think could be improved. But before I dive into how the spec isn't = perfect, let me say that it's a very well written document that allowed = me to build my own implementation without ever looking at babeld's = source code. These comments aren't very well organized, I'm sharing them = with the list to start conversations that could potentially lead to = changes in RFC 6126 bis. Feel free to shoot any questions my way. *) Parts of the specification that I think may be incorrect =E2=80=A2 in 3.1, "a Babel speaker does not need to determine = the destination address of a packet that it receives in order to = interpret it" isn't necessarily true in the case of IHU TLVs with AE=3D0. = Packets that are ambiguous could be explicitly forbidden but checking if = we received the packet over unicast or multicast can be helpful. =E2=80=A2 3.5.4 indicates that the route table is indexed by = (neigh, id, prefix), this should not include the router ID (as in 3.2.5) =E2=80=A2 typo in 3.8.1.2 "A node MUST NOT increase its sequence = number by more than 1 in response to a route request" should be seqno = request *) Parts of the specification that I found confusing =E2=80=A2 when discussing addresses, "compression is allowed" is = unclear - further reading indicates that the only compression that = exists is the omitted field, I ended up searching for more complex = encodings. =E2=80=A2 it was initially unclear that Hellos always require a = seqno increment =E2=80=A2 the feasibility condition is discussed in terms of = updates sent instead of selected routes, which makes sense but feels odd =E2=80=A2 When text discusses if we have an entry for that = prefix, it should be made clearer that it's for that explicit prefix, = not one that contains the requested one (as in a shorter prefix) =E2=80=A2 shouldn't the table of pending seqno requests (3.2.6) = be indexed by routerID too? 3.8.1.2 is not clear about defining what = redundant requests should be indexed on =E2=80=A2 shouldn't the table of pending seqno requests also = contain the destination neighbor we sent it to? =E2=80=A2 the omitted field in updates / corresponding flag are = per-address family but it's unclear what to do when receiving = AE=3D3(IPv6LL) and omitted>0 (are the 64bits of fe80 considered = omitted?) =E2=80=A2 3.2.5 should specify that the information in the = source and route tables are not quite the same. This does feel obvious = after the fact but as a first time routing protocol implementor I = started with a pointer in the route table to the source table entry and = that got me down a pretty deep rabbit hole of things that don't quite = work... *) Parts of the specification / protocol that could be improved =E2=80=A2 the jitter discussion concentrates on one possible = solution, delaying and buffering, but there are other solutions such as = not reseting timers based on outside events =E2=80=A2 there's no reason for the IHU timer to live in the = interface table if IHUs are sent unicast =E2=80=A2 handling of Hellos - this deserves a thread all to = itself but in a nutshell Hellos feel like the most constraining part of = Babel. 3.4.3 states a MUST: "if no hellos were received recently, then = the cost is infinite" which feels too limiting, if an implementation has = access to out of bound mechanisms for neighbor discovery and = bidirectional reachability checks (such as from the underlying link = layer), it should not be constrained as much. Also allowing for unicast = Hellos could improve performance in some networks. =E2=80=A2 would it make sense to use split horizon over wireless = when sharing routes over unicast? (conceptually this could be equivalent = to treating every neighbor as the other end of a point-to-point link) =E2=80=A2 if we get a seqno request from the same node that = advertised the route would it make sense to treat that as a retraction? =E2=80=A2 what does an update with AE=3D0 and plen>0 mean? =E2=80=A2 what do you do on outgoing seqno requests if the route = in question has been unselected between retransmissions? David Schinazi= From nobody Thu Sep 29 08:59:21 2016 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 0F2F712B102 for ; Thu, 29 Sep 2016 08:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 bLw9A-BvA8-Z for ; Thu, 29 Sep 2016 08:59:18 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 2938B12B192 for ; Thu, 29 Sep 2016 08:59:18 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id u134so118188685itb.1 for ; Thu, 29 Sep 2016 08:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=PkDY0soSnp+mDIasQfZu65MyTXu3aKYoGwAIGLaUK8I=; b=Xb13b/9UxnrpCEET7rWhcI0T2dE7KlLdt+fo9Qcs0btKdsixDlyJHX1vDoiiAZFYnk rPrJvu2Wd+wvQeSBjjpxH38dWZmaNOMOdIU8F4Or2Nk95EkQ7TpGTSEP8kmzsu5yL666 Woxjgt6GCYa3OoHrvk0HCBk+9XwgD41ly1oEQh94AhPQ0FRxlYTkcsjv6gl+ZUvSntkB M7yulVg7WZl/PwD+w7FDnqWjaamd36ek3pEm7ceFGpC1dYTJiPIJ0+klL9xFAk9j44uf gqjQKNWPqaFP11fgEGS9p484+juT5OHfAy191PW8yfMCoZAlJ2JhMK7Z7zuTNyOZXyzG VJNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=PkDY0soSnp+mDIasQfZu65MyTXu3aKYoGwAIGLaUK8I=; b=JkyWuGyf5C9+Jccm5k4FMeh/CG+Epu65GLyK8uEp4yoQLtYdPMigXMZ55kLm8LSF2n dSAcBxFq9NGQC0MH5J3Jyu+QKpr0pSW2qcX3xTews4xz4SvMmOBCK3SFI1S8e/jGg5FF u/bzfvTonQTLJs+URmc0hbHETJbsA6tuNovvdRxD9B2SUvUUmdRQKnh4sqbb7IgTjD0Y kPh3pEaxsOf5WGWPkht2e9wusNp133D/kPPsKxTiP1v4fnN+YnWjXJsyoGro1YnuMul1 Ly5wxKtXszsqCRg6Ea/e0ezBTAPb+ckvrgDf64JTHYxE8SCOXacwAPuWuAgVZPF0mT49 CQag== X-Gm-Message-State: AA6/9RltYW9TfjA6gIT043Mr8vsidhu51Jzl8K+sNYuLOdMrPwNBpQcTzgxQLpiJ+hnxXHZhgkcsjRQT8W+ZMg== X-Received: by 10.36.50.67 with SMTP id j64mr9106628ita.41.1475164757464; Thu, 29 Sep 2016 08:59:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.158.82 with HTTP; Thu, 29 Sep 2016 08:58:37 -0700 (PDT) In-Reply-To: References: From: Tony Przygienda Date: Thu, 29 Sep 2016 08:58:37 -0700 Message-ID: To: Babel at IETF Content-Type: multipart/alternative; boundary=001a114acd4c5abd95053da78f00 Archived-At: Subject: Re: [babel] babel Digest, Vol 13, Issue 3 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 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, 29 Sep 2016 15:59:20 -0000 --001a114acd4c5abd95053da78f00 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable inline ... ---------- Forwarded message ---------- > From: David Schinazi > To: babel@ietf.org > Cc: > Date: Tue, 27 Sep 2016 16:01:37 -0700 > Subject: [babel] Comments on RFC 6126 > Fellow Babel enthusiasts, > > As a fun research project, I have built a fully independent implementatio= n > of Babel, exclusively from specification. very cool, looks like this will be one of the wider implemented recent protocols. I only remember RIP implementations sprouting that fast in its time ;-) > While it still has some rough edges, it works well enough for a demo and > interoperates with devices running babeld. In the process of building it,= I > took notes on what parts of RFC 6126 were confusing to me, and also have > written down random thoughts for parts of the document (and protocol) tha= t > I think could be improved. But before I dive into how the spec isn't > perfect, let me say that it's a very well written document that allowed m= e > to build my own implementation without ever looking at babeld's source > code. These comments aren't very well organized, I'm sharing them with th= e > list to start conversations that could potentially lead to changes in RFC > 6126 bis. Feel free to shoot any questions my way. > Experience and good specs are all very valuable and silver, implementors showing the thumb direction is gold. Further inline ... > > *) Parts of the specification that I think may be incorrect > =E2=80=A2 in 3.1, "a Babel speaker does not need to determine the > destination address of a packet that it receives in order to interpret it= " > isn't necessarily true in the case of IHU TLVs with AE=3D0. Packets that = are > ambiguous could be explicitly forbidden but checking if we received the > packet over unicast or multicast can be helpful. > Yep, from bitter experience you DO want to pay close attention how and when your 0/0 starts to slosh around. Those can do extraordinary amount of damage. Rules WHEN 0/0 (AE=3D0) is to be accepted and when dropped cannot b= e strict enough. > > =E2=80=A2 shouldn't the table of pending seqno requests (3.2.6) b= e indexed > by routerID too? 3.8.1.2 is not clear about defining what redundant > requests should be indexed on > In abstract terms, "over"-specifying a protocol is as bad as under specifying it often. Telling people how to build/index data structures often leads to far more confusion and less interoperability than otherwise. A better language is often to talk about "tuples" of things that associate together conceptually. How those tuples are stored, accessed is strictly internal implementation stuff. Imagine we have infinitely deep/fast hash tables tomorrow and you wrote all your spec assuming trees are the hottest index thingies ;-) (been done ;-) > > *) Parts of the specification / protocol that could be improved > =E2=80=A2 the jitter discussion concentrates on one possible solu= tion, > delaying and buffering, but there are other solutions such as not resetin= g > timers based on outside events > yep, jitter spec should say "you SHALL jitter" and _maybe_ give some kind of bound like "5% is not enough, 50% is too generous". Beyond that, specifying how and how much jitter to do has not proven helpful in specs IME. > =E2=80=A2 handling of Hellos - this deserves a thread all to itse= lf but in > a nutshell Hellos feel like the most constraining part of Babel. 3.4.3 > states a MUST: "if no hellos were received recently, then the cost is > infinite" which feels too limiting, if an implementation has access to ou= t > of bound mechanisms for neighbor discovery and bidirectional reachability > checks (such as from the underlying link layer), it should not be > constrained as much. Also allowing for unicast Hellos could improve > performance in some networks. > be careful what you wish for. The hellos are your belts and suspenders and pretty much only ones you have except periodic retransmission to heal any blackholes. Enough times one or even two-way hellos ended up mocking up a link that couldn't carry the traffic. IS-IS ended up all the way with 3-way hellos including MTU padding after many, many painfully learned lessons. Optimizations are fine, being pretty conservative initially when doing hellos pays though ... > =E2=80=A2 would it make sense to use split horizon over wireless = when > sharing routes over unicast? (conceptually this could be equivalent to > treating every neighbor as the other end of a point-to-point link) > hmm, don't parse that, sounds intriguing ... > =E2=80=A2 if we get a seqno request from the same node that adver= tised the > route would it make sense to treat that as a retraction? > I wouldn't advise that. it may be in-flight transient and next thing you start to shake your network using yet another dynamic control loop hoping to improve things while making e'one spin their wheels. The requests are fragile enough as they stand as I think wrote a while ago ... > =E2=80=A2 what does an update with AE=3D0 and plen>0 mean? > =E2=80=A2 what do you do on outgoing seqno requests if the route = in > question has been unselected between retransmissions? > yup, those are the finer points of FSMs involved ... Best in such cases is a self-stabilization (positive stability) built into the protocol. --- tony --001a114acd4c5abd95053da78f00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
inline ...

---------- Forwarded messag= e ----------
From:=C2=A0David Schinazi <dschinazi@apple.com>
To:=C2=A0babel@ietf.org
Cc:=C2=A0
Date:=C2=A0Tue, 27 Sep 2016 16:= 01:37 -0700
Subject:=C2=A0[babel] Comments on RFC 6126
Fellow Babel e= nthusiasts,

As a fun research project, I have built a fully independent implementation = of Babel, exclusively from specification.

v= ery cool, looks like this will be one of the wider implemented recent proto= cols. I only remember RIP implementations sprouting that fast in its time ;= -)=C2=A0
=C2=A0
While it sti= ll has some rough edges, it works well enough for a demo and interoperates = with devices running babeld. In the process of building it, I took notes on= what parts of RFC 6126 were confusing to me, and also have written down ra= ndom thoughts for parts of the document (and protocol) that I think could b= e improved. But before I dive into how the spec isn't perfect, let me s= ay that it's a very well written document that allowed me to build my o= wn implementation without ever looking at babeld's source code. These c= omments aren't very well organized, I'm sharing them with the list = to start conversations that could potentially lead to changes in RFC 6126 b= is. Feel free to shoot any questions my way.

Experience and good specs are all very valuable and silver, implement= ors showing the thumb direction is gold. Further inline ...=C2=A0
=C2=A0

*) Parts of the specification that I think may be incorrect
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 in 3.1, "a Babel speaker does no= t need to determine the destination address of a packet that it receives in= order to interpret it" isn't necessarily true in the case of IHU = TLVs with AE=3D0. Packets that are ambiguous could be explicitly forbidden = but checking if we received the packet over unicast or multicast can be hel= pful.

Yep, from bitter experience you D= O want to pay close attention how and when your 0/0 starts to slosh around.= Those can do extraordinary amount of damage. Rules WHEN 0/0 (AE=3D0) is to= be accepted and when dropped cannot be strict enough.=C2=A0
=C2= =A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 shouldn't the table of pending se= qno requests (3.2.6) be indexed by routerID too? 3.8.1.2 is not clear about= defining what redundant requests should be indexed on

In abstract terms, "over"-specifying a protocol i= s as bad as under specifying it often. Telling people how to build/index da= ta structures often leads to far more confusion and less interoperability t= han otherwise. A better language is often to talk about "tuples" = of things that associate together conceptually.=C2=A0 How those tuples are = stored, accessed is strictly internal implementation stuff.=C2=A0 Imagine w= e have infinitely deep/fast hash tables tomorrow and you wrote all your spe= c assuming trees are the hottest index thingies ;-) =C2=A0(been done ;-)

*) Parts of the specification / protocol that could be improved
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 the jitter discussion concentrates on= one possible solution, delaying and buffering, but there are other solutio= ns such as not reseting timers based on outside events

yep, jitter spec should say "you SHALL jitter" an= d _maybe_ give some kind of bound like "5% is not enough, 50% is too g= enerous". Beyond that, specifying how and how much jitter to do has no= t proven helpful in specs IME.=C2=A0
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 handling of Hellos - t= his deserves a thread all to itself but in a nutshell Hellos feel like the = most constraining part of Babel. 3.4.3 states a MUST: "if no hellos we= re received recently, then the cost is infinite" which feels too limit= ing, if an implementation has access to out of bound mechanisms for neighbo= r discovery and bidirectional reachability checks (such as from the underly= ing link layer), it should not be constrained as much. Also allowing for un= icast Hellos could improve performance in some networks.

be careful what you wish for. The hellos are your belts a= nd suspenders and pretty much only ones you have except periodic retransmis= sion to heal any blackholes. Enough times one or even two-way hellos ended = up mocking up a link that couldn't carry the traffic.=C2=A0 IS-IS ended= up all the way with 3-way hellos including MTU padding after many, many pa= infully learned lessons. Optimizations are fine, being pretty conservative = initially when doing hellos pays though ...=C2=A0
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 would it make sense to use split hori= zon over wireless when sharing routes over unicast? (conceptually this coul= d be equivalent to treating every neighbor as the other end of a point-to-p= oint link)

hmm, don't parse that, s= ounds intriguing ...=C2=A0
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 if we get a seqno request from the sa= me node that advertised the route would it make sense to treat that as a re= traction?

I wouldn't advise that. i= t may be in-flight transient and next thing you start to shake your network= using yet another dynamic control loop hoping to improve things while maki= ng e'one spin their wheels. The requests are fragile enough as they sta= nd as I think wrote a while ago ...=C2=A0
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 what does an update with AE=3D0 and p= len>0 mean?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 what do you do on outgoing seqno requ= ests if the route in question has been unselected between retransmissions?<= br>

yup, those are the finer points of FSMs= involved ... Best in such cases is a self-stabilization (positive stabilit= y) built into the protocol.=C2=A0

--- tony=C2=A0
--001a114acd4c5abd95053da78f00-- From nobody Fri Sep 30 04:11:02 2016 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 4C57E12B2D3 for ; Fri, 30 Sep 2016 04:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.617 X-Spam-Level: X-Spam-Status: No, score=-6.617 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_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 R34MKJexMUPq for ; Fri, 30 Sep 2016 04:10:58 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 B68B512B2D2 for ; Fri, 30 Sep 2016 04:10:58 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5FCA7A2; Fri, 30 Sep 2016 13:10:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1475233856; bh=8Q1iQOWhK1e0IeXjdSXcaKfnzDeaHzxYnYg4Ft7ZR2Y=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=2GpXWUVeSexuG5TZdO1mWuU2L/NloM6qO3dL4J/Z/1lvAJqADcZNgGh42dR0FGTEt lhcgNvCDf0ASTdhQ8nY8rYep1RGVMyMPd8mZRK8o3HHrwKGHz0OFxlpirqxKpRTmPa Di9vavPEssSRcO2iBd2CT8aytx0j30um2ZWhcrBo= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 537C6A1; Fri, 30 Sep 2016 13:10:56 +0200 (CEST) Date: Fri, 30 Sep 2016 13:10:56 +0200 (CEST) From: Mikael Abrahamsson To: Tony Przygienda In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: Babel at IETF Subject: Re: [babel] babel Digest, Vol 13, Issue 3 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 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, 30 Sep 2016 11:11:01 -0000 On Thu, 29 Sep 2016, Tony Przygienda wrote: > yep, jitter spec should say "you SHALL jitter" and _maybe_ give some kind > of bound like "5% is not enough, 50% is too generous". Beyond that, > specifying how and how much jitter to do has not proven helpful in specs > IME. https://en.wikipedia.org/wiki/Jitter https://en.wikipedia.org/wiki/Packet_delay_variation "In computer networking, packet delay variation (PDV) is the difference in end-to-end one-way delay between selected packets in a flow with any lost packets being ignored.[1] The effect is sometimes referred to as jitter, although the definition is an imprecise fit." I have found that for instance people doing electronics/timing/radio, they seem to get very upset when "jitter" is used in the context of packet send/receive times. If the spec:s are re-written, should this be fixed? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Sep 30 04:17:39 2016 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 3B4A212B2F1 for ; Fri, 30 Sep 2016 04:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 OBeHRJAjU9lG for ; Fri, 30 Sep 2016 04:17:34 -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 6727612B2E8 for ; Fri, 30 Sep 2016 04:17:34 -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/56228) with ESMTP id u8UBHT8c032125; Fri, 30 Sep 2016 13:17:29 +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 0983AD9617; Fri, 30 Sep 2016 13:17: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 hoBJwOwARBLC; Fri, 30 Sep 2016 13:17:23 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 5522ED9619; Fri, 30 Sep 2016 13:17:23 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.pps.univ-paris-diderot.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.87) (envelope-from ) id 1bpvoh-0001mu-4P; Fri, 30 Sep 2016 13:17:23 +0200 Date: Fri, 30 Sep 2016 13:17:23 +0200 Message-ID: <7iy429bprw.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: David Schinazi In-Reply-To: <32E33FB4-2785-4220-9C4D-F4097645D243@apple.com> References: <32E33FB4-2785-4220-9C4D-F4097645D243@apple.com> 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 [194.254.61.138]); Fri, 30 Sep 2016 13:17:29 +0200 (CEST) X-Miltered: at korolev with ID 57EE49C9.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57EE49C9.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 : 57EE49C9.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: Cc: babel@ietf.org Subject: Re: [babel] Comments on RFC 6126 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 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, 30 Sep 2016 11:17:37 -0000 Hi David, Sorry for the delay, but I've been overwhelmed with teaching. Tony's mail is what brought me out of my apathy. > *) Parts of the specification that I think may be incorrect > • in 3.1, "a Babel speaker does not need to determine the > destination address of a packet that it receives in order to > interpret it" isn't necessarily true in the case of IHU TLVs > with AE=0. I don't see the issue. AE=0 (which is NOT RECOMMENDED) can be used when an implementation doesn't want to bother with bidirectional reachability -- it just says "whoever you are, just assume I've heard you". It can be processed without knowing the destination address. > • 3.5.4 indicates that the route table is indexed by (neigh, id, > prefix), this should not include the router ID (as in 3.2.5) Colour me confused. 3.2.5 says It is indexed by triples of the form (prefix, plen, neighbour) > • typo in 3.8.1.2 "A node MUST NOT increase its sequence number by > more than 1 in response to a route request" should be seqno > request Ack, noted. > *) Parts of the specification that I found confusing > • when discussing addresses, "compression is allowed" is unclear - Ack. > • it was initially unclear that Hellos always require a seqno increment Perhaps 3.4.1 needs a detailed step-by-step description in the style of 3.5.4 ? > • the feasibility condition is discussed in terms of updates sent > instead of selected routes, which makes sense but feels odd It's actually not equivalent -- what you're suggesting is a uselessly stronger condition (one that makes more routes unfeasible). If you select a better route, until you've sent an update you haven't made any routes unfeasible, which can be important in periods of instability (path exploration doesn't make any routes unfeasible). And it's just as simple to implement as the uselessly stronger condition. > • When text discusses if we have an entry for that prefix, it > should be made clearer that it's for that explicit prefix, not > one that contains the requested one (as in a shorter prefix) Not sure, but noted. > • shouldn't the table of pending seqno requests (3.2.6) be indexed by routerID too? 3.8.1.2 is not clear about defining what redundant requests should be indexed on You might be right, I'm not sure. More comments on that at the very bottom of this mail. > • shouldn't the table of pending seqno requests also contain the > destination neighbor we sent it to? What for? > • the omitted field in updates / corresponding flag are > per-address family but it's unclear what to do when receiving > AE=3(IPv6LL) and omitted>0 (are the 64bits of fe80 considered > omitted?) Compression is not allowed for AE 3. This should be made explicit, noted. > • 3.2.5 should specify that the information in the source and > route tables are not quite the same. That's an editorial call, but I'd like to keep the description of the protocol as concise as reasonable, so any such clarifications should probably go into Section 2. > *) Parts of the specification / protocol that could be improved > • the jitter discussion concentrates on one possible solution, > delaying and buffering, but there are other solutions such as > not reseting timers based on outside events No objection, but since you want to accumulate multiple TLVs in a single packet, you're going to want to buffer TLVs anyhow. > • there's no reason for the IHU timer to live in the interface > table if IHUs are sent unicast Right. The data structures are conceptual, any implementation that yields equivalent results is fine. (Another example, noted by Markus, is that the route table could be split into a table of selected routes and a table of redundant ones.) > • handling of Hellos - this deserves a thread all to itself but in > a nutshell Hellos feel like the most constraining part of > Babel. Yes, that's an editorial flaw. It was actually even worse in earlier drafts, Joel did a great work forcing me to unconstrain this part of the protocol. I'm definitely open to that. > Also allowing for unicast Hellos could improve performance in some networks. Yes. This would require an actual protocol change -- either a new TLV for unicast Hellos, or adding a flag to the existing Hello. (Note that Hellos are already allowed to carry options, and there is one deployed extension that has Hellos with options, so it's not completely trivial to do in a backwards compatible manner.) > • would it make sense to use split horizon over wireless when > sharing routes over unicast? (conceptually this could be > equivalent to treating every neighbor as the other end of > a point-to-point link) Yes. I should try to write up the general property (the cases when split horizon is harmless). > • if we get a seqno request from the same node that advertised the > route would it make sense to treat that as a retraction? No. Babel carefully avoids overloading any TLVs -- every TLV has a well-specified meaning, and if you want to send two pieces of information, you send two TLVs. This is a very important property, and the one that makes the protocol so flexible. (For example, when doing the initial design, I was under pressure to overload the packet header with the semantics of Hello; had I done that, we would have been unable to extend Hellos, as we have done in the RTT extension). As you noted, you usually send a retraction together with a seqno request. Since the two TLVs get aggregated into a single packet, there's very little additional cost. > • what does an update with AE=0 and plen>0 mean? I'm planning to drop AE 0. > • what do you do on outgoing seqno requests if the route in > question has been unselected between retransmissions? This issue doesn't occur with RFC 6126, where seqno requests are indexed by prefix (see above). However, you might be right htat the request must be indexed by router-id, in which case soemthing needs to be done. (It's no big deal -- either you continue resending it, which helps maintain your redundant routes, or you drop the request. Either is fine.) -- Juliusz From nobody Fri Sep 30 04:19:17 2016 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 5A9B512B0B1 for ; Fri, 30 Sep 2016 04:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 QoUFIBQnYhrT for ; Fri, 30 Sep 2016 04:19:15 -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 D4BAE12B2D2 for ; Fri, 30 Sep 2016 04:19:14 -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/56228) with ESMTP id u8UBJDQe001376; Fri, 30 Sep 2016 13:19:13 +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 02933D7ACC; Fri, 30 Sep 2016 13:19:13 +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 4aTZ87XhM2iy; Fri, 30 Sep 2016 13:19:11 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E7CD8D7ACB; Fri, 30 Sep 2016 13:19:11 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.pps.univ-paris-diderot.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.87) (envelope-from ) id 1bpvqR-0001n1-O4; Fri, 30 Sep 2016 13:19:11 +0200 Date: Fri, 30 Sep 2016 13:19:11 +0200 Message-ID: <7iwphtbpow.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Tony Przygienda 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 [194.254.61.138]); Fri, 30 Sep 2016 13:19:13 +0200 (CEST) X-Miltered: at korolev with ID 57EE4A31.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57EE4A31.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 : 57EE4A31.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: Cc: Babel at IETF Subject: Re: [babel] babel Digest, Vol 13, Issue 3 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 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, 30 Sep 2016 11:19:16 -0000 > • if we get a seqno request from the same node that advertised the > route would it make sense to treat that as a retraction? > I wouldn't advise that. it may be in-flight transient and next thing you > start to shake your network using yet another dynamic control loop hoping > to improve things while making e'one spin their wheels. The requests are > fragile enough as they stand as I think wrote a while ago ... Fully agreed. -- Juliusz From nobody Fri Sep 30 04:31:54 2016 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 E385012B31B for ; Fri, 30 Sep 2016 04:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 J39QJnIEbb9k for ; Fri, 30 Sep 2016 04:31:46 -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 1130F12B31F for ; Fri, 30 Sep 2016 04:31: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/56228) with ESMTP id u8UBVhjT012218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Sep 2016 13:31:43 +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/56228) with ESMTP id u8UBVhKC007113; Fri, 30 Sep 2016 13:31:43 +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 7E02CD95E6; Fri, 30 Sep 2016 13:31:43 +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 6sBYosvwwHUN; Fri, 30 Sep 2016 13:31:42 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6A5D6D95BA; Fri, 30 Sep 2016 13:31:42 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.pps.univ-paris-diderot.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.87) (envelope-from ) id 1bpw2Y-0001pq-5w; Fri, 30 Sep 2016 13:31:42 +0200 Date: Fri, 30 Sep 2016 13:31:42 +0200 Message-ID: <7ivaxdbp41.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Mikael Abrahamsson 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]); Fri, 30 Sep 2016 13:31:43 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 30 Sep 2016 13:31:43 +0200 (CEST) X-Miltered: at korolev with ID 57EE4D1F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 57EE4D1F.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57EE4D1F.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 57EE4D1F.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 : 57EE4D1F.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 57EE4D1F.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: Cc: Babel at IETF Subject: Re: [babel] babel Digest, Vol 13, Issue 3 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 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, 30 Sep 2016 11:31:53 -0000 > I have found that for instance people doing electronics/timing/radio, they > seem to get very upset when "jitter" is used in the context of packet > send/receive times. > If the spec:s are re-written, should this be fixed? Tough call. Jitter is the right term for Hello, IHU and Update TLVs (deviation from the period), but for other types of TLVs, random delay makes more sense. I've checked Floyd and Jacobson, and they don't seem to have a nice, compact term (they say "the addition of a random component to the routing timer interval", which is a mouthful). I cannot find something as good as jitter, though. -- Juliusz