From nobody Thu Dec 1 04:26:04 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2B812949B for ; Thu, 1 Dec 2016 04:26:03 -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 StKnItEEhlx0 for ; Thu, 1 Dec 2016 04:26:00 -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 61AFF1296ED for ; Thu, 1 Dec 2016 04:26:00 -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 uB1CPwkf006078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 1 Dec 2016 13:25:58 +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 uB1CPv7L032107 for ; Thu, 1 Dec 2016 13:25:58 +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 E46C4D78B9 for ; Thu, 1 Dec 2016 13:25:57 +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 yQIzs0gLM1uO for ; Thu, 1 Dec 2016 13:25:56 +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 8EF80D7880 for ; Thu, 1 Dec 2016 13:25:56 +0100 (CET) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.87) (envelope-from ) id 1cCQR2-0005Hm-3T for babel@ietf.org; Thu, 01 Dec 2016 13:25:56 +0100 Date: Thu, 01 Dec 2016 13:25:56 +0100 Message-ID: <7i4m2nvnsb.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]); Thu, 01 Dec 2016 13:25:58 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 01 Dec 2016 13:25:58 +0100 (CET) X-Miltered: at korolev with ID 584016D6.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 584016D5.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 584016D6.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 584016D5.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 584016D6.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 584016D5.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Github repository 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, 01 Dec 2016 12:26:03 -0000 I've just created a git repository on https://github.com/jech/babel-drafts The plan is to put all of the Babel drafts there, one subdirectory for each, in the breaks between the student charges on my office. -- Juliusz From nobody Thu Dec 1 04:48:46 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A481129496 for ; Thu, 1 Dec 2016 04:48:45 -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 FYqRIopyoaCw for ; Thu, 1 Dec 2016 04:48:43 -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 32BE9129430 for ; Thu, 1 Dec 2016 04:48:43 -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 uB1CmfGO021886; Thu, 1 Dec 2016 13:48:41 +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 AD11DD78B9; Thu, 1 Dec 2016 13:48:41 +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 HTA7yJBuzoBU; Thu, 1 Dec 2016 13:48:40 +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 9AC64D7880; Thu, 1 Dec 2016 13:48:40 +0100 (CET) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.87) (envelope-from ) id 1cCQn2-0005MF-DE; Thu, 01 Dec 2016 13:48:40 +0100 Date: Thu, 01 Dec 2016 13:48:40 +0100 Message-ID: <7izikfu85z.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= In-Reply-To: <20161016155720.29466-1-toke@toke.dk> References: <20161016155720.29466-1-toke@toke.dk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 01 Dec 2016 13:48:41 +0100 (CET) X-Miltered: at korolev with ID 58401C29.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58401C29.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 58401C29.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: babel@ietf.org Subject: Re: [babel] [PATCH] First shot at integrating RFC7557 into RFC6126bis 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, 01 Dec 2016 12:48:45 -0000 Hmm... I've read your patch, and I don't feel that this is well integrated. It still feels like a basic algorithm plus an extension mechanism, rather than a single protocol that is extensible. I'll think it over. -- Juliusz From nobody Sat Dec 3 09:26:03 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4B112997F for ; Sat, 3 Dec 2016 09:26:02 -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=unavailable 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 8BoMoyGhs4-0 for ; Sat, 3 Dec 2016 09:26:01 -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 5214B129983 for ; Sat, 3 Dec 2016 09:20: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 uB3HK6vU019542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 3 Dec 2016 18:20: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 uB3HK6K6024995 for ; Sat, 3 Dec 2016 18:20: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 8F6B9D7880 for ; Sat, 3 Dec 2016 18:20: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 f5HX31ZQSnSO for ; Sat, 3 Dec 2016 18:20:05 +0100 (CET) Received: from trurl.irif.fr (unknown [78.250.212.131]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 50744D78B9 for ; Sat, 3 Dec 2016 18:20:02 +0100 (CET) Date: Sat, 03 Dec 2016 18:20:06 +0100 Message-ID: <871sxp53qx.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]); Sat, 03 Dec 2016 18:20:07 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 03 Dec 2016 18:20:06 +0100 (CET) X-Miltered: at korolev with ID 5842FEC6.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5842FEC6.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5842FEC6.003 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5842FEC6.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 : 5842FEC6.003 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5842FEC6.002 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Redefining updates X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 17:26:02 -0000 RFC 6126 Updates are not defined well. RFC 6126 Section 4.4.9 says: o if the bit with value 80 hexadecimal is set, then this Update establishes a new default prefix for subsequent Update TLVs with a matching address family within the same packet; This assumes that an implementation is able to match an AE with an address family. Not only does this complicate the definition of new AEs (which must specify which family they belong to), but it's not entirely clear what to do with AEs that don't map cleanly to an address family, such as source-specific routes, MPLS or BIER. I'm planning to make an incompatible change (but one that will not break existing implementations): the implicit prefix established by flag 0x80 will be per-AE. This makes the semantics easier to implement and easier to understand, at a slight cost in compression efficiency. It will not break existing implementations (since AEs 1 and 2 are the only ones carried in updates by existing implementations). Comments? While I'm at it, should I rename the "Prefix" field to "Opaque", since future extensions might use it for carrying things other than prefixes? -- Juliusz From nobody Sun Dec 4 22:35:54 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9822D1297CD for ; Sun, 4 Dec 2016 22:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.096 X-Spam-Level: X-Spam-Status: No, score=-107.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable 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 rYm8514bCCfI for ; Sun, 4 Dec 2016 22:35:48 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD0F1297CE for ; Sun, 4 Dec 2016 22:35:46 -0800 (PST) X-MAILFROM: X-RCPTTO: X-FROMIP: 192.168.168.120 X-SEG-Scaned: 1 X-Received: unknown,192.168.168.120,20161205143422 Received: from unknown (HELO out1.zte.com.cn) (192.168.168.120) by localhost with SMTP; 5 Dec 2016 06:34:22 -0000 X-MAILFROM: X-RCPTTO: X-FROMIP: 10.30.3.20 X-SEG-Scaned: 1 X-Received: unknown,10.30.3.20,20161205143247 Received: from unknown (HELO mse01.zte.com.cn) (10.30.3.20) by localhost with (AES256-SHA encrypted) SMTP; 5 Dec 2016 06:32:47 -0000 Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id uB56Z9hT020167; Mon, 5 Dec 2016 14:35:09 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn) In-Reply-To: <871sxp53qx.wl-jch@irif.fr> To: Juliusz Chroboczek MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.zheng@zte.com.cn Date: Mon, 5 Dec 2016 14:35:21 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-12-05 14:34:58, Serialize complete at 2016-12-05 14:34:58 Content-Type: multipart/alternative; boundary="=_alternative 00242DE248258080_=" X-MAIL: mse01.zte.com.cn uB56Z9hT020167 X-HQIP: 127.0.0.1 X-HQIP: 127.0.0.1 Archived-At: Cc: babel , babel@ietf.org Subject: Re: [babel] Redefining updates 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, 05 Dec 2016 06:35:52 -0000 This is a multipart message in MIME format. --=_alternative 00242DE248258080_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgSnVsaXVzeiwNCg0KICAgIEdsYWQgdG8gc2VlIHlvdXIgbW9kaWZpY2F0aW9uIGNvbnNpZGVy YXRpb24gb2YgdGhlIHByZWZpeCBzZWN0aW9uLiANCkkgYWdyZWUgdG8gdGhlIG1lYW5pbmcgZXh0 ZW5zaW9uIG9mIEFFLiBBbmQgSSB0aGluayB0aGF0IHRoZSBuYW1lIA0KY2hhbmdpbmcgbWF5IGJl IG5vdCBuZWNlc3NhcnkuIEJlY2F1c2UgbW9zdCBvZiB0aGUgaW5mbyBjYW4gYmUgZGVsaXZlcmVk IA0KYnkgc3ViLVRMVnMgb2YgcHJlZml4LiBUaGUgY29udGVudCBjYW4gYmUgZGlzdGluZ3Vpc2hl ZCBmcm9tIHRoZSB0eXBlIG9mIA0Kc3ViLVRMVnMgb3Igb3RoZXIgd2F5cy4NCg0KVGhhbmtzLA0K U2FuZHkNCg0KDQoiYmFiZWwiIDxiYWJlbC1ib3VuY2VzQGlldGYub3JnPiDQtNPaIDIwMTYvMTIv MDQgMDE6MjA6MDY6DQoNCj4gUkZDIDYxMjYgVXBkYXRlcyBhcmUgbm90IGRlZmluZWQgd2VsbC4N Cj4gDQo+IFJGQyA2MTI2IFNlY3Rpb24gNC40Ljkgc2F5czoNCj4gDQo+IG8gIGlmIHRoZSBiaXQg d2l0aCB2YWx1ZSA4MCBoZXhhZGVjaW1hbCBpcyBzZXQsIHRoZW4gdGhpcyBVcGRhdGUNCj4gICAg ZXN0YWJsaXNoZXMgYSBuZXcgZGVmYXVsdCBwcmVmaXggZm9yIHN1YnNlcXVlbnQgVXBkYXRlIFRM VnMgd2l0aCBhDQo+ICAgIG1hdGNoaW5nIGFkZHJlc3MgZmFtaWx5IHdpdGhpbiB0aGUgc2FtZSBw YWNrZXQ7DQo+IA0KPiBUaGlzIGFzc3VtZXMgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBpcyBhYmxl IHRvIG1hdGNoIGFuIEFFIHdpdGggYW4gDQphZGRyZXNzDQo+IGZhbWlseS4gIE5vdCBvbmx5IGRv ZXMgdGhpcyBjb21wbGljYXRlIHRoZSBkZWZpbml0aW9uIG9mIG5ldyBBRXMgKHdoaWNoDQo+IG11 c3Qgc3BlY2lmeSB3aGljaCBmYW1pbHkgdGhleSBiZWxvbmcgdG8pLCBidXQgaXQncyBub3QgZW50 aXJlbHkgY2xlYXINCj4gd2hhdCB0byBkbyB3aXRoIEFFcyB0aGF0IGRvbid0IG1hcCBjbGVhbmx5 IHRvIGFuIGFkZHJlc3MgZmFtaWx5LCBzdWNoIGFzDQo+IHNvdXJjZS1zcGVjaWZpYyByb3V0ZXMs IE1QTFMgb3IgQklFUi4NCj4gDQo+IEknbSBwbGFubmluZyB0byBtYWtlIGFuIGluY29tcGF0aWJs ZSBjaGFuZ2UgKGJ1dCBvbmUgdGhhdCB3aWxsIG5vdCBicmVhaw0KPiBleGlzdGluZyBpbXBsZW1l bnRhdGlvbnMpOiB0aGUgaW1wbGljaXQgcHJlZml4IGVzdGFibGlzaGVkIGJ5IGZsYWcgMHg4MA0K PiB3aWxsIGJlIHBlci1BRS4gIFRoaXMgbWFrZXMgdGhlIHNlbWFudGljcyBlYXNpZXIgdG8gaW1w bGVtZW50IGFuZCBlYXNpZXINCj4gdG8gdW5kZXJzdGFuZCwgYXQgYSBzbGlnaHQgY29zdCBpbiBj b21wcmVzc2lvbiBlZmZpY2llbmN5LiAgSXQgd2lsbCBub3QNCj4gYnJlYWsgZXhpc3RpbmcgaW1w bGVtZW50YXRpb25zIChzaW5jZSBBRXMgMSBhbmQgMiBhcmUgdGhlIG9ubHkgb25lcw0KPiBjYXJy aWVkIGluIHVwZGF0ZXMgYnkgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zKS4NCj4gDQo+IENvbW1l bnRzPyAgV2hpbGUgSSdtIGF0IGl0LCBzaG91bGQgSSByZW5hbWUgdGhlICJQcmVmaXgiIGZpZWxk IHRvDQo+ICJPcGFxdWUiLCBzaW5jZSBmdXR1cmUgZXh0ZW5zaW9ucyBtaWdodCB1c2UgaXQgZm9y IGNhcnJ5aW5nIHRoaW5ncyBvdGhlcg0KPiB0aGFuIHByZWZpeGVzPw0KPiANCj4gLS0gSnVsaXVz eg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IGJhYmVsIG1haWxpbmcgbGlzdA0KPiBiYWJlbEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JhYmVsDQo+IA0KDQo= --=_alternative 00242DE248258080_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEp1bGl1c3osPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IEds YWQgdG8gc2VlIHlvdXIgbW9kaWZpY2F0aW9uDQpjb25zaWRlcmF0aW9uIG9mIHRoZSBwcmVmaXgg c2VjdGlvbi4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIGFn cmVlIHRvIHRoZSBtZWFuaW5nIGV4dGVuc2lvbiBvZg0KQUUuIEFuZCBJIHRoaW5rIHRoYXQgdGhl IG5hbWUgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5jaGFuZ2lu ZyBtYXkgYmUgbm90IG5lY2Vzc2FyeS4gQmVjYXVzZQ0KbW9zdCBvZiB0aGUgaW5mbyBjYW4gYmUg ZGVsaXZlcmVkIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Ynkg c3ViLVRMVnMgb2YgcHJlZml4LiBUaGUgY29udGVudCBjYW4NCmJlIGRpc3Rpbmd1aXNoZWQgZnJv bSB0aGUgdHlwZSBvZiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PnN1Yi1UTFZzIG9yIG90aGVyIHdheXMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5UaGFua3MsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5TYW5keTwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0 PiZxdW90O2JhYmVsJnF1b3Q7ICZsdDtiYWJlbC1ib3VuY2VzQGlldGYub3JnJmd0OyDQtNPaDQoy MDE2LzEyLzA0IDAxOjIwOjA2Ojxicj4NCjxicj4NCiZndDsgUkZDIDYxMjYgVXBkYXRlcyBhcmUg bm90IGRlZmluZWQgd2VsbC48YnI+DQomZ3Q7IDxicj4NCiZndDsgUkZDIDYxMjYgU2VjdGlvbiA0 LjQuOSBzYXlzOjxicj4NCiZndDsgPGJyPg0KJmd0OyBvICZuYnNwO2lmIHRoZSBiaXQgd2l0aCB2 YWx1ZSA4MCBoZXhhZGVjaW1hbCBpcyBzZXQsIHRoZW4gdGhpcyBVcGRhdGU8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDtlc3RhYmxpc2hlcyBhIG5ldyBkZWZhdWx0IHByZWZpeCBmb3Igc3Vic2VxdWVu dCBVcGRhdGUNClRMVnMgd2l0aCBhPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7bWF0Y2hpbmcgYWRk cmVzcyBmYW1pbHkgd2l0aGluIHRoZSBzYW1lIHBhY2tldDs8YnI+DQomZ3Q7IDxicj4NCiZndDsg VGhpcyBhc3N1bWVzIHRoYXQgYW4gaW1wbGVtZW50YXRpb24gaXMgYWJsZSB0byBtYXRjaCBhbiBB RSB3aXRoIGFuDQphZGRyZXNzPGJyPg0KJmd0OyBmYW1pbHkuICZuYnNwO05vdCBvbmx5IGRvZXMg dGhpcyBjb21wbGljYXRlIHRoZSBkZWZpbml0aW9uIG9mIG5ldw0KQUVzICh3aGljaDxicj4NCiZn dDsgbXVzdCBzcGVjaWZ5IHdoaWNoIGZhbWlseSB0aGV5IGJlbG9uZyB0byksIGJ1dCBpdCdzIG5v dCBlbnRpcmVseSBjbGVhcjxicj4NCiZndDsgd2hhdCB0byBkbyB3aXRoIEFFcyB0aGF0IGRvbid0 IG1hcCBjbGVhbmx5IHRvIGFuIGFkZHJlc3MgZmFtaWx5LCBzdWNoDQphczxicj4NCiZndDsgc291 cmNlLXNwZWNpZmljIHJvdXRlcywgTVBMUyBvciBCSUVSLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJ J20gcGxhbm5pbmcgdG8gbWFrZSBhbiBpbmNvbXBhdGlibGUgY2hhbmdlIChidXQgb25lIHRoYXQg d2lsbCBub3QNCmJyZWFrPGJyPg0KJmd0OyBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMpOiB0aGUg aW1wbGljaXQgcHJlZml4IGVzdGFibGlzaGVkIGJ5IGZsYWcNCjB4ODA8YnI+DQomZ3Q7IHdpbGwg YmUgcGVyLUFFLiAmbmJzcDtUaGlzIG1ha2VzIHRoZSBzZW1hbnRpY3MgZWFzaWVyIHRvIGltcGxl bWVudA0KYW5kIGVhc2llcjxicj4NCiZndDsgdG8gdW5kZXJzdGFuZCwgYXQgYSBzbGlnaHQgY29z dCBpbiBjb21wcmVzc2lvbiBlZmZpY2llbmN5LiAmbmJzcDtJdA0Kd2lsbCBub3Q8YnI+DQomZ3Q7 IGJyZWFrIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyAoc2luY2UgQUVzIDEgYW5kIDIgYXJlIHRo ZSBvbmx5IG9uZXM8YnI+DQomZ3Q7IGNhcnJpZWQgaW4gdXBkYXRlcyBieSBleGlzdGluZyBpbXBs ZW1lbnRhdGlvbnMpLjxicj4NCiZndDsgPGJyPg0KJmd0OyBDb21tZW50cz8gJm5ic3A7V2hpbGUg SSdtIGF0IGl0LCBzaG91bGQgSSByZW5hbWUgdGhlICZxdW90O1ByZWZpeCZxdW90Ow0KZmllbGQg dG88YnI+DQomZ3Q7ICZxdW90O09wYXF1ZSZxdW90Oywgc2luY2UgZnV0dXJlIGV4dGVuc2lvbnMg bWlnaHQgdXNlIGl0IGZvciBjYXJyeWluZw0KdGhpbmdzIG90aGVyPGJyPg0KJmd0OyB0aGFuIHBy ZWZpeGVzPzxicj4NCiZndDsgPGJyPg0KJmd0OyAtLSBKdWxpdXN6PGJyPg0KJmd0OyA8YnI+DQom Z3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7IGJhYmVsIG1haWxpbmcgbGlzdDxicj4NCiZndDsgYmFiZWxAaWV0Zi5v cmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmFiZWw8 YnI+DQomZ3Q7IDxicj4NCjwvdHQ+PC9mb250Pg0K --=_alternative 00242DE248258080_=-- From nobody Sun Dec 4 23:34:58 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D15129450 for ; Sun, 4 Dec 2016 23:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, URIBL_RED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmhmDo89nSwF for ; Sun, 4 Dec 2016 23:34:55 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 464471297ED for ; Sun, 4 Dec 2016 23:34:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1480923295; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NPfCEcNSqf8Hsqjn3bwZLjdrm8hr2Jr0utA16mafa0U=; b=JBtk4osn6MCoZWXmlkJ6ypAioz1QUn3u7ZJHhpqq2hzft40WkCMYkoGlIGcTPIG7 epRnu2yYNH+I8HzWDC6j6ovLT2fm2YswTWxwLCH7KHupTC1XBkob3DSEya8+YTQe 7jzL8XgQpH4YKXZNAzZnLoPkNG6+c3qxniIUyxcAsGhKew4REQCSBeeKMCkd4bT7 AKo0v2xJpdMO0e//1QvI5MT64izoDvOplEJIcp2D+IRygnfXXtfiU3WE89LzaaxM YT/dJ9zucCUJcRFJBgY2W9z55XIM8ekux5vK822YImWP64LlGBAeyO0GS9hUAGIn stJLG+Rb89yV3aM+cbVOnQ==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 2C.AD.01803.F9815485; Sun, 4 Dec 2016 23:34:55 -0800 (PST) X-AuditID: 11973e12-52b319a00000070b-e1-5845189f48bb Received: from jimbu (jimbu.apple.com [17.151.62.37]) by relay3.apple.com (Apple SCV relay) with SMTP id A3.74.13773.E9815485; Sun, 4 Dec 2016 23:34:55 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_/vpNJ6w2ifiYY7467IbXLg)" Received: from [10.0.1.42] (76-14-42-253.sf-cable.astound.net [76.14.42.253]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.0 64bit (built Sep 28 2016)) with ESMTPSA id <0OHP00CUGBQ6T300@jimbu.apple.com>; Sun, 04 Dec 2016 23:34:54 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi Message-id: <70E521A2-2946-43B1-A347-07868473AAED@apple.com> Date: Sun, 04 Dec 2016 23:34:54 -0800 In-reply-to: To: Juliusz Chroboczek References: X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUi2FAYrDtfwjXCYN5XLosti7pZLOa3LmOz uLy7kcmB2WPJkp9MHou3vGX0WLPvB0sAcxSXTUpqTmZZapG+XQJXxsOe3cwFty0q2jaGNzB+ 1e9i5OSQEDCRuLFqCzuILSSwl1Hi97ukLkYOsPiSU1JdjFxA4WWMEl9fNLKC1PAKCEr8mHyP BcRmFgiT+Pd4MwtEUT+TxLaOB8wgCWEBaYmuC3dZQQaxCWhJHFhjBNFrI3F/405WiBJ1iYVL poLZLAKqEuserWECsTkFQiVaHzdDzdeSWHbhFhuILSKgIrF82jOoO0MkupqWMUPcLyvx6flP dpAbJARus0nMef+JZQKj0Cwkt85CcussoJOYgXZPmZILEdaWePLuAiuErSax8PciJmTxBYxs qxiFchMzc3Qz80z0EgsKclL1kvNzNzGCImO6ndAOxlOrrA4xCnAwKvHwRki5RAixJpYVV+Ye YpTmYFES573SDBQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAuPCcm/ulx/XLXeVjPGfFTN1m J/Wob6k/89fyfVvmq2yKmXj15N9jIYKbZgd25zUv2Ncy7UhOcQbbN4Y5V3dJxOaxWlR9mq39 3TQhfHKP7aKOysXOagc5svsPzF/wMlnwk63XUj0Rl0SJXG6d7N1/BIpdZC0MJ8ut0cxgZk32 36Rg8G7ZM7t1SizFGYmGWsxFxYkA4pz9TW0CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrIIsWRmVeSWpSXmKPExsUiON1OVXe+hGuEQet3Zosti7pZLOa3LmOz uLy7kcmB2WPJkp9MHou3vGX0WLPvB0sAcxSXTUpqTmZZapG+XQJXxsOe3cwFty0q2jaGNzB+ 1e9i5OCQEDCRWHJKqouRE8gUk7hwbz1bFyMXh5DAMkaJry8aWUESvAKCEj8m32MBsZkFwiT+ Pd7MAlHUzySxreMBM0hCWEBaouvCXVaQoWwCWhIH1hhB9NpI3N+4kxWiRF1i4ZKpYDaLgKrE ukdrmEBsToFQidbHzVDztSSWXbjFBmKLCKhILJ/2jB3EFhIIkehqWsYMcaisxKfnP9knMArM QnLeLCTnzQK6ghlo3ZQpuRBhbYkn7y6wQthqEgt/L2JCFl/AyLaKUaAoNSex0lgvsaAgJ1Uv OT93EyMoxBsKg3cw/llmdYhRgINRiYd3g4xLhBBrYllxZe4hRgkOZiUR3gRh1wgh3pTEyqrU ovz4otKc1OJDjBMZgZ6cyCwlmpwPjMC8knhDExMDE2NjM2NjcxNzWgorifNGsjpFCAmkJ5ak ZqemFqQWwRzFxMEp1cBYe76vRPic85v8tbsPbQsNFIrt0/h8/v7ug9UyMp93+23oT04st1by 7Z28zmpa49lHG9fqaLvtO/ukw+KSbf+fbr+2eW2VjTd3xvJ4Rmz1LVltvvGdWP/txfU1r3Tr Vs4u2lfX1XxfRVv94/RlG9xSRG8uXKGQwP/Hstn72o0vS5af++PV8o9ViaU4I9FQi7moOBEA o97gn+QCAAA= Archived-At: Cc: zhang.zheng@zte.com.cn, babel@ietf.org Subject: Re: [babel] Redefining updates 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, 05 Dec 2016 07:34:57 -0000 --Boundary_(ID_/vpNJ6w2ifiYY7467IbXLg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Juliusz, I agree with this change. This was an area that tripped me up when first = implementing. The new proposal is simpler and more future-proof. David > On Dec 4, 2016, at 22:35, zhang.zheng@zte.com.cn wrote: >=20 >=20 > Hi Juliusz,=20 >=20 > Glad to see your modification consideration of the prefix section.=20= > I agree to the meaning extension of AE. And I think that the name=20 > changing may be not necessary. Because most of the info can be = delivered=20 > by sub-TLVs of prefix. The content can be distinguished from the type = of=20 > sub-TLVs or other ways.=20 >=20 > Thanks,=20 > Sandy=20 >=20 >=20 > "babel" =E5=86=99=E4=BA=8E 2016/12/04 = 01:20:06: >=20 > > RFC 6126 Updates are not defined well. > >=20 > > RFC 6126 Section 4.4.9 says: > >=20 > > o if the bit with value 80 hexadecimal is set, then this Update > > establishes a new default prefix for subsequent Update TLVs with = a > > matching address family within the same packet; > >=20 > > This assumes that an implementation is able to match an AE with an = address > > family. Not only does this complicate the definition of new AEs = (which > > must specify which family they belong to), but it's not entirely = clear > > what to do with AEs that don't map cleanly to an address family, = such as > > source-specific routes, MPLS or BIER. > >=20 > > I'm planning to make an incompatible change (but one that will not = break > > existing implementations): the implicit prefix established by flag = 0x80 > > will be per-AE. This makes the semantics easier to implement and = easier > > to understand, at a slight cost in compression efficiency. It will = not > > break existing implementations (since AEs 1 and 2 are the only ones > > carried in updates by existing implementations). > >=20 > > Comments? While I'm at it, should I rename the "Prefix" field to > > "Opaque", since future extensions might use it for carrying things = other > > than prefixes? > >=20 > > -- Juliusz > >=20 > >=20 > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://www.ietf.org/mailman/listinfo/babel > >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --Boundary_(ID_/vpNJ6w2ifiYY7467IbXLg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Juliusz,

I = agree with this change. This was an area that tripped me up when first = implementing.
The new proposal is simpler and more = future-proof.

David


On Dec 4, 2016, at 22:35, zhang.zheng@zte.com.cn wrote:


Hi = Juliusz,

  =   Glad to see your modification consideration of the prefix section.
I agree = to the meaning extension of AE. And I think that the name
changing = may be not necessary. Because most of the info can be delivered
by = sub-TLVs of prefix. The content can be distinguished from the type of
sub-TLVs = or other ways.

Thanks,
Sandy


"babel" <babel-bounces@ietf.org> =E5=86=99=E4=BA=8E 2016/12/04 01:20:06:

> RFC 6126 Updates are not defined well.
>
> RFC 6126 Section 4.4.9 says:
>
> o  if the bit with value 80 hexadecimal is set, then this = Update
>    establishes a new default prefix for subsequent Update TLVs with a
>    matching address family within the same packet;
>
> This assumes that an implementation is able to match an AE with an address
> family.  Not only does this complicate the definition of new AEs (which
> must specify which family they belong to), but it's not entirely = clear
> what to do with AEs that don't map cleanly to an address family, = such as
> source-specific routes, MPLS or BIER.
>
> I'm planning to make an incompatible change (but one that will not break
> existing implementations): the implicit prefix established by flag 0x80
> will be per-AE.  This makes the semantics easier to implement and easier
> to understand, at a slight cost in compression efficiency.  It will not
> break existing implementations (since AEs 1 and 2 are the only = ones
> carried in updates by existing implementations).
>
> Comments?  While I'm at it, should I rename the "Prefix" field to
> "Opaque", since future extensions might use it for carrying things other
> than prefixes?
>
> -- Juliusz
>
>
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
>
_______________________________________________
babel = mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel

= --Boundary_(ID_/vpNJ6w2ifiYY7467IbXLg)-- From nobody Mon Dec 5 01:44:30 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0134D1297E7 for ; Mon, 5 Dec 2016 01:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvAWB0pq8lyA for ; Mon, 5 Dec 2016 01:44:27 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::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 33AE312940F for ; Mon, 5 Dec 2016 01:44:27 -0800 (PST) Received: from mail.toke.dk (localhost.localdomain [127.0.0.1]) by mail.toke.dk (Postfix) with ESMTPS id D351215818; Mon, 5 Dec 2016 10:44:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1480931062; bh=0DnV+h98oSraEnr0rTS1kMQq1kc0Va422d8Bxy8Q7k0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=uxh3P6M0ecgC6Yk7I0dadAqTl0FbMoI0gJ3EzaF6ZeWWAyM6IZKw2zVzaAJ5Kb4up eZkeuKDrxIkppScqLatAzfxoXOJoFTyICZhNUSGw9cdv+5ENmLG/z12YKj4Zo1NJSG j5PM7uWTp0zLzYT3O7bVyYy/Ew0MGkTmHKwvd92g4Djemba48Ma+yR4GRFnHAklrUb BhZu2QdVOo9miH3DcH9tXyfyVcXYyyndWATlAuB6qNIJOEJDabpTJ6UDT6u5tbF9wT /HpQGjtmg/tdaHYBfPH4ouXelysOQr0Mkj1A47bGjZG8DWcWJmMa8dsOhHlNRNUCCf 8IpjbghvLsnMQ== Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id B29EB9885E2; Mon, 5 Dec 2016 10:44:22 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: David Schinazi References: <70E521A2-2946-43B1-A347-07868473AAED@apple.com> Date: Mon, 05 Dec 2016 10:44:22 +0100 In-Reply-To: <70E521A2-2946-43B1-A347-07868473AAED@apple.com> (David Schinazi's message of "Sun, 04 Dec 2016 23:34:54 -0800") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <8760mylngp.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: zhang.zheng@zte.com.cn, babel@ietf.org, Juliusz Chroboczek Subject: Re: [babel] Redefining updates 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, 05 Dec 2016 09:44:29 -0000 David Schinazi writes: > Juliusz, > > I agree with this change. This was an area that tripped me up when first implementing. > The new proposal is simpler and more future-proof. +1 -Toke From nobody Mon Dec 5 17:01:45 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED9E129646 for ; Mon, 5 Dec 2016 17:01:44 -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 4hK_RX4zYk4H for ; Mon, 5 Dec 2016 17:01:42 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1111295C1 for ; Mon, 5 Dec 2016 17:01:41 -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 uB611djG026250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 6 Dec 2016 02:01:39 +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 uB611c7w025297 for ; Tue, 6 Dec 2016 02:01:39 +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 EC7A7D78B9 for ; Tue, 6 Dec 2016 02:01:38 +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 HzdIT-oiugOq for ; Tue, 6 Dec 2016 02:01:37 +0100 (CET) Received: from trurl.irif.fr (unknown [78.250.65.94]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D3F32D7880 for ; Tue, 6 Dec 2016 02:01:36 +0100 (CET) Date: Tue, 06 Dec 2016 02:01:46 +0100 Message-ID: <87twahj2f9.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, 06 Dec 2016 02:01:39 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 06 Dec 2016 02:01:39 +0100 (CET) X-Miltered: at korolev with ID 58460DF3.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58460DF2.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58460DF3.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58460DF2.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 : 58460DF3.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58460DF2.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] Forwarding of seqno requests is not specified well enough 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, 06 Dec 2016 01:01:44 -0000 RFC 6126 Section 3.8.1.2 says: If the requested router-id is not its own, the received request's hop count is 2 or more, and the node has a route (not necessarily a feasible one) for the requested prefix that does not use the requestor as a next hop, the node SHOULD forward the request. It does so by decreasing the hop count and sending the request in a unicast packet destined to a neighbour that advertises the given prefix (not necessarily the selected neighbour) and that is distinct from the neighbour from which the request was received. This is not well specified. I don't have a minimal algorithm, but the following algorithm is provably complete: If the node has at least one feasible route towards for the requested prefix that does not use the requestor as a next hop, it MUST forward the request in a unicast packet to the next hop associated with one of these feasible routes (typically the selected route). Otherwise, if the node has an unfeasible route towards the requested prefix, it MAY forward the request in a unicast packet to the next hop associated with one of these routes. The second paragraph is not technically required, but it may speed up convergence, and is consistent with existing implementations. Paragraph 3.8.2.1 also needs to be more precise. It currently says A node that has lost all feasible routes to a given destination MUST send a seqno request. [...] Such a request SHOULD be multicast over all of the node's attached interfaces. This is neither minimal nor complete. For completeness, a node that has at least one neighbour that has recently announced a route to the lost prefix MUST send the request to at least such neighbour, either by unicasting it or by multicasting it. For minimality, a node that has no such neighbour SHOULD NOT send the request. This does not match current implementations. -- Juliusz From nobody Sat Dec 10 14:01:02 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DD7129518 for ; Sat, 10 Dec 2016 14:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWkp8dWio26p for ; Sat, 10 Dec 2016 14:00:58 -0800 (PST) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91AE61294BC for ; Sat, 10 Dec 2016 14:00:58 -0800 (PST) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1481407251931179.93074501112733; Sat, 10 Dec 2016 14:00:51 -0800 (PST) Date: Sat, 10 Dec 2016 22:00:51 +0000 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <158eac0c5d5.edf587a130439.861510537051207954@ovsienko.info> In-Reply-To: <87shqpjrwk.wl-jch@irif.fr> References: <87shqpjrwk.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] Summary of my comments about Denis' talk X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 22:01:00 -0000 ---- On Fri, 18 Nov 2016 05:09:15 +0000 Juliusz Chroboczek wrote ---- >Concerning Denis' talk, I'm of the opinion that Appendix A should remain >an informative appendix. Further constraining neighbour discovery and >link-quality sensing should only be done as a last recourse, and after >serious thought. > >It is intended by the protocol that a neighbour only exists after it sent >a Hello. If that's not clear in the spec, it should be clarified, or else >a different policy defined. I'm not sure it matters much, though. > >The spec is very clear about Acks: after your receive an Ack Request, you >MUST send an Ack within the deadling. No other requirements are made -- >how to deal with missed Acks is an implementation issue. Hello Juliusz and all. This was the first section of the talk, please find particular changes I propose to address most of it in this pull request: https://github.com/jech/babel-drafts/pull/2 >I believe that there is consensus that Hellos should not be further >constrained (thanks, David). If the HMAC extension needs extra data, it >can put further constraints when HMAC is enabled -- for example, HMAC >could require the RTT extension (which is pretty cool, but requires >generating a timestamp for every Hello packet -- is that prohibitive?), or >it can put its own sub-TLV in Hello, or it can require that Hellos only be >sent in a packet that carries a TS TLV. (The RTT extension does something >similar -- it requires that IHUs be only sent in packets that carry a Hello.) This was the second, for which I don't yet have a solution more particular than the discussion made during the talk. -- Denis Ovsienko From nobody Sun Dec 11 15:33:11 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201B81297EE for ; Sun, 11 Dec 2016 15:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDiyY8xFjYXs for ; Sun, 11 Dec 2016 15:33:08 -0800 (PST) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96EC12953A for ; Sun, 11 Dec 2016 15:33:08 -0800 (PST) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1481499183603216.63356971545102; Sun, 11 Dec 2016 15:33:03 -0800 (PST) Date: Sun, 11 Dec 2016 23:33:03 +0000 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <158f03b89ed.11c4323dd38877.6995881645496107685@ovsienko.info> 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: [babel] [PATCH 1/4] address IETF-97 slides section I point 1 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, 11 Dec 2016 23:33:10 -0000 "Some of the thinking made in Appendix A.1 looks normative and could make Section 3 (Protocol Operation) more complete if moved there." This change in the middle of "Reverse Reachability Detection" adds one specific piece that was missing: the document did specify updating and flushing of a neighbour entry, now it also specifies initialization. --- draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml b/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml index bac204b..9fa18c4 100644 --- a/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml +++ b/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml @@ -703,7 +703,9 @@ decreased at any time; it SHOULD NOT be increased, except immediately before sending a Hello packet. (Equivalently, a node SHOULD send an unscheduled Hello immediately after increasing its Hello interval.) -How to deal with received Hello TLVs and what statistics to maintain +A node that receives a Hello TLV from an unknown neighbour creates a new +entry in the neighbour table and sets its txcost to infinity. How to deal +with the received Hello TLVs further and what statistics to maintain are considered local implementation matters; typically, a node will maintain some sort of history of recently received Hellos. A possible algorithm is described in . -- 2.7.4 -- Denis Ovsienko From nobody Sun Dec 11 15:34:24 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563E51297EE for ; Sun, 11 Dec 2016 15:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhHr5klPlJ13 for ; Sun, 11 Dec 2016 15:34:21 -0800 (PST) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B6BF12953A for ; Sun, 11 Dec 2016 15:34:21 -0800 (PST) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1481499257373647.9463305419096; Sun, 11 Dec 2016 15:34:17 -0800 (PST) Date: Sun, 11 Dec 2016 23:34:17 +0000 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <158f03caa17.f99ff21138897.6561785689073232467@ovsienko.info> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: MEDIUM User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: [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: Sun, 11 Dec 2016 23:34:22 -0000 "The specification should explicitly state that the =E2=80=9Cgreen=E2=80=9D= TLVs must be ignored unless they come from a valid neighbour..." This change at the end of "Bidirectional Reachability Detection" adds respective normative text. --- draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml b/= draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml index 9fa18c4..d4dd853 100644 --- a/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml +++ b/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml @@ -746,6 +746,15 @@ a small multiple of the value received in the IHU. neighbour's cost () and runs the route selection procedure (). =20 +The bidirectional reachability detection is a prerequisite for the +routing information exchange and processing. Specifically, a node MUST ign= ore: + + any TLV except Hello if received from a neighbour that does not have = an + entry in the neighbour table, and + any TLV except Hello and IHU if received from a neighbour that has an + entry in the neighbour table with txcost equal to infinity. + + =20
--=20 2.7.4 --=20 Denis Ovsienko From nobody Sun Dec 11 15:35:07 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D315D1297EE for ; Sun, 11 Dec 2016 15:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_Ryjjmy09Py for ; Sun, 11 Dec 2016 15:35:04 -0800 (PST) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B193212953A for ; Sun, 11 Dec 2016 15:35:04 -0800 (PST) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1481499299920510.5909566489048; Sun, 11 Dec 2016 15:34:59 -0800 (PST) Date: Sun, 11 Dec 2016 23:34:59 +0000 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <158f03d504a.af6b230a38904.1275316408151406007@ovsienko.info> 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: [babel] [PATCH 3/4] address IETF-97 slides section I point 3 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 23:35:06 -0000 "The dependency of a valid neighbour entry on receiving both Hello and IHU TLVs on time may not look obvious but is critical for a correct implementation." This change in the middle of "Neighbour Acquisition" adds a paragraph to clarify that. --- draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml b/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml index d4dd853..4cab5d1 100644 --- a/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml +++ b/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml @@ -687,6 +687,10 @@ bidirectional reachability. On unreliable media, neighbour acquisition additionally provides some statistics that MAY be used in link quality computation. +For the avoidance of doubt, for a neighbour to remain in a stable +bidirectional reachability state it is essential that it keeps sending both +Hello and IHU TLVs on time as specified below. +
Every Babel node sends periodic Hellos over each of its interfaces. -- 2.7.4 -- Denis Ovsienko From nobody Sun Dec 11 15:36:10 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFFC12953A for ; Sun, 11 Dec 2016 15:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5FSNiq3EFie for ; Sun, 11 Dec 2016 15:36:07 -0800 (PST) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924761294AB for ; Sun, 11 Dec 2016 15:36:07 -0800 (PST) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1481499366166190.71903884099095; Sun, 11 Dec 2016 15:36:06 -0800 (PST) Date: Sun, 11 Dec 2016 23:36:06 +0000 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <158f03e5310.e1dc486b38913.7266150446870095483@ovsienko.info> In-Reply-To: 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: [babel] [PATCH 4/4] address IETF-97 slides section I point 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: Sun, 11 Dec 2016 23:36:09 -0000 "Section 3.3 specifies clearly how to respond to an Acknowledgement Request TLV and discusses a bit when to send it but there is nothing defining how to process an expected/unexpected Acknowledgement (response) TLV or a lack of an expected response." This change at the end of "Acknowledged Packets" adds a paragraph stating those details are up to the implementation to confirm this bit was not missed. --- draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml b/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml index 4cab5d1..4d866bb 100644 --- a/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml +++ b/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml @@ -677,6 +677,9 @@ acknowledgement requests is not necessary, and not even recommended, as the acknowledgements cause additional traffic and may force additional Address Resolution Protocol (ARP) or Neighbour Discovery exchanges. +Likewise, it is a matter of the same policy how to handle acknowledgements +that were received without a request or requested but never received. +
-- 2.7.4 -- Denis Ovsienko From nobody Mon Dec 12 08:58:01 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A36129D99 for ; Mon, 12 Dec 2016 08:57:59 -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 NuwtcyN8HvYq for ; Mon, 12 Dec 2016 08:57:57 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8F5129DB0 for ; Mon, 12 Dec 2016 08:56:52 -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 uBCGuoXB011667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 Dec 2016 17:56:50 +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 uBCGuoBf030179; Mon, 12 Dec 2016 17:56:50 +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 5303AD7889; Mon, 12 Dec 2016 17:56:50 +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 RzllY0E25Osy; Mon, 12 Dec 2016 17:56:49 +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 2E3C8D7885; Mon, 12 Dec 2016 17:56:49 +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 1cGTuC-00061Y-Sy; Mon, 12 Dec 2016 17:56:48 +0100 Date: Mon, 12 Dec 2016 17:56:48 +0100 Message-ID: <7ishpt13xr.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko In-Reply-To: <158f03caa17.f99ff21138897.6561785689073232467@ovsienko.info> References: <158f03caa17.f99ff21138897.6561785689073232467@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]); Mon, 12 Dec 2016 17:56:50 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 12 Dec 2016 17:56:50 +0100 (CET) X-Miltered: at korolev with ID 584ED6D2.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 584ED6D2.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 584ED6D2.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 584ED6D2.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 : 584ED6D2.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 584ED6D2.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: Mon, 12 Dec 2016 16:57:59 -0000 > +A node that receives a Hello TLV from an unknown neighbour creates a new > +entry in the neighbour table and sets its txcost to infinity. [...] > +The bidirectional reachability detection is a prerequisite for the > +routing information exchange and processing. Specifically, a node MUST ignore: > + > + any TLV except Hello if received from a neighbour that does not have an > + entry in the neighbour table, and > + any TLV except Hello and IHU if received from a neighbour that has an > + entry in the neighbour table with txcost equal to infinity. > + I am of somewhat mixed mind on this change. While this is certainly what all existing implementations do, I am not sure that it belongs in the base protocol. I can certainly envision an implementation that uses any packet, not only one that contains a Hello, to create a neighbour association. I could even envision an extension that signals neighbourship at the link layer (think Babel over Bluetooth Low Energy). Here, at Babel towers, our policy has been to only add constraints to the protocol in order to solve a problem. So what problem are you trying to solve with this addition? 1. A problem in the base protocol? 2. A problem in HMAC-based authentication? 3. No problem? I understand that you're trying to fix a problem in HMAC-based authentication. If I'm correct, then perhaps this addition belongs in the HMAC document, something like If a node implements this extension, then it MUST NOT create a neighbour entry before receiving a Hello TLV, and MUST silently ignore etc. If I'm wrong, and you're actually fixing an issue in the base protocol, than your additions must explain to the reader why this is essential, not just add a seemingly arbitrary requirement. -- Juliusz From nobody Mon Dec 12 08:58:46 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD5A129D55 for ; Mon, 12 Dec 2016 08:58:45 -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 rPnTFQGrRmJL for ; Mon, 12 Dec 2016 08:58:43 -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 45D1F129454 for ; Mon, 12 Dec 2016 08:57:48 -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 uBCGvkZS012202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 Dec 2016 17:57:46 +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 uBCGvkIH030465; Mon, 12 Dec 2016 17:57:46 +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 90A26D7885; Mon, 12 Dec 2016 17:57:46 +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 uNqu82LFSZag; Mon, 12 Dec 2016 17:57:45 +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 7D4C6D78B9; Mon, 12 Dec 2016 17:57:45 +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 1cGTv7-00061b-7x; Mon, 12 Dec 2016 17:57:45 +0100 Date: Mon, 12 Dec 2016 17:57:45 +0100 Message-ID: <7ir35d13w6.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko In-Reply-To: <158f03d504a.af6b230a38904.1275316408151406007@ovsienko.info> References: <158f03d504a.af6b230a38904.1275316408151406007@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]); Mon, 12 Dec 2016 17:57:46 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 12 Dec 2016 17:57:46 +0100 (CET) X-Miltered: at korolev with ID 584ED70A.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 584ED70A.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 584ED70A.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 584ED70A.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 584ED70A.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 584ED70A.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: Babel at IETF Subject: Re: [babel] [PATCH 3/4] address IETF-97 slides section I point 3 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 16:58:45 -0000 > +For the avoidance of doubt, for a neighbour to remain in a stable > +bidirectional reachability state it is essential that it keeps sending both > +Hello and IHU TLVs on time as specified below. I don't understand this sentence. Is it an additional requirement for implementations (in which case it should be stated in terms of MUST), or is it just rephrasing what the document already says? -- Juliusz From nobody Mon Dec 12 10:14:16 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEBA1294B8 for ; Mon, 12 Dec 2016 10:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbtrnoFr8BFV for ; Mon, 12 Dec 2016 10:14:12 -0800 (PST) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68BB01294B1 for ; Mon, 12 Dec 2016 10:14:12 -0800 (PST) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 148156644595225.30290884850899; Mon, 12 Dec 2016 10:14:05 -0800 (PST) Date: Mon, 12 Dec 2016 18:14:05 +0000 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <158f43de17b.c4a1eb0f15012.1465924192497187566@ovsienko.info> In-Reply-To: <7ir35d13w6.wl-jch@irif.fr> References: <158f03d504a.af6b230a38904.1275316408151406007@ovsienko.info> <7ir35d13w6.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 3/4] address IETF-97 slides section I point 3 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 18:14:13 -0000 ---- On Mon, 12 Dec 2016 16:57:45 +0000 Juliusz Chroboczek wrote ---- >> +For the avoidance of doubt, for a neighbour to remain in a stable >> +bidirectional reachability state it is essential that it keeps sending both >> +Hello and IHU TLVs on time as specified below. > >I don't understand this sentence. Is it an additional requirement for >implementations (in which case it should be stated in terms of MUST), or >is it just rephrasing what the document already says? It is the latter, as the commit message for this change hopefully says (the quoted text below is from the slides): -------------------------------------------------- "The dependency of a valid neighbour entry on receiving both Hello and IHU TLVs on time may not look obvious but is critical for a correct implementation." This change in the middle of "Neighbour Acquisition" adds a paragraph to clarify that. -------------------------------------------------- Saying the same in other words would be: The stated dependency can be _derived_ from the current document if the reader knows what they are looking for (as I did to produce the FSM diagram). But if they don't look for it on purpose they can make an implementation mistake. This way this statement in this section to me looks as a simple way to avoid a possible waste of time. -- Denis Ovsienko From nobody Mon Dec 12 10:28:12 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0579A1294BF for ; Mon, 12 Dec 2016 10:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCkQp6fFjKAs for ; Mon, 12 Dec 2016 10:28:03 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 01F3B1294A9 for ; Mon, 12 Dec 2016 10:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1481567282; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=crRZ3e5W3Y9XbBqTL3Kcq6MNGGtacFLR0g7aXoRThDQ=; b=DmMajJCz2vODweelUFq0ORmKPbadzd8bGQK2b6igskKAb24x6plOUtF4Fd3k/QEi jGSFci+tl0ikb4q11v+E7/mTbH0zLmsGWd/dN6o2neLu9xacWMqkHAFZknYHdwst /8a/TPEL4Ar5HYQUs+MjetgwP8DGalPiJpzRPSrccIVZ7rcE9mpmOoa+1WIcDIjb 90NJxDjv5DZJGkKNEJM4e2AnBrcZ5Z4u1EcGLz4YWI1p6XGt5KVz6JZOD1DgxRtl SPVdxIkkNmbDpSqiT69ivx+DQNfaMqZ857RTVHy9l7fAr9XKSYJ9IoP4nQBzjkHB QlBkj7tWLJduBVddBL456w==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id EC.56.03436.23CEE485; Mon, 12 Dec 2016 10:28:02 -0800 (PST) X-AuditID: 11973e12-ad9569a000000d6c-77-584eec323603 Received: from koseret (koseret.apple.com [17.151.62.39]) by relay4.apple.com (Apple SCV relay) with SMTP id 1F.34.20305.23CEE485; Mon, 12 Dec 2016 10:28:02 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_rb9BdVpoXpM1KQTQ+homtQ)" Received: from [17.153.39.19] (unknown [17.153.39.19]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.0 64bit (built Sep 28 2016)) with ESMTPSA id <0OI3003H04MNG240@koseret.apple.com>; Mon, 12 Dec 2016 10:28:02 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi Message-id: <4A81578C-8CA7-4FF2-BBF4-EB3F7A72FE76@apple.com> Date: Mon, 12 Dec 2016 10:27:59 -0800 In-reply-to: To: Dave Taht References: X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUi2FAYrmv0xi/C4NxHE4uvnxtYLLYs6max 2LPxJIsDs8fOWXfZPZYs+cnk8eZQH0sAcxSXTUpqTmZZapG+XQJXxsP2HtaC464Vq09NYGxg nGbdxcjJISFgInFr2gfWLkYuDiGBvYwS845eYYdJPPqzgAnEFhJYxSixeEIKiM0rICjxY/I9 FhCbWSBMYu+1FywQzb8YJd7dngjWLCwgLdF14S7QVA4ONgEtiQNrjCB6bSSaHnQxQZRYSVxs 6GcGsVkEVCV+bNgGNpNTIFiifcIqqPmJEhMa5zOC2CICyhJT7p9gh7gnQKL52RKoO2UlPj3/ CWVfZ5N4tU9tAqPQLCSnzkJy6iygi5gF1CWmTMmFCGtLPHl3gRXCVpNY+HsRE7L4Aka2VYxC uYmZObqZeSZ6iQUFOal6yfm5mxhBsTHdTmgH46lVVocYBTgYlXh4BTb5RQixJpYVV+YeYpTm YFES5+V/DBQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAWOr6q7r1uALvtuCibdc2Ny17lm+1 y3QN26aUvXqr/qcyuMfvUt9hvUtiU0NSpUm1X9eaN8xfdIo2pdpYZJrO1jo7n0lLZf+09Ufe bszOWtRWraDav25truFi75OT7TxfJv/4WJcTuCI/7pvSXP0L+3Z2PDV60T3rsfeTj/KpzFN3 2wefVjMzVGIpzkg01GIuKk4EADWQXCJuAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEIsWRmVeSWpSXmKPExsUiON1OXdfojV+EweILehZfPzewWGxZ1M1i sWfjSRYHZo+ds+6yeyxZ8pPJ482hPpYA5igum5TUnMyy1CJ9uwSujIftPawFx10rVp+awNjA OM26i5GTQ0LAROLRnwVMELaYxIV769lAbCGBVYwSiyekgNi8AoISPybfYwGxmQXCJPZeewFk cwHV/GKUeHd7IjtIQlhAWqLrwl3WLkYODjYBLYkDa4wgem0kmh50MUGUWElcbOhnBrFZBFQl fmzYBjaTUyBYon3CKqj5iRITGuczgtgiAsoSU+6fYIe4J0Ci+dkSdog7ZSU+Pf/JPoFRYBaS 82YhOW8W0BXMAuoSU6bkQoS1JZ68u8AKYatJLPy9iAlZfAEj2ypGgaLUnMRKE73EgoKcVL3k /NxNjKAgbygM38H4b5nVIUYBDkYlHl6BTX4RQqyJZcWVuYcYJTiYlUR4Zz0BCvGmJFZWpRbl xxeV5qQWH2KcyAj05ERmKdHkfGAM5pXEG5qYGJgYG5sZG5ubmNNSWEmc19LZO0JIID2xJDU7 NbUgtQjmKCYOTqkGRq/N/3Iksn1nZgq9/ljCMPG93Y2yG194Qz+1hnLL2q67InS//qDTblGF G2viDBf3TBUsdLnDrLHSq1Fq0jV+hvrJubn923ZN/G8syBYW6fQ9g7/t8J+6zBq/505TBT9n dcbWtBgcazyj8WbuzokX1256bSevlXpzsh2/+uZz8bPc1/pPeqn+UYmlOCPRUIu5qDgRAH7O DljlAgAA Archived-At: Cc: "babel-users@lists.alioth.debian.org" , babel@ietf.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, 12 Dec 2016 18:28:10 -0000 --Boundary_(ID_rb9BdVpoXpM1KQTQ+homtQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Dave, Thanks for writing this up, it's an interesting read. I agree with you on the topic of multicast. My implementation sends everything unicast, with the exception of Hellos. I'm interested in working on a way to allow unicast Hellos. I read your thoughts here: https://github.com/dtaht/rabeld/blob/master/babel_unicast_hello.md = and was thinking that we might be able to make this even simpler, by adding a new "I support unicast Hellos" bit in the IHU Reserved = field. That way when a node appears on a link, they send a multicast Hello, and get IHUs in response. If all the IHUs have this bit, then the router can go into unicast Hello mode. Similarly, when a node sees a new neighbor, it sends it an IHU with this bit and if it receives a unicast Hello from that node it knows they are supported, otherwise falls back to multicast. You could then have different intervals for multicast and unicast Hellos, with the multicast one being potentially much higher. This proposal stays in the spirit of current Hellos as a measure for packet loss rate. If as you describe this isn't a great metric, we could take this thought process even further and simply get rid of Hellos for link quality estimation. You would still have multicast = Hellos to detect new peers, but you can estimate by-directional reachability simply by noticing of you receive any Babel packet from a host, and IHU for the reverse direction. This makes particular sense if you were able to query your link-layer for information on how many retransmissions are required on average to reach that host, and what rate the Wi-Fi chip is operating at. Thoughts? David > On Dec 12, 2016, at 09:25, Dave Taht wrote: >=20 > I've long been testing a few out of tree patches for babel and long > have had the intent to try a few more once the first phase of the > make-wifi-fast work was completed - which it mostly is, so far as lede > is concerned ( https://lwn.net/Articles/705884/ ) - and babel-1.8 > stablized. >=20 > I wrote up some of my thinking then in: >=20 > https://github.com/dtaht/rabeld/blob/master/rabel.md >=20 > back when we were having powersave issues affecting multicast (which I > hope is now fixed), but I've partially deployed the "mo' unicast" > patch around my testbed with no ill results. >=20 > Another thing that has come up a lot lately is the default gateway > failing for some reason or another, tighter integration with > babel-pinger might help. >=20 > And lastly, I had a chance to look at some packet captures from the > wlan-slovenia network, which is essentially flat, and is sending 14 > packets worth of route information on a regular basis. Finding ways to > attenuate and create covering routes, and make DV more DV would be > nice. >=20 > I'd also written up some partially crazy thoughts towards a unicast > hello extension in the same repo. >=20 > --=20 > Dave T=C3=A4ht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org >=20 > _______________________________________________ > Babel-users mailing list > Babel-users@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users --Boundary_(ID_rb9BdVpoXpM1KQTQ+homtQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Dave,

Thanks for writing this up, it's an interesting = read.
I agree with you on the topic of multicast. = My implementation sends
everything unicast, with = the exception of Hellos. I'm interested in
working = on a way to allow unicast Hellos. I read your thoughts here:
https://github.com/dtaht/rabeld/blob/master/babel_unicast_hello= .md

and = was thinking that we might be able to make this even simpler,
by adding a new "I support unicast Hellos" bit in the IHU = Reserved field.
That way when a node appears on a = link, they send a multicast Hello,
and get IHUs in = response. If all the IHUs have this bit, then the router
can go into unicast Hello mode. Similarly, when a node sees a = new
neighbor, it sends it an IHU with this bit and = if it receives a unicast
Hello from that node it = knows they are supported, otherwise falls back
to = multicast. You could then have different intervals for multicast = and
unicast Hellos, with the multicast one being = potentially much higher.

This proposal stays in the spirit of current Hellos as a = measure for
packet loss rate. If as you describe = this isn't a great metric, we
could take this = thought process even further and simply get rid of
Hellos for link quality estimation. You would still have = multicast Hellos
to detect new peers, but you can = estimate by-directional reachability
simply by = noticing of you receive any Babel packet from a host, and
IHU for the reverse direction. This makes particular sense if = you were
able to query your link-layer for = information on how many
retransmissions are = required on average to reach that host, and what
rate= the Wi-Fi chip is operating at.

Thoughts?
David


On Dec 12, 2016, at 09:25, Dave Taht <dave.taht@gmail.com>= wrote:

I've long been testing a few out of tree patches for babel = and long
have had the intent to try a few more once the = first phase of the
make-wifi-fast work was completed - = which it mostly is, so far as lede
is concerned ( https://lwn.net/Articles/705884/ ) - and babel-1.8
stablized.

I wrote up some of my = thinking then in:

https://github.com/dtaht/rabeld/blob/master/rabel.md

back when we were having powersave issues = affecting multicast (which I
hope is now fixed), but I've = partially deployed the "mo' unicast"
patch around my = testbed with no ill results.

Another thing = that has come up a lot lately is the default gateway
failing= for some reason or another, tighter integration with
babel-pinger might help.

And = lastly, I had a chance to look at some packet captures from the
wlan-slovenia network, which is essentially flat, and is = sending 14
packets worth of route information on a regular = basis. Finding ways to
attenuate and create covering = routes, and make DV more DV would be
nice.
I'd also written up some partially crazy thoughts towards a = unicast
hello extension in the same repo.

--
Dave T=C3=A4ht
Let's go make = home routers and wifi faster! With better software!
http://blog.cerowrt.org

_______________________________________________
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-u= sers

= --Boundary_(ID_rb9BdVpoXpM1KQTQ+homtQ)-- From nobody Mon Dec 12 11:22:17 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B64129715 for ; Mon, 12 Dec 2016 11:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 yhyVwPj7wYjU for ; Mon, 12 Dec 2016 11:22:12 -0800 (PST) Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.231]) by ietfa.amsl.com (Postfix) with ESMTP id 4C58612970F for ; Mon, 12 Dec 2016 11:22:12 -0800 (PST) Received: from [127.0.0.1] (80.220.131.63) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 5782991C052F0F5E; Mon, 12 Dec 2016 21:19:26 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Markus Stenberg In-Reply-To: <4A81578C-8CA7-4FF2-BBF4-EB3F7A72FE76@apple.com> Date: Tue, 13 Dec 2016 04:21:51 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <065ED768-44B0-4F61-BE7D-B2DE19F0611C@iki.fi> References: <4A81578C-8CA7-4FF2-BBF4-EB3F7A72FE76@apple.com> To: David Schinazi X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Dave Taht , babel@ietf.org, "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, 12 Dec 2016 19:22:15 -0000 > On 13.12.2016, at 3.27, David Schinazi wrote: .. > and was thinking that we might be able to make this even simpler, > by adding a new "I support unicast Hellos" bit in the IHU Reserved = field. > That way when a node appears on a link, they send a multicast Hello, > and get IHUs in response. If all the IHUs have this bit, then the = router > can go into unicast Hello mode. Similarly, when a node sees a new > neighbor, it sends it an IHU with this bit and if it receives a = unicast > Hello from that node it knows they are supported, otherwise falls back > to multicast. You could then have different intervals for multicast = and > unicast Hellos, with the multicast one being potentially much higher. Personally I like the idea of having very infrequent multicast hellos = and common unicast ones (if called for). The extra complexity is the = only downside I see in this scheme.=20 I am not even sure you need separate mode for it in the specification = ('all IHUs'; tricky on e.g. adhoc); you can simply locally configure a = long-ish multicast hello interval, and opt for shorter unicast hellos if = you feel like it with consenting peers (that have indicated consent by = sending IHU with uhello support). Mandating two separate modes should not be necessary but for QoL it = might be an implementation option anyway. Depends on how many orders of = magnitude fewer you would make normal hello interval as opposed to = uhello one.=20 So the question becomes then whether it is worth having uhello support = bit + separate uhello message in the specification (+ some edits related = to it), and then leave their implementation details open. > This proposal stays in the spirit of current Hellos as a measure for > packet loss rate. If as you describe this isn't a great metric, we > could take this thought process even further and simply get rid of > Hellos for link quality estimation. You would still have multicast = Hellos > to detect new peers, but you can estimate by-directional reachability > simply by noticing of you receive any Babel packet from a host, and > IHU for the reverse direction. This makes particular sense if you were > able to query your link-layer for information on how many > retransmissions are required on average to reach that host, and what > rate the Wi-Fi chip is operating at. I am not a fan of using multicast for estimating unicast link quality = anyway. Typically, multicast drop rates are higher (IIRC, cannot be = bothered to look up a reference right now, sorry, it is 4am) than = unicast ones. Therefore estimates generated from uhellos would be better = anyway. Cheers, -Markus= From nobody Mon Dec 12 13:21:09 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B80129483 for ; Mon, 12 Dec 2016 13:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.198 X-Spam-Level: X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JL31cIn9B6OS for ; Mon, 12 Dec 2016 13:21:03 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 62600126BF7 for ; Mon, 12 Dec 2016 13:21:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1481577663; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pjB4L83/s0t66MWLAkmiSEBdc2TRJNcuKqtu72Gqp7E=; b=DzOFo7aTVYEx9j+3+CG0u8dvjQR6rqHC4cJ5iRbkPrCKNJs2s00yh6y7KvjFU8hk PDIT2Y5eM2BZRR7T2GEOnQjDP5xF4bbMaMxEhq1bl+3BWE+IlZuvy7Bo4tK7l1uP DWmC/P1J3yNmagTn9IYVz9jM7ppf+qcYrJYBQSlRt2nNRu4+wEDW/GZZqQOu1wJx A0AahSCgbM8venlEc1GmHx8xurdt03aSC49Yl5d2KxsMSewjsFKvZ4B5Q5Qxtm+O tEVcnwOBebFkWTCF4pHUmfl0dfqEncbmt3wng8HjCDRRiJG37pRjQx5gZMaDXTbj sLDT/y6WdgfgIOCGhK8EMg==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 36.64.25425.EB41F485; Mon, 12 Dec 2016 13:21:03 -0800 (PST) X-AuditID: 11973e13-d93ff70000006351-70-584f14be149b Received: from koseret (koseret.apple.com [17.151.62.39]) by relay4.apple.com (Apple SCV relay) with SMTP id 3E.A2.20305.EB41F485; Mon, 12 Dec 2016 13:21:02 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.39.19] (unknown [17.153.39.19]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.0 64bit (built Sep 28 2016)) with ESMTPSA id <0OI300M0GCN2IG10@koseret.apple.com>; Mon, 12 Dec 2016 13:21:02 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <7ishpt13xr.wl-jch@irif.fr> Date: Mon, 12 Dec 2016 13:21:01 -0800 Message-id: References: <158f03caa17.f99ff21138897.6561785689073232467@ovsienko.info> <7ishpt13xr.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUi2FAYrrtfxD/CYPlKYYsti7pZLObc+s5i Mb91GZsDs8eSJT+ZPBZvecvoseLkRrYA5igum5TUnMyy1CJ9uwSujCszxQp2iFXMf36VvYHx l2AXIyeHhICJxL2fO5m6GLk4hAT2Mkpsud/GBpM4PGc/G0RiFaPEq3Pr2EESvAKCEj8m32Pp YuTgYBaQlzh4XhYkzCygJfH9USsLRP0vRolLjXeYQBLCAtISXRfuskLYnhJtPcsZQXrZgBoO rDECCXMKaEj8urYLrIRFQFXiw8afjBAzPSQ6mv+yQay1keh82cACYgsJpEus2roNLC4ioCKx fNozdoibZSU+Pf8JZR9gk+g/ajOBUXgWkqtnIVw9C8nVCxiZVzEK5SZm5uhm5pnqJRYU5KTq JefnbmIEBfp0O+EdjKdXWR1iFOBgVOLhFdjkFyHEmlhWXJl7iFGag0VJnPffI6CQQHpiSWp2 ampBalF8UWlOavEhRiYOTqkGRhF3o91fC9r+cXYdyD/u8jbObLP999UHijsnzlZw5V98Yc6O eadlNj3zuL/2U2Hpn1dnH+tYJJ/+eKHZcmKphW6fpO42g5T6Q7xa++s3X3ygcttPpmNF2KSZ 24y7dt2ZvrpeLKSiLuhkr1D44YVskwJb3k7U+X29bO21zyl7vZLDfq579ay146ASS3FGoqEW c1FxIgCCcl2/VQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42IRnG6nrrtPxD/C4MseOYsti7pZLObc+s5i Mb91GZsDs8eSJT+ZPBZvecvoseLkRrYA5igum5TUnMyy1CJ9uwSujCszxQp2iFXMf36VvYHx l2AXIyeHhICJxOE5+9kgbDGJC/fWA9lcHEICqxglXp1bxw6S4BUQlPgx+R5LFyMHB7OAvMTB 87IgYWYBLYnvj1pZIOp/MUpcarzDBJIQFpCW6LpwlxXC9pRo61nOCNLLBtRwYI0RSJhTQEPi 17VdYCUsAqoSHzb+ZISY6SHR0fyXDWKtjUTnywYWEFtIIF1i1dZtYHERARWJ5dOesUPcLCvx 6flP9gmMgrOQXDoL4dJZSC5dwMi8ilGgKDUnsdJEL7GgICdVLzk/dxMjKGQbCsN3MP5bZnWI UYCDUYmHV2CTX4QQa2JZcWXuIUYJDmYlEV5xfv8IId6UxMqq1KL8+KLSnNTiQ4zJQPdPZJYS Tc4HxlNeSbyhiYmBibGxmbGxuYk5acJK4ryWzt4RQL8mlqRmp6YWpBbBbGHi4JRqYDzFevGq iOK3uUcUV5266h6fNeHVhNVTvKPqW0/5x2/TPbLl+MKP4WfSA12LNco0/tQvD8+ItjhedTZh 78tZ2o/v1t+qv1/ZYV+76fsje9X8n5UHjWuO75m1YOcEp3fu1izrVn7Vd55/8NaHuXrPQm15 jlqdlW18UK+wVJcz/WPjYjmza/HRjy4psRRnJBpqMRcVJwIANfD3Ep0CAAA= Archived-At: Cc: Denis Ovsienko , 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: Mon, 12 Dec 2016 21:21:05 -0000 This change constrains the protocol more, and is not what *all* implementations do, as I have one that doesn't do this. An implementation could still learn useful information from updates from a host that it has not heard Hellos for. Those routes must have an infinite metric but once we do get the hello we could immediately start using them instead of waiting for another update or asking for one explicitly. Unless what I'm describing breaks some of the properties of Babel, I would advise against constraining the protocol in this way. I agree with Juliusz that if this only impacts the authentication extension, then it should be defined alongside the extension and not the core protocol. David > On Dec 12, 2016, at 08:56, Juliusz Chroboczek wrote: > >> +A node that receives a Hello TLV from an unknown neighbour creates a new >> +entry in the neighbour table and sets its txcost to infinity. > > [...] > >> +The bidirectional reachability detection is a prerequisite for the >> +routing information exchange and processing. Specifically, a node MUST ignore: >> + >> + any TLV except Hello if received from a neighbour that does not have an >> + entry in the neighbour table, and >> + any TLV except Hello and IHU if received from a neighbour that has an >> + entry in the neighbour table with txcost equal to infinity. >> + > > I am of somewhat mixed mind on this change. While this is certainly what > all existing implementations do, I am not sure that it belongs in the base > protocol. I can certainly envision an implementation that uses any > packet, not only one that contains a Hello, to create a neighbour > association. I could even envision an extension that signals > neighbourship at the link layer (think Babel over Bluetooth Low Energy). > > Here, at Babel towers, our policy has been to only add constraints to the > protocol in order to solve a problem. So what problem are you trying to > solve with this addition? > > 1. A problem in the base protocol? > 2. A problem in HMAC-based authentication? > 3. No problem? > > I understand that you're trying to fix a problem in HMAC-based > authentication. If I'm correct, then perhaps this addition belongs in the > HMAC document, something like > > If a node implements this extension, then it MUST NOT create a neighbour > entry before receiving a Hello TLV, and MUST silently ignore etc. > > If I'm wrong, and you're actually fixing an issue in the base protocol, > than your additions must explain to the reader why this is essential, not > just add a seemingly arbitrary requirement. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Mon Dec 12 13:24:09 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09DC129C55 for ; Mon, 12 Dec 2016 13:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.198 X-Spam-Level: X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaVQu8-n5wvH for ; Mon, 12 Dec 2016 13:24:06 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 1CC1C129470 for ; Mon, 12 Dec 2016 13:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1481577846; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=w/W8RR6CO0xLjnfdpL5VOQ/JwZ7IYIJbIWBmlvNgsVY=; b=B+OWVQ0t+OIHaP4xBRT1S4iiwrE40J/1pL1hlutBamrFVw/45nIpFhPSExt+rb3Z sDqxn4qh7MFfW0f6R1eYVe0J16VTruc6ltjwbcTCB2hiptCSwyUueKdb9rVXU3jB y3UAy5hvJBW+s2+qYRzSFVVqlCYkItqKMBpryT9Y1R7AIQ9QbQYLNj7mS1IyrGMf nXyV6yHMYgwtPgRDSBfJQXbWN9YBx/4Z8fw5YKqVUKNmwkI9Qfcn4XyiAtZSZfvJ S3DG1EXVmbfDYkEk62zv3Or53BnGb2xFNGoVPWpIAIBr9A3TU8IvxcX8Y/rSy8YA YIunwm6owgTOvjX8vpp29Q==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id D2.C4.25425.5751F485; Mon, 12 Dec 2016 13:24:05 -0800 (PST) X-AuditID: 11973e13-d93ff70000006351-6f-584f15751f68 Received: from kencur (kencur.apple.com [17.151.62.38]) by relay8.apple.com (Apple SCV relay) with SMTP id B9.C0.29380.5751F485; Mon, 12 Dec 2016 13:24:05 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.39.19] (unknown [17.153.39.19]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.2.0 64bit (built Sep 28 2016)) with ESMTPSA id <0OI300D3BCS5SM70@kencur.apple.com>; Mon, 12 Dec 2016 13:24:05 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi X-Priority: Medium In-reply-to: <158f03b89ed.11c4323dd38877.6995881645496107685@ovsienko.info> Date: Mon, 12 Dec 2016 13:24:05 -0800 Message-id: <9914D9F4-2417-4CE8-9391-F4D6F18048A3@apple.com> References: <158f03b89ed.11c4323dd38877.6995881645496107685@ovsienko.info> To: Denis Ovsienko X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUi2FCYplsq6h9h8PadjcWWRd0sFnNufWdx YPJYsuQnk8eKkxvZApiiuGxSUnMyy1KL9O0SuDJeLd3FVrBIoGLx2QVsDYxHeLsYOTkkBEwk Vl9YyNzFyMUhJLCPUeLKxPeMMInOuZNZQWwhgRWMEqfW+oDYvAKCEj8m32PpYuTgYBaQlzh4 XhYkzCygJfH9USsLxJwfjBIfd3QygSSEBaQlui7cZYWwPSUeruljB+llA2o4sMYIYpWQxJYd c8HWcgp4S+ya0AFWwiKgKtH+LQ5ivJLE6m93mCEusJH4seYcE8RlXhIL7rWwgdgiAhoSX7bM Y4YYKSvx6flPdpBzJAR2sEn0d75gmcAoMgvJB7MQPpiF5IMFjMyrGIVyEzNzdDPzTPUSCwpy UvWS83M3MYKCfbqd8A7G06usDjEKcDAq8fAKbPKLEGJNLCuuzD3EKM3BoiTO++8RUEggPbEk NTs1tSC1KL6oNCe1+BAjEwenVAMj55nyu1V3P0e1Le/mjt1tyvb8GbvN1uWLuA4lH9kedLU+ 5Hjnm5TdvM1v/vxwXf96w09Z/ill2zuqfVVcjj6/0TppecC0hazKMxdvzLscOZdBe/+tCm3O GINrFi92nfoRLc1tuzZpypzauy3B/Z0bxeqTji3f6sKm+fiJa9Gyvl0iS2fm8/w4q8RSnJFo qMVcVJwIAA0g4YZXAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42IRnG6nplsq6h9h0P3bwmLLom4Wizm3vrM4 MHksWfKTyWPFyY1sAUxRXDYpqTmZZalF+nYJXBmvlu5iK1gkULH47AK2BsYjvF2MnBwSAiYS nXMns0LYYhIX7q1nA7GFBFYwSpxa6wNi8woISvyYfI+li5GDg1lAXuLgeVmQMLOAlsT3R61A YS6g8h+MEh93dDKBJIQFpCW6LtxlhbA9JR6u6WMH6WUDajiwxghilZDElh1zGUFsTgFviV0T OsBKWARUJdq/xUGMV5JY/e0OM8QFNhI/1pxjgrjMS2LBvRawK0UENCS+bJnHDDFSVuLT85/s ExiFZiE5ehbC0bOQHL2AkXkVo0BRak5ipYVeYkFBTqpecn7uJkZQ0DYUpu1gbFpudYhRgINR iYdXYJNfhBBrYllxZe4hRgkOZiUR3tPC/hFCvCmJlVWpRfnxRaU5qcWHGJOBzp/ILCWanA+M qLySeEMTEwMTY2MzY2NzE3PShJXEeS2cvSOEBNITS1KzU1MLUotgtjBxcEo1MNrO6drDGcRz OOyF/Kp3HpvOByb+YV171/2552Xv3QYMMgdPOrOtcYmceEBgVrmk4kPVVSrJy77K/U18//7E s8zQT9Z2C/N/JDDWdv0rfcwzY3cZy+LfVguPV3Y9ke3R6T/+X2ut4deQ7ZkFeUwxG+YHpTrH O9us3Mb1Sp9Rts9uR93cl7XsfUosxRmJhlrMRcWJAP83oayeAgAA Archived-At: Cc: Babel at IETF Subject: Re: [babel] [PATCH 1/4] address IETF-97 slides section I point 1 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, 12 Dec 2016 21:24:08 -0000 Denis, As discussed in the other thread (patch 2/4), I believe this change unnecessarily constrains the protocol. The existence of a neighbor table is purely an implementation detail that I'd rather keep in an appendix. David > On Dec 11, 2016, at 15:33, Denis Ovsienko wrote: > > "Some of the thinking made in Appendix A.1 looks normative and could > make Section 3 (Protocol Operation) more complete if moved there." > > This change in the middle of "Reverse Reachability Detection" adds one > specific piece that was missing: the document did specify updating and > flushing of a neighbour entry, now it also specifies initialization. > --- > draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml b/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml > index bac204b..9fa18c4 100644 > --- a/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml > +++ b/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml > @@ -703,7 +703,9 @@ decreased at any time; it SHOULD NOT be increased, except immediately > before sending a Hello packet. (Equivalently, a node SHOULD send an > unscheduled Hello immediately after increasing its Hello interval.) > > -How to deal with received Hello TLVs and what statistics to maintain > +A node that receives a Hello TLV from an unknown neighbour creates a new > +entry in the neighbour table and sets its txcost to infinity. How to deal > +with the received Hello TLVs further and what statistics to maintain > are considered local implementation matters; typically, a node will > maintain some sort of history of recently received Hellos. A possible > algorithm is described in . > -- > 2.7.4 > > -- > Denis Ovsienko > > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Mon Dec 12 15:39:00 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EAF129F40 for ; Mon, 12 Dec 2016 15:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCzCeMFJBH7I for ; Mon, 12 Dec 2016 15:38:55 -0800 (PST) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DEBF129F61 for ; Mon, 12 Dec 2016 15:38:10 -0800 (PST) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 148158588558558.109173567469384; Mon, 12 Dec 2016 15:38:05 -0800 (PST) Date: Mon, 12 Dec 2016 23:38:05 +0000 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <158f5668185.1054273aa3805.8956201339893343725@ovsienko.info> In-Reply-To: <7ishpt13xr.wl-jch@irif.fr> References: <158f03caa17.f99ff21138897.6561785689073232467@ovsienko.info> <7ishpt13xr.wl-jch@irif.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail 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, 12 Dec 2016 23:38:58 -0000 ---- On Mon, 12 Dec 2016 16:56:48 +0000 Juliusz Chroboczek wrote ----=20 >> +A node that receives a Hello TLV from an unknown neighbour creates a= new=20 >> +entry in the neighbour table and sets its txcost to infinity.=20 Thank you for the comments. Please note you are now discussing two independ= ent changes at once. Let me try to comment on each one separately. The above proposed change is related to section I point 1 and the commit me= ssage is as follows: ------------------------------------- Some of the thinking made in Appendix A.1 looks normative and could make Section 3 (Protocol Operation) more complete if moved there." This change in the middle of "Reverse Reachability Detection" adds one specific piece that was missing: the document did specify updating and flushing of a neighbour entry, now it also specifies initialization. ------------------------------------- Let me add some detail to the above. So long as the neighbour table is one = of the protocol data structures currently in the document, it is important = to specify how the entries are added, modified and deleted. "Bidirectional = Reachability Detection" defines the modification (one upon receiving an IHU= TLV and another on a missed timer). Appendix A.1 defines when to delete an= entry (perhaps not the best disposition as I tried to explain before but a= t least the wording is in the document, so can be looked at later). But the= re is no text in the document that tells when to add an entry to the table = and how to set txcost. The specification is plainly incomplete without this= and the proposed change solves this particular problem. >[...]=20 >=20 >> +The bidirectional reachability detection is a prerequisite for the= =20 >> +routing information exchange and processing. Specifically, a node MUST = ignore:=20 >> +=20 >> + any TLV except Hello if received from a neighbour that does not hav= e an=20 >> + entry in the neighbour table, and=20 >> + any TLV except Hello and IHU if received from a neighbour that has = an=20 >> + entry in the neighbour table with txcost equal to infinity.=20 >> +=20 The above proposed change is related to section I point 2 (as stated in the= message subject) and the commit message is as follows: ------------------------------------- "The specification should explicitly state that the =E2=80=9Cgreen=E2=80=9D= TLVs must be ignored unless they come from a valid neighbour..." This change at the end of "Bidirectional Reachability Detection" adds respective normative text. ------------------------------------- This thinking is based on the slide with the FSM, the one that has in the t= itle: "Should it be like this?". If it should be (like it seems to me), the= n the proposed change just spells the norm, however much obvious, as that i= s the purpose of a specification. For a protocol definition it is better to= keep a trivial statement around than to allow implementations that are for= mally compliant but broken. If the inferred FSM in the slides is wrong and one or more TLVs are actuall= y due for processing even without a 2-way neighbour or even without a 1-way= neighbour, then this needs to be specified too. Whichever way is intended,= it needs to be clearly defined regardless of the particular reasoning behi= nd. >I am of somewhat mixed mind on this change. While this is certainly what= =20 >all existing implementations do, I am not sure that it belongs in the base= =20 >protocol. I can certainly envision an implementation that uses any=20 >packet, not only one that contains a Hello, to create a neighbour=20 >association. I could even envision an extension that signals=20 >neighbourship at the link layer (think Babel over Bluetooth Low Energy).= =20 As far as I can currently imagine it, Babel without Hello or implied Hello = would be a notably different protocol because without Hello sequence number= s the neighbour table would be different and neighbour history would have t= o be based on something else to keep things working. One thing I would expe= ct is however the other potential protocol would compare to Babel with Hell= o, it would cost substantial design time anyway. The mention of extensions is a good point and it gives me an idea on specif= ying the requirement better. What do you think about the following wording? The bidirectional reachability detection is a prerequisite for the=20 routing information exchange and processing performed by the protocol instance defined in this document. Specifically, a node MUST ignore the following TLVs: =20 Acknowledgment Request, Acknowledgment, IHU, Router-Id, Next Hop, Update, Route Request, and Seqno Request if received from a neighbour that does not have an entry in the neighbour table, and Acknowledgment Request, Acknowledgment, Router-Id, Next Hop, Update, Route Request, and Seqno Request if received from a neighbour that has an entry in the neighbour table with txcost equal to infinity. Babel protocol extensions that introduce additional TLVs SHOULD specify whether to ignore those TLVs under the conditions stated above. =20 >Here, at Babel towers, our policy has been to only add constraints to the= =20 >protocol in order to solve a problem. So what problem are you trying to=20 >solve with this addition?=20 >=20 > 1. A problem in the base protocol?=20 > 2. A problem in HMAC-based authentication?=20 > 3. No problem?=20 Section I item 1: 1=3Dyes, 2=3Dno, 3=3Dno. Section I item 2: 1=3Dyes, 2=3Dyes, 3=3Dno. >I understand that you're trying to fix a problem in HMAC-based=20 >authentication. If I'm correct, then perhaps this addition belongs in the= =20 >HMAC document, something like=20 >=20 > If a node implements this extension, then it MUST NOT create a neighbour= =20 > entry before receiving a Hello TLV, and MUST silently ignore etc.=20 Yes and no. I was looking how to fix it and in the course of it I had found= issues elsewhere. Usually it helps to resolve the smaller problems first t= o make it easier to focus on the big ones. It seems to me the authentication mechanism should not reach into the main = protocol body as far as described above. There should be a better solution. >If I'm wrong, and you're actually fixing an issue in the base protocol,=20 >than your additions must explain to the reader why this is essential, not= =20 >just add a seemingly arbitrary requirement.=20 >=20 >-- Juliusz=20 --=20 Denis Ovsienko From nobody Mon Dec 12 16:29:18 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F27129F80 for ; Mon, 12 Dec 2016 16:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-kns23_D3Xy for ; Mon, 12 Dec 2016 16:29:13 -0800 (PST) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A6A129F6C for ; Mon, 12 Dec 2016 16:29:13 -0800 (PST) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 14815889486231016.6957898670355; Mon, 12 Dec 2016 16:29:08 -0800 (PST) Date: Tue, 13 Dec 2016 00:29:08 +0000 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <158f5953e89.b7dbea434613.4022202347829091640@ovsienko.info> In-Reply-To: References: <158f03caa17.f99ff21138897.6561785689073232467@ovsienko.info> <7ishpt13xr.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: Tue, 13 Dec 2016 00:29:14 -0000 ---- On Mon, 12 Dec 2016 21:21:01 +0000 David Schinazi wrote ---- > This change constrains the protocol more, and is not what *all* implementations do, > as I have one that doesn't do this. An implementation could still learn useful information > from updates from a host that it has not heard Hellos for. Those routes must have an > infinite metric but once we do get the hello we could immediately start using them > instead of waiting for another update or asking for one explicitly. > > Unless what I'm describing breaks some of the properties of Babel, I would advise > against constraining the protocol in this way. I agree with Juliusz that if this only > impacts the authentication extension, then it should be defined alongside the > extension and not the core protocol. Thank you for being specific, David. I understand what you do but I am not competent right now to confirm if this always works as expected from the routing point of view. 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. All the other TLVs still stand and may occur in an input packet and the specification should have the behaviour defined. Another issue here may be, accepting any information that comes without a proof of freshness (like IHU without the sequence number as discussed before) leaves an exposure to a replay attack. A two-way exchange seems to be essential for protocol security, wherever performed. -- Denis Ovsienko From nobody Tue Dec 13 09:26:11 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A658B129407 for ; Tue, 13 Dec 2016 09:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.198 X-Spam-Level: X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhcYunt9QOE5 for ; Tue, 13 Dec 2016 09:26:07 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (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 E7B7D129450 for ; Tue, 13 Dec 2016 09:26:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1481649964; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=h4uCsaeV5cXqKVkmCuS9gRYzuJeuKS0R7VwiROcOlXY=; b=Cvase5O7yX6q1BJ/FBkFwl1yVt0ESgIsGGJb2W7GvCjiY7mc+6HRrQun1uHJivCa Rj2ekNa8v362SnNJuQsnQOHa1v1fWjYUMosZBMGGMNWF1X7tz/pFpkP1hLdiCG33 M0iCoVsDhLyN2/xUI/Qw/WWIvfWXaMzMhLaa4u9vQxYt8a0jZJRehEvYYUw7ht47 o/2mehEI1Ft1WIi/PYCYk8rgXrTjrLdl5Yd0LQK4Nc/hCojO+6UFPOKgm/g8OXFI e9RTX1yWAfNbthQbXWyg4es4tfNPHNM5hRIHaTxrPEGZcPp35k4DcJHZik2OxA0k kHu+SA1NVipIvdPtcQmqxg==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id BE.03.23572.C2F20585; Tue, 13 Dec 2016 09:26:04 -0800 (PST) X-AuditID: 11973e15-11afc9a000005c14-bf-58502f2c6aef Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay6.apple.com (Apple SCV relay) with SMTP id 19.79.23613.C2F20585; Tue, 13 Dec 2016 09:26:04 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.80.105] (unknown [17.153.80.105]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.0 64bit (built Sep 28 2016)) with ESMTPSA id <0OI400B0YWFEX050@nwk-phonehomebzp-sz01.apple.com>; Tue, 13 Dec 2016 09:26:04 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi X-Priority: Medium In-reply-to: <158f5953e89.b7dbea434613.4022202347829091640@ovsienko.info> Date: Tue, 13 Dec 2016 09:26:01 -0800 Message-id: References: <158f03caa17.f99ff21138897.6561785689073232467@ovsienko.info> <7ishpt13xr.wl-jch@irif.fr> <158f5953e89.b7dbea434613.4022202347829091640@ovsienko.info> To: Denis Ovsienko X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUi2FAYpaujHxBh8LZF0WLLom4Wizm3vrM4 MHksWfKTyWPFyY1sAUxRXDYpqTmZZalF+nYJXBlbDixgLdgjVfG7ZSNTA+Mq0S5GTg4JAROJ J482snUxcnEICexllHg88S2QwwGWePS9HCJ+jFFi7pfnTCANvAKCEj8m32MBqWEWkJc4eF4W JMwsoCXx/VErC4gtJDCLSeL+HW4QW1hAWqLrwl1WCNtToq1nOSNIKxtQ/YE1RhAnCEls2TGX EcTmBCq5eu0uO4jNIqAqMW/5YVaI8UoSq7/dYYa4wEZi7b0T7BCnXWeU6Dy7CCwhIqAh8WXL PGaIobISn57/BCuSEDjAJjF7chfrBEaRWUhemIXwwiwkLyxgZF7FKJSbmJmjm5lnppdYUJCT qpecn7uJERTu0+1EdzCeWWV1iFGAg1GJh/eHcECEEGtiWXFl7iFGaQ4WJXFeby//CCGB9MSS 1OzU1ILUovii0pzU4kOMTBycUg2M059OvLwqKaGOqcqbLZBpdtPW8B/HQzwP3D58ItzgwPx9 mosXiG3025YpUjvF5Z3Br7xPDpfudihlh2yPMT+5M4T1c6ePz3Nv24TJ5j13TgvHztszielE D+/vu0vORrafZHU9WZD3/92sVek2wo+3vWI8IN9vpjnz8h2BnXfr19lUvT1bfqF+ixJLcUai oRZzUXEiAEznsnVYAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42IRnG7noKujHxBh0NcgZrFlUTeLxZxb31kc mDyWLPnJ5LHi5Ea2AKYoLpuU1JzMstQifbsErowtBxawFuyRqvjdspGpgXGVaBcjB4eEgInE o+/lXYycQKaYxIV769m6GLk4hASOMUrM/fKcCSTBKyAo8WPyPRaQemYBeYmD52VBwswCWhLf H7WygNhCArOYJO7f4QaxhQWkJbou3GWFsD0l2nqWM4K0sgHVH1hjBLFKSGLLjrmMIDYnUMnV a3fZQWwWAVWJecsPs0KMV5JY/e0OM8QFNhJr751ghzjtOqNE59lFYAkRAQ2JL1vmMUMMlZX4 9Pwn+wRGoVlIrp6FcPUsJFcvYGRexShQlJqTWGmml1hQkJOql5yfu4kRFLYNhVE7GBuWWx1i FOBgVOLh/SEcECHEmlhWXJl7iFGCg1lJhPeRLlCINyWxsiq1KD++qDQntfgQYzLQAxOZpUST 84ExlVcSb2hiYmBibGxmbGxuYk6asJI4r6Wzd4SQQHpiSWp2ampBahHMFiYOTqkGxvrUnfu/ O1QaTqjgF37pUK0XNOu6xLWH9T6i/4Xz3+9+tD3Y+O+6pvyLqh0lQX3b43Y497773/ZAq8wt Yv7swxrG/hppc6ZuTL6pwzDnD8MEpdZDd8VZn5879df6+IxknjdL69I3PnXff+dAqsWhJTz1 EfOWfbmxK74oI+N8qmrNmu+H5yZO+KPEUpyRaKjFXFScCABQDHtsnwIAAA== 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, 13 Dec 2016 17:26:09 -0000 Denis, I'm not sure I understand why the Update TLV is special here, when I haven't seen a Hello why shouldn't I reply to AckReq? What's wrong with me replying to a RouteReq? The fact that you need established bidirectional reachability still seems specific to the HMAC extension to me. I agree with your points regarding proofs of freshness and replay attacks, however those apply to the HMAC extension, not the core spec. If I were to run Babel over IPsec/ESP, I would already have these properties without constraining the Babel spec. I don't see changes to the Hello structure as a "notably different protocol". Today the spec lets me compute rxcost/txcost as I see fit, and the requirements on how to compute metrics are only what is required to ensure routing properties. If I had a magical oracle that perfectly estimated link quality (I keep it next to my unicorn), then I could use that instead of maintaining hello history. And I could even do this in a way compliant with the specs if all nodes have their Hello and IHU intervals set to 11 minutes (2^16cs). But if I do that then I have no way to quickly discover new peers when I join the network. This is why I'd like to dissociate new peer detection from quality estimation. Your change regarding the initialization of the neighbor table entry is fine with today's spec, but I'd love for us to move in a direction where the spec is less multicast focused and where section 3.2.3 (neighbor table) would be more of an implementation detail than core spec. David > On Dec 12, 2016, at 16:29, Denis Ovsienko wrote: > > ---- On Mon, 12 Dec 2016 21:21:01 +0000 David Schinazi wrote ---- >> This change constrains the protocol more, and is not what *all* implementations do, >> as I have one that doesn't do this. An implementation could still learn useful information >> from updates from a host that it has not heard Hellos for. Those routes must have an >> infinite metric but once we do get the hello we could immediately start using them >> instead of waiting for another update or asking for one explicitly. >> >> Unless what I'm describing breaks some of the properties of Babel, I would advise >> against constraining the protocol in this way. I agree with Juliusz that if this only >> impacts the authentication extension, then it should be defined alongside the >> extension and not the core protocol. > > Thank you for being specific, David. I understand what you do but I am not competent right now to confirm if this always works as expected from the routing point of view. > > 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. All the other TLVs still stand and may occur in an input packet and the specification should have the behaviour defined. > > Another issue here may be, accepting any information that comes without a proof of freshness (like IHU without the sequence number as discussed before) leaves an exposure to a replay attack. A two-way exchange seems to be essential for protocol security, wherever performed. > > -- > Denis Ovsienko > > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Tue Dec 13 15:37:57 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2B5129C3C for ; Tue, 13 Dec 2016 15:37:49 -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 nBGsumTa14lu for ; Tue, 13 Dec 2016 15:37: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 1A47812969B for ; Tue, 13 Dec 2016 15:37:39 -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 uBDNbSVi008172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Dec 2016 00:37:28 +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 uBDNbSPH010252; Wed, 14 Dec 2016 00:37:28 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 6BE12D78B9; Wed, 14 Dec 2016 00:37:28 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id MDk-HIUDPfhJ; Wed, 14 Dec 2016 00:37:25 +0100 (CET) Received: from trurl.irif.fr (unknown [78.250.106.48]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 71A27D7889; Wed, 14 Dec 2016 00:37:24 +0100 (CET) Date: Wed, 14 Dec 2016 00:37:37 +0100 Message-ID: <87h967cse6.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi In-Reply-To: <9914D9F4-2417-4CE8-9391-F4D6F18048A3@apple.com> References: <158f03b89ed.11c4323dd38877.6995881645496107685@ovsienko.info> <9914D9F4-2417-4CE8-9391-F4D6F18048A3@apple.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 14 Dec 2016 00:37:28 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 14 Dec 2016 00:37:28 +0100 (CET) X-Miltered: at korolev with ID 58508638.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58508638.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58508638.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58508638.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 : 58508638.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58508638.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 1/4] address IETF-97 slides section I point 1 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, 13 Dec 2016 23:37:50 -0000 > As discussed in the other thread (patch 2/4), I believe this change > unnecessarily constrains the protocol. The existence of a neighbor table > is purely an implementation detail that I'd rather keep in an appendix. Well, yes and no. The protocol is described in terms of a set of conceptual data structures, and the neighbour table is described in Section 3.2.3. OTOH, the data structures are conceptual -- you're welcome to use a different set of data structures as long as they achieve the same result. There's a number of reasonable data structures for describing Babel (for example pybabel uses two route tables instead of a single table with a boolean selected flag, while my implementation uses a set of linked lists with the selected route being at the head), but I don't see how you can get away without a neighbours table. I agree with you on all of your remaining points. -- Juliusz From nobody Tue Dec 13 15:47:54 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B321129C4D for ; Tue, 13 Dec 2016 15:47:43 -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 yIFCR9fJRN8A for ; Tue, 13 Dec 2016 15:47:31 -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 53EC6126FDC for ; Tue, 13 Dec 2016 15:47:27 -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 uBDNlPEt011880; Wed, 14 Dec 2016 00:47:25 +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 5B288D7889; Wed, 14 Dec 2016 00:47:25 +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 YK6b-WksUUje; Wed, 14 Dec 2016 00:47:23 +0100 (CET) Received: from trurl.irif.fr (unknown [78.250.106.48]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6A784D7885; Wed, 14 Dec 2016 00:47:21 +0100 (CET) Date: Wed, 14 Dec 2016 00:47:34 +0100 Message-ID: <87fulrcrxl.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko In-Reply-To: <158f5953e89.b7dbea434613.4022202347829091640@ovsienko.info> References: <158f03caa17.f99ff21138897.6561785689073232467@ovsienko.info> <7ishpt13xr.wl-jch@irif.fr> <158f5953e89.b7dbea434613.4022202347829091640@ovsienko.info> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 14 Dec 2016 00:47:25 +0100 (CET) X-Miltered: at korolev with ID 5850888D.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5850888D.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 : 5850888D.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: 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, 13 Dec 2016 23:47:43 -0000 > 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? -- Juliusz From nobody Tue Dec 13 16:01:54 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE88A129C5C for ; Tue, 13 Dec 2016 16:01:52 -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 0u-GKpWNQGNV for ; Tue, 13 Dec 2016 16:01:40 -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 12C24129C6B for ; Tue, 13 Dec 2016 15:59:27 -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 uBDNxMT5016336; Wed, 14 Dec 2016 00:59: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 9BC5ED78B9; Wed, 14 Dec 2016 00:59: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 Zm7715tmjVh8; Wed, 14 Dec 2016 00:59:21 +0100 (CET) Received: from trurl.irif.fr (unknown [78.250.106.48]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 47370D7889; Wed, 14 Dec 2016 00:59:19 +0100 (CET) Date: Wed, 14 Dec 2016 00:59:33 +0100 Message-ID: <87eg1bcrdm.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi In-Reply-To: References: <158f03caa17.f99ff21138897.6561785689073232467@ovsienko.info> <7ishpt13xr.wl-jch@irif.fr> <158f5953e89.b7dbea434613.4022202347829091640@ovsienko.info> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 14 Dec 2016 00:59:22 +0100 (CET) X-Miltered: at korolev with ID 58508B5A.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58508B5A.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 58508B5A.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: Babel 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: Wed, 14 Dec 2016 00:01:53 -0000 > Today the spec lets me compute rxcost/txcost as I see fit, This is not going to change. Earlier drafts of RFC 6126 mandated ETX, and Joel successfully convinced me that this should become an informative appendix. > a magical oracle that perfectly estimated link quality David Lamparter built one of those, which he uses in his version of IS-IS. It works very well in IETF presentations, but has some flaws when discussed over beer (the oracle fails to update the link quality of a neighbour that's not being used). More work is needed, perhaps next summer. OTOH, David's oracle works at the link layer, so I would not recommend disabling IHU processing even when using it -- probing bidirectional reachability at the network layer even when the link layer claims everything is working makes for a more robust implementation. > But if I do that then I have no way to quickly discover new peers when > I join the network. Well, your magical link-layer oracle is probably able to provide indication of new peers, so you could send a hello (perhaps over unicast) when it says that a new neighbour has appeared. Of course, the link-layer oracle doesn't say a new Babel node has appeared, just that there is a new link-layer neighbour. > I'd love for us to move in a direction where the spec is less multicast > focused and where section 3.2.3 (neighbor table) would be more of an > implementation detail than core spec. Hmm... even in the absence of bidirectional reachability and link quality estimation, you still need to dump the (interface, IP) information somewhere. I guess you could put it directly in the route table, and I don't think that the current spec disallows that -- the neighbour table is conceptual, after all --, so I don't think it's worth working on removing the neighbour table from the spec. -- Juliusz From nobody Tue Dec 13 16:08:12 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52414129530 for ; Tue, 13 Dec 2016 16:08:02 -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 PKVZ9iqdFn_k for ; Tue, 13 Dec 2016 16:08:01 -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 00DAA129C46 for ; Tue, 13 Dec 2016 16:04:22 -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 uBE04Lvd018095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Dec 2016 01:04:21 +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 uBE04Kb5014573; Wed, 14 Dec 2016 01:04:20 +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 CCB30D78B9; Wed, 14 Dec 2016 01:04:20 +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 ybAUSCTC4m0X; Wed, 14 Dec 2016 01:04:19 +0100 (CET) Received: from trurl.irif.fr (unknown [78.250.106.48]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 86417D7889; Wed, 14 Dec 2016 01:04:18 +0100 (CET) Date: Wed, 14 Dec 2016 01:04:31 +0100 Message-ID: <87d1gvcr5c.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko In-Reply-To: <158f5668185.1054273aa3805.8956201339893343725@ovsienko.info> References: <158f03caa17.f99ff21138897.6561785689073232467@ovsienko.info> <7ishpt13xr.wl-jch@irif.fr> <158f5668185.1054273aa3805.8956201339893343725@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]); Wed, 14 Dec 2016 01:04:21 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 14 Dec 2016 01:04:21 +0100 (CET) X-Miltered: at korolev with ID 58508C85.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58508C84.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58508C85.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58508C84.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 58508C85.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58508C84.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: Babel at IETF Subject: Re: [babel] [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: Wed, 14 Dec 2016 00:08:02 -0000 > But there is no text in the document that tells when to add an entry to > the table and how to set txcost. The specification is plainly incomplete > without this I partly agree. Section 3.4.2 says: A node receiving an IHU updates the value of the sending neighbour's txcost (transmission cost), from its perspective, to the value contained in the IHU, and resets this neighbour's IHU timer to a small multiple of the value received in the IHU. This is meant to say that when you receive an IHU, you grab the corresponding neighbour table entry (creating one if it doesn't exist), and dump the txcost in there. I agree it's horribly badly written, but the intent is clear. Section 3.4.1 doesn't say to create a neighbour entry. This needs fixing. -- Juliusz From nobody Tue Dec 13 16:10:03 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35C7129C8D for ; Tue, 13 Dec 2016 16:10:00 -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 rKYR0-IaRJDR for ; Tue, 13 Dec 2016 16:09:56 -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 E8DEC12950E for ; Tue, 13 Dec 2016 16:07:15 -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 uBE07EIA019143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Dec 2016 01:07:14 +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 uBE07E9Y015018; Wed, 14 Dec 2016 01:07:14 +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 43DEDD7889; Wed, 14 Dec 2016 01:07:14 +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 enuhe0izfLkV; Wed, 14 Dec 2016 01:07:13 +0100 (CET) Received: from trurl.irif.fr (unknown [78.250.106.48]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id F4038D7885; Wed, 14 Dec 2016 01:07:11 +0100 (CET) Date: Wed, 14 Dec 2016 01:07:24 +0100 Message-ID: <87bmwfcr0j.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko In-Reply-To: <158f43de17b.c4a1eb0f15012.1465924192497187566@ovsienko.info> References: <158f03d504a.af6b230a38904.1275316408151406007@ovsienko.info> <7ir35d13w6.wl-jch@irif.fr> <158f43de17b.c4a1eb0f15012.1465924192497187566@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]); Wed, 14 Dec 2016 01:07:14 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 14 Dec 2016 01:07:14 +0100 (CET) X-Miltered: at korolev with ID 58508D32.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58508D32.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58508D32.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58508D32.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 58508D32.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58508D32.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: Babel at IETF Subject: Re: [babel] [PATCH 3/4] address IETF-97 slides section I point 3 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 00:10:01 -0000 >>> +For the avoidance of doubt, for a neighbour to remain in a stable >>> +bidirectional reachability state it is essential that it keeps sending both >>> +Hello and IHU TLVs on time as specified below. >> >> I don't understand this sentence. Is it an additional requirement for >> implementations (in which case it should be stated in terms of MUST), or >> is it just rephrasing what the document already says? > It is the latter, I see. Denis, I agree with you that 3.4.1 and 3.4.2 are badly written. However, the correct fix is to fix 3.4.1 and 3.4.2, not to add an additional paragraph that basically says "3.4.1 and 3.4.2 are badly written, so read them carefully". -- Juliusz From nobody Tue Dec 13 16:15:14 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500071296E7 for ; Tue, 13 Dec 2016 16:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.198 X-Spam-Level: X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VP_SZq9f7b7p for ; Tue, 13 Dec 2016 16:15:10 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 DF5D91293E1 for ; Tue, 13 Dec 2016 16:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1481674510; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Mf0vYnWqzY7arz2HDVAk9t8/XSAoQW0p4pYQJCj8LTQ=; b=qdMXok+Dv97V6SNy0oxWK/SF7Sr1lPSGgUcHtqmcf0FuFzA4VDKDg5hG7ph/WnQd Eecijjxq9QJgxYClnfOHB3RMA/LQQVzKsLBB1sEXrYmD8NmME8PNLRzCqWPUpy3k SqrOk7a2fYakkleA1E7hVa4gqlYOZM6u6rFOvfvdi8Bmd5dDqtjIdFzgDLKSpKpl wizqT6kn6BSih/RFyqjVlv0GFLSCUm9YCIx5RgGwM2iMYmI3xUgNuPLgdAt1LNZq GUsJKxOlUDvaHvjdG0TiVbZrL+cLw3vxIZl5Z7MERo6blY9NxbecbiuY54swzQeO XijVqFMQ+841rOPEiv62uA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 01.63.06020.E0F80585; Tue, 13 Dec 2016 16:15:10 -0800 (PST) X-AuditID: 11973e12-a7d449a000001784-04-58508f0e7671 Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay6.apple.com (Apple SCV relay) with SMTP id 80.6C.23613.E0F80585; Tue, 13 Dec 2016 16:15:10 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from dschinazi.apple.com (dschinazi.apple.com [17.226.40.22]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.0 64bit (built Sep 28 2016)) with ESMTPSA id <0OI500JVYFDAX240@nwk-phonehomebzp-sz01.apple.com>; Tue, 13 Dec 2016 16:15:10 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87h967cse6.wl-jch@irif.fr> Date: Tue, 13 Dec 2016 16:15:10 -0800 Message-id: <470C1361-BDC7-459E-8F77-238DB5A4C07E@apple.com> References: <158f03b89ed.11c4323dd38877.6995881645496107685@ovsienko.info> <9914D9F4-2417-4CE8-9391-F4D6F18048A3@apple.com> <87h967cse6.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUi2FAYpcvXHxBh8GuVusWWRd0sFvNbl7E5 MHksWfKTyWPxlreMAUxRXDYpqTmZZalF+nYJXBl3Fk5gK5jCVTHz8i/GBsYJHF2MnBwSAiYS E85+ZgSxhQT2Mkr8WpQKE995uoW9i5ELKH6MUaK3q5EJJMErICjxY/I9li5GDg5mAXmJg+dl QcLMAloS3x+1skDUr2SSWDXvLCtIQlhAWqLrwl0o21Pi4Zo+dpBeNqCGA2uMQMKcAhoS12ae YQQJswioArUWQIxUklj97Q4zxFYbiSXXnzFCjJ/JKLHk0Bqwc0QEVCSWT3vGDnGzrMSn5z/B bpYQWMMm8X3PYqYJjMKzkJw9C+HsWUjOXsDIvIpRKDcxM0c3M89EL7GgICdVLzk/dxMjKKyn 2wntYDy1yuoQowAHoxIP7w/hgAgh1sSy4srcQ4zSHCxK4rziTkAhgfTEktTs1NSC1KL4otKc 1OJDjEwcnFINjJLvF50r2j4hZqpr1rYla1VVN2++u5s369S3kHM/vBxtlfSSVD/+u6ZRJJZ8 f/GkyaI6aVuSHFjis9Iqsn7M2H6Y97qNe1DRwt+OWz8unGJ/9ZhmV9CZOz4rfolWrjXf8NuY e/VajRbexzItRV68Hy4Ipp7NfJ45MT/0iVT29bTYHdwHJMW+mCuxFGckGmoxFxUnAgA9qb/2 TAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42IRnG7noMvXHxBhsPe7ssWWRd0sFvNbl7E5 MHksWfKTyWPxlreMAUxRXDYpqTmZZalF+nYJXBl3Fk5gK5jCVTHz8i/GBsYJHF2MnBwSAiYS O0+3sEPYYhIX7q1n62Lk4hASOMYo0dvVyASS4BUQlPgx+R5LFyMHB7OAvMTB87IgYWYBLYnv j1pZIOpXMkmsmneWFSQhLCAt0XXhLpTtKfFwTR87SC8bUMOBNUYgYU4BDYlrM88wgoRZBFSB WgsgRipJrP52hxliq43EkuvPGCHGz2SUWHJoDdg5IgIqEsunPYO6WVbi0/Of7BMYBWchuXQW wqWzkFy6gJF5FaNAUWpOYqWZXmJBQU6qXnJ+7iZGUIA2FEbtYGxYbnWIUYCDUYmH94dwQIQQ a2JZcWXuIUYJDmYlEd6MHqAQb0piZVVqUX58UWlOavEhxmSg+ycyS4km5wOjJ68k3tDExMDE 2NjM2NjcxJw0YSVxXg5noBUC6YklqdmpqQWpRTBbmDg4pRoYpyqplDJddr46M7fLg2VJ7e6J d69FnoyeGW3+/Nfqyk3GOzIUWDkYby58s1KpyfbwZi/DIPGSf8wyAu81myd8X7H41Ekricje V13BRk9ZV2QtNBOdyfnpiUC0DVfI1BnnNQXPHTh58YWx7YwDm95tivbVS89xm3HpygbRx/nn rltvz1609dyfRCWW4oxEQy3mouJEAOX7iXqUAgAA Archived-At: Cc: Babel at IETF Subject: Re: [babel] [PATCH 1/4] address IETF-97 slides section I point 1 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, 14 Dec 2016 00:15:12 -0000 Agreed. I've reread the section since and am fine with specifying how to initialize the neighbor table entry. David > On Dec 13, 2016, at 15:37, Juliusz Chroboczek wrote: > >> As discussed in the other thread (patch 2/4), I believe this change >> unnecessarily constrains the protocol. The existence of a neighbor table >> is purely an implementation detail that I'd rather keep in an appendix. > > Well, yes and no. The protocol is described in terms of a set of > conceptual data structures, and the neighbour table is described in > Section 3.2.3. OTOH, the data structures are conceptual -- you're welcome > to use a different set of data structures as long as they achieve the same > result. > > There's a number of reasonable data structures for describing Babel (for > example pybabel uses two route tables instead of a single table with > a boolean selected flag, while my implementation uses a set of linked > lists with the selected route being at the head), but I don't see how you > can get away without a neighbours table. > > I agree with you on all of your remaining points. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Tue Dec 13 18:09:31 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B9A129563 for ; Tue, 13 Dec 2016 18:09:30 -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 urvvFmWu-oL8 for ; Tue, 13 Dec 2016 18:09:29 -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 C8DCC129501 for ; Tue, 13 Dec 2016 18:09:28 -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 uBE29QDU028231 for ; Wed, 14 Dec 2016 03:09:26 +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 A9EB9D78B9 for ; Wed, 14 Dec 2016 03:09:26 +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 QeT47ZZa-8YO for ; Wed, 14 Dec 2016 03:09:25 +0100 (CET) Received: from trurl.irif.fr (unknown [78.250.106.48]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 752EAD7885 for ; Wed, 14 Dec 2016 03:09:22 +0100 (CET) Date: Wed, 14 Dec 2016 03:09:39 +0100 Message-ID: <8760mnclcs.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 [194.254.61.138]); Wed, 14 Dec 2016 03:09:26 +0100 (CET) X-Miltered: at korolev with ID 5850A9D6.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5850A9D6.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 : 5850A9D6.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Discussion about Denis' comments: conclusion? 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, 14 Dec 2016 02:09:30 -0000 So, my reading of this discussion is that 3.4.1 and 3.4.2 must be rewritten. In addition to that, we need to decide between the following: (1) a neighbour entry MUST be created upon receiving any kind of packet; or (2) a neighbour entry MUST be created upon receiving a Hello, MAY be created upon receiving an IHU; or (3) a neighbour entry MUST be created upon receiving a Hello, and MAY be created upon receiving any kind of packet; or (4) a neighbour entry MAY be created upon receiving any kind of packet. My preference is (3), which is not too restrictive while guaranteeing that an entry will be created at some point. I find (4) tempting, since it is the least restrictive, but it requires additional language to ensure that an entry is created at some point, and I'm not sure what it is. (Or perhaps it doesn't -- after all, whether to speak to a given neighbour is an implementation detail.) None of the above fix Denis' problem, which should be handled in the HMAC protocol, not in the core protocol. I think Denis should add a requirement that says that a packet fails validation unless the neighbour has sent something in the last something, but I'm not clear about the details. Are we agreed? -- Juliusz From nobody Tue Dec 13 19:25:27 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414AD12953D for ; Tue, 13 Dec 2016 19:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.198 X-Spam-Level: X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQDJAJu3x1rt for ; Tue, 13 Dec 2016 19:25:23 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 945B812951E for ; Tue, 13 Dec 2016 19:25:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1481685923; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=u/iaDxErJ96xBlr0YjPxuHoDKRn3shmzYlA0kq0Oon4=; b=MtNgsFuuIk+q456VadNJ8KUlQERG8NuGTcMj/FH8ngO8WsEwE4Qmvsc4Bi09BRVA Cngan2iYWSHiCI8XiTe8f7aWFJnFhPknMdNl65paPkLwKXCxtDvjJgasKmXhaTfa wUThA01DhFpcQYqXVVVj1ySkVwZquUYzBlOTygLhmyQNvkP0cFgPr4hRks6ZxKCZ tPGUiKlqZ/A16Ejraj8e2NZtWWEItqZz1bKCJXEhxBdCzYG/9XqdXPIPxd3i+VkW typN6bfFF+v1zUBz24s704dvbGICRMwt6sDj3+EjyszzxkR1oGdOrhPXCB/tPG9i 5Ml22tyIKqXsnqQwo/E6zg==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 7F.C6.07321.3ABB0585; Tue, 13 Dec 2016 19:25:23 -0800 (PST) X-AuditID: 11973e16-5411e9a000001c99-f2-5850bba3fdbe Received: from jimbu (jimbu.apple.com [17.151.62.37]) by relay3.apple.com (Apple SCV relay) with SMTP id AC.17.13773.1ABB0585; Tue, 13 Dec 2016 19:25:22 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.73.99] (unknown [17.153.73.99]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.0 64bit (built Sep 28 2016)) with ESMTPSA id <0OI500A76O67IX30@jimbu.apple.com>; Tue, 13 Dec 2016 19:25:21 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <8760mnclcs.wl-jch@irif.fr> Date: Tue, 13 Dec 2016 19:25:19 -0800 Message-id: <02F27EAF-A0BC-4477-8043-F7B2AA288CE1@apple.com> References: <8760mnclcs.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUi2FAYrLt4d0CEwYX1MhZbFnWzWMxvXcbm wOSxZMlPJo/FW94yBjBFcdmkpOZklqUW6dslcGV82vyRqaBBuGJT5xn2BsZvfF2MnBwSAiYS 3Y27mLsYuTiEBPYySvRuvsIEk+hou8wKkVjGKHFj81p2kASvgKDEj8n3WLoYOTiYBeQlDp6X BQkzC2hJfH/UygJR/41R4lrbaUaQhLCAtETXhbusELaTxM7O5WwgvWxADQfWGIGEOQU0JK4+ OAK2l0VAVWLntJdMEDOVJFZ/u8MMsdZG4unGXrAxQgLqErf6z7GB2CICKhLLpz1jh7hZVuLT 85/sIDdICGxhk1j56DfjBEbhWUjOnoVw9iwkZy9gZF7FKJSbmJmjm5lnrpdYUJCTqpecn7uJ ERTY0+3EdjA+XGV1iFGAg1GJh/eHcECEEGtiWXFl7iFGaQ4WJXFeKSegkEB6YklqdmpqQWpR fFFpTmrxIUYmDk6pBsYJi/Z98dl7Vbvyy4KLMToWc8RyErNmTn3WtN7YZLFodlYNW4SL1Kod r7tP7rSV3Pjw5+zmrPKSdbMf53wtmfQqhtHf+EZp3NmNs4U+Gt1hvH/bdNkvnyw+pQs6ntbn OdV4lb7+SBLYVdZ2Yfv5+WfFtftOTm3RZdM4smrz8pc3lRofHFkq+NBRiaU4I9FQi7moOBEA kKlc9U0CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42IRnG6nqrtod0CEwcfJzBZbFnWzWMxvXcbm wOSxZMlPJo/FW94yBjBFcdmkpOZklqUW6dslcGV82vyRqaBBuGJT5xn2BsZvfF2MnBwSAiYS HW2XWSFsMYkL99azdTFycQgJLGOUuLF5LTtIgldAUOLH5HssXYwcHMwC8hIHz8uChJkFtCS+ P2plgaj/xihxre00I0hCWEBaouvCXVYI20liZ+dyNpBeNqCGA2uMQMKcAhoSVx8cYQKxWQRU JXZOe8kEMVNJYvW3O8wQa20knm7sBRsjJKAucav/HBuILSKgIrF82jN2iJtlJT49/8k+gVFw FpJLZyFcOgvJpQsYmVcxChSl5iRWGuslFhTkpOol5+duYgQFaENh8A7GP8usDjEKcDAq8fD+ EA6IEGJNLCuuzD3EKMHBrCTC+2IbUIg3JbGyKrUoP76oNCe1+BBjMtD9E5mlRJPzgdGTVxJv aGJiYGJsbGZsbG5iTpqwkjgvhzPQCoH0xJLU7NTUgtQimC1MHJxSDYy7Pu78d+yxgMm57qAE f+XSazFir8zXZR43PqmbFRLJ/u6I1p54rd7olhqruS0L9T9kTbl69nuIc3nR7tVrty75z7f3 7ROP6SbVDPNvv562++Eu++sFbDMblq410GJjDeCcMFP4wRnJPaV/FqxasOxMpJaQWoegvvOH h01udRmJn7P37PpVkblRiaU4I9FQi7moOBEA4u74yZQCAAA= Archived-At: Cc: Babel at IETF Subject: Re: [babel] Discussion about Denis' comments: conclusion? 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, 14 Dec 2016 03:25:25 -0000 I agree with the spirit of what Juliusz says. Regarding actual phrasing, how about the following middle ground: (5) A neighbour entry MAY be created upon receiving any kind of packet. If an implementation wishes to exchange routing information with a given peer, it MUST create a neighbour entry upon receiving a Hello, if a corresponding entry does not already exist. But that starts sounding complicated and I really don't feel strongly about the actual wording as long as I'm not required to ignore packets received before the first Hello. And now that I think about it in those terms, how about: (6) A neighbour entry MAY be created upon receiving any kind of packet. An implementation MAY choose to ignore any packet received from a peer before a Hello packet, and create the neighbour entry upon receiving that first Hello. David > On Dec 13, 2016, at 18:09, Juliusz Chroboczek wrote: > > So, my reading of this discussion is that 3.4.1 and 3.4.2 must be > rewritten. In addition to that, we need to decide between the following: > > (1) a neighbour entry MUST be created upon receiving any kind of packet; > > or > > (2) a neighbour entry MUST be created upon receiving a Hello, MAY be > created upon receiving an IHU; > > or > > (3) a neighbour entry MUST be created upon receiving a Hello, and MAY be > created upon receiving any kind of packet; > > or > > (4) a neighbour entry MAY be created upon receiving any kind of packet. > > My preference is (3), which is not too restrictive while guaranteeing that > an entry will be created at some point. I find (4) tempting, since it is > the least restrictive, but it requires additional language to ensure that > an entry is created at some point, and I'm not sure what it is. (Or > perhaps it doesn't -- after all, whether to speak to a given neighbour is > an implementation detail.) > > None of the above fix Denis' problem, which should be handled in the HMAC > protocol, not in the core protocol. I think Denis should add > a requirement that says that a packet fails validation unless the > neighbour has sent something in the last something, but I'm not clear > about the details. > > Are we agreed? > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Tue Dec 13 22:35:36 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C0A129430 for ; Tue, 13 Dec 2016 22:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.096 X-Spam-Level: X-Spam-Status: No, score=-107.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 YD2BkNQPO1i3 for ; Tue, 13 Dec 2016 22:35:32 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE2C129861 for ; Tue, 13 Dec 2016 22:35:31 -0800 (PST) X-MAILFROM: X-RCPTTO: X-FROMIP: 192.168.168.120 X-SEG-Scaned: 1 X-Received: unknown,192.168.168.120,20161214143329 Received: from unknown (HELO out1.zte.com.cn) (192.168.168.120) by localhost with SMTP; 14 Dec 2016 06:33:29 -0000 X-MAILFROM: X-RCPTTO: X-FROMIP: 10.30.3.20 X-SEG-Scaned: 1 X-Received: unknown,10.30.3.20,20161214143117 Received: from unknown (HELO mse01.zte.com.cn) (10.30.3.20) by localhost with (AES256-SHA encrypted) SMTP; 14 Dec 2016 06:31:17 -0000 Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id uBE6YtSv030750; Wed, 14 Dec 2016 14:34:55 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn) In-Reply-To: <02F27EAF-A0BC-4477-8043-F7B2AA288CE1@apple.com> To: David Schinazi MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.zheng@zte.com.cn Date: Wed, 14 Dec 2016 14:35:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-12-14 14:34:36, Serialize complete at 2016-12-14 14:34:36 Content-Type: multipart/alternative; boundary="=_alternative 0024287B48258089_=" X-MAIL: mse01.zte.com.cn uBE6YtSv030750 X-HQIP: 127.0.0.1 X-HQIP: 127.0.0.1 Archived-At: Cc: babel , Juliusz Chroboczek , Babel at IETF Subject: Re: [babel] Discussion about Denis' comments: conclusion? 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, 14 Dec 2016 06:35:35 -0000 This is a multipart message in MIME format. --=_alternative 0024287B48258089_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBwcmVmZXIgKDMpIHRvby4gSSB0aGluayB0aGF0IHRoZSBuZWlnaGJvdXIgZW50cnkgaXMgdmVy eSB1c2VmdWwgZm9yIA0KZGVidWdnaW5nIHdoZW5ldmVyIGFueSBwYWNrZXQgaXMgcmVjZWl2ZWQu DQpJZiBpdCBpcyBiZXR0ZXIgdGhhdCB1c2UgobBTSE9VTEShsSByZXBsYWNlIKGwTUFZobE/DQoo MykgYSBuZWlnaGJvdXIgZW50cnkgTVVTVCBiZSBjcmVhdGVkIHVwb24gcmVjZWl2aW5nIGEgSGVs bG8sIGFuZCBTSE9VTEQgDQpiZSBjcmVhdGVkIHVwb24gcmVjZWl2aW5nIGFueSBraW5kIG9mIHBh Y2tldDsNCg0KU2FuZHkNCg0KDQoiYmFiZWwiIDxiYWJlbC1ib3VuY2VzQGlldGYub3JnPiDQtNPa IDIwMTYvMTIvMTQgMTE6MjU6MTk6DQoNCj4gSSBhZ3JlZSB3aXRoIHRoZSBzcGlyaXQgb2Ygd2hh dCBKdWxpdXN6IHNheXMuDQo+IFJlZ2FyZGluZyBhY3R1YWwgcGhyYXNpbmcsIGhvdyBhYm91dCB0 aGUgZm9sbG93aW5nIG1pZGRsZSBncm91bmQ6DQo+IA0KPiAoNSkgQSBuZWlnaGJvdXIgZW50cnkg TUFZIGJlIGNyZWF0ZWQgdXBvbiByZWNlaXZpbmcgYW55IGtpbmQgb2YgcGFja2V0Lg0KPiBJZiBh biBpbXBsZW1lbnRhdGlvbiB3aXNoZXMgdG8gZXhjaGFuZ2Ugcm91dGluZyBpbmZvcm1hdGlvbiB3 aXRoIGEgZ2l2ZW4NCj4gcGVlciwgaXQgTVVTVCBjcmVhdGUgYSBuZWlnaGJvdXIgZW50cnkgdXBv biByZWNlaXZpbmcgYSBIZWxsbywgaWYgYSANCj4gY29ycmVzcG9uZGluZyBlbnRyeSBkb2VzIG5v dCBhbHJlYWR5IGV4aXN0Lg0KPiANCj4gQnV0IHRoYXQgc3RhcnRzIHNvdW5kaW5nIGNvbXBsaWNh dGVkIGFuZCBJIHJlYWxseSBkb24ndCBmZWVsIHN0cm9uZ2x5DQo+IGFib3V0IHRoZSBhY3R1YWwg d29yZGluZyBhcyBsb25nIGFzIEknbSBub3QgcmVxdWlyZWQgdG8gaWdub3JlIHBhY2tldHMNCj4g cmVjZWl2ZWQgYmVmb3JlIHRoZSBmaXJzdCBIZWxsby4gQW5kIG5vdyB0aGF0IEkgdGhpbmsgYWJv dXQgaXQgaW4gdGhvc2UgDQp0ZXJtcywNCj4gaG93IGFib3V0Og0KPiANCj4gKDYpIEEgbmVpZ2hi b3VyIGVudHJ5IE1BWSBiZSBjcmVhdGVkIHVwb24gcmVjZWl2aW5nIGFueSBraW5kIG9mIHBhY2tl dC4NCj4gQW4gaW1wbGVtZW50YXRpb24gTUFZIGNob29zZSB0byBpZ25vcmUgYW55IHBhY2tldCBy ZWNlaXZlZCBmcm9tIGEgcGVlcg0KPiBiZWZvcmUgYSBIZWxsbyBwYWNrZXQsIGFuZCBjcmVhdGUg dGhlIG5laWdoYm91ciBlbnRyeSB1cG9uIHJlY2VpdmluZyANCnRoYXQNCj4gZmlyc3QgSGVsbG8u DQo+IA0KPiBEYXZpZA0KPiANCj4gDQo+ID4gT24gRGVjIDEzLCAyMDE2LCBhdCAxODowOSwgSnVs aXVzeiBDaHJvYm9jemVrIDxqY2hAaXJpZi5mcj4gd3JvdGU6DQo+ID4gDQo+ID4gU28sIG15IHJl YWRpbmcgb2YgdGhpcyBkaXNjdXNzaW9uIGlzIHRoYXQgMy40LjEgYW5kIDMuNC4yIG11c3QgYmUN Cj4gPiByZXdyaXR0ZW4uICBJbiBhZGRpdGlvbiB0byB0aGF0LCB3ZSBuZWVkIHRvIGRlY2lkZSBi ZXR3ZWVuIHRoZSANCmZvbGxvd2luZzoNCj4gPiANCj4gPiAgKDEpIGEgbmVpZ2hib3VyIGVudHJ5 IE1VU1QgYmUgY3JlYXRlZCB1cG9uIHJlY2VpdmluZyBhbnkga2luZCBvZiANCnBhY2tldDsNCj4g PiANCj4gPiBvcg0KPiA+IA0KPiA+ICAoMikgYSBuZWlnaGJvdXIgZW50cnkgTVVTVCBiZSBjcmVh dGVkIHVwb24gcmVjZWl2aW5nIGEgSGVsbG8sIE1BWSBiZQ0KPiA+ICAgICAgY3JlYXRlZCB1cG9u IHJlY2VpdmluZyBhbiBJSFU7DQo+ID4gDQo+ID4gb3INCj4gPiANCj4gPiAgKDMpIGEgbmVpZ2hi b3VyIGVudHJ5IE1VU1QgYmUgY3JlYXRlZCB1cG9uIHJlY2VpdmluZyBhIEhlbGxvLCBhbmQgTUFZ IA0KYmUNCj4gPiAgICAgIGNyZWF0ZWQgdXBvbiByZWNlaXZpbmcgYW55IGtpbmQgb2YgcGFja2V0 Ow0KPiA+IA0KPiA+IG9yDQo+ID4gDQo+ID4gICg0KSBhIG5laWdoYm91ciBlbnRyeSBNQVkgYmUg Y3JlYXRlZCB1cG9uIHJlY2VpdmluZyBhbnkga2luZCBvZiANCnBhY2tldC4NCj4gPiANCj4gPiBN eSBwcmVmZXJlbmNlIGlzICgzKSwgd2hpY2ggaXMgbm90IHRvbyByZXN0cmljdGl2ZSB3aGlsZSBn dWFyYW50ZWVpbmcgDQp0aGF0DQo+ID4gYW4gZW50cnkgd2lsbCBiZSBjcmVhdGVkIGF0IHNvbWUg cG9pbnQuICBJIGZpbmQgKDQpIHRlbXB0aW5nLCBzaW5jZSBpdCANCmlzDQo+ID4gdGhlIGxlYXN0 IHJlc3RyaWN0aXZlLCBidXQgaXQgcmVxdWlyZXMgYWRkaXRpb25hbCBsYW5ndWFnZSB0byBlbnN1 cmUgDQp0aGF0DQo+ID4gYW4gZW50cnkgaXMgY3JlYXRlZCBhdCBzb21lIHBvaW50LCBhbmQgSSdt IG5vdCBzdXJlIHdoYXQgaXQgaXMuICAoT3INCj4gPiBwZXJoYXBzIGl0IGRvZXNuJ3QgLS0gYWZ0 ZXIgYWxsLCB3aGV0aGVyIHRvIHNwZWFrIHRvIGEgZ2l2ZW4gbmVpZ2hib3VyIA0KaXMNCj4gPiBh biBpbXBsZW1lbnRhdGlvbiBkZXRhaWwuKQ0KPiA+IA0KPiA+IE5vbmUgb2YgdGhlIGFib3ZlIGZp eCBEZW5pcycgcHJvYmxlbSwgd2hpY2ggc2hvdWxkIGJlIGhhbmRsZWQgaW4gdGhlIA0KSE1BQw0K PiA+IHByb3RvY29sLCBub3QgaW4gdGhlIGNvcmUgcHJvdG9jb2wuICBJIHRoaW5rIERlbmlzIHNo b3VsZCBhZGQNCj4gPiBhIHJlcXVpcmVtZW50IHRoYXQgc2F5cyB0aGF0IGEgcGFja2V0IGZhaWxz IHZhbGlkYXRpb24gdW5sZXNzIHRoZQ0KPiA+IG5laWdoYm91ciBoYXMgc2VudCBzb21ldGhpbmcg aW4gdGhlIGxhc3Qgc29tZXRoaW5nLCBidXQgSSdtIG5vdCBjbGVhcg0KPiA+IGFib3V0IHRoZSBk ZXRhaWxzLg0KPiA+IA0KPiA+IEFyZSB3ZSBhZ3JlZWQ/DQo+ID4gDQo+ID4gLS0gSnVsaXVzeg0K PiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gYmFiZWwgbWFpbGluZyBsaXN0DQo+ID4gYmFiZWxAaWV0Zi5vcmcNCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JhYmVsDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBiYWJlbCBtYWlsaW5nIGxpc3QN Cj4gYmFiZWxAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9iYWJlbA0KDQo= --=_alternative 0024287B48258089_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgcHJlZmVyICgzKSB0b28uIEkg dGhpbmsgdGhhdCB0aGUgbmVpZ2hib3VyDQplbnRyeSBpcyB2ZXJ5IHVzZWZ1bCBmb3IgPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5kZWJ1Z2dpbmcgd2hlbmV2ZXIg YW55IHBhY2tldCBpcyByZWNlaXZlZC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPklmIGl0IGlzIGJldHRlciB0aGF0IHVzZSChsFNIT1VMRKGxDQpyZXBsYWNlIKGw TUFZobE/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4oMykgYSBu ZWlnaGJvdXIgZW50cnkgTVVTVCBiZSBjcmVhdGVkDQp1cG9uIHJlY2VpdmluZyBhIEhlbGxvLCBh bmQgU0hPVUxEIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YmUg Y3JlYXRlZCB1cG9uIHJlY2VpdmluZyBhbnkga2luZCBvZg0KcGFja2V0OzwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U2FuZHk8L2ZvbnQ+DQo8YnI+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mcXVvdDtiYWJlbCZxdW90OyAmbHQ7YmFiZWwtYm91 bmNlc0BpZXRmLm9yZyZndDsg0LTT2g0KMjAxNi8xMi8xNCAxMToyNToxOTo8YnI+DQo8YnI+DQom Z3Q7IEkgYWdyZWUgd2l0aCB0aGUgc3Bpcml0IG9mIHdoYXQgSnVsaXVzeiBzYXlzLjxicj4NCiZn dDsgUmVnYXJkaW5nIGFjdHVhbCBwaHJhc2luZywgaG93IGFib3V0IHRoZSBmb2xsb3dpbmcgbWlk ZGxlIGdyb3VuZDo8YnI+DQomZ3Q7IDxicj4NCiZndDsgKDUpIEEgbmVpZ2hib3VyIGVudHJ5IE1B WSBiZSBjcmVhdGVkIHVwb24gcmVjZWl2aW5nIGFueSBraW5kIG9mIHBhY2tldC48YnI+DQomZ3Q7 IElmIGFuIGltcGxlbWVudGF0aW9uIHdpc2hlcyB0byBleGNoYW5nZSByb3V0aW5nIGluZm9ybWF0 aW9uIHdpdGggYQ0KZ2l2ZW48YnI+DQomZ3Q7IHBlZXIsIGl0IE1VU1QgY3JlYXRlIGEgbmVpZ2hi b3VyIGVudHJ5IHVwb24gcmVjZWl2aW5nIGEgSGVsbG8sIGlmDQphIDxicj4NCiZndDsgY29ycmVz cG9uZGluZyBlbnRyeSBkb2VzIG5vdCBhbHJlYWR5IGV4aXN0Ljxicj4NCiZndDsgPGJyPg0KJmd0 OyBCdXQgdGhhdCBzdGFydHMgc291bmRpbmcgY29tcGxpY2F0ZWQgYW5kIEkgcmVhbGx5IGRvbid0 IGZlZWwgc3Ryb25nbHk8YnI+DQomZ3Q7IGFib3V0IHRoZSBhY3R1YWwgd29yZGluZyBhcyBsb25n IGFzIEknbSBub3QgcmVxdWlyZWQgdG8gaWdub3JlIHBhY2tldHM8YnI+DQomZ3Q7IHJlY2VpdmVk IGJlZm9yZSB0aGUgZmlyc3QgSGVsbG8uIEFuZCBub3cgdGhhdCBJIHRoaW5rIGFib3V0IGl0IGlu DQp0aG9zZSB0ZXJtcyw8YnI+DQomZ3Q7IGhvdyBhYm91dDo8YnI+DQomZ3Q7IDxicj4NCiZndDsg KDYpIEEgbmVpZ2hib3VyIGVudHJ5IE1BWSBiZSBjcmVhdGVkIHVwb24gcmVjZWl2aW5nIGFueSBr aW5kIG9mIHBhY2tldC48YnI+DQomZ3Q7IEFuIGltcGxlbWVudGF0aW9uIE1BWSBjaG9vc2UgdG8g aWdub3JlIGFueSBwYWNrZXQgcmVjZWl2ZWQgZnJvbSBhDQpwZWVyPGJyPg0KJmd0OyBiZWZvcmUg YSBIZWxsbyBwYWNrZXQsIGFuZCBjcmVhdGUgdGhlIG5laWdoYm91ciBlbnRyeSB1cG9uIHJlY2Vp dmluZw0KdGhhdDxicj4NCiZndDsgZmlyc3QgSGVsbG8uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IERh dmlkPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBPbiBEZWMgMTMsIDIwMTYs IGF0IDE4OjA5LCBKdWxpdXN6IENocm9ib2N6ZWsgJmx0O2pjaEBpcmlmLmZyJmd0Ow0Kd3JvdGU6 PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBTbywgbXkgcmVhZGluZyBvZiB0aGlzIGRp c2N1c3Npb24gaXMgdGhhdCAzLjQuMSBhbmQgMy40LjIgbXVzdA0KYmU8YnI+DQomZ3Q7ICZndDsg cmV3cml0dGVuLiAmbmJzcDtJbiBhZGRpdGlvbiB0byB0aGF0LCB3ZSBuZWVkIHRvIGRlY2lkZSBi ZXR3ZWVuDQp0aGUgZm9sbG93aW5nOjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5i c3A7KDEpIGEgbmVpZ2hib3VyIGVudHJ5IE1VU1QgYmUgY3JlYXRlZCB1cG9uIHJlY2VpdmluZyBh bnkNCmtpbmQgb2YgcGFja2V0Ozxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgb3I8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOygyKSBhIG5laWdoYm91ciBlbnRyeSBN VVNUIGJlIGNyZWF0ZWQgdXBvbiByZWNlaXZpbmcgYQ0KSGVsbG8sIE1BWSBiZTxicj4NCiZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NyZWF0ZWQgdXBvbiByZWNlaXZpbmcgYW4gSUhVOzxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgb3I8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7ICZuYnNwOygzKSBhIG5laWdoYm91ciBlbnRyeSBNVVNUIGJlIGNyZWF0ZWQgdXBvbiBy ZWNlaXZpbmcgYQ0KSGVsbG8sIGFuZCBNQVkgYmU8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtjcmVhdGVkIHVwb24gcmVjZWl2aW5nIGFueSBraW5kIG9mIHBhY2tldDs8YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IG9yPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyAmbmJzcDsoNCkgYSBuZWlnaGJvdXIgZW50cnkgTUFZIGJlIGNyZWF0ZWQgdXBvbiByZWNlaXZp bmcgYW55DQpraW5kIG9mIHBhY2tldC48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE15 IHByZWZlcmVuY2UgaXMgKDMpLCB3aGljaCBpcyBub3QgdG9vIHJlc3RyaWN0aXZlIHdoaWxlIGd1 YXJhbnRlZWluZw0KdGhhdDxicj4NCiZndDsgJmd0OyBhbiBlbnRyeSB3aWxsIGJlIGNyZWF0ZWQg YXQgc29tZSBwb2ludC4gJm5ic3A7SSBmaW5kICg0KSB0ZW1wdGluZywNCnNpbmNlIGl0IGlzPGJy Pg0KJmd0OyAmZ3Q7IHRoZSBsZWFzdCByZXN0cmljdGl2ZSwgYnV0IGl0IHJlcXVpcmVzIGFkZGl0 aW9uYWwgbGFuZ3VhZ2UgdG8NCmVuc3VyZSB0aGF0PGJyPg0KJmd0OyAmZ3Q7IGFuIGVudHJ5IGlz IGNyZWF0ZWQgYXQgc29tZSBwb2ludCwgYW5kIEknbSBub3Qgc3VyZSB3aGF0IGl0IGlzLg0KJm5i c3A7KE9yPGJyPg0KJmd0OyAmZ3Q7IHBlcmhhcHMgaXQgZG9lc24ndCAtLSBhZnRlciBhbGwsIHdo ZXRoZXIgdG8gc3BlYWsgdG8gYSBnaXZlbg0KbmVpZ2hib3VyIGlzPGJyPg0KJmd0OyAmZ3Q7IGFu IGltcGxlbWVudGF0aW9uIGRldGFpbC4pPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBO b25lIG9mIHRoZSBhYm92ZSBmaXggRGVuaXMnIHByb2JsZW0sIHdoaWNoIHNob3VsZCBiZSBoYW5k bGVkDQppbiB0aGUgSE1BQzxicj4NCiZndDsgJmd0OyBwcm90b2NvbCwgbm90IGluIHRoZSBjb3Jl IHByb3RvY29sLiAmbmJzcDtJIHRoaW5rIERlbmlzIHNob3VsZA0KYWRkPGJyPg0KJmd0OyAmZ3Q7 IGEgcmVxdWlyZW1lbnQgdGhhdCBzYXlzIHRoYXQgYSBwYWNrZXQgZmFpbHMgdmFsaWRhdGlvbiB1 bmxlc3MNCnRoZTxicj4NCiZndDsgJmd0OyBuZWlnaGJvdXIgaGFzIHNlbnQgc29tZXRoaW5nIGlu IHRoZSBsYXN0IHNvbWV0aGluZywgYnV0IEknbSBub3QNCmNsZWFyPGJyPg0KJmd0OyAmZ3Q7IGFi b3V0IHRoZSBkZXRhaWxzLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgQXJlIHdlIGFn cmVlZD88YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IC0tIEp1bGl1c3o8YnI+DQomZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IGJhYmVsIG1haWxpbmcgbGlzdDxicj4NCiZndDsg Jmd0OyBiYWJlbEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2JhYmVsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBiYWJlbCBtYWlsaW5n IGxpc3Q8YnI+DQomZ3Q7IGJhYmVsQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JhYmVsPGJyPg0KPC90dD48L2ZvbnQ+DQo= --=_alternative 0024287B48258089_=-- From nobody Tue Dec 13 23:14:01 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A671129864 for ; Tue, 13 Dec 2016 23:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 ukVgPVyGvpk8 for ; Tue, 13 Dec 2016 23:13:58 -0800 (PST) Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.231]) by ietfa.amsl.com (Postfix) with ESMTP id BC35A129731 for ; Tue, 13 Dec 2016 23:13:57 -0800 (PST) Received: from [192.168.100.78] (36.2.75.216) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 5782991C05942043; Wed, 14 Dec 2016 09:11:17 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Markus Stenberg In-Reply-To: <02F27EAF-A0BC-4477-8043-F7B2AA288CE1@apple.com> Date: Wed, 14 Dec 2016 16:13:46 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8760mnclcs.wl-jch@irif.fr> <02F27EAF-A0BC-4477-8043-F7B2AA288CE1@apple.com> To: David Schinazi X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Babel at IETF , Juliusz Chroboczek Subject: Re: [babel] Discussion about Denis' comments: conclusion? 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, 14 Dec 2016 07:14:00 -0000 > On 14.12.2016, at 12.25, David Schinazi wrote: > (6) A neighbour entry MAY be created upon receiving any kind of = packet. > An implementation MAY choose to ignore any packet received from a peer > before a Hello packet, and create the neighbour entry upon receiving = that > first Hello. I like 6, as forcing (MUST) neighbor in any case seems unneccessary (you = may e.g. only care about subset of nodes for some reason that share the = link). And this (6) is bit more prescriptive than Juliusz' (4) which I = also like. Cheers, -Markus= From nobody Wed Dec 14 05:35:23 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E23129663 for ; Wed, 14 Dec 2016 05:35:19 -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 LO4Pn2vSanZH for ; Wed, 14 Dec 2016 05:35:17 -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 BD416129674 for ; Wed, 14 Dec 2016 05:35:14 -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 uBEDZAUB009656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Dec 2016 14:35:12 +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 uBEDZ9QO009721; Wed, 14 Dec 2016 14:35:10 +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 17DD4D78B9; Wed, 14 Dec 2016 14:35:09 +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 EdeSbuKgQt89; Wed, 14 Dec 2016 14:35:08 +0100 (CET) Received: from trurl.irif.fr (unknown [78.250.0.5]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E1B07D7A24; Wed, 14 Dec 2016 14:35:03 +0100 (CET) Date: Wed, 14 Dec 2016 14:35:16 +0100 Message-ID: <8737hqskff.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg In-Reply-To: References: <8760mnclcs.wl-jch@irif.fr> <02F27EAF-A0BC-4477-8043-F7B2AA288CE1@apple.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 14 Dec 2016 14:35:12 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 14 Dec 2016 14:35:10 +0100 (CET) X-Miltered: at korolev with ID 58514A8E.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58514A8D.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58514A8E.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58514A8D.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 58514A8E.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58514A8D.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: Babel at IETF Subject: Re: [babel] Discussion about Denis' comments: conclusion? 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, 14 Dec 2016 13:35:19 -0000 Okay, perhaps we're doing it wrong. Why not assume that the reader is of average intelligence or higher, and not spelling out everything? When to create a neighbour entry for a given neighbour is a matter of implementation policy, as long as a neighbour entry is eventually created for any neighbour with which the current node wishes to exchange routing information. A simple strategy is to create a neighbour entry whenever the current node receives a packet from a new neighbour, or at least whenever it receives a Hello TLV. From nobody Wed Dec 14 05:45:10 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9C0129699 for ; Wed, 14 Dec 2016 05:45:09 -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 bhi98eFFCPSD for ; Wed, 14 Dec 2016 05:45:04 -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 328AC129546 for ; Wed, 14 Dec 2016 05:45:04 -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 uBEDj2VG016036; Wed, 14 Dec 2016 14:45:02 +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 16D71D7AAE; Wed, 14 Dec 2016 14:45:02 +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 IrhHGWSfsclJ; Wed, 14 Dec 2016 14:45:00 +0100 (CET) Received: from trurl.irif.fr (unknown [78.250.0.5]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 5F27DD7AAD; Wed, 14 Dec 2016 14:44:59 +0100 (CET) Date: Wed, 14 Dec 2016 14:45:12 +0100 Message-ID: <871sxasjyv.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg In-Reply-To: <8737hqskff.wl-jch@irif.fr> References: <8760mnclcs.wl-jch@irif.fr> <02F27EAF-A0BC-4477-8043-F7B2AA288CE1@apple.com> <8737hqskff.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 14 Dec 2016 14:45:02 +0100 (CET) X-Miltered: at korolev with ID 58514CDE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58514CDE.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 : 58514CDE.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] Discussion about Denis' comments: conclusion? 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, 14 Dec 2016 13:45:09 -0000 > When to create a neighbour entry for a given neighbour is a matter of > implementation policy, as long as a neighbour entry is eventually > created for any neighbour with which the current node wishes to > exchange routing information. A simple strategy is to create > a neighbour entry whenever the current node receives a packet from > a new neighbour, or at least whenever it receives a Hello TLV. And if we want to be wholly explicit, et the risk of insulting the reader's intelligence: An implementation MAY choose to drop all packets from a given neighbour until it decides to create an entry in the neighbours table. Protocol extensions may want to put further restrictions on when a neighbour entry is created, notably for security reasons. -- Juliusz From nobody Wed Dec 14 08:24:23 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C271129EA5 for ; Wed, 14 Dec 2016 08:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40ObT-j6_Zx8 for ; Wed, 14 Dec 2016 08:24:20 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::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 58C59129EA2 for ; Wed, 14 Dec 2016 08:22:59 -0800 (PST) Received: from mail.toke.dk (localhost.localdomain [127.0.0.1]) by mail.toke.dk (Postfix) with ESMTPS id 8ED1D20E5C; Wed, 14 Dec 2016 17:22:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1481732572; bh=BcC4NdvChfueJEK8851cBmeq9S4llWzjvB1w84kpJvY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=nWR+UI+jGeZIyKENB4Ny0uQF1KmxLdUiRyRRRyzlbkaDG67lpvuP3U+WObEOuTh4P kkutgb4whzdiHXJ+7Wdx6vuDkT6i5Z3caeYrkeAuq5B4bb1jkJvDVLYzVClUSfBf0v 8LW2wfgfGmmin+IECcFlcfwQ87VEHuZCriL+PU7hL3eE/Fz3JMdjv+SVBTEiW48jJJ 6Vum0gngYKXDytoZpWzKgQXdXm9bIuqhnilYTCx1AiwJzqJ+vcQPDQ2pSEh+mTFnfj KaR0UKTSUMczlqjeyjJIoHFG/Ix///b4ZedUs0QueWUR0GVxiPTsgZOb3ee20drbCs amEt+P/gZSLIQ== Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 7C10713E31; Wed, 14 Dec 2016 08:22:20 -0800 (PST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Juliusz Chroboczek References: <8760mnclcs.wl-jch@irif.fr> <02F27EAF-A0BC-4477-8043-F7B2AA288CE1@apple.com> <8737hqskff.wl-jch@irif.fr> <871sxasjyv.wl-jch@irif.fr> Date: Wed, 14 Dec 2016 08:22:20 -0800 In-Reply-To: <871sxasjyv.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Wed, 14 Dec 2016 14:45:12 +0100") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87r35ascoz.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Markus Stenberg , Babel at IETF Subject: Re: [babel] Discussion about Denis' comments: conclusion? 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, 14 Dec 2016 16:24:22 -0000 Juliusz Chroboczek writes: >> When to create a neighbour entry for a given neighbour is a matter of >> implementation policy, as long as a neighbour entry is eventually >> created for any neighbour with which the current node wishes to >> exchange routing information. A simple strategy is to create >> a neighbour entry whenever the current node receives a packet from >> a new neighbour, or at least whenever it receives a Hello TLV. I like this one. Or alternatively (3) above. > And if we want to be wholly explicit, et the risk of insulting the > reader's intelligence: > > An implementation MAY choose to drop all packets from a given > neighbour until it decides to create an entry in the neighbours table. > Protocol extensions may want to put further restrictions on when > a neighbour entry is created, notably for security reasons. I am generally of the opinion that we should keep the number of insults to the reader's intelligence to a reasonable number in a document such as this... -Toke From nobody Wed Dec 28 08:11:29 2016 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 331C4128AC9; Wed, 28 Dec 2016 08:11:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148294148816.20176.14457107451965053377.idtracker@ietfa.amsl.com> Date: Wed, 28 Dec 2016 08:11:28 -0800 Archived-At: Cc: babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org, akatlas@gmail.com Subject: [babel] babel - New Meeting Session Request for IETF 98 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: Wed, 28 Dec 2016 16:11:28 -0000 A new meeting session request has just been submitted by Donald E. Eastlake 3rd, a Chair of the babel working group. --------------------------------------------------------- Working Group Name: Babel routing protocol Area Name: Routing Area Session Requester: Donald Eastlake Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: manet ospf homenet trill saag lpwan isis idr rtgwg i2rs netmod netconf Second Priority: dnsop dnssd 6man v6ops Special Requests: --------------------------------------------------------- From nobody Wed Dec 28 08:14:58 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BA112987D for ; Wed, 28 Dec 2016 08:14:56 -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 gI82VkoJqB_1 for ; Wed, 28 Dec 2016 08:14:55 -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 5A942128AC9 for ; Wed, 28 Dec 2016 08:14:55 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id o141so171969446itc.0 for ; Wed, 28 Dec 2016 08:14:55 -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=8x0M5RklnqcdvTvt1/WhTJzZqFsqgGhX3f4W8L9K5co=; b=arSS0xnTcE4nYbIw8OOvqKwVA1mhrUaenNtM5Dm5e97d1XEG83lzZwqFkUD6LF0nvl rYOfLdIsZLXIsLlxEkmFHCAoUq5Dzbtqf/qmWZmaeDpOyOmOUiBsn0ctSkO9FA5QmVrW MOYACpNH6VExf47d7jvTd0UdZ9mDBkgn+PQkW+9Yyj1PRXV6WomTyGHzGtj8cYv/ZVMq CFZB/HjvBMjkK41CzeMRlr7yDvfmJnvrp1JVXdRC120uou5/1TzZJTv4sjEPtNqYgM+q YH7GFHPYiwJ89B15/lMehYmGOFCGmLxYgjnBGqsANx11Vl/q071T5B5Eeq7lhocH8wkl cmyA== 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=8x0M5RklnqcdvTvt1/WhTJzZqFsqgGhX3f4W8L9K5co=; b=QRM2+AdAoNEPwnsoqisjOqpzjrf1/EHeYVA8tl+tufYoCrqxha1TeyY/IqnAkgtc3C I79Vx2Lhj0xIfr8gNyq+NCexKDRgzxs/Lf8/gq+5id2JsncPO2RbtnVts6fArB3Gq8im 8JpwHxP4CpnW9fbsBFO4tKAleMYpJI9DtUzlcZ+sr/5j8FPG2fpBzU52nTwO5lKoENLR 06U0Vk0qIEAqr1HBDCmH60kgQOxoeSTIQV7YE7Uv4Mc3+YfSV4X2FRp460LtIr9ectdb asTv4+jTtEB4geLSiAkQkDwdvJyOwdLhfkvB2irvTQZbN00YCz+jLCayMxLNhhpnZ0Ny U7eg== X-Gm-Message-State: AIkVDXIfko3ZOmvQK+1iayV7sstheXLm0IjRNqtvseLjjlFGmgkPhbF5VA9bvTQLmLetmspZvpEV//yarbg5jA== X-Received: by 10.36.96.70 with SMTP id i67mr25036465itc.59.1482941694714; Wed, 28 Dec 2016 08:14:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.136 with HTTP; Wed, 28 Dec 2016 08:14:39 -0800 (PST) From: Donald Eastlake Date: Wed, 28 Dec 2016 11:14:39 -0500 Message-ID: To: Babel at IETF Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [babel] Draft minutes from Seoul uploaded 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, 28 Dec 2016 16:14:57 -0000 Draft minutes from the BABEL WG meeting at the last IETF meeting in Seoul were uploaded a while ago. Sorry for the delay in announcing them. Comments welcome. See https://www.ietf.org/proceedings/97/minutes/minutes-97-babel-00.txt Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com