From nobody Tue Mar 1 01:37:26 2016 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 97B021B36C8 for ; Tue, 1 Mar 2016 01:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, 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 xp6zhhQ_R1Pm for ; Tue, 1 Mar 2016 01:37:24 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D4331B36C6 for ; Tue, 1 Mar 2016 01:37:24 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id p65so24907078wmp.0 for ; Tue, 01 Mar 2016 01:37:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pTdKKGxRY8JxYy6KGmT3KN9nKvdcHmHufRbtL1a82Ag=; b=NAZtpQGRhOyma5wbXNhKSIkX/epJ7/iOCbF1JMm4zoIFoJaXR2984E7vFYyej828dL JDEqHVEPlZEfFfYTo6NhIPlLOzZdCw+4Vd1z5cYfa8WSiTYk1BOgUbTF13YkV6IaKB/g +9niaAqqyV32oc/h+Hr1FDRS8cB3AjN4BaySNOTA+lIlPWeFdhG8maHzUTxl5fOydy8U Vx/HFTn+gokDWsSO4qyxx6aGeH+I7RN5xUMEhMQCmhOZGxPwXJeS7ZYWmKoy31YL/G16 6rYwazTkbg7Gfc+2mQDaDhTaOXGfmYScWykPwnl9zeYcqP965vGUgZ5SZ73j01LdUxYJ bRzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pTdKKGxRY8JxYy6KGmT3KN9nKvdcHmHufRbtL1a82Ag=; b=RQ/fLo/KS3Ad026bnR6hMAJ7S8QXjDzmv6IfvRjDt1y1wsRCsL9c8yOPw1T8ith1Jk zweWcZxCSor8GxKteu9ULo44nJo00e+WcsmFtRMHocCBiK+hyfol8hXFQHv3z8E2XMh7 1r2Wt+tMXeC7mFUQUNx1fhKzyJ1ypobQwDoyq2NLYDAmNuh8Y57jjLtEv7owfSl9W8sR XLZCuRsdyLVYGG1R98J2HumgxCS5ve81XWhAhtHsIuaKoNTKK4IJ8hah3EV+9yIrou+k rzZHAdrvcARhHGfAcOi0rw9e25w+hEVswMhlOm8zunvZuXAMnK/SCPqFZ4uPzYULNzCp lCkw== X-Gm-Message-State: AD7BkJK6kvATkPUVtUfv76bkpn1Wd8XZ9z0r10HGQ4wzLRpds3fulG4oEugzttiuBomlXqW6iNg9VzTWgTJzSzpy X-Received: by 10.195.12.113 with SMTP id ep17mr18753289wjd.102.1456825042700; Tue, 01 Mar 2016 01:37:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.230.20 with HTTP; Tue, 1 Mar 2016 01:36:42 -0800 (PST) In-Reply-To: References: From: Gabriel Kerneis Date: Tue, 1 Mar 2016 10:36:42 +0100 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=047d7bb04c422be690052cf983ab Archived-At: Cc: babel@ietf.org Subject: Re: [babel] Babel BoF approved 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, 01 Mar 2016 09:37:25 -0000 --047d7bb04c422be690052cf983ab Content-Type: text/plain; charset=UTF-8 Hi Alia, Thanks a lot for your advice. > One open question about which I continue to have skepticism and doubt is > whether anyone except Juliusz is intending to write or edit any drafts. > I cannot think of a draft that would need to be written from scratch right now. But in my mind, reviewing includes suggesting and drafting (potentially significant) modifications to existing drafts or RFCs, to produce standards track documents, and I definitely intend to do that. Is that you meant by "editing"? Best, Gabriel --047d7bb04c422be690052cf983ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi A= lia,

T= hanks a lot for your advice.

One open question about which I continue to= have skepticism and doubt is whether anyone except Juliusz is intending to= write or edit any drafts.

I cannot think of a draft t= hat would need to be written from scratch right now. But in my mind, review= ing includes suggesting and drafting (potentially significant) modification= s to existing drafts or RFCs, to produce standards track documents, and I d= efinitely intend to do that. Is that you meant by "editing"?

Best,
Gabriel=C2=A0

--047d7bb04c422be690052cf983ab-- From nobody Tue Mar 1 04:32:59 2016 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 68DA31B2B3B for ; Tue, 1 Mar 2016 04:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 cxxr72YLaj7t for ; Tue, 1 Mar 2016 04:32:57 -0800 (PST) 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 D0DD41B2B37 for ; Tue, 1 Mar 2016 04:32:56 -0800 (PST) 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 u21CWsv1027398; Tue, 1 Mar 2016 13:32:54 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9E17061FA6; Tue, 1 Mar 2016 13:32:54 +0100 (CET) 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 d0xZ7FiFI5-z; Tue, 1 Mar 2016 13:32:49 +0100 (CET) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B530F61FA1; Tue, 1 Mar 2016 13:32:48 +0100 (CET) Date: Tue, 01 Mar 2016 13:32:51 +0100 Message-ID: <87a8mijs3w.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Gabriel Kerneis In-Reply-To: References: <7i7fi6hvq3.wl-jch@pps.univ-paris-diderot.fr> <7iy4a3fksy.wl-jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 01 Mar 2016 13:32:54 +0100 (CET) X-Miltered: at korolev with ID 56D58BF6.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 56D58BF6.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 56D58BF6.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: babel@ietf.org Subject: Re: [babel] Applicability statement for Babel 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, 01 Mar 2016 12:32:58 -0000 > A couple nits: Thanks, noted. From nobody Tue Mar 8 08:57:23 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AA912D83B for ; Tue, 8 Mar 2016 08:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IM_hAl7W6TS for ; Tue, 8 Mar 2016 08:57:20 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68B712D849 for ; Tue, 8 Mar 2016 08:57:20 -0800 (PST) Received: by mail-ob0-x22c.google.com with SMTP id fz5so19904444obc.0 for ; Tue, 08 Mar 2016 08:57:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=7IxxlqU/Kt9tQq/QtvaK4ND9tuzy72W9DKUk8+ERfcA=; b=XFNT8Vs7GIMFjo6B/JkokIK4bRAsigAqDDbtDqEHPE49n6hx8ID1TT0QM47jJRCkQa B93i/8aVKQUnCbL3QAWyicOHkeilW3dr+4RQJzt21jCWb8Pp6NRVI6csv3yUPwLL5J7P G2z6iEKqVtkKYw7qTiKqE/7NRSIvqwKEX/8/p9oTzmbnrFcliXTYa5r2rDzF8YdY+xAZ 4lAynS0lygVJHUBsy4fi9OssE/Zr66+m3D5PmL9AEaDGo3SWByYJxzGCejWHOfYLqMBO MAIlKB6/CIR5CxceechCg796Q/4bTJjKyZ5uci1MxPJqSF6Emmriv+0y/rbyI8lVx4ys cVSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=7IxxlqU/Kt9tQq/QtvaK4ND9tuzy72W9DKUk8+ERfcA=; b=KXqURLEqfR6mtiNTV4swA+XHj+FYH1WQVgmiEh5kxqzk0X4s1dYjd/iM76hxsd/Mou 6eMEUeEqrSjz6FKC967yMxybNBcMElJ4AjyXuBOIB/ExI2sYmE8PfE9Txc0fateJkVtG /EPnddYYxN6JzEk0yT3EIPykBdVx5f2jzyGDHJ3Eae6XBZHqMQSyfc4jiv+zxaAe2m4u nHkjojc+dP3+ebrUkzP5r782FBrdTHrBBeEa4v5UiaATRE2ObAmzkPP7mfF1JqC0QZ5X VtGp1ZHy5WTKItbS2IdCVAVIAwfzbIGvDtCMUwYGio+gyYpb+snNZdlwraYKLp29xucw D08A== X-Gm-Message-State: AD7BkJI+Lp43fXLr9Z3fQyTkMQTRK2sK/p3NaA2kmrYJsy4TSS4/OUy1gH+Hh7Kccg4J2xOXih/KMtgIWG4r2Q== MIME-Version: 1.0 X-Received: by 10.182.241.2 with SMTP id we2mr19501691obc.20.1457456240250; Tue, 08 Mar 2016 08:57:20 -0800 (PST) Received: by 10.60.54.162 with HTTP; Tue, 8 Mar 2016 08:57:20 -0800 (PST) Date: Tue, 8 Mar 2016 11:57:20 -0500 Message-ID: From: Alia Atlas To: babel@ietf.org Content-Type: multipart/alternative; boundary=001a11c2ec2079d96e052d8c7983 Archived-At: Cc: "Joel M. Halpern" , Tony Przygienda Subject: [babel] BoF Chairs update X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 16:57:22 -0000 --001a11c2ec2079d96e052d8c7983 Content-Type: text/plain; charset=UTF-8 I have asked Tony Przygienda and Joel Halpern to serve as BoF chairs. Please work with them on planning an agenda, making suggestions for what should and shouldn't be in the proposed charter, and so on. The BoF is tentatively scheduled for Monday April 4 from 15:50 - 17:20 (GMT-3) Regards, Alia --001a11c2ec2079d96e052d8c7983 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have asked Tony Przygienda and Joel Halpern to serve as = BoF chairs.
Please work with them on planning an agenda, making suggest= ions for
what should and shouldn't be in the proposed charter= , and so on.

The BoF is tentatively scheduled for = Monday April 4 from 15:50 - 17:20 (GMT-3)

Regards,=
Alia
--001a11c2ec2079d96e052d8c7983-- From nobody Fri Mar 11 12:35:46 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A1E12DB7E for ; Fri, 11 Mar 2016 12:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wkt-N1R379Vd for ; Fri, 11 Mar 2016 12:35:42 -0800 (PST) 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 B08FD12DB77 for ; Fri, 11 Mar 2016 12:35:30 -0800 (PST) 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 u2BKZRBS005161; Fri, 11 Mar 2016 21:35:27 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C5DD761FA3; Fri, 11 Mar 2016 21:35:27 +0100 (CET) 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 ef25TmeNona5; Fri, 11 Mar 2016 21:35:26 +0100 (CET) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 462FC61FA2; Fri, 11 Mar 2016 21:35:24 +0100 (CET) Date: Fri, 11 Mar 2016 21:35:24 +0100 Message-ID: <87oaakbvn7.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Alia Atlas In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 11 Mar 2016 21:35:28 +0100 (CET) X-Miltered: at korolev with ID 56E32C0F.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 56E32C0F.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 : 56E32C0F.003 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: "Joel M. Halpern" , babel@ietf.org, Tony Przygienda Subject: Re: [babel] BoF Chairs update X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 20:35:44 -0000 > I have asked Tony Przygienda and Joel Halpern to serve as BoF chairs. Wow, we couldn't possibly hope for better people. Thanks to Tony and Joel for accepting, and to you, Alia, for making this happen. > The BoF is tentatively scheduled for Monday April 4 from 15:50 - 17:20 (GMT-3) Ouch. Jet lag threatens, time to hit the gym ;-) -- Juliusz From nobody Fri Mar 11 12:39:58 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA36E12DB6C for ; Fri, 11 Mar 2016 12:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3-Y98T2d3Im for ; Fri, 11 Mar 2016 12:39:53 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 6103A12DB24 for ; Fri, 11 Mar 2016 12:39:40 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id z76so160037222iof.3 for ; Fri, 11 Mar 2016 12:39:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=eB2jQd0n0RBddT8r9xrQCA/WbOybBurv/lMfbj0uRuU=; b=MMqmaXZtGXMFHhRMsZcLR42DhPJ+WSet9QK2uXnTx/HesQgz9z4i2UJ/oKi8mGVJKo ItXXxNdWQFJgUbL8vDm9BpPou8qWZx9DbuxY7KUFMfVVKhmspuMEd3XBYL4y9YEuVLcP OUlulpf+SAgbqgl1W2E6hZXuDHsz48KxnHcToKbJKefUymM3oDxZWqAibR1VETtY58wI QrkWkBx+S3WcsAynIIJM4YW5N0MzxiQn9PTb6x5tx69f/sz9MlHNq8gXrjCkgiQc6HZ5 a0ATeUdnQenlRrQ4r+4abimwsjY9tRbqx0ZHmaiXtF1dxYe6904HzWdG8FkBwjTamlAZ 6ANw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=eB2jQd0n0RBddT8r9xrQCA/WbOybBurv/lMfbj0uRuU=; b=LkgqRnJvW8EZkKlMagbMerDZ3cTDvtiElGcPD3LhRZz3QKxDT6T5RflXrZh9hcJPE+ xU2wLOQExVd+S+y1afjWGLA4E2llZtb2F8KP/Aj7qatNdKZ0WOA1Mb7e02E3mVSbK1hu IpewoHK0A9zieT3tKHIuKS86eP8+CJN1iv9ab5czKTZT2Q5u/MC1RhpO7ec3CVuiaiVw N9NDVtD3wUB+DjdXejIRhiXyRnKnpvUnvfYZfXwvnAVy6p8g9cip2I+KC6SUjOZORhnM 2Nl2MV60zOvBHUBiT7zb8VqNHGexuNUkAZEtHNCHXiKzOxQqzDLB1vh7gG7as8OTWDW9 WKwA== X-Gm-Message-State: AD7BkJKPHPZbQHdkrxsTqaIYopSiS/vhmdWd1m7yMEzoKZe1L8LrJCs0A8v8tW2LzwuYs8ToMtbTOa3QAr2ANw== MIME-Version: 1.0 X-Received: by 10.107.165.78 with SMTP id o75mr14513190ioe.56.1457728779740; Fri, 11 Mar 2016 12:39:39 -0800 (PST) Received: by 10.107.6.41 with HTTP; Fri, 11 Mar 2016 12:39:39 -0800 (PST) In-Reply-To: <87oaakbvn7.wl-jch@pps.univ-paris-diderot.fr> References: <87oaakbvn7.wl-jch@pps.univ-paris-diderot.fr> Date: Fri, 11 Mar 2016 12:39:39 -0800 Message-ID: From: Tony Przygienda To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=001a1141f262186ede052dcbeeeb Archived-At: Cc: "Joel M. Halpern" , babel@ietf.org, Alia Atlas Subject: Re: [babel] BoF Chairs update X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 20:39:56 -0000 --001a1141f262186ede052dcbeeeb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well, it ain't happening often a new routing protocol spec intended for possibly massive deployment is hatched ;-) Will be a pleasure and looking fwd' to that ... -- tony On Fri, Mar 11, 2016 at 12:35 PM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > > I have asked Tony Przygienda and Joel Halpern to serve as BoF chairs. > > Wow, we couldn't possibly hope for better people. Thanks to Tony and Joe= l > for accepting, and to you, Alia, for making this happen. > > > The BoF is tentatively scheduled for Monday April 4 from 15:50 - 17:20 > (GMT-3) > > Ouch. Jet lag threatens, time to hit the gym ;-) > > -- Juliusz > --=20 *We=E2=80=99ve heard that a million monkeys at a million keyboards could pr= oduce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.* =E2=80=94Robert Wilensky --001a1141f262186ede052dcbeeeb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, it ain't happening often a new routing protocol = spec intended for possibly massive deployment is hatched ;-)=C2=A0

=
Will be a pleasure and looking fwd' to that ...=C2=A0

-- tony=C2=A0
=
On Fri, Mar 11, 2016 at 12:35 PM, Juliusz Ch= roboczek <jch@pps.univ-paris-diderot.fr> wrote:<= br>
> I have asked Tony P= rzygienda and Joel Halpern to serve as BoF chairs.

Wow, we couldn't possibly hope for better people.=C2=A0 Thanks t= o Tony and Joel
for accepting, and to you, Alia, for making this happen.

> The BoF is tentatively scheduled for Monday April 4 from 15:50 - 17:20= (GMT-3)

Ouch.=C2=A0 Jet lag threatens, time to hit the gym ;-)

-- Juliusz



--
We=E2=80=99ve hea= rd that a million monkeys at a million keyboards could produce the complete= works of Shakespeare; now, thanks to the Internet, we know that is not tru= e.
=
=E2=80=94Robert Wilensky
--001a1141f262186ede052dcbeeeb-- From nobody Mon Mar 21 02:25:14 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660F412D719 for ; Mon, 21 Mar 2016 02:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMbhSWgMnxiz for ; Mon, 21 Mar 2016 02:25:10 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B995112D718 for ; Mon, 21 Mar 2016 02:25:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 93A35241023; Mon, 21 Mar 2016 02:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1458552310; bh=BFP2sDicmD+Fzz208jX79VTZz2paTGHUSW3pSzBq3IQ=; h=To:From:Subject:Date:From; b=F94tpQkEHwATSmTkRgdcgtKhuSPF0+JjDA52zHhCTlznm9e4MFYLPcQwwf8KZCUt+ frujdm0sqiYpx2BRDXg8MFA99ugoGMr5eecoqUIqouAkO3O4mWMFafvGDnyOj8Grmq fpVd6M+9VHVt7Lsnn+HEMIOzhVUOgNSSpflr8sGE= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.126.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id D98E6240036; Mon, 21 Mar 2016 02:25:09 -0700 (PDT) To: Alia Atlas , Babel at IETF From: "Joel M. Halpern" Message-ID: <56EFBDF3.20700@joelhalpern.com> Date: Mon, 21 Mar 2016 05:25:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [babel] Charter Proposal X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 09:25:12 -0000 After some discussion, the following is an initial cut at a charter proposal, for discussion on the list now, and as part of the Babel BoF in Buenos Aires. Yours, Joel Name: BABEL Chairs: TBD Area: Routing Babel is a loop-avoiding distance vector protocol that has good provisions for dynamically computed metrics and remains robust even in the presence of metric oscillations and failure of transitivity. Babel has seen some production deployment, notably in hybrid networks (networks that combine classical, wired parts with meshy bits) and in global overlay networks (networks built out of large numbers of tunnels spanning continents). There exist three independent implementations of Babel, all of which are open source. The core of the Babel protocol is described in detail in RFCs 6126 and 7557, with RFC 7298 describing the security extensions, all of which are Experimental Independent Stream RFCs. While these RFCs have been useful (as indicated by the independent reimplementations of Babel), a number of parties have expressed a desire to have a new specification, which would clarify RFC 6126 according to the feedback provided by the independent reimplementations and integrate the contents of RFC 7557. The working group is will focus on what is needed to move the Babel protocol to IETF Proposed Standard with IETF review. Other documents which are relevant to such consideration can also be produced. Particular emphasis will be placed on work needed to meet the needs for Proposed Standards, such as ensuring manageability and strong security. Work Items: - Produce a revision of RFC 6126 suitable for publication as a Proposed Standard, and work with the IESG for approval of same -- incorporate in the revision developments since RFC 6126 -- resolve technical issues found by recent reviews and the working group discussions -- include in the base specification the extensibility work in rfc 7557 -- consider any important changes based on experience with Babel to date. This may include discussion of issues such as the size of the default metric. - Address security needs for BABEL. This may include using the techniques in RF 7298, or other alternatives. This may be by inclusion in the base spec or by normative reference to a separate proposed standard specification. This is required as part of moving Babel to Proposed Standard. - Produce an applicability statement for publication as an informational RFC. This is highly desirable in conjunction with moving Babel to Proposed Standard. - Address manageability of Babel, most likely by producing a YANG model for Babel consistent with other YANG models produced in the routing area. This is required as part of moving Babel to Proposed Standard. - The working group may choose to publish an informational RFC on implementation experience with Babel, so as to enable future readers to better understand the state that drives this work and the experience driving changes. - The working group may choose to work on multicast aspects of Babel once the initial focus on Proposed Standard is met. - Coordinate with other working groups as need. Thus, the working group will produce a proposed standard Babel specification, either including or paired with a suitable security specification for BABEL. It will also produce a management model for BABEL as a proposed standard RFC. An applicability statement, and possibly an experience document will be produced as informational RFC(s). From nobody Mon Mar 21 06:26:58 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA90312D828 for ; Mon, 21 Mar 2016 06:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AACQXwBlV4NM for ; Mon, 21 Mar 2016 06:26:55 -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 7D42812D822 for ; Mon, 21 Mar 2016 06:26:55 -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 u2LDQrkY011347 for ; Mon, 21 Mar 2016 14:26:53 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 7ED7661F9D for ; Mon, 21 Mar 2016 14:26:53 +0100 (CET) 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 Em5NPEOpo1Ye for ; Mon, 21 Mar 2016 14:26:51 +0100 (CET) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3949161FA1 for ; Mon, 21 Mar 2016 14:26:48 +0100 (CET) Date: Mon, 21 Mar 2016 14:26:49 +0100 Message-ID: <8737rkgdwm.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]); Mon, 21 Mar 2016 14:26:53 +0100 (CET) X-Miltered: at korolev with ID 56EFF69D.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 56EFF69D.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 : 56EFF69D.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Some Babel resources X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 13:26:58 -0000 Hi, In case you want to do some homework before the meeting, there are some resources available in addition to the RFCs quoted in the proposed charter (6126, 7557, 7298): * a 50 minute long technical introduction to Babel: slides: http://www.pps.univ-paris-diderot.fr/~jch/software/babel/babel-20150804.pdf talk: https://www.youtube.com/watch?v=1zMDLVln3XM * proposed applicability statement: https://tools.ietf.org/html/draft-chroboczek-babel-applicability-01 * currently deployed extensions: source-specific routing: https://tools.ietf.org/html/draft-boutier-babel-source-specific-01 http://arxiv.org/pdf/1403.0445v4.pdf RTT-based routing: https://tools.ietf.org/html/draft-jonglez-babel-rtt-extension-01 http://arxiv.org/pdf/1403.3488v1.pdf diversity routing: https://tools.ietf.org/html/draft-chroboczek-babel-diversity-routing-01 There is also a proof of the loop-freedom properties, but it's not human-readable yet (the proof is complete, but the prose around it is missing). Let me know if you want a copy. -- Juliusz From nobody Mon Mar 21 11:42:37 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82ED12DA43 for ; Mon, 21 Mar 2016 11:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQ87TalB3-0f for ; Mon, 21 Mar 2016 11:42:31 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD75C12DA3C for ; Mon, 21 Mar 2016 11:42:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 90262250A10; Mon, 21 Mar 2016 11:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1458585747; bh=0ayQ1sq/U+BfnyGlyEqc1ZrujZ+Gbatp+zc2TUlGnXk=; h=To:Cc:From:Subject:Date:From; b=GuS+AaLwg/guO6+vIVTGHWb4nD0Bxf4hvN33kfFEev31sBJwiB3edh18NsSrwtHNf OztxWEnVmSH7DGpgTt/rmkFs1QmsnARGm8RMONa6MNnAS1s2LCM6ToNLWozlzGP+2S SHsmCapq0iF+PwAtQxMUrUgXZetQAb2P4DqLlVTo= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [88.131.67.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 7EEC824EB6E; Mon, 21 Mar 2016 11:42:26 -0700 (PDT) To: Babel at IETF From: "Joel M. Halpern" Message-ID: <56F04090.6070807@joelhalpern.com> Date: Mon, 21 Mar 2016 14:42:24 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Tony Przygienda Subject: [babel] Draft Agenda X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 18:42:37 -0000 Here is the agenda as Tony and I have worked it so far, and I have just posted. Let us know if there is something missing, or you think that a time slot needs adjustment, or ... Introduction: Tony Przygienda, 5 minutes Summary of charter, for context: Joel Halpern, 5 minutes (Note: discussion of charter is later.) Applicability statement: Juliusz Chroboczek 10 minutes http://tools.ietf.org/html/draft-chroboczek-babel-applicability Required changes to Babel documents: Juliusz Chromoczek 10 minutes This is to focus on things we know need review, based on RFC 6126 and RFC 7557. Overview of some technical items: Tony Przygienda 10 minutes This is to highlight some issues that may or may not need to be addressed, but which were noted in several recent reviews. The purpose of this presentation is to give an idea of the kinds of technical work the WG is likely to need to do. Implementation issues: Toke Høiland-Jørgensen 10 minutes Security considerations: Denis Ovsienko 10 minutes This will review RFC 7298 Discussion of draft charter and interest in forming a working group: 20 minutes, led by Chairs Yours, Joel (& Tony) From nobody Mon Mar 21 13:50:35 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D4912D90A for ; Mon, 21 Mar 2016 13:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tDcM9gkOBft for ; Mon, 21 Mar 2016 13:50:32 -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 0070D12DB24 for ; Mon, 21 Mar 2016 13:50:30 -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 u2LKoSk6022346; Mon, 21 Mar 2016 21:50:28 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C8D4461FA5; Mon, 21 Mar 2016 21:50:28 +0100 (CET) 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 d_Sgs1yrzA2w; Mon, 21 Mar 2016 21:50:26 +0100 (CET) Received: from [10.101.3.29] (unknown [62.119.166.9]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A964D61FAB; Mon, 21 Mar 2016 21:50:25 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Matthieu Boutier In-Reply-To: <56EFBDF3.20700@joelhalpern.com> Date: Mon, 21 Mar 2016 21:50:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56EFBDF3.20700@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3112) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 21 Mar 2016 21:50:29 +0100 (CET) X-Miltered: at korolev with ID 56F05E94.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 56F05E94.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 : 56F05E94.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: Babel at IETF , Alia Atlas Subject: Re: [babel] Charter Proposal X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 20:50:34 -0000 Some minor typos: > The working group is will focus on [=E2=80=A6] (is will) > rfc 7557 RFC (to upper case) > techniques in RF 7298, or other alternatives. This may be by RFC Matthieu From nobody Mon Mar 21 16:19:23 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0740412D0EC for ; Mon, 21 Mar 2016 16:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fm9yrNCUGYc6 for ; Mon, 21 Mar 2016 16:19:20 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 41DF712D132 for ; Mon, 21 Mar 2016 16:19:20 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id p65so141069368wmp.0 for ; Mon, 21 Mar 2016 16:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c5L0wKZ1jo8Yd+Gt/c4pVrFqQEckFZSL6SVV5u1vTAk=; b=eb9LiQ1B8qH+XUSwBE7TqmaiBM33s8Syoov07jE7AyudU8cCoATC1o9el1l6hqh9/c zCptXB6o4nk6UgZ44ZFHaLV8VORlXyS8nCdwRJXiRunD1H3WEbDTDIDaSbv4N0ykxX5f mwAPV2zajYKXlQsQkKSHU5jhetc3nFnYUx1bZdpqUEbnGz2TXaX4rnQYvgN92eA1FQwG zwKwpwvf3309W/uF0YHv4ocME/gpCdgtA31fZmzjmJhc3rRBs7oRqvm8cLr5FoLnlNsE AzPmIaQy/7gqZVe5JAQWH6G8W3f0mU8/zDNy8fEq/Wi36sq8caPozxCqHJJPKXCQgT55 ivEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c5L0wKZ1jo8Yd+Gt/c4pVrFqQEckFZSL6SVV5u1vTAk=; b=gddmdJ00Hx8NRtUaprwo2yjiobf9itYfNWJ5pTccFH6M+puDVVx32yA63vFt4Y1ypG FaZ8ecopIa45TcEUEIRMsQCEopi1NjRmEivsr1dw4hD0sb0CmvC1a5ddygOdRpa73yWC TNIJJz9lSywUm8CSHSItOwuviUIfsOrJqHcrBsDZedEEOsnvAtsWqynDEd47Iwm+fFiW B5m4nvvbwpWY6EhD8b7rOkU8JMCPl6iE4CC5OaS3IBzMBJIL/6vNkDMquz/zk/Tc0uet t/ar+5dSD9CKFhDRUKGmajQOeVwy4BetGDWIjiPgXYUKkPr85FBf1wtYAhPREktctSnA bxyg== X-Gm-Message-State: AD7BkJJFiEVk2L4sVcTOv1h9ki59Waj4v2OwnYlbJ42rkK9Lb6WHm+gSjwJCp//am27niPPOIrfa2MgcZIEX5KC4 X-Received: by 10.28.0.148 with SMTP id 142mr15709109wma.72.1458602358715; Mon, 21 Mar 2016 16:19:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.230.4 with HTTP; Mon, 21 Mar 2016 16:18:39 -0700 (PDT) In-Reply-To: <56EFBDF3.20700@joelhalpern.com> References: <56EFBDF3.20700@joelhalpern.com> From: Gabriel Kerneis Date: Tue, 22 Mar 2016 00:18:39 +0100 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a113c96c4762292052e975382 Archived-At: Cc: Babel at IETF , Alia Atlas Subject: Re: [babel] Charter Proposal X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 23:19:22 -0000 --001a113c96c4762292052e975382 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 21, 2016 at 10:25 AM, Joel M. Halpern wrote: > > - Address manageability of Babel, most likely by producing a YANG > model for Babel consistent with other YANG models produced in the > routing area. This is required as part of moving Babel to Proposed > Standard. > Is this a requirement specific to the routing area? Could you provide a couple pointers please? For instance, looking only at the list at https://en.wikipedia.org/wiki/YANG#Usage_in_Standards, I cannot find concrete examples of other routing protocols using this. (I am sure there are, just not easy to find hundreds of pages of RFCs.) Thanks, Gabriel --001a113c96c4762292052e975382 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 21, 2016 at 10:25 AM, Joel M. Halpern <jmh@joelhalpern.com&g= t; wrote:
=C2=A0- Address manageability of Babel, most likely by producing a YANG
=C2=A0 =C2=A0model for Babel consistent with other YANG models produced in = the
=C2=A0 =C2=A0routing area.=C2=A0 This is required as part of moving Babel t= o Proposed
=C2=A0 =C2=A0Standard.

Is this a requir= ement specific to the routing area? Could you provide a couple pointers ple= ase? For instance, looking only at the list at=C2=A0https://en.wikipedia.org/wiki/YA= NG#Usage_in_Standards, I cannot find concrete examples of other routing= protocols using this. (I am sure there are, just not easy to find hundreds= of pages of RFCs.)

Thanks,
Gabriel
--001a113c96c4762292052e975382-- From nobody Mon Mar 21 16:28:00 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F87612D175 for ; Mon, 21 Mar 2016 16:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z98Kz4gXRqLi for ; Mon, 21 Mar 2016 16:27:56 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 747FE12D197 for ; Mon, 21 Mar 2016 16:27:56 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id w20so100400360oia.2 for ; Mon, 21 Mar 2016 16:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=s6jT9bXWURoLagkGHZyJn8/I2ty1Vt2SH6aYKk8ECkk=; b=z2KYsEwvHe2OEcw6STX9A0PgfOw5N4CQIBFujRlfpVvGv8uB0tm4UsP20r/qP7AqTW DFOF68kI0SEK6H1CpJP1Ilc1MhDoGEilNtXYqBu4c2RXEZNfPjUBIc61+dh/8ygG0ZKP m42+nuGURd+BgZzLc58x/0KUwMC8vXVZEtd+5DI92l9Qk+eGjx123B7ZBV7amcIRUHsH EpZNHe7jDiNID+mklglDxmJBv7ERY9ON0gmY6RowA6qIj/Tio50wxbhhWlydH3sTrzMd dN/VzbONvgazD7evWh7iwf80YnFGyDfJRn9Rp4dU5HlF9wWwI80lj3IGCfPBSGWWwbpq tQhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=s6jT9bXWURoLagkGHZyJn8/I2ty1Vt2SH6aYKk8ECkk=; b=TdXy80cAR5CwzeXlrMKb3WfY/mOWjFCTPVGCqdDbyNK9s+2wVW5unnLON2Wq17M4h7 8lkaA5olWKmZ4BjM88rSbLQ567IMcQ6XKukhrtZXWVMMzH1v11RCsvMdwEMad1V+eRBS O6pQTK8vUhipnAGYsKKNCY5byZWA4gU4akbkyy8pPy+QA/WULnNPWIH2pk1jPA6QhFNg JPA7F/wTLUUJ92427JEImSiIEOAsmiH/EfU56N2iCqmpFbHtVF0Qe+/t646yBzFt09uU U4+76cJgmNImudjRJB8t8fGGgAiCGcHwTUssu2MZnhbR9G4I+zoltrjf0bhC1lXIH2r7 McsA== X-Gm-Message-State: AD7BkJJP9PJFO5ZcFDWnoyOPwBn79l6OVoCEQpy6+OXxrgvMJeHBNp0isxOURc0PYSqS/skTY54YnTrAHERDtg== MIME-Version: 1.0 X-Received: by 10.202.171.149 with SMTP id u143mr10738409oie.29.1458602875860; Mon, 21 Mar 2016 16:27:55 -0700 (PDT) Received: by 10.60.137.228 with HTTP; Mon, 21 Mar 2016 16:27:55 -0700 (PDT) In-Reply-To: References: <56EFBDF3.20700@joelhalpern.com> Date: Mon, 21 Mar 2016 19:27:55 -0400 Message-ID: From: Alia Atlas To: Gabriel Kerneis Content-Type: multipart/alternative; boundary=001a113c3f6848bef7052e977278 Archived-At: Cc: "Joel M. Halpern" , Babel at IETF Subject: Re: [babel] Charter Proposal X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 23:27:59 -0000 --001a113c3f6848bef7052e977278 Content-Type: text/plain; charset=UTF-8 Hi Gabriel, There is always a requirement for manageability and associated considerations. Traditionally, this has involved MIBs. In the last couple years, as part of the movement towards orchestration and model-driven software, YANG has taken off as a common modeling language that is used in combination with NetConf or RestConf for configuration and reading of operational state. Even in ecosystems where NetConf or RestConf aren't the preferred protocols to use, it is possible to translate YANG into a suitable encoding (though that isn't currently being standardized). There are currently YANG modules in progress for OSPF, ISIS, BGP, the RIB, MPLS, topology, security key-chains, VRRP, and many many others. Those are in various working groups in the Routing Area. You can find some by looking at https://datatracker.ietf.org/doc/search/?name=yang&sort=&rfcs=on&activedrafts=on . We also have a wiki (alas a bit outdated) at http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgYangCoord and a mailing list rtg-yang-coord@ietf.org. Do you have thoughts on what type of manageability would be needed for likely deployment scenarios for babel? Regards, Alia On Mon, Mar 21, 2016 at 7:18 PM, Gabriel Kerneis wrote: > On Mon, Mar 21, 2016 at 10:25 AM, Joel M. Halpern > wrote: >> >> - Address manageability of Babel, most likely by producing a YANG >> model for Babel consistent with other YANG models produced in the >> routing area. This is required as part of moving Babel to Proposed >> Standard. >> > > Is this a requirement specific to the routing area? Could you provide a > couple pointers please? For instance, looking only at the list at > https://en.wikipedia.org/wiki/YANG#Usage_in_Standards, I cannot find > concrete examples of other routing protocols using this. (I am sure there > are, just not easy to find hundreds of pages of RFCs.) > > Thanks, > Gabriel > --001a113c3f6848bef7052e977278 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Gabriel,

There is always a requireme= nt for manageability and associated considerations.=C2=A0 Traditionally, th= is has involved MIBs.
In the last couple years, as part of the mo= vement towards orchestration and model-driven software, YANG has taken off<= /div>
as a common modeling language that is used in combination with Ne= tConf or RestConf for configuration and reading of
operational st= ate.=C2=A0 Even in ecosystems where NetConf or RestConf aren't the pref= erred protocols to use, it is possible to
translate YANG into a s= uitable encoding (though that isn't currently being standardized).

There are currently YANG modules in progress for OSPF,= ISIS, BGP, =C2=A0the RIB, MPLS, topology, security key-chains, VRRP, and m= any many others.=C2=A0 Those are in various working groups in the Routing A= rea. =C2=A0 You can find some by looking at=C2=A0https://datatracker.ietf.org/doc/search/?name=3Dyang&sort= =3D&rfcs=3Don&activedrafts=3Don .=C2=A0 We also have a wiki (al= as a bit outdated) at=C2=A0http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgYan= gCoord =C2=A0and a mailing list rtg-yang-coord@ietf.org.

Do you have thoug= hts on what type of manageability would be needed for likely deployment sce= narios for babel?

Regards,
Alia

On Mon, Mar 21= , 2016 at 7:18 PM, Gabriel Kerneis <kerneis@google.com> wro= te:
On Mon, Mar 21, 2016 at = 10:25 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote: =C2=A0- Address manageability of Babel, most likely by producing a YANG
=C2=A0 =C2=A0model for Babel consistent with other YANG models produced in = the
=C2=A0 =C2=A0routing area.=C2=A0 This is required as part of moving Babel t= o Proposed
=C2=A0 =C2=A0Standard.

Is this a= requirement specific to the routing area? Could you provide a couple point= ers please? For instance, looking only at the list at=C2=A0https:/= /en.wikipedia.org/wiki/YANG#Usage_in_Standards, I cannot find concrete = examples of other routing protocols using this. (I am sure there are, just = not easy to find hundreds of pages of RFCs.)

Thank= s,
Gabriel

--001a113c3f6848bef7052e977278-- From nobody Fri Mar 25 00:54:30 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517A912D55E for ; Fri, 25 Mar 2016 00:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8ZTsUnKK278 for ; Fri, 25 Mar 2016 00:54:21 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A686012D193 for ; Fri, 25 Mar 2016 00:54:21 -0700 (PDT) Received: by mail-ig0-x234.google.com with SMTP id l20so8948942igf.0 for ; Fri, 25 Mar 2016 00:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=egxihsGkkhdeIhXl/0qG00xAsZD3guqQkSCtxvrf9r0=; b=rM2rKx0XBSBt1apIH1RrwDPsLQeIXB4xVfJszBaQ5ZpKGJ32YPTTMDMYWkDDkDDSvX OTy1jQvbu1Obeh4vnFmJWYjXi1b+Uq4iImBH59775gkUih60wcEYRFjazOkYG4J5Z0Wt gNhgRtcSfyOy345cMdQHLzazk/oGdyl+P6pGqHAF0jp6hmyztf+9WvcmmuyS26wUn0+g /Xo98BlxzMJrtHZ+YJ7qg8rfve9OOIQed6DYk7OyRN708IYmS1Y/Z4v2lPTxwPhs42Af n9fKdXOerVa1KO/sB89OB/n0WpO3LOVJl18NzumhHWHgq7dl2KuL3wlI08i9StBlc3lz hZzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=egxihsGkkhdeIhXl/0qG00xAsZD3guqQkSCtxvrf9r0=; b=jiRiaCt3gTk7ZmzgZ25TZiL6uKiGqlf8QdMJS53XqAbDVyUkBvmRX5SQYVWvjDcVtw gt4A8XMY/WHNXuEcbeHDYTKI2ljhaOWdcv1m06KLs7zLWiHBdUhVkIOpWQ3KW/kyOX8a W6pCi8BQwTfZGsJhQznY0kvEjM7iQ8UcODZyHGxcW1z2GcbVmzGsUDlxsa38BrObRJmz WPljfDDAj5aWvUYye4GXiGuDilNwhn0InxW2Oxn1uFc1WV+0XsfQuq7rjZ4Qw/aA/Srt yWbGH2b6SbmkynKVp+5qlqQX0rCDzvb4GJKLW41/lPcmOXwO5sJFP903cZzoHqiIyx/D yjqw== X-Gm-Message-State: AD7BkJJjN4hYdsGdP0RLgu2I9p44UgM8HjVoYRVO+kkx5bte6g3zh7FBTx2Iqm/CsEnJO976KM2MB6ipiVLXCg== MIME-Version: 1.0 X-Received: by 10.50.112.10 with SMTP id im10mr13130869igb.93.1458892460764; Fri, 25 Mar 2016 00:54:20 -0700 (PDT) Received: by 10.107.6.41 with HTTP; Fri, 25 Mar 2016 00:54:20 -0700 (PDT) Date: Fri, 25 Mar 2016 00:54:20 -0700 Message-ID: From: Tony Przygienda To: babel@ietf.org Content-Type: multipart/alternative; boundary=047d7b1637ade3d773052edadec3 Archived-At: Subject: [babel] In-depth look @ Babel towards PS ... X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 07:54:28 -0000 --047d7b1637ade3d773052edadec3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here's my take before BoF after fairly careful reading & thinking through Babel as documented/implemented today + some enlightening discussions with Juliusz. Comments/discussions/takes from the list before BoF would be very welcome. IMO Babel is sound in principle and worth pursuing for HomeNet world-wide deployment scenarios iif * some technical deficiencies are remedied and procedures defined more tightly * the solution is used on networks with relatively few devices (low 100s) and fairly small diameter (~5-10) without large routing tables (>few K addresses) or extensive aggregation. With suitable optimizations and possibly protocol extensions the protocol may bear significantly larger deployments as well. Desirable properties and trade-offs as far I see them: * significant implementation and standardization simplicity as compared to a link-state protocol * source-destination routing is almost trivial per draft-boutier-babel-source-specific and seems correct from my experience with further comments down. * better stability in lossy networks for the cost of slower convergence than link-state, probably a good trade-off given the likely wireless nature of home style networks [as a trade-off for the stability a certain =E2=80=9Cstickiness=E2=80=9D is obviously to be expected as compared to lin= k-state. This is a normal consequence of a diffused rather than distributed computation. The stickiness will get worse with diameter]. Now, what follows is the remaining work for the BoF (and/or possible WG) to talk through/attack as recommendations from my side in rough sketch form (I had very detailed discussions with Juliusz over email and some things we agreed on, some we differ, some we agreed need further pondering upon by people experienced in the art ;-) I omit many gritty details to keep the picture fairly tractable (while giving underneath 2 examples of discussions that ensued about why the spec as it stands today needs good amount of attention to be of PS quality IME): * first an optional but strongly suggested topic: detailed simulation of Babel within the envelope agreed upon by the developers/chairs/requirements set by HomeNet, i.e. mobility ratios, loss ratios, interference ratios to ensure correct convergence within practical time limits and intended scale * standardization of ideally a single one or max. 2-3 metrics (Juliusz likes "default metric") which at least one of I would recommend to be isotonic (but there seems to be experience/consensus that left distributivity [left isotonicity]) is not necessary for correct routing [vs. optimal]). Something like metric dependent on interface type is probably OK. The reasoning here is that the protocol must be stable, converge well out-the-box amongst different vendors without requiring tons of magic knobs or even if some routers had the "2-3 different metrics" knob twisted. Proliferation of "experimental appendices and metrics" are perfectly fine IMO as long they are understood as such, i.e. IETF-warranty-sticker is peeled off the moment someone starts to twist those in a network. I read http://arxiv.org/pdf/1403.3488v1.pdf and the issues are well researched and understood by authors. In case the simulations @ reasonable sizes under required envelope prove stability/desired properties of such a delay-metric under affine functions & hysteresis I see nothing wrong in discussing this as a standard metric. Yes, it's risky IMO but the traditional wisdom of last 20 years should be challenged with the world changing on us. Without that, no progress can be made. * standardization of default value for many constants e.g. for hysteresis, timeouts that is guaranteed to internetwork in targeted networks out-the-box (albeit doesn't have to be optimal). * BoF/WG needs to discuss the multicast issue. How far is that in charter ? Is another protocol needed ? Is Babel intended long-term to evolve into a M-IGP ? * BoF/WG should discuss/consider/answer the issue of auto-configuration of router IDs. Albeit not within the scope of Babel I consider its deployment success largely hinging off this issue. * Procedures in 3.5.1 and 3.5.4 need tightening up. I expect under simulations that the language will solidify in many more MUSTs than the spec offers today. I do not question the convergence of the protocol fundamentally (under an isotonic metric, otherwise it's one variable too many for my current knowledge ;-) but I had discussions with Juliusz on stable oscillations scenarios and will continue to have so. I give an example below. * From a practical standpoint, I suggest to make the spec strictly numbered (i.e. clauses can be easily talked about like ISIS and OSPF) which will simplify the ensuing discussions in the community significantly * I suggest to introduce a glossary in the spec since many places the reading is pretty loose (along the lines of ids, router ids, neighbor ids which can be only read "in context" today and I ended up falling sometimes on Bird implementation to be sure I understood correctly) * I advise introduction of a mandatory flag on TLVs. src-dst routing works as described in Juliusz' paper (i.e. all routers not understanding it discard src-announcements and with that the multi-topology non-looping properties are preserved correctly. A mandatory flag will allow to differentiate between =E2=80=9Can old router can just ignore unknown TLV an= d use rest of information=E2=80=9D to =E2=80=9Cold router can't understand extens= ion and needs ignore prefix or even whole tlv surrounding [to be specified])=E2=80=9D. In short I consider the current treatment per "source specific routing" paper by Juliusz as theoretically correct but practically too limiting in long term, large-scale deployments. The discussion of mandatory flag on future TLVs extending the protocol and causing black holes/loops if not understood/ignored by old routers is something that I consider prerogatory to be discussed during BoF/WG charter= . * The compression on the packet format would need good tightening in terms of error conditions, multiplicities allowed, TLV sequence/split between packets. The compression itself is a good, novel idea worth trying albeit I assume the spec here will be bigger than "normal" TLVs, discussions longer and implementations more tricky to get them correct including error case treatment. * I advise towards 32 bit metric (first bits can be used to choose 8/16/32 compression if packet sizes are of uttermost importance) and same for 16 bit TLV length or 8/16 first-bit selectable format. ISIS 1-byte TLV length led to lots of issues over years (which can be resolved but are avoidable and represent complexity without value). Metrics that have proven too short were and are operational and specification impediments of first degree. Overall, it may be e.g. quite natural to split 16 bits len into 12 bit len + 4 flags [e.g. mandatory]). * Security is the elephant in the room and I think that security A-D/area should get interested and strongly support the work with input/text/implementations. I don't consider a WG gunning for any kind of standards track feasible without mandatory security deliverables as advisable. The protocol as it stands (and is acknowledged) is open to even the simplest intentional or unintentional attack. * I choose not to touch on ECMP here which is another interesting topic. Overall, I think there is an understanding that the discussions/extensions may cause a likely uplift in protocol version, i.e. Babel-experimental would need to become a Babel-v2-PS. But if there is a good time to do so, the time would be now (in case of working group formation with the according interest, energy and promise of delivery of such a protocol with new ideas in routing adapting to novel link technologies prevalent today and treating problems like src-dst routing which had no real satisfactory solution (on the edge) ) ---- For the insatiably curious, below examples of i) a nit-grit in procedures and discussion necessary for PS track and ii) discussion with Juliusz to clarify my concerns that the experimental spec today implemented would not work correctly (and looking @ implementation would not clarify the issue) and even if the spec is aligned with implementation I still have oscillation concerns that a possible WG would need to discuss out. Example 1: I went looking for SeqNr# rollover procedures and since the spec only talked about =E2=80=9CA node increments its sequence number (modulo 2^= 16) whenever it receives a request for a new sequence number (Section 3.8.1.2 ).=E2=80=9C. I read th= at as =E2=80=9Cdon=E2=80=99t store in variable > 16 bit because you=E2=80=99ll ov= erflow on inc=E2=80=9D and only after talking to Juliusz and looking @ Bird code I understood that the following code below is meant. Now, this will work to _some_ reasonable extent, the margin is fairly small (16 in best case) and whether it=E2=80= =99s enough for Babel deployments deserves a discussion given timeout values, possible network partitioning times, seqnr frequency, possible storms of seqnr requests (leading to discussion of the =E2=80=9Ckeep request for some= time=E2=80=9D logic and timers). A PS spec IMO should spell out clearly and easily how the rollover is implemented and discuss the safety margin, run through enough simulations to verify the margin of safety. using u16 =3D unsigned short int; static inline u16 ge_mod64k(u16 a, u16 b) { return ((u16) a-b) < 0xfff0; } ... auto prev =3D false; u16 i =3D 0; do { prev =3D false; u16 j =3D0; do { if (i>j && !ge_mod64k(i,j)) { if (!prev) { cout << "from " << setw(4) << hex << "0x" << i << ", " << setw(2) << hex << "0x" << j ; } prev =3D true; } else { if (prev) { cout << " until " << setw(4) << hex << "0x" << i << ", " << setw(2) << hex << "0x" << j << endl; } prev =3D false; } j++; } while (j); i++; } while (i); from 0xfff0, 0x0 until 0xfff0, 0x1 from 0xfff1, 0x0 until 0xfff1, 0x2 from 0xfff2, 0x0 until 0xfff2, 0x3 from 0xfff3, 0x0 until 0xfff3, 0x4 from 0xfff4, 0x0 until 0xfff4, 0x5 from 0xfff5, 0x0 until 0xfff5, 0x6 from 0xfff6, 0x0 until 0xfff6, 0x7 from 0xfff7, 0x0 until 0xfff7, 0x8 from 0xfff8, 0x0 until 0xfff8, 0x9 from 0xfff9, 0x0 until 0xfff9, 0xa from 0xfffa, 0x0 until 0xfffa, 0xb from 0xfffb, 0x0 until 0xfffb, 0xc from 0xfffc, 0x0 until 0xfffc, 0xd from 0xfffd, 0x0 until 0xfffd, 0xe from 0xfffe, 0x0 until 0xfffe, 0xf from 0xffff, 0x0 until 0xffff, 0x10 ---- Example 2: (one of the simpler discussions on oscillations and normative language) C -- B -- A -- S source S advertising to A will start with A showing B D_s=3D1 and with that= C being shown D_s=3D2 and B having feasiblity condition of 1. In case link co= st from S to A bumps to 5 (it needs more nodes so S is not bumping seq number but another node shows bigger metric but the idea holds), B will refuse updates from A being the only route to S _and_ it will not start an explicit route request while C will still see the incorrect distance to S based on procedures in 3.5.4 [which would benefit from numbering like ISIS and OSPF spec in case we aim for PS]. The solution is in the fact that 3.8.2.2 casually mentions =E2=80=9CIn orde= r to keep routes from spuriously expiring because they have become unfeasible, a node SHOULD send a unicast seqno request whenever it receives an unfeasible update for a route that is currently selected.=E2=80=9D As Juliusz pointed out, it=E2=80=99s a MUST and not a SHOULD. The differenc= e is impossible to derive from reference implementations obviously and the wording of 3.8.2.2 does not suggest connection to correctness of 3.5.4. Even after the MUST fix, it merits a discussion how far an oscillation behavior can be generated if the condition persists (i.e. a convergence scenario exists where after a feasible route is installed an infeasible route arrives every time due to timing constraints on the propagation of the new seqnr#). thanks --- tony --047d7b1637ade3d773052edadec3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Here's my take before BoF = after fairly careful reading & thinking through Babel as documented/imp= lemented today + some enlightening discussions with Juliusz.=C2=A0 Comments= /discussions/takes from the list before BoF would be very welcome. <= /span>


IMO Babel is sound in principle and wor= th pursuing for HomeNet world-wide deployment scenarios iif

* some technical deficiencies are remedied and = procedures defined more tightly

* the solution is used on networks with relatively fe= w devices (low 100s) and fairly small diameter (~5-10) without large routing tables (>few K addresses) or extensive= aggregation. With suitable op= timizations and possibly protocol extensions the protocol may = bear significantly larger deployments as well.


Desirable properties and trade-offs as far I see them:


* significant implementation and stand= ardization simplicity as compared to a link-state protocol

* source-destination routi= ng is almost trivial per draft-boutier-babel-source-specific and seems corr= ect from my experience with further comments down.

* better stability in lossy netwo= rks for the cost of slower convergence than link-state, probably a good tra= de-off given the likely wireless nature of = home style networks [as a trade-off for the stability a certain =E2=80=9Cst= ickiness=E2=80=9D is obviously to be expected as compared to link-state. This is a normal consequence of a diffused rather than distribut= ed computation. The stickiness will get worse with diameter].


Now, what follows is the remaining work for = the BoF (and/or possible WG) to talk through/attack as recommendations from= my side in rough sketch form (I had very detailed discussions with Juliusz= over email and some things we agreed on, some we differ, some we agreed ne= ed further pondering upon by people experienced in the art ;-) I omit many = gritty details to keep the picture fairly tractable (while giving underneat= h 2 examples of discussions that ensued about why the spec as it stands tod= ay needs good amount of attention to be of PS quality IME): <= /p>

* first an optional but strongly suggested topi= c: detailed simulation of Babel within the envelope agreed upon by the deve= lopers/chairs/requirements set by HomeNet, i.e. mobility ratios, loss ratio= s, interference ratios to ensure correct convergence within practical time = limits and intended scale

* standardization of ideally a single one or max. 2-3 metri= cs (Juliusz likes "default metric") which at least one of I would= recommend to be isotonic (but there seems =C2=A0to be experience/consensus= that left distributivity [left isotonicity]) is not necessary for correct = routing [vs. optimal]). Something like metric dependent on interface type i= s probably OK. The reasoning here is that the protocol must be stable, conv= erge well out-the-box amongst different vendors without requiring tons of m= agic knobs or even if some routers had the "2-3 different metrics"= ; knob twisted.

=C2=A0Proliferation of "experimental appendices and metrics&qu= ot; are perfectly fine IMO as long they are understood as such, i.e. IETF-w= arranty-sticker is peeled off the moment someone starts to twist those in a= network.

=C2=A0I read http://arxiv.org= /pdf/1403.3488v1.pdf and the issues are well researched an= d understood by authors. In case the simulations @ reasonable sizes under r= equired envelope prove stability/desired properties of such a delay-metric = under affine functions & hysteresis I see nothing wrong in discussing t= his as a standard metric. Yes, it's risky IMO but the traditional wisdo= m of last 20 years should be challenged with the world changing on us. With= out that, no progress can be made. =C2=A0

* standardization of default value for many= constants e.g. for hysteresis, timeouts that is guaranteed to internetwork= in targeted networks out-the-box (albeit doesn't have to be optimal). =

* BoF/WG = needs to discuss the multicast issue. How far is that in charter ? Is anoth= er protocol needed ? Is Babel intended long-term to evolve into a M-IGP ? <= /font>

* BoF/WG s= hould discuss/consider/answer the issue of auto-configuration of router IDs= . Albeit not within the scope of Babel I consider its deployment success la= rgely hinging off this issue. =C2=A0

* Procedures in 3.5.1 and 3.5.4 need tightening= up. I expect under simulations that the language will solidify in many mor= e MUSTs than the spec offers today. I do not question the convergence of th= e protocol fundamentally (under an isotonic metric, otherwise it's one = variable too many for my current knowledge ;-) but I had discussions with J= uliusz on stable oscillations scenarios and will continue to have so. I giv= e an example below.

* From a practical standpoint, I suggest to make the spec strict= ly numbered (i.e. clauses can be easily talked about like ISIS and OSPF) wh= ich will simplify the ensuing discussions in the community significantly

* I suggest= to introduce a glossary in the spec since many places the reading is prett= y loose (along the lines of ids, router ids, neighbor ids which can be only= read "in context" today and I ended up falling sometimes on Bird= implementation to be sure I understood correctly)

* I advise introduction of a mand= atory flag on TLVs. src-dst routing works as described in Juliusz' pape= r (i.e. all routers not understanding it discard src-announcements and with= that the multi-topology non-looping properties are preserved correctly. A = mandatory flag will allow to differentiate between =E2=80=9Can old router c= an just ignore unknown TLV and use rest of information=E2=80=9D to =E2=80= =9Cold router can't understand extension and needs ignore prefix or eve= n whole tlv surrounding [to be specified])=E2=80=9D.

=C2=A0In short I consider the = current treatment per "source specific routing" paper by Juliusz = as theoretically correct but practically too limiting in long term, large-s= cale deployments.

=C2=A0The discussion of mandatory flag on future TLVs extending t= he protocol and causing black holes/loops if not understood/ignored by old = routers is something that I consider prerogatory to be discussed during BoF= /WG charter.

* The compression on the packet format would need good tightening in ter= ms of error conditions, multiplicities allowed, TLV sequence/split between = packets. The compression itself is a good, novel idea worth trying albeit I= assume the spec here will be bigger than "normal" TLVs, discussi= ons longer and implementations more tricky to get them correct including er= ror case treatment.

* I advise towards 32 bit metric (first bits can be used to choo= se 8/16/32 compression if packet sizes are of uttermost importance) and sam= e for 16 bit TLV length or 8/16 first-bit selectable format. ISIS 1-byte TL= V length led to lots of issues over years (which can be resolved but are av= oidable and represent complexity without value). Metrics that have proven t= oo short were and are operational and specification impediments of first de= gree. Overall, it may be e.g. quite natural to split 16 bits len into 12 bi= t len + 4 flags [e.g. mandatory]).

* Security is the elephant in the room and I th= ink that security A-D/area should get interested and strongly support the w= ork with input/text/implementations. I don't consider a WG gunning for = any kind of standards track feasible without mandatory security deliverable= s as advisable. The protocol as it stands (and is acknowledged) is open to = even the simplest intentional or unintentional attack. =C2=A0=

* I choose not to touch= on ECMP here which is another interesting topic.


Overall, I think there is an understanding that the discu= ssions/extensions may cause a likely uplift in protocol version, i.e. Babel= -experimental would need to become a Babel-v2-PS. But if there is a good ti= me to do so, the time would be now (in case of working group formation with= the according interest, energy and promise of delivery of such a protocol = with new ideas in routing adapting to novel link technologies prevalent tod= ay and treating problems like src-dst routing which had no real satisfactor= y solution (on the edge) )


---- <= /font>


For the insatiably curious, below= examples of

i) a nit-grit in procedures and discussion necessary for PS track and <= /font>

ii) discus= sion with Juliusz to clarify my concerns that the experimental spec today i= mplemented would not work correctly (and looking @ implementation would not= clarify the issue) and even if the spec is aligned with implementation I s= till have oscillation concerns that a possible WG would need to discuss out= .



Example 1: I went looking = for SeqNr# rollover procedures and since the spec only talked about =E2=80= =9CA node increments its sequence number (modulo 2^16) wheneve= r it receives a request for a new sequence number (Section 3.8.1.2).=E2=80=9C. I read that as =E2=80=9Cdon=E2=80=99t store in variable &= gt; 16 bit because you=E2=80=99ll overflow on inc=E2=80=9D and only after t= alking to Juliusz and looking @ Bird code I understood that the following c= ode below is meant. Now, this will work to _some_ reasonable extent, the ma= rgin is fairly small (16 in best case) and whether it=E2=80=99s enough for = Babel deployments deserves a discussion given timeout values, possible netw= ork partitioning times, seqnr frequency, possible storms of seqnr requests = (leading to discussion of the =E2=80=9Ckeep request for some time=E2=80=9D = logic and timers). A PS spec IMO should spell out clearly and easily how th= e rollover is implemented and discuss the safety margin, run through enough= simulations to verify the margin of safety.


using u16 =3D unsigned short int;=


static inline u16 ge_mod64k(u16 a, u16 b)

{

=C2=A0=C2=A0=C2=A0return ((u16) a-b) < 0xfff0;=

}

...

=C2=A0=C2=A0=C2=A0auto prev =3D false;

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap= ;background-color:transparent"> =C2=A0=C2=A0=C2=A0u16 i =3D 0;

=C2=A0=C2=A0=C2=A0= do {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0prev = =3D false;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= u16 j =3D0;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0do {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0if (i>j && !ge_mod64k(i,j)) {=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0if (!prev) {

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0cout << "from " << setw(4) &l= t;< hex << "0x" << i

<< ", " << setw(2) <&l= t; hex << "0x" << j ;

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0}

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0prev =3D true;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0else {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (prev) {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cout << &= quot; until " << setw(4) << hex << "0x"

<< i << = ", " << setw(2) << hex << "0x"

<< j << endl;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0}

= =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0prev =3D fal= se;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0}

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0j++;

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0} while (j);

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0i++;

=C2=A0=C2=A0=C2=A0= }

=C2=A0=C2=A0=C2=A0while (i);


from =C2=A0=C2= =A00xfff0, 0x0 until =C2=A0=C2=A00xfff0, 0x1

from = =C2=A0=C2=A00xfff1, 0x0 until =C2=A0=C2=A00xfff1, 0x2

= from =C2=A0=C2=A00xfff2, 0x0 until =C2=A0=C2=A00xfff2, 0x3

from =C2=A0=C2=A00xfff3, 0x0 until =C2=A0=C2=A00xfff3, 0x4

from =C2=A0=C2=A00xfff4, 0x0 until =C2=A0=C2=A00xfff4, 0x5

from =C2=A0=C2=A00xfff5, 0x0 until =C2=A0=C2=A00xfff5, 0x6=

from =C2=A0=C2=A00xfff6, 0x0 until =C2=A0=C2=A00xfff6= , 0x7

from =C2=A0=C2=A00xfff7, 0x0 until =C2=A0=C2=A00= xfff7, 0x8

from =C2=A0=C2=A00xfff8, 0x0 until =C2=A0= =C2=A00xfff8, 0x9

from =C2=A0=C2=A00xfff9, 0x0 until = =C2=A0=C2=A00xfff9, 0xa

from =C2=A0=C2=A00xfffa, 0x0 u= ntil =C2=A0=C2=A00xfffa, 0xb

from =C2=A0=C2=A00xfffb, = 0x0 until =C2=A0=C2=A00xfffb, 0xc

from =C2=A0=C2=A00xf= ffc, 0x0 until =C2=A0=C2=A00xfffc, 0xd

from =C2=A0=C2= =A00xfffd, 0x0 until =C2=A0=C2=A00xfffd, 0xe

from = =C2=A0=C2=A00xfffe, 0x0 until =C2=A0=C2=A00xfffe, 0xf

= from =C2=A0=C2=A00xffff, 0x0 until =C2=A0=C2=A00xffff, 0x10

----

<= br>

Example 2: (one of= the simpler discussions on oscillations and normative language)


C -- B -- A -- S

=C2=A0=C2=A0

source S advertising to A will s= tart with A showing B D_s=3D1 and with that C being shown D_s=3D2 and B hav= ing feasiblity condition of 1. In case link cost from S to A bumps to 5 (it= needs more nodes so S is not bumping seq number but another node shows big= ger metric but the idea holds), B will refuse updates from A =C2=A0being th= e only route to S _and_ it will not start an explicit route request while C= will still see the incorrect distance to S based on procedures in 3.5.4 = =C2=A0[which would benefit from numbering like ISIS and OSPF spec in case w= e aim for PS]. =C2=A0


The solutio= n is in the fact that 3.8.2.2 casually mentions =E2=80=9CIn order to keep r= outes from spuriously expiring because they have become unfeasible, a node = SHOULD send a unicast seqno request whenever it receives an unfeasible upda= te for a route that is currently selected.=E2=80=9D


As Juliusz pointed out, it=E2=80=99s a MUST and not a SH= OULD. The difference is impossible to derive from reference implementations= obviously and the wording of 3.8.2.2 does not suggest connection to correc= tness of 3.5.4.

=

Even after the MU= ST fix, it merits a discussion how far an oscillation behavior can be gener= ated if the condition persists (i.e. a convergence scenario exists where af= ter a feasible route is installed an infeasible route arrives every time du= e to timing constraints on the propagation of the new seqnr#). =C2=A0=C2=A0=

thanks=C2= =A0

--- tony=C2=A0


--047d7b1637ade3d773052edadec3-- From nobody Fri Mar 25 15:22:20 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D3612D534 for ; Fri, 25 Mar 2016 15:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYKGzdyj6No3 for ; Fri, 25 Mar 2016 15:22:17 -0700 (PDT) Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (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 3D95612D0FC for ; Fri, 25 Mar 2016 15:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1458944533; bh=gzVWbgMXgU2Gq/RQ+8nhcyyCS89s0IxsVXY5FQJhZr4=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=N8eXS6uFi5WgBNd8GlTuNoV2sP8UC+nW82wogNRIUeBp9ypdGEhT1MnS7MZRUXtT+ DZj51piQAf3CSEGKdd3vzHEgAjTr+G4Kc5UPPO+bGMKSd9jksW2b5atg4e/estNrFT ++mMDbpDOxdvZ6GQq5qkKMhN+fyNTTdx60GmnQpU= Sender: toke@toke.dk Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 804D953E84; Fri, 25 Mar 2016 23:22:12 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Tony Przygienda References: Date: Fri, 25 Mar 2016 23:22:12 +0100 In-Reply-To: (Tony Przygienda's message of "Fri, 25 Mar 2016 00:54:20 -0700") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87k2kqtcyz.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: babel@ietf.org Subject: Re: [babel] In-depth look @ Babel towards PS ... X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 22:22:19 -0000 Tony Przygienda writes: > Here's my take before BoF after fairly careful reading & thinking > through Babel as documented/implemented today + some enlightening > discussions with Juliusz. Comments/discussions/takes from the list > before BoF would be very welcome. Cherry-picking and replying to the parts I do have thoughts on, see below... > * first an optional but strongly suggested topic: detailed simulation > of Babel within the envelope agreed upon by the > developers/chairs/requirements set by HomeNet, i.e. mobility ratios, > loss ratios, interference ratios to ensure correct convergence within > practical time limits and intended scale Probably a good idea. Having a test suite in a suitable simulation or emulation environment that people can actually run their implementation in would be nice too. > * standardization of ideally a single one or max. 2-3 metrics Yes, especially if this is to be implementable by people who are not already routing protocol experts (like, say, homenet router vendors or, well, me...). Upgrading from the current "look in the appendix if you don't have a good idea for a metric to use" to "implement this to comply, *then* go experiment with your own metrics if you want" would probably be a good idea. > Proliferation of "experimental appendices and metrics" are perfectly > fine IMO as long they are understood as such, i.e. > IETF-warranty-sticker is peeled off the moment someone starts to twist > those in a network. Maybe having a set of "standard metrics" that were well-understood and configurable in implementations might be nice? Then (sufficiently advanced) users could be told to "use the Mesh Metric", for instance. > * standardization of default value for many constants e.g. for > hysteresis, timeouts that is guaranteed to internetwork in targeted > networks out-the-box (albeit doesn't have to be optimal). I agree, for the same reason as above for metrics. > * BoF/WG should discuss/consider/answer the issue of > auto-configuration of router IDs. Albeit not within the scope of Babel > I consider its deployment success largely hinging off this issue. Probably a good idea. Isn't the space large enough that drawing them randomly, or by hashing, would work? > * The compression on the packet format would need good tightening in > terms of error conditions, multiplicities allowed, TLV sequence/split > between packets. The compression itself is a good, novel idea worth > trying albeit I assume the spec here will be bigger than "normal" > TLVs, discussions longer and implementations more tricky to get them > correct including error case treatment. Yes; when I wrote the Bird implementation I decided that I wouldn't even try to implement this (on the sending side). Hashing out the edge cases in the standard would probably be enough to make me reconsider :) > * I advise towards 32 bit metric (first bits can be used to choose > 8/16/32 compression if packet sizes are of uttermost importance) and > same for 16 bit TLV length or 8/16 first-bit selectable format. ISIS > 1-byte TLV length led to lots of issues over years (which can be > resolved but are avoidable and represent complexity without value). > Metrics that have proven too short were and are operational and > specification impediments of first degree. Overall, it may be e.g. > quite natural to split 16 bits len into 12 bit len + 4 flags [e.g. > mandatory]). I'd also tend to agree. After all, what is a few extra bytes between friends? > * Security is the elephant in the room and I think that security > A-D/area should get interested and strongly support the work with > input/text/implementations. I don't consider a WG gunning for any kind > of standards track feasible without mandatory security deliverables as > advisable. The protocol as it stands (and is acknowledged) is open to > even the simplest intentional or unintentional attack. Surely nobody will try to do evil things on the homenets of the future? Certainly that seems to be the philosophy driving the internet of things :/ > Overall, I think there is an understanding that the > discussions/extensions may cause a likely uplift in protocol version, > i.e. Babel-experimental would need to become a Babel-v2-PS. But if > there is a good time to do so, the time would be now (in case of > working group formation with the according interest, energy and > promise of delivery of such a protocol with new ideas in routing > adapting to novel link technologies prevalent today and treating > problems like src-dst routing which had no real satisfactory solution > (on the edge) ) I'd agree that *if* we are to increment the protocol version number, now would be the time. Not sure if the possible improvements from doing so outweigh the cost (for myself the cost is fairly low: I can easily upgrade my entire network at once when needed). After all, we'd also want to have the people currently running Babel to use the IETF standard version of it when that time comes. -Toke From nobody Fri Mar 25 22:32:19 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570BE12D1DC for ; Fri, 25 Mar 2016 22:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2kp3Mij1Bdk for ; Fri, 25 Mar 2016 22:32:15 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5382B12D12B for ; Fri, 25 Mar 2016 22:32:15 -0700 (PDT) Received: by mail-ig0-x234.google.com with SMTP id nk17so23119582igb.1 for ; Fri, 25 Mar 2016 22:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/GOu2G1oOhn/eVil5aijrTv0/KW6/Xh9uMM/1EUjG6I=; b=PCAD5legZYjkYoo8cLe6NsxcU0oPNOuSt0R6hUnpdhSsVjbPXnHvLekPtstZGSil6X l09yfOI2jJ55weZZbu87l6QmpPDlGaaHUwBM98+LDzwCJMt/VldwiMnbfevvt6kGn8Td lni/cAA5TC+8QjOKaq0e1mHyYLEXukxq3BXZ+0gkw9dlN2gGq2j9gNpZFNSGLMofJWRV mYM8nyWE1BiOPFIRL2/Rfg3vxbo0HkqCCS/c00pafPuBU4Rgwd8vKQPeie09SR+oXcOn zkwVFwgdmHXEwtc1Zgzon3xHVZ/OAeMRvr5Cp3N46yVONHvQ5sN8547wpO6J1dcx8+YP trPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/GOu2G1oOhn/eVil5aijrTv0/KW6/Xh9uMM/1EUjG6I=; b=GOqZ469AsucV/txY7RDrwp13H75nPHMPI4BfZrdaCKJqpEpgBbF4NNoyfffuQjsTTV JTRTNitTVxG9GYJhZ3yMog4PqRvCwKM3MxSLDEJjqe1uNDMLIZDu9gNAj4KXhlPIY1vb KmhnwBcx6C9/B4FlLxS2KILoFHXqHnG63mnDGtRNdYvKQ06qBCthgdypP3Kgfx0iqR6I T6Fyz0xmmz9m5vYGQBAROF1jeTpaGeBFA3v7lFE2bxMMpLcGV6t77iYG5UsXkQfYBsbM aFKgpgG/V6wfu+ruJ2nxBAJMJqsbzMFKqN+htVh/kfbfCrkDNmoMDINh0oghuSCWyagG Sscw== X-Gm-Message-State: AD7BkJJpyzU2NscyzNI35tp4h1GHAcvpzZ04jY7WBcdGIVPe9eeZ8KeG7SlVHft5gZKICE57nj+j6czbWF5rlQ== MIME-Version: 1.0 X-Received: by 10.50.112.10 with SMTP id im10mr135222igb.93.1458970334695; Fri, 25 Mar 2016 22:32:14 -0700 (PDT) Received: by 10.107.6.41 with HTTP; Fri, 25 Mar 2016 22:32:14 -0700 (PDT) In-Reply-To: <87k2kqtcyz.fsf@toke.dk> References: <87k2kqtcyz.fsf@toke.dk> Date: Fri, 25 Mar 2016 22:32:14 -0700 Message-ID: From: Tony Przygienda To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Content-Type: multipart/alternative; boundary=047d7b1637ad8a0348052eed0031 Archived-At: Cc: babel@ietf.org Subject: Re: [babel] In-depth look @ Babel towards PS ... X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 05:32:17 -0000 --047d7b1637ad8a0348052eed0031 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Toke, very good, seems we're hitting roughly same wavelength. Let's see whether more people chime in into this thread ... BTW, Babel in Bird is pretty easy on the eyes (i.e. flows well and just the right amount of comments to get over the rougher patches ;-) given it's C, compliments ;-) -- tony On Fri, Mar 25, 2016 at 3:22 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Tony Przygienda writes: > > > Here's my take before BoF after fairly careful reading & thinking > > through Babel as documented/implemented today + some enlightening > > discussions with Juliusz. Comments/discussions/takes from the list > > before BoF would be very welcome. > > Cherry-picking and replying to the parts I do have thoughts on, see > below... > > > * first an optional but strongly suggested topic: detailed simulation > > of Babel within the envelope agreed upon by the > > developers/chairs/requirements set by HomeNet, i.e. mobility ratios, > > loss ratios, interference ratios to ensure correct convergence within > > practical time limits and intended scale > > Probably a good idea. Having a test suite in a suitable simulation or > emulation environment that people can actually run their implementation > in would be nice too. > > > * standardization of ideally a single one or max. 2-3 metrics > > Yes, especially if this is to be implementable by people who are not > already routing protocol experts (like, say, homenet router vendors or, > well, me...). Upgrading from the current "look in the appendix if you > don't have a good idea for a metric to use" to "implement this to > comply, *then* go experiment with your own metrics if you want" would > probably be a good idea. > > > Proliferation of "experimental appendices and metrics" are perfectly > > fine IMO as long they are understood as such, i.e. > > IETF-warranty-sticker is peeled off the moment someone starts to twist > > those in a network. > > Maybe having a set of "standard metrics" that were well-understood and > configurable in implementations might be nice? Then (sufficiently > advanced) users could be told to "use the Mesh Metric", for instance. > > > * standardization of default value for many constants e.g. for > > hysteresis, timeouts that is guaranteed to internetwork in targeted > > networks out-the-box (albeit doesn't have to be optimal). > > I agree, for the same reason as above for metrics. > > > * BoF/WG should discuss/consider/answer the issue of > > auto-configuration of router IDs. Albeit not within the scope of Babel > > I consider its deployment success largely hinging off this issue. > > Probably a good idea. Isn't the space large enough that drawing them > randomly, or by hashing, would work? > > > * The compression on the packet format would need good tightening in > > terms of error conditions, multiplicities allowed, TLV sequence/split > > between packets. The compression itself is a good, novel idea worth > > trying albeit I assume the spec here will be bigger than "normal" > > TLVs, discussions longer and implementations more tricky to get them > > correct including error case treatment. > > Yes; when I wrote the Bird implementation I decided that I wouldn't even > try to implement this (on the sending side). Hashing out the edge cases > in the standard would probably be enough to make me reconsider :) > > > * I advise towards 32 bit metric (first bits can be used to choose > > 8/16/32 compression if packet sizes are of uttermost importance) and > > same for 16 bit TLV length or 8/16 first-bit selectable format. ISIS > > 1-byte TLV length led to lots of issues over years (which can be > > resolved but are avoidable and represent complexity without value). > > Metrics that have proven too short were and are operational and > > specification impediments of first degree. Overall, it may be e.g. > > quite natural to split 16 bits len into 12 bit len + 4 flags [e.g. > > mandatory]). > > I'd also tend to agree. After all, what is a few extra bytes between > friends? > > > * Security is the elephant in the room and I think that security > > A-D/area should get interested and strongly support the work with > > input/text/implementations. I don't consider a WG gunning for any kind > > of standards track feasible without mandatory security deliverables as > > advisable. The protocol as it stands (and is acknowledged) is open to > > even the simplest intentional or unintentional attack. > > Surely nobody will try to do evil things on the homenets of the future? > Certainly that seems to be the philosophy driving the internet of things = :/ > > > Overall, I think there is an understanding that the > > discussions/extensions may cause a likely uplift in protocol version, > > i.e. Babel-experimental would need to become a Babel-v2-PS. But if > > there is a good time to do so, the time would be now (in case of > > working group formation with the according interest, energy and > > promise of delivery of such a protocol with new ideas in routing > > adapting to novel link technologies prevalent today and treating > > problems like src-dst routing which had no real satisfactory solution > > (on the edge) ) > > I'd agree that *if* we are to increment the protocol version number, now > would be the time. Not sure if the possible improvements from doing so > outweigh the cost (for myself the cost is fairly low: I can easily > upgrade my entire network at once when needed). After all, we'd also > want to have the people currently running Babel to use the IETF standard > version of it when that time comes. > > -Toke > --=20 *We=E2=80=99ve heard that a million monkeys at a million keyboards could pr= oduce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.* =E2=80=94Robert Wilensky --047d7b1637ad8a0348052eed0031 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Toke, very good, seems we're =C2=A0hitting roughly sam= e wavelength. Let's see whether more people chime in into this thread .= ..=C2=A0

BTW, Babel in Bird is pretty easy on the eyes (= i.e. flows well and just the right amount of comments to get over the rough= er patches ;-) given it's C, compliments ;-) =C2=A0

<= div>-- tony=C2=A0

On Fri, Mar 25, 2016 at 3:22 PM, Toke H=C3=B8iland-J=C3= =B8rgensen <toke@toke.dk> wrote:
Tony Przygienda <tonysietf@gmail.com> writes:

> Here's my take before BoF after fairly careful reading & think= ing
> through Babel as documented/implemented today + some enlightening
> discussions with Juliusz. Comments/discussions/takes from the list
> before BoF would be very welcome.

Cherry-picking and replying to the parts I do have thoughts on, see<= br> below...

> * first an optional but strongly suggested topic: detailed simulation<= br> > of Babel within the envelope agreed upon by the
> developers/chairs/requirements set by HomeNet, i.e. mobility ratios, > loss ratios, interference ratios to ensure correct convergence within<= br> > practical time limits and intended scale

Probably a good idea. Having a test suite in a suitable simulation o= r
emulation environment that people can actually run their implementation
in would be nice too.

> * standardization of ideally a single one or max. 2-3 metrics

Yes, especially if this is to be implementable by people who are not=
already routing protocol experts (like, say, homenet router vendors or,
well, me...). Upgrading from the current "look in the appendix if you<= br> don't have a good idea for a metric to use" to "implement thi= s to
comply, *then* go experiment with your own metrics if you want" would<= br> probably be a good idea.

> Proliferation of "experimental appendices and metrics" are p= erfectly
> fine IMO as long they are understood as such, i.e.
> IETF-warranty-sticker is peeled off the moment someone starts to twist=
> those in a network.

Maybe having a set of "standard metrics" that were well-un= derstood and
configurable in implementations might be nice? Then (sufficiently
advanced) users could be told to "use the Mesh Metric", for insta= nce.

> * standardization of default value for many constants e.g. for
> hysteresis, timeouts that is guaranteed to internetwork in targeted > networks out-the-box (albeit doesn't have to be optimal).

I agree, for the same reason as above for metrics.

> * BoF/WG should discuss/consider/answer the issue of
> auto-configuration of router IDs. Albeit not within the scope of Babel=
> I consider its deployment success largely hinging off this issue.

Probably a good idea. Isn't the space large enough that drawing = them
randomly, or by hashing, would work?

> * The compression on the packet format would need good tightening in > terms of error conditions, multiplicities allowed, TLV sequence/split<= br> > between packets. The compression itself is a good, novel idea worth > trying albeit I assume the spec here will be bigger than "normal&= quot;
> TLVs, discussions longer and implementations more tricky to get them > correct including error case treatment.

Yes; when I wrote the Bird implementation I decided that I wouldn= 9;t even
try to implement this (on the sending side). Hashing out the edge cases
in the standard would probably be enough to make me reconsider :)

> * I advise towards 32 bit metric (first bits can be used to choose
> 8/16/32 compression if packet sizes are of uttermost importance) and > same for 16 bit TLV length or 8/16 first-bit selectable format. ISIS > 1-byte TLV length led to lots of issues over years (which can be
> resolved but are avoidable and represent complexity without value). > Metrics that have proven too short were and are operational and
> specification impediments of first degree. Overall, it may be e.g.
> quite natural to split 16 bits len into 12 bit len + 4 flags [e.g.
> mandatory]).

I'd also tend to agree. After all, what is a few extra bytes bet= ween
friends?

> * Security is the elephant in the room and I think that security
> A-D/area should get interested and strongly support the work with
> input/text/implementations. I don't consider a WG gunning for any = kind
> of standards track feasible without mandatory security deliverables as=
> advisable. The protocol as it stands (and is acknowledged) is open to<= br> > even the simplest intentional or unintentional attack.

Surely nobody will try to do evil things on the homenets of the futu= re?
Certainly that seems to be the philosophy driving the internet of things :/=

> Overall, I think there is an understanding that the
> discussions/extensions may cause a likely uplift in protocol version,<= br> > i.e. Babel-experimental would need to become a Babel-v2-PS. But if
> there is a good time to do so, the time would be now (in case of
> working group formation with the according interest, energy and
> promise of delivery of such a protocol with new ideas in routing
> adapting to novel link technologies prevalent today and treating
> problems like src-dst routing which had no real satisfactory solution<= br> > (on the edge) )

I'd agree that *if* we are to increment the protocol version num= ber, now
would be the time. Not sure if the possible improvements from doing so
outweigh the cost (for myself the cost is fairly low: I can easily
upgrade my entire network at once when needed). After all, we'd also want to have the people currently running Babel to use the IETF standard version of it when that time comes.

-Toke



--
We=E2=80=99ve hea= rd that a million monkeys at a million keyboards could produce the complete= works of Shakespeare; now, thanks to the Internet, we know that is not tru= e.
=
=E2=80=94Robert Wilensky
--047d7b1637ad8a0348052eed0031-- From nobody Sat Mar 26 03:49:24 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC2812D1C8 for ; Sat, 26 Mar 2016 03:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGYIU_vLOhUC for ; Sat, 26 Mar 2016 03:49:22 -0700 (PDT) Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (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 BA2E712D130 for ; Sat, 26 Mar 2016 03:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1458989359; bh=gbcStXLwkvftaLxLqQgEmrcy4+92F5ZgVCEGmtFKs0Q=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=OEjRNPd6nJ5OU6bZgCo8WrG2QNqVpXzv3+xSvmsJZZPF/g/Vgjp6NbllzA0immQYc 9v1iVDxW+W8xNWRxBn9vc0Zmnnz2xPY06YWk7lkYsQJjLorpAi0wDJ8UlS7gcecL0C YAyOhL8MMeijTIlJV6t2xilmVQ8gYA7Gn4EgMU18= Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id F0FBA547AE; Sat, 26 Mar 2016 11:49:17 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Tony Przygienda References: <87k2kqtcyz.fsf@toke.dk> Date: Sat, 26 Mar 2016 11:49:17 +0100 In-Reply-To: (Tony Przygienda's message of "Fri, 25 Mar 2016 22:32:14 -0700") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87d1qhtsya.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: babel@ietf.org Subject: Re: [babel] In-depth look @ Babel towards PS ... X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 10:49:24 -0000 Tony Przygienda writes: > Toke, very good, seems we're hitting roughly same wavelength. Let's > see whether more people chime in into this thread ... Yup. :) > BTW, Babel in Bird is pretty easy on the eyes (i.e. flows well and > just the right amount of comments to get over the rougher patches ;-) > given it's C, compliments ;-) Oh, wow, gee... thanks! :) -Toke From nobody Sun Mar 27 10:51:03 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B9B12D511 for ; Sun, 27 Mar 2016 10:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKtzoiA4tb-e for ; Sun, 27 Mar 2016 10:51:00 -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 35FE912D1BD for ; Sun, 27 Mar 2016 10:50:59 -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 u2RHovDv015282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 27 Mar 2016 19:50:57 +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 u2RHovKS017930; Sun, 27 Mar 2016 19:50:57 +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 64C7C61FA5; Sun, 27 Mar 2016 19:50:57 +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 LqW3eB7F7ZQS; Sun, 27 Mar 2016 19:50:56 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 62AEF61F9A; Sun, 27 Mar 2016 19:50:53 +0200 (CEST) Date: Sun, 27 Mar 2016 19:50:56 +0200 Message-ID: <87io07n727.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Tony Przygienda In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sun, 27 Mar 2016 19:50:57 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 27 Mar 2016 19:50:57 +0200 (CEST) X-Miltered: at korolev with ID 56F81D81.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 56F81D81.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 56F81D81.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 56F81D81.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 : 56F81D81.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 56F81D81.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] In-depth look @ Babel towards PS ... X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 17:51:02 -0000 Thanks for your work, Tony. > * I advise introduction of a mandatory flag on TLVs. Do you mean on sub-TLVs? If you really mean TLVs, then I'd appreciate you spelling out the proposed semantics. (Pro memoria, Babel's packet structure is not recursive, it has just three levels: a Packet contains a sequence of TLV which can optionally contain sub-TLVs. Putting a mandatory bit in sub-TLVs makes sense -- you drop the whole enclosing TLV --, although I'm not yet convinced it's worth the added complexity. On the other hand, I don't see what a mandatory bit in toplevel TLVs would mean -- you drop the whole packet?) > src-dst routing works as described in Juliusz' paper Matthieu's and Juliusz' paper. > Babel-experimental would need to become a Babel-v2-PS. RFC 6126 describes Babel version 2, so that would be Babel version 3. > Example 1: I went looking for SeqNr# rollover procedures [...] [...] > and only after talking to Juliusz and looking @ Bird code I understood > that the following code below is meant: > static inline u16 ge_mod64k(u16 a, u16 b) > { > return ((u16) a-b) < 0xfff0; > } No, Bird gets it wrong (I've mentioned it to Toke already). The proper definition is static inline int seqno_compare(unsigned short s1, unsigned short s2) { if(s1 == s2) return 0; else return ((s2 - s1) & 0x8000) ? 1 : -1; } Which only strenghens your point that this needs to be spelled out in the RFC. (When writing RFC 6126, I was under the illusion that ordering modulo is a standard, well known notion -- it turns out I was wrong.) -- Juliusz From nobody Sun Mar 27 10:58:50 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACB212D14D for ; Sun, 27 Mar 2016 10:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDgZ4fXetyEq for ; Sun, 27 Mar 2016 10:58:47 -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 AC8BA12D14A for ; Sun, 27 Mar 2016 10:58:46 -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 u2RHwiX0016415; Sun, 27 Mar 2016 19:58:44 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C68AF61FB8; Sun, 27 Mar 2016 19:58:44 +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 4oS2IXko39Bc; Sun, 27 Mar 2016 19:58:43 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 72E1C61FBC; Sun, 27 Mar 2016 19:58:43 +0200 (CEST) Date: Sun, 27 Mar 2016 19:58:46 +0200 Message-ID: <87h9frn6p5.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Tony Przygienda In-Reply-To: <87io07n727.wl-jch@pps.univ-paris-diderot.fr> References: <87io07n727.wl-jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 27 Mar 2016 19:58:44 +0200 (CEST) X-Miltered: at korolev with ID 56F81F54.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 56F81F54.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 56F81F54.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: babel@ietf.org Subject: Re: [babel] In-depth look @ Babel towards PS ... X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 17:58:48 -0000 > Which only strenghens your point that this needs to be spelled out in the > RFC. (When writing RFC 6126, I was under the illusion that ordering > modulo is a standard, well known notion -- it turns out I was wrong.) It is defined in RFC 1982, altough the RFC doesn't define the case s1 = s2 + 2^15. From nobody Sun Mar 27 11:11:25 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D0F12D522 for ; Sun, 27 Mar 2016 11:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaYWL5OL8Ahe for ; Sun, 27 Mar 2016 11:11:22 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001: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 EA84A12D1C9 for ; Sun, 27 Mar 2016 11:11:21 -0700 (PDT) Received: by mail-ig0-x233.google.com with SMTP id av4so40174949igc.1 for ; Sun, 27 Mar 2016 11:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=k5i4rb3V/BcwFVxwDH9gwmHgadFtug8CD+ZTJLLaHds=; b=OFmFyjZ9u+eEOsf5n+ueV3Db7TU7Nojy0jscMWMKNkj+p7rKUsfFXGp+hmipZoXQ/7 kaGKvv0DtBKzG270g8+T5CkTu3+m1GKdpU78gc0sXOM2PZENtqRXRfRj4vy2/FWT9ANZ 91MqRChbQFVKvxByc6GtZFyK0m5I7FcvWfaqUp1w34RK0+clLLrkbmDo4H7Kdhuv0BKU udIFjznFMoqNEUUVBv+gNssxezj7+jdbttP8o+KH1j5WB5tKt4eHO6bBBD0EVY2YHl3l aEfeeXY8Ss3+XBuAZVlN/kzll9W2HoGkiOiEI2pXUOLZWHl30iHrcx1+HYaSMUWAj7kL CV/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=k5i4rb3V/BcwFVxwDH9gwmHgadFtug8CD+ZTJLLaHds=; b=lSpDu5vc364pBG5v6Fcq1Vcplzi3ofYYAnC+v7tUvbhdYnvh6uCqxsIOIaK8Xx4TgC 7hbY+Kcol0hovWdFhfPTSeGPbpMMTqkQXCEvOfUwr5ZdbaL2bCBCXiJCfjcOw95IAQUH i6GDN51fHOZu/Ou5VbrEVgkfs7kWZHn9rEoHUG4kungFSCZEPv1ruIui2S2JNLOgY7v1 MubLlfILrs7tfrv4gvJGxE0xvhc8H5jgyt/K4ftEYpoGpbLjnwaDy2UrcVarlI65FdnO 9Tb69/6K+f+tZuKr9hXXDApsMdBKZX1ZDl4jmQq9mF9ararrBoTkYMa9MNvEMthY/wV2 u+zg== X-Gm-Message-State: AD7BkJJ0PY7CoXRhhQlXjPXD/Xirjo3xldQ+JBBnHNlhzPj5Qt633O63QH2M8cg22KN+kLmz1K7i7jWp0h2jQw== MIME-Version: 1.0 X-Received: by 10.50.112.10 with SMTP id im10mr6196903igb.93.1459102281367; Sun, 27 Mar 2016 11:11:21 -0700 (PDT) Received: by 10.107.6.41 with HTTP; Sun, 27 Mar 2016 11:11:21 -0700 (PDT) In-Reply-To: <87io07n727.wl-jch@pps.univ-paris-diderot.fr> References: <87io07n727.wl-jch@pps.univ-paris-diderot.fr> Date: Sun, 27 Mar 2016 11:11:21 -0700 Message-ID: From: Tony Przygienda To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=047d7b1637ad2c0c7d052f0bb95c Archived-At: Cc: babel@ietf.org Subject: Re: [babel] In-depth look @ Babel towards PS ... X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 18:11:24 -0000 --047d7b1637ad2c0c7d052f0bb95c Content-Type: text/plain; charset=UTF-8 On Sun, Mar 27, 2016 at 10:50 AM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > Thanks for your work, Tony. > > > * I advise introduction of a mandatory flag on TLVs. > > Do you mean on sub-TLVs? If you really mean TLVs, then I'd appreciate you > spelling out the proposed semantics. > > (Pro memoria, Babel's packet structure is not recursive, it has just three > levels: a Packet contains a sequence of TLV which can optionally contain > sub-TLVs. Putting a mandatory bit in sub-TLVs makes sense -- you drop the > whole enclosing TLV --, although I'm not yet convinced it's worth the > added complexity. On the other hand, I don't see what a mandatory bit in > toplevel TLVs would mean -- you drop the whole packet?) > yes, i) I advise completely symmetric type/len/flags field on all TLV/sub-tlv/sub^n-TLV for the simple reason that parsin' is much simpler but you'll figure ii) laugh or not, after initial tlv/sub-tlv and never deeper "sign-in-blood-and-cross-my-heart" structure started in ISIS we are discussing possible sub^3-TLVs for better or for worse for certain things now. Price of "wild success" we discussed in other conversations. > > > src-dst routing works as described in Juliusz' paper > > Matthieu's and Juliusz' paper. > sorry, forgot how to do BibTex ages ago ;-) > > > Babel-experimental would need to become a Babel-v2-PS. > > RFC 6126 describes Babel version 2, so that would be Babel version 3. > nit ... ack. > > > Example 1: I went looking for SeqNr# rollover procedures [...] > > [...] > > > and only after talking to Juliusz and looking @ Bird code I understood > > that the following code below is meant: > > > static inline u16 ge_mod64k(u16 a, u16 b) > > { > > return ((u16) a-b) < 0xfff0; > > } > > No, Bird gets it wrong (I've mentioned it to Toke already). The proper > definition is > > static inline int > seqno_compare(unsigned short s1, unsigned short s2) > { > if(s1 == s2) > return 0; > else > return ((s2 - s1) & 0x8000) ? 1 : -1; > } > > Which only strenghens your point that this needs to be spelled out in the > RFC. (When writing RFC 6126, I was under the illusion that ordering > modulo is a standard, well known notion -- it turns out I was wrong.) > yepp, now THIS looks more like lolli-pop space I mentioned (if memory carries after all those years) and this was FAR more safe but yes, it would need a write-down or reference to OSPF spec (don't remember John ever described it carefully @ the end either). Current OSPF folks will have it present. Yuh, reference implementations and all ;-) and this is of course only a single nit but exemplifies the "scar tissue" and PS track point. E'one who read John's book will read the entertaining story of "you have to shut down the _WHOLE_ internet to fix it". Whether it's the Internet of the "shut your whole home network" is just a flavor of "unhappy customer" at the end ... --- tony --047d7b1637ad2c0c7d052f0bb95c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 27, 2016 at 10:50 AM, Juliusz Chroboczek = <jch@= pps.univ-paris-diderot.fr> wrote:
Thanks for your work, Tony.

> * I advise introduction of a mandatory flag on TLVs.

Do you mean on sub-TLVs?=C2=A0 If you really mean TLVs, then I'd= appreciate you
spelling out the proposed semantics.

(Pro memoria, Babel's packet structure is not recursive, it has just th= ree
levels: a Packet contains a sequence of TLV which can optionally contain sub-TLVs.=C2=A0 Putting a mandatory bit in sub-TLVs makes sense -- you drop= the
whole enclosing TLV --, although I'm not yet convinced it's worth t= he
added complexity.=C2=A0 On the other hand, I don't see what a mandatory= bit in
toplevel TLVs would mean -- you drop the whole packet?)

yes,=C2=A0

i) I advise completely= symmetric type/len/flags field on all TLV/sub-tlv/sub^n-TLV=C2=A0
for the simple reason that parsin' is much simpler but you'll fig= ure
ii) laugh or not, after initial tlv/sub-tlv and never deeper = "sign-in-blood-and-cross-my-heart"=C2=A0
structure star= ted in ISIS we are discussing possible sub^3-TLVs for better or=C2=A0
=
for worse for certain things now. Price of "wild success" we= discussed in other conversations. =C2=A0
=C2=A0

> src-dst routing works as described in Juliusz' paper

Matthieu's and Juliusz' paper.

sorry, forgot how to do BibTex ages ago ;-)=C2=A0
=C2=A0

> Babel-experimental would need to become a Babel-v2-PS.

RFC 6126 describes Babel version 2, so that would be Babel version 3= .

nit ... ack.=C2=A0
=C2=A0

> Example 1: I went looking for SeqNr# rollover procedures [...]

[...]

> and only after talking to Juliusz and looking @ Bird code I understood=
> that the following code below is meant:

> static inline u16 ge_mod64k(u16 a, u16 b)
> {
>=C2=A0 =C2=A0 =C2=A0return ((u16) a-b) < 0xfff0;
> }

No, Bird gets it wrong (I've mentioned it to Toke already).=C2= =A0 The proper
definition is

=C2=A0 =C2=A0static inline int
=C2=A0 =C2=A0seqno_compare(unsigned short s1, unsigned short s2)
=C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0if(s1 =3D=3D s2)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 0;
=C2=A0 =C2=A0 =C2=A0 =C2=A0else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return ((s2 - s1) & 0x8000) ? = 1 : -1;
=C2=A0 =C2=A0}

Which only strenghens your point that this needs to be spelled out in the RFC.=C2=A0 (When writing RFC 6126, I was under the illusion that ordering modulo is a standard, well known notion -- it turns out I was wrong.)


yepp, now THIS looks more lik= e lolli-pop space I mentioned (if memory carries=C2=A0
after all = those years) and this was FAR more safe =C2=A0but yes, it would need a writ= e-down=C2=A0
or reference to OSPF spec (don't remember John e= ver described it carefully @ the end either).=C2=A0
Current OSPF = folks will have it present.=C2=A0

Yuh, reference i= mplementations and all ;-) =C2=A0and this is =C2=A0of course only a single= =C2=A0
nit but exemplifies the "scar tissue" and PS tra= ck point. E'one who read John's book will read=C2=A0
the = entertaining story of "you have to shut down the _WHOLE_ internet to f= ix it".=C2=A0
Whether it's the Internet of the "shu= t your whole home network" is just a flavor of=C2=A0
"u= nhappy customer" at the end ...

--- tony=C2= =A0

=C2=A0
--047d7b1637ad2c0c7d052f0bb95c-- From nobody Sun Mar 27 11:12:50 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EADB12D522 for ; Sun, 27 Mar 2016 11:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7QLfQWOhr_N for ; Sun, 27 Mar 2016 11:12:47 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 4A26D12D1C9 for ; Sun, 27 Mar 2016 11:12:47 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id 124so156130004iov.3 for ; Sun, 27 Mar 2016 11:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=iOqcvI6EnofKsVUdqPQCZk8cv5Is6NUa6HfZzusk5jI=; b=dcB4kLVR+15DB0MtShf3se5ZvkEb36jQgjlMTZ9CnTSm9eRybfpXYEv3pvvFZgCQf/ d8pqttPv4vC1MfnFoQE1TFwqzrvJbsagqDYlDjHT8va7N1Ay72vJWSnFEmlH8znNMwvq 5ky8EAUq/P9vAE63Vmg817QadC/SdPfT41rqXtVarkp6R4vGy66i2r976DU7cttMLa5p cLelYHrufYZlcu7razfZA0Gu2qvYoV/5rsoKb1I/0iyFugBhUDwiDIEVW3XKxcRVPyK5 HqeQXXWazMIawqYUcwjG4rPRKtPjLZzy0HGchAeXLFX2aSt6ii3spscAT50La4O36tI9 yavg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=iOqcvI6EnofKsVUdqPQCZk8cv5Is6NUa6HfZzusk5jI=; b=crENXgTnegQR0c77XPSkUaud+q5TxKOO3D7dGfVPiIu47pIfbGVGsFJnD9hSH+OtAy m4WaBcGUd9TDdj9HqJP7e6106etynIHi9lMquNPW6pr8Obx8QOFnKn1ujLApR2I3JpNg NY7wv/rugpVIIz3/l9QvcFtiJ/kvTbDgQzffpUaBZcWHvZ25tSCEgSuTizYVQynX64Cd tUquHI7KYgovAl+Vo/vA7Qo8jL06XPqsFOPyDBancZLpoGiwZ7XGfOcTzry6DOjUdQxB KXy+KJny0cPUWKNOhkkkT2clXEqpUV422i0BEaLvDQ+d3ys3iID7PtHxaVc42l5wE849 jSeg== X-Gm-Message-State: AD7BkJJs3mlEI5XIHICHQe2ikdrclCayaeR5+QpENCPkOTzdgq7Jqj/tK1pISEhn8rXw+uCdH5F3mBO5zPLQEw== MIME-Version: 1.0 X-Received: by 10.107.165.78 with SMTP id o75mr25312041ioe.56.1459102366708; Sun, 27 Mar 2016 11:12:46 -0700 (PDT) Received: by 10.107.6.41 with HTTP; Sun, 27 Mar 2016 11:12:46 -0700 (PDT) In-Reply-To: <87h9frn6p5.wl-jch@pps.univ-paris-diderot.fr> References: <87io07n727.wl-jch@pps.univ-paris-diderot.fr> <87h9frn6p5.wl-jch@pps.univ-paris-diderot.fr> Date: Sun, 27 Mar 2016 11:12:46 -0700 Message-ID: From: Tony Przygienda To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=001a1141f262423b7a052f0bbe0d Archived-At: Cc: babel@ietf.org Subject: Re: [babel] In-depth look @ Babel towards PS ... X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 18:12:49 -0000 --001a1141f262423b7a052f0bbe0d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Wow, good catch. Forgot all about that. On Sun, Mar 27, 2016 at 10:58 AM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > > Which only strenghens your point that this needs to be spelled out in t= he > > RFC. (When writing RFC 6126, I was under the illusion that ordering > > modulo is a standard, well known notion -- it turns out I was wrong.) > > It is defined in RFC 1982, altough the RFC doesn't define the case > s1 =3D s2 + 2^15. > --=20 *We=E2=80=99ve heard that a million monkeys at a million keyboards could pr= oduce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.* =E2=80=94Robert Wilensky --001a1141f262423b7a052f0bbe0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wow, good catch. Forgot all about that.=C2=A0

On Sun, Mar 27, 2016 at 10:58 = AM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr><= /span> wrote:
> Which= only strenghens your point that this needs to be spelled out in the
> RFC.=C2=A0 (When writing RFC 6126, I was under the illusion that order= ing
> modulo is a standard, well known notion -- it turns out I was wrong.)<= br>
It is defined in RFC 1982, altough the RFC doesn't define the ca= se
s1 =3D s2 + 2^15.


--
We=E2=80=99ve heard that a million monkeys at a m= illion keyboards could produce the complete works of Shakespeare; now, than= ks to the Internet, we know that is not true.
=E2=80=94Robert Wil= ensky
--001a1141f262423b7a052f0bbe0d-- From nobody Mon Mar 28 06:42:29 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E6512D942 for ; Mon, 28 Mar 2016 06:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCzMMJonKv6O for ; Mon, 28 Mar 2016 06:42:27 -0700 (PDT) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C150C12D960 for ; Mon, 28 Mar 2016 06:42:27 -0700 (PDT) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1459171532839123.3967549589371; Mon, 28 Mar 2016 06:25:32 -0700 (PDT) Date: Mon, 28 Mar 2016 14:25:32 +0100 From: Denis Ovsienko To: Message-ID: <153bd669f46.e5f7f9bf1515.6305608076425038357@ovsienko.info> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Zoho-Virus-Status: 1 Archived-At: Subject: Re: [babel] In-depth look @ Babel towards PS ... X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 13:42:29 -0000 Hello all. [...] >* Security is the elephant in the room and I think that security A-D/area = should get interested and strongly support the work with input/text/impleme= ntations. I don't consider a WG gunning for any kind of standards track fea= sible without mandatory security deliverables as advisable. The protocol as= it stands (and is acknowledged) is open to even the simplest intentional o= r unintentional attack. =C2=A0 [...] That's the motivation behind RFC 7298. I am looking forward both to present= my own input and to listen to any other input on this subject. On this not= e, if anybody considers some document(s) meaningful for this BoF discussion= (not just security), may I suggest they mention such documents on the mail= ing list soonest possible to help the participants to prepare better? Thank= you. --=20 Denis Ovsienko From nobody Mon Mar 28 06:53:28 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1616012D979 for ; Mon, 28 Mar 2016 06:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zm3ooiHmEm8q for ; Mon, 28 Mar 2016 06:53:25 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF6512D915 for ; Mon, 28 Mar 2016 06:53:24 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u2SDrNkE016579; Mon, 28 Mar 2016 15:53:23 +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 4937361F9A; Mon, 28 Mar 2016 15:53: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 4Tzg_epC1TPv; Mon, 28 Mar 2016 15:53:17 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3A7B361FAB; Mon, 28 Mar 2016 15:53:17 +0200 (CEST) Date: Mon, 28 Mar 2016 15:53:20 +0200 Message-ID: <87egauogj3.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Denis Ovsienko In-Reply-To: <153bd669f46.e5f7f9bf1515.6305608076425038357@ovsienko.info> References: <153bd669f46.e5f7f9bf1515.6305608076425038357@ovsienko.info> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 28 Mar 2016 15:53:23 +0200 (CEST) X-Miltered: at korolev with ID 56F93753.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 56F93753.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 : 56F93753.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] In-depth look @ Babel towards PS ... X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 13:53:27 -0000 > if anybody considers some document(s) meaningful for this BoF discussion > [...] mention such documents on the mailing list Seconded. Here's my current reading list for the plane, further suggestions welcome: - details of the IS-IS packet format (Gredler?); - DVMRP (RFC 1075, anything else?); - RFC 7298 (I'm a little rusty); - ??? -- Juliusz From nobody Mon Mar 28 06:57:55 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D557212D93C for ; Mon, 28 Mar 2016 06:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wzVu-qbP1tg for ; Mon, 28 Mar 2016 06:57:53 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (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 DDEEB12D920 for ; Mon, 28 Mar 2016 06:57:52 -0700 (PDT) Received: by mail-ob0-x22a.google.com with SMTP id x3so30834421obt.0 for ; Mon, 28 Mar 2016 06:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=iz8dOEWEnINQwIvZIGDyklQKMLOAr6ju9BXofl3dsOk=; b=Rz7ybegOoJYod5KO1cgmwMprlgda91Ngw5cDFkwc+70MUyJM5GiRijhRlQ+H+REANZ O6cvFHma53xICcP5LQKcmZCB8fi09QGMEikkepxGgTpIQ9ze5vmsbGrVCeUBWNDiI8Vj ROzj8Tbp7GrxpKTMmn1XuU1VoCuXsPEN5HNTSexwc1WSkVvNHu5OWMqDCmVGEK8kZ5Oo G5nHVnpV8Er5cpZuyoSDYjF9BDL/QjtaP4/2U0NoQ/V84KmxnAf1DawgDI41/ngw47O6 mhCPhj9UCrtE/Vi1TeBUPEn73k2Utkp6JQqS8XfNOeDMmnEjXyh8BJPcEIWjFvMFzgG1 Z2qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=iz8dOEWEnINQwIvZIGDyklQKMLOAr6ju9BXofl3dsOk=; b=XY9l4hTMbARdLiD/XDav/mwaTnriV5k92p0hYPJ/TBnAXvxcP6WJzDWvoQGG8zRxew 7zLiDVzp3VQQgHNBN+QBHR3lSPePTwEpo+e7NXdOOz4IENw1zlXQMKdieXxeq66t83M8 B6uRif8yTFr7N7BgP3rr84QP6I6+zyI9zMeBfq75ie2XodBeVvN9xHBM8bFSXzMaIS8Y ZQxPzvVLQEfukhkgyAz1DArplvXjNghr5FxixapT8G8a6m9IJ/yT8ou4Apx5kLYuuVck ITtQRmjDpKTVIcNrsEh2RbEaOLI/L/ms8NhnSiGJUWCDYd4+sbFjIyaCmKT8kK3qP+wS ntdw== X-Gm-Message-State: AD7BkJJ3C9iX1Q5fd915qzh2jIf3/dqWO3B6vTf4H7DHAmvfALTiVaX67BgJyQp9ik0xe/I9R8y5TiNz0CqdlQ== MIME-Version: 1.0 X-Received: by 10.60.39.194 with SMTP id r2mr12497890oek.69.1459173472319; Mon, 28 Mar 2016 06:57:52 -0700 (PDT) Received: by 10.202.168.129 with HTTP; Mon, 28 Mar 2016 06:57:52 -0700 (PDT) In-Reply-To: <87egauogj3.wl-jch@pps.univ-paris-diderot.fr> References: <153bd669f46.e5f7f9bf1515.6305608076425038357@ovsienko.info> <87egauogj3.wl-jch@pps.univ-paris-diderot.fr> Date: Mon, 28 Mar 2016 06:57:52 -0700 Message-ID: From: Dave Taht To: Juliusz Chroboczek Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Denis Ovsienko , babel@ietf.org Subject: Re: [babel] In-depth look @ Babel towards PS ... X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 13:57:55 -0000 On Mon, Mar 28, 2016 at 6:53 AM, Juliusz Chroboczek wrote: >> if anybody considers some document(s) meaningful for this BoF discussion >> [...] mention such documents on the mailing list > > Seconded. > > Here's my current reading list for the plane, further suggestions welcome: > > - details of the IS-IS packet format (Gredler?); > - DVMRP (RFC 1075, anything else?); > - RFC 7298 (I'm a little rusty); > - ??? bgp-pgp rfc3971 > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Mon Mar 28 07:11:47 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A62212D93C for ; Mon, 28 Mar 2016 07:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FBn_z1ROKwo for ; Mon, 28 Mar 2016 07:11:44 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C95E312D9BE for ; Mon, 28 Mar 2016 07:10:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 7C6891C0D94; Mon, 28 Mar 2016 07:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1459174233; bh=JwW//AG0OVnkKZnxw+fNCZCEfV4BhZEV59n9QWzlAHM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=odQY2S7wjeJXVvle2QTqan22rN0QnbxMDc4BzdNdMkD1KR4jM3xgCikDyBvWDUcBp rmqWdz/iBjCkCgOxSy/vV7lKKJbz0m0qicb6RJUbJy47+n2DYfjVGoHt3Mq0yQjGJ/ +xDTHEeSQ/mnQlO2+FUAw1UzPcwoxljvjwf1hG+Q= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D5B014E023C; Mon, 28 Mar 2016 07:10:32 -0700 (PDT) To: Dave Taht , Juliusz Chroboczek References: <153bd669f46.e5f7f9bf1515.6305608076425038357@ovsienko.info> <87egauogj3.wl-jch@pps.univ-paris-diderot.fr> From: "Joel M. Halpern" Message-ID: <56F93B52.6000901@joelhalpern.com> Date: Mon, 28 Mar 2016 10:10:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Denis Ovsienko , babel@ietf.org Subject: Re: [babel] In-depth look @ Babel towards PS ... X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 14:11:46 -0000 I must be missing something. What is the relevance of SEND (RFC 3971, Secure Neighbor Discovery) to Babel? Also, as anyone actually rolled out SEND in operation? Yours, Joel On 3/28/16 9:57 AM, Dave Taht wrote: > On Mon, Mar 28, 2016 at 6:53 AM, Juliusz Chroboczek > wrote: >>> if anybody considers some document(s) meaningful for this BoF discussion >>> [...] mention such documents on the mailing list >> >> Seconded. >> >> Here's my current reading list for the plane, further suggestions welcome: >> >> - details of the IS-IS packet format (Gredler?); >> - DVMRP (RFC 1075, anything else?); >> - RFC 7298 (I'm a little rusty); >> - ??? > > bgp-pgp > > rfc3971 > >> >> -- Juliusz >> >> _______________________________________________ >> babel mailing list >> babel@ietf.org >> https://www.ietf.org/mailman/listinfo/babel > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > From nobody Mon Mar 28 07:17:26 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A3712DA12 for ; Mon, 28 Mar 2016 07:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6G7Ymv0ysqV4 for ; Mon, 28 Mar 2016 07:17:23 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D08F12D9A9 for ; Mon, 28 Mar 2016 07:15:20 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id h6so115770085oia.2 for ; Mon, 28 Mar 2016 07:15: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:date:message-id:subject:from:to :cc; bh=rPL2V7xdQjErzh6L/tJEK0EOOHSqk1a1qL3cHFIoWmQ=; b=tRa3agyOUCMDyhLCUgtQbiy2zJa88Ss7pqX+5GNvW3itggqxq10dp01+BmiCMBoyJR Cno/h+JtTB859acHVADYHaKX/YHPDaiXJRztj2RJ9jVNjDJEjSDIpecAPvbCGASzh2Lg SjdjtBS3URAJsC+C5Eq7b/niyG2U/e2x4dY3nC69tQn9VESO5cocXHVYk6PJD6uQbEnc jed+EuQyfoRh9908AiG3q5yea54qUiVzRhSXKBGHUeZeYEP1XOZE2jCeg2pyE9GvRYrG HtK2kEiclj/24wTSq/me0qyLpbmoZPCPk3nerzte2E/VIxF1B1/Nw+KQ+y2zhJpyrK4j mhAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=rPL2V7xdQjErzh6L/tJEK0EOOHSqk1a1qL3cHFIoWmQ=; b=lJDZbNlhlMmo+Fmgy2lTbSL4FnwlwWpmNd5l5usUUNSv+KpnhjscngAzgmi/o3HZii gpX7rgx25f090Aq1Kgmls0cCK4Lf3C461XuWjzbkzRZ+NoBHj4HdcUnrKWwpxrLQ0dbv 1jTVqFjiBg93esqvtosdQ5gXOSzQDeHOMeveU/wO+wBvEjueJ2xTm40xTQjLUlMJ92Ci PtCJR7+OfLRde+XycqXrnhbmK9X7EeSt+gFWcUr3IUNv1graURnNg3DSdzwBAiK5WQYn CZGyVa9FetqRlCfCT2H5iTSjhkqZFofJVltPXOZfKM1eyqe64tMNF+hp0NMgREPzpIc2 mPCw== X-Gm-Message-State: AD7BkJJnddhG/yS/JGqfoqozW9HcUy8ygYIRy/dxm0FNXAsogyXM4qb35lkVWKqBoiLRcQ5+l0qR2SZrOGCOaw== MIME-Version: 1.0 X-Received: by 10.157.5.7 with SMTP id 7mr2985456otw.127.1459174465666; Mon, 28 Mar 2016 07:14:25 -0700 (PDT) Received: by 10.202.168.129 with HTTP; Mon, 28 Mar 2016 07:14:25 -0700 (PDT) In-Reply-To: <56F93B52.6000901@joelhalpern.com> References: <153bd669f46.e5f7f9bf1515.6305608076425038357@ovsienko.info> <87egauogj3.wl-jch@pps.univ-paris-diderot.fr> <56F93B52.6000901@joelhalpern.com> Date: Mon, 28 Mar 2016 07:14:25 -0700 Message-ID: From: Dave Taht To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Denis Ovsienko , babel@ietf.org, Juliusz Chroboczek Subject: Re: [babel] In-depth look @ Babel towards PS ... X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 14:17:25 -0000 On Mon, Mar 28, 2016 at 7:10 AM, Joel M. Halpern wrote: > I must be missing something. What is the relevance of SEND (RFC 3971, > Secure Neighbor Discovery) to Babel? > Also, as anyone actually rolled out SEND in operation? It is a very good example of a failure to deploy, yes, a good learning experience. Given that arp, and nd, and ra, still have problems in these regards, and that things like bgp-pgp also have issues, and there are other major issues with these problems in other in-home protocols (dnssec, mdns, upnp, pcp), what's one more insecure protocol going to do to us? /me ducks > > Yours, > Joel > > > On 3/28/16 9:57 AM, Dave Taht wrote: >> >> On Mon, Mar 28, 2016 at 6:53 AM, Juliusz Chroboczek >> wrote: >>>> >>>> if anybody considers some document(s) meaningful for this BoF discussion >>>> [...] mention such documents on the mailing list >>> >>> >>> Seconded. >>> >>> Here's my current reading list for the plane, further suggestions >>> welcome: >>> >>> - details of the IS-IS packet format (Gredler?); >>> - DVMRP (RFC 1075, anything else?); >>> - RFC 7298 (I'm a little rusty); >>> - ??? >> >> >> bgp-pgp >> >> rfc3971 >> >>> >>> -- Juliusz >>> >>> _______________________________________________ >>> babel mailing list >>> babel@ietf.org >>> https://www.ietf.org/mailman/listinfo/babel >> >> >> _______________________________________________ >> babel mailing list >> babel@ietf.org >> https://www.ietf.org/mailman/listinfo/babel >> > From nobody Thu Mar 31 15:13:21 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F66212D0BF for ; Thu, 31 Mar 2016 15:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLowGwVyGuPj for ; Thu, 31 Mar 2016 15:13:19 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C01F12D1B0 for ; Thu, 31 Mar 2016 15:13:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id D7277D59457 for ; Thu, 31 Mar 2016 15:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1459462398; bh=gCBdWGx0hUG93qCFwcv/9YermeReqkYx2hsPc3fbzrg=; h=To:From:Subject:Date:From; b=qXKrOjr3bon1aeZqG7491xmsKR70SaO5NsZnXEoUY7EbN+GxxKVduE1eXJahM9i/C kfJUfUvxRNzKOuOruu2x7AGuulhxO+90uN95dPVeHZjBqbKWbbHpNaj2mDfk1ErX+j bxw1DESNM3RDOa4XH9Ye+LAVZhCCOfPHnJ1hkOQ4= X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 76010D407AA for ; Thu, 31 Mar 2016 15:13:18 -0700 (PDT) To: Babel at IETF From: "Joel M. Halpern" Message-ID: <56FDA0FA.3000405@joelhalpern.com> Date: Thu, 31 Mar 2016 18:13:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [babel] BoF prep, please X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 22:13:20 -0000 Speakers, the chairs (Tony and me) need your slides. We need to upload them so folks can get them from the repository. I recommend PDF. It is quite acceptable to talk without slides. But we will be upset if you show up at the last minute, with slides that have not been uploaded. Yours, Joel From nobody Thu Mar 31 15:17:09 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2AF12D1AA for ; Thu, 31 Mar 2016 15:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-j36SJBeXMF for ; Thu, 31 Mar 2016 15:17:06 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 E2B9712D511 for ; Thu, 31 Mar 2016 15:17:05 -0700 (PDT) Received: by mail-ig0-x232.google.com with SMTP id nk17so212511igb.1 for ; Thu, 31 Mar 2016 15:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=m0KoifDX5TpbuRQDxy6SXIo9y2WuoRvqHU62yOZIJZo=; b=JloqbRciRTjr+6V/CTZaXXkfrZYKV61G70RVAEXU53OQNYcvwIY9Z5LVU4P4VzXcfN F97sWYzD0AZAALqmRjc3kPm1Lx43/doW5BuwUH6bpHd7KKx5yHVLlQl+UxvcBApla6tm eBu68wlM0Cye3O91/modEo6m3szXCIyblfN25MDgKq6/VSlczRb3iJkRAbmWnOQnVfTl QkzK8le+BHHrk0jrSOG+vY+OgolYBn9LyxxWx2ZsYg/B7daFw74MtT0vmQNCKnRaCQt6 nhFy2PIEJE3PkW523FLPqIRN2cJKkC2YNF0HS8cvzUqNWYh/YlIpaX3rDsS5EcCeGkm1 3X4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=m0KoifDX5TpbuRQDxy6SXIo9y2WuoRvqHU62yOZIJZo=; b=Lo/Nnp7jAMVyKfT8ZT+n5LzPPBSjTQHDHl43c0pmBvXY7RtX9TXK+6XiYgkFDfRkg7 BaUlXMJHBd18kRSwnNZQbRA/u9+gOYMJUgr+28LNIF4LYwWCSnzHKuoV1blhYMuLIyUT OX9tFSmCv0K1W7nYzniphm8Z7KnaPGzXZYqPtGXvrNTNjnAYcIgWFPX3gSN1b5/y7bZx b0YdM0BxH/OuW/Qlb8b3+zX8UJAVJJ9+8VBTBhrUagO4A9144IymTzaGB4Nuh4Fli36H 7MPO1MSbCMLItxET9CRvwYDXhynEamZJf7SDkx4Z/kjklxf7/f24VPvcK608zsYvBj3E 0OIw== X-Gm-Message-State: AD7BkJKjwQqs+zBCyVxXFrEyI4LROEziJypFG159v7nl61Ra3mmID0v1RD8lQRxDOSjOv/T76ORCS3768wsK/g== MIME-Version: 1.0 X-Received: by 10.50.64.179 with SMTP id p19mr56190igs.25.1459462625125; Thu, 31 Mar 2016 15:17:05 -0700 (PDT) Received: by 10.107.198.198 with HTTP; Thu, 31 Mar 2016 15:17:05 -0700 (PDT) In-Reply-To: <56FDA0FA.3000405@joelhalpern.com> References: <56FDA0FA.3000405@joelhalpern.com> Date: Thu, 31 Mar 2016 15:17:05 -0700 Message-ID: From: Tony Przygienda To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=047d7bd75cec5590d7052f5f9fdf Archived-At: Cc: Babel at IETF Subject: Re: [babel] BoF prep, please X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 22:17:08 -0000 --047d7bd75cec5590d7052f5f9fdf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable possibly even _very_ upset. enough said ... --- tony On Thu, Mar 31, 2016 at 3:13 PM, Joel M. Halpern wrote: > Speakers, the chairs (Tony and me) need your slides. We need to upload > them so folks can get them from the repository. I recommend PDF. > > It is quite acceptable to talk without slides. But we will be upset if > you show up at the last minute, with slides that have not been uploaded. > > Yours, > Joel > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --=20 *We=E2=80=99ve heard that a million monkeys at a million keyboards could pr= oduce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.* =E2=80=94Robert Wilensky --047d7bd75cec5590d7052f5f9fdf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
possibly even _very_ upset. enough said ...=C2=A0

=
--- tony=C2=A0

On Thu, Mar 31, 2016 at 3:13 PM, Joel M. Halpern <jmh@joel= halpern.com> wrote:
Speaker= s, the chairs (Tony and me) need your slides.=C2=A0 We need to upload them = so folks can get them from the repository.=C2=A0 I recommend PDF.

It is quite acceptable to talk without slides.=C2=A0 But we will be upset i= f you show up at the last minute, with slides that have not been uploaded.<= br>
Yours,
Joel

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



--
We=E2=80=99ve heard that a mi= llion monkeys at a million keyboards could produce the complete works of Sh= akespeare; now, thanks to the Internet, we know that is not true.
=E2=80=94Robert Wilensky
--047d7bd75cec5590d7052f5f9fdf-- From nobody Thu Mar 31 15:48:12 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CE212D8D9 for ; Thu, 31 Mar 2016 15:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iagpp2_DReJm for ; Thu, 31 Mar 2016 15:48:09 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCA4D12D8BD for ; Thu, 31 Mar 2016 15:48:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id B2556D5B32F for ; Thu, 31 Mar 2016 15:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1459464489; bh=yfWaIircoI65b2qVcOWqKVNBuiAbeZedL3aoXZbpHEg=; h=To:From:Subject:Date:From; b=blmSAnQA5ItONBT/GJZSIh59ICalvS+CXafcp8c+HAsuONpRiE3gPqMZedlrRXm9R mFsSRoV8SHRrYO+3QRH6kzsE95vj17GPfhB6LbJuJAMe7K+CfRwLB9wqpyReg8evda ec6CpP949qRtoZY82ZRUhUKwLWR0GB5Mq7w3l8Uk= X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 4D8F5D5B325 for ; Thu, 31 Mar 2016 15:48:09 -0700 (PDT) To: Babel at IETF From: "Joel M. Halpern" Message-ID: <56FDA925.2000404@joelhalpern.com> Date: Thu, 31 Mar 2016 18:48:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [babel] Note Taker? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 22:48:11 -0000 In order to conduct the BoF, we will need a note taker. The job is NOT to capture every word spoken. Nor is it to capture what is on the slides. Folks can look at those. THe job is to capture what the topics were (so that the right slides can be examined, and important points that were raised. In particular, during the charter discussion, any agreements in the room to make changes will need to be captured in the minutes so Tony and I can make sure that the changes get made (assuming that the email list agrees with the room.) Can someone please commit to doing this. It will make starting the meeting much smoother. Thank you, Joel and Tony