From nobody Sun Jan 1 08:00:14 2017 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 BBC081293F2 for ; Sun, 1 Jan 2017 08:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lcMYJLv3FBC for ; Sun, 1 Jan 2017 08:00:11 -0800 (PST) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) (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 2546F129480 for ; Sun, 1 Jan 2017 08:00:10 -0800 (PST) Received: from trurl.irif.fr (unknown [IPv6:2a01:e35:2e12:c380:4d7d:3015:8f54:1fc9]) by smtp3-g21.free.fr (Postfix) with ESMTPS id A28C713F8C0 for ; Sun, 1 Jan 2017 17:00:06 +0100 (CET) Date: Sun, 01 Jan 2017 17:00:10 +0100 Message-ID: <8760ly4vp1.wl-jch@irif.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 Archived-At: Subject: [babel] What's up with draft-ietf-babel-applicability? 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, 01 Jan 2017 16:00:13 -0000 Dear chairs, dear all, I'm wondering what's supposed to happen with draft-ietf-babel-applicability. This document is in-charter, and while it's almost a year old, it remains a fairly accurate description of Babel's areas of applicability. Do people think anything needs to be done with it, should it be submitted for publication, or should it just be left to simmer until rfc6126-bis is ready? -- Juliusz From nobody Sun Jan 1 21:13:24 2017 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 EC9EF129567 for ; Sun, 1 Jan 2017 21:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_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 MEnayieqjVMH for ; Sun, 1 Jan 2017 21:13:21 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 194BC129556 for ; Sun, 1 Jan 2017 21:13:21 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id x2so271104388itf.1 for ; Sun, 01 Jan 2017 21:13:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IskGkoVHfgOx94KMOzPLLPDj+HBcQ188vlmNfZrFZsY=; b=gJFEVu5PnX/2b4dssUaKGRidYMSAsirFG4tE0hQks345v/eU+YfRFCzlSVn9uD/dA1 wnN9+HSRCt8YhKCJKw3fztgMQDQP6PuyPZLputws+3k7z8itzrSNZdreA/81NNIR0fVa fqw0SPQlbUNk9ZeeKCXG7lX/o1lRgEj8j4dhCO7nQI44a4JJnEiDvVfQ4k4lTZM50Yp2 U3gGhfMIzpLfB0A/xl+l3ku09suFTLBS6pooNpJrImsetO8wJiRHIsFKHb5Rb5cwvllT 7UasG7ZetH8k7y2hef6rek86PkUcA6YkOGUIkO/fwzwaQcSZ9pLc06fro8ShVoiNX6jG AIfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IskGkoVHfgOx94KMOzPLLPDj+HBcQ188vlmNfZrFZsY=; b=J9/mKdUco49GeQf+jYqIkZZyRRp35N8WhviUpguOVr3FRjQqk6VwX8YsrucSa9W1Sq NR+BUGOplPcGGGPwllP/4cQX/RXjdG65X7WyxX1/I8IaZtE/ILcpJS6wE6BEPohg/+mv 9D7b+hGWLrLXOa2knMNzLZpJ+6Z2SmukRv1BKWg174C8iNiF5QYu7y21HqZhDi9NyElb 6rKmCAvwDJI68oRgUQMzVsgZUNJduJ4eua8JGPJBAW44/yRMFQInssJSsV1j2mcGgxef Wl6bbxROGqaOSGSklgdkeVn4k51u6LfneulVcIQ4b2BzwlXox/L72UzDDkqFOeO92dhG t0qw== X-Gm-Message-State: AIkVDXJxuQyzJTG+/cnIcTNrn8SeV6JA6x5W/tzqD+2KIhYuUEmMsBBq9VZwofyYiJ5FLrK9pBewRWNahu2M+g== X-Received: by 10.36.33.151 with SMTP id e145mr42055890ita.14.1483334000284; Sun, 01 Jan 2017 21:13:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.136 with HTTP; Sun, 1 Jan 2017 21:13:04 -0800 (PST) In-Reply-To: <8760ly4vp1.wl-jch@irif.fr> References: <8760ly4vp1.wl-jch@irif.fr> From: Donald Eastlake Date: Mon, 2 Jan 2017 00:13:04 -0500 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Babel at IETF Subject: Re: [babel] What's up with draft-ietf-babel-applicability? 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, 02 Jan 2017 05:13:23 -0000 Hi Juliusz, If the draft is ready, normally the next step would be a two week Working Group Last Call. However, I notice that it is expiring soon so a new version need to be uploaded in any case and the nits checker indicates some glitches (https://tools.ietf.org/tools/idnits/). So I suspect the thing is to post a minor revision and then initiate the WG LC. I'll post some suggested changes tomorrow. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Sun, Jan 1, 2017 at 11:00 AM, Juliusz Chroboczek wrote: > Dear chairs, dear all, > > I'm wondering what's supposed to happen with draft-ietf-babel-applicability. > This document is in-charter, and while it's almost a year old, it remains > a fairly accurate description of Babel's areas of applicability. > > Do people think anything needs to be done with it, should it be submitted > for publication, or should it just be left to simmer until rfc6126-bis is > ready? > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Mon Jan 2 06:10:30 2017 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 C78801295EF for ; Mon, 2 Jan 2017 06:10:27 -0800 (PST) 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 HauwwUYL2MY3 for ; Mon, 2 Jan 2017 06:10:26 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 73A0A1295FB for ; Mon, 2 Jan 2017 06:10:26 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id d45so219602203qta.1 for ; Mon, 02 Jan 2017 06:10:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mT4DoJ7HuRqmf5dveeRef3SSoc02csq01B2qHlfXtyQ=; b=S9LXbzaPbHK4Yq1/rmxhZBOI4k21mRAsaB6XAJlLwZDO1uNDWi0GmNZ10LqKWmgHgk lIClAMTbOEiZ86chvNzjgNyyqCiBNl1GPp21FEevGo+pCG306pbjElGdH0vYrdvGx/jv /Dnwvoj+yLbgr7CgwWjfohH1sBtkGEd0CDSQM6pA4MXPZ9tClpvNBPej5IAesuVilyFs W36aWT8nOp9GNtKqjmITyJuk9scbFqoTa7YKmmX8OXRdA+DZF1FmQsEhZMeUySCFJKUq TSfIxp9vARD4Ymq+spuJsaS4mOJZyzaUmpu3zcQrjaUHv2lZWRoeTXpdtOi4TlcUvVSj KJjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mT4DoJ7HuRqmf5dveeRef3SSoc02csq01B2qHlfXtyQ=; b=cwHKIbykH3NowVkgcSlDy8w3s3pXtdVhm5KB6CrBJpCvlUX+ZMhDSD7liIraWFWSLG 6OSFaRmZFcI1CWGxBlB/0Snc/SPqH3N73MCU2c6a7gAOq8CIf8jW3JFEdqmLhWT+OoVg g/u0xceuEBtLYVfaBWrAz3kdqf+FymK2LjdOyY6EIoHBe6J1fmxPT3ACWpQWqlt5260m wYPUNHduquygwZY/znf+1d9cvuf+PE6UDEu1Jv/Bm4N207gr4uioPy0c6KhH3VJE7Hsp Y7S0NTvDwlx7Dt98rHMunrsPYwxvhUFXCO76wz2BJxFSAGJ3afbTXrjY6GG/zXLgUGX5 bQZg== X-Gm-Message-State: AIkVDXLCgDY2G7Ew2zMFbqCv+7O4Q41DJRzDr5Sol4PlfgAbQpG89peS1MtxkGLcPYjhIh9b6M4Q69tbDMubZg== X-Received: by 10.200.44.202 with SMTP id 10mr55633291qtx.156.1483366225482; Mon, 02 Jan 2017 06:10:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.152.197 with HTTP; Mon, 2 Jan 2017 06:10:25 -0800 (PST) In-Reply-To: <065ED768-44B0-4F61-BE7D-B2DE19F0611C@iki.fi> References: <4A81578C-8CA7-4FF2-BBF4-EB3F7A72FE76@apple.com> <065ED768-44B0-4F61-BE7D-B2DE19F0611C@iki.fi> From: Dave Taht Date: Mon, 2 Jan 2017 06:10:25 -0800 Message-ID: To: Markus Stenberg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: David Schinazi , Babel at IETF , "babel-users@lists.alioth.debian.org" Subject: Re: [babel] [Babel-users] some thoughts towards babel-1.9 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, 02 Jan 2017 14:10:28 -0000 I added a todo list for my "rabel" branch of babel covering some of the stuff I'd like to try. https://raw.githubusercontent.com/dtaht/rabeld/master/todo.org From nobody Mon Jan 2 08:21:18 2017 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 668011296BF; Mon, 2 Jan 2017 08:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 Z2xAVZdanBYN; Mon, 2 Jan 2017 08:21:16 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B3331296BB; Mon, 2 Jan 2017 08:21:13 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id x2so279710688itf.1; Mon, 02 Jan 2017 08:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r7GJcjuFVYFNbMG8pO+uKX7MmxhSyTVRSuI7Vix4eMw=; b=V9w/CA+UW21B2iWkvylYRpdzXdAVZ7VdxPjY0toofRyR/UjIgAdFjeV+OLpczNK/de eNpQP7LWM7hkNTfkKngX0rV9OApFkWnPct0NxZK5879qbuP360AlLnZR8LfJ2AI6xQb2 NUDe7F2YzU6zu3VbYdKctBnVftNnOaKca/riXa8ZzBN4Hvg1JKSEIgwiTCJokPoQX86F XpkwNlK8aepoYIIIAZXE1CivZGgNxl9U4LKt9pxWXSdsvgEAh+GLSGrhwb3xdX7zRAZn AwEyNaOAMcgBpGHvZI3Klh4a2uJTtW0CAGrFztv1/N7sQHFZVKfcsq5hykd3W7U69uTx TnQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r7GJcjuFVYFNbMG8pO+uKX7MmxhSyTVRSuI7Vix4eMw=; b=IPgOjq4h6Chy7EeNQWHLK2xdyS/0w8g0UaEISvxgdRBeNogMhCZuWEX2zq+IfPbMgy AvArREcp8MsYHt5H7XDEI10ldk+bcNmYxxNYPwe8IJJMGUwS1AfYQ3bMNkz+mXC0fw71 wD9M+0EGcS88byFt4qNKnrCqCFMG0z9yohF5LQfGmVL2V5yxqlXgVIm3frvQRMjwO4YU 0uWMmkBNZCPbKBwoG7Ww5u751u23BAP2mMEMdIqkLtD3MR3wRpsxaTFDa0LS/PGSrI+l 10w+niCPJHcwwwZNI+JHv7WOWoAq14lAY1EvHpewCh1xtEicHf2+LeZ625Owq5zaFQn/ nYrA== X-Gm-Message-State: AIkVDXKCeZakqyAAuWOxemla3oqBOl+FPJdUbOCHfIKLJVys6QzK5RER2XSwQ8K7o0MbZ2vsaNz8Vck0HnWqTA== X-Received: by 10.36.37.16 with SMTP id g16mr45170112itg.7.1483374061394; Mon, 02 Jan 2017 08:21:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.136 with HTTP; Mon, 2 Jan 2017 08:20:45 -0800 (PST) In-Reply-To: <148336094080.21313.16326257529253865319.idtracker@ietfa.amsl.com> References: <148336094080.21313.16326257529253865319.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Mon, 2 Jan 2017 11:20:45 -0500 Message-ID: To: Babel at IETF Content-Type: multipart/alternative; boundary=001a114530b6ffa13105451eefca Archived-At: Cc: babel-chairs@ietf.org, Alia Atlas Subject: Re: [babel] Expiration impending: 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, 02 Jan 2017 16:21:17 -0000 --001a114530b6ffa13105451eefca Content-Type: text/plain; charset=UTF-8 Suggested changes to fix nits in this draft: All drafts must have a Security Considerations section and an IANA Considerations section. The traditional thing to put in the IANA Considerations section if there are none is: This document requires no IANA actions. RFC Editor: Please remove this section before publication. Security Considerations section could possible mention the importance of securing routing, relative hostility of different use environments, have a pointer to RFC 7298, or the like... The References need to be labeled as Informational or Normative. While you can have normative references in Informational documents, in this case it seems OK to just change the name of the References section to "Informational References". Square bracketed references are not allowed in the Abstract so "Babel [RFC6126]" needs to change to something like "Babel (see RFC 6162)". Some references need to be updated. draft-ietf-manet-olsrv2-dat-metric has been published as RFC 7779, draft-savage-eigrp has been published as RFC 7868. There are also two draft referenced by specific version number where subsequent versions have come out. I suggest just dropping the version number: draft-ietf-manet-aodvv2-13 and draft-clausen-lln-loadng-14. I'll check with my co-chair but I think with the above minor fixed, we could probably do a WG Last Call on a revision of the draft. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Mon, Jan 2, 2017 at 7:42 AM, IETF Secretariat < ietf-secretariat-reply@ietf.org> wrote: > The following draft will expire soon: > > Name: draft-ietf-babel-applicability > Title: Applicability of the Babel routing protocol > State: I-D Exists > Expires: 2017-01-09 (in 6 days, 19 hours) > > --001a114530b6ffa13105451eefca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Suggested changes to fix nits in this draft:

All drafts must have a Security Considerations section and an IANA Co= nsiderations section. The traditional thing to put in the IANA Consideratio= ns section if there are none is:

This document requires= no IANA actions. RFC Editor: Please remove this section before publication= .

Security Considerations section cou= ld possible mention the importance of securing routing, relative hostility = of different use environments, have a pointer to RFC 7298, or the like...

The References need to be labeled as Informational = or Normative. While you can have normative references in Informational docu= ments, in this case it seems OK to just change the name of the References s= ection to "Informational References".

Sq= uare bracketed references are not allowed in the Abstract so "Babel [R= FC6126]" needs to change to something like "Babel (see RFC 6162)&= quot;.

Some references need to be updated. draft-ietf-manet-olsrv2-dat-= metric has been published as RFC 7779, draft-savage-eigrp has been published as RFC 7868.= There are also two draft referenced by specific version number where subse= quent versions have come out. I suggest just dropping the version number: <= /span>draft-ietf-mane= t-aodvv2-13 and draft-clausen-lln-loadng-14.

I'll check wit= h my co-chair but I think with the above minor fixed, we could probably do = a WG Last Call on a revision of the draft.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E= . Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Mi= lford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

On Mon, Jan 2, 2017 at 7:42 AM, IETF Secreta= riat <ietf-secretariat-reply@ietf.org> wrote:<= br>
The following draft will expire soon:

Name:=C2=A0 =C2=A0 =C2=A0draft-ietf-babel-applicability
Title:=C2=A0 =C2=A0 Applicability of the Babel routing protocol
State:=C2=A0 =C2=A0 I-D Exists
Expires:=C2=A0 2017-01-09 (in 6=C2=A0days, 19=C2=A0hours)


--001a114530b6ffa13105451eefca-- From nobody Mon Jan 2 08:24:52 2017 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 4C3AA1296BE; Mon, 2 Jan 2017 08:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=messagingengine.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 TXdeYRyesRu5; Mon, 2 Jan 2017 08:24:48 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE05A1296BB; Mon, 2 Jan 2017 08:24:47 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 18DA6207CA; Mon, 2 Jan 2017 11:24:47 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Mon, 02 Jan 2017 11:24:47 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=lkhv4r5UBoNqzPnlaWIQKjpC98M=; b=c9P8j9fQvJpIk1eJ7dYz s2lPIQO89d3bYfMTMrxvRPWeE+Y3p3e81cvTRmsZMihcFeglCsNbUt0/P8ot/dW5 QliZWv4LwUf+FdI7nzxUlUKW7M++dfJsgjbcMTwdsaqxtteskXpxGCB3StiURf/8 V1CefH0jGyGU+SsWqP2QB4E= X-ME-Sender: X-Sasl-enc: V9filSmouRm7YejdNQsT/ad4fp5Lv03qtbyPLVBcIVbo 1483374286 Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net [108.78.210.25]) by mail.messagingengine.com (Postfix) with ESMTPA id 943117E709; Mon, 2 Jan 2017 11:24:46 -0500 (EST) From: "Russ White" To: "'Donald Eastlake'" , "'Babel at IETF'" References: <148336094080.21313.16326257529253865319.idtracker@ietfa.amsl.com> In-Reply-To: Date: Mon, 2 Jan 2017 11:24:46 -0500 Message-ID: <013e01d26514$bbbf3f70$333dbe50$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH8Es8VKRF2mHO3fTAgkpyJplI0zALlq/fToLrWVkA= Content-Language: en-us Archived-At: Cc: babel-chairs@ietf.org, 'Alia Atlas' Subject: Re: [babel] Expiration impending: 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, 02 Jan 2017 16:24:50 -0000 > I'll check with my co-chair but I think with the above minor fixed, we = could > probably do a WG Last Call on a revision of the draft. I would agree.=20 :-) Russ From nobody Mon Jan 2 08:45:15 2017 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 B28521296C5 for ; Mon, 2 Jan 2017 08:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 cjSNEbszCvWf for ; Mon, 2 Jan 2017 08:45:13 -0800 (PST) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A602C1296C4 for ; Mon, 2 Jan 2017 08:45:13 -0800 (PST) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1483375512709482.7399743764481; Mon, 2 Jan 2017 08:45:12 -0800 (PST) Date: Mon, 02 Jan 2017 16:45:12 +0000 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <15960120c7f.112eefdc011843.5788899878514189763@ovsienko.info> In-Reply-To: <87fulrcrxl.wl-jch@irif.fr> References: <158f03caa17.f99ff21138897.6561785689073232467@ovsienko.info> <7ishpt13xr.wl-jch@irif.fr> <158f5953e89.b7dbea434613.4022202347829091640@ovsienko.info> <87fulrcrxl.wl-jch@irif.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] [PATCH 2/4] address IETF-97 slides section I point 2 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, 02 Jan 2017 16:45:14 -0000 ---- On Tue, 13 Dec 2016 23:47:34 +0000 Juliusz Chroboczek wrote ---- >> If all is fine, the specification should say that an Update TLV may be >> processed in this specific way in the absence of a normal 2-way >> neighbour. > >Does the spec not already say that? I don't see any place where it would >say that updates from non-bidirectional neighbours, or even from >non-neighbours, are dropped. > >To the contrary, what the spec fails to make clear is that it is legal to >drop updates before bidirectional reachability has been ascertained. I'm >not sure that this is worth clarifying more -- none of the three >independent reimplementations had trouble with this particular bit. > >Denis, you haven't replied to my question: what problem with the basic >protocol are you trying to solve? The normative text in 6126-bis does not define the protocol instance behaviour in terms of a finite state machine (FSM). This is not a problem in itself, just a fact. Why it matters is because for network protocols FSMs are a good common ground between the specification and the implementation. In RFC 2328 (OSPF version 2) Sections 9 (The Interface Data Structure) and 10 (The Neighbor Data Structure) use FSMs extensively to define the protocol instance. For example: * the graphs in Figures 11 and 12 summarize the text concerned (even though one can eventually derive everything from the text) * Section 10.4 (Whether to become adjacent) explicitly confirms that bidirectional communication as a requirement for adjacency * Section 10.6 (Receiving Database Description Packets) tells how to process a packet based on the neighbour state (And so on, about 40 pages in those two sections altogether.) RFC 4271 (BGP-4) Section 8 (BGP FSM) exists for a reason too, makes similar definitions and takes 38 pages. In particular, it explicitly states that an UPDATE message requires the peer to be in the Established state (one time in the middle of Section 8.2.2, another time at the beginning of Section 9 and probably elsewhere). It is obvious, trivial, expected, but the document states and re-states it explicitly and this is a right thing to do. Trying to reconstruct the FSM that the 6126-bis normative text implies helps to see the problem. One problem is that some parts of the spec seem to be closed whereas they are open. By "closed" I mean, for instance, OSPF LS type in RFC 2328, handling of which is explicitly summarized in Section 13: (2) Examine the LSA's LS type. If the LS type is unknown, discard the LSA and get the next one from the Link State Update Packet. This specification defines LS types 1-5 (see Section 4.3). By "open" I mean, for instance, BGP path attributes in RFC 4271 Section 5, which defines 4 categories and states: In addition to well-known attributes, each path MAY contain one or more optional attributes. It is not required or expected that all BGP implementations support all optional attributes. (And so on.) Generally speaking about protocols, neither of the two is good or bad in itself, the difference is where to draw the line at the design time. Once the line has been drawn, wherever that is, it is important to keep it clearly understood by all parties. In particular, if a specific part of the protocol is open, this fact needs to be acknowledged and interoperability between extensions explained. This is goind to be a Standard Track document after all. Back to 6126-bis particulars, when the document describes a bidirectional detection mechanism, it is easy for the reader to presume that its purpose is to guard the routing part of the protocol instance, in other word, that this part is closed. This used to be my own impression for a long time. Given that this dependency actualy exists in other protocols (not just OSPF and BGP as illustrated above) and does the job, a reasonable default could be to have it in place too. That's why slide 6 is titled "Should it be like this?" as that is the first clarification that naturally came to my mind. Whether we have or don't have a consensus on the exact way to reduce the ambiguity, it seems wrong to me to leave the document as it is now. The changes I suggested are on the list, would you like to suggest something too? Thank you. -- Denis Ovsienko From nobody Mon Jan 2 15:33:42 2017 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 475D7129957; Mon, 2 Jan 2017 15:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBXR2RswuTIh; Mon, 2 Jan 2017 15:33:39 -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 AF146129958; Mon, 2 Jan 2017 15:33:38 -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 v02NXaK6025863; Tue, 3 Jan 2017 00:33:36 +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 04275D7950; Tue, 3 Jan 2017 00:33:36 +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 PBPtpVrdTMns; Tue, 3 Jan 2017 00:33:33 +0100 (CET) Received: from trurl.irif.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6FA12D788F; Tue, 3 Jan 2017 00:33:32 +0100 (CET) Date: Tue, 03 Jan 2017 00:33:38 +0100 Message-ID: <87r34lca0d.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake In-Reply-To: References: <148336094080.21313.16326257529253865319.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 03 Jan 2017 00:33:36 +0100 (CET) X-Miltered: at korolev with ID 586AE350.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 586AE350.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 : 586AE350.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-chairs@ietf.org, Babel at IETF Subject: Re: [babel] Expiration impending: 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, 02 Jan 2017 23:33:41 -0000 Thanks for the detailed comments, Donald. Will get down to work ASAP. -- Juliusz From nobody Mon Jan 2 16:05:12 2017 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 6409512998F for ; Mon, 2 Jan 2017 16:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgMMlwhnNq0M for ; Mon, 2 Jan 2017 16:05:09 -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 49F88129421 for ; Mon, 2 Jan 2017 16:05:09 -0800 (PST) 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 v030577q015821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Jan 2017 01:05:07 +0100 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 v03056B3007356; Tue, 3 Jan 2017 01:05:06 +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 AB864D7950; Tue, 3 Jan 2017 01:05:06 +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 sS9dZRLLmM3o; Tue, 3 Jan 2017 01:05:05 +0100 (CET) Received: from trurl.irif.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9A5BCD788F; Tue, 3 Jan 2017 01:05:05 +0100 (CET) Date: Tue, 03 Jan 2017 01:05:11 +0100 Message-ID: <87mvf9c8js.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake In-Reply-To: References: <148336094080.21313.16326257529253865319.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 03 Jan 2017 01:05:07 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 03 Jan 2017 01:05:07 +0100 (CET) X-Miltered: at korolev with ID 586AEAB3.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 586AEAB2.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 586AEAB3.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 586AEAB2.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 : 586AEAB3.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 586AEAB2.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 at IETF Subject: Re: [babel] Expiration impending: 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, 03 Jan 2017 00:05:10 -0000 > Security Considerations section could possible mention the importance of > securing routing, relative hostility of different use environments, have a > pointer to RFC 7298, or the like...
As in all distance-vector routing protocols, a Babel speaker receives reachability information from its neighbours, which by default is trusted. A number of attacks are possible if this information is not suitably protected, either by a lower-layer mechanism or by an extension to the protocol itself (e.g. ). Implementors and deployers must be aware of the insecure nature of the base protocol, and must take suitable measures to ensure that the protocol is deployed as securely as required by the application. I've just pushed my changes to Github. I'll sleep over it, do some proof-reading tomorrow, and if there are no further nits on the list, I'll submit version -01. -- Juliusz From nobody Mon Jan 2 16:30:22 2017 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 D1167129513 for ; Mon, 2 Jan 2017 16:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EO6qBFSR6SlK for ; Mon, 2 Jan 2017 16:30:20 -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 A4808127735 for ; Mon, 2 Jan 2017 16:30:19 -0800 (PST) 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 v030UIRs000951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 3 Jan 2017 01:30:18 +0100 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 v030UIDR009499 for ; Tue, 3 Jan 2017 01:30:18 +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 0435FD7950 for ; Tue, 3 Jan 2017 01:30:18 +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 738HE7Nd2Nla for ; Tue, 3 Jan 2017 01:30:15 +0100 (CET) Received: from trurl.irif.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0CBF8D788F for ; Tue, 3 Jan 2017 01:30:14 +0100 (CET) Date: Tue, 03 Jan 2017 01:30:21 +0100 Message-ID: <87inpxc7du.wl-jch@irif.fr> From: Juliusz Chroboczek To: Babel at IETF 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]); Tue, 03 Jan 2017 01:30:18 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 03 Jan 2017 01:30:18 +0100 (CET) X-Miltered: at korolev with ID 586AF09A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 586AF09A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 586AF09A.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 586AF09A.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 : 586AF09A.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 586AF09A.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Security Considerations for Babel 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, 03 Jan 2017 00:30:21 -0000 While we're on the subject of Security Considerations, I'd like to remind people that I once wrote that thing: https://tools.ietf.org/html/draft-chroboczek-babel-security-considerations-00 At the time, I was feeling somewhat displeased with the deliberate obstructionism of some security experts wrt. MTI security mechanisms, so the document contains a fair amount of deliberately provocative rhethoric in Sections 1 and 4 which is not necessarily suitable for publication in an RFC. OTOH, Sections 2 and 3 contain a fair amount of useful information about the more obvious attacks on unsecured Babel. I'm happy to let this document rot in peace in the IETF archives, but I also see no reason why somebody wouldn't want to take it over in a view to getting it published. -- Juliusz From nobody Tue Jan 3 13:47:01 2017 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 1E75212978C for ; Tue, 3 Jan 2017 13:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svRx2OkUIKrY for ; Tue, 3 Jan 2017 13:46:46 -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 3F33B129759 for ; Tue, 3 Jan 2017 13:46:18 -0800 (PST) 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 v03LkHgN018445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Jan 2017 22:46:17 +0100 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 v03LkGht012667; Tue, 3 Jan 2017 22:46:16 +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 4BBE9D78B7; Tue, 3 Jan 2017 22:46:16 +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 EtEsIcwRlJQt; Tue, 3 Jan 2017 22:46:14 +0100 (CET) Received: from trurl.irif.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id BA4F0D788F; Tue, 3 Jan 2017 22:46:13 +0100 (CET) Date: Tue, 03 Jan 2017 22:46:13 +0100 Message-ID: <87vatves0q.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko In-Reply-To: <15960120c7f.112eefdc011843.5788899878514189763@ovsienko.info> References: <158f03caa17.f99ff21138897.6561785689073232467@ovsienko.info> <7ishpt13xr.wl-jch@irif.fr> <158f5953e89.b7dbea434613.4022202347829091640@ovsienko.info> <87fulrcrxl.wl-jch@irif.fr> <15960120c7f.112eefdc011843.5788899878514189763@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 [IPv6:2001:660:3301:8000::1:2]); Tue, 03 Jan 2017 22:46:17 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 03 Jan 2017 22:46:17 +0100 (CET) X-Miltered: at korolev with ID 586C1BA9.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 586C1BA8.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 586C1BA9.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 586C1BA8.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 : 586C1BA9.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 586C1BA8.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 at IETF Subject: Re: [babel] [PATCH 2/4] address IETF-97 slides section I point 2 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, 03 Jan 2017 21:46:57 -0000 > The normative text in 6126-bis does not define the protocol instance > behaviour in terms of a finite state machine (FSM). There is no FSM in Babel. Babel is described in terms of a set of conceptual data structures and a set of requirements. I do not know whether Babel can be described by an FSM, I suspect any such description would be over-specified. > In RFC 2328 (OSPF version 2) Sections 9 (The Interface Data Structure) > and 10 (The Neighbor Data Structure) use FSMs extensively to define the > protocol instance. [...] > (And so on, about 40 pages in those two sections altogether.) Right. OSPF relies crucially on the reliability of the flooding procedure, so it is quite natural that the spec spends a lot of space describing the reliability features in excruciating detail. Babel's design is very different -- Babel is designed to be robust in the presence of an unreliable protocol, and Babel's properties are preserved even in the presence of packet loss, of packet delay, and even of packets overtaking each other. I have a proof of that. > RFC 4271 (BGP-4) Section 8 (BGP FSM) exists for a reason too, makes > similar definitions and takes 38 pages. Yes, BGP relies on a reliable transport and a reliable handshake, albeit for slightly different reasons (efficiency rather than correctness). Again, these reasons do not apply to Babel, which is not designed to carry large amounts of data, and does not rely on a reliable transport. > Whether we have or don't have a consensus on the exact way to reduce the > ambiguity, it seems wrong to me to leave the document as it is now. The > changes I suggested are on the list, would you like to suggest something > too? I made a number of proposals, the last of which was in my mail dated 14 December 2016 with message-id <8737hqskff.wl-jch@irif.fr>. In short, I intend to rewrite 3.4.1 and 3.4.2 to make them stylistically more in line with the rest of the document. But that's point 3 on my todo list (point 1 is integrating the extension mechanism in the body of the document, and point 2 is fixing the treatment of bit 0x80 with unknown AEs). -- Juliusz From nobody Wed Jan 4 12:36:38 2017 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 5FF4E1295CD for ; Wed, 4 Jan 2017 12:36:37 -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 C2RwPAmpzFbI for ; Wed, 4 Jan 2017 12:36:34 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 5806B1295BB for ; Wed, 4 Jan 2017 12:36:34 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id t79so466614274wmt.0 for ; Wed, 04 Jan 2017 12:36:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=U6hDO6rBLoCq5k5aM6JHv80LwJiHBsU1G+QmVESRCzA=; b=dyOUyyFoBZK+yVHHNK51+v6eWfJNV/0ymuuS6On8sr6+dOe3wyaaf/IfRCwEIzyrG/ VoyyflBqgMKZj7U7EHavZth3RCtg9Mzpz1D7a67O19Fv0qaatmRv/+gU/JbhmhGeRCxH S99R6X94mO2ckEjN9nL5izvdjCTa/GktXGKDIzZxo3dBiChmB54M1Tf95NQxhyclAJKL NUwCKgEVR81pGQ4CaNK0LM9Pb4QiAsRaruhk0aEGJ8R/ObU48dS5ZpHG1CVap3QV+O+R LuojtvgGgJR4Cyt3nTNu446MsrCuaBRNr7CqZ+3s/cTeMpwpUhFKWozCENCglJbe2hnX Gf4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=U6hDO6rBLoCq5k5aM6JHv80LwJiHBsU1G+QmVESRCzA=; b=rbvo9pdmovodisTqNw9X9dV6BAEy+lbPFl6Evtcs3aM7aa3IsUJ6WEosyBV90Cb56v RaUSHsug6Kx+vFp43iq7edYG8K8NuBu5HDnxrr6HPujy+86DSphtjvbZeKeBecsIqpFD 5W/8uorgi0UiBzZoBI5E1n+yDj/EtW6yuqieZCjm0qtFU0Gqyr35eML/gwa+6vm8bOwo kIZhiDxp7C0m63mV/3rNijivDtnNJ/KRVGdBO8rUYqQcK3qczbGQxTQW1DjnDtnNHqqB Xi9KfzLvnZkucS3M2DcYzHGWbnUWoJYjX++2XgzxPJopTdloPHojPZCtzNAMmPIldzaP KOOw== X-Gm-Message-State: AIkVDXJtXmOGH4jqkCbsbXAapOEYPB3envFgxK3m3Fbwr8UNbD07b6V/T2//tsJvqi12cMJzA31tsTkDgZNZ7g== X-Received: by 10.28.144.70 with SMTP id s67mr55430621wmd.138.1483562192444; Wed, 04 Jan 2017 12:36:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.149.150 with HTTP; Wed, 4 Jan 2017 12:35:52 -0800 (PST) In-Reply-To: References: From: Tony Przygienda Date: Wed, 4 Jan 2017 12:35:52 -0800 Message-ID: To: Babel at IETF Content-Type: multipart/alternative; boundary=001a1146b3347ba5e605454abd93 Archived-At: Subject: Re: [babel] babel Digest, Vol 17, Issue 4 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: Wed, 04 Jan 2017 20:36:37 -0000 --001a1146b3347ba5e605454abd93 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FSM cannot "overspecify" a protocol unless you are perfectly happy with "undefined" behavior on certain transitions. The underspecification of transitions tends to hit very, very late in the game under heavy deployments resulting in hard-to-phatom non-interoperable behavior and confusing protocol "spec patches" or worst, exploits. Case in point were some TCP CLOSE corner cases (cleaned up in the mid 90's) and BGP peer establishment FSM (long denied, finally provided after many, many interesting corner cases, especially on collisions). A sure indication is proliferation of "last resort" timers on a protocol or clauses like "if anything bad happens, just reset". Descriptive language is nothing but ad-hoc extended FSM description along the lines "if THAT happens, do THIS" ... Yes, FSMs can be quite a lot of work and hence shunned for simple, hacked-up protocols ... In OSPF, it was largely a question of "style" given John is a mathematician by trade but it is my observation that long-term stable, maintainable asynchronous software with transition chains longer than 2 states is almost always religiously written with FSMs rather than switch statements and bits sprinkled around ... --- tony On Wed, Jan 4, 2017 at 12:00 PM, wrote: > Send babel mailing list submissions to > babel@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/babel > or, via email, send a message with subject or body 'help' to > babel-request@ietf.org > > You can reach the person managing the list at > babel-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of babel digest..." > > Today's Topics: > > 1. Re: [PATCH 2/4] address IETF-97 slides section I point 2 > (Juliusz Chroboczek) > > > ---------- Forwarded message ---------- > From: Juliusz Chroboczek > To: Denis Ovsienko > Cc: Babel at IETF > Date: Tue, 03 Jan 2017 22:46:13 +0100 > Subject: Re: [babel] [PATCH 2/4] address IETF-97 slides section I point 2 > > The normative text in 6126-bis does not define the protocol instance > > behaviour in terms of a finite state machine (FSM). > > There is no FSM in Babel. Babel is described in terms of a set of > conceptual data structures and a set of requirements. I do not know > whether Babel can be described by an FSM, I suspect any such description > would be over-specified. > > > In RFC 2328 (OSPF version 2) Sections 9 (The Interface Data Structure) > > and 10 (The Neighbor Data Structure) use FSMs extensively to define the > > protocol instance. > > [...] > > > (And so on, about 40 pages in those two sections altogether.) > > Right. OSPF relies crucially on the reliability of the flooding > procedure, so it is quite natural that the spec spends a lot of space > describing the reliability features in excruciating detail. Babel's > design is very different -- Babel is designed to be robust in the presenc= e > of an unreliable protocol, and Babel's properties are preserved even in > the presence of packet loss, of packet delay, and even of packets > overtaking each other. I have a proof of that. > > > RFC 4271 (BGP-4) Section 8 (BGP FSM) exists for a reason too, makes > > similar definitions and takes 38 pages. > > Yes, BGP relies on a reliable transport and a reliable handshake, albeit > for slightly different reasons (efficiency rather than correctness). > Again, these reasons do not apply to Babel, which is not designed to carr= y > large amounts of data, and does not rely on a reliable transport. > > > Whether we have or don't have a consensus on the exact way to reduce th= e > > ambiguity, it seems wrong to me to leave the document as it is now. The > > changes I suggested are on the list, would you like to suggest somethin= g > > too? > > I made a number of proposals, the last of which was in my mail dated 14 > December 2016 with message-id <8737hqskff.wl-jch@irif.fr>. In short, > I intend to rewrite 3.4.1 and 3.4.2 to make them stylistically more in > line with the rest of the document. > > But that's point 3 on my todo list (point 1 is integrating the extension > mechanism in the body of the document, and point 2 is fixing the treatmen= t > of bit 0x80 with unknown AEs). > > -- Juliusz > > > > _______________________________________________ > 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 --001a1146b3347ba5e605454abd93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FSM cannot "overspecify" a protocol unless you a= re perfectly happy with "undefined" behavior on certain transitio= ns. The underspecification of transitions tends to hit very, very late in t= he game under heavy deployments resulting in hard-to-phatom non-interoperab= le behavior and confusing protocol "spec patches" or worst, explo= its. Case in point were some TCP CLOSE corner cases (cleaned up in the mid = 90's) and BGP peer establishment FSM (long denied, finally provided aft= er many, many interesting corner cases, especially on collisions). A sure i= ndication is proliferation of "last resort" timers on a protocol = or clauses like "if anything bad happens, just reset".=C2=A0
=
Descriptive language is nothing but ad-hoc extended FSM desc= ription along the lines "if THAT happens, do THIS" ...
=
Yes, FSMs can be quite a lot of work and hence shunned for s= imple, hacked-up protocols ...=C2=A0 In OSPF, it was largely a question of = "style" given John is a mathematician by trade but it is my obser= vation that long-term stable, maintainable asynchronous software with trans= ition chains longer than 2 states is almost always religiously written with= FSMs rather than switch statements and bits sprinkled around ...=C2=A0

--- tony=C2=A0
=
On Wed, Jan 4, 2017 at 12:00 PM, <ba= bel-request@ietf.org> wrote:
babel@ietf.or= g

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/= listinfo/babel
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 babel= -request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 babel-o= wner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of babel digest..."

Today's Topics:

=C2=A0 =C2=A01. Re: [PATCH 2/4] address IETF-97 slides section I point 2 =C2=A0 =C2=A0 =C2=A0 (Juliusz Chroboczek)


---------- Forwarded message ----------
From:=C2=A0Juliusz Chrob= oczek <jch@irif.fr>
To:=C2=A0De= nis Ovsienko <denis@ovsienko.info= >
Cc:=C2=A0Babel at IETF <ba= bel@ietf.org>
Date:=C2=A0Tue, 03 Jan 2017 22:46:13 +0100
Subje= ct:=C2=A0Re: [babel] [PATCH 2/4] address IETF-97 slides section I point 2> The normative text in 6126-bis does not define the protocol instance=
> behaviour in terms of a finite state machine (FSM).

There is no FSM in Babel.=C2=A0 Babel is described in terms of a set of
conceptual data structures and a set of requirements.=C2=A0 I do not know whether Babel can be described by an FSM, I suspect any such description would be over-specified.

> In RFC 2328 (OSPF version 2) Sections 9 (The Interface Data Structure)=
> and 10 (The Neighbor Data Structure) use FSMs extensively to define th= e
> protocol instance.

[...]

> (And so on, about 40 pages in those two sections altogether.)

Right.=C2=A0 OSPF relies crucially on the reliability of the flooding
procedure, so it is quite natural that the spec spends a lot of space
describing the reliability features in excruciating detail.=C2=A0 Babel'= ;s
design is very different -- Babel is designed to be robust in the presence<= br> of an unreliable protocol, and Babel's properties are preserved even in=
the presence of packet loss, of packet delay, and even of packets
overtaking each other.=C2=A0 I have a proof of that.

> RFC 4271 (BGP-4) Section 8 (BGP FSM) exists for a reason too, makes > similar definitions and takes 38 pages.

Yes, BGP relies on a reliable transport and a reliable handshake, albeit for slightly different reasons (efficiency rather than correctness).
Again, these reasons do not apply to Babel, which is not designed to carry<= br> large amounts of data, and does not rely on a reliable transport.

> Whether we have or don't have a consensus on the exact way to redu= ce the
> ambiguity, it seems wrong to me to leave the document as it is now. Th= e
> changes I suggested are on the list, would you like to suggest somethi= ng
> too?

I made a number of proposals, the last of which was in my mail dated 14
December 2016 with message-id <8737hqskff.wl-jch@irif.fr>.=C2=A0 In short,
I intend to rewrite 3.4.1 and 3.4.2 to make them stylistically more in
line with the rest of the document.

But that's point 3 on my todo list (point 1 is integrating the extensio= n
mechanism in the body of the document, and point 2 is fixing the treatment<= br> of bit 0x80 with unknown AEs).

-- Juliusz



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




--
=
We=E2=80=99ve heard that a million monkeys at a million keyboards c= ould produce the complete works of Shakespeare; now, thanks to the Internet= , we know that is not true.
= =E2=80=94Robert Wilensky
--001a1146b3347ba5e605454abd93-- From nobody Thu Jan 5 07:01:49 2017 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B97FD12956F; Thu, 5 Jan 2017 07:01:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148362850572.20669.8150435708248392076.idtracker@ietfa.amsl.com> Date: Thu, 05 Jan 2017 07:01:45 -0800 Archived-At: Cc: babel@ietf.org Subject: [babel] I-D Action: draft-ietf-babel-applicability-01.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 15:01:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol of the IETF. Title : Applicability of the Babel routing protocol Author : Juliusz Chroboczek Filename : draft-ietf-babel-applicability-01.txt Pages : 5 Date : 2017-01-05 Abstract: This document describes some application areas where the Babel routing protocol (RFC 6126) has been found to be useful. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-applicability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-babel-applicability-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-applicability-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 5 07:27:14 2017 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 846A1129B62 for ; Thu, 5 Jan 2017 07:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vVTTatGMI6F for ; Thu, 5 Jan 2017 07:27:05 -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 8E8EB129459 for ; Thu, 5 Jan 2017 07:27:05 -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 v05FR3cp008837; Thu, 5 Jan 2017 16:27:03 +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 4BF5FD79EF; Thu, 5 Jan 2017 16:27:03 +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 moeCHwGYILrm; Thu, 5 Jan 2017 16:27:02 +0100 (CET) Received: from trurl.irif.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 4725CD79B5; Thu, 5 Jan 2017 16:26:59 +0100 (CET) Date: Thu, 05 Jan 2017 16:26:59 +0100 Message-ID: <87y3ypr0ho.wl-jch@irif.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 [194.254.61.138]); Thu, 05 Jan 2017 16:27:03 +0100 (CET) X-Miltered: at korolev with ID 586E65C7.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 586E65C7.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 : 586E65C7.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 at IETF Subject: [babel] Babel and undefined behaviour [was: babel Digest, Vol 17, Issue 4] 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, 05 Jan 2017 15:27:07 -0000 Hi Tony, good to hear from you. > FSM cannot "overspecify" a protocol unless you are perfectly happy with > "undefined" behavior on certain transitions. Yes, Babel is tolerant of undefined behaviour in many cases. Please bear with me while I lecture a little. Traditional link-state protocols are based on an algorithm that is extremely refined: their correctness crucially depends on three non-trivial properties: 1. the LSDBs are synchronised at all times; 2. Dijkstra converges; 3. the concatenation of each node's truncated tree yields a forest. These properties are not built into the algorithm, they must be guaranteed by the protocol. (1) is why OSPF and IS-IS use a reliable transport and split large routing domains into areas; (2) and (3) are why link-state protocols are restricted to integer metrics and lowest-metric route selection without filtering (within areas). Babel is more similar to BGP: it uses a primitive and therefore robust algorithm, that can survive filtering, non-isotonic metrics, unreliable transports, and different neighbour acquisition algorithms. The only requirements Babel puts on the implementation are: 1. In the flat routing case, Babel is safe (yields a loop-free tree) as long as: (a) no message is received before it is sent; and (b) the feasibility condition is respected. 2. Babel is complete (eventually yields all possible routes) as long as: (a) every neighbour is eventually acquired; (b) every update is eventually received; (c) every request eventually reaches the source. Because the algorithm is so robust, there are fewer requirements on the protocol. For example, property 2.a above can be satisfied by acquiring a neighbour as soon as we receive a packet, as soon as we receive a Hello, as soon as we receive an IHU, or at any other time as soon as this happens often enough. (Aside: note that filtering is a structured way of violating property 2b. That's fine, Babel remains safe in the presence of filtering, although it is no longer complete.) (Aside: as we've discussed before, Tony, property 1.a does not assume a global clock -- it merely says that the happens-before relation is well-founded.) > Descriptive language is nothing but ad-hoc extended FSM description along the > lines "if THAT happens, do THIS" .. There are a few places in Babel where the protocol says "it doesn't matter when you do this, as long as it eventually happens". I don't know how to express that in an FSM, even a non-deterministic one. > In OSPF, it was largely a question of "style" given John is > a mathematician by trade The notion of "often enough" is well established in Maths, although it's usually called "infinitely often". Of course, since Babel uses expiry timers, "often enough" really means "before the timer expires and flushes your incomplete state". -- Juliusz From nobody Thu Jan 5 07:39:28 2017 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 DB6D5129B68; Thu, 5 Jan 2017 07:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jZ7-vcjhUUs; Thu, 5 Jan 2017 07:39:24 -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 7178512995C; Thu, 5 Jan 2017 07:39:24 -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 v05FdMkd023556; Thu, 5 Jan 2017 16:39:22 +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 72DBED79F0; Thu, 5 Jan 2017 16:39:22 +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 diPZSMqsJ2_8; Thu, 5 Jan 2017 16:39:21 +0100 (CET) Received: from trurl.irif.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0C98DD79B6; Thu, 5 Jan 2017 16:39:20 +0100 (CET) Date: Thu, 05 Jan 2017 16:39:20 +0100 Message-ID: <87shoxqzx3.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake In-Reply-To: References: <148336094080.21313.16326257529253865319.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 05 Jan 2017 16:39:22 +0100 (CET) X-Miltered: at korolev with ID 586E68AA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 586E68AA.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 : 586E68AA.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-chairs@ietf.org, Babel at IETF , Alia Atlas Subject: Re: [babel] Expiration impending: 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, 05 Jan 2017 15:39:27 -0000 > There are also two draft referenced by specific version number where > subsequent versions have come out. I suggest just dropping the version number: Donald, I've allowed myself not to follow this suggestion, since I like references to be dated and versioned -- it avoids misunderstandings when something was added in a later version. I hope that's okay with you. -- Juliusz From nobody Thu Jan 5 07:41:33 2017 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 09FDF1293D9; Thu, 5 Jan 2017 07:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_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 Imd46yJ17TEm; Thu, 5 Jan 2017 07:41:31 -0800 (PST) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 DB7EC124281; Thu, 5 Jan 2017 07:41:30 -0800 (PST) Received: by mail-io0-x244.google.com with SMTP id n85so36834096ioi.1; Thu, 05 Jan 2017 07:41:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z5yNW1ID7mrWm/C+jMONME6MEDBUPL+KGjwNm7ktNmU=; b=Kg9/lHE3q46G5OsH2Te5m3dTGdImaig1HGka3gsPMklCi7fGR7OHYEZK6dk8eWX/8T toibW1m4cTsCC9TJIkr4P3j8kaJMz9vIogLNnSCNM7EBH+Wo9nkmpEomQmpPJew23Cdj SJ/oPDn7+Jqlj1ll4znlfVk1ACkzEoSdqpS5lozyo++38iLVPFBG1NApiIetzPrEKlbJ LMYidNZtJKpf52exryZ2Ffjtr6BoNYUaw06T4/ZpR8haUvgBlEWVKMbDUXbugQ4GW4nw x4ylZ03CMefK5rntDrJ6jq1ClMnzbwX22Chd46VagKuFgKLlvjYR/2saRLi1wGsBptU/ FqMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z5yNW1ID7mrWm/C+jMONME6MEDBUPL+KGjwNm7ktNmU=; b=eoHCBrBXdd+T6LmEFMXw9qtgD0OrkdTMsSaoL0vztZNmKkWo9lkSCRXZJAItiTCWvK gqG5anjkdbhMazqY7zOiGreaAB5oNFiZ21I3QaeJ5VNwqWp6vbbPd0ahB/waulSkiVc8 wibGnOGv7T8k4nw7UIacE4tJ7zITFDAWaM/hTmjhuGFdFqWZobQUr7voMpEWqiL3T2hj bDd4mV/Yc0Od55tonw9tWx0ziBf6ya6C8Hz5fhWeOGtVr2DBocOLlji2n6WbfGx7iz24 TLZPUS7okMXqdZfb+Gt8V/6/9F/3duyIWYMHlPDIKF/cqhmTHKxQufe+UiOZEgClBn+3 NSbA== X-Gm-Message-State: AIkVDXI7jnczJIPbESJG+wHbKbKZLrB9XyShOYqFk+GG8Wk6RN4o3mhr8VxJTH/JwW0rpRe22BkEiuW3q3rZnA== X-Received: by 10.107.175.80 with SMTP id y77mr52853238ioe.12.1483630890119; Thu, 05 Jan 2017 07:41:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.136 with HTTP; Thu, 5 Jan 2017 07:41:14 -0800 (PST) In-Reply-To: <87shoxqzx3.wl-jch@irif.fr> References: <148336094080.21313.16326257529253865319.idtracker@ietfa.amsl.com> <87shoxqzx3.wl-jch@irif.fr> From: Donald Eastlake Date: Thu, 5 Jan 2017 10:41:14 -0500 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: babel-chairs@ietf.org, Babel at IETF , Alia Atlas Subject: Re: [babel] Expiration impending: 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, 05 Jan 2017 15:41:32 -0000 Hi Juliusz, On Thu, Jan 5, 2017 at 10:39 AM, Juliusz Chroboczek wrote: > > > There are also two draft referenced by specific version number where > > subsequent versions have come out. I suggest just dropping the version number: > > Donald, I've allowed myself not to follow this suggestion, since I like > references to be dated and versioned -- it avoids misunderstandings when > something was added in a later version. I hope that's okay with you. That's fine with me. I was just trying to make a little less work for the draft authors. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > -- Juliusz From nobody Thu Jan 5 22:43:02 2017 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 E7E13129AA3 for ; Thu, 5 Jan 2017 22:43:00 -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 OX5qbIjIY1V7 for ; Thu, 5 Jan 2017 22:42:58 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 6114E1296B0 for ; Thu, 5 Jan 2017 22:42:58 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id k184so16235884wme.1 for ; Thu, 05 Jan 2017 22:42:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=F/1l945z44rvvnVMUmggdWFh0b0ft1A9usqVraoDNy4=; b=CVVO8lVsID5b45Fr7E+wh7dYulzdII998iHsebsqB4+nZDtPbWfE8WJWxncFwpTaJt y22dv/pdKy9Z5TS78k46oG+V9VQbYpJgGvN2FcvdxAgC2xsk0t3EaRfEDwoBC7aSsQ/t +CVQGPW9oPy/vkwDLJCt8V0tN/t0Jkc6mvIadiGTWTFGT2OJ6P9BYl7CAmjTcoi/lUKM /l8ACckov7JKBF1nrbdnSJASCeqMXoBZG6ASDydATIdgsYr8MQ6AhZFdKCoQhdKAPqgH xFexZK6dUlmHzS0jKQw/p9SrdCsoc8MJpiHY/WTSQIIJXsPEnq2vVno3cEK4zhc2O3/l gNKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=F/1l945z44rvvnVMUmggdWFh0b0ft1A9usqVraoDNy4=; b=Q6TGOpC+PN1ex/qkxHuf52X78CxH1TBNCxcKGGDlh/UweousKsJW7QnQEvkzATepeG dHK/cZkGOR0zFT9+IVpkEY67nxUnql0FD0QeYIQSPuc9HsOksxLUdlwfL4haCJgFbj9Y nk+Cz+oX6FHLlQnElDnAf0dPMiK918QTKqEoXyeSD5cFlqSqo0Pah8ffFvhpOXBMJZIA fQmYsJzp8CFqf/9lin8wDSAUrFUr8wReralOeR0nb5q3puW2gEq+kbZgTiR6RABkz3Kj iNUDetFccryJfy76cCEDbmNisa8k3WYlg1guuAyeBrAWTS+X4gPoxmdemJYCdk5vkH2s Qq1A== X-Gm-Message-State: AIkVDXIqPBWvJBRl4prvcVkPM3SRgaiIPrb6OhiZ5ugMC1w01c23bO2PfXzdhb6JYKSU6aJCJtrZyvnkTSN+2A== X-Received: by 10.28.26.197 with SMTP id a188mr1806265wma.93.1483684976420; Thu, 05 Jan 2017 22:42:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.149.150 with HTTP; Thu, 5 Jan 2017 22:42:15 -0800 (PST) In-Reply-To: References: From: Tony Przygienda Date: Thu, 5 Jan 2017 22:42:15 -0800 Message-ID: To: Babel at IETF Content-Type: multipart/alternative; boundary=001a114ccbbafa6d8005456753a9 Archived-At: Subject: Re: [babel] babel Digest, Vol 17, Issue 5 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, 06 Jan 2017 06:43:01 -0000 --001a114ccbbafa6d8005456753a9 Content-Type: text/plain; charset=UTF-8 > Hi Tony, good to hear from you. > Hey Prof. J. ;-) I'm loosely following Babel for my personal interest ... > > > FSM cannot "overspecify" a protocol unless you are perfectly happy with > > "undefined" behavior on certain transitions. > > Yes, Babel is tolerant of undefined behaviour in many cases. Please bear > with me while I lecture a little. > > Traditional link-state protocols are based on an algorithm that is > extremely > refined: their correctness crucially depends on three non-trivial > properties: > > 1. the LSDBs are synchronised at all times; > 2. Dijkstra converges; > 3. the concatenation of each node's truncated tree yields a forest. > > These properties are not built into the algorithm, they must be guaranteed > by the protocol. (1) is why OSPF and IS-IS use a reliable transport and > split large routing domains into areas; (2) and (3) are why link-state > protocols are restricted to integer metrics and lowest-metric route > selection without filtering (within areas). > all correct (except 3., more can be done but that's not the discussion here). You don't give link-state enough kuddos for convergence speed but that's not the topic either. > > ... > > Because the algorithm is so robust, there are fewer requirements on the > protocol. For example, property 2.a above can be satisfied by acquiring > a neighbour as soon as we receive a packet, as soon as we receive a Hello, > as soon as we receive an IHU, or at any other time as soon as this happens > often enough. > > (Aside: note that filtering is a structured way of violating property 2b. > That's fine, Babel remains safe in the presence of filtering, although it > is no longer complete.) > > (Aside: as we've discussed before, Tony, property 1.a does not assume > a global clock -- it merely says that the happens-before relation is > well-founded.) > yepp ... we had those discussions. We're in sync, you gave me an interesting info with all the one-side-distributive metric thinking in the process. > > > Descriptive language is nothing but ad-hoc extended FSM description > along the > > lines "if THAT happens, do THIS" .. > > There are a few places in Babel where the protocol says "it doesn't matter > when you do this, as long as it eventually happens". I don't know how to > express that in an FSM, even a non-deterministic one. > hmm, I am not a big friend of "eventual consistencies" since I don't like my customers to "eventually" pay the bills. We do and must live with epsilon which is what e.g. OSPF is doing and Babel does as well (given they are simply async distributed algorithms without enough info to provide concurrent consistency which wouldn't serve much of a purpose albeit one could argue that all the FRR work is nothing else but a cut-consistency guarantee while the algorithms themselves are only epsilon consistent @ a scale which was fine originally [seconds] but is not anymore for lots deploymens [<50msecs]. Anything else, as we spoke, would necessitate a global [synchronous] clock or at least clock matrices which are practically too slow for dynamic routing protocols by the gut-feeling I have from database work). So what you describe is nothing different than eventual or in-fact attempted epsilon (timer-based-retransmission) and that can be well expressed with FSMs. As footnote: strictly said, even OSPF is only "eventually consistent" and that only within a certain loss probability envelope so it's nothing new. As any dynamic system, one has to pick either positive stability @ the cost of slower adaptation or negative stability like OSPF that gives you faster adaptation to changes but carries a price in complexity and smaller operating envelope. I digress ;-) > > > In OSPF, it was largely a question of "style" given John is > > a mathematician by trade > > The notion of "often enough" is well established in Maths, although it's > usually called "infinitely often". Of course, since Babel uses expiry > timers, "often enough" really means "before the timer expires and flushes > your incomplete state". > Yeah, in summary though I don't think Babel is anything new much really in terms of distributed algo nature and FSMs would do a fine job on Babel as well. But if the descriptive is good enough to provide interoperable implementations, it's a matter of style largely (acknowledging the fact again that Babel is significantly simpler as algorithm and somewhat more positively stable than link-states). To come back to the the original point I was arguing a FSM will never "overspecify" a protocol since ultimately we're building DFAs here unless you want to argue that Babel is NFA (i.e. a transition can end up in two possible states and even then you can write FSMs for it, either as NFA or epsilon-NFA). We don't parse regexes which is probably only application of NFAs I know (and even those can be regularized into class-equivalent DFA if I remember correctly) so the discussion whether choosing whether you recognize neighbor on receiving a packet or not are two possible transitions until yoou "eventually" recognize the neighbor is somewhat interesting. One could argue that OSPF can do that as well (since ignoring a packet is indistinguishable from loss until you ignore them often enough you never converge) but I don't think I would consider that as argument that OSPF is best written using NFAs? And to completely split the hair here four ways, the proof exists that NFA and class equivalent to DFA so head I win and tails you loose ;-) my sum_n=0^\inf 1/n! cents ;-) --- tony --001a114ccbbafa6d8005456753a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
Hi Tony, good to hear from you.

Hey Prof. J. ;-) =C2=A0I'm loosely following Ba= bel for my personal interest ...=C2=A0
=C2=A0

> FSM cannot "overspecify" a protocol unless you are perfectly= happy with
> "undefined" behavior on certain transitions.

Yes, Babel is tolerant of undefined behaviour in many cases.=C2=A0 Please b= ear
with me while I lecture a little.

Traditional link-state protocols are based on an algorithm that is extremel= y
refined: their correctness crucially depends on three non-trivial propertie= s:

=C2=A01. the LSDBs are synchronised at all times;
=C2=A02. Dijkstra converges;
=C2=A03. the concatenation of each node's truncated tree yields a fores= t.

These properties are not built into the algorithm, they must be guaranteed<= br> by the protocol.=C2=A0 (1) is why OSPF and IS-IS use a reliable transport a= nd
split large routing domains into areas; (2) and (3) are why link-state
protocols are restricted to integer metrics and lowest-metric route
selection without filtering (within areas).

=
all correct (except 3., more can be done but that's not the discus= sion here). You don't give link-state enough kuddos for convergence spe= ed but that's not the topic either.=C2=A0
=C2=A0

...

Because the algorithm is so robust, there are fewer requirements on the
protocol.=C2=A0 For example, property 2.a above can be satisfied by acquiri= ng
a neighbour as soon as we receive a packet, as soon as we receive a Hello,<= br> as soon as we receive an IHU, or at any other time as soon as this happens<= br> often enough.

(Aside: note that filtering is a structured way of violating property 2b. That's fine, Babel remains safe in the presence of filtering, although = it
is no longer complete.)

(Aside: as we've discussed before, Tony, property 1.a does not assume a global clock -- it merely says that the happens-before relation is
well-founded.)

yepp ... we had those di= scussions. We're in sync, you gave me an interesting info with all the = one-side-distributive metric thinking in the process.=C2=A0
=C2= =A0

> Descriptive language is nothing but ad-hoc extended FSM description al= ong the
> lines "if THAT happens, do THIS" ..

There are a few places in Babel where the protocol says "it doesn'= t matter
when you do this, as long as it eventually happens".=C2=A0 I don't= know how to
express that in an FSM, even a non-deterministic one.
=
hmm, I am not a big friend of "eventual consistencies&q= uot; since I don't like my customers to "eventually" pay the = bills. We do and must live with epsilon which is what e.g. OSPF is doing an= d Babel does as well (given they are simply async distributed algorithms wi= thout enough info to provide concurrent consistency which wouldn't serv= e much of a purpose albeit one could argue that all the FRR work is nothing= else but a cut-consistency guarantee while the algorithms themselves are o= nly epsilon consistent @ a scale which was fine originally [seconds] but is= not anymore for lots deploymens [<50msecs]. Anything else, as we spoke,= would necessitate a global [synchronous] clock or at least clock matrices = which are practically too slow for dynamic routing protocols by the gut-fee= ling I have from database work). So what you describe is nothing different = than eventual or in-fact attempted epsilon (timer-based-retransmission) and= that can be well expressed with FSMs. As footnote: strictly said, even OSP= F is only "eventually consistent" and that only within a certain = loss probability envelope so it's nothing new. As any dynamic system, o= ne has to pick either positive stability @ the cost of slower adaptation or= negative stability like OSPF that gives you faster adaptation to changes b= ut carries a price in complexity and smaller operating envelope. I digress = ;-)=C2=A0
=C2=A0

> In OSPF, it was largely a question of "style" given John is<= br> > a mathematician by trade

The notion of "often enough" is well established in Maths, althou= gh it's
usually called "infinitely often".=C2=A0 Of course, since Babel u= ses expiry
timers, "often enough" really means "before the timer expire= s and flushes
your incomplete state".

Yeah, in s= ummary though I don't think Babel is anything new much really in terms = of distributed algo nature and FSMs would do a fine job on Babel as well. B= ut =C2=A0if the descriptive is good enough to provide interoperable impleme= ntations, it's a matter of style largely (acknowledging the fact again = that Babel is significantly simpler as algorithm and somewhat more positive= ly stable than link-states).=C2=A0

To come back to= the the original point I was arguing a FSM will never "overspecify&qu= ot; a protocol since ultimately we're building DFAs here unless you wan= t to argue that Babel is NFA (i.e. a transition can end up in two possible = states and even then you can write FSMs for it, either as NFA or epsilon-NF= A). We don't parse regexes which is probably only application of NFAs I= know (and even those can be regularized into class-equivalent DFA if I rem= ember correctly) so the discussion whether choosing whether you recognize n= eighbor on receiving a packet or not are two possible transitions until yoo= u "eventually" recognize the neighbor is somewhat interesting. On= e could argue that OSPF can do that as well (since ignoring a packet is ind= istinguishable from loss until you ignore them often enough you never conve= rge) but I don't think I would consider that as argument that OSPF is b= est written using NFAs? And to completely split the hair here four ways, th= e proof exists that NFA and class equivalent to DFA so head I win and tails= you loose ;-)=C2=A0

my sum_n=3D0^\inf 1/n! cents = ;-)=C2=A0

--- tony=C2=A0
--001a114ccbbafa6d8005456753a9-- From nobody Fri Jan 6 09:37:50 2017 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 67016129D18 for ; Fri, 6 Jan 2017 09:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-mo5a_q1Wfh for ; Fri, 6 Jan 2017 09:37:48 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E47129591 for ; Fri, 6 Jan 2017 09:37:47 -0800 (PST) Received: from trurl.irif.fr (unknown [78.250.43.111]) by smtp1-g21.free.fr (Postfix) with ESMTPS id 06505B005D2; Fri, 6 Jan 2017 18:37:39 +0100 (CET) Date: Fri, 06 Jan 2017 18:37:37 +0100 Message-ID: <878tqogkda.wl-jch@irif.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 Archived-At: Cc: Babel at IETF Subject: Re: [babel] babel Digest, Vol 17, Issue 5 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, 06 Jan 2017 17:37:49 -0000 > You don't give link-state enough kuddos for convergence speed Ok, here we go. With a link state algorithm, given enough CPU, convergence speed is almost entirely predicated on the speed of LSDB synchronisation. This gives link-state protocols a fundamental advantage as far as convergence speed is concerned, at the cost of greater complexity and lesser robustness than well-designed distance-vector protocols. -- Juliusz From nobody Fri Jan 6 09:50:50 2017 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 07ED71295A2 for ; Fri, 6 Jan 2017 09:50:49 -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 2KHv26kQo2kA for ; Fri, 6 Jan 2017 09:50:47 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A73412958C for ; Fri, 6 Jan 2017 09:50:47 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id c85so34258174wmi.1 for ; Fri, 06 Jan 2017 09:50:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hwsz6GV/gCjNVs6OmCV2d3iDp8sau97jBJIaaLoKhXM=; b=NTIM6BH7v7FN82vsb5LLh7xHPeQkXfBQq5QIcCluseOTJBL5ecwp0gF3Jxt0EAWAjm apnXWTcX9YYdM4UPrmr4Hdsf2IV0XoUMgqncZORyy/wpr8Lyqdq6TtooyFtc74Kg6juZ Rip+64kNutx7r4X/FxDs0DU8Tdki5cDuuLCK6vtIz93hyXYElbvVu8wovBN5u6iBLJee 8h9x/m4zgjAy6Ls7XtMyqxW6KcYi7feNCZaLIRpHbXwzicD9tVHlzhwDh8I+/w3m6//t NWgYB3jIwNpxSQaejxbKMKJvBW1eaDVMyXphBmmSxa4ZHyWtyE5CL/htb68NCAmsCTLN zimA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hwsz6GV/gCjNVs6OmCV2d3iDp8sau97jBJIaaLoKhXM=; b=eIvJHyGTIYMRMPzkCwm2/5sC7vdpclGFLGHA6IV8dLxDmIo1hHNW26hCiloIjCGFtR 4LI9FkIy2GI3mgJ/V5lVMeNlJHlUVCZGfMezQiuP/CY+OlgN7OAYy04iD76LucDrftAD fDrLVdQv8wzUn9CI9FmwAJpZxpUYWr+Lhn37nmLm89DqKYOFK0Dy+Gu3upAY+A7yYU4c Ky7joPlv2iyMU2WuKkTHdMZUhoId1Y7++W3prnMVUb2BLCEuz7tsqPv9F58Bh2Ru4RES n4tnX7TT+MrPMWwvjDzmAq2JmFd/vJQwjpJm2qjtj9ipgDmpE0ZcUA3+y/MBwSfz3Qmo GZXg== X-Gm-Message-State: AIkVDXLlePTQBl+S5oA+tj4A8qwIng3UGpIpcgLpIq9gOwt76IqHjcX7gozjjvUJfMYhK31LVbCi4oy9Rxh02w== X-Received: by 10.223.181.17 with SMTP id a17mr2420582wrd.111.1483725045889; Fri, 06 Jan 2017 09:50:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.149.150 with HTTP; Fri, 6 Jan 2017 09:50:05 -0800 (PST) In-Reply-To: <878tqogkda.wl-jch@irif.fr> References: <878tqogkda.wl-jch@irif.fr> From: Tony Przygienda Date: Fri, 6 Jan 2017 09:50:05 -0800 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=94eb2c1cd62c4e0090054570a8f2 Archived-At: Cc: Babel at IETF Subject: Re: [babel] babel Digest, Vol 17, Issue 5 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, 06 Jan 2017 17:50:49 -0000 --94eb2c1cd62c4e0090054570a8f2 Content-Type: text/plain; charset=UTF-8 See, just needed some prodding ;-) I agree with everything except maybe the complexity, a fully fledged BGP these days is 10x a fully fledged IGP. But then again, it's apples and kiwis, IGPs do not attempt to do EVPN or even multicast ;-) so if we're talking the "smallest viable routing solution", yes, IGP has a higher price of admission ;-) --- tony On Fri, Jan 6, 2017 at 9:37 AM, Juliusz Chroboczek wrote: > > You don't give link-state enough kuddos for convergence speed > > Ok, here we go. > > With a link state algorithm, given enough CPU, convergence speed is almost > entirely predicated on the speed of LSDB synchronisation. This gives > link-state protocols a fundamental advantage as far as convergence speed > is concerned, at the cost of greater complexity and lesser robustness than > well-designed distance-vector protocols. > > -- Juliusz > --94eb2c1cd62c4e0090054570a8f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
See, just needed some prodding ;-) =C2=A0

I agree with everything except maybe the complexity, a fully fledged BGP= these days is 10x a fully fledged IGP. But then again, it's apples and= kiwis, IGPs do not attempt to do EVPN or even multicast ;-) =C2=A0so if we= 're talking the "smallest viable routing solution", yes, IGP = has a higher price of admission ;-)=C2=A0

--- tony= =C2=A0

On Fri,= Jan 6, 2017 at 9:37 AM, Juliusz Chroboczek <jch@irif.fr> wrote:=
> You don't give= link-state enough kuddos for convergence speed

Ok, here we go.

With a link state algorithm, given enough CPU, convergence speed is almost<= br> entirely predicated on the speed of LSDB synchronisation.=C2=A0 This gives<= br> link-state protocols a fundamental advantage as far as convergence speed is concerned, at the cost of greater complexity and lesser robustness than<= br> well-designed distance-vector protocols.

-- Juliusz


--94eb2c1cd62c4e0090054570a8f2-- From nobody Fri Jan 6 15:22:49 2017 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 822B912946C for ; Fri, 6 Jan 2017 15:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rqBfaTVbVPY for ; Fri, 6 Jan 2017 15:22:45 -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 73F65129456 for ; Fri, 6 Jan 2017 15:22:45 -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 v06NMg9S021156; Sat, 7 Jan 2017 00:22:42 +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 028D9D7974; Sat, 7 Jan 2017 00:22:42 +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 HH_sV5oDlk29; Sat, 7 Jan 2017 00:22:40 +0100 (CET) Received: from trurl.irif.fr (unknown [78.250.43.111]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 500B4D7950; Sat, 7 Jan 2017 00:22:39 +0100 (CET) Date: Sat, 07 Jan 2017 00:22:40 +0100 Message-ID: <87zij3g4e7.wl-jch@irif.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 [194.254.61.138]); Sat, 07 Jan 2017 00:22:42 +0100 (CET) X-Miltered: at korolev with ID 587026C2.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 587026C2.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 : 587026C2.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: Babel at IETF Subject: Re: [babel] babel Digest, Vol 17, Issue 5 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, 06 Jan 2017 23:22:47 -0000 I've now had some time to spend on the rest of your mail. > hmm, I am not a big friend of "eventual consistencies" since I don't like my > customers to "eventually" pay the bills. We do and must live with epsilon > which is what e.g. OSPF is doing and Babel does as well I'm not familiar with the "epsilon" terminology, but if I understand correctly what you mean -- OSPF encapsulates the probabilistic aspect within the reliable flooding algorithm. Assuming that flooding terminates, OSPF is correct. Of course, no bound can be given on the termination of flooding, but at least the probabilistic nature of the protocol is cleanly encapsulated within the flooding algorithm. All the remainder of the protocol is completely deterministic. This is very different from Babel, which does not rely on a reliable transport, and therefore carries probabilities throughout the protocol. Hence the strong invariant (loop-freedom), which has the side benefit of allowing a somewhat more lax style of specification. > Yeah, in summary though I don't think Babel is anything new much really in > terms of distributed algo nature I agree, most of the good ideas in Babel were stolen from other protocols (RIP, DSDV, EIGRP, BGP). > and FSMs would do a fine job on Babel as well. I don't know how to do that. I don't know how to express in an FSM the notion that "When to acquire a neighbour is an implementation detail, as long as a neighbour is acquired soon enough. A simple strategy is to create a neighbour table entry as soon as we receive a well-formed Babel packet from a given IP, but other strategies are possible". > (acknowledging the fact again that Babel is significantly simpler as > algorithm and somewhat more positively stable than link-states). Quoting for my personal enjoyment :-) > And to completely split the hair here four ways, the proof exists that NFA and > class equivalent to DFA so head I win and tails you loose ;-) I don't think the theorem applies here. The equivalence only states that the class of recognised languages is the same, nothing more. -- Juliusz From nobody Sun Jan 8 18:37:08 2017 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 07BDF1296BF for ; Sun, 8 Jan 2017 18:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_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 RXkWjNACLqdg for ; Sun, 8 Jan 2017 18:37:05 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D3E31296C2 for ; Sun, 8 Jan 2017 18:37:05 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id x2so54254296itf.1 for ; Sun, 08 Jan 2017 18:37:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=L/rHXrrreONyROXDeJDGVa71dKxLNRAV1ApS3Lqvrus=; b=oiHn+m7fQvMeZlfDrt6aWb5JatgSvqEbaUNirAp6xXjTstu/tNnWbV0kxMr2jx9Boi 6nvYy1ESh2gGsNHJ0Kedb4kcUs/EL0Mc2R3IHKptxwrito4CxpfA5BhkP4wEAJBkqyih Y/eS65lbVCZfQUqPsEjsH74Qze4PEnGEmhHiEwOglIK1SCkZWhfJJfUx7ASjj8qo1TZJ RzR+BjH+Q7XbGJdiwcm+qEYeKCLAHtGEqJlGz3wrhGewWRqev9mOCilqfM4jD/cjhgaL WCh42l16RGN5HxHUdaPk2gewrAHcQ7Tq6L7z6NCPWoClCS0GCu9IS1a4YmRYTXUb/+nX iJ5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=L/rHXrrreONyROXDeJDGVa71dKxLNRAV1ApS3Lqvrus=; b=HEtbiUpOnFrD153VBULZWiMtFmwZVjZ47upN8jZbVcEIDI0HgSp9//smFlGNGfU7k/ knkTirOISW0CGMCV9mAvheswV8qYXSG6vc5ZUXp1h6mD4WuXk0YgE6mEz3ONeyH4bIUR ZSVM45++/hIvxQ4q4rthBSJPhEck+gEGfIIAhdBM652tcPnQwBr5yvklcd6zVk9Jx9+v xfG+pi+0FbbfjV8IQycsCgRtU7EJQFb1e8g8D4wTZ0Mh+wJDmIk+qv/TJBkOuWwJCv7H qklXld5POjlez8Hz5QQabp54EDSwnZ+MuQJSVCOzoaghkEyRoPBdWgphdg+dHfTTFMVc t+hQ== X-Gm-Message-State: AIkVDXKt3rY9cl22MhPqa6M8r4OC9s3rJNpe4abh5JS7lnUfSl6uNsrTB175cDvkmqRNYE4liI5SQpsVW4ku2w== X-Received: by 10.36.33.151 with SMTP id e145mr6756505ita.14.1483929424722; Sun, 08 Jan 2017 18:37:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.136 with HTTP; Sun, 8 Jan 2017 18:36:49 -0800 (PST) From: Donald Eastlake Date: Sun, 8 Jan 2017 21:36:49 -0500 Message-ID: To: Babel at IETF Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [babel] WG Last Call for draft-ietf-trill-babel-applicability (Jan 8 - Jan 22) 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, 09 Jan 2017 02:37:07 -0000 This is a last call for comments on https://tools.ietf.org/html/draft-ietf-babel-applicability-01 Please indicate if you support publication of this draft and think it reasonably represents BABE's appllicability. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Tue Jan 31 11:51:36 2017 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 4EBBC1299E8 for ; Tue, 31 Jan 2017 11:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZuNrGukeXcq for ; Tue, 31 Jan 2017 11:51:34 -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 0202C129581 for ; Tue, 31 Jan 2017 11:51:33 -0800 (PST) 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 v0VJpWPF022198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 31 Jan 2017 20:51:32 +0100 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 v0VJpWC8000550 for ; Tue, 31 Jan 2017 20:51:32 +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 1AE1CD7A21 for ; Tue, 31 Jan 2017 20:51:32 +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 fIzYYsAUIiWt for ; Tue, 31 Jan 2017 20:51:31 +0100 (CET) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 20027D7A19 for ; Tue, 31 Jan 2017 20:51:31 +0100 (CET) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.88) (envelope-from ) id 1cYeSg-0004Do-S3 for babel@ietf.org; Tue, 31 Jan 2017 20:51:30 +0100 Date: Tue, 31 Jan 2017 20:51:30 +0100 Message-ID: <7ivasvhut9.wl-jch@irif.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 [IPv6:2001:660:3301:8000::1:2]); Tue, 31 Jan 2017 20:51:32 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 31 Jan 2017 20:51:32 +0100 (CET) X-Miltered: at korolev with ID 5890EAC4.004 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5890EAC4.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5890EAC4.004 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5890EAC4.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 : 5890EAC4.004 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5890EAC4.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: [babel] draft-...-rfc6126bis-01 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, 31 Jan 2017 19:51:35 -0000 I've just submitted -01 of 6126bis. Since I'm a lazy bum, that's just the version of December with the date changed. It doesn't yet contain the interesting bits, namely: (1) integrating the extension mechanism; (2) changing the definition of updates to be more extensible; (3) changes to neighbour acquisition according to the discussion prompted by Denis' comments. I promise I'll cut down on my sleeping time ASAP. (But not my teaching time -- that, never!) -- Juliusz From nobody Tue Jan 31 11:52:02 2017 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E70A129581; Tue, 31 Jan 2017 11:51:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148589231005.6043.10256824387883741448.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2017 11:51:50 -0800 Archived-At: Cc: babel@ietf.org Subject: [babel] I-D Action: draft-ietf-babel-rfc6126bis-01.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 19:51:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol of the IETF. Title : The Babel Routing Protocol Author : Juliusz Chroboczek Filename : draft-ietf-babel-rfc6126bis-01.txt Pages : 45 Date : 2017-01-31 Abstract: Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-rfc6126bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/