From nobody Thu Feb 6 03:08:03 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 136DD12025D; Thu, 6 Feb 2020 03:08:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <158098728001.12180.15332547368423437291@ietfa.amsl.com> Date: Thu, 06 Feb 2020 03:08:00 -0800 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-rfc6126bis-17.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 11:08:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : The Babel Routing Protocol Authors : Juliusz Chroboczek David Schinazi Filename : draft-ietf-babel-rfc6126bis-17.txt Pages : 69 Date : 2020-02-06 Abstract: Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol, and obsoletes RFCs 6126 and 7557. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-17 https://datatracker.ietf.org/doc/html/draft-ietf-babel-rfc6126bis-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-rfc6126bis-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 7 02:04:04 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 7BF8712011E; Fri, 7 Feb 2020 02:03:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <158106983949.11765.4179688990312888059.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2020 02:03:59 -0800 Archived-At: Subject: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-babel-rfc6126bis-17=3A_=28with_COMMENT=29?= 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, 07 Feb 2020 10:04:02 -0000 Mirja Kühlewind 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: ---------------------------------------------------------------------- Thanks for all the work to address my discuss points. I still think that it is important for PS spec to normatively define default values as part of the main spec, also because it is rather uncommon to use normative language in the appendix. However, there are references to the appendix in all relevant places in the spec now and I'm okay to clear my discuss on this basis. Please note that the following comment from my discuss ballot is not fully addressed: "In section 4.1.1 the update interval needs a lower limit (e.g. 3 seconds) and a recommend default value would be could as well (Note that there are other part in section 3 where the update value is discussed as well)." We had a long discuss about this value specifically and the recommended default in the appendix is fine with me. However, section 4.1.1 does not have a pointer to the appendix. Further I think it would be appropriate to add a warning here that low values mean higher network load which can have a negative impact in certain networks. ------------------------------- Old comments (here for the record; didn't check these points): 1) While this point might not raise discuss-level, it would probably also be good to provide more concrete advise on how to implement jitter: Sec 3.1.: “ A moderate amount of jitter may be applied to packets sent by a Babel speaker: outgoing TLVs are buffered and SHOULD be sent with a small random delay.” Sec 4: “a Babel node SHOULD buffer every TLV and delay sending a packet by a small, randomly chosen delay [JITTER].” 2) Sec 4.1.2. (Router-Id) should probably state again that the router-id is assumed to be unique within a domain. 3) Sec 4: “The most-significant bit of the sub-TLV, called the mandatory bit, indicates how to handle unknown sub-TLVs.” I would recommend to also indicate this bit in the image. 4) Sec 4.4: “If a TLV has a self-terminating format, then it MAY allow a sequence of sub-TLVs to follow the body.” Initially I wasn’t quite sure what you wanted to say here. I guess you say that the length would indicate a larger value that needed for the body and therefore a subTLV might be present? I recommend to clarify this here a bit. 5) I recommend to move Appendix C (Considerations for protocol extensions) in the body of the document. From nobody Fri Feb 7 08:41:22 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 2CE521209AE; Fri, 7 Feb 2020 08:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qv3pqkdkTJ_y; Fri, 7 Feb 2020 08:41:11 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 E7D5512096F; Fri, 7 Feb 2020 08:41:10 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id t17so25551ilm.13; Fri, 07 Feb 2020 08:41:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=50O1Z6uf6ztnBAXt5Xokq/omRcslFe1b2b3uq8lZIB0=; b=TcrtQHencqGKxkmqDWC56S3oeZl1NA/62GG7xH53ayUaEGUOtPBklkDHG73I3nO7zg EOApn+MK7QKWjo8Hvu6fH7DIo3/Z4PjfTTjYGwynoais66EjjP5mncCxkCAP9RCSEHI0 YOIl9EGTYyaitWGOve++oLBP4zYSdiGu7oT4JIuVwf0AQW16WREAg2xxXW56xbpQgnrC TR+PbjVI4e/fyHcqcZO1T0uthDTIQwLEqlDTr8msRP4V+vkNxcO9/R6YdILRYuofl5Ch ypG3Cq20FNI6CPVmkahEKelaK4ss6Q3zNfpZFS2CmESJxizHmRwI8ZGu94wdgMP/cWY+ vMsw== 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=50O1Z6uf6ztnBAXt5Xokq/omRcslFe1b2b3uq8lZIB0=; b=sPn1va/4350sTiiTDXOFQZvSy+F/h3Dy1wDXX9fXRuvVjU6MIBIpyt0U1PvHbmNP7I kHn41JMxlVPtXKeFuh3a1il610Zi+k0cyeTN31r2KV2WRBiWUp8QrLnfo86qxNh4tJQR mBWl0DtAWzPdBErZzbD68dNX6LAf9gE87D8UqMjDBnhT6FSWw79aOCmKLMGdMyFPyT4j LwaLXS+uwFm9s+MYTcfUGhdJVK6rEuYOdgkv2DKIcRQ917SuYT9q0S9ibpZ8H6OpVu2+ Ehm3bgNZmHiHERYVVwuapef4wSCLj6WEvC5R9ufVK0lI/ZxWpwj2Vuzd677LNE7ODScz 8p7g== X-Gm-Message-State: APjAAAU/dqrkaRC1eGyrLIE0X2WyUWbdp8AT0wDKEaWVI9l67tb/NZAe VZ9AbDsTIBC2ToOPg71DbEvpGXavhCce0HFPeeqba8cm X-Google-Smtp-Source: APXvYqxXDN9DxmTRuV6FzBS6I0AKccf3bHft+dqV1wsj84n5QX/0BDSPeD2KRE4sCipmuh4UENAsekdqWOBLC8Uxi7I= X-Received: by 2002:a05:6e02:ea9:: with SMTP id u9mr279820ilj.40.1581093669995; Fri, 07 Feb 2020 08:41:09 -0800 (PST) MIME-Version: 1.0 References: <158106983949.11765.4179688990312888059.idtracker@ietfa.amsl.com> In-Reply-To: <158106983949.11765.4179688990312888059.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Fri, 7 Feb 2020 11:40:58 -0500 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , draft-ietf-babel-rfc6126bis@ietf.org, Babel at IETF Content-Type: multipart/alternative; boundary="0000000000008e8b17059dff0eac" Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-babel-rfc6126bis-17=3A_=28with_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 16:41:17 -0000 --0000000000008e8b17059dff0eac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mirja, Thanks for clearing your DISCUSS. Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Fri, Feb 7, 2020 at 5:04 AM Mirja K=C3=BChlewind via Datatracker < noreply@ietf.org> wrote: > Mirja K=C3=BChlewind 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: > ---------------------------------------------------------------------- > > Thanks for all the work to address my discuss points. I still think that > it is > important for PS spec to normatively define default values as part of the > main > spec, also because it is rather uncommon to use normative language in the > appendix. However, there are references to the appendix in all relevant > places > in the spec now and I'm okay to clear my discuss on this basis. > > Please note that the following comment from my discuss ballot is not full= y > addressed: "In section 4.1.1 the update interval needs a lower limit (e.g= . > 3 > seconds) and a recommend default value would be could as well (Note that > there > are other part in section 3 where the update value is discussed as well).= " > We > had a long discuss about this value specifically and the recommended > default in > the appendix is fine with me. However, section 4.1.1 does not have a > pointer to > the appendix. Further I think it would be appropriate to add a warning he= re > that low values mean higher network load which can have a negative impact > in > certain networks. > > ------------------------------- > Old comments (here for the record; didn't check these points): > > 1) While this point might not raise discuss-level, it would probably also > be > good to provide more concrete advise on how to implement jitter: Sec 3.1.= : > =E2=80=9C > A moderate amount of jitter may be applied to packets sent by a Babel > speaker: outgoing TLVs are buffered and SHOULD be sent with a small > random delay.=E2=80=9D > Sec 4: =E2=80=9Ca Babel node SHOULD > buffer every TLV and delay sending a packet by a small, randomly > chosen delay [JITTER].=E2=80=9D > > 2) Sec 4.1.2. (Router-Id) should probably state again that the router-id = is > assumed to be unique within a domain. > > 3) Sec 4: =E2=80=9CThe most-significant bit of the sub-TLV, called the ma= ndatory > bit, > indicates how to handle unknown sub-TLVs.=E2=80=9D > I would recommend to also indicate this bit in the image. > > 4) Sec 4.4: > =E2=80=9CIf a TLV has a self-terminating format, then it MAY > allow a sequence of sub-TLVs to follow the body.=E2=80=9D > Initially I wasn=E2=80=99t quite sure what you wanted to say here. I gues= s you say > that > the length would indicate a larger value that needed for the body and > therefore > a subTLV might be present? I recommend to clarify this here a bit. > > 5) I recommend to move Appendix C (Considerations for protocol extensions= ) > in > the body of the document. > --0000000000008e8b17059dff0eac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mirja,

Thanks for c= learing your DISCUSS.

Donald
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)<= br>=C2=A02386 Panoramic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.com

On Fri, Feb 7, 2020 at 5:04 AM Mirja K=C3=BChlewind via Datatracker <= ;noreply@ietf.org> wrote:
Mirja K=C3=BChlewind h= as 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/s= tatement/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:
----------------------------------------------------------------------

Thanks for all the work to address my discuss points. I still think that it= is
important for PS spec to normatively define default values as part of the m= ain
spec, also because it is rather uncommon to use normative language in the appendix. However, there are references to the appendix in all relevant pla= ces
in the spec now and I'm okay to clear my discuss on this basis.

Please note that the following comment from my discuss ballot is not fully<= br> addressed: "In section 4.1.1 the update interval needs a lower limit (= e.g. 3
seconds) and a recommend default value would be could as well (Note that th= ere
are other part in section 3 where the update value is discussed as well).&q= uot; We
had a long discuss about this value specifically and the recommended defaul= t in
the appendix is fine with me. However, section 4.1.1 does not have a pointe= r to
the appendix. Further I think it would be appropriate to add a warning here=
that low values mean higher network load which can have a negative impact i= n
certain networks.

-------------------------------
Old comments (here for the record; didn't check these points):

1) While this point might not raise discuss-level, it would probably also b= e
good to provide more concrete advise on how to implement jitter: Sec 3.1.: = =E2=80=9C=C2=A0
A moderate amount of jitter may be applied to packets sent by a Babel
=C2=A0 =C2=A0speaker: outgoing TLVs are buffered and SHOULD be sent with a = small
=C2=A0 =C2=A0random delay.=E2=80=9D
Sec 4: =E2=80=9Ca Babel node SHOULD
=C2=A0 =C2=A0buffer every TLV and delay sending a packet by a small, random= ly
=C2=A0 =C2=A0chosen delay [JITTER].=E2=80=9D

2) Sec 4.1.2. (Router-Id) should probably state again that the router-id is=
assumed to be unique within a domain.

3) Sec 4: =E2=80=9CThe most-significant bit of the sub-TLV, called the mand= atory bit,
=C2=A0 =C2=A0indicates how to handle unknown sub-TLVs.=E2=80=9D
I would recommend to also indicate this bit in the image.

4) Sec 4.4:
=E2=80=9CIf a TLV has a self-terminating format, then it MAY
=C2=A0 =C2=A0allow a sequence of sub-TLVs to follow the body.=E2=80=9D
Initially I wasn=E2=80=99t quite sure what you wanted to say here. I guess = you say that
the length would indicate a larger value that needed for the body and there= fore
a subTLV might be present? I recommend to clarify this here a bit.

5) I recommend to move Appendix C (Considerations for protocol extensions) = in
the body of the document.
--0000000000008e8b17059dff0eac-- From nobody Fri Feb 7 09:02:13 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 6631B12093C; Fri, 7 Feb 2020 09:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVeNaRf1R9Om; Fri, 7 Feb 2020 09:02:10 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 52C7312084E; Fri, 7 Feb 2020 09:02:10 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id x1so260077iop.7; Fri, 07 Feb 2020 09:02:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=EWBI4jEA9wnoKVZ/D3pcSFlDxgoYoA463O5d+TbXiTY=; b=A4/81MM5C5aMJGNSwvNiDVX5l/6rOOVnSvt0i+qRl+b2IAr5to+Gk94dnKRooTRVra +0HuAdFUf0zCMzTH46gaeWG/q0UPD3wNRteYlY9kWD16CNCnBVGn2GzMEicis2piZyfP qN4PEahKFk+mqPx7ZmGjO1ZMwSgxGF+5XCfv5VJrunA15/AnjvgyzDD1RJFnUZcVTQYV TY8Ey6HAWv9KCe9HSELZLSOugAGERRtb8w/wpDYO7suIRu4t+e6/qRU/Q+eBIDWEhMFw Yc+MgX2sa+0/ZADNAM5mg2weLM1UUZV44bWxMW6myp17qlr/Z9MMlcOvzm2SiWG/YMpV pihA== 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=EWBI4jEA9wnoKVZ/D3pcSFlDxgoYoA463O5d+TbXiTY=; b=YFWpItqKHp8owJf3blNWMDW1adcULXN/bLX8ZmQVAMSE1hqnqHNc1dZZnh0Jf72T1p ozmTzVqq7XLQfaJVGfs3tTqzInhmB1vOH6A37XMsMmohuEKdNSz/kemJZdo/TLV5jG9A mYRamFzD4XWJznr3yMjTs+qL/hhYDpMutDmZ5ygnQt7axMST3+Rx+9KiBCv9JmTFVLoT ToNqgEn5Mr+kZ3521LY/UTNhpBuUsru7qZupprm4Cfi2oiMLMyt9cl2z35Z+qyETvV9m KsEEEFSOcrmb0v8p/0jR0XdTwsMRTNUwWF4t1KY2DdQ5mivAcjTaY4mmjrN8HnG1K7Gd IkAg== X-Gm-Message-State: APjAAAXCaRnps8XlFcIPoxEGSXU/qBjDs4o4CN0UNXbCjmsn2tDya7g6 Yv6BiftVfoIcg7+VFdYZbh8pzNKfFw8DGsroOhrVjE4m X-Google-Smtp-Source: APXvYqzAY+TPXYAoCw7DoZSP9vQusKmeRqAf2WzBQkOhn/uBJOdpLp981Pe+lhtVUaicX8MmCM8uQyJ4fzqBZsT7KU4= X-Received: by 2002:a5d:9d11:: with SMTP id j17mr261495ioj.83.1581094929157; Fri, 07 Feb 2020 09:02:09 -0800 (PST) MIME-Version: 1.0 From: Donald Eastlake Date: Fri, 7 Feb 2020 12:01:58 -0500 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: multipart/alternative; boundary="0000000000009bd110059dff5916" Archived-At: Subject: [babel] Call for Babel 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: Fri, 07 Feb 2020 17:02:11 -0000 --0000000000009bd110059dff5916 Content-Type: text/plain; charset="UTF-8" Hi, We have requested a 1 hour Babel WG meeting slot at the 21-17 March IETF in Vancouver, British Columbia. If you would like to present at that meeting, please send a request to babel-chairs@ietf.org or post to this list. It is possible to present remotely if you are not attending the meeting. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com --0000000000009bd110059dff5916 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

We have requested a 1 hour Babel WG= meeting slot at the 21-17 March IETF in Vancouver, British Columbia. If yo= u would like to present at that meeting, please send a request to babel-chairs@ietf.org or post to this= list. It is possible to present remotely if you are not attending the meet= ing.

Thanks,
Donald
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2= =A02386 Panoramic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.com
--0000000000009bd110059dff5916-- From nobody Mon Feb 17 18:40: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 5F6EB12011D for ; Mon, 17 Feb 2020 08:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U1SzO9ukucU for ; Mon, 17 Feb 2020 08:38:03 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 7741612007C for ; Mon, 17 Feb 2020 08:38:03 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id j15so9469535pgm.6 for ; Mon, 17 Feb 2020 08:38:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=MLm3/joipyC34LqcIxXc9fBQn9Kuwvfr/q/1o5yHvak=; b=TU3bH+fgZUF9zmHu0bAvHYTXw5LP9GTquqC8bIh6g+YoVv99Eqauiuir075o3Z1A29 ctW7G5ST7lhXdiIsJWIWju6nkgqT1nBlzjv+aZ1YRaawrwSp3ZyUOQD1U9TaqYD5xXqw 1sjK3tXHa1PEGCvKZEPL+MjHiHnKP8pvQA8e7hnzSXClC2qCPCE7/BqLaYdlcpcqkNwR hZ4NZ8TYTVdfr++Npbx1vRJYqgFp7Hfb/kSQw67kbaeze3ri9l06/Z2+V+jBoPcYBzJM fTeCQN50kGA3aDnshJBtnsQTThGvB26gvScIw97oS7fZH4oCw7tmfNVCHkRMpiIANe5w 4XFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=MLm3/joipyC34LqcIxXc9fBQn9Kuwvfr/q/1o5yHvak=; b=X3V+PYIhoytvcfpgDBI36dDewUsSvbKz8CZbjac43SCP00NywIH0sCxj6opWR8Hbw5 aOgJ6kLsS7EKB0mDPTUfQutLsrM6K64odp0akkc/pnk+axdYQZ/sGR2pqgjnhHS02QtV IsQ87QgrJZi5oe1pS6l75uPVOCahvO4/Ewc8M3nV/Fy30R/c8LVakYMTL/BMlnI42kjs W4g2olaRryyYgFoZVNAndIRqqDRMbvVQ0OlgOlf0AInz/nVosfTsmndCt/7On/xb4vvg dSgrDVEZ7/zhfrrJcpzm4yIgLwTTwW2x0pU8AlbRo1zkh+TGzfPTB3mFroA6kneAJ1GG hdsA== X-Gm-Message-State: APjAAAWkaCn+u9JM19vK7XVvjnxdFDuuheM1m1KUGtjL+yFjFDYlDikn 3fgAnILErjSm7lnYXf/DY/U= X-Google-Smtp-Source: APXvYqzUARHrli3i1CznucwxS3aNlId3tk1lhuIvXSarmXDYeKW6uFSOxlKrIvSsuMbAVvKiHoYT0w== X-Received: by 2002:a63:5809:: with SMTP id m9mr18002827pgb.26.1581957482550; Mon, 17 Feb 2020 08:38:02 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:cca3:c610:3be7:3a9e? ([2601:647:5600:5020:cca3:c610:3be7:3a9e]) by smtp.gmail.com with ESMTPSA id u2sm1419014pgj.7.2020.02.17.08.38.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Feb 2020 08:38:01 -0800 (PST) From: Mahesh Jethanandani Message-Id: <9764387E-CCD0-4D42-AF4E-7C45A66D6A23@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6BF03C72-1355-45E4-864E-A06863F5F7FB" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 17 Feb 2020 08:37:59 -0800 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611537590F3@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: Donald Eastlake , "babel@ietf.org" To: "STARK, BARBARA H" References: <2D09D61DDFA73D4C884805CC7865E61153754370@GAALPA1MSGUSRBF.ITServices.sbc.com> <53327E10-4D4F-4F2D-9F9C-DC30EC3C1FA1@gmail.com> <2D09D61DDFA73D4C884805CC7865E61153757B62@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611537590F3@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] info and data models -- feedback requested 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, 17 Feb 2020 16:38:07 -0000 --Apple-Mail=_6BF03C72-1355-45E4-864E-A06863F5F7FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Barbara, Sorry for going silent on this.=20 As I said before, YANG DM cannot enforce what happens outside of the = model. Of the behaviors noted below, the DM cannot enforce what happens = to the contents of the log file/memory. All it can do is to clear the = reference to the log file/memory. Therefore in 1 it cannot delete the = old file or clear the old memory. In 4 it cannot clear the existing = file/memory. You do ask in 1, 2 that the old reference be replaced by the new = reference. For that you do not need a clear/reset action. All you have = to do is to overwrite the old reference with a new reference. As such, I still do not see why a reset/clear action is needed for log = in the (YANG) DM. But there are many things I do not see :-) > On Jan 21, 2020, at 9:29 AM, STARK, BARBARA H wrote: >=20 > For logs, I can see several holistic (not focusing on result of a = single action) sets of behaviors a user may want to accomplish at the = time they=E2=80=99re enabling logging (I=E2=80=99m wording this = specifically to be vague about how many commands the user might need to = issue): > Old file is deleted or old memory store is cleared/released, new file = is started or memory space created with new reference. > Old file / memory store stays, new file / memory store is started with = new reference. // there is no longer a reference specified in the Babel = info model that would point to the old file or memory; some DM schemes, = like TR-181, would still allow access to the log (the Babel packet log = is a reference to an entry in a log object); where the log came from, = though, would be lost unless it was incorporated in the filename by the = implementation or otherwise contained in log metadata; may need to = consider if something needs to be said about persistence across reboots > Existing referenced file / memory store is appended. > Existing referenced file / memory store is cleared and then appended. > =20 > 1 and 4 are very similar in effect.=20 > =20 > Note that there are behaviors that can be enforced by the model, and = behaviors that are imposed on compliant implementations (e.g., mandatory = to implement). I=E2=80=99m not concerned with whether or not a desired = behavior is enforced by a model. I=E2=80=99m perfectly satisfied for = desired behaviors to be imposed through implementation compliance. The = question for me is what the desired behavior is, and not whether or not = any particular DM scheme has the ability to enforce. > =20 > I=E2=80=99m thinking (based on opinions expressed to date) that in the = absence of a log =E2=80=9Creset=E2=80=9D, behavior 3 (appending) might = be expected to occur (note the info model says nothing about limiting = filesize =E2=80=93 it=E2=80=99s up to the DM or implementation to do or = say something wrt max filesize and what to do when max is reached). If = we were to have a log reset, I think either behavior 1 or 4 would be = fine, and don=E2=80=99t think we=E2=80=99d need to dictate one or the = other in the info model. I=E2=80=99d prefer to avoid 2, because I think = it poses a danger of memory leaks. It may also be useful to include a = statement that there is no expectation for logs to persist across = reboots. > =20 > Barbara > =20 > From: Mahesh Jethanandani =20 >=20 > Hi Barbara, > =20 > Good point. What would you expect the reset action on packet log to = do? > =20 > The difference between packet log and statistics from a data model is = that, statistics are maintained by the data model. As such a reset = causes the values in the data model to be cleared. For the packet log, = all that the model does is maintain a pointer to a URL/file where the = log is maintained. It does not maintain the contents of that log. A = reset action on an object that is external to the model cannot be = enforced by the model. All the model can do is clear the pointer, but I = gather that is not what you are looking for it to do. > =20 > Cheers. >=20 >=20 > On Jan 20, 2020, at 8:25 AM, STARK, BARBARA H > wrote: > =20 > That would suggest we should add a reset action for the packet log. We = don=E2=80=99t currently have one. > Barbara > =20 > From: Donald Eastlake >=20 >=20 > Hi Mahesh and Barbara, > =20 > Speaking just as a WG member, it seems to me more flexible for the = clearing of statistics and the enablement of statistics to be separate = actions. You can always do both if that's wht you want. >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > =20 > =20 > On Fri, Jan 17, 2020 at 3:13 PM Mahesh Jethanandani = > wrote: >=20 >=20 > > On Jan 17, 2020, at 7:32 AM, STARK, BARBARA H > wrote: > >=20 > > There are 2 items related to the info/data models that have been = swirling around in my head over the past month.=20 > >=20 > > 1. Since the most recent drafts of rfc6126bis now have 2 examples of = initial interval settings (for cases where fast convergence is desired, = or where slow convergence is acceptable and less chattiness is desired), = I don't like that we have no means for the user to express what their = preference is around this (in case an implementation could support both = cases). Should we have something at the top level of the model like: > > boolean rw converge-fast; > >=20 > > converge-fast: Indicates whether the user wants the network to = converge=20 > > quickly (which will cause Babel messages to be sent more = frequently), or > > prefers fewer Babel messages with slower time to convergence. = Fast > > convergence is desired if "true". An implementation MAY choose = to expose > > this parameter as read-only ("ro"). > >=20 > > 2. In BBF, I got a comment related to babel-stats-enable and = babel-packet-log-enable. It's unspecified as to whether previous data is = discarded when the stats or log are enabled, or the new log entries are = appended / existing counts incremented. I tend to agree that the lack of = a statement will lead to inconsistency, and would prefer consistent = behavior. Mahesh and I had a brief exchange where we disagreed on what = the preferred behavior should be -- which suggests there is definitely a = strong likelihood of different implementations choosing different = behavior in the absence of guidance. >=20 > And to clarify the disagreement between Barbara and I was =E2=80=A6 >=20 > The Babel information and data models define a boolean flag that = enables/disables the collection of statistics. The Babel data model in = addition has an =E2=80=98action=E2=80=99 YANG statement defined to clear = the statistics being collected. Barbara=E2=80=99s assumption with = enabling the boolean flag was that it would implicitly clear all the = statistics. But the data model with a separate =E2=80=98action=E2=80=99 = statement requires it to be called explicitly to clear the statistics.=20= >=20 > Unfortunately, there isn=E2=80=99t a way in YANG to invoke the calling = of an =E2=80=98action=E2=80=99 statement when a certain attribute value = toggles. Implementations can choose to make it implicit by including the = call to the =E2=80=98action=E2=80=99 statement as part of enabling = statistics. But it is not something YANG can enforce. >=20 > So the question is - should the information model require that = enabling of statistics collection also clear the statistics (even if the = YANG model cannot enforce it) or leave it to implementations to = decide/enforce? >=20 > Cheers. >=20 > >=20 > > I realize we're past last call. But I think these are important. > >=20 > > Barbara > >=20 > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://www.ietf.org/mailman/listinfo/babel = >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel = Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_6BF03C72-1355-45E4-864E-A06863F5F7FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Barbara,

Sorry for going silent on this. 

As I said before, YANG = DM cannot enforce what happens outside of the model. Of the behaviors = noted below, the DM cannot enforce what happens to the contents of the = log file/memory. All it can do is to clear the reference to the log = file/memory. Therefore in 1 it cannot delete the old file or clear the = old memory. In 4 it cannot clear the existing file/memory.

You do ask in 1, 2 that = the old reference be replaced by the new reference. For that you do not = need a clear/reset action. All you have to do is to overwrite the old = reference with a new reference.

As such, I still do not see why a = reset/clear action is needed for log in the (YANG) DM. But there are = many things I do not see :-)

On Jan 21, 2020, at 9:29 AM, = STARK, BARBARA H <bs7652@att.com> wrote:

For logs, = I can see several holistic (not focusing on result of a single action) = sets of behaviors a user may want to accomplish at the time they=E2=80=99r= e enabling logging (I=E2=80=99m wording this specifically to be vague = about how many commands the user might need to issue):
  1. Old file is deleted or old memory store is = cleared/released, new file is started or memory space created with new = reference.
  2. Old file / memory store stays, new file / memory = store is started with new reference. // there is no longer a reference = specified in the Babel info model that would point to the old file or = memory; some DM schemes, like TR-181, would still allow access to the = log (the Babel packet log is a reference to an entry in a log object); = where the log came from, though, would be lost unless it was = incorporated in the filename by the implementation or otherwise = contained in log metadata; may need to consider if something needs to be = said about persistence across reboots
  3. Existing referenced file / = memory store is appended.
  4. Existing referenced file / = memory store is cleared and then appended.
 
1 and 4 = are very similar in effect. 
 
Note that = there are behaviors that can be enforced by the model, and behaviors = that are imposed on compliant implementations (e.g., mandatory to = implement). I=E2=80=99m not concerned with whether or not a desired = behavior is enforced by a model. I=E2=80=99m perfectly satisfied for = desired behaviors to be imposed through implementation compliance. The = question for me is what the desired behavior is, and not whether or not = any particular DM scheme has the ability to enforce.
 
I=E2=80=99m= thinking (based on opinions expressed to date) that in the absence of a = log =E2=80=9Creset=E2=80=9D, behavior 3 (appending) might be expected to = occur (note the info model says nothing about limiting filesize =E2=80=93 = it=E2=80=99s up to the DM or implementation to do or say something wrt = max filesize and what to do when max is reached). If we were to have a = log reset, I think either behavior 1 or 4 would be fine, and don=E2=80=99t= think we=E2=80=99d need to dictate one or the other in the info model. = I=E2=80=99d prefer to avoid 2, because I think it poses a danger of = memory leaks. It may also be useful to include a statement that there is = no expectation for logs to persist across reboots.
 
Barbara
 
From: Mahesh Jethanandani <mjethanandani@gmail.com> 

Hi Barbara,
 
Good point. What would you expect the = reset action on packet log to do?
 
The difference between packet log and statistics from a data = model is that, statistics are maintained by the data model. As such a = reset causes the values in the data model to be cleared. For the packet = log, all that the model does is maintain a pointer to a URL/file where = the log is maintained. It does not maintain the contents of that log. A = reset action on an object that is external to the model cannot be = enforced by the model. All the model can do is clear the pointer, but I = gather that is not what you are looking for it to do.
 
Cheers.


On Jan 20, 2020, at 8:25 AM, STARK, BARBARA H <bs7652@att.com> wrote:
 
That would suggest we should add a = reset action for the packet log. We don=E2=80=99t currently have = one.
Barbara
 

From: Donald Eastlake <d3e3e3@gmail.com> 

Hi Mahesh and Barbara,
 
Speaking just as a WG member, it seems = to me more flexible for the clearing of statistics and the enablement of = statistics to be separate actions. You can always do both if that's wht = you want.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com
 
 
On Fri, Jan 17, 2020 at = 3:13 PM Mahesh Jethanandani <mjethanandani@gmail.com>= wrote:


> On Jan 17, 2020, at 7:32 = AM, STARK, BARBARA H <bs7652@att.com> wrote:
> 
> There = are 2 items related to the info/data models that have been swirling = around in my head over the past month. 
> 
> 1. = Since the most recent drafts of rfc6126bis now have 2 examples of = initial interval settings (for cases where fast convergence is desired, = or where slow convergence is acceptable and less chattiness is desired), = I don't like that we have no means for the user to express what their = preference is around this (in case an implementation could support both = cases). Should we have something at the top level of the model like:
> boolean              =   rw converge-fast;
> 
>  =  converge-fast:  Indicates whether the user wants the network = to converge 
>      quickly (which will cause Babel = messages to be sent more frequently), or
>    =   prefers fewer Babel messages with slower time to = convergence.  Fast
>      = convergence is desired if "true". An implementation MAY choose to = expose
>      this parameter as = read-only ("ro").
> 
> 2. In = BBF, I got a comment related to babel-stats-enable and = babel-packet-log-enable. It's unspecified as to whether previous data is = discarded when the stats or log are enabled, or the new log entries are = appended / existing counts incremented. I tend to agree that the lack of = a statement will lead to inconsistency, and would prefer consistent = behavior. Mahesh and I had a brief exchange where we disagreed on what = the preferred behavior should be -- which suggests there is definitely a = strong likelihood of different implementations choosing different = behavior in the absence of guidance.

And to = clarify the disagreement between Barbara and I was =E2=80=A6

The Babel information and data models define a = boolean flag that enables/disables the collection of statistics. The = Babel data model in addition has an =E2=80=98action=E2=80=99 YANG = statement defined to clear the statistics being collected. Barbara=E2=80=99= s assumption with enabling the boolean flag was that it would implicitly = clear all the statistics. But the data model with a separate = =E2=80=98action=E2=80=99 statement requires it to be called explicitly = to clear the statistics. 

Unfortunately, there isn=E2=80=99t a way in YANG to invoke = the calling of an =E2=80=98action=E2=80=99 statement when a certain = attribute value toggles. Implementations can choose to make it implicit = by including the call to the =E2=80=98action=E2=80=99 statement as part = of enabling statistics. But it is not something YANG can enforce.

So the question is - should the information = model require that enabling of statistics collection also clear the = statistics (even if the YANG model cannot enforce it) or leave it to = implementations to decide/enforce?

Cheers.
> 
> I = realize we're past last call. But I think these are important.
> 
> Barbara
> 
> = _______________________________________________
> babel = mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel

Mahesh Jethanandani
mjethanandani@gmail.com



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

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_6BF03C72-1355-45E4-864E-A06863F5F7FB-- From nobody Sun Feb 23 15:09: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 F301A3A11A2 for ; Sun, 23 Feb 2020 15:09:23 -0800 (PST) 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 s0TsnHysbOgv for ; Sun, 23 Feb 2020 15:09:19 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B028B3A119F for ; Sun, 23 Feb 2020 15:09:18 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1582499356; bh=NsdVNr5FRSS7KgQVKpy3Hq+Ag5+KJDKVdvCzjktT4Uo=; h=From:To:Subject:References:Date:From; b=WjySUcjralCtdhomQAvAyrUD3w/tzDhg+mCYG/3ycxzFSgj1gZ3XYymF2Fi002lSW rTds5U2y04TctGcB+1ZveW9i8fA6wtAPJSX90WZ+YubZZ2DIYgRUN31w+eibDJp+7C nPI2g+3PMvlB2z4DTJNWG0kYeMs263Xlnj8q1S58LUBxJFCK1Y+RTl4JCF9IpYMKtf YvcT7sih9GCot0MnW5FnvVgo38G2Sn8PiONrIVih5BLkGa14NWwGo6JmvCsOmsHegz ZUW2jcFC1R7rereFkdEeQI1NMFeeXy5RM2/3Zsau0ElGPC9K7KxaGlMdvLVZsUcNMo EU69Mg4KKPSuw== To: babel@ietf.org, babel-users@alioth-lists.debian.net References: <158249859363.84431.6477899599086019164.stgit@alrua-x1> Date: Mon, 24 Feb 2020 00:09:16 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87ftf03nqb.fsf@toke.dk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Archived-At: Subject: [babel] Fwd: [PATCH 0/4] Add MAC authentication support to the Babel protocol 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, 23 Feb 2020 23:09:24 -0000 --=-=-= Content-Type: text/plain Hi everyone Just an FYI: I finally found the time to respin the Bird patches to add MAC support to Babel. I'm forwarding the cover letter to the patch series which describes the state of the implementation. The full series is available here: http://trubka.network.cz/pipermail/bird-users/2020-February/014251.html And a Github repository with the implementation for those wanting to test it: https://github.com/tohojo/bird/tree/babel-mac-01 Cheers, -Toke --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.toke.dk X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.4 Delivered-To: toke@toke.dk Received: from mail.toke.dk by mail.toke.dk with LMTP id ER6XLSIDU16HsgQAOr1fkg (envelope-from ) for ; Sun, 23 Feb 2020 23:56:34 +0100 Subject: [PATCH 0/4] Add MAC authentication support to the Babel protocol DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1582498594; bh=RwWixrnmbpA9/K2ddU8Cdrgf5nJfjjPCGOZTNeNlQMk=; h=Subject:From:To:Date:From; b=LZ4xABTFZNQgaeDFF0Yz6wM2sTfD3qPznWQUIh0iTYlW8/SBNk5WqxJaQCiinsri+ MJ1lO3sOJ7muvR4YjPorvEuj7FiaIv2Lf9PVDs6vQjG3vzIQfkCfxdN8+eczdQGk6s vn9Sv8tYVe3izUHxdMe5QUhQg7Jm9THeyhEmipor8AIyHEOZOUIldA0MU0/n/z36lG eUBacyIpoKAsK0fnd+ns3TN6nKVPXAZEHvnR4pkh0X58V+OsxfTA+1VP/NnZTwvJuL mN/wfBfcPd5XVHlw7bVOgRTfe1xfj2FcbqTAQlrOUEqoZ1zb8Pb5OSMOhvcbmrNwS2 lmOeyOJvq+IdQ== From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: bird-users@network.cz Date: Sun, 23 Feb 2020 23:56:33 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <158249859363.84431.6477899599086019164.stgit@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This series adds MAC authentication support to the Babel protocol as specif= ied in by the IETF Babel working group in draft-babel-hmac-10: https://tools.ietf.org/html/draft-ietf-babel-hmac-10 An initial RFC patch series was posted here in July 2018[0]. Since then, the protocol specification has progressed through the IETF, to the point where = it is now in the IESG publication queue as a proposed standard RFC. This version = of the patch series updates the implementation to correspond to the final vers= ion of the draft, and also addresses the review comments from the initial RFC p= atch. The major changes are: Major updates to the specification (for a full list see the draft appendix): - Added Blake2s as a recommended algorithm - Updated terminology to use MAC everywhere instead of HMAC (since Blake is= not an HMAC algorithm). - Added expiration of neighbours and rate limiting of challenge replies - Update TLV type numbers after IANA allocation In addition, the following changes have been made to the implementation: - Add wrapper function to bird sysdep code to pick a suitable source of ran= dom bytes - Import reference Blake2 implementations into lib/ - Rename function names and data structures to use an auth_ prefix instead = of hmac_ - Perform a separate authentication pass before parsing the packet, and mov= e the authentication-related code to its own source file - Enforce key length recommendation from the specification - Add a 'permissive' configuration mode where outgoing packets are signed b= ut incoming packets are accepted even though they fail authentication - Add user documentation for the authentication configuration, and function docstrings to the main authentication functions - Fix a bunch of nits and code style issues I have performed basic interoperability testing between this implementation= and the current babeld HMAC implementation[1]. The two implementations were abl= e to successfully exchange authenticated messages with both HMAC-256 and Blake2s= keys. Given the above, and the close-to-final state of the specification at the I= ETF, I believe this series is ready for merging (subject to review, of course). = For those wanting to test the code, a version of Bird with this series applied = is available on Github[2] for easy consumption. Cheers, -Toke [0] http://trubka.network.cz/pipermail/bird-users/2018-July/012536.html [1] https://github.com/jech/babeld/pull/52 [2] https://github.com/tohojo/bird/tree/babel-mac-01 --- Toke H=C3=B8iland-J=C3=B8rgensen (4): sysdep: Add wrapper to get random bytes nest: Add Blake2s and Blake2b hash functions babel: Refactor packet parsing code for reuse in authentication checks babel: Add MAC authentication support aclocal.m4 | 49 ++++ conf/conf.c | 1=20 configure.ac | 15 + doc/bird.sgml | 38 +++ lib/Makefile | 2=20 lib/birdlib.h | 2=20 lib/blake2-impl.h | 160 +++++++++++++ lib/blake2-ref.h | 112 +++++++++ lib/blake2.c | 46 ++++ lib/blake2.h | 67 ++++++ lib/blake2b-ref.c | 270 ++++++++++++++++++++++ lib/blake2s-ref.c | 263 ++++++++++++++++++++++ lib/mac.c | 7 + lib/mac.h | 2=20 nest/config.Y | 4=20 proto/babel/Doc | 1=20 proto/babel/Makefile | 4=20 proto/babel/auth.c | 593 +++++++++++++++++++++++++++++++++++++++++++++= ++++ proto/babel/babel.c | 33 ++- proto/babel/babel.h | 54 ++++ proto/babel/config.Y | 38 +++ proto/babel/packets.c | 294 +++++++++++++----------- proto/babel/packets.h | 96 ++++++++ sysdep/unix/random.c | 78 ++++++ 24 files changed, 2068 insertions(+), 161 deletions(-) create mode 100644 lib/blake2-impl.h create mode 100644 lib/blake2-ref.h create mode 100644 lib/blake2.c create mode 100644 lib/blake2.h create mode 100644 lib/blake2b-ref.c create mode 100644 lib/blake2s-ref.c create mode 100644 proto/babel/auth.c create mode 100644 proto/babel/packets.h --=-=-=-- From nobody Mon Feb 24 20:43:35 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 73BF93A0957; Mon, 24 Feb 2020 20:43:33 -0800 (PST) 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 YBgeQ1jpQ2Bu; Mon, 24 Feb 2020 20:43:32 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 3C4E63A0958; Mon, 24 Feb 2020 20:43:29 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id i7so1083507ilr.7; Mon, 24 Feb 2020 20:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LX9m7SBq1FrUYt23Vvfq5ff4xvHgE6W6rmkePQvnVtA=; b=rE4/7bc2NT9CQEODwCDuZ80Y4CDTZTk7qfREDpxWi9k4GX1Um9EPagwps6v2iVu3sg ZbYy0vk46vi6WRxFkpAimsdTEin4Lti0EY7JIailvHBcfFABl1lJ6TMxXjEObGhtogjj F2TCga10CkLdjhpSiyJqapmAZHohKoxP9bQALAe7K6+cpxC7yMGUbYqSMPr1IvNhsllt ktPm+Iak/QJZ/amSNl7jrABpxhxEO6EJZOLgY4g3GNK5s5eCqqaTRTJX/ikOdgCJIhrV eW8pG8gxoJIlB+E5R4uLva2mTU8RF6KSGMtS1BLYFA3/lxfHrUpS2zafaejVj8bZNfep ECTw== 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:content-transfer-encoding; bh=LX9m7SBq1FrUYt23Vvfq5ff4xvHgE6W6rmkePQvnVtA=; b=n3jHmDn1jVy6n11JpCBzLH2OwG8X13Y5PPtwBlHRoCm+QLdd/AKaPjPw50N5r0dWnK ImXVXfpu1DEePUWZ/01EBJYrJC0B7lE6a/63gDoGyA8lqTtCvvmpmd064egr0EQl/xko LGqbooCyviQZ4jPPHKmjzK2OT/3NM2zI6ySXNYyVSrh2Xid7O4C8eleqFO64OxS4luL6 D5R7M/gj+qaCRa8GrHWk0ep8PFymMJKUhB0aMB21GR95tkM+f6Mjg3C8Kw6PqJEI4dt4 7xvD4JQiBsuelReo5ZWp4iO2eYHGvhVNiLFhC6yPS6lJP/sqWpOIpK108r+O3Nnmw2ab 8V6Q== X-Gm-Message-State: APjAAAV4a2DBQT0mhdubEGtJZonOxsVl178zMeitUwJaQNsFAIbfEjSv zqwLxZB2XNzrWwegui1bk0seat79+OBouPu4pjCwXQ== X-Google-Smtp-Source: APXvYqwDy8WIK/j58hAJil+nKDm8Hkk4RpURpapGAP6vANszuU3nm9rLfYvYzAe9otTBx3nHqjiLm9stESVRXAcAdEc= X-Received: by 2002:a05:6e02:ea9:: with SMTP id u9mr65544129ilj.40.1582605807982; Mon, 24 Feb 2020 20:43:27 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Donald Eastlake Date: Mon, 24 Feb 2020 23:43:16 -0500 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Call for Babel 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: Tue, 25 Feb 2020 04:43:34 -0000 Hi, The Babel WG meeting at the March IETF meeting in Vancouver has been tentatively scheduled for Tuesday afternoon, 24 March, 1740 to 1840 hours. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Fri, Feb 7, 2020 at 12:01 PM Donald Eastlake wrote: > > Hi, > > We have requested a 1 hour Babel WG meeting slot at the 21-17 March IETF = in Vancouver, British Columbia. If you would like to present at that meetin= g, please send a request to babel-chairs@ietf.org or post to this list. It = is possible to present remotely if you are not attending the meeting. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com From nobody Fri Feb 28 14:36:05 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 951723A1F82; Fri, 28 Feb 2020 14:35:01 -0800 (PST) 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: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292930159.19931.16832223501851129262@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:01 -0800 Archived-At: Subject: [babel] babel - Requested session has been scheduled for IETF 107 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, 28 Feb 2020 22:35:09 -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 (1:00 requested) Tuesday, 24 March 2020, Afternoon Session III 1740-1840 Room Name: Georgia A size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/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): 1 Hour Number of Attendees: 21 Conflicts to Avoid: Chair Conflict: saag rtgwg idr bess 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: ---------------------------------------------------------