[babel] Mirja Kühlewind's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT)
Mirja Kühlewind via Datatracker <noreply@ietf.org> Wed, 07 August 2019 11:29 UTC
Return-Path: <noreply@ietf.org>
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 EB47B1206CE; Wed, 7 Aug 2019 04:29:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kühlewind via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake <d3e3e3@gmail.com>, babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.100.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Mirja Kühlewind <ietf@kuehlewind.net>
Message-ID: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com>
Date: Wed, 07 Aug 2019 04:29:39 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/nZQzssUFsQSnqHknlcdtEOC8rmI>
Subject: [babel] Mirja Kühlewind's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Aug 2019 11:29:40 -0000
Mirja Kühlewind has entered the following ballot position for draft-ietf-babel-rfc6126bis-12: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a couple of points that needs addressing before this document can move forward. Most of them should the straight forward to address. My main point is about network load. Thanks for discussing network load and correctly adding some warnings at the right places, however, for a PS track document I would like to see more than this. Usually it's good provide default values were suitable (as this often is what people will then pick if there is no good reason to diverge) and more important I really like to see min/max values. Note that RFC8085 recommend a minimal interval of 3 seconds which probably is also a good hard boundary here. More concretely I think there are these cases that need more guidance: - Section 3.7.2. (Triggered Updates) advises to send a message multiple times for redundancy in case of loss. 5 and 2 are mentioned as example values. Please provide a normative default value and a normative maximum value here. Moreover the spec should also require to pace out these messages and avoid "tail loss" by overloading the local queue. (See also section 3.8.2.1) - Section 3.8.1.1. (Route Requests) says: "Full route dumps MAY be rate-limited, especially if they are sent over multicast." I think this should at least be a SHOULD. Please also provide further guidance about to appropriately rate limit and think about other cases where a recommend to implement rate-limiting could make sense. - 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). - Section 3.8.2.4. mentions network load when requests are sent to all neighbours after reboot. Please provide more guidance about how to pace out these requests. - Section 3.8.1.2. (Seqno Requests) discusses hop count values but could maybe also give more concrete guidance. I would assume that the hop count value of the current active route is usually know. Maybe that knowledge could be used to pick an appropriate value? Two other smaller discuss points/questions/comments: 1) Sec 4.6.8. (Next Hop): If I interpret this correctly, address compression is allowed for the next hop field and therefore this TLV would actually not be self-terminating. What do I miss? 2) This document needs to specify a registration policy also for each of the already existing registries given this document obsoletes RFC7557. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Other comments: 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.
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… STARK, BARBARA H
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Mirja Kuehlewind
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Juliusz Chroboczek
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… David Schinazi
- [babel] Mirja Kühlewind's Discuss on draft-ietf-b… Mirja Kühlewind via Datatracker
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Juliusz Chroboczek
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Mirja Kuehlewind
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Juliusz Chroboczek
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Mirja Kuehlewind
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Juliusz Chroboczek
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Mirja Kuehlewind
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Mirja Kuehlewind
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… David Schinazi
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Mirja Kuehlewind
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Juliusz Chroboczek
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Mirja Kuehlewind
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Juliusz Chroboczek
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Mirja Kuehlewind
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… STARK, BARBARA H
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Mirja Kuehlewind
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Juliusz Chroboczek
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Teco Boot
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Juliusz Chroboczek
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Teco Boot
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Mirja Kuehlewind
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Juliusz Chroboczek
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Mirja Kuehlewind
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Juliusz Chroboczek
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Mirja Kuehlewind
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… Mirja Kühlewind (IETF)
- Re: [babel] Mirja Kühlewind's Discuss on draft-ie… David Schinazi