Hi,

I see that this mailing list has 44= subscribers.=C2=A0 One of the key questions, of course, is whether there i= s an active and energetic community of people interested in doing the work = to potentially standardize Babel.

From the side-me= eting, a point of having a mailing list was to discuss and clarify the pote= ntial applicability of babel, the motivations for standardizing it, and the= work to be done to bring Babel to a proposed standard.

Regards,

Alia

--089e0111b2a2b92987051c9426e5-- From nobody Mon Aug 10 01:31:56 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F121A6EE6 for ; Mon, 10 Aug 2015 01:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 f5WR_Afc5P6a for ; Mon, 10 Aug 2015 01:31:53 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 33C911ACE43 for ; Mon, 10 Aug 2015 01:31:53 -0700 (PDT) Received: by wicja10 with SMTP id ja10so27781162wic.1 for ; Mon, 10 Aug 2015 01:31:51 -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 :cc:content-type; bh=ywWai+xa3Xl7U2ub8XIv6/24/QusCrx4MGqy+33MWC8=; b=Om/Pf6SKpqZa+huQsaNUTPZ9iMftWZgJd8fnTdehJ7bHCkV4/0X8HGoSNXtMIoZDjr PR4dJmVLpPbvetW1UbNZKJPThzCQQ7JcDdnHlCRjcXmcRUEsJzilTdDbHxvDyeHoNHbp ub94DmGx9nLBFp5meIPR5g91FRxfhJWsgnPHzsqLnOBUP614Wz6F2gnPH+KiYiqvaJMQ IOORUONQqkrltz3M/L5kx+cSB/nJ6RK94d6hGCUslfhLn1CurbTSnXQXwv2/+qI4Bvc+ m44fRPv94zv6IzPWPwhZORFDyoyRJhE4gdZ0x44N4JEETxB0TYKaHba03+put1l/xGbn U+2Q== X-Received: by 10.180.74.229 with SMTP id x5mr21203495wiv.90.1439195511833; Mon, 10 Aug 2015 01:31:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.81.70 with HTTP; Mon, 10 Aug 2015 01:31:22 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Mon, 10 Aug 2015 10:31:22 +0200 Message-ID: To: Alia Atlas Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: babel@ietf.org Subject: Re: [babel] first message? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 10 Aug 2015 08:31:54 -0000 Hi, the Babel developer team (and quite a few people interested in Babel including me and Dave Taht) were on the Battlemesh (www.battlemesh.org) in Slovenia last week... where we did tests with 5 mesh routing protocols including Babel. so I expect the amounts of mails here to increase in the future. Henning Rogge On Wed, Aug 5, 2015 at 7:58 PM, Alia Atlas wrote: > Hi, > > I see that this mailing list has 44 subscribers. One of the key questions, > of course, is whether there is an active and energetic community of people > interested in doing the work to potentially standardize Babel. > > From the side-meeting, a point of having a mailing list was to discuss and > clarify the potential applicability of babel, the motivations for > standardizing it, and the work to be done to bring Babel to a proposed > standard. > > Regards, > Alia > > > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > From nobody Mon Aug 10 05:58:43 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3A61B3502 for ; Mon, 10 Aug 2015 05:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 s8wkpMbri71u for ; Mon, 10 Aug 2015 05:58:40 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 643071B3509 for ; Mon, 10 Aug 2015 05:58:40 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id CD3AFDA0077; Mon, 10 Aug 2015 12:58:39 +0000 (UTC) Received: from [10.0.20.218] (71.233.41.235) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 10 Aug 2015 05:58:39 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 8.2 $2102$) From: Ted Lemon In-Reply-To: Date: Mon, 10 Aug 2015 08:58:37 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2764EFB9-A025-44B3-939E-90309B0B9E6E@nominum.com> References: To: Henning Rogge X-Mailer: Apple Mail (2.2102) X-Originating-IP: [71.233.41.235] Archived-At: Cc: babel@ietf.org, Alia Atlas Subject: Re: [babel] first message? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 10 Aug 2015 12:58:41 -0000 One of the comments I saw from the battlemesh discussion is that the = babel implementation that Juliusz has done has substantial tweaks to = deal with the startup problem he described on WiFi networks. Are those = tweaks documented in the current specification? From nobody Mon Aug 10 11:45:08 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5C81B29DD for ; Mon, 10 Aug 2015 11:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.922 X-Spam-Level: X-Spam-Status: No, score=0.922 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_FR=0.35, URG_BIZ=0.573] autolearn=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 t5_8EyUbNstK for ; Mon, 10 Aug 2015 11:45:06 -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 31C561B29C7 for ; Mon, 10 Aug 2015 11:45:06 -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 t7AIj3kt008698; Mon, 10 Aug 2015 20:45:03 +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 742CE61F9D; Mon, 10 Aug 2015 20:45:04 +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 JBLYTstYgcSd; Mon, 10 Aug 2015 20:45:03 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (89-212-69-163.static.t-2.net [89.212.69.163]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 747F361F9A; Mon, 10 Aug 2015 20:45:03 +0200 (CEST) Date: Mon, 10 Aug 2015 20:45:04 +0200 Message-ID: <871tfb3rv3.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ted Lemon In-Reply-To: <2764EFB9-A025-44B3-939E-90309B0B9E6E@nominum.com> References: <2764EFB9-A025-44B3-939E-90309B0B9E6E@nominum.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]); Mon, 10 Aug 2015 20:45:03 +0200 (CEST) X-Miltered: at korolev with ID 55C8F12F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 55C8F12F.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 : 55C8F12F.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: [babel] Heuristics in Babel [was: first message?] X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 10 Aug 2015 18:45:07 -0000 > One of the comments I saw from the battlemesh discussion is that the > babel implementation that Juliusz has done has substantial tweaks to > deal with the startup problem he described on WiFi networks. Are those > tweaks documented in the current specification? I wouldn't call them substantial tweaks -- they are just two tradeoffs between spam and fast convergence that I had gotten wrong initially. (It took me a long, long time to understand that theoretical convergence speed is not the primary concern -- not breaking the medium is more important than the theoretical worst-case convergence time. Yeah, seems obvious in hindsight.) Concerning the noise at startup, RFC 6126 only has the following to say (Section 3.8.2.4): In order to speed up convergence after a mobility event, a node MAY send a unicast wildcard request after acquiring a new neighbour. Additionally, a node MAY send a small number of multicast wildcard requests shortly after booting. What I've learned since RFC 6126 was written is that a node SHOULD NOT do that, at least not without implementing some other mechanism to avoid spam. Additionally, 3.8.1.1 says When a node receives a wildcard route request, it SHOULD send a full routing table dump. What is missing here (which I didn't know at the time) is that the full route dump MAY be sent over either unicast or multicast, and that multicast full table dumps MUST be rate limited. (The current implementation uses multicast, and does do rate limiting.) As to the jitter, RFC 6126 is pretty clear. Section 3.1 says The exact delay and amount of jitter applied to a packet depends on whether it contains any urgent TLVs. Acknowledgement TLVs MUST be sent before the deadline specified in the corresponding request. The particular class of updates specified in Section 3.7.2 MUST be sent in a timely manner. The particular class of request and update TLVs specified in Section 3.8.2 SHOULD be sent in a timely manner. and the informative appendix B adds the following: The amount of jitter applied to a packet depends on whether it contains any urgent TLVs or not. Urgent triggered updates and urgent requests are delayed by no more than 200 ms; other TLVs are delayed by no more than one-half the Hello interval. I think this section should contain some words of caution about reducing the 200ms constant, at least on some media. (Editorial note: the document is not quite clear that the "urgent" TLVs of Appendix B are the ones that are sent "in a timely manner" in the body of the document.) Finally, RFC 6126 allows both unicast and multicast operation, and allows both unreliable and acknowledged communication. The current implementation uses multicast almost exclusively, and doesn't use any acknowledged packets; I still need to experiment with the alternatives. I'd be cautious about making anything of the above normatively constrained, since Babel interoperates just fine with differing time constants and emission strategies, and I am optimistic that the algorithms of the current implementation can be improved more. -- Juliusz From nobody Mon Aug 10 15:42:41 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195841A01A5 for ; Mon, 10 Aug 2015 15:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 k1P8bJyqglsA for ; Mon, 10 Aug 2015 15:42:38 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 474741A0120 for ; Mon, 10 Aug 2015 15:42:38 -0700 (PDT) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 2FC9CDA0072; Mon, 10 Aug 2015 22:42:38 +0000 (UTC) Received: from [10.0.20.218] (71.233.41.235) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 10 Aug 2015 15:42:37 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_5B3F9868-8AF5-452B-92B4-007C58BD2E99" MIME-Version: 1.0 (Mac OS X Mail 8.2 $2102$) From: Ted Lemon In-Reply-To: <871tfb3rv3.wl-jch@pps.univ-paris-diderot.fr> Date: Mon, 10 Aug 2015 18:42:35 -0400 Message-ID: References: <2764EFB9-A025-44B3-939E-90309B0B9E6E@nominum.com> <871tfb3rv3.wl-jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.2102) X-Originating-IP: [71.233.41.235] Archived-At: Cc: babel@ietf.org Subject: Re: [babel] Heuristics in Babel [was: first message?] X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 10 Aug 2015 22:42:40 -0000 --Apple-Mail=_5B3F9868-8AF5-452B-92B4-007C58BD2E99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Aug 10, 2015, at 2:45 PM, Juliusz Chroboczek = wrote: > I'd be cautious about making anything of the above normatively = constrained, > since Babel interoperates just fine with differing time constants and > emission strategies, and I am optimistic that the algorithms of the > current implementation can be improved more. It seems reasonable to say "here are the parameters that we know work in = practice, here are some examples of problems that occur if you use = values more in this range, and we think that further tuning is = possible," rather than making normative requirements, then, right? --Apple-Mail=_5B3F9868-8AF5-452B-92B4-007C58BD2E99 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" On Aug 10, 2015, at 2:45 PM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:

I'd be cautious about making anything of the = above normatively constrained,
since Babel interoperates just fine with = differing time constants and
emission strategies, and I = am optimistic that the algorithms of the
current implementation can be improved = more.

It = seems reasonable to say "here are the parameters that we know work in = practice, here are some examples of problems that occur if you use = values more in this range, and we think that further tuning is = possible," rather than making normative requirements, then, = right?

= --Apple-Mail=_5B3F9868-8AF5-452B-92B4-007C58BD2E99-- From nobody Tue Aug 11 16:16:48 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1A11B2A8E for ; Tue, 11 Aug 2015 16:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 PI9zW-jd9TNL for ; Tue, 11 Aug 2015 16:16:45 -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 37C061B2AAA for ; Tue, 11 Aug 2015 16:16:38 -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 t7BNGZLP021484; Wed, 12 Aug 2015 01:16:35 +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 C90D661F9A; Wed, 12 Aug 2015 01:16: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 AjOJCkHrmtcD; Wed, 12 Aug 2015 01:16:30 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 5E66861FA1; Wed, 12 Aug 2015 01:16:30 +0200 (CEST) Date: Wed, 12 Aug 2015 01:16:29 +0200 Message-ID: <87pp2t76wi.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: 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=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 12 Aug 2015 01:16:35 +0200 (CEST) X-Miltered: at korolev with ID 55CA8253.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 55CA8253.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 : 55CA8253.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: Cc: babel-users@lists.alioth.debian.org Subject: [babel] Babel to standard X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: babel@ietf.org 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, 11 Aug 2015 23:16:47 -0000 The goal of this mail is to list what I think are the issues with the current experimental Babel specification, RFC 6126, that should be fixed before Babel can be standardised, as well as improvements that I think are not needed. I'll wait a few days to see if consensus emerges, then I'll write up the results. This mail is crossposted between the babel@ietf and babel-users mailing lists. I've directed replies to babel@ietf, to which you're encouraged to subscribe: https://www.ietf.org/mailman/listinfo/babel MUST be fixed ============= Incorrect port number --------------------- The RFC gives an incorrect port number. There is an erratum to RFC 6126 to this effect. Garbage collecting routes ------------------------- RFC 6126 doesn't say when a route entry is garbage collected. The answer is -- it doesn't matter, just don't do it too early, but this needs to be stated explicitly. More precisely, a route entry SHOULD be garbage collected some time after it is retracted and blackholed (as described in Section 3.5.5), a couple of minutes is enough. That is a SHOULD, since nothing bad will happen if you don't -- you'll just run out of memory at some point. (Do people think that this deserves an erratum?) Ignoring extra data ------------------- Section 4.3 is clear that extra data after the end of the contents of a TLV MUST be silently ignored. However, two respectable implementors (Denis and Markus) got that wrong, so this needs to be made more prominent. Editorial changes ================= Merging extensions into the base spec ------------------------------------- Which, if any, of the currently defined extensions should be merged into the base spec? My opinion is that the extension mechanism should be merged, but that the actual extensions should remain separate documents. Describing the route selection algorithm ---------------------------------------- RFC 6126 states that designing a route selection algorithm for Babel is an open research problem. While this is still true, there should be an informative appendix that describes the trivial algorithm (just pick the route with the lowest metric) and the time-sensitive algorithm used since version 1.4.0 of babeld since it is simple and appears to work well in practice. Including suggested metric values --------------------------------- While suggested values for metrics on lossy links are described in Appendix A.2.2, no such values are described for lossless links (Appendix A.2.1). Changing "metric" to "primary metric" ------------------------------------- Babel is able to carry additional metrics in extension TLVs; the metric used in the Metric field is merely the "primary metric", the one that is used for loop avoidance and ensures interoperability between different extensions (which can always fall back to the primary metric). This should be made clear in the base spec, especially if the extension mechanism is merged. Deprecating wildcard requests ----------------------------- Wildcard requests are useful for debugging, but we now know that they SHOULD NOT be used in normal operation. Say that an implementation MUST limit the rate at which it honours such requests, and recommend that they SHOULD NOT be sent. Rethinking recommendations about seqno requests ----------------------------------------------- Loosen Section 3.8.2.1 -- the "SHOULD be multicast over all of the node's attached interfaces" is what the reference implementation does, but the spec should allow more parsimonious implementations. This is far from trivial to write. Incompatible protocol changes ============================= A Babel packet carries a protocol number, which it is possible to increase if the protocol needs to change in an incompatible version. I'd be opposed to doing that, since it would severely impact the installed base of Babel routers, and could cause a split in the community, as has unfortunately happened with the OLSR community. Using a wider primary metric ---------------------------- It has been suggested that the current 16 bits are not sufficient. However, an extended metric can be as wide as will fit in a sub-TLV (255 octets). The Babel-Z (diversity routing) metric, for example, has variable width. Unless you intend to put 65536 routers in a row, there is no need to extend the primary metric. Adding mandatory and transitive bits, as in BGP ----------------------------------------------- There is currently no way to mark a sub-TLV of an Update TLV as mandatory, as in BGP. This has forced us to design the source-specific extension as using a separate TLV, which is not very elegant. However, the source-specific extension would still have required new TLVs for requests. Mandatory and transitive bits would make it easier to design an extension that does BGP-style communities that are suitable for filtering, a feature that has been requested by both the Italian and Slovenian communities. I believe that the doubtful benefits that this provides do not justify an incompatible protocol change. Making source-specific routing part of the base spec ---------------------------------------------------- Source-specific routing uses its own set of TLVs, which are distinct from the base protocol's TLVs. Merging the two kinds of TLVs would yield a slightly cleaner protocol, but would require putting source-specific routing in the base spec. I like small specs. Removing prefix compression --------------------------- Joel dislikes prefix compression. I'm not sure I like it myself, but it yields a massive traffic reduction in typical IPv6 networks, and costs very little code. Security considerations ======================= There are at least four known ways to secure the Babel protocol: * lower-layer security (e.g. put a frightening guy or gal with a truncheon in front of each Ethernet plug, or use 802.1X); * HMAC authentication (RFC 7298); * Stenberg-style authentication (move everything to unicast except hellos, use DTLS); * use the replay protection from RFC 7298 together with statically keyed IPsec. There are different tradeoffs between these techniques (reuse of existing libraries vs. compact code, authentication only vs. privacy, etc.), so the current plan is to implement them all and let the community decide. I am therefore strongly opposed to putting any security mechanism in the base spec. From nobody Tue Aug 11 16:35:19 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0EC1A009C for ; Tue, 11 Aug 2015 16:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35] autolearn=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 4ULQ6-eZ-uFk for ; Tue, 11 Aug 2015 16:35: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 D54E41A0092 for ; Tue, 11 Aug 2015 16:35:16 -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 t7BNZEFx025494 for ; Wed, 12 Aug 2015 01:35: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 9157361FA0 for ; Wed, 12 Aug 2015 01:35: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 6YYY0kW_3PbD for ; Wed, 12 Aug 2015 01:35:14 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 8517261FA1 for ; Wed, 12 Aug 2015 01:35:14 +0200 (CEST) Date: Wed, 12 Aug 2015 01:35:14 +0200 Message-ID: <87lhdh7619.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: 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=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 12 Aug 2015 01:35:14 +0200 (CEST) X-Miltered: at korolev with ID 55CA86B2.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 55CA86B2.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 : 55CA86B2.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: [babel] Babel resources X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 11 Aug 2015 23:35:18 -0000 I'm trying to do my best to put all available Babel resources on the Babel web page: http://www.pps.univ-paris-diderot.fr/~jch/software/babel/ This contains links to three Babel-related RFCs and three I-Ds, as well as some slides and papers. Additions welcome. In addition, * the babel-users mailing list is the best place to discuss implementation and deployment issues: http://lists.alioth.debian.org/mailman/listinfo/babel-users * there is a #babel channel on the FreeNode IRC network, where a number of Babel experts hang out and generally behave in a friendly manner. -- Juliusz From nobody Tue Aug 11 18:02:24 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982541ACD5A for ; Tue, 11 Aug 2015 18:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 5WBnIEK8bAuU for ; Tue, 11 Aug 2015 18:02:21 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (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 79FDE1ACD80 for ; Tue, 11 Aug 2015 18:02:20 -0700 (PDT) Received: from 162-229-180-77.lightspeed.rlghnc.sbcglobal.net ([162.229.180.77]:62758 helo=RussPC) by server.riw.us with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1ZPKQq-00088t-JN; Wed, 12 Aug 2015 01:02:16 +0000 From: "Russ White" To: References: <87pp2t76wi.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <87pp2t76wi.wl-jch@pps.univ-paris-diderot.fr> Date: Tue, 11 Aug 2015 21:02:14 -0400 Message-ID: <030001d0d49a$879e6060$96db2120$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLijKEOsib3XtzUyxJgunR4fBLe7JvkGZGg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: babel-users@lists.alioth.debian.org Subject: Re: [babel] Babel to standard X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2015 01:02:23 -0000 > Which, if any, of the currently defined extensions should be merged into the > base spec? My opinion is that the extension mechanism should be merged, > but that the actual extensions should remain separate documents. I would agree with this assessment -- the extension mechanism should be merged in the base doc, but any actual extensions should be managed separately. I would say each proposed extension needs a pretty clear use case, a specification, and then an implementation report (if available), and possibly some form of deployment experience draft (if available). Smaller, more focused chunks are better than the long many page documents we've been seeing a lot of recently. > RFC 6126 states that designing a route selection algorithm for Babel is an > open research problem. While this is still true, there should be an > informative appendix that describes the trivial algorithm (just pick the route > with the lowest metric) and the time-sensitive algorithm used since version > 1.4.0 of babeld since it is simple and appears to work well in practice. Yes, definitely. Note that choosing a route across two metrics is, as I understand it, unsolvable. This is the reason EIGRP uses the K values to merge the metrics the user would like to actually deploy into a single metric. Note also there needs to be some way to prevent oscillation between the control plane and the data plane when you start playing with delay, bandwidth utilization, etc., in the real world. These are nasty problems. > Incompatible protocol changes > ============================= > > A Babel packet carries a protocol number, which it is possible to increase if > the protocol needs to change in an incompatible version. I'd be opposed to > doing that, since it would severely impact the installed base of Babel routers, > and could cause a split in the community, as has unfortunately happened > with the OLSR community. A protocol version? It would be simpler to have some sort of capabilities negotiation here, possibly. > Adding mandatory and transitive bits, as in BGP > ----------------------------------------------- > > There is currently no way to mark a sub-TLV of an Update TLV as mandatory, > as in BGP. This has forced us to design the source-specific extension as using > a separate TLV, which is not very elegant. However, the source-specific > extension would still have required new TLVs for requests. > > Mandatory and transitive bits would make it easier to design an extension > that does BGP-style communities that are suitable for filtering, a feature that > has been requested by both the Italian and Slovenian communities. > > I believe that the doubtful benefits that this provides do not justify an > incompatible protocol change. I would disagree... It's better to have some way for a device receiving an update if it should ignore and potentially send an error, or if it should try and process. If you don't have mandatory bits, then you don't have a way to error out of a neighbor relationship. This means the receiver can either just bounce the relationship and refuse to peer, which is really hard to troubleshoot, or it can accept and ignore, which can also be really hard to troubleshoot. > Source-specific routing uses its own set of TLVs, which are distinct from the > base protocol's TLVs. Merging the two kinds of TLVs would yield a slightly > cleaner protocol, but would require putting source-specific routing in the > base spec. I like small specs. I would keep the specs separate, myself. > * lower-layer security (e.g. put a frightening guy or gal with > a truncheon in front of each Ethernet plug, or use 802.1X); > * HMAC authentication (RFC 7298); > * Stenberg-style authentication (move everything to unicast except > hellos, use DTLS); > * use the replay protection from RFC 7298 together with statically keyed > IPsec. > > There are different tradeoffs between these techniques (reuse of existing > libraries vs. compact code, authentication only vs. privacy, etc.), so the > current plan is to implement them all and let the community decide. I am > therefore strongly opposed to putting any security mechanism in the base > spec. I would allow separate development in this area -- but it does need to be done. I would look at requirements and solutions, and make a single decision. Otherwise you fragment the implementations, as not every one of these is as easy to implement as it might seem, and you might find holes that need to be fixed in all four at some point. A single solution is better, IMHO. :-) Russ From nobody Tue Aug 11 18:36:28 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F41C1A1B6C for ; Tue, 11 Aug 2015 18:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_FR=0.35] autolearn=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 5x3mCsuYl09o for ; Tue, 11 Aug 2015 18:36:26 -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 F3F721A1B66 for ; Tue, 11 Aug 2015 18:36:25 -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 t7C1aMXI014395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Aug 2015 03:36:23 +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 t7C1aMDF011149; Wed, 12 Aug 2015 03:36:22 +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 9731D61F9D; Wed, 12 Aug 2015 03:36:23 +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 fznZmQR_EZn4; Wed, 12 Aug 2015 03:36:22 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7F3DE61F9A; Wed, 12 Aug 2015 03:36:21 +0200 (CEST) Date: Wed, 12 Aug 2015 03:36:21 +0200 Message-ID: <87d1yt70fe.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Russ White" In-Reply-To: <030001d0d49a$879e6060$96db2120$@riw.us> References: <87pp2t76wi.wl-jch@pps.univ-paris-diderot.fr> <030001d0d49a$879e6060$96db2120$@riw.us> 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, 12 Aug 2015 03:36:23 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 12 Aug 2015 03:36:23 +0200 (CEST) X-Miltered: at korolev with ID 55CAA316.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 55CAA316.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 55CAA316.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 55CAA316.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 : 55CAA316.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 55CAA316.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: Cc: babel-users@lists.alioth.debian.org, babel@ietf.org Subject: Re: [babel] Babel to standard X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2015 01:36:28 -0000 I've reordered your comments. > I would say each proposed extension needs a pretty clear use case, > a specification, and then an implementation report (if available), and > possibly some form of deployment experience draft (if available). That's not the way we work, here at Babel Towers. We don't usually develop an extension without an actual feature request from our users, and we never freeze the protocol until we have both working code and deployment experience. We're very serious about that. > A protocol version? It would be simpler to have some sort of capabilities > negotiation here, possibly. That's not how Babel works. A Babel router simply ignores any routes it doesn't grok. In other words, capability negotiation happens at route granularity, not at neighbour relationship granularity. > Note that choosing a route across two metrics is, as I understand it, > unsolvable. This is the reason EIGRP uses the K values to merge the > metrics A given router must use a single metric (at least in the absence of TOS-specific routing and similar), granted, but distinct routers may use different metrics. This is analogous to routing policies in BGP. > Note also there needs to be some way to prevent oscillation between the > control plane and the data plane when you start playing with delay, > bandwidth utilization, etc., in the real world. These are nasty > problems. Absolutely. We have worked really hard on stability, this is described in detail in Baptiste Jonglez, Matthieu Boutier (PPS), Juliusz Chroboczek. A delay-based routing metric. Unpublished draft. 2014. http://arxiv.org/pdf/1403.3488 -- Juliusz From nobody Wed Aug 12 01:39:24 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453181B2C72 for ; Wed, 12 Aug 2015 01:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 3z_todtLRQCI for ; Wed, 12 Aug 2015 01:39:21 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (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 752641A1BB4 for ; Wed, 12 Aug 2015 01:39:21 -0700 (PDT) Received: by wicja10 with SMTP id ja10so104181811wic.1 for ; Wed, 12 Aug 2015 01:39:20 -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 :cc:content-type; bh=cf4gDR5d7xcqhkp2zDZ8QqXirC6hj5egw5SIzW5/Am0=; b=AOhFnH1EnZpCG/vmgVs1hKYZfdz+NwHwSuAJWczEOOzunxMx0lzRt9MKkyGY4BLLqo noJr0iUh2QcjxE82hZe0IlIX901WRPtiaAdOUtJ7hnwQreWtskySSpFWKKzUpDcLlBHy nR5lsZqaN6Dv07z9BeBBRU9pGBujNzdGFjK+UCV6gDbFaJi7TacoCuIfvvogc1VWcMQh bh4o08fpOgkaFrcr0X+ccdSM40Gn2hD92WDsRfiYB92BKnMCTcuAohw4Vj9omZ92yicU vSjZ/4zamdnBg0at6x4J1QpPsvc5RdLdBku5NVqqdC4HzjjBqgHGVltUEqJm1Liey4l+ GxWQ== X-Received: by 10.180.106.68 with SMTP id gs4mr38333148wib.61.1439368760210; Wed, 12 Aug 2015 01:39:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.81.70 with HTTP; Wed, 12 Aug 2015 01:38:50 -0700 (PDT) In-Reply-To: <038c01d0d49d$70d278a0$527769e0$@riw.us> References: <87pp2t76wi.wl-jch@pps.univ-paris-diderot.fr> <038c01d0d49d$70d278a0$527769e0$@riw.us> From: Henning Rogge Date: Wed, 12 Aug 2015 10:38:50 +0200 Message-ID: To: Russ White Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: babel-users , babel@ietf.org Subject: Re: [babel] [Babel-users] Babel to standard X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2015 08:39:23 -0000 On Wed, Aug 12, 2015 at 3:23 AM, Russ White wrote: >> * lower-layer security (e.g. put a frightening guy or gal with >> a truncheon in front of each Ethernet plug, or use 802.1X); >> * HMAC authentication (RFC 7298); >> * Stenberg-style authentication (move everything to unicast except >> hellos, use DTLS); >> * use the replay protection from RFC 7298 together with statically keyed >> IPsec. >> >> There are different tradeoffs between these techniques (reuse of existing >> libraries vs. compact code, authentication only vs. privacy, etc.), so the >> current plan is to implement them all and let the community decide. I am >> therefore strongly opposed to putting any security mechanism in the base >> spec. > > I would allow separate development in this area -- but it does need to be > done. I know that the OLSRv2 document was delayed by a long time because we had planned to put security into a second document. > I would look at requirements and solutions, and make a single > decision. Otherwise you fragment the implementations, as not every one of > these is as easy to implement as it might seem, and you might find holes > that need to be fixed in all four at some point. A single solution is > better, IMHO. The problem is that the selected solution heavily depends on the network you plan to deploy. See here for the "compromise" that were used for OLSRv2: https://tools.ietf.org/html/rfc7181#section-23.5 We should get a security AD involved before we decide "this is enough for Standard Track Babel" and get an unpleasant surprise. Henning Rogge From nobody Wed Aug 12 02:37:47 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8721C1A0027 for ; Wed, 12 Aug 2015 02:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_FR=0.35] autolearn=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 ui4FuUJep_1Z for ; Wed, 12 Aug 2015 02:37:45 -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 B48361A0026 for ; Wed, 12 Aug 2015 02:37: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 t7C9bfjm011632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Aug 2015 11:37:41 +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 t7C9bfOG022532; Wed, 12 Aug 2015 11:37:41 +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 8A6C661F9D; Wed, 12 Aug 2015 11:37:42 +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 X_D-yp6nlrul; Wed, 12 Aug 2015 11:37:41 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 5276B61FA0; Wed, 12 Aug 2015 11:37:41 +0200 (CEST) Date: Wed, 12 Aug 2015 11:37:42 +0200 Message-ID: <877fp03l09.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Henning Rogge In-Reply-To: References: <87pp2t76wi.wl-jch@pps.univ-paris-diderot.fr> <038c01d0d49d$70d278a0$527769e0$@riw.us> 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, 12 Aug 2015 11:37:41 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 12 Aug 2015 11:37:42 +0200 (CEST) X-Miltered: at korolev with ID 55CB13E5.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 55CB13E5.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 55CB13E5.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 55CB13E5.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 : 55CB13E5.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 55CB13E5.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@ietf.org Subject: [babel] [Off topic] MTI security X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2015 09:37:46 -0000 CC restricted to babel@ietf > See here for the "compromise" that were used for OLSRv2: > https://tools.ietf.org/html/rfc7181#section-23.5 This section is being widely ignored in the wild, as far as I can tell. The main effect of the insistence of the security people on MTI security mechanisms is to train the users and implementers to ignore MUST requirements in standard track RFCs. I would like the security people to make an empirical review of the effects of their actions before continuing with this nonsense. (DLEP, I'm looking at you.) -- Juliusz From nobody Wed Aug 12 03:22:06 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C48D1A00E2 for ; Wed, 12 Aug 2015 03:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 haxJ95i6Wc0D for ; Wed, 12 Aug 2015 03:22:03 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::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 893B11A00E1 for ; Wed, 12 Aug 2015 03:22:03 -0700 (PDT) Received: by wicja10 with SMTP id ja10so21237425wic.1 for ; Wed, 12 Aug 2015 03:22:02 -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 :cc:content-type; bh=SA7fpwBv33J819Gni/4BRFt5y22xh3WDbBPI/0l+BfQ=; b=NREpHDKix+Y2Fi5zT9wTuNmBB92drlx8A0ECtdkPcmFHzVEH83jemImGZNnmtvPz5K bi61BhAq1FebuTgJELLpLwWZLW0BiWGx3HHr9NpW9emopSUWDMjmUKZRb235HyJTOBM0 IgIAJ3/520AECEYk+mj6soRrgmYjBp2iW4KZeGJ1Fx4M8Ls+mOvHUXESUttRxM0S6XVM KvVhfIi8fQ61q2VCzvbVyVZKC4sLcSTbJetSYFP4qZ5s05LEBpKwc5JuX8kNPTeHiAL3 St4ZP7zgI31nL2rG4ZQY6hSA3pEg55/5bQSM//7abG5s/ip8Pt0wzC6lWl84UxigTv3S Df0A== X-Received: by 10.194.2.9 with SMTP id 9mr63984509wjq.95.1439374921883; Wed, 12 Aug 2015 03:22:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.81.70 with HTTP; Wed, 12 Aug 2015 03:21:32 -0700 (PDT) In-Reply-To: <877fp03l09.wl-jch@pps.univ-paris-diderot.fr> References: <87pp2t76wi.wl-jch@pps.univ-paris-diderot.fr> <038c01d0d49d$70d278a0$527769e0$@riw.us> <877fp03l09.wl-jch@pps.univ-paris-diderot.fr> From: Henning Rogge Date: Wed, 12 Aug 2015 12:21:32 +0200 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: babel@ietf.org Subject: Re: [babel] [Off topic] MTI security X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2015 10:22:05 -0000 On Wed, Aug 12, 2015 at 11:37 AM, Juliusz Chroboczek wrote: > CC restricted to babel@ietf > >> See here for the "compromise" that were used for OLSRv2: >> https://tools.ietf.org/html/rfc7181#section-23.5 > > This section is being widely ignored in the wild, as far as I can tell. Yes... I have implemented the security extensions far later than the core code and I don't think the suggested "shared secret HMAC" security is more useful than pure layer-2 hop-by-hop security. And I definitely do not suggest activating the shared-key security by default. Especially because layer-2 security (e.g. WPA2 for 802.11 adhoc mode) also provides security for the user traffic. > The main effect of the insistence of the security people on MTI security > mechanisms is to train the users and implementers to ignore MUST > requirements in standard track RFCs. I would like the security people to > make an empirical review of the effects of their actions before continuing > with this nonsense. > The main effect of the insistence of the security people on MTI security > mechanisms is to train the users and implementers to ignore MUST > requirements in standard track RFCs. I would like the security people to > make an empirical review of the effects of their actions before continuing > with this nonsense. *sigh* > (DLEP, I'm looking at you.) Yes, its even worst in the DLEP case because DLEP has no "over the air" component and is "node local". Henning Rogge From nobody Wed Aug 12 11:29:32 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869951A1B91 for ; Wed, 12 Aug 2015 11:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ZnNtrIFRje8V for ; Wed, 12 Aug 2015 11:29:29 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C9F1A0063 for ; Wed, 12 Aug 2015 11:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=672; q=dns/txt; s=iport; t=1439404170; x=1440613770; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yny+jfdQTgTnBfQtpzlRKpRmKsgV6QB3X561k2KB+yc=; b=kOvEXvcvLDV2+XUsfYNJMv4+D6O1BXdpxGTr0LAabLtf26NdcWWylUPF UHcMkYq+S4EtDzN9ZJkYQO7yaPP4v9wmCWjsGdoSILwrD8eTD24L6I/Yj 9MCC22l18kLpdcSL6SXXVFu9DWY0Z3qvA3lViWH7fo6EbW14hqaEoYMQe A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AiAwB7j8tV/4kNJK1dgxuBPQa9ZwmHbgKBTTgUAQEBAQEBAYEKhCQBAQR5EAIBCA44IRElAgQBDQUbh34DEsspDYU8AQEBAQEBAQEBAQEBAQEBAQEBAQEYi1OCT4IHMweELAEEkguDCAGKfoFtkl6HMyaDfXGBSIEEAQEB X-IronPort-AV: E=Sophos;i="5.15,663,1432598400"; d="scan'208";a="178009710" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 12 Aug 2015 18:29:29 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t7CITSsm031644 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Aug 2015 18:29:29 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 12 Aug 2015 13:29:28 -0500 Received: from xhc-aln-x13.cisco.com (173.36.12.87) by xch-aln-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 12 Aug 2015 13:29:28 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.148]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0248.002; Wed, 12 Aug 2015 13:29:28 -0500 From: "Alvaro Retana (aretana)" To: Henning Rogge , Russ White Thread-Topic: [babel] [Babel-users] Babel to standard Thread-Index: AQHQ1NpmsLlLidDSCEa0+zOo4Nx3tp4IwKwA Date: Wed, 12 Aug 2015 18:29:27 +0000 Message-ID: References: <87pp2t76wi.wl-jch@pps.univ-paris-diderot.fr> <038c01d0d49d$70d278a0$527769e0$@riw.us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.30] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: babel-users , "babel@ietf.org" Subject: Re: [babel] [Babel-users] Babel to standard X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2015 18:29:31 -0000 On 8/12/15, 4:38 AM, "babel on behalf of Henning Rogge" wrote: Hi! >The problem is that the selected solution heavily depends on the >network you plan to deploy. This is an excellent point =8B not just related to security, but in general= . The applicability =8B what problem will Babel solve? Where is it expected to be used? Etc. =8B is of great importance to scope whatever effort is done going forward. IMHO, that should be one of the first things that are discussed =8B maybe the specifics are obvious to everyone on the list, but they still need to be documented. Thanks! Alvaro. From nobody Wed Aug 12 14:02:48 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C220D1ACDE9 for ; Wed, 12 Aug 2015 14:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 eZf0wdqjTRKB for ; Wed, 12 Aug 2015 14:02:38 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (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 6656B1ACDE5 for ; Wed, 12 Aug 2015 14:02:38 -0700 (PDT) Received: from 162-229-180-77.lightspeed.rlghnc.sbcglobal.net ([162.229.180.77]:58588 helo=RussPC) by server.riw.us with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1ZPdAR-0002E0-Oa for babel@ietf.org; Wed, 12 Aug 2015 21:02:36 +0000 From: "Russ White" To: Date: Wed, 12 Aug 2015 17:02:33 -0400 Message-ID: <03c701d0d542$35c78390$a1568ab0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGdjtmkciLQVW+PCjgcE2c7pIbM5Q== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [babel] Thoughts on Other Use Cases X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2015 21:02:40 -0000 Y'all -- One thing that might be really nice is to have a brainstorm about alternate use cases for BABEL. Two I can think of off the top of my head are: 1. Data center fabric underlay/overlay. I know we're all moving in the BGP/eVPN direction on this right now, but I think BABEL could perform in this space with a simpler/more tuned protocol. It would take adding some things, such as some sort of "community" or policy support and some sort of "any AF to any AF" sort of support, but this might be a solid use case for fast convergences in a simple, pretty much self-configuring protocol. 2. Much the same for something like DMVPNs, only with more support to get closer to something like SD-WAN capabilities in a standards based setup. 3. A sort-of crazy idea, but one of the "bigger" problems with link state is it's performance over large scale hub and spoke networks. One place EIGRP has been really successful is in this space, actually. Perhaps some way of doing large scale hub and spoke so the hub routers simply pull the information as native link state protocol information. To put this another way, to have BABEL serve as a "feeder" for a link state protocol, with no redistribution. I'm not convinced this sort of thing is possible, but it would be interesting to look at. 4. MANET -- as an alternative to the existing OSPF and other work. Any more ideas? Thoughts on these ideas? :-) Russ From nobody Wed Aug 12 14:24:24 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD5A1ACE0A for ; Wed, 12 Aug 2015 14:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=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 oEDeM_cLKEVh for ; Wed, 12 Aug 2015 14:24:21 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (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 9E0051ACE08 for ; Wed, 12 Aug 2015 14:24:21 -0700 (PDT) Received: by qgdd90 with SMTP id d90so19720753qgd.3 for ; Wed, 12 Aug 2015 14:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4j+TvbZ/7M9rq2OzFc9BVUOpmATf32+Ao30oNO1PVVk=; b=aGSyqHdoiTRMCL8Uury7Fb3I1Cif+brj10gW0uzpWcVVHywcvlLsuCuEXKFKS7oG97 bhzFUccw4OZUXm1f1kqIVIwk1/VlpK9ag/Fo9BLt2fZMu+7+yFw3lzmPOFTNOKlzXD9S C+IDWu0wvif6BDfZxGG6kWk0HxHbJYBmdRcrCsrgxs2a7zHlN22bORvX0uuQekUOwW3n qokrU0whE2AJ0H4kPX3qY8299AZwQIe9E/fi6n6cwjVCm9TZD9EUUY7UAkAkY2mdJMgc 577YNs+VxJSiqFR4De4Rifhazez98NovyWObzxRFQAbDlHdIOByRtqPB3IJvWbju5jK7 JkMA== X-Received: by 10.140.152.208 with SMTP id 199mr63898067qhy.99.1439414660850; Wed, 12 Aug 2015 14:24:20 -0700 (PDT) Received: from [192.168.0.103] (cpe-74-75-98-143.maine.res.rr.com. [74.75.98.143]) by smtp.gmail.com with ESMTPSA id 77sm67188qhw.4.2015.08.12.14.24.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Aug 2015 14:24:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) From: Margaret Cullen In-Reply-To: <03c701d0d542$35c78390$a1568ab0$@riw.us> Date: Wed, 12 Aug 2015 17:24:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03c701d0d542$35c78390$a1568ab0$@riw.us> To: "Russ White" X-Mailer: Apple Mail (2.1510) Archived-At: Cc: babel@ietf.org Subject: Re: [babel] Thoughts on Other Use Cases X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2015 21:24:23 -0000 Interesting ideas, Russ. I particularly like the idea of using babel as = a data center underlay/overlay. I am working on a transitive trust system for use with the IETF's abfab = (GSS-EAP) security protocols. The system deploys a number of "Trust = Routers" that distribute information about "Trust Paths" to reach the = AAA servers for target realms across a AAA fabric. I have just started = work on a dynamic "routing protocol" for this system. I had been = considering using a link-state algorithm, but I'm currently assessing = the possibility of using a DV protocol based on babel, since it looks = like it will be easier to implement and, perhaps more importantly, = easier to test. Margaret On Aug 12, 2015, at 5:02 PM, "Russ White" wrote: > Y'all -- >=20 > One thing that might be really nice is to have a brainstorm about = alternate > use cases for BABEL. Two I can think of off the top of my head are: >=20 > 1. Data center fabric underlay/overlay. I know we're all moving in the > BGP/eVPN direction on this right now, but I think BABEL could perform = in > this space with a simpler/more tuned protocol. It would take adding = some > things, such as some sort of "community" or policy support and some = sort of > "any AF to any AF" sort of support, but this might be a solid use case = for > fast convergences in a simple, pretty much self-configuring protocol. >=20 > 2. Much the same for something like DMVPNs, only with more support to = get > closer to something like SD-WAN capabilities in a standards based = setup. >=20 > 3. A sort-of crazy idea, but one of the "bigger" problems with link = state is > it's performance over large scale hub and spoke networks. One place = EIGRP > has been really successful is in this space, actually. Perhaps some = way of > doing large scale hub and spoke so the hub routers simply pull the > information as native link state protocol information. To put this = another > way, to have BABEL serve as a "feeder" for a link state protocol, with = no > redistribution. I'm not convinced this sort of thing is possible, but = it > would be interesting to look at. >=20 > 4. MANET -- as an alternative to the existing OSPF and other work. >=20 > Any more ideas? Thoughts on these ideas? >=20 > :-) >=20 > Russ=20 >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Wed Aug 12 14:47:26 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D0E1ACE2D for ; Wed, 12 Aug 2015 14:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 eIbjhocGAT4l for ; Wed, 12 Aug 2015 14:47: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 201141ACE2A for ; Wed, 12 Aug 2015 14:47:22 -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 t7CLlJ6m024119; Wed, 12 Aug 2015 23:47: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 1E67D61F9D; Wed, 12 Aug 2015 23:47:21 +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 YyMIALeoJ949; Wed, 12 Aug 2015 23:47:20 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1476161F9A; Wed, 12 Aug 2015 23:47:19 +0200 (CEST) Date: Wed, 12 Aug 2015 23:47:19 +0200 Message-ID: <87h9o4npqw.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Russ White" In-Reply-To: <03c701d0d542$35c78390$a1568ab0$@riw.us> References: <03c701d0d542$35c78390$a1568ab0$@riw.us> 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, 12 Aug 2015 23:47:20 +0200 (CEST) X-Miltered: at korolev with ID 55CBBEE7.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 55CBBEE7.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 : 55CBBEE7.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] Thoughts on Other Use Cases X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2015 21:47:25 -0000 Hi Russ, > 1. Data center fabric underlay/overlay. [...] > It would take adding some things, such as some sort of "community" or > policy support As all DV protocols, Babel supports pretty much arbitrary filtering of routes. What is missing is the ability to attach opaque labels ("communities") to routes; while this could be added by an extension, reliable filtering would require ensuring that all routers support the extension. Or is that not what you meant? > some sort of "any AF to any AF" sort of support Please clarify. > 2. Much the same for something like DMVPNs I'll pass on this one, not sure what's required from the routing protocol for DMVPNs. Is that not similar to your point (3) below? > 3. A sort-of crazy idea, but one of the "bigger" problems with link > state is it's performance over large scale hub and spoke networks. One > place EIGRP has been really successful is in this space Agreed, with filtering and split-horizon processing, DV should scale really well in this kind of topology. > with no redistribution Please clarify. > 4. MANET -- as an alternative to the existing OSPF and other work. (I think you meant OLSR.) Actually, most of the deployment of Babel is happening in the community mesh networking space and the proprietary MANET space. While OLSRv2 is a fine protocol, Babel has some properties that make it attractive in large meshes: - much lower overhead on wired links and VPNs, especially if the frequency of periodic updates is tuned down; - ability to perform arbitrary route filtering and (manual) aggregation (OLSRv2 doesn't have areas, so it cannot perform filtering); - good support for dual-stack networks. An interesting application is the Italian community mesh, where every regional mesh uses its protocol of choice, and the meshes redistribute into Babel and peer over VPNs. I find it interesting that Babel has filled the niche of BGP -- it's fairly natural to use DV for peering, due to the filtering capabilities. One feature that the community people find missing is the ability to find out if two remote interfaces belong to the same router -- something you get for free in link-state, but that you cannot determine at all in distance vector. I'm half tempted to implement an extension that allows a router to announce its set of attached interfaces (e.g. within a sub-TLV of the Hello TLV), unless somebody has a better idea. -- Juliusz From nobody Wed Aug 12 14:52:23 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D32D1ACE47 for ; Wed, 12 Aug 2015 14:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 UsksutWRRbyl for ; Wed, 12 Aug 2015 14:52:21 -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 607A51ACE44 for ; Wed, 12 Aug 2015 14:52:21 -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 t7CLqIxS024557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Aug 2015 23:52:18 +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 t7CLqI8P008716; Wed, 12 Aug 2015 23:52:18 +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 7A94961FA2; Wed, 12 Aug 2015 23:52:19 +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 aT8U1aQUzdhp; Wed, 12 Aug 2015 23:52:14 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7B0C661F9D; Wed, 12 Aug 2015 23:52:14 +0200 (CEST) Date: Wed, 12 Aug 2015 23:52:14 +0200 Message-ID: <87fv3onpip.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Margaret Cullen In-Reply-To: References: <03c701d0d542$35c78390$a1568ab0$@riw.us> 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, 12 Aug 2015 23:52:18 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 12 Aug 2015 23:52:18 +0200 (CEST) X-Miltered: at korolev with ID 55CBC012.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 55CBC012.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 55CBC012.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 55CBC012.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 : 55CBC012.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 55CBC012.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: Cc: babel@ietf.org Subject: Re: [babel] Thoughts on Other Use Cases X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2015 21:52:22 -0000 > The system deploys a number of "Trust Routers" that distribute > information about "Trust Paths" to reach the AAA servers for target > realms across a AAA fabric. [...] I had been considering using > a link-state algorithm, but I'm currently assessing the possibility of > using a DV protocol based on babel Note that if you're doing flat routing (host routes only), Babel can be simplified a lot -- you don't need router-ids, just index everything by addresses (the route table, the source table, the pending requests table, the duplicate suppression table). You can also get rid of the mechanism in Section 3.5.5. -- Juliusz From nobody Wed Aug 12 15:20:28 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E511ACE89 for ; Wed, 12 Aug 2015 15:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 u09AZN2sSAeE for ; Wed, 12 Aug 2015 15:20:16 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (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 D0B2C1ACE8E for ; Wed, 12 Aug 2015 15:20:12 -0700 (PDT) Received: from 162-229-180-77.lightspeed.rlghnc.sbcglobal.net ([162.229.180.77]:59596 helo=RussPC) by server.riw.us with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1ZPeNS-00035t-QN; Wed, 12 Aug 2015 22:20:08 +0000 From: "Russ White" To: "'Juliusz Chroboczek'" References: <03c701d0d542$35c78390$a1568ab0$@riw.us> <87h9o4npqw.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <87h9o4npqw.wl-jch@pps.univ-paris-diderot.fr> Date: Wed, 12 Aug 2015 18:20:03 -0400 Message-ID: <047601d0d54d$09fe8e60$1dfbab20$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLbZJjRp7J+qFFwsYH0mDjXxS/4qgIuid+Tm+JZFVA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: babel@ietf.org Subject: Re: [babel] Thoughts on Other Use Cases X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2015 22:20:26 -0000 > > 1. Data center fabric underlay/overlay. > [...] > > It would take adding some things, such as some sort of "community" or > > policy support > > As all DV protocols, Babel supports pretty much arbitrary filtering of routes. > What is missing is the ability to attach opaque labels > ("communities") to routes; while this could be added by an extension, > reliable filtering would require ensuring that all routers support the > extension. Right -- one of the points with a DC overlay is the ability to filter routes using something like a route target, to reduce the number of devices that need to hold specific routes in their table. You also need to have a route distinguisher, which allows overlapping reachability information, and the ability to differentiate multiple virtual topologies. All of these can be solved with some sort of community system, or opaque tags. > > some sort of "any AF to any AF" sort of support > > Please clarify. One of the issues with overlay support would be the ability to have multiple tunnel systems. For instance, you could have -- IPv4 over IPv6 IPv6 over IPv4 IPv4/IPv6 over MPLS IPv4/IPv6 over VxLAN Ethernet over MPLS Ethernet over VxLAN The idea here is just to have some sort of TLV that allows any address family as a destination, and then any address family as the "next hop" for this given destination. This would allow you to draw any traffic into any sort of tunnel. BGP does this with a (possible more complex than necessary for a DC fabric) address family system (originally designed for L3VPNs). We could do something simpler in BABEL, I think for the DC fabric case. > > 2. Much the same for something like DMVPNs > > I'll pass on this one, not sure what's required from the routing protocol for > DMVPNs. Is that not similar to your point (3) below? Yes, but combined with the AF above... DMVPNs are similar to an SD-WAN solution, an tunneled overlay (virtual topology) on top of a straight IP network. A lot of companies are working in this space right now with proprietary systems; having an IETF standard that meets all the requirements in a simpler protocol would make a lot of sense. Cisco uses EIGRP for this function, BTW, so there's a close analog already out there we could draw from in terms of system level design work. > > 3. A sort-of crazy idea, but one of the "bigger" problems with link > > state is it's performance over large scale hub and spoke networks. > > One place EIGRP has been really successful is in this space > > Agreed, with filtering and split-horizon processing, DV should scale really well > in this kind of topology. > > > with no redistribution > > Please clarify. In OSPF and IS-IS, you already have the concept of a flooding domain boundary. What a lot of designers do is put the ABR (in OSPF terms) on the hub router in a large scale hub and spoke network. Of course, you can use a distance vector protocol, like EIGRP, in the hub and spoke, and then redistribute the routes into the link state protocol, but it would actually be a lot cleaner to have a way to simply pull the distance-vector routes in so they look like they're internal to the link state protocol. As an example, look at the TTZ work going on in OSPF. Replace the TTZ subzone running OSPF with a subzone running BABEL to get a general idea... It would need more working out than that -- this is completely brainstorming... :-) > > 4. MANET -- as an alternative to the existing OSPF and other work. > > (I think you meant OLSR.) OLSR and OSPF. > Actually, most of the deployment of Babel is happening in the community > mesh networking space and the proprietary MANET space. While OLSRv2 is a > fine protocol, Babel has some properties that make it attractive in large > meshes: Okay... So one thing we could do here is to level set against the requirements there, to make certain everything is covered. It might be interesting to see if there are overlaps between the different sets of requirements for some potential use cases, to see what sorts of interesting things could be done. For instance, the AF concept would be useful for an SD-WAN solution, for a DC overlay, and even potentially for the MANET space. > An interesting application is the Italian community mesh, where every > regional mesh uses its protocol of choice, and the meshes redistribute into > Babel and peer over VPNs. I find it interesting that Babel has filled the niche > of BGP -- it's fairly natural to use DV for peering, due to the filtering > capabilities. > > One feature that the community people find missing is the ability to find out > if two remote interfaces belong to the same router -- something you get for > free in link-state, but that you cannot determine at all in distance vector. I'm > half tempted to implement an extension that allows a router to announce its > set of attached interfaces (e.g. within a sub-TLV of the Hello TLV), unless > somebody has a better idea. Interesting idea... If you included an interface id of some sort in each origination of reachability information, then the router information advertisement could just contain a list of interface id's, and everything could be connected together. One problem is going to be when these should be filtered... If you aggregate routing information at some point, do you somehow summarize routers behind the aggregation point, or simply remove this information, or... ?? :-) Russ From nobody Wed Aug 12 15:21:14 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0CF1ACE8A for ; Wed, 12 Aug 2015 15:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 LNlPbnRGxQ2K for ; Wed, 12 Aug 2015 15:21:11 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (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 C51D81ACE89 for ; Wed, 12 Aug 2015 15:21:11 -0700 (PDT) Received: from 162-229-180-77.lightspeed.rlghnc.sbcglobal.net ([162.229.180.77]:59600 helo=RussPC) by server.riw.us with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1ZPeOT-00036h-Ma; Wed, 12 Aug 2015 22:21:10 +0000 From: "Russ White" To: "'Margaret Cullen'" References: <03c701d0d542$35c78390$a1568ab0$@riw.us> In-Reply-To: Date: Wed, 12 Aug 2015 18:21:06 -0400 Message-ID: <047801d0d54d$2f79e4a0$8e6dade0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLbZJjRp7J+qFFwsYH0mDjXxS/4qgF9T+nXm+fmaKA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: babel@ietf.org Subject: Re: [babel] Thoughts on Other Use Cases X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2015 22:21:13 -0000 > Interesting ideas, Russ. I particularly like the idea of using babel as a data > center underlay/overlay. I do, too, actually... We're using a lot of BGP in this space. Something simpler might get some attention, particularly if it knows how to play nice with overlay tunnels and programmability to manage policy. > I am working on a transitive trust system for use with the IETF's abfab (GSS- > EAP) security protocols. The system deploys a number of "Trust Routers" > that distribute information about "Trust Paths" to reach the AAA servers for > target realms across a AAA fabric. I have just started work on a dynamic > "routing protocol" for this system. I had been considering using a link-state > algorithm, but I'm currently assessing the possibility of using a DV protocol > based on babel, since it looks like it will be easier to implement and, perhaps > more importantly, easier to test. This is interesting... Do you have docs? :-) Russ From nobody Wed Aug 12 15:46:22 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE7E1B29CC for ; Wed, 12 Aug 2015 15:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 3WkdXFgXNPqL for ; Wed, 12 Aug 2015 15:46:20 -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 0358C1B29C3 for ; Wed, 12 Aug 2015 15:46:19 -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 t7CMkGrj032105; Thu, 13 Aug 2015 00:46:16 +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 3564861FA0; Thu, 13 Aug 2015 00:46:18 +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 Q6m0hqR-bQzv; Thu, 13 Aug 2015 00:46:13 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 2419861F9A; Thu, 13 Aug 2015 00:46:13 +0200 (CEST) Date: Thu, 13 Aug 2015 00:46:12 +0200 Message-ID: <874mk4nn0r.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Russ White" In-Reply-To: <047601d0d54d$09fe8e60$1dfbab20$@riw.us> References: <03c701d0d542$35c78390$a1568ab0$@riw.us> <87h9o4npqw.wl-jch@pps.univ-paris-diderot.fr> <047601d0d54d$09fe8e60$1dfbab20$@riw.us> 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, 13 Aug 2015 00:46:17 +0200 (CEST) X-Miltered: at korolev with ID 55CBCCB8.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 55CBCCB8.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 : 55CBCCB8.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] Thoughts on Other Use Cases X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2015 22:46:21 -0000 > All of these can be solved with some sort of community system, or > opaquetags. Yes. That's something that's been repeatedly requested. I'm not sure what format the labels should have, though -- arbitrary length binary blobs? Triples (registry, tag-type, value)? Obviously, this should be redistributable into other routing protocols, so its format matters. > IPv4 over IPv6 > IPv6 over IPv4 > IPv4/IPv6 over MPLS > IPv4/IPv6 over VxLAN > Ethernet over MPLS > Ethernet over VxLAN Ah, I see. RFC 6126 defines v4/v6 and v6/v4 operation, but the implementation only supports v4/v6. I know very little about MPLS, and nothing about VxLAN. > The idea here is just to have some sort of TLV that allows any address > family as a destination, and then any address family as the "next hop" for > this given destination. Yes, Babel supports that. See Sections 4.1.3 and 4.4.8 of RFC 6126. > Interesting idea... If you included an interface id of some sort in each > origination of reachability information, then the router information > advertisement could just contain a list of interface id's, and everything > could be connected together. That was the design of Babel version 0 (current version is 2). I decided against it in the end, since as you justly note it prevents arbitrary filtering, which is something that people really want, and since it complicates the protocol somewhat. I replaced that with prefix compression (stolen from OLSRv2), which provides similar benefits without the limitations and cleanly packages the complexity in the TLV parser. The new extension is meant to be purely informational, and not used by the core protocol -- the mesh communities are big on monitoring GUIs. -- Juliusz From nobody Wed Aug 12 20:15:31 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF841B2F7E for ; Wed, 12 Aug 2015 20:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=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 Q8fhaejnMBN1 for ; Wed, 12 Aug 2015 20:15:26 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (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 6C2801B2F87 for ; Wed, 12 Aug 2015 20:15:24 -0700 (PDT) Received: by qgdd90 with SMTP id d90so23904775qgd.3 for ; Wed, 12 Aug 2015 20:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=43XDNqNOotdALwXIOriGMZ32bRVeTZrFd5wZ6bb6a7g=; b=sUs2YBWc+RGiNXfnBWhRo1RA/nUA8G6pyXvwphu+H5/4ZSVMjJ20ScR9I20HHTCUrq +uWsfVhXc5K94qe156jhriPpFOHpGpwuBvgVTy2ge7Haecz2DRHg9fSRV3BnESNnLO5n EzalqstNMmgRYsfyb6RcfK3Q23K7IB96hDCUonbBY73eR0O4ylUZuNxiuq8VKHnsYZdq 8tMy0xMZk1GAAOewjGXrCFMJTgh2sXsXsWtFs1/P/Xj+vkj9oQ30QnQWwZROcjcCPK8w v9VpKewwYDOwJdJ8mzST46f3LHec8DjjNucqCHW9XKqPX4D6Msf/wa9ua66MlL6lJJz6 rOJw== X-Received: by 10.140.217.138 with SMTP id n132mr1231995qhb.96.1439435723649; Wed, 12 Aug 2015 20:15:23 -0700 (PDT) Received: from [192.168.1.196] (cpe-74-75-108-92.maine.res.rr.com. [74.75.108.92]) by smtp.gmail.com with ESMTPSA id i52sm501841qgi.5.2015.08.12.20.15.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Aug 2015 20:15:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) From: Margaret Cullen In-Reply-To: <87fv3onpip.wl-jch@pps.univ-paris-diderot.fr> Date: Wed, 12 Aug 2015 23:13:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3F94FADB-22FC-4E6E-93B7-5D7CE0115E59@gmail.com> References: <03c701d0d542$35c78390$a1568ab0$@riw.us> <87fv3onpip.wl-jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1510) Archived-At: Cc: babel@ietf.org Subject: Re: [babel] Thoughts on Other Use Cases X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 13 Aug 2015 03:15:30 -0000 On Aug 12, 2015, at 5:52 PM, Juliusz Chroboczek = wrote: >> The system deploys a number of "Trust Routers" that distribute >> information about "Trust Paths" to reach the AAA servers for target >> realms across a AAA fabric. [...] I had been considering using >> a link-state algorithm, but I'm currently assessing the possibility = of >> using a DV protocol based on babel >=20 > Note that if you're doing flat routing (host routes only), Babel can = be > simplified a lot -- you don't need router-ids, just index everything = by > addresses (the route table, the source table, the pending requests = table, > the duplicate suppression table). You can also get rid of the = mechanism > in Section 3.5.5. Thanks, Juliusz. I had it in my queue to look at the spec and figure = out what parts of the babel protocol (and possibly the babel = implementation) would/would not be needed for flat routing. This advice = will speed up that effort. Margaret From nobody Wed Aug 12 21:40:02 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97951A0064 for ; Wed, 12 Aug 2015 21:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 3LzIRYfVuLm3 for ; Wed, 12 Aug 2015 21:39:59 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 F09B21A0029 for ; Wed, 12 Aug 2015 21:39:58 -0700 (PDT) Received: by wicne3 with SMTP id ne3so243297728wic.1 for ; Wed, 12 Aug 2015 21:39:57 -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 :cc:content-type; bh=AvAdE5UBSoaHKdx7B3RiwvrAT9zJrpL5pnCbYBWiiPE=; b=y2wodo/slrYjX4iciKgVDmbGBNoYMezMV5aWEOrK90ooxPYvuR3+IJZRXtFy3fLxM4 OcK2V56XQ7eT8IJjZ4RDfmPmhhrJPdQyAOqV43NQrngLQ87OLfVn00ZTPVBdXke0iid2 9e//NcR84/p3hfmlRrYfd2Ca5KTervtvXzdq5q9NWwXD/Evc5ZE93R17cP/R33BHR7ue gUneWjsHs2FcHocqH/GCxLveLu6e4lL6vNGkaXAD0ms4SWs5kAVzbSKrzrjwF10ZcEeQ /iE/9ApwUxzMS61iEJUuQdU3hWebzdJbeb1D59u00fUbXL/++r5TwqQk3PZydbNnSldT jHyw== X-Received: by 10.194.249.100 with SMTP id yt4mr79502035wjc.0.1439440797740; Wed, 12 Aug 2015 21:39:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.81.70 with HTTP; Wed, 12 Aug 2015 21:39:28 -0700 (PDT) In-Reply-To: <047601d0d54d$09fe8e60$1dfbab20$@riw.us> References: <03c701d0d542$35c78390$a1568ab0$@riw.us> <87h9o4npqw.wl-jch@pps.univ-paris-diderot.fr> <047601d0d54d$09fe8e60$1dfbab20$@riw.us> From: Henning Rogge Date: Thu, 13 Aug 2015 06:39:28 +0200 Message-ID: To: Russ White Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: babel@ietf.org, Juliusz Chroboczek Subject: Re: [babel] Thoughts on Other Use Cases X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 13 Aug 2015 04:40:00 -0000 On Thu, Aug 13, 2015 at 12:20 AM, Russ White wrote: >> > 4. MANET -- as an alternative to the existing OSPF and other work. >> >> (I think you meant OLSR.) > > OLSR and OSPF. Did you ever tried one of the OSPF Manet extensions? I have a few co-workers that had a lot of problems with them... Henning Rogge From nobody Thu Aug 13 04:30:51 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B748A1B38A4 for ; Thu, 13 Aug 2015 04:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.207 X-Spam-Level: X-Spam-Status: No, score=-0.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 MJfff1S1tUQV for ; Thu, 13 Aug 2015 04:30:49 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (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 50A641B38A1 for ; Thu, 13 Aug 2015 04:30:49 -0700 (PDT) Received: by qgeg42 with SMTP id g42so28822284qge.1 for ; Thu, 13 Aug 2015 04:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VSMoJZHyHH4wN6obAM+JqBFGl3YEoBPNjCTmoyglUQE=; b=brezlR2g7qZIlKT3uAtvzR6gFoWwBvxqLIWSLUfLT+4swt5qPVcGPIHYXJp9EEiCSJ 9WhkZwDTKedIxpyhCWzMwi6xGYEd0cLELwXyPPPVI0dIFNxwJqlFxa6FAL2+CJ5KF16P YR6kX6ClWFXBkVHqt78W3U99XiJK3TUGdxzVxxHM3m3smsyO86Ux+3mrg82gOVpxQOyt GUS44G7GcPtHCzbk+i+rpIxOKVF9oh4lDNvjjpK9W7DCqinocmdVCaHBiiF1vg/FaOfg Za1t6J4ebF5acSHvCo7zjbHurhLscq7klPlcIhDuRTan0EP7wkfxyyjmHXe5tql4doR2 KRlA== X-Received: by 10.140.218.133 with SMTP id o127mr68615473qhb.67.1439465448562; Thu, 13 Aug 2015 04:30:48 -0700 (PDT) Received: from [192.168.1.196] (cpe-74-75-108-92.maine.res.rr.com. [74.75.108.92]) by smtp.gmail.com with ESMTPSA id h49sm951761qgd.24.2015.08.13.04.30.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Aug 2015 04:30:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) From: Margaret Cullen In-Reply-To: <047801d0d54d$2f79e4a0$8e6dade0$@riw.us> Date: Thu, 13 Aug 2015 00:48:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03c701d0d542$35c78390$a1568ab0$@riw.us> <047801d0d54d$2f79e4a0$8e6dade0$@riw.us> To: "Russ White" X-Mailer: Apple Mail (2.1510) Archived-At: Cc: babel@ietf.org Subject: Re: [babel] Thoughts on Other Use Cases X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.15 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, 13 Aug 2015 11:30:50 -0000 On Aug 12, 2015, at 6:21 PM, "Russ White" wrote: >> I am working on a transitive trust system for use with the IETF's = abfab > (GSS- >> EAP) security protocols. The system deploys a number of "Trust = Routers" >> that distribute information about "Trust Paths" to reach the AAA = servers > for >> target realms across a AAA fabric. I have just started work on a = dynamic >> "routing protocol" for this system. I had been considering using a > link-state >> algorithm, but I'm currently assessing the possibility of using a DV > protocol >> based on babel, since it looks like it will be easier to implement = and, > perhaps >> more importantly, easier to test. >=20 > This is interesting... Do you have docs? There were some old (expired) drafts on this subject named: draft-mrw-abfab-multihop-fed-02, and draft-mrw-abfab-trust-router-02. However, things have moved along a bit since then. The latest docs and = code are being developed as part of the Moonshot open source project = found here: =20 https:/wiki.moonshot.ja.net/ We tried to bring the Trust Identity Protocol (the transitive trust = protocol) and the Trust Router Protocol (the routing protocol that is = used to choose a path of transitive trust across a federation) to the = IETF a couple of years ago, but at that time we were only piloting the = technology in the UK and there wasn't much interested from anyone but = European universities and associated entities. Stephen Farrell didn't = want to charter the work without interest from the commercial sector, so = we have been working on this outside of the IETF since then. The work has matured significantly since the drafts were last updated. = We have an operational Moonshot federation among universities in the UK = (using a single Trust Router), and we are piloting a European-wide = federation with multiple Trust Routers over the next year. Once we have = a multi-Trust Router federation operational, we may come back to the = IETF to see if there is greater interest in standardizing this work. If you might be interested in following this work, let me know, and I = will find out how you can joint he associated mailing lists. Margaret From nobody Thu Aug 13 14:37:55 2015 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9377F1B3B44 for ; Thu, 13 Aug 2015 14:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 WCj1RqU0iX9i for