Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT)
Juliusz Chroboczek <jch@irif.fr> Fri, 09 August 2019 20:07 UTC
Return-Path: <jch@irif.fr>
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 6B76112015B; Fri, 9 Aug 2019 13:07:08 -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 HskY9W6Wo7Gk; Fri, 9 Aug 2019 13:07:06 -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 BF70512006B; Fri, 9 Aug 2019 13:07:05 -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 x79K7033022253; Fri, 9 Aug 2019 22:07:00 +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 71D6F347F7; Fri, 9 Aug 2019 22:07:03 +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 cDjxYJJUw2kU; Fri, 9 Aug 2019 22:07:01 +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 C7AA8347F5; Fri, 9 Aug 2019 22:07:01 +0200 (CEST)
Date: Fri, 09 Aug 2019 22:07:01 +0200
Message-ID: <875zn685ne.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake <d3e3e3@gmail.com>, babel-chairs@ietf.org, babel@ietf.org
In-Reply-To: <156518456148.8400.6644665367614468260.idtracker@ietfa.amsl.com>
References: <156518456148.8400.6644665367614468260.idtracker@ietfa.amsl.com>
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]); Fri, 09 Aug 2019 22:07:00 +0200 (CEST)
X-Miltered: at korolev with ID 5D4DD264.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5D4DD264.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 5D4DD264.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: <https://mailarchive.ietf.org/arch/msg/babel/RKU2BA4-9iu4dgyIYIBrzgynUlA>
Subject: Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and 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." <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: Fri, 09 Aug 2019 20:07:09 -0000
Dear Alvaro, This mail concerns your Discuss point (A) and your Comments. Discuss points (B) and (C) have been discussed in an earlier mail. > (A) Clear Defaults and Operational Guidance > While I appreciate Babel's flexibility in terms of the ability to use > different strategies, I believe that both defaults and clear guidance > should be provided. Given that "not all...strategies will give good > results" and that in most cases these are listed as possible choices, > I don't think that this document "has resolved known design choices" > [BCP9/rfc7127]. The cost/metric computation and route selection > specially concern me because I believe that a robust/clear specification > is at the heart of any routing protocol. After thinking it over very carefully, it is with utmost sadness that I must disagree with you on this latter point. This document does three things: - it makes normative requirements where the issues are well-understood (e.g. strict monotnicity of the metric); - in all cases, it suggests algorithms that are known to work well; - it gives a statement of caution to the adventurous implementer. This gives enough information to the implementer to implement something that works, while not unduly restricting the possibilities of future experimentation. Compare this with RFC 4271, which proudly states: BGP can support any policy conforming to the destination-based forwarding paradigm. even though many such policies will cause persistent oscillations. (By no fault of theirs -- determining statically if a given set of BGP route policies gives rise to oscillations is an open research problem.) (FWIW, early drafts of RFC 6126 used to describe cost and metric computation normatively. It was Joel Halpern who convinced me to move them to an informative appendix, and to give more flexibility in the core protocol. The results we have obtained with RTT-sensitive routing show that he was entirely right.) > (A1) Clear defaults. For example, Appendix B talks about constants/default > values. I would assume that, given the existing experience, that the values > there are probably sensible defaults. Is that not the case? I've rewritten Appendix B in the way you suggest, and added references to it in the document. > (A2) Operational Considerations. Given that Babel can be (and is) used > in different environments, I would like to see guidance to operators as > they deploy the protocol in their networks. An example of the type of > discussion I would like to see expanded is: "a mobile node that is low > on battery may choose to use larger time constants (hello and update > intervals, etc.) than a node that has access to wall power" (§1.1). I've expanded Appendix B. > (B) Error Handling Discussed in a previous mail. > (C) Mandatory Bit Discussed in a previous mail. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > (a) §3.1 introduces the term "urgent TLVs". The whole paragraph has been rewritten, and the terminology unified throughout. > (b) §3.2.2: "SHOULD NOT increment its sequence number (seqno) > spontaneously" When it is ok to increase the seqno spontaneously? It is always ok. The worst it can do is prematurely make some unselected routes unfeasible at downstream nodes, which they will recover from. This is intended as a warning to the implementer familiar with DSDV where seqnos are incremented periodically. > IOW, why not use MUST NOT? This document is fairly consistent in its usage of MUST NOT and SHOULD NOT. You MUST NOT break the network. You SHOULD NOT do harmless but pointless things. > I think it would be better if there was a clear indication of when the > seqno is increased. Scanning the rest of the document, it seems that > those indications are in place. I'm fairly positive this is the case. Starvation avoidance is a crucial part of the algorithm. > (c) There seems to be no specific explanation of how the timers are handled, > what happens when they expire, etc. I have added some precisions. > The only place where hello timers are mentioned is in Appendix A.1...but > that is just an example. This is expected. Hellos are used to compute link cost, and cost computation is in Appendix A. > (d) §3.7.2 includes two instances of "SHOULD make a reasonable attempt > at ensuring that all [reachable] neighbours receive this > update/retraction". What does making "a reasonable attempt" mean? This is expanded in the next two paragraphs. > How can that be Normatively enforced? If an implementation implements one of the two algorithms, it complies. If an implementation implements a different algorithm that can be shown to have the same effect, it complies. If an implementation doesn't implement any algorithm that has a similar effect, it doesn't comply. > (e) §3.7.2 > Finally, a node MAY send a triggered update when the metric for a > given prefix changes in a significant manner, due to a received > update, because a link's cost has changed, or because a different > next hop has been selected. A node SHOULD NOT send triggered updates > for other reasons, such as when there is a minor fluctuation in a > route's metric, when the selected next hop changes, or to propagate a > new sequence number (except to satisfy a request, as specified in > Section 3.8). > How much is "a significant manner"? What about "a minor fluctuation"? > Are the modifiers (next hop change, for example) the only conditions to > take into account, or are they just examples of when these > significant/minor changes may occur? I'm not sure what you're aiming for here. This enumeration lists a set of events for which an implementer might be tempted to send a triggered update, and states that it's a bad idea. > How can these terms be Normatively enforced? In order to comply, an implementation: - doesn't send an update when the metric changes by 1 and nothing else changes; - doesn't send an update when NH changes and nothing else changes; - doesn't send an update when seqno changes and nothing else changes. The boundary between minor and major fluctuation is left to the implementation, which is okay, since in any case that's only a MAY. The intent being that it's reasonable to send a triggered update when the metric fluctuation is large enough to indicate that the route has probably become unusable. If the implementation doesn't follow the MAY, then the fluctuation will be propagated by the next periodic update. > (f) §3.8.1.1: "When a node receives a wildcard route request, it SHOULD > send a full route table dump." When is it ok to not send a full table dump? It is always okay to not send one. The protocol does not rely on full route dump requests. The ability to make a full route dump makes debugging easier, and the feature has very little implementation cost (since you already have code to send a full dump). > IOW, why is MUST not used? Because you might be rate limiting the updates. I've added a sentence to that effect. > (g) §3.8.2.1: "a node SHOULD repeat such a request a small number of times if > no route becomes feasible within a short time." What does "a small number of > times" and "within a short time" mean? How can that be Normatively enforced? > Please be specific. Suggested values are given in Appendix B: Request timeout: initially 2 seconds, doubled every time a request is resent, up to a maximum of three times. I've added a forward ref. > (h) §4.6.9: "Omitted...that should be taken from a preceding Update TLV > in the same address family with the Prefix flag set." What if that > Update TLV is not in the packet? That's part of error handling, your Discuss above. > (i) Security Considerations We've rewritten this section. > (j) Are the appendices intended to be Normative or not? I'm assuming the > answer is no...but I can base that only on the references in the text to > Appendix A.*, pointing to them as examples. I've removed all normative language from the appendices. > What about the others? They are not even referenced in the text. Appendices A and B are referenced. I've added a reference to what was Appendix C (now D). > - Appendix D defines a "stub implementation". This is also valuable > information. But...there's no reference from the text, and Normative language > is used... This is not references in the main body. I don't see a good way to reference it. I've removed all normative language from this appendix, since all the properties stated are consequences of the protocol definition. > Why is this type of implementation (which I would think might be > relatively common) not normative? This appendix doesn't add any new requirements -- it merely describes what is in our opinion the smallest useful implementation that complies with the body of the spec. It is a convenience for the implementer. > - Appendix E simply points to the sample implementation. I've removed the whole appendix. > (k) "The length of..." is used everywhere in the document, but no units are > mentioned. Added suitable boilerplate. > (l) §4: s/SHOULD attempt to maximise the size of the packets/SHOULD maximise > the size of the packets Done. > (m) §4.1.3: The description of AE 1 and 2 says that "Compression is allowed." > -- but it looks like the only place where it can happen is in an Update. It > might be nice to indicate that...and avoid indicating that compression is not > allowed where it can't be done anyway. Done. > (n) rfc8126 should be a Normative reference. Done. > (o) Please include Informative references to rfc6126 and rfc7557. Done. > (p) s/Bellman-Ford protocol/Bellman-Ford algorithm Done. > (q) §2.4: Include an Informative reference to AODV (rfc3561). Done. > (r) §2.4: "if A has selected B as its successor" This is the only place where > "successor" is used. For clarity, perhaps use a different word/description. Done. -- Juliusz
- [babel] Alvaro Retana's Discuss on draft-ietf-bab… Alvaro Retana via Datatracker
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Juliusz Chroboczek
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Juliusz Chroboczek
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Alvaro Retana
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Juliusz Chroboczek
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Juliusz Chroboczek
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Alvaro Retana
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Juliusz Chroboczek
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Juliusz Chroboczek
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Alvaro Retana
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Alvaro Retana
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Juliusz Chroboczek
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Juliusz Chroboczek
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Alvaro Retana
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Juliusz Chroboczek
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Juliusz Chroboczek
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Vigoureux, Martin (Nokia - FR/Paris-Saclay)
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Donald Eastlake