From nobody Thu Dec 5 03:50:51 2019 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 6A7261200F8; Thu, 5 Dec 2019 03:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 qmedEGukrrzR; Thu, 5 Dec 2019 03:50:46 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 1D86E120105; Thu, 5 Dec 2019 03:50:46 -0800 (PST) Received: from 200116b82cc7ef0034996fbfb45dc371.dip.versatel-1u1.de ([2001:16b8:2cc7:ef00:3499:6fbf:b45d:c371]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1icpeX-0004ki-Tr; Thu, 05 Dec 2019 12:50:37 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <87imomknn0.wl-jch@irif.fr> Date: Thu, 5 Dec 2019 12:50:37 +0100 Cc: draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs , Babel at IETF , The IESG , Alvaro Retana , Martin Vigoureux Content-Transfer-Encoding: quoted-printable Message-Id: References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1575546646;0a48da61; X-HE-SMSGID: 1icpeX-0004ki-Tr Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 11:50:48 -0000 Hi Juliusz, hi all, I took another look at the updated RFC and I have to say I=E2=80=99m = still concerned about the default values (which is also an issue that = was also raised by Alvaro) and the appendix B. You know added another case: "The following values are recommended in a network where reconvergence within 2 seconds after a mobility event is desired: Multicast Hello Interval: 0.5 seconds. Unicast Hello Interval: infinite (no Unicast Hellos are sent). Link cost, IHU Interval, Update Interval, IHU Hold Time, and Route Expiry Time: computed as in the first case above. Request Timeout: initially 0.5 seconds, doubled every time a request is resent, up to a maximum of three times. Urgent timeout: 0.2 seconds. Source GC time: 3 minutes.=E2=80=9D These value are much lower than in the first case and can easily leads = to signification congestion, however, you don=E2=80=99t say anything = appropriate about when those value might be used or should be avoided. = What appendix B does is simply given some sample calculation about what = the expected reconvergence time is based on the selected values but it = does not give any guidance about which network conditions would bear = which setup, nor does it talk about negative implication of selecting = lower values. I still think that it is important to provide default values as part of = the normative specification. For me finding such default value (maybe = with more discussions about in which network scenarios these vales makes = sense and when it might be useful to consider different values) was part = of the experiment with babel and if you are not able to address these = questions, babel is not ready for PS.=20 Alternatively you can check the values in RFC8085 again and see if these = are acceptable values for most scenarios. Values in that RFC are lightly = lower than the first example (e.g. 3 secs interval and 1 sec timeout) = but quite a bit larger than the new example you introduced (without = further guidance on usage of the values). Especially in section 3.8.2.1. regarding the Request Timeout it is not = sufficient to only point to the appendix. Please also note that there = are actually two values here that need suitable default values, the = time-out itself and the number of retries. Thanks! Mirja > On 18. Oct 2019, at 18:46, Juliusz Chroboczek wrote: >=20 > Dear Mirja, >=20 >> 1) Let's move appendix B into the body of the document. I think these >> are important information for an implementer and therefore it needs = more >> attention. >=20 > I am sorry, but I disagree. The original document that I submitted = for > IETF review back in 2009 had the structure that you suggest, but the > reviewer (Joel Halpern) convinced me to a adopt the following = structure: >=20 > - the body of the document describes the main algorithm, the parts = that > are required to enforce the strong guarantees that the protocol = makes > about lack of loops and forward progress; > - the appendices describe algorithms that have been shown to be = useful > over some link layers but that might need to be tweaked when Babel = is > run over new, exciting link layers. >=20 > Since Joel did a good job convincing me, it will take some work to > convince me otherwise. >=20 >> 2) Maybe you can add something like: [...] I=E2=80=99m sure you have = a better >> wording. My intention is simply to add another warning, to think >> carefully instead of just pick some default. >=20 > I don't necessarily agree, but I've done as you request. >=20 >>>> Thanks. I was also hoping that you could make any recommendation on = how >>>> to implement that e.g. a fixed delay of a certain (default) value = or >>>> based on some other knowledge. [...] >=20 >>> You do realise it's a very high bar you're setting? >=20 > [...] >=20 >> I wasn=E2=80=99t looking for a tutorial for pacing but rather a = reference to >> add. E.g. just naming different approaches for how to implement = pacing >> and provide a reference would be a good thing I think. However, I = will >> not block on this one thing. Your choice. >=20 > I am not aware of any good reference on packet pacing that covers IEEE > 802.11 multicast (an important usecase for Babel). After checking = some > papers and scratching my head for a long time, I've just added another > sentence to Section 3.1; I'm afraid I'm not competent to do anything = more. >=20 >> I just wondering why you don=E2=80=99t call them default value rather = then >> examples. I think specifying default value normatively would be more >> clear and is what we usually do in specs. However, I think in this = case >> it will not make a huge practical difference. >=20 > Great, let's agree that we're not in full agreement, then. >=20 > -- Juliusz >=20 >=20 >=20 From nobody Thu Dec 5 03:53:31 2019 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 C4112120108; Thu, 5 Dec 2019 03:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 BGzGcnhS4L36; Thu, 5 Dec 2019 03:53:23 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 1FF541200F8; Thu, 5 Dec 2019 03:53:23 -0800 (PST) Received: from 200116b82cc7ef0034996fbfb45dc371.dip.versatel-1u1.de ([2001:16b8:2cc7:ef00:3499:6fbf:b45d:c371]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1icph9-0007KD-UR; Thu, 05 Dec 2019 12:53:19 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Thu, 5 Dec 2019 12:53:19 +0100 Cc: draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs , Babel at IETF , The IESG , Alvaro Retana , Martin Vigoureux Content-Transfer-Encoding: quoted-printable Message-Id: <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1575546803;9af5b230; X-HE-SMSGID: 1icph9-0007KD-UR Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 11:53:25 -0000 Hi again, And one more comment regarding pacing: Again I will not block on this = issue anymore, however, as you have a babel implementation I would = assume it would be easy to add more details on how pacing is done in = your implementation in the draft (at least in the appendix). Mirja > On 5. Dec 2019, at 12:50, Mirja Kuehlewind = wrote: >=20 > Hi Juliusz, hi all, >=20 > I took another look at the updated RFC and I have to say I=E2=80=99m = still concerned about the default values (which is also an issue that = was also raised by Alvaro) and the appendix B. >=20 > You know added another case: >=20 > "The following values are recommended in a network where reconvergence > within 2 seconds after a mobility event is desired: >=20 > Multicast Hello Interval: 0.5 seconds. >=20 > Unicast Hello Interval: infinite (no Unicast Hellos are sent). >=20 > Link cost, IHU Interval, Update Interval, IHU Hold Time, and = Route > Expiry Time: computed as in the first case above. >=20 > Request Timeout: initially 0.5 seconds, doubled every time a > request is resent, up to a maximum of three times. >=20 > Urgent timeout: 0.2 seconds. >=20 > Source GC time: 3 minutes.=E2=80=9D >=20 > These value are much lower than in the first case and can easily leads = to signification congestion, however, you don=E2=80=99t say anything = appropriate about when those value might be used or should be avoided. = What appendix B does is simply given some sample calculation about what = the expected reconvergence time is based on the selected values but it = does not give any guidance about which network conditions would bear = which setup, nor does it talk about negative implication of selecting = lower values. >=20 > I still think that it is important to provide default values as part = of the normative specification. For me finding such default value (maybe = with more discussions about in which network scenarios these vales makes = sense and when it might be useful to consider different values) was part = of the experiment with babel and if you are not able to address these = questions, babel is not ready for PS.=20 >=20 > Alternatively you can check the values in RFC8085 again and see if = these are acceptable values for most scenarios. Values in that RFC are = lightly lower than the first example (e.g. 3 secs interval and 1 sec = timeout) but quite a bit larger than the new example you introduced = (without further guidance on usage of the values). >=20 > Especially in section 3.8.2.1. regarding the Request Timeout it is not = sufficient to only point to the appendix. Please also note that there = are actually two values here that need suitable default values, the = time-out itself and the number of retries. >=20 > Thanks! > Mirja >=20 >=20 >> On 18. Oct 2019, at 18:46, Juliusz Chroboczek wrote: >>=20 >> Dear Mirja, >>=20 >>> 1) Let's move appendix B into the body of the document. I think = these >>> are important information for an implementer and therefore it needs = more >>> attention. >>=20 >> I am sorry, but I disagree. The original document that I submitted = for >> IETF review back in 2009 had the structure that you suggest, but the >> reviewer (Joel Halpern) convinced me to a adopt the following = structure: >>=20 >> - the body of the document describes the main algorithm, the parts = that >> are required to enforce the strong guarantees that the protocol = makes >> about lack of loops and forward progress; >> - the appendices describe algorithms that have been shown to be = useful >> over some link layers but that might need to be tweaked when Babel = is >> run over new, exciting link layers. >>=20 >> Since Joel did a good job convincing me, it will take some work to >> convince me otherwise. >>=20 >>> 2) Maybe you can add something like: [...] I=E2=80=99m sure you = have a better >>> wording. My intention is simply to add another warning, to think >>> carefully instead of just pick some default. >>=20 >> I don't necessarily agree, but I've done as you request. >>=20 >>>>> Thanks. I was also hoping that you could make any recommendation = on how >>>>> to implement that e.g. a fixed delay of a certain (default) value = or >>>>> based on some other knowledge. [...] >>=20 >>>> You do realise it's a very high bar you're setting? >>=20 >> [...] >>=20 >>> I wasn=E2=80=99t looking for a tutorial for pacing but rather a = reference to >>> add. E.g. just naming different approaches for how to implement = pacing >>> and provide a reference would be a good thing I think. However, I = will >>> not block on this one thing. Your choice. >>=20 >> I am not aware of any good reference on packet pacing that covers = IEEE >> 802.11 multicast (an important usecase for Babel). After checking = some >> papers and scratching my head for a long time, I've just added = another >> sentence to Section 3.1; I'm afraid I'm not competent to do anything = more. >>=20 >>> I just wondering why you don=E2=80=99t call them default value = rather then >>> examples. I think specifying default value normatively would be more >>> clear and is what we usually do in specs. However, I think in this = case >>> it will not make a huge practical difference. >>=20 >> Great, let's agree that we're not in full agreement, then. >>=20 >> -- Juliusz >>=20 >>=20 >>=20 >=20 From nobody Tue Dec 10 17:15:34 2019 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 E91A0120086; Tue, 10 Dec 2019 17:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 RfxMMqo2lxVk; Tue, 10 Dec 2019 17:15:30 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7A7120059; Tue, 10 Dec 2019 17:15:30 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id 21so22077149ljr.0; Tue, 10 Dec 2019 17:15:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vomdwQLIUTPP9NX821+dqPFt+XvaM3NL2a3jaDsEgNQ=; b=oMwc/ppybPzXbV8leFlpinoIX2kzEI1MV6lwmQ5AbCeXNhWlzibseUMEqvDma6VkDQ HwYrJbIpPesuxwQYvyfQbCcp1TjNvMAM3xFOClvvxDBrSFrnUuYZIc4qz1XaUbgEBscw dFPULO4gJopown0HOHBLWe1/prkA9gLvNjhT5fcnoxYqpS5CoorbayyMU3+cLYK4yW7b nfC7XIn62syfdGBLf/79DEQPs+chZ9stXsjvl/2eo02h3qKMOreP1+YCoF/qq6l1ULE/ ZTvUrlzNsODWq2GofWCy8xNnpHy45B4Q+cr3ZOXx07NltejELHDeBjAvu8l5YtbNebFB 17VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vomdwQLIUTPP9NX821+dqPFt+XvaM3NL2a3jaDsEgNQ=; b=uUygdH9ZwlRD4kg0IiA02tXRa+pF7ctBm5njvipUYcD5EtLxsTPJoS9Ymh+yx/2kbf 9RuTMIfU8w2FihJo/Od632gvTmd6yvhdG38Gr2zQP7eErzZYMePMP4NfL88ELvf7/aoz afYGXDftgXUZJAil10DCRFXxJIjFxp6p9kxpQ3VcvbkS6FaOip4e6AYw7kQyWhBv6Bx+ 9ib94nlHR8Sqk1VXAdRpezuEr9OnJ0p5j375i18vQM6WQ9zxLysZ47X24+XMk3w229X6 gs3qJMpO+Ll+BMfcaoYwsow2oVBbqvc0kTVWHZptEbzDFEorpN5txFuc9AVzLmWKoYkc sgVw== X-Gm-Message-State: APjAAAUiB7Uc30gEIvaLiAueVeGjRh7KsAX8fLa4CZt5y+N57Gp/E4EA Fowk91tNunFkWWmGChklo/pfa0mr9zJUfFEpEfE= X-Google-Smtp-Source: APXvYqzBoU1ymL7pAvEWvrrWK5uvVo/EVP/j22LKvqtIQ8Aoqh6N9rA2jbPRBtMxwW5ktDS1h+zJoUyyOMgsUBsGW3I= X-Received: by 2002:a2e:241a:: with SMTP id k26mr168439ljk.26.1576026928209; Tue, 10 Dec 2019 17:15:28 -0800 (PST) MIME-Version: 1.0 References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> In-Reply-To: <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> From: David Schinazi Date: Tue, 10 Dec 2019 17:15:17 -0800 Message-ID: To: Mirja Kuehlewind Cc: Juliusz Chroboczek , draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs , Babel at IETF , The IESG , Alvaro Retana , Martin Vigoureux Content-Type: multipart/alternative; boundary="0000000000003664010599635dc5" Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 11 Dec 2019 01:15:33 -0000 --0000000000003664010599635dc5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mirja, Thank you for taking another look at the document. I hope we can get this resolved quickly, as we have already waited for 49 days for your last email. I understand that you are busy but I did want to point out that this is adding stress on the authors. First, it appears that your review is still treating Babel like a protocol running over UDP on the Internet. It is not. Babel only operates point-to-point using IPv6 link-local addresses, and the congestion properties of 802.11 are very different from the ones of an end-to-end transport running over the wide area. Second, the Babel working group prides itself with strict adherence to the running code principle. Features or recommendations do not make it into a Babel spec unless they have been implemented and tested. If we were discussing a transport protocol, I would agree with your review. RFC 8085 is a great document, but it wasn't written with link-local routing protocols in mind. As transport AD, it is your responsibility to ensure new IETF protocols do not bring about another congestion collapse, and I think that's critical. I want to really thank you for the hours you spend reviewing documents to ensure that goal. But I don't think all of that guidance applies here. Could I kindly ask you to take another look at your review in this lens, and please let us know in what way you think this draft has real-world issues? We'd really like to make forward progress here, if the only issue is default values, I'm not sure this is worth causing delays on, as we haven't seen these cause problems when implementing the protocol. Thanks, David On Thu, Dec 5, 2019 at 3:53 AM Mirja Kuehlewind wrote= : > Hi again, > > And one more comment regarding pacing: Again I will not block on this > issue anymore, however, as you have a babel implementation I would assume > it would be easy to add more details on how pacing is done in your > implementation in the draft (at least in the appendix). > > Mirja > > > > > On 5. Dec 2019, at 12:50, Mirja Kuehlewind wrote: > > > > Hi Juliusz, hi all, > > > > I took another look at the updated RFC and I have to say I=E2=80=99m st= ill > concerned about the default values (which is also an issue that was also > raised by Alvaro) and the appendix B. > > > > You know added another case: > > > > "The following values are recommended in a network where reconvergence > > within 2 seconds after a mobility event is desired: > > > > Multicast Hello Interval: 0.5 seconds. > > > > Unicast Hello Interval: infinite (no Unicast Hellos are sent). > > > > Link cost, IHU Interval, Update Interval, IHU Hold Time, and Route > > Expiry Time: computed as in the first case above. > > > > Request Timeout: initially 0.5 seconds, doubled every time a > > request is resent, up to a maximum of three times. > > > > Urgent timeout: 0.2 seconds. > > > > Source GC time: 3 minutes.=E2=80=9D > > > > These value are much lower than in the first case and can easily leads > to signification congestion, however, you don=E2=80=99t say anything appr= opriate > about when those value might be used or should be avoided. What appendix = B > does is simply given some sample calculation about what the expected > reconvergence time is based on the selected values but it does not give a= ny > guidance about which network conditions would bear which setup, nor does = it > talk about negative implication of selecting lower values. > > > > I still think that it is important to provide default values as part of > the normative specification. For me finding such default value (maybe wit= h > more discussions about in which network scenarios these vales makes sense > and when it might be useful to consider different values) was part of the > experiment with babel and if you are not able to address these questions, > babel is not ready for PS. > > > > Alternatively you can check the values in RFC8085 again and see if thes= e > are acceptable values for most scenarios. Values in that RFC are lightly > lower than the first example (e.g. 3 secs interval and 1 sec timeout) but > quite a bit larger than the new example you introduced (without further > guidance on usage of the values). > > > > Especially in section 3.8.2.1. regarding the Request Timeout it is not > sufficient to only point to the appendix. Please also note that there are > actually two values here that need suitable default values, the time-out > itself and the number of retries. > > > > Thanks! > > Mirja > > > > > >> On 18. Oct 2019, at 18:46, Juliusz Chroboczek wrote: > >> > >> Dear Mirja, > >> > >>> 1) Let's move appendix B into the body of the document. I think these > >>> are important information for an implementer and therefore it needs > more > >>> attention. > >> > >> I am sorry, but I disagree. The original document that I submitted fo= r > >> IETF review back in 2009 had the structure that you suggest, but the > >> reviewer (Joel Halpern) convinced me to a adopt the following structur= e: > >> > >> - the body of the document describes the main algorithm, the parts tha= t > >> are required to enforce the strong guarantees that the protocol make= s > >> about lack of loops and forward progress; > >> - the appendices describe algorithms that have been shown to be useful > >> over some link layers but that might need to be tweaked when Babel i= s > >> run over new, exciting link layers. > >> > >> Since Joel did a good job convincing me, it will take some work to > >> convince me otherwise. > >> > >>> 2) Maybe you can add something like: [...] I=E2=80=99m sure you have= a better > >>> wording. My intention is simply to add another warning, to think > >>> carefully instead of just pick some default. > >> > >> I don't necessarily agree, but I've done as you request. > >> > >>>>> Thanks. I was also hoping that you could make any recommendation on > how > >>>>> to implement that e.g. a fixed delay of a certain (default) value o= r > >>>>> based on some other knowledge. [...] > >> > >>>> You do realise it's a very high bar you're setting? > >> > >> [...] > >> > >>> I wasn=E2=80=99t looking for a tutorial for pacing but rather a refer= ence to > >>> add. E.g. just naming different approaches for how to implement pacin= g > >>> and provide a reference would be a good thing I think. However, I wil= l > >>> not block on this one thing. Your choice. > >> > >> I am not aware of any good reference on packet pacing that covers IEEE > >> 802.11 multicast (an important usecase for Babel). After checking som= e > >> papers and scratching my head for a long time, I've just added another > >> sentence to Section 3.1; I'm afraid I'm not competent to do anything > more. > >> > >>> I just wondering why you don=E2=80=99t call them default value rather= then > >>> examples. I think specifying default value normatively would be more > >>> clear and is what we usually do in specs. However, I think in this ca= se > >>> it will not make a huge practical difference. > >> > >> Great, let's agree that we're not in full agreement, then. > >> > >> -- Juliusz > >> > >> > >> > > > > --0000000000003664010599635dc5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mirja,

Thank you fo= r taking another look at the document.

I hope we c= an get this resolved quickly, as we have
already waited for 49 da= ys for your last=C2=A0email.
I understand that you are busy but I= did want to point
out that this is adding stress on the authors.=

First, it appears that your review is still treat= ing Babel like
a protocol running over UDP on the Internet. It is= not.
Babel only operates point-to-point using IPv6 link-local
addresses, and the congestion properties of 802.11
are ve= ry different from the ones of an end-to-end
transport running ove= r the wide area.

Second, the Babel working group p= rides itself with strict
adherence to the=C2=A0running code princ= iple. Features or
recommendations do not make it into a Babel spe= c
unless they have been implemented and tested.

If we were discussing a transport protocol, I would
agree= with your review. RFC 8085 is a great
document, but it wasn'= t written with link-local routing
protocols in mind.
As transport AD, it is your responsibility to ensure
new IETF protocols do not bring about another
congestion collaps= e, and I think that's critical.
I want to really thank you fo= r the hours you spend
reviewing documents to ensure that goal. Bu= t I don't
think all of that guidance applies here.
=
Could I kindly ask you to take another look at your
review in this lens, and please let us know in what
way you thi= nk this draft has real-world issues?

We'd real= ly like to make forward progress here, if
the only issue is d= efault values, I'm not sure this is
worth causing delays on, = as we haven't seen these
cause problems when implementing the= protocol.

Thanks,
David

<= /div>

On Thu, Dec 5, 2019 at 3:53 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
Hi again,

And one more comment regarding pacing: Again I will not block on this issue= anymore, however, as you have a babel implementation I would assume it wou= ld be easy to add more details on how pacing is done in your implementation= in the draft (at least in the appendix).

Mirja



> On 5. Dec 2019, at 12:50, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
>
> Hi Juliusz, hi all,
>
> I took another look at the updated RFC and I have to say I=E2=80=99m s= till concerned about the default values (which is also an issue that was al= so raised by Alvaro) and the appendix B.
>
> You know added another case:
>
> "The following values are recommended in a network where reconver= gence
>=C2=A0 =C2=A0within 2 seconds after a mobility event is desired:
>
>=C2=A0 =C2=A0 =C2=A0 Multicast Hello Interval: 0.5 seconds.
>
>=C2=A0 =C2=A0 =C2=A0 Unicast Hello Interval: infinite (no Unicast Hello= s are sent).
>
>=C2=A0 =C2=A0 =C2=A0 Link cost, IHU Interval, Update Interval, IHU Hold= Time, and Route
>=C2=A0 =C2=A0 =C2=A0 Expiry Time: computed as in the first case above.<= br> >
>=C2=A0 =C2=A0 =C2=A0 Request Timeout: initially 0.5 seconds, doubled ev= ery time a
>=C2=A0 =C2=A0 =C2=A0 request is resent, up to a maximum of three times.=
>
>=C2=A0 =C2=A0 =C2=A0 Urgent timeout: 0.2 seconds.
>
>=C2=A0 =C2=A0 =C2=A0 Source GC time: 3 minutes.=E2=80=9D
>
> These value are much lower than in the first case and can easily leads= to signification congestion, however, you don=E2=80=99t say anything appro= priate about when those value might be used or should be avoided. What appe= ndix B does is simply given some sample calculation about what the expected= reconvergence time is based on the selected values but it does not give an= y guidance about which network conditions would bear which setup, nor does = it talk about negative implication of selecting lower values.
>
> I still think that it is important to provide default values as part o= f the normative specification. For me finding such default value (maybe wit= h more discussions about in which network scenarios these vales makes sense= and when it might be useful to consider different values) was part of the = experiment with babel and if you are not able to address these questions, b= abel is not ready for PS.
>
> Alternatively you can check the values in RFC8085 again and see if the= se are acceptable values for most scenarios. Values in that RFC are lightly= lower than the first example (e.g. 3 secs interval and 1 sec timeout) but = quite a bit larger than the new example you introduced (without further gui= dance on usage of the values).
>
> Especially in section 3.8.2.1. regarding the Request Timeout it is not= sufficient to only point to the appendix. Please also note that there are = actually two values here that need suitable default values, the time-out it= self and the number of retries.
>
> Thanks!
> Mirja
>
>
>> On 18. Oct 2019, at 18:46, Juliusz Chroboczek <jch@irif.fr> wrote:
>>
>> Dear Mirja,
>>
>>> 1) Let's move appendix B into the body of the document. I = think these
>>> are important information for an implementer and therefore it = needs more
>>> attention.
>>
>> I am sorry, but I disagree.=C2=A0 The original document that I sub= mitted for
>> IETF review back in 2009 had the structure that you suggest, but t= he
>> reviewer (Joel Halpern) convinced me to a adopt the following stru= cture:
>>
>> - the body of the document describes the main algorithm, the parts= that
>>=C2=A0 =C2=A0are required to enforce the strong guarantees that the= protocol makes
>>=C2=A0 =C2=A0about lack of loops and forward progress;
>> - the appendices describe algorithms that have been shown to be us= eful
>>=C2=A0 =C2=A0over some link layers but that might need to be tweake= d when Babel is
>>=C2=A0 =C2=A0run over new, exciting link layers.
>>
>> Since Joel did a good job convincing me, it will take some work to=
>> convince me otherwise.
>>
>>> 2) Maybe you can add something like: [...]=C2=A0 I=E2=80=99m s= ure you have a better
>>> wording. My intention is simply to add another warning, to thi= nk
>>> carefully instead of just pick some default.
>>
>> I don't necessarily agree, but I've done as you request. >>
>>>>> Thanks. I was also hoping that you could make any reco= mmendation on how
>>>>> to implement that e.g. a fixed delay of a certain (def= ault) value or
>>>>> based on some other knowledge. [...]
>>
>>>> You do realise it's a very high bar you're setting= ?
>>
>> [...]
>>
>>> I wasn=E2=80=99t looking for a tutorial for pacing but rather = a reference to
>>> add. E.g. just naming different approaches for how to implemen= t pacing
>>> and provide a reference would be a good thing I think. However= , I will
>>> not block on this one thing. Your choice.
>>
>> I am not aware of any good reference on packet pacing that covers = IEEE
>> 802.11 multicast (an important usecase for Babel).=C2=A0 After che= cking some
>> papers and scratching my head for a long time, I've just added= another
>> sentence to Section 3.1; I'm afraid I'm not competent to d= o anything more.
>>
>>> I just wondering why you don=E2=80=99t call them default value= rather then
>>> examples. I think specifying default value normatively would b= e more
>>> clear and is what we usually do in specs. However, I think in = this case
>>> it will not make a huge practical difference.
>>
>> Great, let's agree that we're not in full agreement, then.=
>>
>> -- Juliusz
>>
>>
>>
>

--0000000000003664010599635dc5-- From nobody Wed Dec 11 06:55:18 2019 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 5323D120289; Wed, 11 Dec 2019 06:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 mm9LycZk6Uk9; Wed, 11 Dec 2019 06:55:09 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 1CE5C120271; Wed, 11 Dec 2019 06:55:09 -0800 (PST) Received: from [129.192.10.3] (helo=[10.149.1.243]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1if3OM-0008U1-8P; Wed, 11 Dec 2019 15:55:06 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Wed, 11 Dec 2019 15:55:05 +0100 Cc: draft-ietf-babel-rfc6126bis@ietf.org, babel-chairs , Juliusz Chroboczek , Babel at IETF , Alvaro Retana , The IESG , Donald Eastlake , Martin Vigoureux Content-Transfer-Encoding: quoted-printable Message-Id: <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> To: David Schinazi X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1576076109;2e7f330f; X-HE-SMSGID: 1if3OM-0008U1-8P Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 11 Dec 2019 14:55:11 -0000 Hi David, Sorry for the delays (but there was also a large delay by the author in = between).=20 I don=E2=80=99t necessarily want to impose anything that is written in = RFC8085 here, but what I=E2=80=99m saying it that the protocol in order = to go to PS must given recommendations for default values or at a = minimum discuss which values are appropriate in which situation (and = what the consequences are otherwise). Due to the lack of these guidance = I keep pointing at RFC8085 because that=E2=80=99s what the IETF agreed = to be =E2=80=9Csafe=E2=80=9D in the general case. Currently the document proposes some values but it does not discuss in = which scenario these values are appropriate to use (or when they are not = appropriate to use anymore). Given people tend to simply implement = default values, I would prefer to see a set of default values that is = suitable for most scenarios and basically safe to use in all scenarios. = If that is not possible it would also be okay to discuss the boundary of = the values based on certain network conditions but usually that is more = complicated.=20 As you say, you have an implementation-driven approach. That is great = and what we usually try to do in the IETF. For PS it is however usually = expected that you have a running implementation as well as also some = extend of operational experience (I guess that it what the experimental = phase was for). If you have that experience it should be possible to = e.g. to describe the network scenario that you used babel in and give = the values that have been used in that scenario. What are those = scenarios? Mirja > On 11. Dec 2019, at 02:15, David Schinazi = wrote: >=20 > Hi Mirja, >=20 > Thank you for taking another look at the document. >=20 > I hope we can get this resolved quickly, as we have > already waited for 49 days for your last email. > I understand that you are busy but I did want to point > out that this is adding stress on the authors. >=20 > First, it appears that your review is still treating Babel like > a protocol running over UDP on the Internet. It is not. > Babel only operates point-to-point using IPv6 link-local > addresses, and the congestion properties of 802.11 > are very different from the ones of an end-to-end > transport running over the wide area. >=20 > Second, the Babel working group prides itself with strict > adherence to the running code principle. Features or > recommendations do not make it into a Babel spec > unless they have been implemented and tested. >=20 > If we were discussing a transport protocol, I would > agree with your review. RFC 8085 is a great > document, but it wasn't written with link-local routing > protocols in mind. >=20 > As transport AD, it is your responsibility to ensure > new IETF protocols do not bring about another > congestion collapse, and I think that's critical. > I want to really thank you for the hours you spend > reviewing documents to ensure that goal. But I don't > think all of that guidance applies here. >=20 > Could I kindly ask you to take another look at your > review in this lens, and please let us know in what > way you think this draft has real-world issues? >=20 > We'd really like to make forward progress here, if > the only issue is default values, I'm not sure this is > worth causing delays on, as we haven't seen these > cause problems when implementing the protocol. >=20 > Thanks, > David >=20 >=20 > On Thu, Dec 5, 2019 at 3:53 AM Mirja Kuehlewind = wrote: > Hi again, >=20 > And one more comment regarding pacing: Again I will not block on this = issue anymore, however, as you have a babel implementation I would = assume it would be easy to add more details on how pacing is done in = your implementation in the draft (at least in the appendix). >=20 > Mirja >=20 >=20 >=20 > > On 5. Dec 2019, at 12:50, Mirja Kuehlewind = wrote: > >=20 > > Hi Juliusz, hi all, > >=20 > > I took another look at the updated RFC and I have to say I=E2=80=99m = still concerned about the default values (which is also an issue that = was also raised by Alvaro) and the appendix B. > >=20 > > You know added another case: > >=20 > > "The following values are recommended in a network where = reconvergence > > within 2 seconds after a mobility event is desired: > >=20 > > Multicast Hello Interval: 0.5 seconds. > >=20 > > Unicast Hello Interval: infinite (no Unicast Hellos are sent). > >=20 > > Link cost, IHU Interval, Update Interval, IHU Hold Time, and = Route > > Expiry Time: computed as in the first case above. > >=20 > > Request Timeout: initially 0.5 seconds, doubled every time a > > request is resent, up to a maximum of three times. > >=20 > > Urgent timeout: 0.2 seconds. > >=20 > > Source GC time: 3 minutes.=E2=80=9D > >=20 > > These value are much lower than in the first case and can easily = leads to signification congestion, however, you don=E2=80=99t say = anything appropriate about when those value might be used or should be = avoided. What appendix B does is simply given some sample calculation = about what the expected reconvergence time is based on the selected = values but it does not give any guidance about which network conditions = would bear which setup, nor does it talk about negative implication of = selecting lower values. > >=20 > > I still think that it is important to provide default values as part = of the normative specification. For me finding such default value (maybe = with more discussions about in which network scenarios these vales makes = sense and when it might be useful to consider different values) was part = of the experiment with babel and if you are not able to address these = questions, babel is not ready for PS.=20 > >=20 > > Alternatively you can check the values in RFC8085 again and see if = these are acceptable values for most scenarios. Values in that RFC are = lightly lower than the first example (e.g. 3 secs interval and 1 sec = timeout) but quite a bit larger than the new example you introduced = (without further guidance on usage of the values). > >=20 > > Especially in section 3.8.2.1. regarding the Request Timeout it is = not sufficient to only point to the appendix. Please also note that = there are actually two values here that need suitable default values, = the time-out itself and the number of retries. > >=20 > > Thanks! > > Mirja > >=20 > >=20 > >> On 18. Oct 2019, at 18:46, Juliusz Chroboczek wrote: > >>=20 > >> Dear Mirja, > >>=20 > >>> 1) Let's move appendix B into the body of the document. I think = these > >>> are important information for an implementer and therefore it = needs more > >>> attention. > >>=20 > >> I am sorry, but I disagree. The original document that I submitted = for > >> IETF review back in 2009 had the structure that you suggest, but = the > >> reviewer (Joel Halpern) convinced me to a adopt the following = structure: > >>=20 > >> - the body of the document describes the main algorithm, the parts = that > >> are required to enforce the strong guarantees that the protocol = makes > >> about lack of loops and forward progress; > >> - the appendices describe algorithms that have been shown to be = useful > >> over some link layers but that might need to be tweaked when = Babel is > >> run over new, exciting link layers. > >>=20 > >> Since Joel did a good job convincing me, it will take some work to > >> convince me otherwise. > >>=20 > >>> 2) Maybe you can add something like: [...] I=E2=80=99m sure you = have a better > >>> wording. My intention is simply to add another warning, to think > >>> carefully instead of just pick some default. > >>=20 > >> I don't necessarily agree, but I've done as you request. > >>=20 > >>>>> Thanks. I was also hoping that you could make any recommendation = on how > >>>>> to implement that e.g. a fixed delay of a certain (default) = value or > >>>>> based on some other knowledge. [...] > >>=20 > >>>> You do realise it's a very high bar you're setting? > >>=20 > >> [...] > >>=20 > >>> I wasn=E2=80=99t looking for a tutorial for pacing but rather a = reference to > >>> add. E.g. just naming different approaches for how to implement = pacing > >>> and provide a reference would be a good thing I think. However, I = will > >>> not block on this one thing. Your choice. > >>=20 > >> I am not aware of any good reference on packet pacing that covers = IEEE > >> 802.11 multicast (an important usecase for Babel). After checking = some > >> papers and scratching my head for a long time, I've just added = another > >> sentence to Section 3.1; I'm afraid I'm not competent to do = anything more. > >>=20 > >>> I just wondering why you don=E2=80=99t call them default value = rather then > >>> examples. I think specifying default value normatively would be = more > >>> clear and is what we usually do in specs. However, I think in this = case > >>> it will not make a huge practical difference. > >>=20 > >> Great, let's agree that we're not in full agreement, then. > >>=20 > >> -- Juliusz > >>=20 > >>=20 > >>=20 > >=20 >=20 From nobody Tue Dec 17 08:43:49 2019 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 EEBAC12007C; Tue, 17 Dec 2019 08:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 VT0uZwusp043; Tue, 17 Dec 2019 08:43:44 -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 635531201DB; Tue, 17 Dec 2019 08:43:44 -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/82085) with ESMTP id xBHGhdvN010166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 Dec 2019 17:43: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/82085) with ESMTP id xBHGhcbM013679; Tue, 17 Dec 2019 17:43:38 +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 1366CA8376; Tue, 17 Dec 2019 17:43:42 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id eaD7ymQ6Uz9R; Tue, 17 Dec 2019 17:43:40 +0100 (CET) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 89638A8374; Tue, 17 Dec 2019 17:43:39 +0100 (CET) Date: Tue, 17 Dec 2019 17:43:39 +0100 Message-ID: <87lfra9a2s.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mirja Kuehlewind Cc: David Schinazi , draft-ietf-babel-rfc6126bis@ietf.org, babel-chairs , Babel at IETF , Alvaro Retana , The IESG , Donald Eastlake , Martin Vigoureux In-Reply-To: <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 17 Dec 2019 17:43: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, 17 Dec 2019 17:43:38 +0100 (CET) X-Miltered: at korolev with ID 5DF905BB.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5DF905BA.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5DF905BB.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5DF905BA.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 : 5DF905BB.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5DF905BA.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: Re: [babel] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 17 Dec 2019 16:43:47 -0000 Dear Mirja, > I keep pointing at RFC8085 because that’s what the IETF agreed to be > “safe” in the general case. I refer you to my mail of 9 August 2019, where I reply to almost exactly the same statement. RFC 8085 discusses what is considered recommended for protocols that run over the Internet. To witness: Internet paths can have widely varying characteristics, including transmission delays, available bandwidths, congestion levels, reordering probabilities, supported message sizes, or loss rates. Furthermore, the same Internet path can have very different conditions over time. In Babel, like in OSPF, there is no "Internet path" involved -- there is just an association between two direct neighbours (from the point of view of layer 3). It is therefore my opinion -- already stated in my mail of August 9 --, that obeying the recommendations in RFC 8085 is not required for Babel to become PS. In the same mail of 9 August 2019, I make the claim that there is no mechanism related to RFC 8085 in RFC 5340. In other words, it would appear that you are holding Babel to a much higher standard than OSPFv. If that is the case, then I request that you state explicitly why you think that Babel must be held to a much higher standard than OSPFv3. If that is not the case, then please clear your discuss. > Currently the document proposes some values but it does not discuss in > which scenario these values are appropriate to use (or when they are not > appropriate to use anymore). Appendix B gives values that are suggested for implementations. > If you have that experience it should be possible to e.g. to describe > the network scenario that you used babel in and give the values that > have been used in that scenario. What are those scenarios? The first set of parameters in Appendix B gives the values that are used by recent versions of babeld (the reference implementation of Babel) and that have been used in production for many years in a wide range of networks, including wifi meshes, wired networks, and large community networks consisting of a complex mixture of wireless and wired links. These scenarios are described in the Applicability statement. -- Juliusz From nobody Tue Dec 17 09:13:52 2019 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 C5D4C120B2E; Tue, 17 Dec 2019 09:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 dvYa2IqIljRk; Tue, 17 Dec 2019 09:13:48 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 9537F120220; Tue, 17 Dec 2019 09:13:48 -0800 (PST) Received: from host109-105-dynamic.8-87-r.retail.telecomitalia.it ([87.8.105.109] helo=[192.168.1.11]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ihGPp-0001a9-Es; Tue, 17 Dec 2019 18:13:45 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <87lfra9a2s.wl-jch@irif.fr> Date: Tue, 17 Dec 2019 18:13:43 +0100 Cc: David Schinazi , draft-ietf-babel-rfc6126bis@ietf.org, babel-chairs , Babel at IETF , Alvaro Retana , The IESG , Donald Eastlake , Martin Vigoureux Content-Transfer-Encoding: quoted-printable Message-Id: <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net> References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> <87lfra9a2s.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1576602828;9b4770b8; X-HE-SMSGID: 1ihGPp-0001a9-Es Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 17 Dec 2019 17:13:51 -0000 Hi Juliusz, Please see below. > On 17. Dec 2019, at 17:43, Juliusz Chroboczek wrote: >=20 > Dear Mirja, >=20 >> I keep pointing at RFC8085 because that=E2=80=99s what the IETF = agreed to be >> =E2=80=9Csafe=E2=80=9D in the general case. You are citing this sentence out of context. I didn=E2=80=99t say that = you have to stick to these values but (if you don=E2=80=99t want to do = that) you have to provide reasonable values in the spec and discuss when = it is safe to use low values. >=20 > I refer you to my mail of 9 August 2019, where I reply to almost = exactly > the same statement. RFC 8085 discusses what is considered recommended = for > protocols that run over the Internet. To witness: >=20 > Internet paths can have widely varying characteristics, including > transmission delays, available bandwidths, congestion levels, > reordering probabilities, supported message sizes, or loss rates. > Furthermore, the same Internet path can have very different > conditions over time. >=20 > In Babel, like in OSPF, there is no "Internet path" involved -- there = is > just an association between two direct neighbours (from the point of = view > of layer 3). It is therefore my opinion -- already stated in my mail = of > August 9 --, that obeying the recommendations in RFC 8085 is not = required > for Babel to become PS. Yes it=E2=80=99s not an Internet path but you still want to design a = protocol that is safe to deploy, as you say, in various scenarios and = therefore you should build some safety measures to not overload the = network. >=20 > In the same mail of 9 August 2019, I make the claim that there is no > mechanism related to RFC 8085 in RFC 5340. In other words, it would > appear that you are holding Babel to a much higher standard than = OSPFv. >=20 > If that is the case, then I request that you state explicitly why you > think that Babel must be held to a much higher standard than OSPFv3. = If > that is not the case, then please clear your discuss. In OSPFv3 as far as I can see (and I am really not an expert here) all = values that define intervals are in seconds which leads to a minimum = value of 1 seconds. This is not the case for babel and therefore we need = to be more carful here. >=20 >> Currently the document proposes some values but it does not discuss = in >> which scenario these values are appropriate to use (or when they are = not >> appropriate to use anymore). >=20 > Appendix B gives values that are suggested for implementations. Yes but it doesn=E2=80=99t discuss for with _deployment_ scenarios these = values are suitable. >=20 >> If you have that experience it should be possible to e.g. to describe >> the network scenario that you used babel in and give the values that >> have been used in that scenario. What are those scenarios? >=20 > The first set of parameters in Appendix B gives the values that are = used > by recent versions of babeld (the reference implementation of Babel) = and > that have been used in production for many years in a wide range of > networks, including wifi meshes, wired networks, and large community > networks consisting of a complex mixture of wireless and wired links. > These scenarios are described in the Applicability statement. First it would be helpful to then provide a pointer to that document. I = assume you means draft-ietf-babel-applicability right? Then it would be = nice to be more concrete. Did you deploy the same parameters in all of = the discussed scenarios. Does it actually makes sense to use the same = parameters in a "small unmanaged network" as well as in a "large overlay = network"? And what does e.g. a small unmanaged network means? How many = devices do you usually have in such a network to call it =E2=80=9Csmall=E2= =80=9D? Is that network connected to the Internet or not? >=20 > -- Juliusz >=20 From nobody Tue Dec 17 11:04:54 2019 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 49E1E120C9F; Tue, 17 Dec 2019 11:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 mDJ6pRPbr0ks; Tue, 17 Dec 2019 11:04:49 -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 93CFB1208C8; Tue, 17 Dec 2019 11:04:05 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id xBHJ40I0001286; Tue, 17 Dec 2019 20:04:00 +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 686B1A90AA; Tue, 17 Dec 2019 20:04:03 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 9iw4YMXPKvrS; Tue, 17 Dec 2019 20:04:01 +0100 (CET) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id DAF5BA90A6; Tue, 17 Dec 2019 20:04:00 +0100 (CET) Date: Tue, 17 Dec 2019 20:04:00 +0100 Message-ID: <87r212n59b.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mirja Kuehlewind Cc: David Schinazi , draft-ietf-babel-rfc6126bis@ietf.org, babel-chairs , Babel at IETF , Alvaro Retana , The IESG , Donald Eastlake , Martin Vigoureux In-Reply-To: <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net> References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> <87lfra9a2s.wl-jch@irif.fr> <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 17 Dec 2019 20:04:00 +0100 (CET) X-Miltered: at korolev with ID 5DF926A0.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5DF926A0.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 : 5DF926A0.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 17 Dec 2019 19:04:52 -0000 >> If that is the case, then I request that you state explicitly why you >> think that Babel must be held to a much higher standard than OSPFv3. If >> that is not the case, then please clear your discuss. > In OSPFv3 as far as I can see (and I am really not an expert here) all > values that define intervals are in seconds which leads to a minimum > value of 1 seconds. This is not the case for babel and therefore we need > to be more carful here. After a change of topology, OSPF executes the procedure described in Section 4.5.2 of RFC 5340 (Section 13.3 of RFC 2328). At this point, a potentially unbounded number of LSAs are flooded out every active interface (point 5 in Section 13.3 of RFC 2328). This flooding is not regulated by any timer -- all that the protocol says is that the LSAs must go out through a certain subset of the router's interfaces. I could be wrong, but I am fairly confident that nothing in RFCs 5340 and 2328 specifies congestion control, flow control or packet pacing for this flooding procedure. My interpretation is that since OSPF is designed to be deployed on local links, congestion caused by OSPF is not likely to endanger the Global Internet, and therefore packet pacing (if required) is left to the implementation. I also don't recall any discussion of flow control in Moy's and Gredler's books, but they have a lot of pages (especially Gredler's), so, again, I could be wrong. Where you are right, Mirja, is that packet pacing is a very difficult problem in OSPF, where incorrectly delaying flooding could lead to microloops; since Babel has a loop-avoidance mechanism built-in, it can safely perform packet pacing should the need to do so be demonstrated in a particular topology. In summary, while I agree that packet pacing for Babel would be an interesting research project, I maintain that by requiring packet pacing as a condition for publication as PS, you are requiring an unreasonably high standard, certainly a standard that neither OSPF nor IS-IS are held to. >> Appendix B gives values that are suggested for implementations. > Yes but it doesn’t discuss for with _deployment_ scenarios these values > are suitable. As far as I am aware, all current production deployments use the first set of constants. The one exception is an experimental testbed used for mobility research, that uses the (more aggressive) second set of constants. > Did you deploy the same parameters in all of the discussed scenarios. Yes. > Does it actually makes sense to use the same parameters in a "small > unmanaged network" as well as in a "large overlay network"? Yes. > Is that network connected to the Internet or not? Yes, but that's irrelevant -- the Babel traffic is link-local, and does not go outside the local routing domain. -- Juliusz From nobody Mon Dec 23 15:42:45 2019 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 57E1F120D15 for ; Mon, 23 Dec 2019 15:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 WjUTwA7CdZc6 for ; Mon, 23 Dec 2019 15:42: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 A98B312003E for ; Mon, 23 Dec 2019 15:42:41 -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/82085) with ESMTP id xBNNgZsg013272; Tue, 24 Dec 2019 00:42:35 +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 A545C101DD3; Tue, 24 Dec 2019 00:42: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 RKDtGtz2nLc9; Tue, 24 Dec 2019 00:42:37 +0100 (CET) Received: from pirx.irif.fr (176-153-23-26.abo.bbox.fr [176.153.23.26]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3BEBA101DD1; Tue, 24 Dec 2019 00:42:37 +0100 (CET) Date: Tue, 24 Dec 2019 00:42:36 +0100 Message-ID: <87y2v2vcb7.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org CC: David Schinazi User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 24 Dec 2019 00:42:35 +0100 (CET) X-Miltered: at korolev with ID 5E0150EB.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5E0150EB.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 : 5E0150EB.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] 6126bis: implementing Babel-MAC is RECOMMENDED X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 23 Dec 2019 23:42:44 -0000 Dear all, I've just committed some tweaks to 6126bis to the Git repository. There's a bunch of wording tweaks that aim at clarifying the security language, but there's also one single-sentence paragraph with normative language: Every implementation of Babel SHOULD implement BABEL-MAC. This was not discussed by the WG, and hence I do not know to what extent this change fits WG consensus. I'd be pleased if people who disagree with this change could let me know now rather than later. -- Juliusz From nobody Mon Dec 23 15:50:49 2019 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 5358C120044 for ; Mon, 23 Dec 2019 15:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 hl5NldzupX27 for ; Mon, 23 Dec 2019 15:50:47 -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 CDBD012002F for ; Mon, 23 Dec 2019 15:50:46 -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/82085) with ESMTP id xBNNofrc014089; Tue, 24 Dec 2019 00:50: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 EE95B101DF5; Tue, 24 Dec 2019 00:50:44 +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 r-1HLyHmMv_o; Tue, 24 Dec 2019 00:50:43 +0100 (CET) Received: from pirx.irif.fr (176-153-23-26.abo.bbox.fr [176.153.23.26]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id AB886101DF3; Tue, 24 Dec 2019 00:50:43 +0100 (CET) Date: Tue, 24 Dec 2019 00:50:42 +0100 Message-ID: <87d0cewqi5.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org Cc: David Schinazi In-Reply-To: <87y2v2vcb7.wl-jch@irif.fr> References: <87y2v2vcb7.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]); Tue, 24 Dec 2019 00:50:41 +0100 (CET) X-Miltered: at korolev with ID 5E0152D1.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5E0152D1.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 : 5E0152D1.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: Re: [babel] 6126bis: implementing Babel-MAC is RECOMMENDED X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 23 Dec 2019 23:50:48 -0000 > Every implementation of Babel SHOULD implement BABEL-MAC. I'm realising that this may seem somewhat cryptic to those of you who haven't been following the ongoing discussion with the IESG. Babel-MAC is already the RECOMMENDED cryptographic protection mechanism. However, there's no normative language that recommends implementing Babel-MAC. This merely adds a recommendation for implementers, as opposed to network administrators (who are already encouraged to deploy Babel-MAC). -- Juliusz From nobody Tue Dec 24 07:59:14 2019 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 D1E9C12011E for ; Tue, 24 Dec 2019 07:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 SysOOQuMtgzH for ; Tue, 24 Dec 2019 07:59:11 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 54C37120118 for ; Tue, 24 Dec 2019 07:59:11 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id c16so18038224ioh.6 for ; Tue, 24 Dec 2019 07:59:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fy0jqUE6HB8YztTfi8deDNigHi1vuFBYnUl+GwvPUvs=; b=Sf/cU+JrhmX5ltR3FFp3m2PJ/VG2UyKslv/K6s1L8uKSAFPYw9Sa7RNqANKiUapC34 834fvvjbWrXOBRv3AFAIhe99r/EPJFlac2fowakeQft1vJTXcKMvQhujHd+G/RM+Ivpn 3OxKYH8YeDoXirwGbp3tDNVSf9iINDeib473vgnGW+aRp3N3FqRAh21DVfSe0ldhVTDr Wwxj4tY2T+28UhSVI5uRFwsvXUB2svBJx4awtKB6iSLYf5PWooU6qTmpTZOuOHfY317m 09AtxoWZDzqmyeSozo+SAEwl31Q6812btx6yHtBhUdZCQgwQ+CoCSaGeMBRyOwTLwefw kTPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Fy0jqUE6HB8YztTfi8deDNigHi1vuFBYnUl+GwvPUvs=; b=r3b6F9H6BFH0IPSqkFcyWz+Swfyh2hyNne+lm/xlTUpfUDtnI/TxBN4fGcxREECJxg 8I7LEkYwpa+kdqEw7+q9ttdvYG9cmS9jrP1+rhAe7zTNN5XLZjusSly+dJBnF5GY62VS wm3lqTol4inkC7o+/ECewqqB1gTqvBSWp3K8x4DCBIdFYX6sIRF5D6qvL/5DgLpMBIWx hCSWvKTHko3QQzQAtnLVxgrVpiN4mu/IPWhSeZicXqJWR9HjCcYRtiQTx95r8G9DCUxv ZwOhr5hBti/bACFxdpKpVJRcRHE8xI7P8cjbFuJsv1t7xzBcWVoXjdSrPB7tMWG627GJ i7rQ== X-Gm-Message-State: APjAAAWmvpY68d+tzh4GxHm1KrrDf5UydjwiQEbGNWXspV2ae94oz0Yu XkJO+h3o6ugaayIoztbQjkk6H9FPg5aiwTE8WGQ= X-Google-Smtp-Source: APXvYqwr3nu62i1/xN7CN3IBTEDCbVnvvwJEBUcbTAefXm9FjGUULiyHuyF6GGUjj74g4yPDgvqAYL+Ab4kC4pTWwoU= X-Received: by 2002:a6b:b941:: with SMTP id j62mr25526506iof.168.1577203150606; Tue, 24 Dec 2019 07:59:10 -0800 (PST) MIME-Version: 1.0 References: <87y2v2vcb7.wl-jch@irif.fr> <87d0cewqi5.wl-jch@irif.fr> In-Reply-To: <87d0cewqi5.wl-jch@irif.fr> From: Donald Eastlake Date: Tue, 24 Dec 2019 10:58:59 -0500 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF , David Schinazi Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] 6126bis: implementing Babel-MAC is RECOMMENDED X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 24 Dec 2019 15:59:13 -0000 Hi Juliusz, Season's Greetings! Speaking just as a member of the WG, I think this is a reasonable minor change. As you point out, use of Babel-MAC was recommended when it provided the security features needed so it seems reasonable to RECOMMEND its implementation. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Mon, Dec 23, 2019 at 6:50 PM Juliusz Chroboczek wrote: > > > Every implementation of Babel SHOULD implement BABEL-MAC. > > I'm realising that this may seem somewhat cryptic to those of you who > haven't been following the ongoing discussion with the IESG. > > Babel-MAC is already the RECOMMENDED cryptographic protection mechanism. > However, there's no normative language that recommends implementing > Babel-MAC. This merely adds a recommendation for implementers, as opposed > to network administrators (who are already encouraged to deploy Babel-MAC). > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Fri Dec 27 06:52:18 2019 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 676B5120072 for ; Fri, 27 Dec 2019 06:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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 kL5POavMIE-R for ; Fri, 27 Dec 2019 06:52:14 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 3D37012006E for ; Fri, 27 Dec 2019 06:52:14 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id xBREjQqt020995; Fri, 27 Dec 2019 09:52:12 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2x4vfrng29-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Dec 2019 09:52:12 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id xBREqBXv026489; Fri, 27 Dec 2019 09:52:11 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id xBREq3Zc026251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Dec 2019 09:52:03 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 14A534009E94; Fri, 27 Dec 2019 14:52:03 +0000 (GMT) Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30485.vci.att.com (Service) with ESMTPS id 006694009E90; Fri, 27 Dec 2019 14:52:03 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.43]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0468.000; Fri, 27 Dec 2019 09:52:02 -0500 From: "STARK, BARBARA H" To: "'Donald Eastlake'" , "'Juliusz Chroboczek'" CC: "'David Schinazi'" , "'Babel at IETF'" Thread-Topic: [babel] 6126bis: implementing Babel-MAC is RECOMMENDED Thread-Index: AQHVueqzmJtN1LzzWEK70WFKkK5tmqfIt44AgAEOiYCABFBNAA== Date: Fri, 27 Dec 2019 14:52:02 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6115371C253@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <87y2v2vcb7.wl-jch@irif.fr> <87d0cewqi5.wl-jch@irif.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.112.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-27_04:2019-12-24,2019-12-27 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 suspectscore=0 adultscore=0 clxscore=1015 lowpriorityscore=0 mlxlogscore=692 phishscore=0 impostorscore=0 spamscore=0 mlxscore=0 priorityscore=1501 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912270126 Archived-At: Subject: Re: [babel] 6126bis: implementing Babel-MAC is RECOMMENDED X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 14:52:16 -0000 I agree -- with the change and with what Donald said. Barbara > -----Original Message----- > From: babel On Behalf Of Donald Eastlake > Sent: Tuesday, December 24, 2019 10:59 AM > To: Juliusz Chroboczek > Cc: David Schinazi ; Babel at IETF > > Subject: Re: [babel] 6126bis: implementing Babel-MAC is RECOMMENDED >=20 > Hi Juliusz, >=20 > Season's Greetings! >=20 > Speaking just as a member of the WG, I think this is a reasonable minor > change. As you point out, use of Babel-MAC was recommended when it > provided the security features needed so it seems reasonable to > RECOMMEND its implementation. >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com >=20 > On Mon, Dec 23, 2019 at 6:50 PM Juliusz Chroboczek wrote: > > > > > Every implementation of Babel SHOULD implement BABEL-MAC. > > > > I'm realising that this may seem somewhat cryptic to those of you who > > haven't been following the ongoing discussion with the IESG. > > > > Babel-MAC is already the RECOMMENDED cryptographic protection > mechanism. > > However, there's no normative language that recommends implementing > > Babel-MAC. This merely adds a recommendation for implementers, as > > opposed to network administrators (who are already encouraged to deploy > Babel-MAC). > > > > -- Juliusz > > > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mail > > man_listinfo_babel&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8T > > > q4vrfog&m=3D05TfINwjdsEszrnTHiGaQNngGrBDbZT7y9yuUYORZMc&s=3DSk7JQ1 > TnSy-u9I > > aRMHDq-pShPTZ5e1Gz8QD9I0u-Pgc&e=3D >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_babel&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3D05TfINwjdsEszrnTHiGaQNngGrBDbZT7y9yuUYORZMc&s > =3DSk7JQ1TnSy-u9IaRMHDq-pShPTZ5e1Gz8QD9I0u-Pgc&e=3D From nobody Fri Dec 27 09:17:25 2019 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 3251F12012D for ; Fri, 27 Dec 2019 09:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 jndZgCAUHPpk for ; Fri, 27 Dec 2019 09:17:22 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (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 504E1120091 for ; Fri, 27 Dec 2019 09:17:22 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1577467039; bh=eAMskvkNjaAjuFKMAKi75HXVqtd+9SwXbLO9jvI/HOk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=t4oNaFcj1cv9Yn7WO+5AOVvaZDZIYiFBtg+KP23Gzw0WQWXqQ7eJAq8HNTizBaFdF wFwlKm05w4N3PXY1vSa3t3MuIaWdNFQm89dEwTtRhfqwb0Njxdj0Bmjcj2NfCUfZ2X KbnwKDYCNz6rXn+LtPOLDmSNRZnS6I3AXl8Me+36ie0yICnsLDeZSqENogzHDCoYGy mihSa1X7SpZc5M7doRI0qlNeC89ZSE29amQr9PPRUNx89Cvm7vuIfVmOuurN2vTET0 A4scEY40bl6LhsXAGtlSLCMGbtu4Oshx0skl3JEVo5g4gbFDlOh+KJWe8zPPbtXRjp Jy3c7oiLbDd6Q== To: "STARK\, BARBARA H" , 'Donald Eastlake' , 'Juliusz Chroboczek' Cc: 'David Schinazi' , 'Babel at IETF' In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6115371C253@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <87y2v2vcb7.wl-jch@irif.fr> <87d0cewqi5.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6115371C253@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Fri, 27 Dec 2019 18:17:18 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87d0c9zo0x.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] 6126bis: implementing Babel-MAC is RECOMMENDED X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 17:17:24 -0000 "STARK, BARBARA H" writes: > I agree -- with the change and with what Donald said. +1 -Toke From nobody Fri Dec 27 09:25:18 2019 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 657BE120991 for ; Fri, 27 Dec 2019 09:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.234 X-Spam-Level: X-Spam-Status: No, score=0.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_SINGLE_WORD=2.233, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 6qyvWVOc9ywK for ; Fri, 27 Dec 2019 09:25:15 -0800 (PST) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 540BD12098D for ; Fri, 27 Dec 2019 09:25:15 -0800 (PST) Received: by mail-il1-x12c.google.com with SMTP id z12so22877910iln.11 for ; Fri, 27 Dec 2019 09:25:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yubnqvOxH5wghrCpYkYGbKsY6Wx8HEC3NSs/FNvj738=; b=N4UEVCGEqSPLccuENJGrRJ9EBclm3vZPRA/YmPro3vH0wQAM98kstT6GP/ApROEr1q x+r8lA1VBmemysuQJPyZBM5xTY5YICHyNXJwdERXFTAwkFfJLS8g3FzO3PQQaB/fR6M9 SUITEns+NkWrNM8x9d5trjOA8CqYbqmM+aTLMMCPLNEYcAMSzCeagaUen3x3h+Ck1yvf jm1EpQb7WCO0AzPSZ909RjnoKr19HGq58VK8JtVl9O8dCjya6LHGhIh7FHf6XqZaOpN6 3LGST2b+6kyDaNvVNeycmKinOc7IADKMtmsfJwVhaMfh/xJxvLWxcUp+U4kcUmDpciTE 2VcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yubnqvOxH5wghrCpYkYGbKsY6Wx8HEC3NSs/FNvj738=; b=mrrAjvOkO1zql1t6RmDaSm7dAbUeuoWPNUDI5/2ShPPUW8noGiGSWZDseqNHQahmoP PMsg0rUksBow/0RfhlIZBJcDi9HGFW6M08Fv8hDG6J0Oem9QTZvat8wZo/e6hE6hMv4s XzQGjIxMGJGgpJi/eX101zsl9OFt2FvI6arsDQitprofgeWC4aupJpTErD8N5rKfPjwP xBlzlQg6u/7o3iXehRfav3U6oFI6CrcAQeiy6qnRt2gAXe/5+YawNIc0vbPqyanx6Nz0 WGQeBQ23Nss+i5UvkQqzIhtrYgeqiaAud9l0DM8djax+MXkwlRn0IYuAtEAxh5tPulxf y9og== X-Gm-Message-State: APjAAAVzwd8DwrvNRfWKAz3DXGWKaMvK92zGWcsBW1H0sryTQZ3j11/X obE8bTuTxEdirUOF8aKVaINfWpEaL8Bo11RMC+M= X-Google-Smtp-Source: APXvYqypDF9SJ5sfxMU8+JERjwi3EItVV79UDXdu1301zD3stjMnuSF/cEbmYbVaQ/Q6tVCPuB0kbFXFNXOybkGthHM= X-Received: by 2002:a05:6e02:5c8:: with SMTP id l8mr46730209ils.287.1577467514603; Fri, 27 Dec 2019 09:25:14 -0800 (PST) MIME-Version: 1.0 References: <87y2v2vcb7.wl-jch@irif.fr> <87d0cewqi5.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6115371C253@GAALPA1MSGUSRBF.ITServices.sbc.com> <87d0c9zo0x.fsf@toke.dk> In-Reply-To: <87d0c9zo0x.fsf@toke.dk> From: Dave Taht Date: Fri, 27 Dec 2019 09:25:03 -0800 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: "STARK, BARBARA H" , Donald Eastlake , Juliusz Chroboczek , David Schinazi , Babel at IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] 6126bis: implementing Babel-MAC is RECOMMENDED X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 17:25:16 -0000 +1 From nobody Fri Dec 27 11:46:31 2019 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 A763D1200E5 for ; Fri, 27 Dec 2019 11:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Da2HzBwKGGxC for ; Fri, 27 Dec 2019 11:46:27 -0800 (PST) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 E3C7712006F for ; Fri, 27 Dec 2019 11:46:26 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id w21so29679785otj.7 for ; Fri, 27 Dec 2019 11:46:26 -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 :content-transfer-encoding; bh=dJMq9DbrS1oj7+RGOt6hDj4mjWUpdFzT6DiQpAUgw7o=; b=Idd5k3hMBQjvof7NWt+chvIaeh8oj6Kozt+tmTNRlXdflzxltV+XQbocTCDmjiDQ0L hJu63Cc0D3LiLjwldHLJAQ5Imt4+G5lZfvmaHhJL10f6O7usvfEkJV+ZPNlhIRdaD/FU 8v6yKRffzUw0XuTtByFn4AkzfN+NKc5G5+EPo2N0sHQOHR+yONH+j42nDx99ARI1Otfs +glSp7xxRQk8yndl9HSqKZZQuqdciRaHy1TDPNjXfSzpDepo5xgSZ+Jg/OebiuFnsK1Z wJ/yfk1mNa8q9oR7naDGAK3X3Hyvj29zYearH8LjX3SpSguJhxxegEptBPXqb0wZ7U+B XCpw== 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 :content-transfer-encoding; bh=dJMq9DbrS1oj7+RGOt6hDj4mjWUpdFzT6DiQpAUgw7o=; b=j8NmuZWOhYyRG75QAYckuvsAG31eqigBwWzK14rxYGDi0xIhIpkINTNnCQVosxqP9A 4ZhHYjNR25uDPcsAAzNj7lqNijTqNbnrl3HhdLMJT2GvvqUPkSBaQygv3szwTcbqGdEx e2WBApsF+NBPXn3Y0a5N40S5JczH8zIIzHHwUY7U6sB237nlyiaqvmCk55Q18avuO1hY xJKJhSON508O5Iw0eFS7sMy3R3tB0EH8yLpUj8Zl1iuwk/m97iLypMJHkXGBcsOxrhDe e/4d7vtzCHLBiDmrPfCjYvIFndNLJ6OaMRHZkAF12Yu0Hnv/H8ofJmyreVl7x8ahl45w l6dg== X-Gm-Message-State: APjAAAVXXr6qDxyL1FpsCBF60J7nBq7fBw81+Z+Xl0i9PNJ065Y9svAv ZDyF50S/Qe1lq1QK85aK8Zdj/xnQJZ9uIxZ7v01UgFTJ X-Google-Smtp-Source: APXvYqw7aBbYLs2sT5OJgwLr58cTlEUG7BDWO4P5+2Yrxjrfl4Adr+HQAmi4f8UDsw0/COnTH6oA9ljzRgvJC7K1RKo= X-Received: by 2002:a05:6830:1f89:: with SMTP id v9mr55709553otr.90.1577475985971; Fri, 27 Dec 2019 11:46:25 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?Q?Antonin_D=C3=A9cimo?= Date: Fri, 27 Dec 2019 20:46:31 +0100 Message-ID: To: Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [babel] Babel-MAC: key size and digest size X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 19:46:30 -0000 Dear all, After working a bit on the MAC authentication for Babel implementation in babeld, I think that the draft need clarification on two points: 1. Key size The draft reads: =C2=A77 > Ideally, they should have a length of 32 octets (both for > HMAC-SHA256 and Blake2s) Other RFCs state: - https://tools.ietf.org/html/rfc2104#section-3 > However, less than L [hashing function block size] bytes is > strongly discouraged as it would decrease the security strength of > the function. - https://tools.ietf.org/html/rfc4868#section-2.1.2 SHA256 has a block size of 64 octets (see RFC6234, search SHA256_Message_Block_Size). Blake2s key length is 0 <=3D kk <=3D 32 (see https://tools.ietf.org/html/rfc7693#section-2.1) HMAC algorithms deal with shorter keys by padding them with zeroes up to some size, and with longer keys by hashing them first. I suggest we rephrase the draft to state that key length should ideally be the maximum key length advertised by the hashing algorithm, which for Blake2s is explicitly 32 octets, or no less than the block size of the hashing algorithm which is 64 octets for SHA256. 2. Digest size The length of the digest (=3D the MAC) produced by Blake2s may be configured. Blake2s: 1 <=3D nn <=3D 32 For instance, the API of the reference implementation let the programmer ask for specific digest length (outlen parameter). // Initialize the hashing context "ctx" with optional key "key". // 1 <=3D outlen <=3D 32 gives the digest size in bytes. // Secret key (also <=3D 32 bytes) is optional (keylen =3D 0). int blake2s_init(blake2s_ctx *ctx, size_t outlen, const void *key, size_t keylen); The MAC TLV =C2=A76.1 is composed by the length L of the digest, followed by the digest D. On reception of a packet, D must be validated. A logical thing to do is to compute a digest of length L with Blake2s. The draft does not explicitly state that the checking code must use L for the digest length, and not say, the maximum digest length. We may conservatively assume that if two digests D1 and D2 of length L1 < L2 are computed from the same message, D1 won't necessarily be a prefix of D2. Now, suppose that we allow digests of various length for the same hashing algorithm. What happens when we receive a MAC TLV of length 0? Or what if an attacker captures a packet, tampers with it, removes all MAC TLVs, and adds 256 MAC TLVs of length 1 with all 256 possible digest values? A least one MAC would be accepted, and the overhead is only 3*256=3D768 octets. If I am not mistaken this breaks the first assumption of the protocol =C2=A71.2: > that the Message Authentication Code (MAC) being used is > invulnerable to pre-image attacks, i.e., that an attacker is unable > to generate a packet with a correct MAC without access to the secret > key; Short digest lengths should not be allowed; a fix could be that the draft explicitly states that only digests of the maximum (or a predefined) length for each hashing algorithm should be send and checked on reception. Cheers! -- Antonin From nobody Sat Dec 28 10:15:50 2019 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 36FB912013C for ; Sat, 28 Dec 2019 10:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 0m0CWnGJ_NLC for ; Sat, 28 Dec 2019 10:15:46 -0800 (PST) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 B191912016E for ; Sat, 28 Dec 2019 10:15:46 -0800 (PST) Received: by mail-ot1-x32c.google.com with SMTP id p8so4222764oth.10 for ; Sat, 28 Dec 2019 10:15:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=rKujk2YgnNvsrs5TKqt9nrxYo4z5/mPaW/QC+TZU/8A=; b=M09gqIX7/traArcY+ZKeREqMYEi53lF1dWkBmJEqJOgaEWn+QIRTPJxcECEkKfqrbp TMqPDpw///EEU8T8PRWjcA+zJuPTPywdoaQA3kEfpMq6qub1f8jT/C28uWNVRivOjxtb HAnhQl6Lt92cgsryK0Ahb6s0rHVPWGYSDe5sUm2uRQBayyojHTtHw7kXpwP5vV4ykH7d gb4hytxEK3/MdOEIIabNGKeLRQW41kDgpcL63mcIeUlVmle+7rkGJvB8uUrcrvhuXxea DDLOFqyMC3DOuwnkhQSVSdmMqwRuN5gELAe0re2rh46YPWgEEKkDoiP6+FkauSkkBxf4 Hzxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=rKujk2YgnNvsrs5TKqt9nrxYo4z5/mPaW/QC+TZU/8A=; b=V/hvaLFk2pdhliuX4H52UG693Yk4/oqg4cglSeN9ioIEo2aUqKGK3CcraKNKdimPxT 5aajygWO6qw13yigyCjydzeFjxMWUqmZHjBSC6wQKYL/f4fz7qr0s5h2A2t9R2/scMpF 9e/ncR2xCsyzAnxoDtzFFINUdlA50hbXKqTtn5viBPxG21Oqfgr2K9LU24VwBCOBlK1r 7ugg8nEY94RN10IXXj4lTeoJjzwPK13tR4FFK91k9zdRQQsg1iG+GioZ+rCzhAtmsCGF FxrhtCBk44Q/WQiGju0yIBFpxX08NH+2XLjsJYcWLj0SpyaqIpXi2Tqv1RMOgytHEQID 9scQ== X-Gm-Message-State: APjAAAXzZyaWcAKHLCHkG5mDJXZqZa2f3IQCJVYNNY0ETz5syuCyVc/Y 023xMx71KsxstOyzVGzp93sTdO+IjffNiSAKDV+8ZIP9 X-Google-Smtp-Source: APXvYqy3OaDRkQWRDuM9BIPSMWQkCIy8Qa6Urb6NNI/LKr2uWer+OLHktEGB8ee2uL/6e/XUatwH6IxOygXhyN56UE4= X-Received: by 2002:a05:6830:1f89:: with SMTP id v9mr60809426otr.90.1577556945890; Sat, 28 Dec 2019 10:15:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Antonin_D=C3=A9cimo?= Date: Sat, 28 Dec 2019 19:15:54 +0100 Message-ID: To: Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Babel-MAC: key size and digest size X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 28 Dec 2019 18:15:48 -0000 Hello again, I'm keeping in mind that (=C2=A77): > Every implementation MUST implement HMAC-SHA256 as defined in > [RFC6234] and Section 2 of [RFC2104] , SHOULD implement keyed > BLAKE2s [RFC7693] , and MAY implement other MAC algorithms. 1. Key length This is the change I'm proposing in =C2=A77: Keys must be chosen in a manner that makes them difficult to guess. -Ideally, they should have a length of 32 octets (both for HMAC-SHA256 -and Blake2s), and be chosen randomly. +Ideally, they should be chosen randomly, and have the maximum key +length supported by the MAC algorithm (32 octets for keyed BLAKE2S) +or no less than the block size of the MAC algorithm (64 octets for +HMAC-SHA256). 2. Digest length After a bit of sleep, I realised that reading the length of the MAC TLV in order to compute a MAC of this length is not compliant with the protocol (=C2=A74.3) since MACs are computed without looking into the packet. > Then, for each key configured on the receiving interface, the > receiver computes the MAC of the packet. It then compares every > generated MAC against every MAC included in the packet; Still, it was an error I was almost going to make. I propose the following change to ensure that we're always using the maximum digest length of the MAC algorithm. This is the change I'm proposing in =C2=A74.1: implementation MUST implement HMAC-SHA256 as defined in and Section 2 of , SHOULD implement keyed BLAKE2s , and MAY impleme= nt other MAC algorithms. +The length of the MAC MUST be the maximum MAC length computable by +the MAC algorithm (32 octets for both HMAC-SHA256 and keyed +BLAKE2S). 3. Lazy computation With the idea that computing a MAC is more costly than comparing MACs, and that there's a very limited amount of MACs to check, I propose we lazily compute MACs. Instead of computing the MAC for every key on packet reception, we compute the MAC with the first key, then check it against the MACs carried by the packet. If there's a match, the packet is immediately accepted. If there's no match, we the proceed to the next key until all keys are exhausted, and the packet is rejected. This is the change I'm proposing in =C2=A74.3: -Then, for each key configured on the receiving interface, the -receiver computes the MAC of the packet. It then compares every -generated MAC against every MAC included in the packet; if there is -at least one match, the packet passes the MAC test; if there is none, -the packet MUST be silently dropped and processing stops at this -point. +Then, for each key configured on the receiving interface, the +receiver computes the MAC of the packet and compares it against every +MAC included in the packet; if there is at least one match, the +packet passes the MAC test; if there is none, the receiver proceeds +with the next key. If none of the MAC matched, the packet MUST be +silently dropped and processing stops at this point. Cheers! -- Antonin From nobody Mon Dec 30 14:10:59 2019 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 0E4311200A4; Mon, 30 Dec 2019 14:10:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <157774385196.4608.15839542177049046909@ietfa.amsl.com> Date: Mon, 30 Dec 2019 14:10:52 -0800 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-rfc6126bis-16.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 30 Dec 2019 22:10:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : The Babel Routing Protocol Authors : Juliusz Chroboczek David Schinazi Filename : draft-ietf-babel-rfc6126bis-16.txt Pages : 69 Date : 2019-12-30 Abstract: Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol, and obsoletes RFCs 6126 and 7557. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-16 https://datatracker.ietf.org/doc/html/draft-ietf-babel-rfc6126bis-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-rfc6126bis-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 30 21:03:52 2019 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 825DA1200C3; Mon, 30 Dec 2019 21:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 GWnBalJAbleC; Mon, 30 Dec 2019 21:03:49 -0800 (PST) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 2995A12002E; Mon, 30 Dec 2019 21:03:49 -0800 (PST) Received: by mail-il1-x135.google.com with SMTP id t8so29453606iln.4; Mon, 30 Dec 2019 21:03:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CeOofYEmovx0I8mu/+WbrZHfJFwMFZxlJxjl/4cMioQ=; b=fsxgVDdtreOXsPBOTRuK9TJM1W9Vb04WbqEMP14tZLaC5KVoYkY2QpoCxPknulYtRa fbJm08KjwFRipjds7bD4z27liyXCOgzjOD+4sssqptQHr4z2VrLQn6CU2x1p0byhVciJ 2o5myaHnGg1Ptws1/0vhxgRSl2GLb/5mL5dBME5o8oZPGQsREUHaDmjAN76FUjXfNrUk MzjjTkh9V5yPnwfBlL1lJNpa717ptc4yEXZQAg/qDVMi9jY2X9yrrkavxp9ctw2IEMkr hmEeyVjSjId83bclF8gefrcztK4+sOTO45laIxithz8FEZ9TmAcO3T/BYJZNTUD5azNz xTQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CeOofYEmovx0I8mu/+WbrZHfJFwMFZxlJxjl/4cMioQ=; b=ogEB05kheO2gTR/VWALzf5bXPRAsC5JgkxRDAbci3ZmyNA7lebNnWym3WHau5cLjpt wivBZ4b6tIOXfn5ETD0E22mSHG45UoVjgpVPj8pMTn2kO9dtrgr9ZA/BoH79pxRmxkhm HjRsJFk6ZcyaNrcLC+07YXNYzKO9VBM46LSmxmliDpoappRlc23S0L3nm1v1G5xGyAtR Gq2lMxXXydOi17pi0gxaV4nHXVbLunb6kpRNiI8RXYeFrNpE6alfvz0xFIm1MNDPhpAx 0LVvzjszsoIVNFfAH3ePMdUF1Iedp1aQ4UEDNnudpC93QAKaR/FSLlO/MMFimeA0AQak EUbQ== X-Gm-Message-State: APjAAAXqR72DO/DxloZefK26cz4qHfZ0C74Clj6As7MbrgCkpu7S0Xww bd3kD5c4CWJ/JgUlCrKNtAZrVwK3Bfrmv2K/wDIH4913 X-Google-Smtp-Source: APXvYqxl6izdmoutJWc5563q8QBrsUWSyZZBcfoIKbPXqU0uSIJUTSfuaXmP2CyCbZG9BhYH+lf6MEqPQYQNP7CTnyA= X-Received: by 2002:a92:8712:: with SMTP id m18mr56373813ild.40.1577768627742; Mon, 30 Dec 2019 21:03:47 -0800 (PST) MIME-Version: 1.0 References: <157774385196.4608.15839542177049046909@ietfa.amsl.com> In-Reply-To: <157774385196.4608.15839542177049046909@ietfa.amsl.com> From: Donald Eastlake Date: Tue, 31 Dec 2019 00:03:36 -0500 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-rfc6126bis-16.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 05:03:51 -0000 Looking at the diffs with -15, all the changes look good to me. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Mon, Dec 30, 2019 at 5:11 PM wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Babel routing protocol WG of the IETF. > > Title : The Babel Routing Protocol > Authors : Juliusz Chroboczek > David Schinazi > Filename : draft-ietf-babel-rfc6126bis-16.txt > Pages : 69 > Date : 2019-12-30 > > Abstract: > Babel is a loop-avoiding distance-vector routing protocol that is > robust and efficient both in ordinary wired networks and in wireless > mesh networks. This document describes the Babel routing protocol, > and obsoletes RFCs 6126 and 7557. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-16 > https://datatracker.ietf.org/doc/html/draft-ietf-babel-rfc6126bis-16 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-rfc6126bis-16 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel