From nobody Wed Jul 1 17:20:03 2020 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 48DB23A1271; Wed, 1 Jul 2020 17:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 baXJpSekPKPX; Wed, 1 Jul 2020 17:19:59 -0700 (PDT) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 B4E643A1270; Wed, 1 Jul 2020 17:19:58 -0700 (PDT) Received: by mail-vk1-xa2a.google.com with SMTP id d64so5917113vke.4; Wed, 01 Jul 2020 17:19:58 -0700 (PDT) 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=4Aj07n9EgcefUcah08AXrASlXUMb2Vrjwx2nQoZTfRI=; b=IRRcnhWj+alO5SC2owBrugnXxQh/tQ+nU4wmlMjnGUN9UrZnjScOr303IbCPZpolvF S2B+x3KDc7KIcWIEfGAJVqelxweqaiVOT9VvWCTCMn5IA2z0M5joWfv9gxL9dfZX9ER1 IypkB3BP/EYz9mLnZuSYuDQgqYPdVZp4TCdQ9jJP4NG/aK5b8rdzlf9ekyL3i/tup/9+ 2tYAoLneJJrBI7wY+qGoFxYmyqAYNb2jE50SFTIG60p5gz0AUJLTCr4mcTYbQQLJWabI p+f6F+Mm49577jgWXHMBRLTInYt3T2SVHmSPxHQlsEglUC0V2YFnFUvCBYJ8f4hVsf2b C8zA== 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=4Aj07n9EgcefUcah08AXrASlXUMb2Vrjwx2nQoZTfRI=; b=i8e8hulMHy3Nk7nWp0/vgmr/JZ6yi8KjaA5IwQkXQEzbmSCENtFv+ietot60XibH5c Cz6lqYofvt94qnphSOaAh4bEHqAKMkNgHKSemS99+tIRH+x0ChHKpqoJ8p+EBaOeD7sg 9v+7krF/1qEcIbGzWnnHaJ0LvxrzPfRI51/4ZDiMbLNbGS2Pb0CMCM2Tp8DO3tE0ELPY adxRWNBQhoAjtGxYCmRwVwnwvubrtuQbe1bpPBnb2787w8/sIdd0gJI+dxrr67rhGgbl x4V593xafCVzL87Qn5h9QRwNlmHGiyvT2fMtsASulwOffHUwu7/5DCz5J/JYNU+J3b92 NuuA== X-Gm-Message-State: AOAM533BnIVsDOvR0ZJ9tPpe/zGN7IInh2cmSMPL259qKwQqWJu1zJwf NggaY/EvRK6H4KP0xOp+gcMT+K6v11nMsiVa1IM= X-Google-Smtp-Source: ABdhPJzhaukg27C2i5Cy782S/DuA4i8W7Lt0if03qH0Fu+VfCTCzdl/c1+t5Zlvo5MjmOP6KUdOJOlRhILBv/icD4cQ= X-Received: by 2002:ac5:c76e:: with SMTP id c14mr21408077vkn.60.1593649197550; Wed, 01 Jul 2020 17:19:57 -0700 (PDT) MIME-Version: 1.0 References: <159329532285.23961.12116288483331623753@ietfa.amsl.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 1 Jul 2020 17:19:45 -0700 Message-ID: To: David Schinazi Cc: The IESG , draft-ietf-babel-dtls@ietf.org, babel-chairs , Babel at IETF , Donald Eastlake Content-Type: multipart/alternative; boundary="000000000000511cee05a96a5e35" Archived-At: Subject: Re: [babel] Murray Kucherawy's No Objection on draft-ietf-babel-dtls-09: (with COMMENT) 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, 02 Jul 2020 00:20:00 -0000 --000000000000511cee05a96a5e35 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 30, 2020 at 4:01 PM David Schinazi wrote: > > > >> * "Nodes SHOULD drop packets that have been reordered ..." -- Why would an >> implementer not do this? (i.e., why is it only a SHOULD?) >> > > Tracking reordering like this is not a feature that is available in all > DTLS stacks. > Requiring Babel implementors to add features to DTLS stacks is not a > realistic > possibility, so we made this a SHOULD. > I would suggest mentioning this. SHOULD leaves some interoperability discretion to the reader, and I think it helps to provide guidance around that discretion especially when you have a specific alternative in mind. >> >> Section 2.5: >> >> * Why is the stuff in the first paragraph only SHOULD/RECOMMENDED? (The >> answer >> may lie in the second paragraph, but I'm uncertain.) >> > > Because it's not required for the correctness or security of the protocol. > For example, > we do not need to mandate where implementors save their DTLS state. > Given the words of Section 6 of RFC 2119, I suggest you don't need to use these key words here if that's the reason. -MSK --000000000000511cee05a96a5e35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 30, 2020 at 4:01 PM David Sch= inazi <dschinazi.ietf@gmail.= com> wrote:

=C2=A0
* "Nodes SHOULD drop packets that have been reordered ..." -- Why= would an
implementer not do this?=C2=A0 (i.e., why is it only a SHOULD?)

Tracking reordering like this is not a feature tha= t is available in all DTLS stacks.
Requiring Babel implementors t= o add features to DTLS stacks is not a realistic
possibility, so = we made this a SHOULD.

I = would suggest mentioning this.=C2=A0 SHOULD leaves some interoperability di= scretion to the reader, and I think it helps to provide guidance around tha= t discretion especially when you have a specific alternative in mind.

=C2=A0
Section 2.5:

* Why is the stuff in the first paragraph only SHOULD/RECOMMENDED?=C2=A0 (T= he answer
may lie in the second paragraph, but I'm uncertain.)

Because it's not required for the correctness or secu= rity of the protocol. For example,
we do not need to mandate wher= e=C2=A0implementors=C2=A0save their DTLS state.

Given the words of Section 6 of RFC 2119, I sug= gest you don't need to use these key words here if that's the reaso= n.

-MSK
--000000000000511cee05a96a5e35-- From nobody Thu Jul 2 09:50:21 2020 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 9909E3A0AA7; Thu, 2 Jul 2020 09:50:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-babel-rfc6126bis@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <159370860960.14219.14404876065329344086@ietfa.amsl.com> Date: Thu, 02 Jul 2020 09:50:09 -0700 Archived-At: Subject: [babel] Murray Kucherawy's No Objection on draft-ietf-babel-rfc6126bis-17: (with COMMENT) 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: Thu, 02 Jul 2020 16:50:10 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-babel-rfc6126bis-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- My review is focusing mainly on the diff with RFC6126 for expediency. The technical material seems fine to me, so I just have some editorial nits to offer: Section 1.2: * "The ability to build such heterogeneous networks makes Babel particularly adapted to the unmanaged and wireless environment." -- The ending feels awkward. Maybe "to unmanaged, wireless environments"? Or maybe "or" in between? Section 3: * "... assigns host IDs, see the definition ..." -- comma splice; "see" should begin a new sentence, or the comma should be a semi-colon Section 3.1: * "... in a previous TLV, (such as in ..." -- remove the comma Section 3.2.1: * "Given a seqno s and a non-negative integer n, the sum ..." -- It feels to me as if things like "s" and "n" should be quoted when in prose. I don't know what the RFC Editor prefers, but I keep thinking this as I read through the whole document; I hit it again in 3.5.2, for example. Section 4.6.5: * "neighbor" is spelled the American way here, but the British way everywhere else. Come to think of it, I think the RFC Editor standardizes on the former (see RFC 7322) if you're not internally consistent. So, if you like your "u"s, don't give them this ammunition to change them. Section 5: * I suggest replacing with "IANA has {registered, created} ..." with "IANA previously {registered, created} ..." to make it clear that the prior RFCs did that work, and that they're simply being restated here and/or that this document is assuming authority over them. * The new registries feel like they're under-specified to me. It's not clear, for example, whether I could register bit 16 in the "Babel Hello Flags Values" registry. Maybe add a sentence making it explicit that registrations can only be made from the "Unassigned" range? Admittedly, this could be experience bias on my part as I typically work with registries that cover unconstrained namespaces, so I'm leaving this only as a comment. Appendix G: * Although it's possibly obvious and perhaps unnecessary, I suggest making it explicit that this appendix is not intended to be published and can be removed by the editor. From nobody Thu Jul 2 17:21:25 2020 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 083EA3A092F; Thu, 2 Jul 2020 17:20:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: martin.vigoureux@nokia.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159373563102.30173.15287224541353565745@ietfa.amsl.com> Date: Thu, 02 Jul 2020 17:20:31 -0700 Archived-At: Subject: [babel] babel - Requested session has been scheduled for IETF 108 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: Fri, 03 Jul 2020 00:20:36 -0000 Dear Donald Eastlake, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. babel Session 1 (0:50 requested) Monday, 27 July 2020, Session II 1300-1350 Room Name: Room 6 size: 6 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/108/sessions/babel.ics Request Information: --------------------------------------------------------- Working Group Name: Babel routing protocol Area Name: Routing Area Session Requester: Donald Eastlake Number of Sessions: 1 Length of Session(s): 50 Minutes Number of Attendees: 21 Conflicts to Avoid: Chair Conflict: bess idr rtgwg nvo3 Technology Overlap: homenet manet rtgarea lpwan Key Participant Conflict: netconf netmod People who must be present: Donald E. Eastlake 3rd Russ White Martin Vigoureux Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Jul 5 09:41:39 2020 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 CDA623A00C0; Sun, 5 Jul 2020 09:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Vkv0ulWmnF9H; Sun, 5 Jul 2020 09:41:22 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 51E2D3A00B2; Sun, 5 Jul 2020 09:41:22 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id t27so26033232ill.9; Sun, 05 Jul 2020 09:41:22 -0700 (PDT) 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=xAn+4wZCTduWmqGv0KTvp1fnkK2mrVB017oROniQHPQ=; b=AmJEtS3zuDitSaUhb0aukA7kHCFSqA4kfDth2CXB0C8Xek0H8OkjR1rWLXqqa4fFHF 3P4GuOc+MGbAoXjw4zGd51U/9UqBeZbL+qP14UNnPnEzAUi/L52K8BGNJjXc4nt2ujCc n4+yY6wA+VTJZFfxd7K8LYfoyTm3W8l6jyPzJR0icXneonFG4fFDWfvcsaKiUEDfC3x0 mIOI/VFaqhOnwOk3p5zTFXe+ll/zbhFb3q/qj2jar0F0Z7BUOq9FhJ6z55sqMz3fCsoe qqRGaEwynndFPbvBb+HC75DcOdPqYwQN7vHZZB0T9Aqv4YQFP+Y7/Rd1zuurfhEqoCKv hd2w== 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=xAn+4wZCTduWmqGv0KTvp1fnkK2mrVB017oROniQHPQ=; b=ViTnFJM/q8dadSqv0BdX2eLLrxfhmTIdg9FuVWy0ZxEZkcAVZF4Pbl72HxT9Ry3OEs /cuO+hF9f2NqKaCBieJHwBNmf91oDHtzVKCRMwWBVEHi8hkL/MP0p/d/s88keksFa1zW eIZhi+k95qatRtm/Zq/ZX/Vkj/MdwfrSVycpa9gEdZR7iXA4isSkZSsOkfrutkCwETsZ gO8htv+8mQ/oFLg/8j0wcxMZEsnfsV4J76QwRU/jmuFRn8OkxukFNMJCcT/nliP/xMkC j6Rbh0Mr/n/YBcLKdyIbSNM/AWN6YUiGqJJwj9FqxREVG244vlwexuxL1AVy5BSJRJDE MTQg== X-Gm-Message-State: AOAM532+9DPRZB9mnZgBLa7HOOjdcg/DgocChQiMWQU8B4vYVKBqTeH3 KinT6AFUPfyv+R5kkpnOs98s5iIRWPhohmkmTPE= X-Google-Smtp-Source: ABdhPJzBCzuUK2eekEQx5OwZlzYtUOUJEjKbeDOkRGuAjL98zQ2GfFV5xmanh4DurwcFzGt0LUFTg/d54BDstMORL8E= X-Received: by 2002:a92:58d1:: with SMTP id z78mr26198405ilf.276.1593967281447; Sun, 05 Jul 2020 09:41:21 -0700 (PDT) MIME-Version: 1.0 References: <159370860960.14219.14404876065329344086@ietfa.amsl.com> In-Reply-To: <159370860960.14219.14404876065329344086@ietfa.amsl.com> From: Donald Eastlake Date: Sun, 5 Jul 2020 12:41:10 -0400 Message-ID: To: Murray Kucherawy Cc: The IESG , draft-ietf-babel-rfc6126bis@ietf.org, babel-chairs , Babel at IETF Content-Type: multipart/alternative; boundary="0000000000009829c905a9b46dd7" Archived-At: Subject: Re: [babel] Murray Kucherawy's No Objection on draft-ietf-babel-rfc6126bis-17: (with COMMENT) 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: Sun, 05 Jul 2020 16:41:25 -0000 --0000000000009829c905a9b46dd7 Content-Type: text/plain; charset="UTF-8" Hi Murray, Thanks for your comments. See below. My apologies for the delay in response. I am replying as the document shephard. On Thu, Jul 2, 2020 at 12:50 PM Murray Kucherawy via Datatracker < noreply@ietf.org> wrote: > Murray Kucherawy has entered the following ballot position for > draft-ietf-babel-rfc6126bis-17: No Objection > > ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > My review is focusing mainly on the diff with RFC6126 for expediency. The > technical material seems fine to me, so I just have some editorial nits to > offer: > > Section 1.2: > > * "The ability to build such heterogeneous networks makes Babel particularly > adapted to the unmanaged and wireless environment." -- The ending feels > awkward. Maybe "to unmanaged, wireless environments"? Or maybe "or" in > between? I think changing "and" to "or" is reasonable. You don't need a network that is both unmanaged and wireless for Babel to be well adapted. > Section 3: > > * "... assigns host IDs, see the definition ..." -- comma splice; "see" should > begin a new sentence, or the comma should be a semi-colon I like semicolons; I think they are used too rarely. > Section 3.1: > > * "... in a previous TLV, (such as in ..." -- remove the comma Removing the comma seems reasonable. > Section 3.2.1: > > * "Given a seqno s and a non-negative integer n, the sum ..." -- It feels to me > as if things like "s" and "n" should be quoted when in prose. I don't know > what the RFC Editor prefers, but I keep thinking this as I read through the > whole document; I hit it again in 3.5.2, for example. I understand your feeling but this would be a pretty massive change that no one else has previously requested. Readers do not seem to have difficulty understanding the document as it is in this regard. Perhaps we should wait to see if the RFC Editor says anything. > Section 4.6.5: > > * "neighbor" is spelled the American way here, but the British way everywhere > else. Come to think of it, I think the RFC Editor standardizes on the former > (see RFC 7322) if you're not internally consistent. So, if you like your "u"s, > don't give them this ammunition to change them. They should all be consistent. > Section 5: > > * I suggest replacing with "IANA has {registered, created} ..." with "IANA > previously {registered, created} ..." to make it clear that the prior RFCs did > that work, and that they're simply being restated here and/or that this > document is assuming authority over them. Sorry, I don't actually see how what you suggest above changes anything. > * The new registries feel like they're under-specified to me. It's not clear, > for example, whether I could register bit 16 in the "Babel Hello Flags Values" > registry. Maybe add a sentence making it explicit that registrations can only > be made from the "Unassigned" range? Admittedly, this could be experience > bias on my part as I typically work with registries that cover unconstrained > namespaces, so I'm leaving this only as a comment. The range of bits available is determined by the field size so I don't think any additional text is needed here. > Appendix G: > > * Although it's possibly obvious and perhaps unnecessary, I suggest making it > explicit that this appendix is not intended to be published and can be removed > by the editor. Sure, I think a line right after the Appendix section line saying RFC Editor: Please delete this section before publication. would do it. Thanks again for the comment, Donald [document shephard] =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com --0000000000009829c905a9b46dd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Murray,

Thanks for your comments. See below.=C2= =A0

My apologies for the delay in response. I am replyin= g as the document shephard.

On Thu, Jul 2, 2020 at 12:50 PM Murray K= ucherawy via Datatracker <noreply@ie= tf.org> wrote:
> Murray Kucherawy has entered the following ba= llot position for
> draft-ietf-babel-rfc6126bis-17: No Objection
&= gt;
> ...
> ---------------------------------------------------= -------------------
> COMMENT:
> ------------------------------= ----------------------------------------
>
> My review is focus= ing mainly on the diff with RFC6126 for expediency.=C2=A0 The
> techn= ical material seems fine to me, so I just have some editorial nits to
&g= t; offer:
>
> Section 1.2:
>
> * "The ability = to build such heterogeneous networks makes Babel particularly
> adapt= ed to the unmanaged and wireless environment." -- The ending feels
= > awkward.=C2=A0 Maybe "to unmanaged, wireless environments"?= =C2=A0 Or maybe "or" in
> between?

I think changing = "and" to "or" is reasonable. You don't need a netwo= rk that is both unmanaged and wireless for Babel to be well adapted.
> Section 3:
>
> * "... assigns host IDs, see the def= inition ..." -- comma splice; "see" should
> begin a n= ew sentence, or the comma should be a semi-colon

I like semicolons; = I think they are used too=C2=A0rarely.

> Section 3.1:
&= gt;
> * "... in a previous TLV, (such as in ..." -- remove = the comma

Removing the comma=C2=A0seems reasonable.

&g= t; Section 3.2.1:
>
> * "Given a seqno s and a non-negativ= e integer n, the sum ..." -- It feels to me
> as if things like = "s" and "n" should be quoted when in prose.=C2=A0 I don= 't know
> what the RFC Editor prefers, but I keep thinking this a= s I read through the
> whole document; I hit it again in 3.5.2, for e= xample.

I understand your feeling but this would be a pretty massive= change that no one else has previously requested. Readers do not seem to h= ave difficulty understanding the document as it is in this regard. Perhaps = we should wait to see if the RFC Editor says anything.

> Section = 4.6.5:
>
> * "neighbor" is spelled the American way h= ere, but the British way everywhere
> else.=C2=A0 Come to think of it= , I think the RFC Editor standardizes on the former
> (see RFC 7322) = if you're not internally consistent.=C2=A0 So, if you like your "u= "s,
> don't give them this ammunition to change them.
They should all be consistent.

> Section 5:
>
&g= t; * I suggest replacing with "IANA has {registered, created} ..."= ; with "IANA
> previously {registered, created} ..." to mak= e it clear that the prior RFCs did
> that work, and that they're = simply being restated here and/or that this
> document is assuming au= thority over them.

Sorry, I don't actually see how what you=C2= =A0suggest above changes anything.

> * The new registries = feel like they're under-specified to me.=C2=A0 It's not clear,
&= gt; for example, whether I could register bit 16 in the "Babel Hello F= lags Values"
> registry.=C2=A0 Maybe add a sentence making it ex= plicit that registrations can only
> be made from the "Unassigne= d" range? =C2=A0 Admittedly, this could be experience
> bias on = my part as I typically work with registries that cover unconstrained
>= ; namespaces, so I'm leaving this only as a comment.

The range o= f bits available is determined by the field size so I don't think any a= dditional text is needed here.

> Appendix G:
>
&g= t; * Although it's possibly obvious and perhaps unnecessary, I suggest = making it
> explicit that this appendix is not intended to be publish= ed and can be removed
> by the editor.

Sure,= I think a line right after the Appendix section line saying

=
= RFC Editor: Please delete this section before publication.

would do it.

Thanks again for the comment,
= Donald [document shephard]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlak= e 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A02386 Panoramic Circle, Apopka,= FL 32703 USA
=C2=A0d3e3e3@gmail.com=
--0000000000009829c905a9b46dd7-- From nobody Mon Jul 6 12:56:31 2020 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 E27683A09F4; Mon, 6 Jul 2020 12:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 I-8Eqgf7vSoV; Mon, 6 Jul 2020 12:56:29 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 9E9AE3A09F0; Mon, 6 Jul 2020 12:56:29 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id a6so17255713ilq.13; Mon, 06 Jul 2020 12:56:29 -0700 (PDT) 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=0MXS3JnE3d4wRLd70qpxcE/5MacTvGnS7g6/n8udgew=; b=tGzlkRIAxeGJ8IynZ3BwR7Q54bowQEbgHWfox59QTaRaR8VO1wlkmlj72jNbM8XZ1/ 7WLbLg/kOaFC++l8WWrh2VKIfE37So9vEYb2iofFn4ONA78z8tRuODPU4kOjSQ1WB0+p hQxB6CLiqOVfpQmtgGAL5hHhasHUFZfbJgw/n3Uo+BptQ2DEBXvvia4cJoU2FCUBzvS9 vFwZrakT5WGltdj+X+KOW9lsAdWPPzKi4wDwC5/MmMTqpOy9Sa5Ui9bldSoUqTuG0e3D X7IjmPHX2oKda9BTev3SMxYpAtIQQAcD1Luo300wPiTXd7Zkohv+bEO69WsrFJTVYgIu DThg== 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=0MXS3JnE3d4wRLd70qpxcE/5MacTvGnS7g6/n8udgew=; b=O1ygsWJC2wdYsFpq/Lu4A3jSn2Cq/Ev8xmn2SQ49ZViQPpW56zifKqU9QmFIRFxBbT LL/6bnPk4Xy3SDe8d2nl2/9hHFy66gvDyXDDnSj8b7h9y5jMBogU048b+R3r+/cUigz8 oFVF0jc/oojjoIWT7OpIOLDC1BgaNyROniRv0C6KWtBs4j5KGK5ureWqutummEJfRYh+ Nj4lTIXN2+lngWTZK1OGhY0wM1N/M9Vu4RkunHBjofMXoVKdKlRQ8FT8weeWKez+ao5n +qVFH2O/dl7M/bLhtRZQoqgV7MDwMjtYIeupRhiXwxgCJQ9fa8fZJfxbi1SIOi8CrOnZ 6P0A== X-Gm-Message-State: AOAM5315bMG5d8yO34Zi6hbMVvC4E5xlF5Uil9CPSec7RRBvF3ghFHM+ aQ9CzMTQP4Mb4gXddl6m0d3SW+YQwgrXdLIVkRqSQERM X-Google-Smtp-Source: ABdhPJzQW6ohq0dqwx2bumICpF83liXBuit7HI+cYy4gbX9oVg1Ai5vWjYFCGztco/mfnVQIdqG4tDvgqW0iAT+SaUo= X-Received: by 2002:a92:c213:: with SMTP id j19mr32268580ilo.40.1594065388316; Mon, 06 Jul 2020 12:56:28 -0700 (PDT) MIME-Version: 1.0 References: <159373563102.30173.15287224541353565745@ietfa.amsl.com> In-Reply-To: <159373563102.30173.15287224541353565745@ietfa.amsl.com> From: Donald Eastlake Date: Mon, 6 Jul 2020 15:56:17 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [babel] Call for Babel meeting presentations 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, 06 Jul 2020 19:56:31 -0000 Hi, If you would like to present at the upcoming Babel WG meeting (see below) and have not already done so, please send a request to the chairs or post to this list. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Thu, Jul 2, 2020 at 8:20 PM "IETF Secretariat" wrote: > > Dear Donald Eastlake, > > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request. > > > babel Session 1 (0:50 requested) > Monday, 27 July 2020, Session II 1300-1350 > Room Name: Room 6 size: 6 > --------------------------------------------- > > > iCalendar: https://datatracker.ietf.org/meeting/108/sessions/babel.ics > From nobody Mon Jul 6 19:09:47 2020 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 642993A08CB for ; Mon, 6 Jul 2020 19:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 TbhEaOjNugiu for ; Mon, 6 Jul 2020 19:09:44 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 73C093A08CA for ; Mon, 6 Jul 2020 19:09:44 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id x9so2430587plr.2 for ; Mon, 06 Jul 2020 19:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=6IUmb2t8n/P7pkxAzbvaOw25KHs4YnmCgdFeTlR4cK0=; b=VsBU57bdg4lqCYoJpEv6xWJx/8gX6aIvcHolRtPBA7qj8TUoUOiJMyV+Y5gHUm7FV4 8ZMbnxsj/MZyrOUEXW19xJh82ucF5t22a8zm4kgQH3ovKmjSo3b4aK2qIRpc12kRJuFr Tg/Ehnvl1nipI34FMWdempQz4xJSNGlqr07PRA7+kXVEm6HsciM7j0qFyC1K+yNXrXqY 3Qnxh+Dw4r+TKNHO+doJRbwjw0XJJLM5jN5uaUKum14r3/5epQ2D3T6JQDQ8EwRr4u67 ltakeolMy5Y9C73GDKyE+MBlp9G5JeTvTyRoyIc+yIx185i3SpXX5ZJVY/sj7utnJCVZ U8uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=6IUmb2t8n/P7pkxAzbvaOw25KHs4YnmCgdFeTlR4cK0=; b=qDXtlY/nssLmZZXVDcjOy6ZNY8AGCpBOaSlfRXQnJ5Rvpy7B9Q6kUVVotumQSAHxHB 2UPJVmhxEI6HT2eb9VmoQ5aevXpoXOvrbQFCE2BikLPQ7l4plhrtNzdtIbH7VF0H1XWd xc0O5HqjH9JaU2ExIrLWr6GeVAmbr60Co5y3mD+6tFCFTRxxr13HA0zSwoCWWPi+bnmV WaMJVY2kbCQoISEEu9OLKyurIxdUbDUQ0gOUNs8w4s9h43gHGCNAe7NfWXtoQ7qrP+np 7bEoERJU3AN30AXLYOA7U6Nd/c7JM0UA5k0OIp5t0v/gaw/khzWN1+WNmjKZLCASPJph +jwA== X-Gm-Message-State: AOAM533ckmp154VRueks3X5A5Sdhk7gxXKL1ev9FcpJWZI5/Of0NtLZ0 ixx8VW/JJPGpm/81Ewg8EeGXV9GI X-Google-Smtp-Source: ABdhPJyBft11XDWRZmVgzfXJpiwvm7uFOQy/kfiVH84ydfcnpw8qw0yOZlvdCWcwCtQplLVP0ZcIgw== X-Received: by 2002:a17:90a:668f:: with SMTP id m15mr1984656pjj.32.1594087783659; Mon, 06 Jul 2020 19:09:43 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:2da1:1cb9:e3de:8e6d? ([2601:647:5600:5020:2da1:1cb9:e3de:8e6d]) by smtp.gmail.com with ESMTPSA id c1sm706505pje.9.2020.07.06.19.09.42 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2020 19:09:42 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_87193A8F-1C79-41F1-98A3-41811E84B189" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) Date: Mon, 6 Jul 2020 19:09:41 -0700 References: <306B3968-3A40-4E8C-B29D-72CD8E06873B@gmail.com> To: Babel at IETF In-Reply-To: <306B3968-3A40-4E8C-B29D-72CD8E06873B@gmail.com> Message-Id: X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [babel] Issue#15: Add support for routing policy 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, 07 Jul 2020 02:09:47 -0000 --Apple-Mail=_87193A8F-1C79-41F1-98A3-41811E84B189 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Since I have not heard anything from the WG on this issue, I am assuming = that Babel does not have a requirement to extend the routing policy = model. As such, and unless I hear otherwise, I will go ahead and close = this issue by the end of the week. > On Jun 29, 2020, at 10:49 AM, Mahesh Jethanandani = wrote: >=20 > Babel WG, >=20 > I hope this issue has not been brought up already. In either case, I = do not remember what the resolution was. So here it goes. >=20 > The issue against the Babel YANG model that I needed to close on is = documented here = . It asks = if Babel needs to add support for extending the base routing policy = model described in draft-ietf-rtgwg-policy-model = . The base = model defined in that document already defines how routes are imported, = exported, or modified across different routing protocols. The idea for = Babel to extend would come if there was a need to extend it further with = conditions (match sets) and actions that the base model cannot or does = not cover. For example, BGP extends the model to add community option = type, to check if the route type is external or internal, etc. >=20 > Does Babel have a need for operators to be able to extend policy = definition beyond what is already defined in the base model? >=20 > Cheers. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_87193A8F-1C79-41F1-98A3-41811E84B189 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Since= I have not heard anything from the WG on this issue, I am assuming that = Babel does not have a requirement to extend the routing policy model. As = such, and unless I hear otherwise, I will go ahead and close this issue = by the end of the week.

On Jun 29, 2020, at 10:49 AM, = Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

Babel WG,

I hope this issue has = not been brought up already. In either case, I do not remember what the = resolution was. So here it goes.

The issue against the Babel YANG model = that I needed to close on is documented here. It asks if Babel needs to add support for = extending the base routing policy model described in draft-ietf-rtgwg-policy-model. The base model defined in = that document already defines how routes are imported, exported, or = modified across different routing protocols. The idea for Babel to = extend would come if there was a need to extend it further with = conditions (match sets) and actions that the base model cannot or does = not cover. For example, BGP extends the model to add community option = type, to check if the route type is external or internal, etc.

Does Babel have a need = for operators to be able to extend policy definition beyond what is = already defined in the base model?

Cheers.

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_87193A8F-1C79-41F1-98A3-41811E84B189-- From nobody Thu Jul 23 11:50:50 2020 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 0B4313A0CB8; Thu, 23 Jul 2020 11:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Ow5HrNfPGmOo; Thu, 23 Jul 2020 11:50:45 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 B3A7B3A0CA3; Thu, 23 Jul 2020 11:50:45 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id t27so5187209ill.9; Thu, 23 Jul 2020 11:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=OLM0xT3eI4NtMbBRTsQLKckH+W45NvvGgbtQrnYe73k=; b=fe0VTlYwaKUS5zESLwPKhczQue4meK2ofgb6QCcvP6gr/jBcsh3uZ4eTt6UbX9t7hW DHMbmoOw7zm/dtgr6J9WSgIZU6KUqR4sTfFnwYK+eZTN6W1I22GldMz/EuBwo0OvezP6 b95+96TyQUk309xkGcUt+6bURtS/ePc90Y5zOMfDdlM+5e2T+kb1A9C4rwZTm9jzqi5I 1jJLUtgTtccEKZF6EdpArPK2ECY4mSje5zyoY+pMEoUNdGuAMoJx1rJbvu85H/7NovFs Tr3x/DFZG/QTnL4PipHoGQxC01CrzNEviiRLDWh8VyHbLYlQrwLvHF2SWYQv9+s37Lwd iJDA== 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:cc; bh=OLM0xT3eI4NtMbBRTsQLKckH+W45NvvGgbtQrnYe73k=; b=SxYYgULFuLXBIckPqJ+aC/j0/gwc/1Lw4eo7lUZv2uIw7bNHhSZAcaNWZuALPXt38p CBdQfWuPm1kfDqSLOdgDV3R4ITGlIPT7LYOdjxLFlilqUkUAvpptB8wUlag6g0YYDJjX H0PHgyw7D7VeaKWv0ZyiojjCHN2b5ceKuvLDH4C+rwNRQCciJdrkkYMelPXhPnh3zoQz InvQWJdM+djhwhwlpEtD3UtvOFwSW+ooiDXfqvXYO6TOqS5iVBucKMSLTndhyqXPmLpS LRzI+UydUTglzYCJS0EnfwhSPnRDurjRMHjT64fDFfzmmHvBGFLm9YToc/O5j5GQ3n+V 5l9A== X-Gm-Message-State: AOAM531cdSJKMLe4ltbmDdjXBn7h4Px0JDcsQLWeWNM/cW/aMhkdRndd ++CTK3GXab+A6iJaT8y7YvsUorJZMQz/XLesG6vwnr7xIW4= X-Google-Smtp-Source: ABdhPJx5lzpNIuMdFdTs4jbwhbHaADhCIeYZpOQdJRZymqWQfCw4VavnjFtOPhHwpydjzAtGRsAnArDG0wItRD/vpUs= X-Received: by 2002:a92:aa92:: with SMTP id p18mr6284471ill.199.1595530244317; Thu, 23 Jul 2020 11:50:44 -0700 (PDT) MIME-Version: 1.0 From: Donald Eastlake Date: Thu, 23 Jul 2020 14:50:33 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: multipart/alternative; boundary="00000000000070e69505ab20556a" Archived-At: Subject: [babel] Babel meeting agenda, request for slides 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, 23 Jul 2020 18:50:47 -0000 --00000000000070e69505ab20556a Content-Type: text/plain; charset="UTF-8" Hi, The Babel WG meeting at the IETF Virtual meeting next week is 13:00 to 13:50 on Monday, July 27th. That time is UTC. I believe that, for example, easter US time is 4 hours earlier and central European time is 2 hours later. The current agenda is at https://www.ietf.org/proceedings/108/agenda/agenda-108-babel-00 If you are presenting, please send me your slides by Sunday so they can be uploaded. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com --00000000000070e69505ab20556a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The Babel WG meeting at the IETF Vi= rtual meeting next week is 13:00 to 13:50 on Monday, July 27th. That time i= s UTC. I believe that, for example, easter US time is 4 hours earlier and c= entral European time is 2 hours later. The current agenda is at
<= a href=3D"https://www.ietf.org/proceedings/108/agenda/agenda-108-babel-00">= https://www.ietf.org/proceedings/108/agenda/agenda-108-babel-00

If you are presenting, please send me your slides by = Sunday so they can be uploaded.

Thanks,Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-50= 8-333-2270 (cell)
=C2=A02386 Panoramic Circle, Apopka, FL 32703 USA
= =C2=A0d3e3e3@gmail.co= m
--00000000000070e69505ab20556a-- From nobody Fri Jul 24 08:09:32 2020 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 573953A0B8F for ; Fri, 24 Jul 2020 08:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 5wNxz7kgTqTI for ; Fri, 24 Jul 2020 08:09:27 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229483A0BBB for ; Fri, 24 Jul 2020 08:08:34 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 06OF8WM0007453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Jul 2020 17:08:32 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 06OF8Whg032012; Fri, 24 Jul 2020 17:08:32 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9D25EAF442; Fri, 24 Jul 2020 17:08:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id VSFbGvOXqiWa; Fri, 24 Jul 2020 17:08:30 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 8B091AF43F; Fri, 24 Jul 2020 17:08:30 +0200 (CEST) Date: Fri, 24 Jul 2020 17:08:30 +0200 Message-ID: <878sf9vtld.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel-users@lists.alioth.debian.org, babel@ietf.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 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]); Fri, 24 Jul 2020 17:08:32 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 24 Jul 2020 17:08:32 +0200 (CEST) X-Miltered: at korolev with ID 5F1AF970.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5F1AF970.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F1AF970.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5F1AF970.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5F1AF970.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5F1AF970.002 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Babel IETF online meeting on Monday 27 July 13:00 UTC 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, 24 Jul 2020 15:09:30 -0000 Dear all, There will be an online Babel IETF meeting on Monday 27 July 2020, 13:00 UTC Registration is expensive ($330, slightly more expensive than a 10-year US visa), but it is easy enough to get a fee a waiver (I got one straight away, and so did Théo). Just go to https://www.ietf.org/how/meetings/108/ follow the link titled "Fee Waiver Program", and provide a minimal set of personal information. Hope to see you on Monday, -- Juliusz From nobody Sun Jul 26 19:44:04 2020 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 56CAA3A1620 for ; Sun, 26 Jul 2020 19:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 OOBHp4Bieh8D for ; Sun, 26 Jul 2020 19:44:02 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 C67C03A1611 for ; Sun, 26 Jul 2020 19:44:01 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id s21so11809873ilk.5 for ; Sun, 26 Jul 2020 19:44:01 -0700 (PDT) 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; bh=D3g8t1LPyK5zSd3i+1L4N8Es/xofCdJ9zMuBkw+3dSM=; b=p4eDnN5+vPnds3Kr5wu8gH18fl6BMJDsGtGmyThuhdaKxV/tJgK8NyUzUAFxauK6P9 V8Eja9uy1nOaZP//kZgy/IBkwBVRs/qkyCiHgLubp4GaTT30SZYcx99Zgb3eD9vf50GT uKCVBKKwiqpYSux9mc6Qr2qPzfYOs3wZhdXyVACDi7RJAf/NUUuu/recSxZA5fKSFGJP FoIbgqsJJf0Nfoj6As8IWH93P1bp8URo3hyZ0t8R/tXWkuSgMk+dOt79CQJ2oooU3N0u 1Pc9a2fgmoRaN7gWMySk7fwSF0Z8yMN5O4TBhoWp2o8y0XaEDgo/ieOzkPS9qV3Bt7sA 41uA== 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; bh=D3g8t1LPyK5zSd3i+1L4N8Es/xofCdJ9zMuBkw+3dSM=; b=qVDrzKqjf4xdWr6XbJEsP5LNZLcpjC1F/H0tMdVvVKSdlOw327R9osfDW6Dl7WfEW/ NFy2As/4oKDYJm3j8s+uxMR2DAvAIPtcXDlxCbS2ZjidUeUz4Ut7J/sI9d+ufipE+jum kqqH0mnBErkhZazK7aCrBenLJvZb9Mkg0HvDp0QOazoWE2m7/pvbTl3WZCUaq4lB/5Fj qOg8AYeRT3SWU5aGzVVyqWahXTZkGLO2oK27eAPNp7jwbVzSGT08EOH3+1uiOWlw1flJ 7ubCipI9M3WIPq9Ufh7oJILThiLZyLjita9ktbbtfeYCDCVkyBelkOF3pX2W6mMA8Ph9 1z0w== X-Gm-Message-State: AOAM530Oex5QEjUkN6mXuJplTUMk4kZ6JElHCK1KFWdyf+FIfF1jFfMK KBqKiqgnKJVrrHmWi08QxxKw+9r8MLI2nOP4kxJt7GyA X-Google-Smtp-Source: ABdhPJx0Bu5RJGkHpeaELzBORATZLcB9Ba0mIVmzHbxM431UOVp7VKj/hwKUjOiu1AdJUnym6WUtJySvFIRj7DI46Rk= X-Received: by 2002:a92:8453:: with SMTP id l80mr22727939ild.83.1595817840647; Sun, 26 Jul 2020 19:44:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Donald Eastlake Date: Sun, 26 Jul 2020 22:43:49 -0400 Message-ID: To: Babel at IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [babel] Fwd: Encourage people to visit NomCom during office hours 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, 27 Jul 2020 02:44:03 -0000 The following is forwarded at the request of Barbar Stark. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com ---------- Forwarded message --------- From: STARK, BARBARA H Date: Sat, Jul 25, 2020 at 4:16 PM Subject: Encourage people to visit NomCom during office hours To: Working Group Chairs ... I wanted to let everyone know that NomCom will be holding some office hours next week. If you want to stop by and talk with us (just to say Hi, ask about NomCom, ask about being a nominee for the various I* positions, etc.), we'd love to see and hear from you. The date and times (which are also posted on the IETF 108 Agenda) are: Monday, July 27, 16:00-17:00 UTC WebEx: https://ietf.webex.com/ietf/j.php?MTID=m13c41ae118e538b6d25efb25d41307ee Tuesday, July 28, 09:30-10:30 UTC WebEx: https://ietf.webex.com/ietf/j.php?MTID=m6132b48c3eac5469a41043ce55dada20 Thursday, July 30, 20:00-21:00 UTC WebEx: https://ietf.webex.com/ietf/j..php?MTID=mf7ce451931e35818fd7b3bf44abd1026 In addition to being available by WebEx, those of us who can will simultaneously be on Gather.Town (possibly in a special NomCom corner). To find us, the easiest way is to go to the Participants list (at right of the Gather screen), find "Barbara Stark", left click on my name and select "Locate". See you next week! Barbara From nobody Mon Jul 27 00:30:44 2020 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 B06E93A1762 for ; Mon, 27 Jul 2020 00:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE0slYGU73Dl for ; Mon, 27 Jul 2020 00:30:41 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 0CBBF3A175F for ; Mon, 27 Jul 2020 00:30:40 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id p14so12813665wmg.1 for ; Mon, 27 Jul 2020 00:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m3kskAFmebVWrFkPrXoMZVyo2nbGSsyECjSVlES9yPU=; b=i2AgFcZoDyAyvyJhi4PC8WNOZXAjU8zT1Vep5qzEekY4+/06EJg1KRWvNFtqwBb4zk s1KTAm7RlDejyla92FCeLkxp9IGa3fO5dLrK9/oki9feAdz7VQpeuvRcjp5yskWs5miT Re9cppExqt+NkevsuUS5alpyNWC6A+qsAV1kLvKj1cqLGB6XS8LTSl4PhYklUvrOdxHN WU2fT2R5yha2Na/QtjjTteNkNgqi2TUpxQhsmarJMrMQqdCEHVdIP0kYLYDdI3gtJJZA Dnb/In48/MPh6dV/dAlV/5AWMCNAN+9I1B3mnA0itPeCWsaNhQG+J2b51hPYXaNoiPuz PGnw== 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=m3kskAFmebVWrFkPrXoMZVyo2nbGSsyECjSVlES9yPU=; b=VLpUHmsvCjsuNnfDi3/+o3ygkdJ56PcApyylko0PnnBtauwIf51Sim163iNt1zyNW3 DPvw17vKxIQoVKdG83SoZgzKNerT8g0gAaF2irHjBWZFvt7ca0Om1kWwLjnFkLBCyfPH 9T9VpUlvAnczW/DBxKJOWCGhtd92WGKPMWohbijKwjh2uxcyzO7kFA+1fSfUsw4F3+nf WsRv/hNUn8txJ+W8eBqr74pwIJKDtoiOO2+NAb+7vhUjfJS3uyOBgBWuBHF8od8nmmGW nmR3YeNtNbxkK7s9rjxub1ql9Lg7kCx3COq1somfATmm0qr9nr6D83JJP/75FNec5A+K MeKw== X-Gm-Message-State: AOAM5330s41Ld6hdIXI4O5dOy4vIrj1MLaZD8Jl498fpIt0LXIkFC+RK UQEMaTmNptqDai2Nl30kQR1bmkoGMqchLbX74VDrQQ== X-Google-Smtp-Source: ABdhPJx2i50VSd+MfcIY3qKQ72jlVxgeB67oDsiazh5gCoRPBSyQ7KXJ9eySwTIDxxSh+7BJ3WOwS+2MQd3weuZgVLY= X-Received: by 2002:a1c:1bce:: with SMTP id b197mr18075564wmb.32.1595835039280; Mon, 27 Jul 2020 00:30:39 -0700 (PDT) MIME-Version: 1.0 References: <878sf9vtld.wl-jch@irif.fr> In-Reply-To: <878sf9vtld.wl-jch@irif.fr> From: Gabriel Kerneis Date: Mon, 27 Jul 2020 09:30:03 +0200 Message-ID: To: Juliusz Chroboczek Cc: babel-users@lists.alioth.debian.org, Babel at IETF Content-Type: multipart/alternative; boundary="000000000000a34ffa05ab674cd7" Archived-At: Subject: Re: [babel] Babel IETF online meeting on Monday 27 July 13:00 UTC 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, 27 Jul 2020 07:30:43 -0000 --000000000000a34ffa05ab674cd7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://datatracker.ietf.org/wg/babel/meetings/ says the meeting is at 13:00 (UTC) but https://datatracker.ietf.org/doc/agenda-108-babel/ says 13:30. I'm assuming the former is the correct time, but fixing the typo in the latter would be nice if possible. Best, Gabriel go/kerneis-feedback On Fri, Jul 24, 2020 at 5:09 PM Juliusz Chroboczek wrote: > Dear all, > > There will be an online Babel IETF meeting on > > Monday 27 July 2020, 13:00 UTC > > Registration is expensive ($330, slightly more expensive than a 10-year U= S > visa), but it is easy enough to get a fee a waiver (I got one straight > away, and so did Th=C3=A9o). Just go to > > https://www.ietf.org/how/meetings/108/ > > follow the link titled "Fee Waiver Program", and provide a minimal set of > personal information. > > Hope to see you on Monday, > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --000000000000a34ffa05ab674cd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
https://datatracker.ietf.org/wg/babel/meetings/=C2=A0says the meeting= is at 13:00 (UTC) but=C2=A0https://datatracker.ietf.org/doc/agenda-108-babel/=C2= =A0says 13:30. I'm assuming the former is the correct time, but fixing = the typo in the latter would be nice if possible.

Best,<= br clear=3D"all">

On Fri, Jul 24, 2020 at 5:09 PM Juliusz= Chroboczek <jch@irif.fr> wrote:
Dear all,

There will be an online Babel IETF meeting on

=C2=A0 Monday 27 July 2020, 13:00 UTC

Registration is expensive ($330, slightly more expensive than a 10-year US<= br> visa), but it is easy enough to get a fee a waiver (I got one straight
away, and so did Th=C3=A9o).=C2=A0 Just go to

=C2=A0 https://www.ietf.org/how/meetings/108/

follow the link titled "Fee Waiver Program", and provide a minima= l set of
personal information.

Hope to see you on Monday,

-- Juliusz

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--000000000000a34ffa05ab674cd7-- From nobody Mon Jul 27 04:15:44 2020 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 A9D9F3A18AB for ; Mon, 27 Jul 2020 04:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 SqlMUVGw6BOf for ; Mon, 27 Jul 2020 04:15:38 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2108.outbound.protection.outlook.com [40.107.223.108]) (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 C9C003A0D8A for ; Mon, 27 Jul 2020 04:15:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jbbboX0dHqQ6TmGrWFQxhfQS4QtV+7+nqWBLIzjJ0F/IV+CVM36BmJPfNvX/G6boiNb3ao6ovluinXcL26R1bNu3VGb3etmlPbthWEnIFsnjJFZeePHH+pDtRZCYOMWUwR8t6UfDp/h1+dzjNT+Fx69Qht20xnd3k0z5d21XKjS51XLjyUY2sSGXNaUAqYUWRzU7+oIOkQ9vz3YHu3qviF8Z4PckUkulqAttxQoevdTtyfP4mvPyzwhnJL41W15zBipl0n9b1aScGuc0+0E27VwAWG08RRUsTmZgmX807EOTJenFu19l2QVAlosPIGqUY4fU8SyZmD3DonpgikQqiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ylnb6eA+o2EkmnyqQT+03msq83/1QEa2gaRyrlJx5tc=; b=OuPqUnGHO0/OKzpSOxtQMiWoEXznYfpGinO2TzlQ7krOPu+0hbUduQf5e0LnOV5jNB7xVpjQjqupXGS25XIHRsNIgmITaxvJoEuVWGCFNFBHHqq2GrVASrXywJYZVhZquHof0un1KkQ8E7gWYHMlrxQ7KnAFukILGSrdYE4kaOrfS4gnpEpvVi7FbDr9ttvpUYaEaXSeQ3HnpXgiiL2CDLxevp02tT7tkoqxeG/SpcVTdxC0FbAbHV1I3rwRACx9eNZu+JBRae9jCvgM0tDoCs0GK5f/caN6nnGLVOWXwajozUs0LcW2laBC1y4j3eW+TD2G2Sf/FuvqZf6eHdKgjw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ylnb6eA+o2EkmnyqQT+03msq83/1QEa2gaRyrlJx5tc=; b=Lucwc3S1IRzDiymMxCwhKm4YYMkOA5YsLYMd5+dq/CfSbUsk2Co5Nhrs74GAlwuVCQTXmKZ37c9Qb02nIujRrwEwYP2pwyFmTdD4jUdPjXikHj0b2cYIErLwVRqvNrE+r7tnnAOxs6VcnsO4LvpIs+BoJ4rH3cM7Tczsqj0CFpg= Received: from BN6PR13MB1763.namprd13.prod.outlook.com (2603:10b6:404:144::9) by BN6PR13MB0881.namprd13.prod.outlook.com (2603:10b6:404:4::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Mon, 27 Jul 2020 11:15:35 +0000 Received: from BN6PR13MB1763.namprd13.prod.outlook.com ([fe80::4863:4cfb:1fc:5ed7]) by BN6PR13MB1763.namprd13.prod.outlook.com ([fe80::4863:4cfb:1fc:5ed7%7]) with mapi id 15.20.3239.009; Mon, 27 Jul 2020 11:15:35 +0000 From: Donald Eastlake To: Gabriel Kerneis , Juliusz Chroboczek CC: "babel-users@lists.alioth.debian.org" , Babel at IETF Thread-Topic: [babel] Babel IETF online meeting on Monday 27 July 13:00 UTC Thread-Index: AQHWYcx5fP9KzPVdUE6PQ9vCLMn50akbC+OAgAA+2/A= Date: Mon, 27 Jul 2020 11:15:34 +0000 Message-ID: References: <878sf9vtld.wl-jch@irif.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [68.204.227.25] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 194ccbe0-cd6b-4c4a-6936-08d8321e6240 x-ms-traffictypediagnostic: BN6PR13MB0881: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /oxmxIuN/U1n1qt99gCmXTvVn1PZ00EnAthmARtOtiqu6ROWLMrUfN8fyrNhAVGGIZaQaHWMFnCfji6pRdF4RHsDOCRRae2N+oDG+N2nUqn4PLkt5WqFM9UXVmSzhTRWP1NJ942Xii5vOjqmGvH99cHMR8Z1xz4A8C9qV5s66g6YhxSxMPsYzNcbz8eiL54jGyKfGw9GBCYZ6vKBcaB8oRo2+LUKwzANfl1yPBB9DvvEZ6eIUb9l/pSB1pDSwBzQR2g7LGQx5yKBomlI8tjNap4cGdODjpXD+WDJzkVcWUWO3k47HeBib1H+yiRmCl2qR6/X/LdEnRy9nRZ9l+xg/1CiOB27PY6NWyGOCiFhmtbivr7p/40jdSXLm3JAfR/KjY5reoP64rVBSWiBWSuolw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR13MB1763.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(136003)(366004)(376002)(39840400004)(6506007)(66476007)(83380400001)(5660300002)(54906003)(66556008)(53546011)(166002)(9686003)(55016002)(66946007)(44832011)(76116006)(316002)(86362001)(52536014)(26005)(2906002)(7696005)(66446008)(71200400001)(33656002)(186003)(508600001)(8676002)(110136005)(966005)(8936002)(64756008)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: Ok53RMdeqm3FDrci5R9A+rys7jlepp6aFAViAA3MnPug/JVT1rY9E/n/n4E6v0EPo27in2syJ71ONroazS2xikoAjpX6n1pyR4/hP/ZIvq3MfoMa0YZcuEi5beZf+IV2TxT2Fg/xTTmxU1pqkkDYfliHYshEM+cirxfxRcII4svIzWpJNHAUC9iZ9HuOyghbQ0j/ICavZlUWNz7WIBZWQpTJDdC2VlRV8DOGDNgYf+RHzBawkUsGORb2TJ2Cx6wvvXEpIGQwMMBdPxPrBsKnfg+2G8sgkfY+rFDVbBNiqdBTqITtCJAGA/3LfmCxIHST6f1CWHhvVDhxFoDA6Qmeqyio/0WqGJWr8XEuso/gVuxy0kCCGqR/o3FR28OBXvOaeV9KRrVsWkmFDbqMixU7fCQI+TkgwJRBgKGb61Pd4wHuNALSmXAuRM2GKBh9rHLYQJyNXd9OQpvcl2wCXqSAzrKXSkjrKgDqNUFaTrrIHEtC5UNu94/oojtbAqtl0VDLd+WVmi76ZShBpYKdEuBJMFpOP8ImReSZtIXwwEQGQtW5UUQxuJYV3YXtXKDKrLknYMS31KjIv7AVffxHqNkqWN9NYC3zd4LMaQGwp4csR9XEYxK/+xOVuxnxmu0Bd9qlNSzAaZkDLrJ5kTcGCOYWEQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN6PR13MB1763252276EB6B80AC4A3D6FE9720BN6PR13MB1763namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR13MB1763.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 194ccbe0-cd6b-4c4a-6936-08d8321e6240 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2020 11:15:34.9962 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Q37NEylKtfaTS0kG/0g2WcSm0YCQZotciiOhCrqDTY0SJ1qdRz3UVbOgTpRfeOIVBadv4g9vwTzHt9reG6055Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR13MB0881 Archived-At: Subject: Re: [babel] Babel IETF online meeting on Monday 27 July 13:00 UTC 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, 27 Jul 2020 11:15:40 -0000 --_000_BN6PR13MB1763252276EB6B80AC4A3D6FE9720BN6PR13MB1763namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBpdOKAmXMgMTM6MDAuIFNvcnJ5IGZvciB0aGUgZXJyb3IuIEl0IGhhcyBiZWVuIGZpeGVk Lg0KDQpEb25hbGQNCg0KRnJvbTogYmFiZWwgPGJhYmVsLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJl aGFsZiBPZiBHYWJyaWVsIEtlcm5laXMNClNlbnQ6IE1vbmRheSwgSnVseSAyNywgMjAyMCAzOjMw IEFNDQpUbzogSnVsaXVzeiBDaHJvYm9jemVrIDxqY2hAaXJpZi5mcj4NCkNjOiBiYWJlbC11c2Vy c0BsaXN0cy5hbGlvdGguZGViaWFuLm9yZzsgQmFiZWwgYXQgSUVURiA8YmFiZWxAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW2JhYmVsXSBCYWJlbCBJRVRGIG9ubGluZSBtZWV0aW5nIG9uIE1vbmRh eSAyNyBKdWx5IDEzOjAwIFVUQw0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL2Jh YmVsL21lZXRpbmdzLzxodHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRndnJTJGYmFiZWwl MkZtZWV0aW5ncyUyRiZkYXRhPTAyJTdDMDElN0Nkb25hbGQuZWFzdGxha2UlNDBmdXR1cmV3ZWku Y29tJTdDMjMxZDJkZTgzMzMzNDU1ZWZkMGMwOGQ4MzFmZWZhOTclN0MwZmVlOGZmMmEzYjI0MDE4 OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MxJTdDNjM3MzE0MzE4NDk4MTMxODg4JnNkYXRhPWFkV2xz S0xXcFdYaTZMSWlwR0pBJTJGJTJGMnZXZFNNaDZ2R1NRVXdPU1dTTzBNJTNEJnJlc2VydmVkPTA+ IHNheXMgdGhlIG1lZXRpbmcgaXMgYXQgMTM6MDAgKFVUQykgYnV0IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2FnZW5kYS0xMDgtYmFiZWwvPGh0dHBzOi8vbmFtMTEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmll dGYub3JnJTJGZG9jJTJGYWdlbmRhLTEwOC1iYWJlbCUyRiZkYXRhPTAyJTdDMDElN0Nkb25hbGQu ZWFzdGxha2UlNDBmdXR1cmV3ZWkuY29tJTdDMjMxZDJkZTgzMzMzNDU1ZWZkMGMwOGQ4MzFmZWZh OTclN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MxJTdDNjM3MzE0MzE4 NDk4MTMxODg4JnNkYXRhPUdOaHJsUDR4alB4NCUyQjB6TFNNbGtYajMlMkZKJTJCRjdqUUprRHI0 RmZhNEtOSmMlM0QmcmVzZXJ2ZWQ9MD4gc2F5cyAxMzozMC4gSSdtIGFzc3VtaW5nIHRoZSBmb3Jt ZXIgaXMgdGhlIGNvcnJlY3QgdGltZSwgYnV0IGZpeGluZyB0aGUgdHlwbyBpbiB0aGUgbGF0dGVy IHdvdWxkIGJlIG5pY2UgaWYgcG9zc2libGUuDQoNCkJlc3QsDQpHYWJyaWVsDQpnby9rZXJuZWlz LWZlZWRiYWNrPGh0dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRmdvdG8uZ29vZ2xlLmNvbSUyRmtlcm5laXMtZmVlZGJhY2smZGF0 YT0wMiU3QzAxJTdDZG9uYWxkLmVhc3RsYWtlJTQwZnV0dXJld2VpLmNvbSU3QzIzMWQyZGU4MzMz MzQ1NWVmZDBjMDhkODMxZmVmYTk3JTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMl N0MxJTdDMSU3QzYzNzMxNDMxODQ5ODE0MTg4MyZzZGF0YT1SSVUyaHZuV0doY29WYm94aVJxVmF2 WlF3alhVRzc5UmVrcUdNZUhxZlhvJTNEJnJlc2VydmVkPTA+DQoNCg0KT24gRnJpLCBKdWwgMjQs IDIwMjAgYXQgNTowOSBQTSBKdWxpdXN6IENocm9ib2N6ZWsgPGpjaEBpcmlmLmZyPG1haWx0bzpq Y2hAaXJpZi5mcj4+IHdyb3RlOg0KRGVhciBhbGwsDQoNClRoZXJlIHdpbGwgYmUgYW4gb25saW5l IEJhYmVsIElFVEYgbWVldGluZyBvbg0KDQogIE1vbmRheSAyNyBKdWx5IDIwMjAsIDEzOjAwIFVU Qw0KDQpSZWdpc3RyYXRpb24gaXMgZXhwZW5zaXZlICgkMzMwLCBzbGlnaHRseSBtb3JlIGV4cGVu c2l2ZSB0aGFuIGEgMTAteWVhciBVUw0KdmlzYSksIGJ1dCBpdCBpcyBlYXN5IGVub3VnaCB0byBn ZXQgYSBmZWUgYSB3YWl2ZXIgKEkgZ290IG9uZSBzdHJhaWdodA0KYXdheSwgYW5kIHNvIGRpZCBU aMOpbykuICBKdXN0IGdvIHRvDQoNCiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaG93L21lZXRpbmdz LzEwOC88aHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGaG93JTJGbWVldGluZ3MlMkYxMDglMkYmZGF0 YT0wMiU3QzAxJTdDZG9uYWxkLmVhc3RsYWtlJTQwZnV0dXJld2VpLmNvbSU3QzIzMWQyZGU4MzMz MzQ1NWVmZDBjMDhkODMxZmVmYTk3JTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMl N0MxJTdDMSU3QzYzNzMxNDMxODQ5ODE1MTg4MSZzZGF0YT1lZlQ3SDBtJTJGT1FncklPQk1NQzN2 eEh5TElNYWMxTkF4QnJvOU1ES3U3RTAlM0QmcmVzZXJ2ZWQ9MD4NCg0KZm9sbG93IHRoZSBsaW5r IHRpdGxlZCAiRmVlIFdhaXZlciBQcm9ncmFtIiwgYW5kIHByb3ZpZGUgYSBtaW5pbWFsIHNldCBv Zg0KcGVyc29uYWwgaW5mb3JtYXRpb24uDQoNCkhvcGUgdG8gc2VlIHlvdSBvbiBNb25kYXksDQoN Ci0tIEp1bGl1c3oNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCmJhYmVsIG1haWxpbmcgbGlzdA0KYmFiZWxAaWV0Zi5vcmc8bWFpbHRvOmJhYmVsQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iYWJlbDxodHRw czovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0El MkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZiYWJlbCZkYXRhPTAyJTdD MDElN0Nkb25hbGQuZWFzdGxha2UlNDBmdXR1cmV3ZWkuY29tJTdDMjMxZDJkZTgzMzMzNDU1ZWZk MGMwOGQ4MzFmZWZhOTclN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0Mx JTdDNjM3MzE0MzE4NDk4MTUxODgxJnNkYXRhPXZ1ZGN1SlNtclpCRiUyRmtBUyUyRjFCMDNNaWJK VDJaNFljeDZHQ2p3VElQaTM4JTNEJnJlc2VydmVkPTA+DQo= --_000_BN6PR13MB1763252276EB6B80AC4A3D6FE9720BN6PR13MB1763namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlllcywgaXTigJlzIDEzOjAwLiBTb3JyeSBmb3IgdGhlIGVycm9yLiBJdCBoYXMgYmVlbiBm aXhlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG9uYWxkPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBiYWJlbCAmbHQ7YmFi ZWwtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCkdhYnJpZWwgS2Vy bmVpczxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgMjcsIDIwMjAgMzozMCBBTTxicj4N CjxiPlRvOjwvYj4gSnVsaXVzeiBDaHJvYm9jemVrICZsdDtqY2hAaXJpZi5mciZndDs8YnI+DQo8 Yj5DYzo8L2I+IGJhYmVsLXVzZXJzQGxpc3RzLmFsaW90aC5kZWJpYW4ub3JnOyBCYWJlbCBhdCBJ RVRGICZsdDtiYWJlbEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtiYWJl bF0gQmFiZWwgSUVURiBvbmxpbmUgbWVldGluZyBvbiBNb25kYXkgMjcgSnVseSAxMzowMCBVVEM8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9u YW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG ZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZ3ZyUyRmJhYmVsJTJGbWVldGluZ3MlMkYmYW1wO2RhdGE9 MDIlN0MwMSU3Q2RvbmFsZC5lYXN0bGFrZSU0MGZ1dHVyZXdlaS5jb20lN0MyMzFkMmRlODMzMzM0 NTVlZmQwYzA4ZDgzMWZlZmE5NyU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjJTdD MSU3QzElN0M2MzczMTQzMTg0OTgxMzE4ODgmYW1wO3NkYXRhPWFkV2xzS0xXcFdYaTZMSWlwR0pB JTJGJTJGMnZXZFNNaDZ2R1NRVXdPU1dTTzBNJTNEJmFtcDtyZXNlcnZlZD0wIj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL3dnL2JhYmVsL21lZXRpbmdzLzwvYT4mbmJzcDtzYXlzDQogdGhl IG1lZXRpbmcgaXMgYXQgMTM6MDAgKFVUQykgYnV0Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9uYW0x MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0 YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZhZ2VuZGEtMTA4LWJhYmVsJTJGJmFtcDtkYXRhPTAy JTdDMDElN0Nkb25hbGQuZWFzdGxha2UlNDBmdXR1cmV3ZWkuY29tJTdDMjMxZDJkZTgzMzMzNDU1 ZWZkMGMwOGQ4MzFmZWZhOTclN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzEl N0MxJTdDNjM3MzE0MzE4NDk4MTMxODg4JmFtcDtzZGF0YT1HTmhybFA0eGpQeDQlMkIwekxTTWxr WGozJTJGSiUyQkY3alFKa0RyNEZmYTRLTkpjJTNEJmFtcDtyZXNlcnZlZD0wIj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9hZ2VuZGEtMTA4LWJhYmVsLzwvYT4mbmJzcDtzYXlzDQog MTM6MzAuIEknbSBhc3N1bWluZyB0aGUgZm9ybWVyIGlzIHRoZSBjb3JyZWN0IHRpbWUsIGJ1dCBm aXhpbmcgdGhlIHR5cG8gaW4gdGhlIGxhdHRlciB3b3VsZCBiZSBuaWNlIGlmIHBvc3NpYmxlLjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCw8YnIgY2xl YXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkdhYnJpZWw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YSBocmVmPSJodHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnb3RvLmdvb2dsZS5jb20lMkZrZXJuZWlzLWZlZWRi YWNrJmFtcDtkYXRhPTAyJTdDMDElN0Nkb25hbGQuZWFzdGxha2UlNDBmdXR1cmV3ZWkuY29tJTdD MjMxZDJkZTgzMzMzNDU1ZWZkMGMwOGQ4MzFmZWZhOTclN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNh MWQ1NTkxZmVkYyU3QzElN0MxJTdDNjM3MzE0MzE4NDk4MTQxODgzJmFtcDtzZGF0YT1SSVUyaHZu V0doY29WYm94aVJxVmF2WlF3alhVRzc5UmVrcUdNZUhxZlhvJTNEJmFtcDtyZXNlcnZlZD0wIiB0 YXJnZXQ9Il9ibGFuayI+Z28va2VybmVpcy1mZWVkYmFjazwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IEZyaSwgSnVsIDI0LCAyMDIwIGF0IDU6MDkgUE0gSnVsaXVzeiBDaHJvYm9jemVrICZsdDs8YSBo cmVmPSJtYWlsdG86amNoQGlyaWYuZnIiPmpjaEBpcmlmLmZyPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFy IGFsbCw8YnI+DQo8YnI+DQpUaGVyZSB3aWxsIGJlIGFuIG9ubGluZSBCYWJlbCBJRVRGIG1lZXRp bmcgb248YnI+DQo8YnI+DQombmJzcDsgTW9uZGF5IDI3IEp1bHkgMjAyMCwgMTM6MDAgVVRDPGJy Pg0KPGJyPg0KUmVnaXN0cmF0aW9uIGlzIGV4cGVuc2l2ZSAoJDMzMCwgc2xpZ2h0bHkgbW9yZSBl eHBlbnNpdmUgdGhhbiBhIDEwLXllYXIgVVM8YnI+DQp2aXNhKSwgYnV0IGl0IGlzIGVhc3kgZW5v dWdoIHRvIGdldCBhIGZlZSBhIHdhaXZlciAoSSBnb3Qgb25lIHN0cmFpZ2h0PGJyPg0KYXdheSwg YW5kIHNvIGRpZCBUaMOpbykuJm5ic3A7IEp1c3QgZ28gdG88YnI+DQo8YnI+DQombmJzcDsgPGEg aHJlZj0iaHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGaG93JTJGbWVldGluZ3MlMkYxMDglMkYmYW1w O2RhdGE9MDIlN0MwMSU3Q2RvbmFsZC5lYXN0bGFrZSU0MGZ1dHVyZXdlaS5jb20lN0MyMzFkMmRl ODMzMzM0NTVlZmQwYzA4ZDgzMWZlZmE5NyU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFm ZWRjJTdDMSU3QzElN0M2MzczMTQzMTg0OTgxNTE4ODEmYW1wO3NkYXRhPWVmVDdIMG0lMkZPUWdy SU9CTU1DM3Z4SHlMSU1hYzFOQXhCcm85TURLdTdFMCUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0 PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaG93L21lZXRpbmdzLzEwOC88L2E+PGJy Pg0KPGJyPg0KZm9sbG93IHRoZSBsaW5rIHRpdGxlZCAmcXVvdDtGZWUgV2FpdmVyIFByb2dyYW0m cXVvdDssIGFuZCBwcm92aWRlIGEgbWluaW1hbCBzZXQgb2Y8YnI+DQpwZXJzb25hbCBpbmZvcm1h dGlvbi48YnI+DQo8YnI+DQpIb3BlIHRvIHNlZSB5b3Ugb24gTW9uZGF5LDxicj4NCjxicj4NCi0t IEp1bGl1c3o8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCmJhYmVsIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpi YWJlbEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJhYmVsQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRmJhYmVs JmFtcDtkYXRhPTAyJTdDMDElN0Nkb25hbGQuZWFzdGxha2UlNDBmdXR1cmV3ZWkuY29tJTdDMjMx ZDJkZTgzMzMzNDU1ZWZkMGMwOGQ4MzFmZWZhOTclN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1 NTkxZmVkYyU3QzElN0MxJTdDNjM3MzE0MzE4NDk4MTUxODgxJmFtcDtzZGF0YT12dWRjdUpTbXJa QkYlMkZrQVMlMkYxQjAzTWliSlQyWjRZY3g2R0Nqd1RJUGkzOCUzRCZhbXA7cmVzZXJ2ZWQ9MCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmFi ZWw8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_BN6PR13MB1763252276EB6B80AC4A3D6FE9720BN6PR13MB1763namp_-- From nobody Mon Jul 27 05:16:26 2020 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 BABB33A1955; Mon, 27 Jul 2020 05:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 vAAHaWICb0d7; Mon, 27 Jul 2020 05:16:15 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 F1AC83A1940; Mon, 27 Jul 2020 05:16:14 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id a5so1427593ioa.13; Mon, 27 Jul 2020 05:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=wycw/aOAudDwKNBtTO+QBNhiOxdEN0wRvTIe7Lvdsyk=; b=CWfjCHk9h+s5r5QnRWcNMv0aXR9TPwv9HwgIxmVUyeAus56iZjD0KfECcUI72tkGvk aXnHK/RE+E9yfs6swjwfhldPEpNmb5/UKK2dG6OFn6w9x74TW7BhdNUK+H4w6oubZtfS w7yHlh54dCILF3PgXbGAg/WZ+itSQ4TrZHLD0lHYb4uZlKzrlYLZkAmsG/fwfuAwui6H rmyekilt6CfH5q+vRMzruVZZ3dzEMoJfRLvrFSlRaMnmKovPAHElsmqrQ1IF4aSO8oSr uZK9DJhlPwfYxJXtltT8cWXUJmlYDhFgMhtqso4AhrQMooupIf+LJPruWbsH8QFfUwrj zRUA== 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:cc; bh=wycw/aOAudDwKNBtTO+QBNhiOxdEN0wRvTIe7Lvdsyk=; b=WmUyXdKwlNmWjDe8r+GhsW0BSxQ+o9w7wAfpNZrX3M+w1xV7Smri00ba4VK5oBwnsW 2Kl9RLCHHd2CkcOPbjOfexpmHsIdfeUcvKP8qoWnDIkKoh3UIJE7g4D8sAXwx8DpuoE3 6smaS5t0sn8dqNoWhHR53bN7BQECdBf3PauH+DKBYFJWDyXJHgIhCDl7MKwQpqP7yZxY oz0DkIDKxCQoxWPZWhGktmiBH4SfgBVLxrd5AKY3n8ovcp4UZ/2E2q5tn2PsC8+Mfren 8yFTdP5GEit29NEYCun6bsQsJ7SAEt1+FerATRQJgs0rpeHIm377skAbPNdIAy2qorUO eVuQ== X-Gm-Message-State: AOAM533xBIfD0SeQeOgBaQdL3ruH7iuyDRH6sdZ6BO2bJUeOqI6TRl0M x37kq5tZGIoNu4J7ASg7Q+KVWYGglx6BnQaOpGlEH1ZsxCc= X-Google-Smtp-Source: ABdhPJzkVYdXb+ETaxUSwi13UJjk/1W5Y8edhz/tF42kNIb9o/JdP2h8PDjd37ggBk1H/OnMoz6Ay1myNoSwalyNoi4= X-Received: by 2002:a6b:6413:: with SMTP id t19mr23168045iog.167.1595852173549; Mon, 27 Jul 2020 05:16:13 -0700 (PDT) MIME-Version: 1.0 From: Donald Eastlake Date: Mon, 27 Jul 2020 08:16:02 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [babel] Joining the Babel WG meeting 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, 27 Jul 2020 12:16:24 -0000 Hi, The URLs for joining the meeting coming up soon should be as follows: Meetecho https://meetings.conf.meetecho.com/ietf108/?group=babel&short=&item=1 Audio only http://mp3.conf.meetecho.com/ietf/ietf1086.m3u Chat only xmpp:babel@jabber.ietf.org?join Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com From nobody Mon Jul 27 07:13:16 2020 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 7060C3A1AF0 for ; Mon, 27 Jul 2020 07:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hVF-ZIIFWZNE for ; Mon, 27 Jul 2020 07:13:04 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DD033A1A20 for ; Mon, 27 Jul 2020 07:12:52 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 06RECoaQ018872; Mon, 27 Jul 2020 16:12:50 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 731E4AA9F6; Mon, 27 Jul 2020 16:12:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 5-twY2I3I-PD; Mon, 27 Jul 2020 16:12:49 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3C32EAA9F1; Mon, 27 Jul 2020 16:12:49 +0200 (CEST) Date: Mon, 27 Jul 2020 16:12:48 +0200 Message-ID: <87d04hxd0f.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org CC: Margaret Cullen User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 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]); Mon, 27 Jul 2020 16:12:50 +0200 (CEST) X-Miltered: at korolev with ID 5F1EE0E2.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F1EE0E2.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 : 5F1EE0E2.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] v4-via-v6: what about ICMPv4? 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, 27 Jul 2020 14:13:16 -0000 Dear all, Margaret (in copy of this mail) made two comments during Théo's presentation about v4-via-v6. 1. We should call it « v4-via-v6 » instead of « v4-over-v6 ». I think she's right. I haven't discussed it with Théo yet. Comments? 2. In a network that's routing IPv4 but where some interfaces have no v4 addresses, there might be issues with ICMPv4. In particular, a router might find itself unable to send an ICMPv4 packet. I haven't thought about the issue yet, I'll start looking at the litterature to see if the problem has been considered. If anyone knows anything about this issue, please let me know. Thanks for your help, -- Juliusz From nobody Mon Jul 27 07:19:28 2020 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 D5E723A0ECC for ; Mon, 27 Jul 2020 07:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 tZZIdocY4Z8m for ; Mon, 27 Jul 2020 07:19:24 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [IPv6:2a0c:4d80:42:2001::664]) (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 254A83A0EB9 for ; Mon, 27 Jul 2020 07:19:23 -0700 (PDT) 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=1595859561; bh=pLL9UNxcJONw+nolzvKx6MjKzTeYqRGi5lafW/LjBA0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=U64HmOIeOYSpRIA+Xxmybi4bJeTw/r8zLNuh/L2YR58Lgo2xfKjlvMRJcMiyJbxOC U1hWN46UYr/lL2SXyQw2i3TnplIAoLcluSYBjAEHALMprnYrjzYKpnk6028Hcp37j6 GtlRv9os8qoqaS06PfRsef0q+6kRr8W6y4iZrYZ5W9QdxNnlqiXMJn4ucQuv6s/WzR 0Ww1cjUBj3WqQHWYqdN/2MhCHVACSChGDKqG0r6lz3wC2yUqepdAZH6hY6+Y33snX6 9ldNP6kCIhvLU+ONc32SPIYX0hzxWKusN3v5rGRLZhUICHjxgeWLJl9f6EmGjgYwdK oOl75We9enERg== To: Juliusz Chroboczek , babel@ietf.org Cc: Margaret Cullen In-Reply-To: <87d04hxd0f.wl-jch@irif.fr> References: <87d04hxd0f.wl-jch@irif.fr> Date: Mon, 27 Jul 2020 16:19:18 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <871rkx59cp.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] v4-via-v6: what about ICMPv4? 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, 27 Jul 2020 14:19:26 -0000 Juliusz Chroboczek writes: > Dear all, > > Margaret (in copy of this mail) made two comments during Th=C3=A9o's > presentation about v4-via-v6. > > 1. We should call it =C2=AB v4-via-v6 =C2=BB instead of =C2=AB v4-over-v6= =C2=BB. > > I think she's right. I haven't discussed it with Th=C3=A9o yet. Comment= s? Fine with me. > 2. In a network that's routing IPv4 but where some interfaces have no v4 > addresses, there might be issues with ICMPv4. In particular, a router > might find itself unable to send an ICMPv4 packet. > > I haven't thought about the issue yet, I'll start looking at the > litterature to see if the problem has been considered. If anyone knows > anything about this issue, please let me know. No idea, I'll await your no doubt thorough literature review :) What happens if you run traceroute over your test v4-over-v6 setup? -Toke From nobody Mon Jul 27 07:24:30 2020 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 AAC7D3A1A37 for ; Mon, 27 Jul 2020 07:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 (1024-bit key) header.d=ens.fr 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 GGaISjgi7jyV for ; Mon, 27 Jul 2020 07:24:26 -0700 (PDT) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) (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 CB4D23A19F2 for ; Mon, 27 Jul 2020 07:23:44 -0700 (PDT) X-ENS-nef-client: 129.199.1.22 ( name = clipper-gw.ens.fr ) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens.fr; s=default; t=1595859822; bh=Iw+HjPF7BwjjCnEfhFFuaihJLVBB1uKIMoIsJgMI+RA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=X3DMh66MOlGcXWy5h8irGAmHw+qrwunVq0bxGDdZv5jkys6rbH8THqsuyAG/xernz VkpK0R0OrrQG3hj1INY6XDhwvJ8MnDQWouo6LZ53xEQilWfvM8gedXtNc90p6anAIc TXd35pUrf7i4j6A/a2jvOtdE9d57G+7YRtGhoy0c= Received: from clipper.ens.fr (clipper-gw.ens.fr [129.199.1.22]) by nef.ens.fr (8.14.4/1.01.28121999) with ESMTP id 06RENfGx006601 ; Mon, 27 Jul 2020 16:23:41 +0200 Received: from [192.168.0.14] using smtps by clipper.ens.fr (8.14.4/jb-1.1) id 06RENejR135580 ; Mon, 27 Jul 2020 16:23:41 +0200 (authenticated user tbastian) X-ENS-Received: (91-160-99-187.subs.proxad.net [91.160.99.187]) To: babel@ietf.org Cc: Margaret Cullen References: <87d04hxd0f.wl-jch@irif.fr> <871rkx59cp.fsf@toke.dk> From: =?UTF-8?Q?Th=c3=a9ophile_Bastian?= Message-ID: Date: Mon, 27 Jul 2020 16:23:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <871rkx59cp.fsf@toke.dk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US-large Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Mon, 27 Jul 2020 16:23:41 +0200 (CEST) Archived-At: Subject: Re: [babel] v4-via-v6: what about ICMPv4? 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, 27 Jul 2020 14:24:29 -0000 On 7/27/20 4:12 PM, Juliusz Chroboczek wrote: > 1. We should call it « v4-via-v6 » instead of « v4-over-v6 ». > > I think she's right. I haven't discussed it with Théo yet. Comments? I would tend to agree, too. I find "via" a bit more accurate, "over" sounds a bit like tunnels now that I think about it. On 7/27/20 4:19 PM, Toke Høiland-Jørgensen wrote: > What happens if you run traceroute over your test v4-over-v6 setup? I'll try this right away and update you. -- Théophile Bastian From nobody Mon Jul 27 08:15:43 2020 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 0F1BA3A0F0F for ; Mon, 27 Jul 2020 08:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 (1024-bit key) header.d=ens.fr 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 u-IWRVjOzhhC for ; Mon, 27 Jul 2020 08:15:39 -0700 (PDT) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) (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 C07263A1A3E for ; Mon, 27 Jul 2020 08:15:34 -0700 (PDT) X-ENS-nef-client: 129.199.1.22 ( name = clipper-gw.ens.fr ) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens.fr; s=default; t=1595862932; bh=p1GUP7RwOaKv8mPEXSDTP18zC3FgrYhVPb5g59805zs=; h=Subject:From:To:References:Date:In-Reply-To:From; b=NnaeqAO+7+hoTQ1eGEhqKl8AlWLf89RrwlF+3/YxPjz1x04rE+qrVtDh1VsQxUQU3 WZXtUXBsMxFjHyvG37EXHZ142UB9zft2YLuVE6kdUYr82zkRKYnOevBS4iLjoZKGa/ ml9e6z0sbjYAM3fccc4VIEXYgO7U7u9MIfVL8yzE= Received: from clipper.ens.fr (clipper-gw.ens.fr [129.199.1.22]) by nef.ens.fr (8.14.4/1.01.28121999) with ESMTP id 06RFFWeO031978 for ; Mon, 27 Jul 2020 17:15:32 +0200 Received: from [192.168.0.14] using smtps by clipper.ens.fr (8.14.4/jb-1.1) id 06RFFVhi086148 for ; Mon, 27 Jul 2020 17:15:32 +0200 (authenticated user tbastian) X-ENS-Received: (91-160-99-187.subs.proxad.net [91.160.99.187]) X-Envelope-To: From: =?UTF-8?Q?Th=c3=a9ophile_Bastian?= To: babel@ietf.org References: <87d04hxd0f.wl-jch@irif.fr> <871rkx59cp.fsf@toke.dk> Message-ID: <5ae89f16-c996-c928-c935-0dbdf22760e0@ens.fr> Date: Mon, 27 Jul 2020 17:15:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Mon, 27 Jul 2020 17:15:32 +0200 (CEST) Archived-At: Subject: Re: [babel] v4-via-v6: what about ICMPv4? 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, 27 Jul 2020 15:15:41 -0000 >> What happens if you run traceroute over your test v4-over-v6 setup? In this topology: A --- B --- C --- D --- E 4 4 4 4 I get # tracepath 10.132.4.5 1?: [LOCALHOST] pmtu 1500 1: ??? 0.089ms 1: ??? 0.083ms 2: no reply 3: ??? 0.154ms 4: ??? 0.149ms reached Resume: pmtu 1500 hops 4 back 4 while trying a tracepath from A to E. -- Théophile Bastian From nobody Mon Jul 27 08:27:55 2020 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 F39103A0F46 for ; Mon, 27 Jul 2020 08:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=painless-security-com.20150623.gappssmtp.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 Z0A-nytAuKaE for ; Mon, 27 Jul 2020 08:27:52 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 568FE3A0F1E for ; Mon, 27 Jul 2020 08:27:52 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id s16so12480339qtn.7 for ; Mon, 27 Jul 2020 08:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=painless-security-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=2b6QSlPSA36PeBmuWH1tO/UBLuZYFnqSE5aw5cc8qaI=; b=vEjS1GxnlOCFModtqcnqpcEgRyZ43hSi3V3WllQ/mv84bRWXIMbJTWhjLxVtq0kAkm b1bMcuxAo7mluIF7mWwcD55IDrFto2GVk5Jd5sOqo8zYHbCP6rUP4XzH5JnFhGhubXd1 UAVKmiu725ZlM+EV2C5eq+j/uSf5v9O8XJEkekASbc/Da0gyQAyUBbOu6N/oGP2IjdFH hhPaTu5tZxlvNjtT4dfHNpPGfmR26Adog9cIZ4ABTuQ1h+f5XJyEeD7DcywqBddV8ji+ /fzrSMseiou1FaEqO3yOFtEoTSYOvLci1IuydyA23OeXou4F4g83EHedc7e1Jba/TpNC cFPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=2b6QSlPSA36PeBmuWH1tO/UBLuZYFnqSE5aw5cc8qaI=; b=PzIM5ig2CDpUvLJ8bw88qLhx/KZEsIycxySZbFCBCNqX8Zt8D8aq7RF2gSL0pXdBlt li5hmlmR5UiQZHxbN1eG9nFjkygG5iAMT91r+XLtLdg1Bk1tbmgk+JKys6IYwE31NawH Gy2LClbTnuNlhl8CvZGKk+BeZtTVHlbwNzRsRUWQz3Ezwfy//qWwiAHkq8CNepb2La3y 6cVshvtRmq1tgctw9bL2x9eKaaVy+6Yri03OoZIMUNF9s5H3cCgLuBtfgRMx1Y3BvKEY 2Dn41YAz2KL4ozst9CPk7cwV/fgns9zgmChILBPV6o9+xB+fT/VFurHERU27lTHfuJmK m/1Q== X-Gm-Message-State: AOAM530ekpnPTNjz4Dsk7ooOPzbG+mCtX48+p/c+BlKn0ANREUkFBNnd cNZ7XV4WgJYHN/Rdms+sjzcd5Zjdpsg9UGGIQI9i2SgqBJp6kNxnFtWHfsyiSlXRSlNil644Svr fCYZM1C2ZWmlhKkiNvhmO00nxzZjVuet02thSst4x9dcpU4JOUjBTERztorWpW/cPE0aAYxs= X-Google-Smtp-Source: ABdhPJzcwg0/BFdDbIlSLeypeK7C98Mclaw4dTW4vA8AEP5L6eOQlVN5t71wBDj8tM/aGOfi2Uy0fQ== X-Received: by 2002:aed:20e5:: with SMTP id 92mr22679769qtb.388.1595863671116; Mon, 27 Jul 2020 08:27:51 -0700 (PDT) Received: from ?IPv6:2607:fb90:68d8:d555:2c1a:7be1:2f66:4717? ([2607:fb90:68d8:d555:2c1a:7be1:2f66:4717]) by smtp.gmail.com with ESMTPSA id n127sm19173713qke.29.2020.07.27.08.27.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Jul 2020 08:27:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Margaret Cullen Mime-Version: 1.0 (1.0) Date: Mon, 27 Jul 2020 11:27:32 -0400 Message-Id: <736B4827-1031-4054-BC0E-56B169114B1A@painless-security.com> References: <5ae89f16-c996-c928-c935-0dbdf22760e0@ens.fr> Cc: babel@ietf.org In-Reply-To: <5ae89f16-c996-c928-c935-0dbdf22760e0@ens.fr> To: =?utf-8?Q?Th=C3=A9ophile_Bastian?= X-Mailer: iPhone Mail (17F80) Archived-At: Subject: Re: [babel] v4-via-v6: what about ICMPv4? 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, 27 Jul 2020 15:27:54 -0000 Does this imply that if network AB had a higher MTU than network CD, large I= Pv4 packets from network AB with the DF (don=E2=80=99t fragment) bit set wou= ld black-holed by router C? =20 I need to go refresh my memory of IPv4 MTU discovery to know what issues (if= any) that would cause... > On Jul 27, 2020, at 11:15 AM, Th=C3=A9ophile Bastian wrote: >=20 > =EF=BB=BF >>=20 >>> What happens if you run traceroute over your test v4-over-v6 setup? >=20 > In this topology: >=20 > A --- B --- C --- D --- E > 4 4 4 4 >=20 > I get >=20 > # tracepath 10.132.4.5 > 1?: [LOCALHOST] pmtu 1500 > 1: ??? 0.089ms > 1: ??? 0.083ms > 2: no reply > 3: ??? 0.154ms > 4: ??? 0.149ms reached > Resume: pmtu 1500 hops 4 back 4 >=20 > while trying a tracepath from A to E. >=20 > --=20 > Th=C3=A9ophile Bastian >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Mon Jul 27 09:00:06 2020 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 48B7B3A1B1E for ; Mon, 27 Jul 2020 08:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NF0HGNxUpFfs for ; Mon, 27 Jul 2020 08:59:53 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 726253A1B17 for ; Mon, 27 Jul 2020 08:59:51 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 06RFxnJX016245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 27 Jul 2020 17:59:49 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 06RFxn6O023876 for ; Mon, 27 Jul 2020 17:59:49 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id CD056AB36B for ; Mon, 27 Jul 2020 17:59:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id QKV3fu_bPalQ for ; Mon, 27 Jul 2020 17:59:48 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 8B893AB369 for ; Mon, 27 Jul 2020 17:59:48 +0200 (CEST) Date: Mon, 27 Jul 2020 17:59:48 +0200 Message-ID: <874kptx823.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Mon, 27 Jul 2020 17:59:49 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 27 Jul 2020 17:59:49 +0200 (CEST) X-Miltered: at korolev with ID 5F1EF9F5.008 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5F1EF9F5.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F1EF9F5.008 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5F1EF9F5.003 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5F1EF9F5.008 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5F1EF9F5.003 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Information model: fast-convergence 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, 27 Jul 2020 16:00:04 -0000 Dear all, Barbara proposed a switch called (if memory serves) "fast-convergence" that is essentially a macro that changes the values of a number of parameters to values that make convergence faster at the cost of higher overhead. More exactly, the followng values are influenced by it: - Hello Interval; - IHU Interval; - Update Interval; - IHU Hold Time; - Route Expiry Time. It is my opinion that this switch should not be added. First of all, the values given in Appendix B of 6126bis are just examples; the protocol is robust enough to function with a wide range of parameters, and I expect implementations to use different sets of parameters in different kinds of networks. (The only reason they appear as "recommended defaults" is because some IESG members appear to be unable or unwilling to accept the notion of a robust algorithm. Please ignore this recommendation, and experiment with the values most suitable in your particular network. You will probably find out that only the Hello Interval matters, and that the algorithm compensates for all of the other values.) Second, the switch was inspired by an alternative set of parameters in Appendix B of 6126bis. This was introduced during a lengthy and confused discussion with Mirja Kuehlewind, and it was removed when it turned out that this was not what Mirja wanted in the end. It is no longer present in -17, which is the latest published version of the draft. Third, by being a macro, the parameter makes the information model redundant. Thuos, it is not clear what an implementation should announce if its parmeterxes are set to values that don't match either the default nor the fast convergece set. I now recall why we made the other parameters read-only: it is perfectly legal for an implementation to tweak them dynamically, depending on network conditions or other data (such as battery load). Thus, it is not clear that it makes sense to make them read-write. The same argument applies to the proposed "fast-convergence" switch. Thus, it is my opinion that such a switch should not be added to the information model. -- Juliusz From nobody Mon Jul 27 09:56:08 2020 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 C98873A0F9E for ; Mon, 27 Jul 2020 09:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 RMGvduwyAyRr for ; Mon, 27 Jul 2020 09:56:01 -0700 (PDT) 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 155513A0F9A for ; Mon, 27 Jul 2020 09:56:00 -0700 (PDT) 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=1595868956; bh=YctfbBhHeCAwU6N3dgLGbTJvp4vX1KhZ4OeGUpf9X/E=; h=From:To:Subject:In-Reply-To:References:Date:From; b=uFZI/AsFVzbYk7CX8sXHZV4q6RaosDzTeu5LOWioVSx39/z5dVxb28JHGQLBdBsGE SLjuoAtjqzcSGq9imfrDBt6XPWzwKUddv1CiR/MlzzpyHAFXhKSVjD2EExWa4qBoxb HcYx6tcFdevi14+hMz5qyO+Jj1Vb8p1SKzTQonzvILenk/aADvCyahpI7L7bl6FiQE 2jetAMFYAHMrGp8f4SlS1YWl3tPsg4evCrZhlcrvnR0lo6a7ytObNT36pX02jSxwzO zSmhPe9rZGnjr9U2Y2agePqSQdtKkigDSgBSfkNmOb5vlt/UwhVb+rsHzFftPvzn0e vge0r5rXv6oXA== To: Juliusz Chroboczek , babel@ietf.org In-Reply-To: <874kptx823.wl-jch@irif.fr> References: <874kptx823.wl-jch@irif.fr> Date: Mon, 27 Jul 2020 18:55:55 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87y2n4523o.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Information model: fast-convergence 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, 27 Jul 2020 16:56:05 -0000 Juliusz Chroboczek writes: > Dear all, > > Barbara proposed a switch called (if memory serves) "fast-convergence" > that is essentially a macro that changes the values of a number of > parameters to values that make convergence faster at the cost of higher > overhead. More exactly, the followng values are influenced by it: > > - Hello Interval; > - IHU Interval; > - Update Interval; > - IHU Hold Time; > - Route Expiry Time. > > It is my opinion that this switch should not be added. > > First of all, the values given in Appendix B of 6126bis are just examples; > the protocol is robust enough to function with a wide range of parameters, > and I expect implementations to use different sets of parameters in > different kinds of networks. (The only reason they appear as "recommended > defaults" is because some IESG members appear to be unable or unwilling to > accept the notion of a robust algorithm. Please ignore this recommendation, > and experiment with the values most suitable in your particular network. > You will probably find out that only the Hello Interval matters, and that > the algorithm compensates for all of the other values.) > > Second, the switch was inspired by an alternative set of parameters in > Appendix B of 6126bis. This was introduced during a lengthy and confused > discussion with Mirja Kuehlewind, and it was removed when it turned out > that this was not what Mirja wanted in the end. It is no longer present > in -17, which is the latest published version of the draft. > > Third, by being a macro, the parameter makes the information model > redundant. Thuos, it is not clear what an implementation should announce > if its parmeterxes are set to values that don't match either the default > nor the fast convergece set. > > I now recall why we made the other parameters read-only: it is perfectly > legal for an implementation to tweak them dynamically, depending on > network conditions or other data (such as battery load). Thus, it is not > clear that it makes sense to make them read-write. The same argument > applies to the proposed "fast-convergence" switch. > > Thus, it is my opinion that such a switch should not be added to the > information model. I would tend to agree with your reasoning and conclusion. -Toke From nobody Mon Jul 27 11:55:20 2020 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 82FCF3A1C9D for ; Mon, 27 Jul 2020 11:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 iggdHJZDli8t for ; Mon, 27 Jul 2020 11:55:09 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 9DB913A1CF7 for ; Mon, 27 Jul 2020 11:54:59 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id j22so3689889lfm.2 for ; Mon, 27 Jul 2020 11:54:59 -0700 (PDT) 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=NnAejA6pYcCqM/orMkI7J77y0H+DkfeYBYBLl+jL9Oo=; b=nb+YqX5aWdgXpYGl0qFMmmzYtYMLOQuYyUg6T12nksrmVSBsPuqdSABMdXclzkbLKp 636APCJmqQP70wn+Z5Szw9XA5RF7EXZOIAutygiRSfwEXSoHWdeNz5uYz7ULP91Mhsyf 62j832mkYA0MhtZ49kXbHuWT7ZLo0kd9kanZwYLOorBZeVdibcracZis2A1Q66lIGoSh 5Lft9KNmPvRPTi9aMGdp82t6rTCRrDTeluUHJXx/CbPThT064DBD8aNVIBzdDiPkT8/I grX8TOCnF8ATzrKSAlf+mZzQgICGSh7FlVw3snXrydqp/bKRK2IsC/FrT/7XErF3nf3O Eo7w== 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=NnAejA6pYcCqM/orMkI7J77y0H+DkfeYBYBLl+jL9Oo=; b=c3mpie0779Qmw3G/VYJS3TrvZY1a5qtaVGUFbxxjf3a+BInqcbaJEW0tsJlJMEOw5m anzACAKehUGNqwUH80Yxe6oJyZ3z0PcM7wkNFLmiZaPE3DuSXowP0LlHLBferJj6N6ek fvXn8mGMCUdifpGWKwdslR76NkgmLTktJ5Mp73QDUM4+Cy2QizaQC6kj+wp89r39T3RS m2EmSO3GCRK45VNeEyJnC9Ffa66k8u3IGpjwKGsEpgnyWj3UPVxWNQ6gxMI3VQXtTnKS /FvPNU2Td0EQVGN7zoG2uhfneBWHJDG3VZvjuujCqIcecl1kELO/yoOLkjJuTfoj5RoZ ElwA== X-Gm-Message-State: AOAM531n84d/un9v5f1uiLnFGSnpvXTOx4elTGSDjQj5QOLjUBKV5Auj iZoIDHWt43n+KfxAXNzZn2OirdWcG0xTovYJtlA= X-Google-Smtp-Source: ABdhPJxnfSv51ADgjqXaQjpsqmGi5PWl5XJGCfTW8rNb7L2XCBkI3kSaQO6+WO5QZaIn10H/U8so8190FMzbJHfWmYc= X-Received: by 2002:a19:8705:: with SMTP id j5mr12287141lfd.122.1595876097571; Mon, 27 Jul 2020 11:54:57 -0700 (PDT) MIME-Version: 1.0 References: <5ae89f16-c996-c928-c935-0dbdf22760e0@ens.fr> <736B4827-1031-4054-BC0E-56B169114B1A@painless-security.com> In-Reply-To: <736B4827-1031-4054-BC0E-56B169114B1A@painless-security.com> From: David Schinazi Date: Mon, 27 Jul 2020 11:54:46 -0700 Message-ID: To: Margaret Cullen Cc: =?UTF-8?Q?Th=C3=A9ophile_Bastian?= , Babel at IETF Content-Type: multipart/alternative; boundary="000000000000e6c21805ab70db9f" Archived-At: Subject: Re: [babel] v4-via-v6: what about ICMPv4? 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, 27 Jul 2020 18:55:18 -0000 --000000000000e6c21805ab70db9f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 1) I like "via", it's more accurate than "over" 2) ICMP Allow me to paraphrase what's already been said to make sure I understand the problem correctly. The topology is: A --- B --- C --- D --- E and every node is dual-stacked except C who doesn't have an IPv4 address. A is sending IPv4 packets to E, with the DontFragment bit set, and using the full MTU for A --- B. scenario a) D --- E has a lower MTU than all the other links, so it'll send ICMP to A's IPv4 address, and that should work fine because to C this just looks like any other IPv4 packet addressed to A. scenario b) C --- D has a lower MTU than all the other links, and C realizes that it won't be able to forward this IPv4 packet because it's too big. We know that C has some notion of IPv4 even though it's not provisioned with an IPv4 address. So, couldn't we just say that C SHOULD send ICMP using a bogus source IPv4 address? If C doesn't want to implement ICMPv4, then it just silently drops the packet. In practice ICMP isn't reliable over the Internet today, so modern protocols have mechanisms for PMTUD that can survive ICMP blackholing. All this to say that I think we should address this in the draft, but I don't think it's a dealbreaker. David On Mon, Jul 27, 2020 at 8:27 AM Margaret Cullen < margaret@painless-security.com> wrote: > > Does this imply that if network AB had a higher MTU than network CD, larg= e > IPv4 packets from network AB with the DF (don=E2=80=99t fragment) bit set= would > black-holed by router C? > > I need to go refresh my memory of IPv4 MTU discovery to know what issues > (if any) that would cause... > > > > > On Jul 27, 2020, at 11:15 AM, Th=C3=A9ophile Bastian < > theophile.bastian@ens.fr> wrote: > > > > =EF=BB=BF > >> > >>> What happens if you run traceroute over your test v4-over-v6 setup? > > > > In this topology: > > > > A --- B --- C --- D --- E > > 4 4 4 4 > > > > I get > > > > # tracepath 10.132.4.5 > > 1?: [LOCALHOST] pmtu 1500 > > 1: ??? 0.089ms > > 1: ??? 0.083ms > > 2: no reply > > 3: ??? 0.154ms > > 4: ??? 0.149ms reach= ed > > Resume: pmtu 1500 hops 4 back 4 > > > > while trying a tracepath from A to E. > > > > -- > > Th=C3=A9ophile Bastian > > > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://www.ietf.org/mailman/listinfo/babel > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --000000000000e6c21805ab70db9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
1) I like "via", it's more accurate than &qu= ot;over"

2) ICMP
Allow me to paraphrase w= hat's already been
said to make sure I understand the problem= correctly.
The topology is:=C2=A0A --- B --- C --- D --- E
=
and every node is dual-stacked except C who doesn't
have= an IPv4 address. A is sending IPv4 packets to E,
with the DontFr= agment bit set, and using the full MTU
for A --- B.
scenario=C2=A0a) D --- E has a lower MTU than all the other lin= ks,
so it'll send ICMP to A's IPv4 address, and that shou= ld work
fine because to C this just looks like any other IPv4 pac= ket
addressed to A.

scenario b) C --- D = has a lower MTU than all the other links,
and C realizes that it = won't be able to forward this IPv4 packet
because it's to= o big. We know that C has some notion of IPv4
even though it'= s not provisioned with an IPv4 address. So,
couldn't we just = say that C SHOULD send ICMP using a bogus
source IPv4 address? If= C doesn't want to implement ICMPv4,
then it just silently dr= ops the packet. In practice ICMP isn't
reliable over the Inte= rnet today, so modern protocols have
mechanisms for PMTUD that ca= n survive ICMP blackholing.
All this to say that I think we shoul= d address this in the draft,
but I don't think it's a dea= lbreaker.

David


On Mon, Jul 27= , 2020 at 8:27 AM Margaret Cullen <margaret@painless-security.com> wrote:

Does this imply that if network AB had a higher MTU than network CD, large = IPv4 packets from network AB with the DF (don=E2=80=99t fragment) bit set w= ould black-holed by router C?=C2=A0

I need to go refresh my memory of IPv4 MTU discovery to know what issues (i= f any) that would cause...



> On Jul 27, 2020, at 11:15 AM, Th=C3=A9ophile Bastian <theophile.bastian@ens.fr> wrote:
>
> =EF=BB=BF
>>
>>> What happens if you run traceroute over your test v4-over-v6 s= etup?
>
> In this topology:
>
> A --- B --- C --- D --- E
> 4=C2=A0 =C2=A04=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04=C2=A0= =C2=A04
>
> I get
>
> # tracepath 10.132.4.5
> 1?: [LOCALHOST]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 pmtu 1500
> 1:=C2=A0 ???=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.089ms
> 1:=C2=A0 ???=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.083ms
> 2:=C2=A0 no reply
> 3:=C2=A0 ???=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.154ms
> 4:=C2=A0 ???=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.149ms reached
>=C2=A0 =C2=A0 =C2=A0Resume: pmtu 1500 hops 4 back 4
>
> while trying a tracepath from A to E.
>
> --
> Th=C3=A9ophile Bastian
>
> _______________________________________________
> babel mailing list
> babel@ietf.org=
> https://www.ietf.org/mailman/listinfo/babel

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--000000000000e6c21805ab70db9f-- From nobody Mon Jul 27 13:23:39 2020 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 737ED3A0BAC; Mon, 27 Jul 2020 13:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 PIxpoQBZjobh; Mon, 27 Jul 2020 13:23:36 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 DC2693A0BAB; Mon, 27 Jul 2020 13:23:35 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id l17so4028780ilq.13; Mon, 27 Jul 2020 13:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=9aPsJoO0j5wiVCfz1gb8WxwEGGurZPg1ZcPD1IatzkA=; b=pufy/xDE1yIhBLOEwKHsg0BU1pCPkc4W8ulI1BMAD7XHlMMilOyqLXW25/8Th0E7i/ EOGjtkb1MUXoA20oPYN9WnCloRmqxuCpSQjbWJqdKILJRuhc5bzW9f7X4UFLFizUwGLH y1LA1t8EnPeJfoz1ixbPa0tW4yChugJ41eIjZLYIxdwQY02iG+f37eBWR/MFSv2F5Q7/ o4q5cPFhQTMJ7DVWIFJqh8avqidYVGvKsenBFT0Y9Nj+P/K/XMnn0GPc+s6J9Xn6a/07 VBPaQ7syWKnrW8Y407VMM+WOrWvFf8w7vrcHj1tA98G8ADr4HAfLbBJQAc7p264+lT/s fIEQ== 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:cc; bh=9aPsJoO0j5wiVCfz1gb8WxwEGGurZPg1ZcPD1IatzkA=; b=UOJvo68miYIfTe2TnyhzkC9wcNoC9NvKZyQhFqCqReLjjE2QhbcEAGOvL76oCPF0SO +VJuVC4KlJ8tms+/SnPrXWEnP9nBGTqiEhIzJwKuHE8ttstwtZQ+8mxsqXmRDc9ee0yP GOwsAsicN73FhbuXRPbCIDhkxbAAJCw+NeQbJnvFBS09RE3gX20dFtuxIUUNanALq1VA c3gl3aNjTfgwfNL16gBB3ErZ7P1Tw9/v6eTu5I6yLUYEChSvbo7x1SylVs6Zz0Y7TjaE M9iFPzgt/7U1OFbp9oD/v1dHZ6DtCMt2Ct7J9+zYeZcQwmTtnDc9mYXSR+g9Q3HHmXvV B2Ew== X-Gm-Message-State: AOAM533jWu5BICQKPbpVjvczZfnif+4mKaqXw/A0JvG5+qABXRSzWVZz nq91FSA81hGSS7ax89wNM2aGiagjH+LqWgYy610xmHuRK3E= X-Google-Smtp-Source: ABdhPJzoZLH26Er44hsg7NzTpIq27F77za00cUkZQ6Ez6mA77axoSvoXBhwLwbDUN2O7N/qvQxJno6emIdgeKqzqMWY= X-Received: by 2002:a92:c78c:: with SMTP id c12mr16686941ilk.199.1595881414429; Mon, 27 Jul 2020 13:23:34 -0700 (PDT) MIME-Version: 1.0 From: Donald Eastlake Date: Mon, 27 Jul 2020 16:23:23 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [babel] Draft Babel WG Meeting Minutes 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, 27 Jul 2020 20:23:38 -0000 Hi, Draft minutes of the Babel WG meeting are at https://www.ietf.org/proceedings/108/minutes/minutes-108-babel-00 Thanks to Gabriel Kerneis who took the initial notes. Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com From nobody Mon Jul 27 15:23:37 2020 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 BEE653A08E4; Mon, 27 Jul 2020 15:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 IId9HejnQc5r; Mon, 27 Jul 2020 15:23:31 -0700 (PDT) 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 029773A08F8; Mon, 27 Jul 2020 15:23:27 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 06RMNFjO045726; Mon, 27 Jul 2020 18:23:27 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 32gg6j4fbn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jul 2020 18:23:26 -0400 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 06RMNQY8004516; Mon, 27 Jul 2020 18:23:26 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 06RMNLqA004427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Jul 2020 18:23:21 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 3ECFD4009E62; Mon, 27 Jul 2020 22:23:21 +0000 (GMT) Received: from GAALPA1MSGEX1CA.ITServices.sbc.com (unknown [135.50.89.108]) by zlp30484.vci.att.com (Service) with ESMTPS id 283B44009E60; Mon, 27 Jul 2020 22:23:21 +0000 (GMT) Received: from GAALPA1MSGEX1CB.ITServices.sbc.com (135.50.89.109) by GAALPA1MSGEX1CA.ITServices.sbc.com (135.50.89.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Mon, 27 Jul 2020 18:23:20 -0400 Received: from GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) by GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) with mapi id 15.01.2044.004; Mon, 27 Jul 2020 18:23:20 -0400 From: "STARK, BARBARA H" To: =?iso-8859-1?Q?=27Toke_H=F8iland-J=F8rgensen=27?= , "'Juliusz Chroboczek'" , "'babel@ietf.org'" Thread-Topic: [babel] Information model: fast-convergence Thread-Index: AQHWZC8IzOVFj2MvSUCk1EUbNccHN6kb6EWAgAAYK7A= Date: Mon, 27 Jul 2020 22:23:20 +0000 Message-ID: References: <874kptx823.wl-jch@irif.fr> <87y2n4523o.fsf@toke.dk> In-Reply-To: <87y2n4523o.fsf@toke.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.89.35] x-tm-snts-smtp: 802D7EF239AB86DA990A99A91A8929BBA45B35CF0456CB44A59BA527591E3B872 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-27_15:2020-07-27, 2020-07-27 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 malwarescore=0 clxscore=1011 suspectscore=0 bulkscore=0 impostorscore=0 phishscore=0 priorityscore=1501 spamscore=0 adultscore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007270149 Archived-At: Subject: Re: [babel] Information model: fast-convergence 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, 27 Jul 2020 22:23:34 -0000 Thanks y'all. I'm comfortable with your responses and will close that out. Barbara > -----Original Message----- > From: babel On Behalf Of Toke H=F8iland- > J=F8rgensen > Sent: Monday, July 27, 2020 11:56 AM > To: Juliusz Chroboczek ; babel@ietf.org > Subject: Re: [babel] Information model: fast-convergence >=20 > Juliusz Chroboczek writes: >=20 > > Dear all, > > > > Barbara proposed a switch called (if memory serves) "fast-convergence" > > that is essentially a macro that changes the values of a number of > > parameters to values that make convergence faster at the cost of higher > > overhead. More exactly, the followng values are influenced by it: > > > > - Hello Interval; > > - IHU Interval; > > - Update Interval; > > - IHU Hold Time; > > - Route Expiry Time. > > > > It is my opinion that this switch should not be added. > > > > First of all, the values given in Appendix B of 6126bis are just exampl= es; > > the protocol is robust enough to function with a wide range of paramete= rs, > > and I expect implementations to use different sets of parameters in > > different kinds of networks. (The only reason they appear as > "recommended > > defaults" is because some IESG members appear to be unable or unwilling > to > > accept the notion of a robust algorithm. Please ignore this > recommendation, > > and experiment with the values most suitable in your particular network= . > > You will probably find out that only the Hello Interval matters, and th= at > > the algorithm compensates for all of the other values.) > > > > Second, the switch was inspired by an alternative set of parameters in > > Appendix B of 6126bis. This was introduced during a lengthy and confus= ed > > discussion with Mirja Kuehlewind, and it was removed when it turned out > > that this was not what Mirja wanted in the end. It is no longer presen= t > > in -17, which is the latest published version of the draft. > > > > Third, by being a macro, the parameter makes the information model > > redundant. Thuos, it is not clear what an implementation should announ= ce > > if its parmeterxes are set to values that don't match either the defaul= t > > nor the fast convergece set. > > > > I now recall why we made the other parameters read-only: it is perfectl= y > > legal for an implementation to tweak them dynamically, depending on > > network conditions or other data (such as battery load). Thus, it is n= ot > > clear that it makes sense to make them read-write. The same argument > > applies to the proposed "fast-convergence" switch. > > > > Thus, it is my opinion that such a switch should not be added to the > > information model. >=20 > I would tend to agree with your reasoning and conclusion. >=20 > -Toke >=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=3Dg2rVU1U-LEyG- > WHR5Fg6R7KWViUSggfrgxfvCTLIQMA&s=3DMPVW3N71R2of- > pMbpPYvrk7QGd40ZIqVBryhCAGuPeY&e=3D From nobody Tue Jul 28 09:26:25 2020 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 059AD3A0E98 for ; Tue, 28 Jul 2020 09:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XNbbrXDJq-VD for ; Tue, 28 Jul 2020 09:26:22 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB5C3A0E99 for ; Tue, 28 Jul 2020 09:26:21 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 06SGQJpI023467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Jul 2020 18:26:19 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 06SGQJg0007574; Tue, 28 Jul 2020 18:26:19 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 890DFB1DF0; Tue, 28 Jul 2020 18:26:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 2nuH8BDaJ5C0; Tue, 28 Jul 2020 18:26:18 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3C17FB1DEE; Tue, 28 Jul 2020 18:26:18 +0200 (CEST) Date: Tue, 28 Jul 2020 18:26:17 +0200 Message-ID: <877dunip1y.wl-jch@irif.fr> From: Juliusz Chroboczek To: "Velt, R. (Ronald) in 't" CC: babel@ietf.org, babel-users@lists.alioth.debian.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 28 Jul 2020 18:26:19 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 28 Jul 2020 18:26:19 +0200 (CEST) X-Miltered: at korolev with ID 5F2051AB.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5F2051AB.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F2051AB.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5F2051AB.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 : 5F2051AB.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5F2051AB.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: [babel] About Babel-RTT 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, 28 Jul 2020 16:26:24 -0000 Dear Ronald, [Both Babel MLs in CC] At the WG meeting, you asked about the future of the Babel-RTT draft. The protocol extension isn't going away. It's been used in production for many years at Nexedi, where it works beautifully. No other production-quality routing protocol known to me has this kind of automation. As to the draft, the situation is somewhat less good. Baptiste Jonglez, who did the initial implementation, does not appear to be interested in working on the subject. The current draft merely describes the packet format, it doesn't fully describe the algorithms needed to make it work well. As to the algorithms, we did determine experimentally that they work well, but we haven't been able to get a satisfactory theoretical explanation of why that is the case. So in order to make it into a peer-reviewed paper or an internet-draft, I would need help from a competent dynamic systems theorist. Any help with that would be welcome. -- Juliusz From nobody Tue Jul 28 10:08:21 2020 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 41A543A0EC9 for ; Tue, 28 Jul 2020 10:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 v99iWs_GqC5X for ; Tue, 28 Jul 2020 10:08:18 -0700 (PDT) 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 C64803A0EC8 for ; Tue, 28 Jul 2020 10:08:17 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id q7so21973388ljm.1 for ; Tue, 28 Jul 2020 10:08:17 -0700 (PDT) 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=TmjTtU+pPapbJ7JKmMaSiCBY/NRUJXDuhTJEW3C6d5g=; b=PVYMXol8obKFzF7RoUMBsoRC52/DaFfz3TinMDrS3ZnyOUVO1OmzyvRt/U1/QTExxe GyDfqUpwvvW1YgCFU+vQ2nOfgR/w/uIBCQFVs2BFmSUJ/E8WIxtHAmspDGf46AQ0onQY i1hiCcydtuwGPlq/76ANinLkD/m8suB8mP3Y/3VfZnUUWgSaxYAO2Sh6LBalCGzFu9k0 4DG+RcFHpNIX+v0z80m1DGvyGQZ9sFpkTi6PAxooVmv9FNIi8Mzr48pXzt+dhAxjtXtx 2uhqTq0GNPOFTybdnQJBG3SB/paG5a4hgMS06oGy58bELGvtfF1T/kfdNPZwtWTdl7IR 9UOw== 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=TmjTtU+pPapbJ7JKmMaSiCBY/NRUJXDuhTJEW3C6d5g=; b=aqW4GkW07LfWJimCPMZYRoR3MtaXFfZPf0mSAvBpsi2wxv2P1SpXsHwvSxzK4W7oCJ 5djvjdlSl48nz4EewDd0JGK0/m9oBBprEhuFTqhww7KOeY5aGvRcq0/TOmsTPr/ly4oI 5kVN45LIsjOSpMMKEK+MMjIcwMHNIBOe41hBTwOn2oT56+cnz+xaeKGDsPr026ZyKJcm TBWFbMChAnIlo8gN7yJQlvNkoEq9VdJKSvoPX2gq0W4hhhhNEK1bDihEPsJYNiAEYduE XKlu+8Tj5723W7gLTo/RzmfFkPgcDIcoxNfhB8eQqaGNXLrmm/pW6ybZZqBBiBs84OKb e6tw== X-Gm-Message-State: AOAM533mqbVwUqt5DNvG/wTjPl3X56Nsigngrtkon50dK+FAWeia3ODB FOzxtq2E/MrgNExRcvHeXo3fR2MnEArvgy2Y9SQ= X-Google-Smtp-Source: ABdhPJzUaMQCsOWIEa57aDNSg4ksAXBWq6uFhmBNvcFOFwM2QkhXqkLRmL2EepFKLLKRSW/KtrBPVSTqCIZ9ibp6beM= X-Received: by 2002:a2e:161a:: with SMTP id w26mr13130235ljd.216.1595956095644; Tue, 28 Jul 2020 10:08:15 -0700 (PDT) MIME-Version: 1.0 References: <877dunip1y.wl-jch@irif.fr> In-Reply-To: <877dunip1y.wl-jch@irif.fr> From: David Schinazi Date: Tue, 28 Jul 2020 10:08:04 -0700 Message-ID: To: Juliusz Chroboczek Cc: "Velt, R. (Ronald) in 't" , babel-users , Babel at IETF Content-Type: multipart/alternative; boundary="00000000000028787a05ab837cb2" Archived-At: Subject: Re: [babel] [Babel-users] About Babel-RTT 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, 28 Jul 2020 17:08:20 -0000 --00000000000028787a05ab837cb2 Content-Type: text/plain; charset="UTF-8" I'll note that while a theoretical explanation/study sounds interesting, it's not required for publication of an IETF document. The fact that there is a real-world deployment of this technology is much more useful to me than whether or not it's theoretically sound. So I'd be in favor of advancing the document without the theoretical analysis, if someone has the time to document the "algorithms needed to make it work well" in the draft. Note that I do not qualify as a "competent dynamic systems theorist", I am merely an engineer that likes protocols that work, like Babel :-) David On Tue, Jul 28, 2020 at 9:26 AM Juliusz Chroboczek wrote: > Dear Ronald, > > [Both Babel MLs in CC] > > At the WG meeting, you asked about the future of the Babel-RTT draft. > > The protocol extension isn't going away. It's been used in production for > many years at Nexedi, where it works beautifully. No other > production-quality > routing protocol known to me has this kind of automation. > > As to the draft, the situation is somewhat less good. Baptiste Jonglez, > who did the initial implementation, does not appear to be interested in > working on the subject. The current draft merely describes the packet > format, it doesn't fully describe the algorithms needed to make it work > well. As to the algorithms, we did determine experimentally that they > work well, but we haven't been able to get a satisfactory theoretical > explanation of why that is the case. > > So in order to make it into a peer-reviewed paper or an internet-draft, > I would need help from a competent dynamic systems theorist. Any help > with that would be welcome. > > -- Juliusz > > _______________________________________________ > Babel-users mailing list > Babel-users@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users --00000000000028787a05ab837cb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'll note that while a theoretical explanation/study s= ounds interesting,
it's not required for publication of an IETF doc= ument. The fact that
there is a real-world deployment of this tec= hnology=C2=A0is much more
useful to me than whether or not it'= ;s theoretically sound. So I'd be
in favor of advancing the d= ocument without the theoretical analysis,
if someone has the time= to document the "algorithms needed to
make it work well&quo= t; in the draft.

Note that I do not qualify as a &= quot;competent dynamic systems theorist",
I am merely an eng= ineer that likes protocols that work, like Babel :-)

David

On Tue, Jul 28, 2020 at 9:26 AM Juliusz Chroboczek <jch@irif.fr> wrote:
Dear Ronald,

[Both Babel MLs in CC]

At the WG meeting, you asked about the future of the Babel-RTT draft.

The protocol extension isn't going away.=C2=A0 It's been used in pr= oduction for
many years at Nexedi, where it works beautifully.=C2=A0 No other production= -quality
routing protocol known to me has this kind of automation.

As to the draft, the situation is somewhat less good.=C2=A0 Baptiste Jongle= z,
who did the initial implementation, does not appear to be interested in
working on the subject.=C2=A0 The current draft merely describes the packet=
format, it doesn't fully describe the algorithms needed to make it work=
well.=C2=A0 As to the algorithms, we did determine experimentally that they=
work well, but we haven't been able to get a satisfactory theoretical explanation of why that is the case.

So in order to make it into a peer-reviewed paper or an internet-draft,
I would need help from a competent dynamic systems theorist.=C2=A0 Any help=
with that would be welcome.

-- Juliusz

_______________________________________________
Babel-users mailing list
Ba= bel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/= cgi-bin/mailman/listinfo/babel-users
--00000000000028787a05ab837cb2-- From nobody Tue Jul 28 10:55:45 2020 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 B83B43A0A9F for ; Tue, 28 Jul 2020 10:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 m8Akx9EuNjld for ; Tue, 28 Jul 2020 10:55:42 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37CA3A0A98 for ; Tue, 28 Jul 2020 10:55:41 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 06SHtc1U017025; Tue, 28 Jul 2020 19:55:38 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C5836B2314; Tue, 28 Jul 2020 19:55:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id RXnTvJnFhkJC; Tue, 28 Jul 2020 19:54:30 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 81007B22F2; Tue, 28 Jul 2020 19:54:30 +0200 (CEST) Date: Tue, 28 Jul 2020 19:54:30 +0200 Message-ID: <87wo2nwmnd.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Babel at IETF , babel-users , "Velt,\ R. (Ronald) in 't" In-Reply-To: References: <877dunip1y.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, 28 Jul 2020 19:55:38 +0200 (CEST) X-Miltered: at korolev with ID 5F20669A.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F20669A.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 : 5F20669A.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] [Babel-users] About Babel-RTT 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, 28 Jul 2020 17:55:44 -0000 > I'll note that while a theoretical explanation/study sounds interesting, > it's not required for publication of an IETF document. In my opinion, without a theoretical understanding, it is difficult to provide adequate guidance to implementers. We have a deep theoretical understanding of what makes Babel work. This is why we can say with confidence that implementations MUST evaluate the feasibility condition and that the metric MUST be stricly monotonic, but we can safely leave the details of the route selection algorithm to the implementation. Not so with Babel-RTT. We've got an implementation that has been shown to work, but we have no precise ide which parts of the implementation are important and which are coincidental. In this situation, I don't feel confident to write up a protocol description. -- Juliusz From nobody Tue Jul 28 11:09:47 2020 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 E54BD3A0AA5 for ; Tue, 28 Jul 2020 11:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7hZJeQaqS_4k for ; Tue, 28 Jul 2020 11:09:42 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771673A0A0B for ; Tue, 28 Jul 2020 11:09:42 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 06SI9eTm020765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Jul 2020 20:09:40 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 06SI9eg3031917; Tue, 28 Jul 2020 20:09:40 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 7B2A1B238B; Tue, 28 Jul 2020 20:09:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 94mKmHEHKzrM; Tue, 28 Jul 2020 20:09:39 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 49418B2389; Tue, 28 Jul 2020 20:09:39 +0200 (CEST) Date: Tue, 28 Jul 2020 20:09:39 +0200 Message-ID: <87tuxrwly4.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: "Velt, R. (Ronald) in 't" , babel-users , Babel at IETF In-Reply-To: <87wo2nwmnd.wl-jch@irif.fr> References: <877dunip1y.wl-jch@irif.fr> <87wo2nwmnd.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 [IPv6:2001:660:3301:8000::1:2]); Tue, 28 Jul 2020 20:09:40 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 28 Jul 2020 20:09:40 +0200 (CEST) X-Miltered: at korolev with ID 5F2069E4.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5F2069E4.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F2069E4.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5F2069E4.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 : 5F2069E4.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5F2069E4.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] [Babel-users] About Babel-RTT 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, 28 Jul 2020 18:09:45 -0000 > In my opinion, without a theoretical understanding, it is difficult to > provide adequate guidance to implementers. Since I'm in a chatty mood, I'll give another example. While both RFC 2328 and Moy's book are written in a very simple engineering style, there is some reasonably solid theory behind OSPF, which at least some OSPF specialists don't appear to fully appreciate. For example, the topological restrictions on area adjacency are pretty much the weakest conditions that avoid counting to infinity, and the extreme care given to the flooding subprotocol indicates a good understanding of the consequences of desynchronised LSDBs. I'm deeply convinced that there is no such thing as sound engineering without a solid theoretical base. -- Juliusz From nobody Tue Jul 28 14:40:19 2020 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 379003A08EC for ; Tue, 28 Jul 2020 14:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 299quErHzS4M for ; Tue, 28 Jul 2020 14:40:15 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 E86FF3A0807 for ; Tue, 28 Jul 2020 14:40:01 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id l17so7349538ilq.13 for ; Tue, 28 Jul 2020 14:40:01 -0700 (PDT) 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=gJUXfj2n8EwEZ4rFbzyZAtPgDY/m7x1RrNU+LZRdnOI=; b=kjFJzjQrmetAC9W+H0J+yBrSkxMAObHnarS7Lbxd8cEk7rl+zp3hbJ+u9tYrXwjzyk Jgt0DyYYVOE2VQIH9PRaiGRrFmrwDKR4nMaD6hC3rLtDnEZz2/5RQtI4B/JQieva14eK R7tauazvibmH6HD8TBTQHIE1ryNYv+YG3edfCuqQiDwwbqo6ecGjx63uyUWpb0w8acNY wgubi4JbNG6QaPQE12gPFj86PsTu45eZL5eM0PV++4qFPKNKUil0iBMSBq1zjswb1HYe PyQa59yI6A7uiFIKPaSvxTxoqQ36ljHME/359yVuh0TjynbFccDwFFFa2NgSqxwEgcbP PiEQ== 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=gJUXfj2n8EwEZ4rFbzyZAtPgDY/m7x1RrNU+LZRdnOI=; b=myaJhR4RxeVgHyeUCj/kc8wQVsG3XtqUCYBsqnkhhGisP+6kwv4HkVK0SlrJ+jtyYf 0HDCxX7w0zCkNiS71lkeZtkfSlVFWdJYpwmUFHRE4tc9UJ7w6XdKiqmYbQ73/CDygBhj bR3H8DYMu9wJOjJQ5MpXUUtnsX9a6fbqwLy+9pQExldXhqGjRy+JwoZ4wF1zV6aTTWhG /9E2++QuejstUz5j6NeXAId/vp1qR1it8OT/dkNbzqznu9hyHKYlB8GAIlOhSyiqB+6V LvwXJxnMQDC1enYapqE3+dKmIFatpMR5bedhWpYSL2KSstib7xnEd+sNnDSdpDknIw8E fGNw== X-Gm-Message-State: AOAM530Gj1CXGIc19iDdS4sozydo21SqAIVYssqd9oytMIstGgevdocL XWunNlakt4tZ0NUPrAnaQRd9PNdDXgej1K5SkoL+FruheMs= X-Google-Smtp-Source: ABdhPJxHs2NWx2ZcqL+PtyIEb4SDkwNhn2OiZJ+txBijSF5TqbcmCK973D3ttTFMPBOBYp9tym2aUWI76FaJwRVDZwY= X-Received: by 2002:a05:6e02:f07:: with SMTP id x7mr19536322ilj.40.1595972401154; Tue, 28 Jul 2020 14:40:01 -0700 (PDT) MIME-Version: 1.0 References: <874kptx823.wl-jch@irif.fr> In-Reply-To: <874kptx823.wl-jch@irif.fr> From: Donald Eastlake Date: Tue, 28 Jul 2020 17:39:49 -0400 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] Information model: fast-convergence 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, 28 Jul 2020 21:40:17 -0000 Hi, On Mon, Jul 27, 2020 at 12:00 PM Juliusz Chroboczek wrote: > > Dear all, > > Barbara proposed a switch called (if memory serves) "fast-convergence" > that is essentially a macro that changes the values of a number of > parameters to values that make convergence faster at the cost of higher > overhead. ... > > It is my opinion that this switch should not be added. Speaking as a WG member, I agree. > First of all, the values given in Appendix B of 6126bis are just examples; > the protocol is robust enough to function with a wide range of parameters, > and I expect implementations to use different sets of parameters in > different kinds of networks. (The only reason they appear as "recommended > defaults" is because some IESG members appear to be unable or unwilling to > accept the notion of a robust algorithm. I do not think it has anything to do with non-acceptance of algorithm robustness. I believe their thought process is more or less as follows: If a parameter makes no difference, then it shouldn't be called out at all or should just have a fixed value. If a parameter does make a difference then, while this might not apply to informational or experimental or research documents, for a protocol standard there should be a recommended value or a method for determining a recommended value. As an example I recently saw, look at Section 14 (top of page 16) in https://tools.ietf.org/html/draft-ietf-6tisch-msf-16 (I read this draft because I was asked to review it as a member of the IETF Security Directorate.) That document calls them "constants" rather than "parameters" but it is the same thing and the draft has a table of their RECOMMENDED values. It is what people want and expect in a protocol standard, at least in the IETF and in IEEE 802 where I have the most experience. > Please ignore this recommendation, > and experiment with the values most suitable in your particular network. A recommended value is just that: only a recommendation. Implementations are free to use other values and will still be conformant to the standard. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 33896 USA d3e3e3@gmail.com > ... > > -- Juliusz From nobody Tue Jul 28 17:50:15 2020 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 53D603A0DAE for ; Tue, 28 Jul 2020 17:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GCXmSgSON0Cp for ; Tue, 28 Jul 2020 17:50:11 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194B33A0DAF for ; Tue, 28 Jul 2020 17:50:07 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 06T0o6O4027248; Wed, 29 Jul 2020 02:50:06 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id EEA4EB2F89; Wed, 29 Jul 2020 02:50:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id m0O4uABDB9EL; Wed, 29 Jul 2020 02:50:04 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 8BA12B2F87; Wed, 29 Jul 2020 02:50:04 +0200 (CEST) Date: Wed, 29 Jul 2020 02:50:04 +0200 Message-ID: <87ime7w3er.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake Cc: Babel at IETF In-Reply-To: References: <874kptx823.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 29 Jul 2020 02:50:06 +0200 (CEST) X-Miltered: at korolev with ID 5F20C7BE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F20C7BE.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 : 5F20C7BE.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] Information model: fast-convergence 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, 29 Jul 2020 00:50:14 -0000 >> Please ignore this recommendation, >> and experiment with the values most suitable in your particular network. > A recommended value is just that: only a recommendation. > Implementations are free to use other values and will still be > conformant to the standard. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. This is a quite a bit stronger than what you describe, which is why I attempted to convince the IESG that "example values" should be used instead. I find it unfortunate that I didn't manage to get through. Perhaps we should be using the terminology defined in RFC 6919: 1. MUST (BUT WE KNOW YOU WON'T) The phrase "MUST (BUT WE KNOW YOU WON'T)" is used to indicate requirements that are needed to meet formal review criteria (e.g., mandatory-to-implement security mechanisms), when these mechanisms are too inconvenient for implementers to actually implement. This phrase is frequently used in a contracted form in which the parenthetical is omitted. -- Juliusz From nobody Wed Jul 29 20:24:19 2020 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 648BA3A0C4D for ; Wed, 29 Jul 2020 20:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 cwcr6PoBtLNk for ; Wed, 29 Jul 2020 20:24:15 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 94ED13A0C48 for ; Wed, 29 Jul 2020 20:24:15 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id t15so17897841iob.3 for ; Wed, 29 Jul 2020 20:24:15 -0700 (PDT) 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=OgYIl1DnBq2MxYN11Qm+pRgsVHPGbPrWPo6ZEJmD8j0=; b=QP35IeJ598RkZTGEXNIxxUyKq0QM2sEzMjpUJT5OxK2nRjOsbrYgUTqEPpfDRJ9721 DL1ygNCwzSYwv552SlIpkuhDNOdTxnG3r+Os1VbpDHLe57OmOBJ7G6et3Idbteg6iYao 0bEuYmXslW6o0ixeH9NMNd0SWiorgV+dSGb5yZPMBCVqRhiAFUWbw9yUH86uQCIIWL8M 1clCo5LWsGGuHy3JoQbu9c7F44TnigyJhKz98qjv9TjmQFnsuaxM/dNEbwwK3nLN4q/y w8aEbor/hgOrr8EGCLSitlgXP4vDlJonnCuBGNOHqF9VMv0XPGPuQ+HA9WYRsgOFD4ee Eplw== 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=OgYIl1DnBq2MxYN11Qm+pRgsVHPGbPrWPo6ZEJmD8j0=; b=VR3TKD0lpFpK9tmKHqLHqVdo7oDdlvMED/A61CyAdRo64PWcZ4YDpfRH/b1K9VPruJ niP9+e8GB7VNJWpaVgXakbEhrD+GKGVK0ZA1SDJZc/reO+XwouMmgSfj9IPE+u72tpWM CndEPtQJdmTY/4WctRYWWXfqUHCVo4Nr6REu1MmBbYNo+qQYj/jL7kwAbFyJq4hjX1y5 ejhHFvs0pFaA+WiyN6ajUU6tm/RdS1d9pyTD0yARHLLeYnzsqlTFoa4EvJGpoth1rmIp XGL/DUzIBaPiwEeZX0QrGKtNWlwdd0tcDHXw56tstVYB1LCFuH9ZjRh+n9w5zHpYlj1l PMIg== X-Gm-Message-State: AOAM530dpNGgOnO6++5FQmH0hBgepNn5qEJdk9Enng84zpPBxCUmdTYh UDhldkgx5dY1BzqfWVqSgr8olVgfLUz52XUrEXnjw5iIYxU= X-Google-Smtp-Source: ABdhPJzoAh/rTnzI+08j9IquBIarbIEOwdWFuInp7cHovMf3RNf+7TjaURA+CAHahmQv15/x1aa+9S4zkXbI7dPelH4= X-Received: by 2002:a6b:6413:: with SMTP id t19mr36183129iog.167.1596079454405; Wed, 29 Jul 2020 20:24:14 -0700 (PDT) MIME-Version: 1.0 References: <877dunip1y.wl-jch@irif.fr> <87wo2nwmnd.wl-jch@irif.fr> <87tuxrwly4.wl-jch@irif.fr> In-Reply-To: <87tuxrwly4.wl-jch@irif.fr> From: Donald Eastlake Date: Wed, 29 Jul 2020 23:24:03 -0400 Message-ID: To: Babel at IETF Cc: babel-users Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] [Babel-users] About Babel-RTT 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, 30 Jul 2020 03:24:18 -0000 Given that it is deployed and working well but not well understood, this seems like an excellent candidate for an Experimental RFC, which is what the expired draft here https://www.ietf.org/archive/id/draft-ietf-babel-rtt-extension-00.txt is targeted for. Presumably the experiment would be to try variations in different deployments. If even experimental is considered too ambitious, it could be just an informational document to make a record of the known good deployment. (Either experimental or informational would work as the basis to allocate the required code point.) Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Tue, Jul 28, 2020 at 2:09 PM Juliusz Chroboczek wrote: > > > In my opinion, without a theoretical understanding, it is difficult to > > provide adequate guidance to implementers. > > Since I'm in a chatty mood, I'll give another example. > > While both RFC 2328 and Moy's book are written in a very simple engineering > style, there is some reasonably solid theory behind OSPF, which at least > some OSPF specialists don't appear to fully appreciate. For example, the > topological restrictions on area adjacency are pretty much the weakest > conditions that avoid counting to infinity, and the extreme care given to > the flooding subprotocol indicates a good understanding of the consequences > of desynchronised LSDBs. > > I'm deeply convinced that there is no such thing as sound engineering > without a solid theoretical base. > > -- Juliusz > > _______________________________________________ > Babel-users mailing list > Babel-users@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users