From nobody Thu Jun 1 12:01:39 2017 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 AB9641300E8 for ; Thu, 1 Jun 2017 12:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 hLxeSqtghTYi for ; Thu, 1 Jun 2017 12:01:34 -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 767CD13012A for ; Thu, 1 Jun 2017 12:01:13 -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/56228) with ESMTP id v51J18q9016334; Thu, 1 Jun 2017 21:01:08 +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 857F5EB201; Thu, 1 Jun 2017 21:01:08 +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 OpDyqiKUPpCa; Thu, 1 Jun 2017 21:01:07 +0200 (CEST) Received: from ijon.irif.fr (host30-37-dynamic.25-79-r.retail.telecomitalia.it [79.25.37.30]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C1FEEEB207; Thu, 1 Jun 2017 21:01:05 +0200 (CEST) Date: Thu, 01 Jun 2017 21:01:02 +0200 Message-ID: <87r2z38rdd.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: babel@ietf.org, babel-users@lists.alioth.debian.org In-Reply-To: <16975D69-DAA5-418D-A345-DBD550EE4DB5@apple.com> References: <87h90a9nlz.wl-jch@irif.fr> <16975D69-DAA5-418D-A345-DBD550EE4DB5@apple.com> 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]); Thu, 01 Jun 2017 21:01:08 +0200 (CEST) X-Miltered: at korolev with ID 59306474.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59306474.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 : 59306474.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] [Babel-users] draft-ietf-babel-rfc6126bis-02 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jun 2017 19:01:39 -0000 > I also think Appendix C (Considerations for protocol extensions) > should be changed now that we have mandatory sub-TLVs. I believe I've already done that. It probably needs some fine-tuning, but I think it's complete. -- Juliusz From nobody Fri Jun 2 06:49:48 2017 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 0E8E912EBB5 for ; Fri, 2 Jun 2017 06:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 sCmKzT4g_fGC for ; Fri, 2 Jun 2017 06:49: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 502A4129BCF for ; Fri, 2 Jun 2017 06:49:42 -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/56228) with ESMTP id v52Dnc8T017578; Fri, 2 Jun 2017 15:49: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 C9355EB201; Fri, 2 Jun 2017 15:49: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 sPMfVzuVUOjK; Fri, 2 Jun 2017 15:49:36 +0200 (CEST) Received: from host-37-32.sg.lan (unknown [172.23.37.32]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 35E6CEB28B; Fri, 2 Jun 2017 15:49:35 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/mixed; boundary="Apple-Mail=_25C56B0B-5847-4F62-AA12-97076ACD3F7C" From: Matthieu Boutier In-Reply-To: <87y3tdhy84.wl-jch@irif.fr> Date: Fri, 2 Jun 2017 15:49:35 +0200 Cc: babel-users@lists.alioth.debian.org, babel@ietf.org Message-Id: References: <87h90a9nlz.wl-jch@irif.fr> <70ED4D66-B6BF-4D29-B24F-32A2C6779789@irif.fr> <87y3tdhy84.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3124) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 02 Jun 2017 15:49:39 +0200 (CEST) X-Miltered: at korolev with ID 59316CF2.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59316CF2.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 : 59316CF2.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] source sub-tlv X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 02 Jun 2017 13:49:46 -0000 --Apple-Mail=_25C56B0B-5847-4F62-AA12-97076ACD3F7C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > could you please write up a new version of the I-D with your > encoding? Attached. About requests, I put the two remaining possibilities (1, 3). About the sub-TLV type, the implementation uses an "experimental" one (250) and this draft proposes 128. Matthieu --Apple-Mail=_25C56B0B-5847-4F62-AA12-97076ACD3F7C Content-Disposition: attachment; filename=draft-boutier-babel-source-specific.txt Content-Type: text/plain; name="draft-boutier-babel-source-specific.txt" Content-Transfer-Encoding: quoted-printable Network Working Group M. Boutier Internet-Draft J. Chroboczek Updates: 6126bis IRIF, University of Paris-Diderot (if approved) June 01, 2017 Intended status: Experimental Expires: December 3, 2017 Source-Specific Routing in Babel draft-boutier-babel-source-specific-01 Abstract This document describes an extension to the Babel routing protocol to support source-specific routing. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 3, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Boutier & Chroboczek Expires December 3, 2017 [Page 1] =0C Internet-Draft Source-Specific Routing in Babel June 2017 Table of Contents 1. TODOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction and background . . . . . . . . . . . . . . . . . 3 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. The Source Table . . . . . . . . . . . . . . . . . . . . . 3 3.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 3 3.3. The Table of Pending Requests . . . . . . . . . . . . . . 4 4. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 4 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Source-specific messages . . . . . . . . . . . . . . . . . 5 5.2. Route Acquisition . . . . . . . . . . . . . . . . . . . . 5 5.3. Wildcard requests . . . . . . . . . . . . . . . . . . . . 6 6. Backwards compatibility . . . . . . . . . . . . . . . . . . . 7 6.1. Loop-avoidance . . . . . . . . . . . . . . . . . . . . . . 7 6.2. Starvation and Blackholes . . . . . . . . . . . . . . . . 8 7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 8 7.2. Source-specific Update . . . . . . . . . . . . . . . . . . 9 7.3. Source-specific (Route) Request . . . . . . . . . . . . . 9 7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Security considerations . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Boutier & Chroboczek Expires December 3, 2017 [Page 2] =0C Internet-Draft Source-Specific Routing in Babel June 2017 1. TODOs o check references (Section) for BABEL in 6126bis 2. Introduction and background Source-specific routing (other known as Source Address Dependant Routing, SAD Routing or SADR) is an extension to traditional next-hop routing where packets are routed according to both their destination and their source address. This document describes the source- specific routing extension to the Babel routing protocol as defined in 6126bis [BABEL]. It notably requires the sub-TLV mandatory bit. Background information about source-specific routing is provided in [SS-ROUTING]. 3. Data Structures This extension adds some data to the data structures maintained by a Babel node. 3.1. The Source Table Every Babel node maintains a source table, as described in [BABEL], Section 3.2.4. A source-specific Babel node extends this table with the following field: o the source prefix (sprefix, splen) specifying the source address of packets to which this entry applies. If a source table entry has a zero length source prefix (splen equals to 0), then the entry is a non-source-specific entry, and is treated just like a source table entry defined by the original Babel protocol. With this extension the route entry contains a source which itself contains a source prefix. Notwithstanding the accidental similarity in their names, these are two very different concepts, and should not be confused. 3.2. The Route Table Every Babel node maintains a route table, as described in [BABEL], Section 3.2.5. With this extension, this table is indexed by the 5-tuple (prefix, plen, source prefix, source plen, router-id) obtained from the associated source table entry. Boutier & Chroboczek Expires December 3, 2017 [Page 3] =0C Internet-Draft Source-Specific Routing in Babel June 2017 If a route table entry has a zero length source prefix, then the entry is a non-source-specific entry, and is treated just like a route table entry defined by the original Babel protocol. 3.3. The Table of Pending Requests Every Babel node maintains a table of pending requests, as described in [BABEL], Section 3.2.6. A source-specific Babel node extends this table with the following entry: o the source prefix being requested. 4. Data Forwarding In next-hop routing, if two routing table entries overlap, then one is necessarily more specific than the other; the "longest prefix rule" specifies that the most specific applicable routing table entry is chosen. With source-specific routing, there might no longer be a most specific applicable prefix: two routing table entries might match a given packet without one necessarily being more specific than the other. Consider for example the following fragment of a routing table: (2001:DB8:0:1::/64, ::/0, A) (::/0, 2001:DB8:0:2::/64, B) This specifies that all packets with destination in 2001:DB8:0:1::/64 are to be routed through A, while packets with a source in 2001:DB8: 0:2::/64 are to be routed through B. A packet with source 2001:DB8:0: 2::42 and destination 2001:DB8:0:1::57 matches both rules, although neither is more specific than the other. A choice is necessary, and unless the choice being made is the same on all routers in a routing domain, persistent routing loops may occur. A Babel implementation MUST choose routing table entries by using the so-called destination-first ordering, where a routing table entry R1 is preferred to a routing table entry R2 when either R1's destination prefix is more specific than R2's, or the destination prefixes are equal and R1's source prefix is more specific than R2's. (In more formal terms, routing table entries are compared using the lexicographic product of the destination prefix ordering by the source prefix ordering.) In practice, this means that a source-specific Babel implementation must take care that any lower layer that performs packet forwarding Boutier & Chroboczek Expires December 3, 2017 [Page 4] =0C Internet-Draft Source-Specific Routing in Babel June 2017 obey this semantics. In particular: o If the lower layers implement the destination-first ordering, then the Babel implementation MAY use them directly; o If the lower layers can hold source-specific routes, but not with the right semantics, then the Babel implementation MUST disambiguate the routing table by using a suitable disambiguation algorithm (see [SS-ROUTING] for such an algorithm); o If the lower layers cannot hold source-specific routes, then a Babel implementation MUST silently ignore any source-specific routes. 5. Protocol Operation This extension does not fundamentally change the operation of the Babel protocol. We only described the fundamental differences between the original protocol and the extension in this section. The other mechanisms described in [BABEL] (Section 3) may be infered by using pairs of (destination, source) prefixes instead of just (destination) prefixes. 5.1. Source-specific messages A route of this extension with a zero-length source prefix is the same than a route without source prefix (a route of the classical Babel). In both of the cases, packets are accepted independantly of their source address. Thus, a route is said source-specific only if its source prefix has a non-zero length. Three messages are used to communicate informations on routes: Updates, Route Requests and Seqno Requests. With this extension, these messages carry an additionnal source prefix if (and only if) the corresponding route is source-specific. More formally, an Update, a Route Request and a Seqno Request MUST carry a source prefix if they concern a source-specific route (non-zero length source prefix) and MUST NOT carry a source prefix otherwise (zero length source prefix). A message which carry a source prefix is said source-specific. 5.2. Route Acquisition When a non-source-specific Babel node receives a source-specific update, it just ignores it. On receipt of a source-specific update (id, prefix, source prefix, seqno, metric), a source-specific Babel node behaves as described in [BABEL] Section 3.5.4 though indexing entries by (neigh, id, prefix, Boutier & Chroboczek Expires December 3, 2017 [Page 5] =0C Internet-Draft Source-Specific Routing in Babel June 2017 source prefix). When a source-specific Babel node receives a non- source-specific update, it MUST consider this update as carrying a zero length source prefix. 5.3. Wildcard requests TODO: behaviour to be defined. 5.3.1. Proposal 1 The original Babel protocol states that when a node receives a wildcard route request, it SHOULD send a full routing table dump. This extension does not change this statement: a source-specific node SHOULD send a full routing table dump when receiving a wildcard request. Source-specific wildcard requests does not exist: a wildcard request SHOULD NOT carry a source prefix. 5.3.2. Proposal 3 The Babel protocol provides the ability to request a full routing table dump by sending a "wildcard request", a route request with the AE field set to 0. As the original protocol has no source-specific routes, such a request may only concern non-source-specific routes. This extension does not modify the semantics of wildcard requests in that sense: a wildcard request prompts the receiver to send its non- source-specific routes only, and a Babel node SHOULD NOT send any source-specific updates in reply to a wildcard request. To obtain a dump of the source-specific routes, a source-specific wildcard request MUST be used. A source-specific wildcard request is a wildcard request carrying a zero length source prefix. When a node receives a source-specific wildcard request, it SHOULD send a dump of its routes which are source-specific "only". It SHOULD NOT send any non-source-specific routes in reply to a source- specific wildcard request. It SHOULD NOT send any source-specific routes which are under the effect of a future extension. Such extension should detail how to handle the possible combinations. In consequence, a node requiring a full routing table dump must send both a non-source-specific wildcard request and a source-specific wildcard request. Boutier & Chroboczek Expires December 3, 2017 [Page 6] =0C Internet-Draft Source-Specific Routing in Babel June 2017 5.3.3. Note on Overhead between (1) and (3) Sending one wildcard request (1) instead of a few something-specific wildcard requests (3) in a negligible gain. Non-source-specific nodes sending requests to source-specific nodes may reduce the global overhead with (3). But, if the network has no source-specific route, there is no overhead to reduce; if there is only a few source-specific routes (like in a home network), the overhead would be negligible. Thus, the interesting case is when there is a lot of source-specific routes. We can imagine a network with a source-specific backbone announcing a default route and catching all trafic. Good old routers not supporting this extensions would be put at some backbone leafs. Is sbabeld part of that use case ? Couldn't we just send a Route Request for *default* ? 6. Backwards compatibility The protocol extension defined in this document is, to a great extent, interoperable with the base protocol defined in [BABEL] (and all its known extensions). More precisely, if non-source-specific routers and source-specific routers are mixed in a single routing domain, Babel's loop-avoidance properties are preserved, and, in particular, no persistent routing loops will occur. 6.1. Loop-avoidance The extension defined in this protocol uses a new Mandatory sub-TLV to carry the source prefix information. As discussed in Section 4 of [BABEL], this encoding ensures that non-source-specific routers will silently ignore the whole TLV, which is necessary to avoid persistent routing loops in hybrid networks. Consider two nodes A and B, with A source-specific announcing a route to (D, S). Suppose that B ignores the source prefix information when it receives the update, and reannounces it as D. This is reannounced to A, which treats it as (D, ::/0). Packets destined to D but not sourced in S will be forwarded by A to B, and by B to A, causing a persistent routing loop: (D,S) (D) <-- <-- ------ A ----------------- B --> Boutier & Chroboczek Expires December 3, 2017 [Page 7] =0C Internet-Draft Source-Specific Routing in Babel June 2017 (D,::/0) 6.2. Starvation and Blackholes In general, discarding of source-specific routes by non-source- specific routers will cause routing starvation. Intuitively, unless there are enough non-source-specific routes in the network, non- source-specific routers will suffer starvation, and discard packets for destinations that are only announced by source-specific routers. A simple yet sufficient condition for avoiding starvation is to build a connected source-specific backbone that includes all of the edge routers, and announce a (non-source-specific) default route towards the backbone. However, introducing such a default route in the network may in the same time introduce a blackhole. This tradeoff is let to the administrator. 7. Protocol Encoding This extension defines a new sub-TLV used to carry a source prefix by the three following existing messages: Update, Route Request and Seqno Request. 7.1. Source Prefix sub-TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type =3DTODO:128?| Length | Source Plen | Source Prefix... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fields: Type Set to TODO:128? to indicate a Source Prefix sub-TLV. Length The length of the body, exclusive of the Type and Length fields. Source Plen The length of the advertised source prefix. This MUST NOT be 0. Source Prefix The source prefix being advertised. This field's size is (Source Plen)/8 rounded upwards. The Source Prefix field's encoding is the same than the Prefix's. It is defined by the AE field of the corresponding TLV. Remark that this sub-TLV is a Mandatory sub-TLV. The whole TLV MUST be ignored if that TLV is not recognized. Otherwise, routing loops may occur. Boutier & Chroboczek Expires December 3, 2017 [Page 8] =0C Internet-Draft Source-Specific Routing in Babel June 2017 7.2. Source-specific Update The source-specific Update is an Update TLV with a Source Prefix sub- TLV. It advertises or retracts source-specific routes in the same manner than routes with non-source-specific Updates (see [BABEL]). Contrary to the destination prefix, this extension does not compress the source prefix attached to Updates. The destination prefix uses compression as defined in [BABEL] for Updates with Mandatory extensions. TODO: Recall how is defined compression for Updates with Mandatory extensions. Prefix Compression, default prefix update, router id update. 7.3. Source-specific (Route) Request TODO: A source-specific Route Request prompts the receiver to send an update for a given pair of destination and source prefixes. It MUST NOT be used to request a full routing table dump. The Source Prefix sub-TLV of a wildcard source-specific Route Request (Request with AE equals to 0 and a Source Prefix sub-TLV) MIGHT be ignored: a receiver MIGHT reply by a full routing table dump. 7.4. Source-Specific Seqno Request A source-specific Seqno Request is just like a Seqno Request for a source-specific route. It uses the same mechanisms described in [BABEL]. 8. IANA Considerations IANA is instructed to add the following entry to the "Babel sub-TLV Types" registry: +------------+---------------+-----------------+ | Type | Name | Reference | +------------+---------------+-----------------+ | TODO: 128? | Source Prefix | (this document) | +------------+---------------+-----------------+ 9. Security considerations The extension defined in this document adds a new sub-TLV to three TLVs already present in the original Babel protocol. It does not by itself change the security properties of the protocol. Boutier & Chroboczek Expires December 3, 2017 [Page 9] =0C Internet-Draft Source-Specific Routing in Babel June 2017 10. References 10.1. Normative References [BABEL] Chroboczek, J., "The Babel Routing Protocol", Internet Draft draft-ietf-babel-rfc6126bis-02, May 2017. 10.2. Informative References [SS-ROUTING] Boutier, M. and J. Chroboczek, "Source-Specific Routing", August 2014. In Proc. IFIP Networking 2015. A slightly earlier version is available online from http://arxiv.org/pdf/1403.0445. Authors' Addresses Matthieu Boutier IRIF, University of Paris-Diderot Case 7014 75205 Paris Cedex 13, France Email: boutier@irif.fr Juliusz Chroboczek IRIF, University of Paris-Diderot Case 7014 75205 Paris Cedex 13, France Email: jch@irif.fr Boutier & Chroboczek Expires December 3, 2017 [Page 10] =0C --Apple-Mail=_25C56B0B-5847-4F62-AA12-97076ACD3F7C Content-Disposition: attachment; filename=draft-boutier-babel-source-specific.xml Content-Type: application/xml; name="draft-boutier-babel-source-specific.xml" Content-Transfer-Encoding: 7bit Source-Specific Routing in Babel IRIF, University of Paris-Diderot
Case 7014 75205 Paris Cedex 13 France boutier@irif.fr
IRIF, University of Paris-Diderot
Case 7014 75205 Paris Cedex 13 France jch@irif.fr
This document describes an extension to the Babel routing protocol to support source-specific routing.
check references (Section) for BABEL in 6126bis
Source-specific routing (other known as Source Address Dependant Routing, SAD Routing or SADR) is an extension to traditional next-hop routing where packets are routed according to both their destination and their source address. This document describes the source-specific routing extension to the Babel routing protocol as defined in 6126bis . It notably requires the sub-TLV mandatory bit. Background information about source-specific routing is provided in .
This extension adds some data to the data structures maintained by a Babel node.
Every Babel node maintains a source table, as described in , Section 3.2.4. A source-specific Babel node extends this table with the following field: the source prefix (sprefix, splen) specifying the source address of packets to which this entry applies. If a source table entry has a zero length source prefix (splen equals to 0), then the entry is a non-source-specific entry, and is treated just like a source table entry defined by the original Babel protocol. With this extension the route entry contains a source which itself contains a source prefix. Notwithstanding the accidental similarity in their names, these are two very different concepts, and should not be confused.
Every Babel node maintains a route table, as described in , Section 3.2.5. With this extension, this table is indexed by the 5-tuple (prefix, plen, source prefix, source plen, router-id) obtained from the associated source table entry. If a route table entry has a zero length source prefix, then the entry is a non-source-specific entry, and is treated just like a route table entry defined by the original Babel protocol.
Every Babel node maintains a table of pending requests, as described in , Section 3.2.6. A source-specific Babel node extends this table with the following entry: the source prefix being requested.
In next-hop routing, if two routing table entries overlap, then one is necessarily more specific than the other; the "longest prefix rule" specifies that the most specific applicable routing table entry is chosen. With source-specific routing, there might no longer be a most specific applicable prefix: two routing table entries might match a given packet without one necessarily being more specific than the other. Consider for example the following fragment of a routing table: (2001:DB8:0:1::/64, ::/0, A) (::/0, 2001:DB8:0:2::/64, B) This specifies that all packets with destination in 2001:DB8:0:1::/64 are to be routed through A, while packets with a source in 2001:DB8:0:2::/64 are to be routed through B. A packet with source 2001:DB8:0:2::42 and destination 2001:DB8:0:1::57 matches both rules, although neither is more specific than the other. A choice is necessary, and unless the choice being made is the same on all routers in a routing domain, persistent routing loops may occur. A Babel implementation MUST choose routing table entries by using the so-called destination-first ordering, where a routing table entry R1 is preferred to a routing table entry R2 when either R1's destination prefix is more specific than R2's, or the destination prefixes are equal and R1's source prefix is more specific than R2's. (In more formal terms, routing table entries are compared using the lexicographic product of the destination prefix ordering by the source prefix ordering.) In practice, this means that a source-specific Babel implementation must take care that any lower layer that performs packet forwarding obey this semantics. In particular: If the lower layers implement the destination-first ordering, then the Babel implementation MAY use them directly; If the lower layers can hold source-specific routes, but not with the right semantics, then the Babel implementation MUST disambiguate the routing table by using a suitable disambiguation algorithm (see for such an algorithm); If the lower layers cannot hold source-specific routes, then a Babel implementation MUST silently ignore any source-specific routes.
This extension does not fundamentally change the operation of the Babel protocol. We only described the fundamental differences between the original protocol and the extension in this section. The other mechanisms described in (Section 3) may be infered by using pairs of (destination, source) prefixes instead of just (destination) prefixes.
A route of this extension with a zero-length source prefix is the same than a route without source prefix (a route of the classical Babel). In both of the cases, packets are accepted independantly of their source address. Thus, a route is said source-specific only if its source prefix has a non-zero length. Three messages are used to communicate informations on routes: Updates, Route Requests and Seqno Requests. With this extension, these messages carry an additionnal source prefix if (and only if) the corresponding route is source-specific. More formally, an Update, a Route Request and a Seqno Request MUST carry a source prefix if they concern a source-specific route (non-zero length source prefix) and MUST NOT carry a source prefix otherwise (zero length source prefix). A message which carry a source prefix is said source-specific.
When a non-source-specific Babel node receives a source-specific update, it just ignores it. On receipt of a source-specific update (id, prefix, source prefix, seqno, metric), a source-specific Babel node behaves as described in [BABEL] Section 3.5.4 though indexing entries by (neigh, id, prefix, source prefix). When a source-specific Babel node receives a non-source-specific update, it MUST consider this update as carrying a zero length source prefix.
TODO: behaviour to be defined.
The original Babel protocol states that when a node receives a wildcard route request, it SHOULD send a full routing table dump. This extension does not change this statement: a source-specific node SHOULD send a full routing table dump when receiving a wildcard request. Source-specific wildcard requests does not exist: a wildcard request SHOULD NOT carry a source prefix.
The Babel protocol provides the ability to request a full routing table dump by sending a "wildcard request", a route request with the AE field set to 0. As the original protocol has no source-specific routes, such a request may only concern non-source-specific routes. This extension does not modify the semantics of wildcard requests in that sense: a wildcard request prompts the receiver to send its non-source-specific routes only, and a Babel node SHOULD NOT send any source-specific updates in reply to a wildcard request. To obtain a dump of the source-specific routes, a source-specific wildcard request MUST be used. A source-specific wildcard request is a wildcard request carrying a zero length source prefix. When a node receives a source-specific wildcard request, it SHOULD send a dump of its routes which are source-specific "only". It SHOULD NOT send any non-source-specific routes in reply to a source-specific wildcard request. It SHOULD NOT send any source-specific routes which are under the effect of a future extension. Such extension should detail how to handle the possible combinations. In consequence, a node requiring a full routing table dump must send both a non-source-specific wildcard request and a source-specific wildcard request.
Sending one wildcard request (1) instead of a few something-specific wildcard requests (3) in a negligible gain. Non-source-specific nodes sending requests to source-specific nodes may reduce the global overhead with (3). But, if the network has no source-specific route, there is no overhead to reduce; if there is only a few source-specific routes (like in a home network), the overhead would be negligible. Thus, the interesting case is when there is a lot of source-specific routes. We can imagine a network with a source-specific backbone announcing a default route and catching all trafic. Good old routers not supporting this extensions would be put at some backbone leafs. Is sbabeld part of that use case ? Couldn't we just send a Route Request for *default* ?
The protocol extension defined in this document is, to a great extent, interoperable with the base protocol defined in (and all its known extensions). More precisely, if non-source-specific routers and source-specific routers are mixed in a single routing domain, Babel's loop-avoidance properties are preserved, and, in particular, no persistent routing loops will occur.
The extension defined in this protocol uses a new Mandatory sub-TLV to carry the source prefix information. As discussed in Section 4 of , this encoding ensures that non-source-specific routers will silently ignore the whole TLV, which is necessary to avoid persistent routing loops in hybrid networks. Consider two nodes A and B, with A source-specific announcing a route to (D, S). Suppose that B ignores the source prefix information when it receives the update, and reannounces it as D. This is reannounced to A, which treats it as (D, ::/0). Packets destined to D but not sourced in S will be forwarded by A to B, and by B to A, causing a persistent routing loop:
(D,::/0) ]]>
In general, discarding of source-specific routes by non-source-specific routers will cause routing starvation. Intuitively, unless there are enough non-source-specific routes in the network, non-source-specific routers will suffer starvation, and discard packets for destinations that are only announced by source-specific routers. A simple yet sufficient condition for avoiding starvation is to build a connected source-specific backbone that includes all of the edge routers, and announce a (non-source-specific) default route towards the backbone. However, introducing such a default route in the network may in the same time introduce a blackhole. This tradeoff is let to the administrator.
This extension defines a new sub-TLV used to carry a source prefix by the three following existing messages: Update, Route Request and Seqno Request.
Fields: Set to TODO:128? to indicate a Source Prefix sub-TLV. The length of the body, exclusive of the Type and Length fields. The length of the advertised source prefix. This MUST NOT be 0. The source prefix being advertised. This field's size is (Source Plen)/8 rounded upwards. The Source Prefix field's encoding is the same than the Prefix's. It is defined by the AE field of the corresponding TLV. Remark that this sub-TLV is a Mandatory sub-TLV. The whole TLV MUST be ignored if that TLV is not recognized. Otherwise, routing loops may occur.
The source-specific Update is an Update TLV with a Source Prefix sub-TLV. It advertises or retracts source-specific routes in the same manner than routes with non-source-specific Updates (see ). Contrary to the destination prefix, this extension does not compress the source prefix attached to Updates. The destination prefix uses compression as defined in for Updates with Mandatory extensions. TODO: Recall how is defined compression for Updates with Mandatory extensions. Prefix Compression, default prefix update, router id update.
TODO: A source-specific Route Request prompts the receiver to send an update for a given pair of destination and source prefixes. It MUST NOT be used to request a full routing table dump. The Source Prefix sub-TLV of a wildcard source-specific Route Request (Request with AE equals to 0 and a Source Prefix sub-TLV) MIGHT be ignored: a receiver MIGHT reply by a full routing table dump.
A source-specific Seqno Request is just like a Seqno Request for a source-specific route. It uses the same mechanisms described in .
IANA is instructed to add the following entry to the "Babel sub-TLV Types" registry: TypeNameReference TODO: 128?Source Prefix(this document)
The extension defined in this document adds a new sub-TLV to three TLVs already present in the original Babel protocol. It does not by itself change the security properties of the protocol.
The Babel Routing Protocol Source-Specific Routing In Proc. IFIP Networking 2015. A slightly earlier version is available online from http://arxiv.org/pdf/1403.0445. --Apple-Mail=_25C56B0B-5847-4F62-AA12-97076ACD3F7C-- From nobody Sun Jun 4 15:01:45 2017 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 B219512957C for ; Sun, 4 Jun 2017 15:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtzcEAO5lvxP for ; Sun, 4 Jun 2017 15:01:40 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 B42AD126DD9 for ; Sun, 4 Jun 2017 15:01:40 -0700 (PDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1496613692; bh=0H9pbGkF5MjMaQ8zfyxpwJu44KLbz1B3RjNmWsS7TXc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=yj5mVX4pLO/xvIQH0FEHSuiXiLIHm2Bz1I6FWRSabOp/DKHyyE4WB8MLjO0ATiZ4g 9U1q/is/oYuL7uaFPMiGdJgHJjbmfc+cEoG0gKWmiyO2uXsuL7oXP4fLiD71wtEEBt 4Ya/O/aLd92y+bK5RMfGVTnylGrNa3XtdbJomS1DxcG75Oq4GZQLnfu5L0v8rwfgev AeaiT1zW70toWANOfsSuKfZJFe/porBzyTWwp1Ro9PUsEtrAMd8a+OYl52Y2bEHEd4 uRIY1Hpz6yRdPobV88QVpCkU60+Me4c5sLO9ZxeGvJ7SGwvcgY6LA6lRUBPdIySnCS MZJUxi0msvaAw== To: Juliusz Chroboczek Cc: babel@ietf.org, babel-users@lists.alioth.debian.org References: <87h90a9nlz.wl-jch@irif.fr> Date: Mon, 05 Jun 2017 00:01:30 +0200 In-Reply-To: <87h90a9nlz.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Wed, 24 May 2017 19:22:00 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87poeje7k5.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] draft-ietf-babel-rfc6126bis-02 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jun 2017 22:01:44 -0000 Juliusz Chroboczek writes: > Dear all, > > I've just published a new version of the Babel protocol specification: > > https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-02 I read it, and I think the updates are an improvement. I think the specification of the extension mechanism and mandatory sub-TLVs is quite clear. One thing that might be worth adding now that there's a section about parser state, is what to do with parse errors (i.e., a malformed TLV, not one that should be ignored). I guess the right thing to do is to discard the rest of the packet when a parse error is encountered? Other than that, a few nits: Section 3.8.1.2, second paragraph: "Otherwise, if the requested router-id is not its own..." Not clear what "otherwise" refers to, exactly. Section 4.4, second paragraph: "Sub-TLVs have the same structure as TLVs. With the exception of PAD1, all TLVs have the following structure:" Second "TLVs" should probably be "sub-TLVs"? Don't think Appendix C was updated to reflect mandatory sub-TLVs? -Toke From nobody Sun Jun 4 17:59:26 2017 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 AE460124B0A for ; Sun, 4 Jun 2017 17:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 ezH63St3sUIA for ; Sun, 4 Jun 2017 17:59:23 -0700 (PDT) Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (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 1B2ED1200C1 for ; Sun, 4 Jun 2017 17:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1496624362; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VM3J/laivSLDd3s4gT77vdr8rVDkERD2g7UIAPRLL2I=; b=ZAt6wdMjfl0bkhruxH/rPFp8bndqdp4KqK4zZTGuhbcixQiVog/uiW/ApA0jJT+6 jPiOhytD4dRHuwxDO2pN5skdRMNwJj6ffyi2MGJgZGvUU94pnqtuvkiWk50j2tBb fDJfpcS9a5tailkqEEH/pqkvtZ9CVaZGQSBIbZ3PD4qnDtNHQdHlEWgAaZhK3XfD rt2W4nM3NwRcTh5ObWf9CYsYqnodHPT4pWp0fXcdkVaOWtIHvCm0TL569cp5285b rgO2nMqjJRmI9LJCTu39et6FbwB8QYEaEznoYzUDknhgjMaZ7wBXNGKd5atPk3ZG bEvPFg4puA9Z4qX95D4Ztw==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id 5A.8C.02740.9ECA4395; Sun, 4 Jun 2017 17:59:22 -0700 (PDT) X-AuditID: 11ab0216-12b3a9a000000ab4-09-5934ace972bc Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay8.apple.com (Apple SCV relay) with SMTP id ED.98.21490.6ECA4395; Sun, 4 Jun 2017 17:59:19 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.59.37] (unknown [17.153.59.37]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OR100DASUQT6E60@nwk-phonehomebzp-sz01.apple.com>; Sun, 04 Jun 2017 17:59:18 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87tw41hwj1.wl-jch@irif.fr> Date: Sun, 04 Jun 2017 17:59:16 -0700 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , babel@ietf.org Message-id: References: <87y3tmbg1e.wl-jch@irif.fr> <87zie2gylh.fsf@alrua-x1> <87h90abbp0.wl-jch@irif.fr> <87efvebb9x.wl-jch@irif.fr> <513D2D6A-E00A-4D46-9762-8D57F0E57B22@iki.fi> <8760gqb9ss.wl-jch@irif.fr> <87shjus424.fsf@alrua-karlstad> <87wp969tvn.wl-jch@irif.fr> <87o9uhrwin.fsf@alrua-karlstad> <87r2zdta7c.wl-jch@irif.fr> <87tw41hwj1.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUi2FCYpvtqjUmkwa3twhZbFnWzWMxvXcZm sfX9CnYHZo8lS34yeSze8pbRY8uhi2wBzFFcNimpOZllqUX6dglcGec/XGcpmMFdsfL0FrYG xvccXYycHBICJhLf5k9h7WLk4hASWMsk8XrxByaYxNwVe6ESxxglZnbvZgVJ8AoISvyYfI+l i5GDg1lAXuLgeVmQMLOAlsT3R60sEPXzmSRO3trPApIQFpCW6LpwlxWkXljAUWLKJzsQkw2o /sAaIxCTU0BDYvmxZJBiFgFViRMNR5ghJvpLbHq5lx1iqY3EtUXX2CCmT2KW+HOlmw0kISKg IrF82jN2iJNlJW7NvsQMUiQhsINN4sLRnWwTGIVnIbl6FsLVs5BcvYCReRWjcG5iZo5uZp6R kV5iQUFOql5yfu4mRlCwr2YS28F477XhIUYBDkYlHt6EFSaRQqyJZcWVuYcYpTlYlMR5vz40 ihQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAaK4erL38TnFCnOnPb2Ey07zlNLKksj/cWrFR K/98MievQMEbm7WpD5NSOV8btDpbJL6ZrtOX0eike8t949FfxxRzazNlD14PTTZe/jb4zOa4 rYf1eTnzwmvalG7tdpr69u9nz+VSG89aMV0vncPjn7/70fnKzgL/nLelxW9Nn1sG+im42D5T YinOSDTUYi4qTgQA2kIjN1cCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUiON3OQff5GpNIg9OnBCy2LOpmsZjfuozN Yuv7FewOzB5Llvxk8li85S2jx5ZDF9kCmKO4bFJSczLLUov07RK4Ms5/uM5SMIO7YuXpLWwN jO85uhg5OSQETCTmrtjL2sXIxSEkcIxRYmb3blaQBK+AoMSPyfdYuhg5OJgF5CUOnpcFCTML aEl8f9TKAlE/n0ni5K39LCAJYQFpia4Ld1lB6oUFHCWmfLIDMdmA6g+sMQIxOQU0JJYfSwYp ZhFQlTjRcIQZYqK/xKaXe9khltpIXFt0jQ1i+iRmiT9XutlAEiICKhLLpz1jhzhZVuLW7EvM ExgFZiE5dBbCobOQHLqAkXkVo0BRak5ipYVeYkFBTqpecn7uJkZQaDYUpu1gbFpudYhRgINR iYdXItMkUog1say4MvcQowQHs5IIb4Y1UIg3JbGyKrUoP76oNCe1+BBjFdADE5mlRJPzgXGT VxJvaGJiYGJsbGZsbG5iThVhJXFei/1GkUIC6YklqdmpqQWpRTDLmTg4pRoY05YzaHEeOZcc /W+5rfWMrPxO6yKhAGuZuepTJtX+Plpza1fZIb93/OHPU3af2Vz6i6HSVrj37YNDrNc5T7ZM CC/u2nLwu+777xd65/Ybbt4fm59Xkyl8WH7y/6I5L1M4X8evtJ77SUFnotfKmRE7i6X0ci0/ PHtx+ulMyaBC+yumBceihJZdUmIpzkg01GIuKk4EAOM+udeoAgAA Archived-At: Subject: Re: [babel] Mandatory sub-TLVs in Next Hop and Router-ID X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jun 2017 00:59:24 -0000 I guess I shouldn't read email before my morning coffee :) The good news is that while I misunderstood the emails, the document was clear and I didn't find ambiguity there. Now that I've given it more thought, I agree with this design choice. David > On May 31, 2017, at 08:32, Juliusz Chroboczek wrote: > >> I'm a little late to the party here, but I think I agree with where the >> discussion landed, as in treat NextHop and RouterID like any other TLV, >> fully ignore it in the presence of an unknown mandatory sub TLV. > > Er... no. The conclusion is that Next Hop and Router-ID TLVs are honoured > even if ignored due to an unknown mandatory sub-TLV. > > The rationale is that the current next hop and router-id are part of the > parser's state, and that the packet is parsed with no reference to > sub-TLVs. Only after the packet is parsed are some TLVs dropped. This > way, the produced parse tree is identical no matter which sub-TLVs are > honoured by a given implementation, which makes it possible to build tools > such as tcpdump that need to parse a packet but don't honour any sub-TLVs. > > Folks, please read the relevant sections in -02, and let me know if the > current text is not clear in any way. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Mon Jun 5 15:05:33 2017 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 D44F4126C26 for ; Mon, 5 Jun 2017 15:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 7HaMxnVhwGrP for ; Mon, 5 Jun 2017 15:05:29 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 A1E0B12700F for ; Mon, 5 Jun 2017 15:05:29 -0700 (PDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1496700326; bh=4fASfE6+lQDLZJiKjjXu+/+e5vpXD7INaW14um5FAzs=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=OkU68dcIZgoNG/yyFL2Z6M04UWXyeALVeBfTP06AQeRd2Wa5uaBnp58GFYzbgQvZZ 9soICAPe8o08k9+l/4gEhUXq2ElGOWaVbWetNkX13ikZSGT5wWfTjicbLcswKGT7rU 56ii6MbXwYsW4ZTes2QiYh9QRwvSzO0R5AX0Sc0J0m5DxHjSmM8DXLKor23SgfxazS fvJG94ZSXkNnIa0awhl9Cya9ITQtvi4OrCbmVkHVfHa/d9oiM5EKDhsUiIBsUI4a6H 0jbLD+6fJwIUWMmtwUDrlpNyym++bqIRCInRM94kY5hyYOSo83S3Z0avQSR6AozfVs 8kGhWvQwho4Bg== To: Juliusz Chroboczek Cc: babel@ietf.org, babel-users@lists.alioth.debian.org References: <87h90a9nlz.wl-jch@irif.fr> Date: Tue, 06 Jun 2017 00:05:25 +0200 In-Reply-To: <87h90a9nlz.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Wed, 24 May 2017 19:22:00 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87wp8qccpm.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] draft-ietf-babel-rfc6126bis-02 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jun 2017 22:05:32 -0000 Juliusz Chroboczek writes: > Both babeld and sbabeld have support for mandatory bits in their > "mandatory" branches. I'll wait a few days to see if there are any > flaws in this proposal, then merge into trunk. Please consider > implementing mandatory bits if you have an implementation of Babel. I have implemented support for subtlvs and the mandatory bit in Bird[1][2] and confirmed that it correctly discards source-specific updates from Matthieu's branch. -Toke [1] Mirror of the Bird repo with my changes: https://github.com/tohojo/bird [2] Patch posting to the Bird mailing list: http://trubka.network.cz/pipermail/bird-users/2017-June/011316.html From nobody Tue Jun 6 08:02:36 2017 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 064AA1294CC for ; Tue, 6 Jun 2017 08:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_E0TBoqg01M for ; Tue, 6 Jun 2017 08:02:31 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 E029E1293F4 for ; Tue, 6 Jun 2017 08:02:30 -0700 (PDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1496761343; bh=T4COeK7KZKUxpFd5YWRQJI72PzKCiJ4K6wqytv1Mf+Q=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=YsFo5C+uhAAd4ZLIijdEi/fZ/VVQujzq2JhUuHAPOKbeG16WxNuiBmqGNo/h3OBhE gWGhsqWJ30aCDkYx5w1R/814Du9fWcAqyK3NfhiqZ5PD0udJOnY2swhExAncSnYOkr bfa88RrHdBMxsXdD5lQruLS/t8GujJ+xGdUqNu8TpmUGYbDi/U35UDgqs4CSAw5WpU dEa2eqhc+8I3YBC87CKe72PYm+jo4sW6HTuUsI1MLxtZuTeRpAvpcJJodDXy7bdcmL U/wsjhZqRcythm12XpBG//6N3aZEZ7sw440tXILCM2xQANgGgRbXWnQA7K8I18bx6c JMgRfVQUukTwQ== To: Juliusz Chroboczek Cc: Matthieu Boutier , babel-users@lists.alioth.debian.org, babel@ietf.org References: <87h90a9nlz.wl-jch@irif.fr> <70ED4D66-B6BF-4D29-B24F-32A2C6779789@irif.fr> <87y3tdhy84.wl-jch@irif.fr> Date: Tue, 06 Jun 2017 17:02:21 +0200 In-Reply-To: <87y3tdhy84.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Wed, 31 May 2017 16:55:55 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87shjdcg76.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] source sub-tlv X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jun 2017 15:02:34 -0000 Juliusz Chroboczek writes: > I support (3). Last time I spoke to him, Toke supported (4). I am > opposed to (2). I can live with (1). Well, I can see the point in retaining wildcard requests for speeding up convergence when a new node joins a network. Don't recall expressing a preference on this matter before, but on the other hand it's quite likely that Juliusz remembers that better than me... ;) However, if this (helping new nodes) is the only use case, to me the simplest seems to be option (1), i.e., a wildcard request translates to "give me all routes you have, regardless of extensions". That's dead simple to implement, and I'm not convinced that "mixed networks" (where nodes speak different extensions) are going to be common enough to warrant the complexity of what is essentially an optimisation for that one case (i.e., option (3)). So I prefer (1), but can live with (3). -Toke From nobody Tue Jun 6 12:59:06 2017 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 AB66F12751F for ; Tue, 6 Jun 2017 12:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 dwFMdnvrQCqU for ; Tue, 6 Jun 2017 12:59: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 A04AD128B37 for ; Tue, 6 Jun 2017 12:59:03 -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/56228) with ESMTP id v56Jx09j011899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Jun 2017 21:59:01 +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/56228) with ESMTP id v56JwxxB029551; Tue, 6 Jun 2017 21:58:59 +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 22BF4EB201; Tue, 6 Jun 2017 21:58:59 +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 k2BfS7qd_ZBM; Tue, 6 Jun 2017 21:58:58 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0B306EB207; Tue, 6 Jun 2017 21:58:58 +0200 (CEST) Date: Tue, 06 Jun 2017 21:59:08 +0200 Message-ID: <8737bcevlf.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: babel@ietf.org, babel-users@lists.alioth.debian.org In-Reply-To: <87wp8qccpm.fsf@alrua-x1> References: <87h90a9nlz.wl-jch@irif.fr> <87wp8qccpm.fsf@alrua-x1> 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, 06 Jun 2017 21:59:01 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 06 Jun 2017 21:59:00 +0200 (CEST) X-Miltered: at korolev with ID 59370984.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 59370983.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59370984.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 59370983.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 : 59370984.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 59370983.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] draft-ietf-babel-rfc6126bis-02 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jun 2017 19:59:06 -0000 > I have implemented support for subtlvs and the mandatory bit in > Bird[1][2] and confirmed that it correctly discards source-specific > updates from Matthieu's branch. Thanks, Toke! I should be a little more free starting this week-end, I'll try to get mandatory bits in all remaining implementations. The Nexedi fork of babeld will probably be the most difficult, and require some face-to-face meetings. (But they're a fun bunch to work with, and they usually buy me lunch, so that's okay.) -- Juliusz From nobody Fri Jun 9 07:56:11 2017 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 9A7D3129B66 for ; Fri, 9 Jun 2017 07:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 gjbuUZab5a54 for ; Fri, 9 Jun 2017 07:56:08 -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 1D751129AE8 for ; Fri, 9 Jun 2017 07:56:07 -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/56228) with ESMTP id v59Eu5HY019785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 9 Jun 2017 16:56:05 +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/56228) with ESMTP id v59Eu3tF010554; Fri, 9 Jun 2017 16:56:04 +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 B17D8EB201; Fri, 9 Jun 2017 16:56: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 6T3YykxferEu; Fri, 9 Jun 2017 16:56:02 +0200 (CEST) Received: from host-37-32.sg.lan (unknown [172.23.37.32]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 877C9EB207; Fri, 9 Jun 2017 16:56:01 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Matthieu Boutier In-Reply-To: <87shjdcg76.fsf@alrua-x1> Date: Fri, 9 Jun 2017 16:56:02 +0200 Cc: Juliusz Chroboczek , babel-users@lists.alioth.debian.org, babel@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <87h90a9nlz.wl-jch@irif.fr> <70ED4D66-B6BF-4D29-B24F-32A2C6779789@irif.fr> <87y3tdhy84.wl-jch@irif.fr> <87shjdcg76.fsf@alrua-x1> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3124) 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, 09 Jun 2017 16:56:06 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 09 Jun 2017 16:56:05 +0200 (CEST) X-Miltered: at korolev with ID 593AB705.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 593AB703.008 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 593AB705.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 593AB703.008 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 : 593AB705.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 593AB703.008 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] source sub-tlv X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 09 Jun 2017 14:56:10 -0000 Summary on wildcard requests. Please correct me if I misunderstood what has been expressed. Nobody supports (2) and (4). It rests: 1. only keep (legacy) wildcard requests, and reply with a full dump. 3. Send a non-specific wildcard request for non-specific routes, a source-specific wildcard request for source-specific routes, a tos-specific wildcard request for tos-specific routes, a source-and-tos-specific wildcard request for source-and-tos-specific routes, etc. Send all this kind of requests for a full dump. Juliusz prefers (3) because (1) is less conservative than (3) in the sense that a legacy Babel speaker may receive unsolicited routes. David prefers (3). Toke prefers (1), because (3) increases implementation complexity while not solving anything (no use case). I prefer (1), mainly because (3) is a pain to define. An extension (like the TOS one) will have to consider all previous extensions to consider the possible combinations, which I consider confusing. I'm not so afraid by the implementation complexity induced by (3), because an implementation can send an update at any time. It results that an implementation MAY send a full dump regardless the request received. In other terms, a receiver may implement (1) even if (3) is standardized. On the requester side, a wildcard request is statically defined, so from an implementation point of view it's not worth it. Thoughts ? Matthieu From nobody Fri Jun 9 08:17:23 2017 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 4EBA3129B66 for ; Fri, 9 Jun 2017 08:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 fLJ86KxmSZLt for ; Fri, 9 Jun 2017 08:17:20 -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 A96EE129B5D for ; Fri, 9 Jun 2017 08:17:19 -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/56228) with ESMTP id v59FHIm3032461; Fri, 9 Jun 2017 17:17:18 +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 F2622EB206; Fri, 9 Jun 2017 17:17:17 +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 AxExwrcib4Mg; Fri, 9 Jun 2017 17:17:16 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id DCDD8EB201; Fri, 9 Jun 2017 17:17:16 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.89) (envelope-from ) id 1dJLf2-0001vW-Kf; Fri, 09 Jun 2017 17:17:16 +0200 Date: Fri, 09 Jun 2017 17:17:16 +0200 Message-ID: <7itw3pry0z.wl-jch@irif.fr> From: Juliusz Chroboczek To: Matthieu Boutier Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , babel-users@lists.alioth.debian.org, babel@ietf.org In-Reply-To: References: <87h90a9nlz.wl-jch@irif.fr> <70ED4D66-B6BF-4D29-B24F-32A2C6779789@irif.fr> <87y3tdhy84.wl-jch@irif.fr> <87shjdcg76.fsf@alrua-x1> 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 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 09 Jun 2017 17:17:18 +0200 (CEST) X-Miltered: at korolev with ID 593ABBFE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 593ABBFE.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 : 593ABBFE.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] source sub-tlv X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 09 Jun 2017 15:17:21 -0000 > Thoughts ? I agree with all of the technical points in your mail. Your point about combining extensions is correct, but the issue is pretty much unavoidable now that we've committed to compositionality (the ability to add multiple sub-TLVs to a single TLV) -- we'll unavoidably run into the issue of what it means for an update to carry sub-TLVs from two different extensions. For example, we've never defined the specificity ordering for TOS- and source-specific routes, and that's something we'll need to do if anybody ever decides to implement doubly-specific routing. In other words, compositionality only goes so far when total orderings and acyclicity are involved. =46rom a word-smithing point of view, there are two approaches we can consider. Either we say nothing in the base spec, and delegate these choices to individual extensions, or we give some guidelines for extensions in Appendix C of the base spec. I'll see what I can do. -- Juliusz From nobody Tue Jun 13 10:24:21 2017 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 50188131989 for ; Tue, 13 Jun 2017 10:24:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZRda99KcAl3h for ; Tue, 13 Jun 2017 10:24:16 -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 EAC7C1272E1 for ; Tue, 13 Jun 2017 10:24:10 -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/56228) with ESMTP id v5DHO8aX026810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Jun 2017 19:24:08 +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/56228) with ESMTP id v5DHO7q1022248; Tue, 13 Jun 2017 19:24:07 +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 7A6B5EB206; Tue, 13 Jun 2017 19:24:07 +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 K4BXwws0UfEX; Tue, 13 Jun 2017 19:24:06 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 09339EB201; Tue, 13 Jun 2017 19:24:05 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.89) (envelope-from ) id 1dKpXx-0005Vb-Dj; Tue, 13 Jun 2017 19:24:05 +0200 Date: Tue, 13 Jun 2017 19:24:05 +0200 Message-ID: <7itw3jls22.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org, babel-users@lists.alioth.debian.org CC: Donald Sharp 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, 13 Jun 2017 19:24:08 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 13 Jun 2017 19:24:08 +0200 (CEST) X-Miltered: at korolev with ID 59401FB8.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 59401FB7.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59401FB8.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 59401FB7.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 : 59401FB8.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 59401FB7.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: [babel] Babel in FRR X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jun 2017 17:24:19 -0000 Dear all, Donald Sharp has just merged Babel into the master branch of FRR (the successor of Quagga). Matthieu and I have done some informal testing, including running this code as our IPv6 edge router (redistributing between RIPng and Babel), and it appears to work. https://github.com/FRRouting/frr This code is based on babeld, so it doesn't count as another independent implementation of the Babel protocol. Still, since FRR appears to be taking over from Quagga, it is an important addition to the Babel ecosystem. Many thanks to Donald for this work. -- Juliusz From nobody Tue Jun 13 10:26:45 2017 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 C662B129457 for ; Tue, 13 Jun 2017 10:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 qNUESgD_O4Sr for ; Tue, 13 Jun 2017 10:26: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 16D3613193A for ; Tue, 13 Jun 2017 10:26: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/56228) with ESMTP id v5DHQemT027841 for ; Tue, 13 Jun 2017 19:26: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 7B7E9EB201 for ; Tue, 13 Jun 2017 19:26: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 0RKgbLfh_Rem for ; Tue, 13 Jun 2017 19:26:39 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 863E4EB207 for ; Tue, 13 Jun 2017 19:26:39 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.89) (envelope-from ) id 1dKpaR-0005Vv-8l for babel@ietf.org; Tue, 13 Jun 2017 19:26:39 +0200 Date: Tue, 13 Jun 2017 19:26:39 +0200 Message-ID: <7ir2ynlrxs.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 [194.254.61.138]); Tue, 13 Jun 2017 19:26:40 +0200 (CEST) X-Miltered: at korolev with ID 59402050.007 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59402050.007 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 : 59402050.007 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] Cutoff date for rfc6126bis is 3 July X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jun 2017 17:26:44 -0000 Dear all, The I-D cutoff date is 3 July, and I'd really like to get any major new features into rfc6126bis by that date. I feel that the document is mostly complete with the significant exception of Unicast Hellos. Is there an implementation yet? Are we ready to write it down? -- Juliusz From nobody Tue Jun 13 10:31:30 2017 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 AA860131A17 for ; Tue, 13 Jun 2017 10:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 AQNPUcrsTPLS for ; Tue, 13 Jun 2017 10:31:26 -0700 (PDT) Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (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 0C0921319FA for ; Tue, 13 Jun 2017 10:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497375085; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bWj88E1OJ1x3NmfKz4lngFG6HHFNKckuepi4uaItK+k=; b=I0zGrQwA383TZgGSQ7LbnTdDZi2VVmD3FBgTjad8j1PhmrXiY3FCYN8MlmLSRkgg a+c52PFOWRceO6NvhBua0jouorqRCn6Jh8PYvejQv3qVpP9LaACqknrORo2G2SUV 9RXf72dYZw6Hpaj7jX6c4Z79itie8JMk302PEy3Is/QzaJo+/wQLB6aA8KQKW5Sw KHqHLzxKyzcRdlvQSsz2tbdO2D3l5iqXHLHBPsly13STaMePEVjJXnwuWk12ZPMC 6OkulYKLkN882YYp9eafAU5jMUcKk3DfSUDcrDiAd++d+jWMidep1p5veIStyLjT RNnpedPUWiIYH7T6NNtfeQ==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id F0.D0.17842.C6120495; Tue, 13 Jun 2017 10:31:25 -0700 (PDT) X-AuditID: 11ab0218-4df929a0000045b2-57-5940216ca716 Received: from koseret (koseret.apple.com [17.151.62.39]) by relay8.apple.com (Apple SCV relay) with SMTP id 2A.EA.21490.ED020495; Tue, 13 Jun 2017 10:29:02 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.41.204] (unknown [17.153.41.204]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORH006YFXWBM620@koseret.apple.com>; Tue, 13 Jun 2017 10:29:02 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <7ir2ynlrxs.wl-jch@irif.fr> Date: Tue, 13 Jun 2017 10:28:55 -0700 Cc: babel@ietf.org Message-id: <7A983CBB-3F2C-4B32-B74F-3A649911F22C@apple.com> References: <7ir2ynlrxs.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUi2FCYppur6BBpsGMlu8WWRd0sFvNbl7E5 MHksWfKTyWPxlreMAUxRXDYpqTmZZalF+nYJXBkbOicxFZxirVj/cD9bA+Mmli5GTg4JAROJ Od+vMHYxcnEICaxlkuj/uoEdJvF6+0RWiMQqRon1KzcxgiR4BQQlfky+B9TNwcEsIC9x8Lws SJhZQEvi+6NWFoj6ViaJ3hX7wTYIC0hLdF24ywpSLyxgKfHmiDeIyQZUf2CNEUgFp4CGxIP7 b8GqWQRUJRYtOcEIMVJI4sy1GSwQW20kfvZtZwOxhQTUJVb/3ApWIyKgIrF82jOok2Ulbs2+ xAxygoTAdHaJ/oMPmSAS0hIN+78yT2AUmYXkg1kIH8xC8sECRuZVjMK5iZk5upl5RiZ6iQUF Oal6yfm5mxhBAb+aSWIH45fXhocYBTgYlXh4H7y3jxRiTSwrrsw9xCjNwaIkzltsax0pJJCe WJKanZpakFoUX1Sak1p8iJGJg1OqgTHtS81c44PHj3moZMkeDlxVVnl3euicoCty9+502K8y uV7pyx0h+WRm5RrJRZ1yNcqWl2bleHfybBV+vP68k8hHw3K/Zx3m816t/hUiempfzByGI6WM Uwo95PeHXHHaZS3ycdtePnOFqxcbLkXaHPANV8ioXNdwrdNMb+OqmO3TPmvNcd3DPU+JpTgj 0VCLuag4EQCq+Ky+WQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUiON1OXTdb0SHS4PZVTosti7pZLOa3LmNz YPJYsuQnk8fiLW8ZA5iigm0yUhNTUosUUvOS81My89JtlTyD/XUtLEwtdQ2VFPISc1NtlSJ0 HcN0i1JzEit1Q/OKkxPz8hKTclKVFMoSc0qB0pGuwUr6djYpqTmZZalF+nYJwRkbOicxFZxi rVj/cD9bA+Mmli5GTg4JAROJ19snsnYxcnEICaxilFi/chMjSIJXQFDix+R7QEUcHMwC8hIH z8uChJkFtCS+P2plgahvZZLoXbEfbJCwgLRE14W7rCD1wgKWEm+OeIOYbED1B9YYgVRwCmhI PLj/FqyaRUBVYtGSE4wQI4UkzlybwQKx1UbiZ992NhBbSEBdYvXPrWA1IgIqEsunPWOHOFlW 4tbsS8wTGAVmITl0FsKhs5AcuoCReRWjADicLPQSCwpyUvWS83M3MYIio6EwbQdj03KrQ4xm HIxSgqWIYIzPL8lILcIipMTD++C9faQQa2JZcWXuIUYJDmYlEV6W10Ah3pTEyqrUovz4otKc 1OJDjFVAX05klhJNzgcmgLySeEMTEwMTY2MzY2NzE3OqCCuJ86Z4WUQKCaQnlqRmp6YWpBbB LGfi4JRqYNzba+F+6ZOVbPECt1mC+x9drT7ap/VWpdU7/scWtyTejgZRk3u/r4fveLtD6ENA j6WR+ufNIW/XO0cunsTM4LF6U/IFhctKRgxJ/55HbqsWW+65avti06KTpzh5ek2Ky76cVdjy J9W76/DaUEcP24mVeYdm6qdKWcpb+W6JV9JINOK+WLOfTYmlOCPRUIu5qDgRAJoYDrMNAwAA X-AV-relay-Unscannable: YES Archived-At: Subject: Re: [babel] Cutoff date for rfc6126bis is 3 July X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jun 2017 17:31:29 -0000 I was planning on working on that this week. First an implementation, and once it works a proposal for RFC text. I'll do my best to have that ready by Friday. David > On Jun 13, 2017, at 10:26, Juliusz Chroboczek wrote: > > Dear all, > > The I-D cutoff date is 3 July, and I'd really like to get any major new > features into rfc6126bis by that date. I feel that the document is mostly > complete with the significant exception of Unicast Hellos. > > Is there an implementation yet? Are we ready to write it down? > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Tue Jun 13 10:36:52 2017 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 5830C1319F9 for ; Tue, 13 Jun 2017 10:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 pDlIyzwmyEB9 for ; Tue, 13 Jun 2017 10:36:49 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 65343129457 for ; Tue, 13 Jun 2017 10:36:49 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id u12so181887732qth.0 for ; Tue, 13 Jun 2017 10:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GTQHwqcvJLqkZ6ZKmAxyWDdarMZkp0ZbiRWmIHY0+go=; b=vKcV+5yxVQLrIFLZeKP+GtO2Bf4StAR/doNNxSeEQFlHj87sTsg2N2qZwSRApJ1wfM kwq4jG8UdS+Xdf90TpdQ2MU4dnLYwU+m3S/V0VmhrNzuKEXrerjw6gmwB/9ycqR4z9In MZYvvUOqRHqWizyfhyMfoHj0HDqmJvaJlAWhBCv05nowrw4BbSnxhvg+NtuvqW4F+fNy lsvpm4hYaODaLZ8Cr7UG1I5lS3tKiCir9YefbUJot5kFMMXCbyDZKIZ3/Y11xIu/UAnO LgAXsugWbzYKNK8Zfgrkpck715e27EVZJTg6SEPmSdtF8rM4Og89jeoDemVt73NojejJ 2O5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GTQHwqcvJLqkZ6ZKmAxyWDdarMZkp0ZbiRWmIHY0+go=; b=oubfOKKv1qGkXcfHftF6Uc8Kch8lrx+fujAlu/uvINZLe9ViuaYZrUwChFJVos2Bd1 V+fa+IcIqkgZMs4evPg4ki+fgJxOGIln9ACxOsGdgipKcK/zm83vAgYbGp2+U49KZo67 vk76YmWt0Txj8Wv3dA5Kwimt48QtjEmx6FlNjspishxYSGQFZFHSdDs78k28aLYXKTqM f7ZZW8qUR5iUkTE/Xgv6fe9GT/nnK8DOpaWFt0V2jbX4laD0Udg55ZejrMIUen1wFQY6 2hue7ilUJwtO2ESBhxAy3zlQ8LSASeQXovAhG/kyIjyHD/EvYfmI64dN4geyyu8N1Cec 4F7g== X-Gm-Message-State: AKS2vOyFg8/T3hW1Jw+X2kSu8ZZDkO5Km9pgoD+EOi47O4v8cdY8rzN/ j47v1+P3qauXMti9dPcNh7jVWscJJw== X-Received: by 10.237.34.88 with SMTP id o24mr1468212qtc.217.1497375408618; Tue, 13 Jun 2017 10:36:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.131.34 with HTTP; Tue, 13 Jun 2017 10:36:48 -0700 (PDT) In-Reply-To: <7itw3jls22.wl-jch@irif.fr> References: <7itw3jls22.wl-jch@irif.fr> From: Dave Taht Date: Tue, 13 Jun 2017 10:36:48 -0700 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF , "babel-users@lists.alioth.debian.org" , Donald Sharp Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] Babel in FRR X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jun 2017 17:36:51 -0000 That's really wonderful news. On my end, I'm planning to deploy lede + babel 1.8 across about 35 routers at lupin lodge (los gatos, ca, hills) starting next week, and heading down to nicaragua the week following to explore the possibilities of a deployment here: http://www.harmonia.life/ ... before the rainy season starts. I'm using a mixture of nanostation m5s, rocket m5s and m2s (ath9k), and the uap-lite (ath10k with the adhoc capable candelatech firmware). If anyone wants to camp out (and help) at either site anytime in the next few months please let me know. From nobody Tue Jun 13 13:40:56 2017 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 0DDDE1243F3 for ; Tue, 13 Jun 2017 13:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 RLrN7evu6u6G for ; Tue, 13 Jun 2017 13:40: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 CCAB7128768 for ; Tue, 13 Jun 2017 13:40: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/56228) with ESMTP id v5DKelhV015956; Tue, 13 Jun 2017 22:40:47 +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 3F138EB206; Tue, 13 Jun 2017 22:40:47 +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 t40haiLH_gD9; Tue, 13 Jun 2017 22:40:46 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id CDEE3EB201; Tue, 13 Jun 2017 22:40:45 +0200 (CEST) Date: Tue, 13 Jun 2017 22:40:45 +0200 Message-ID: <87k24f8vua.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: babel@ietf.org In-Reply-To: <7A983CBB-3F2C-4B32-B74F-3A649911F22C@apple.com> References: <7ir2ynlrxs.wl-jch@irif.fr> <7A983CBB-3F2C-4B32-B74F-3A649911F22C@apple.com> 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, 13 Jun 2017 22:40:47 +0200 (CEST) X-Miltered: at korolev with ID 59404DCF.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59404DCF.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 : 59404DCF.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] Cutoff date for rfc6126bis is 3 July X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jun 2017 20:40:55 -0000 > First an implementation, and once it works a proposal for RFC text. > I'll do my best to have that ready by Friday. Excellent. Let me know if you want to have a chat on the phone or on IRC. -- Juliusz From nobody Tue Jun 13 14:43:22 2017 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 6B1CF12702E for ; Tue, 13 Jun 2017 14:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 pDaiALWGmPOZ for ; Tue, 13 Jun 2017 14:43:18 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 31CF4120724 for ; Tue, 13 Jun 2017 14:43:18 -0700 (PDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1497390195; bh=NHNwdLMtaD63mEeFo6t/WqenEiZIbPeB+1BFBLC4EIQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=nf5k0xaYp6zMfn36FNoc4IHe7PAFNLDNIjwpF6ifdqk1dsmGZI2X0d22MPOclmzjS pf98MVycYbfftmkzLNb3YrODlFrm40dkRguRZ7SpcCM6l8LzN62MW4waAwJc55eEUF JNABVVGiBgXE+utnDlokyqX6p4Slx8xIS1G2Bzyd570aeqO03dV4wAH8AZC73JC0xf mY6zxtXadpbqEvsRjFHzwq3DLBwJygdoZGJb4zBUqgCZL8gvH40g0x+bhPHYZDwdbb HwLfmpKw9yXrh9zW0kslxAF+uhleQ41ypitO0URM02F3HYZwvEGci+8IWRhId4DdeO b00I61JtWnLlg== To: Juliusz Chroboczek Cc: babel@ietf.org References: <7ir2ynlrxs.wl-jch@irif.fr> Date: Tue, 13 Jun 2017 23:43:12 +0200 In-Reply-To: <7ir2ynlrxs.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Tue, 13 Jun 2017 19:26:39 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87wp8fzhqn.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Cutoff date for rfc6126bis is 3 July X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jun 2017 21:43:21 -0000 Juliusz Chroboczek writes: > Dear all, > > The I-D cutoff date is 3 July, and I'd really like to get any major new > features into rfc6126bis by that date. I feel that the document is mostly > complete with the significant exception of Unicast Hellos. > > Is there an implementation yet? Are we ready to write it down? Not a complete implementation, but I managed to get something rudimentary to work. Pushed here: https://github.com/tohojo/bird/tree/babel-unicast Basically, what this does is: - Change the first byte of the reserved part of the hello TLV to be a flags field and define a unicast flag (0x20) to indicate unicast hellos. - If configured to do so (there's a per-interface 'prefer unicast' config option), whenever a new neighbour is acquired, send a unicast hello (flag set, unicast packet dest, per-neighbour sequence number) to that neighbour. - Upon receiving a unicast hello, if 'prefer unicast' is enabled on the interface, switch that neighbour to unicast mode, reset the hello history and immediately reply with a unicast hello in return. If unicast mode is disabled, just ignore the TLV. - When a neighbour is in unicast mode, completely ignore all multicast hellos from that neighbour and don't multicast IHUs to it. There is no way to switch back to multicast mode short of losing and re-acquiring the neighbour completely. Because a peer is only switched into unicast mode upon receiving a unicast hello, the initial unsolicited unicast hello acts as a probe. If no unicast hello is ever received in the other direction, everything continues as before; but if it is, the nodes will effectively have negotiated unicast mode and continue that way. As I said, the implementation is quite rudimentary. But it works so that two nodes can successfully negotiate unicast mode and switch over; or stay in multicast mode if one or both have the config option switched off. However, I have not tested how robust this is on a real network. Right now I'm just sending a unicast hello to every unicast mode neighbour whenever I'm sending multicast hellos, and send an IHU after every unicast hello. Planning to make that smarter (at the minimum, allow separate intervals for unicast and multicast hellos), and also to add an option to send all other TLVs as unicast to unicast neighbours; and probably a config option to add unicast peers without having to discover them via multicast (for links that don't support that at all). But that is not really that important for the protocol spec, I figure... As far as the protocol spec is concerned, I suppose the flag and the "mode switch" need to go into the RFC. Don't really see much of a use case for "mixing" unicast and multicast cost estimation for the same neighbour, which is why I went with the simple option of just switching mode. I can propose some text once someone else has confirmed that this way of doing things is not completely daft... -Toke From nobody Wed Jun 14 22:45:12 2017 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 0B04412025C for ; Wed, 14 Jun 2017 22:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 HdJ9L9tN0R_D for ; Wed, 14 Jun 2017 22:45:08 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 6ECF51200F1 for ; Wed, 14 Jun 2017 22:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497505508; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YjYpEbd9O6LWQHKKGQ43r5O1HNbKH26UOxtska77PsI=; b=gYI7RlGXsWE/O/LQKw6tU4PTbvo4NgX7SMZ81MENPLFrpBKPArH2+cvLAydVg/VX zGa6jREpYFjx7BLAeUpvV9HAT54KAUlEeEr2oGypsaBo+upze1ROw/9CqTNDzwWg N75swNyxMxYEFNQtTM8gdP3x9fE3vDhkZy9Uqoou0yOC5oeojLbD5qQpay7FOyuc R7bDQaaLIaKow6Y4eIdjd2MwVxyGg38METO8DnxkgV2WFgXItwmcOMm8gqm0tM+K 8ealiaWWvrXed9r1FKGuX2wua2B+6F/biaA3w0u1855Iaql4GWFwhaw7nrXO7S1D Xj65g59iZdrlM1pVmmB4dA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id B4.C2.07949.3EE12495; Wed, 14 Jun 2017 22:45:08 -0700 (PDT) X-AuditID: 11973e16-0c7789a000001f0d-51-59421ee49c78 Received: from jimbu (jimbu.apple.com [17.151.62.37]) by relay6.apple.com (Apple SCV relay) with SMTP id EB.26.25627.3EE12495; Wed, 14 Jun 2017 22:45:07 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_9E03bwMrKGqQ5ubPvpCnBg)" Received: from [17.153.81.230] (unknown [17.153.81.230]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORK00H9CQN6UQ70@jimbu.apple.com>; Wed, 14 Jun 2017 22:45:07 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> Date: Wed, 14 Jun 2017 22:45:05 -0700 In-reply-to: <87wp8fzhqn.fsf@alrua-x1> Cc: Juliusz Chroboczek , =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Babel at IETF References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUi2FAYpftEzinS4Ox9dosti7pZLOa3LmOz 2Pp+BbsDs8eSJT+ZPBZvecvoseXQRbYA5igum5TUnMyy1CJ9uwSujO/z7rIWnCqpeH4uuYGx I6mLkZNDQsBE4tK+ZkYQW0hgNZPEqvOFMPGj646ydDFyAcWXMUpM3LWICSTBKyAo8WPyPRYQ m1kgTGLltQ1sEEX/GSXmH/0CNklYQFqi68Jd1i5GDg42AS2JA2uMIHptJE4uWswCEhYWsJR4 c8QbJMwioCox69wasPGcAmoSk1o/MkKMT5aY/fI42CoRASWJzTd/MkPc6Six6cR0Zog7ZSVu zb7EDHKChMBlNonTU+YzTWAUmoXk1FlITp0FtJpZQF1iypRciLC2xJN3F1ghbDWJhb8XMSGL L2BkW8UolJuYmaObmWeul1hQkJOql5yfu4kRFBnT7cR2MD5cZXWIUYCDUYmHl8HCMVKINbGs uDL3EKM0B4uSOO+6ZqCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxkT/BTu0LjUfcpRIOeP6 PyW81U5pgpql+oTHkyJOXj2jdOqA3f+d3CJNpQ8nvjNIzxYJXaUvF+aSHiEZVnxo8ov/Jcev vtib9PO4d5+QxYPN+yp9K4QrnzyvsOI/Zf4/hz37+A+dgv32hw88VdBwbHzwwL5N+ivn8Ykr zS/uPjpXzZ8xTnZSpRJLcUaioRZzUXEiADMvn25tAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKIsWRmVeSWpSXmKPExsUiON1OVfexnFOkwcvFMhZbFnWzWMxvXcZm sfX9CnYHZo8lS34yeSze8pbRY8uhi2wBzFFcNimpOZllqUX6dglcGd/n3WUtOFVS8fxccgNj R1IXIyeHhICJxNF1R1m6GLk4hASWMUpM3LWICSTBKyAo8WPyPRYQm1kgTGLltQ1sEEX/GSXm H/3CCJIQFpCW6Lpwl7WLkYODTUBL4sAaI4heG4mTixazgISFBSwl3hzxBgmzCKhKzDq3Bmw8 p4CaxKTWj4wQ45MlZr88DrZKREBJYvPNn8wgtpCAo8SmE9OZIe6Ulbg1+xLzBEb+WUium4Xk ullA25gF1CWmTMmFCGtLPHl3gRXCVpNY+HsRE7L4Aka2VYwCRak5iZVmeokFBTmpesn5uZsY QaHcUBi1g7FhudUhRgEORiUe3hWmjpFCrIllxZW5hxglOJiVRHhvrwcK8aYkVlalFuXHF5Xm pBYfYpzICPTkRGYp0eR8YKTllcQbmpgYmBgbmxkbm5uY01JYSZx34SGgiwTSE0tSs1NTC1KL YI5i4uCUamDUXvF69x03k4OcDA++ip5U1npZ8Vx3UuzidYc3tPw799i5LNLLIDyVadsOi5K1 om/YEmezFRq5vCmexPDT+K5YbEDqUnamJVumTdDsuf1L7sgs/XmbPWez8B6tebail231c/U1 S7LXmei8zEx4q3tlBk/ibfnt6TvSq/xufc67mLHouPGOWCUuJZbijERDLeai4kQA7ZDUKNgC AAA= Archived-At: Subject: Re: [babel] Cutoff date for rfc6126bis is 3 July X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jun 2017 05:45:11 -0000 --Boundary_(ID_9E03bwMrKGqQ5ubPvpCnBg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi everyone, I finally got some free time to spend on Babel and brought my = implementation up to speed, it now supports mandatory sub-TLVs, which were easy to add. I've also added support for unicast Hellos, which I've renamed Personal = Hellos. I thought unicast/multicast were IP-level concepts and since these = Hellos have more interesting properties than their destination IP address, I named them - Public Hellos -- which are multicast and equivalent to RFC6126 Hellos - Personal Hellos -- which are unicast I went with an approach different from Toke's, of having both of them = co-exist. On the outgoing side, nodes now have a per-interface Public Hello seqno (which renames the previous per-interface Hello seqno) and a (new) per-neighbor Personal Hello seqno. On the incoming side, nodes now keep two sets of Hello = timer/history/interval/expected seqno per neighbor, one for Public and one for Personal. This allows computing = two independent costs, and they are combined to create the actual link cost. Regarding packet encoding, I renamed the Reserved field in Hello TLVs to = Flags, and added a PERSONAL flag (hex 8000). Adding this to my implementation was pretty straightforward, and it = seems to work well. I haven't had time to play with many different values for the timers, or to come up with fancy cost computation techniques, but as these are implementation-specific, it doesn't block discussion of the = specification. I think this approach has the advantage of - not needing negotiation (feature negotiation isn't in the spirit of = Babel today) - not needing modes of operation (from experience, these always cause = bugs where two nodes disagree on what mode they think the other is in) Regarding backwards compatibility, I think we could deploy a quick fix = in today's implementations: simply ignore Hello TLVs with the Personal flag. This = can be done alongside mandatory sub-TLV support. Implementations can then take their time to support Personal Hellos. I took a jab at writing this up, and pushed it to the repository: https://github.com/jech/babel-drafts/pull/3/files = It's a very early draft, but I think it conveys a possible solution. Let me know what you think! Thanks, David Schinazi > On Jun 13, 2017, at 14:43, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Juliusz Chroboczek writes: >=20 >> Dear all, >>=20 >> The I-D cutoff date is 3 July, and I'd really like to get any major = new >> features into rfc6126bis by that date. I feel that the document is = mostly >> complete with the significant exception of Unicast Hellos. >>=20 >> Is there an implementation yet? Are we ready to write it down? >=20 > Not a complete implementation, but I managed to get something > rudimentary to work. Pushed here: >=20 > https://github.com/tohojo/bird/tree/babel-unicast >=20 > Basically, what this does is: >=20 > - Change the first byte of the reserved part of the hello TLV to be a > flags field and define a unicast flag (0x20) to indicate unicast > hellos. >=20 > - If configured to do so (there's a per-interface 'prefer unicast' > config option), whenever a new neighbour is acquired, send a unicast > hello (flag set, unicast packet dest, per-neighbour sequence number) > to that neighbour. >=20 > - Upon receiving a unicast hello, if 'prefer unicast' is enabled on = the > interface, switch that neighbour to unicast mode, reset the hello > history and immediately reply with a unicast hello in return. If > unicast mode is disabled, just ignore the TLV. >=20 > - When a neighbour is in unicast mode, completely ignore all multicast > hellos from that neighbour and don't multicast IHUs to it. There is = no > way to switch back to multicast mode short of losing and re-acquiring > the neighbour completely. >=20 > Because a peer is only switched into unicast mode upon receiving a > unicast hello, the initial unsolicited unicast hello acts as a probe. = If > no unicast hello is ever received in the other direction, everything > continues as before; but if it is, the nodes will effectively have > negotiated unicast mode and continue that way. >=20 > As I said, the implementation is quite rudimentary. But it works so = that > two nodes can successfully negotiate unicast mode and switch over; or > stay in multicast mode if one or both have the config option switched > off. However, I have not tested how robust this is on a real network. >=20 > Right now I'm just sending a unicast hello to every unicast mode > neighbour whenever I'm sending multicast hellos, and send an IHU after > every unicast hello. Planning to make that smarter (at the minimum, > allow separate intervals for unicast and multicast hellos), and also = to > add an option to send all other TLVs as unicast to unicast neighbours; > and probably a config option to add unicast peers without having to > discover them via multicast (for links that don't support that at = all). > But that is not really that important for the protocol spec, I = figure... >=20 > As far as the protocol spec is concerned, I suppose the flag and the > "mode switch" need to go into the RFC. Don't really see much of a use > case for "mixing" unicast and multicast cost estimation for the same > neighbour, which is why I went with the simple option of just = switching > mode. >=20 > I can propose some text once someone else has confirmed that this way = of > doing things is not completely daft... >=20 > -Toke >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --Boundary_(ID_9E03bwMrKGqQ5ubPvpCnBg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi everyone,

I finally got some free time to spend on Babel and brought my = implementation up to speed,
it now supports = mandatory sub-TLVs, which were easy to add.

I've also added support for unicast = Hellos, which I've renamed Personal Hellos.
I = thought unicast/multicast were IP-level concepts and since these Hellos = have more
interesting properties than their = destination IP address, I named them
- Public = Hellos -- which are multicast and equivalent to RFC6126 Hellos
- Personal Hellos -- which are unicast
I went with an approach different from = Toke's, of having both of them co-exist.

On the outgoing side, nodes now have a = per-interface Public Hello seqno
(which renames the = previous per-interface Hello seqno) and
a (new) = per-neighbor Personal Hello seqno.

On the incoming side, nodes now keep = two sets of Hello timer/history/interval/expected seqno
per neighbor, one for Public and one for Personal. This = allows computing two independent
costs, and they = are combined to create the actual link cost.

Regarding packet encoding, I renamed = the Reserved field in Hello TLVs to Flags,
and = added a PERSONAL flag (hex 8000).

Adding this to my implementation was = pretty straightforward, and it seems to work well.
I = haven't had time to play with many different values for the = timers,
or to come up with fancy cost computation = techniques, but as these are
implementation-specific,= it doesn't block discussion of the specification.

I think this approach = has the advantage of
- not needing negotiation = (feature negotiation isn't in the spirit of Babel today)
- not needing modes of operation (from experience, these = always cause bugs where
    two nodes = disagree on what mode they think the other is in)
Regarding backwards compatibility, I = think we could deploy a quick fix in today's
implementations: simply ignore Hello TLVs with the Personal = flag. This can be
done alongside mandatory sub-TLV = support. Implementations can then take
their time = to support Personal Hellos.

I took a jab at writing this up, and pushed it to the = repository:
https://github.com/jech/babel-drafts/pull/3/files

It's a very early = draft, but I think it conveys a possible solution.

Let me know what you = think!

Thanks,
David Schinazi


On Jun 13, 2017, at 14:43, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> = wrote:

Juliusz Chroboczek <jch@irif.fr> writes:

Dear all,

The I-D cutoff date is 3 July, and I'd really = like to get any major new
features into rfc6126bis by that = date.  I feel that the document is mostly
complete = with the significant exception of Unicast Hellos.

Is there an implementation yet?  Are we ready to write = it down?

Not a complete = implementation, but I managed to get something
rudimentary = to work. Pushed here:

https://github.com/tohojo/bird/tree/babel-unicast

Basically, what this does is:

- Change the first byte of the reserved part of the hello TLV = to be a
 flags field and define a unicast flag = (0x20) to indicate unicast
 hellos.

- If configured to do so (there's a per-interface 'prefer = unicast'
 config option), whenever a new neighbour = is acquired, send a unicast
 hello (flag set, = unicast packet dest, per-neighbour sequence number)
=  to that neighbour.

- Upon receiving a = unicast hello, if 'prefer unicast' is enabled on the
=  interface, switch that neighbour to unicast mode, reset the = hello
 history and immediately reply with a unicast = hello in return. If
 unicast mode is disabled, just = ignore the TLV.

- When a neighbour is in = unicast mode, completely ignore all multicast
=  hellos from that neighbour and don't multicast IHUs to it. There = is no
 way to switch back to multicast mode short of = losing and re-acquiring
 the neighbour = completely.

Because a peer is only switched = into unicast mode upon receiving a
unicast hello, the = initial unsolicited unicast hello acts as a probe. If
no = unicast hello is ever received in the other direction, everything
continues as before; but if it is, the nodes will effectively = have
negotiated unicast mode and continue that way.

As I said, the implementation is quite = rudimentary. But it works so that
two nodes can = successfully negotiate unicast mode and switch over; or
stay= in multicast mode if one or both have the config option switched
off. However, I have not tested how robust this is on a real = network.

Right now I'm just sending a = unicast hello to every unicast mode
neighbour whenever I'm = sending multicast hellos, and send an IHU after
every = unicast hello. Planning to make that smarter (at the minimum,
allow separate intervals for unicast and multicast hellos), = and also to
add an option to send all other TLVs as = unicast to unicast neighbours;
and probably a config = option to add unicast peers without having to
discover = them via multicast (for links that don't support that at all).
But that is not really that important for the protocol spec, = I figure...

As far as the protocol spec is = concerned, I suppose the flag and the
"mode switch" need = to go into the RFC. Don't really see much of a use
case = for "mixing" unicast and multicast cost estimation for the same
neighbour, which is why I went with the simple option of just = switching
mode.

I can propose = some text once someone else has confirmed that this way of
doing things is not completely daft...

-Toke

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

= --Boundary_(ID_9E03bwMrKGqQ5ubPvpCnBg)-- From nobody Thu Jun 15 02:15:01 2017 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 B74B5129C5F for ; Thu, 15 Jun 2017 02:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHGzgvidPRaB for ; Thu, 15 Jun 2017 02:14:56 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 66A15129BBD for ; Thu, 15 Jun 2017 02:14:56 -0700 (PDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1497518092; bh=tzpNKB1+Uc/P2OLeVO/H+FfHJQ3NV7hMN94Pvujskok=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=wEgyxMTC/m3gB3UTB6xyxMpEr+Lxbdg78ztQERinzPxueWopL4WNXJm2ZXOdnGWyy QhuN5I8nL8FV47gHcV2y8Bcch9KXCOg+MLGKgpQFlHGfYQRKnUxrjjBtnKcnPyIp4f fbzlIa8vviiNg5hMjx5CZaEzwphQ7Jd/Mhs8xDQlf9VBW5/WLKZLYyZf39Tkp4+RRz KIYKkp2kdIa/ElRNWEJNpqOfj3aNTTfgnGVo7c5YPESMvoRciCv0F494wLKX1Jzxrw L0sJ4u3BIhd86y2kaImYJjnxRytfRUOp5ORTrAgmrMgVNIHofof00c27cNcULIrf9T UgDKy4nHnJIlQ== To: David Schinazi Cc: Babel at IETF , Juliusz Chroboczek References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> Date: Thu, 15 Jun 2017 11:14:50 +0200 In-Reply-To: <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> (David Schinazi's message of "Wed, 14 Jun 2017 22:45:05 -0700") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87k24dzk6t.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Cutoff date for rfc6126bis is 3 July X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jun 2017 09:15:00 -0000 David Schinazi writes: > I've also added support for unicast Hellos, which I've renamed Personal Hellos. > I thought unicast/multicast were IP-level concepts and since these Hellos have more > interesting properties than their destination IP address, I named them > - Public Hellos -- which are multicast and equivalent to RFC6126 Hellos > - Personal Hellos -- which are unicast For some reason I *really* don't like those names. Not sure why; too anthropomorphic, perhaps? Anyway, that aside... > I went with an approach different from Toke's, of having both of them > co-exist. Yeah, I guess you are right that just having them co-exist is better. > Regarding packet encoding, I renamed the Reserved field in Hello TLVs > to Flags, and added a PERSONAL flag (hex 8000). I guess there's an implicit network-to-host byte order here; is that always obvious when the field is not an integer field? That was the reason why I opted for a 1-byte flags field. In either case we should probably at least pick the same flag value... ;) > It's a very early draft, but I think it conveys a possible solution. A few things that I'm not sure are well-defined currently; consider these questions that should be resolved: - Is it allowed to not send multicast hellos at all (I think it should be)? - Is it legal for an implementation to completely ignore one type of hello (probably should be, but could be problematic if we don't guarantee that they are both always available, see below)? - Is an implementation allowed to stop sending unicast hellos to a neighbour after it started doing it? This could be problematic if the other neighbour relies only on unicast to define neighbour availability. - When should a neighbour entry be expired? When we stop receiving multicast hellos, or when we stop receiving any one type? - Should we recommend that IHUs be send the same way as the hello was received? -Toke From nobody Thu Jun 15 07:57:04 2017 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 4548612EA64 for ; Thu, 15 Jun 2017 07:57:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 OSu8mt-epSqe for ; Thu, 15 Jun 2017 07:57:01 -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 CAADA12E040 for ; Thu, 15 Jun 2017 07:57:00 -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/56228) with ESMTP id v5FEuxmJ027323; Thu, 15 Jun 2017 16:56:59 +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 16860EB2C3; Thu, 15 Jun 2017 16:56:59 +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 57gohGyyYawp; Thu, 15 Jun 2017 16:56:57 +0200 (CEST) Received: from eduroam-prg-sg-1-44-130.net.univ-paris-diderot.fr (eduroam-prg-sg-1-44-130.net.univ-paris-diderot.fr [172.28.44.130]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B39FDEB206; Thu, 15 Jun 2017 16:56:57 +0200 (CEST) From: Matthieu Boutier Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 15 Jun 2017 16:56:58 +0200 References: <149753600138.12968.17430801165728958448.idtracker@ietfa.amsl.com> To: Babel at IETF , babel-users Message-Id: <7679DA79-5B56-4A19-95C3-8DE0CB2C8C12@irif.fr> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 15 Jun 2017 16:56:59 +0200 (CEST) X-Miltered: at korolev with ID 5942A03B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5942A03B.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 : 5942A03B.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] draft-boutier-babel-source-specific-02 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jun 2017 14:57:03 -0000 Hello, I've submitted the 02 version. https://datatracker.ietf.org/doc/draft-boutier-babel-source-specific/ To be discussed: - choose one proposal for wildcard requests, - Define the Source Prefix sub-TLV type, - I've deprecated source-specific wildcard updates (disagreements ?), - should I put a note about incompatibility with RFC 6126 ? About wildcard updates: they're used to retracts all routes, typically before a node stops. I don't see any use case of source-specific wildcard updates (which would mean "retraction of source-specific routes")... Matthieu From nobody Thu Jun 15 08:40:00 2017 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 886DE1205F1 for ; Thu, 15 Jun 2017 08:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 BsWVSooVMPeM for ; Thu, 15 Jun 2017 08:39:57 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 3E13E1294F8 for ; Thu, 15 Jun 2017 08:39:57 -0700 (PDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1497541189; bh=slRqadahSOQ1AHwncM8wwlkCM4xYM+5a1PCGfSftgyk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=WgNwBsK61qYLgXXiWcnCBM3hCHoaCSBSxUZOgLCwm5TbZi3eQwzUytSNFN/vHsHxG m81W0tzyVe5LpVkXNpxFrVqz0rrygO5K4SjRWtLK9txWPriLIhTh95dkC1HbqGUMEN iJWWZ6mGK+THxt2Aka/pfB0S+U6Kdl+bcABfzewKwBN0ldosbRNX1591qJxI0ZlYi9 J2Dn5kWhlLte3Ra/ELEk3Guqjc8tqpFE2ceRz6KzhLwLfaSsKjdtQYNTSDZPzimBbD gegjiwF7y+qtzXa1WYshMhBXDKR6n9qPh3njpa+OmJXbbW6k14dls1L9KvI6JfeElC KRt7oweeQ0RHQ== To: Matthieu Boutier Cc: Babel at IETF , babel-users References: <149753600138.12968.17430801165728958448.idtracker@ietfa.amsl.com> <7679DA79-5B56-4A19-95C3-8DE0CB2C8C12@irif.fr> Date: Thu, 15 Jun 2017 17:39:45 +0200 In-Reply-To: <7679DA79-5B56-4A19-95C3-8DE0CB2C8C12@irif.fr> (Matthieu Boutier's message of "Thu, 15 Jun 2017 16:56:58 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <8760fxz2da.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] draft-boutier-babel-source-specific-02 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jun 2017 15:40:00 -0000 Matthieu Boutier writes: > About wildcard updates: they're used to retracts all routes, typically > before a node stops. I don't see any use case of source-specific > wildcard updates (which would mean "retraction of source-specific > routes")... Does this mean whatever we decide for wildcard requests applies to wildcard updates as well? -Toke From nobody Thu Jun 15 08:48:37 2017 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 B2C0C128D2E for ; Thu, 15 Jun 2017 08:48:35 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 KOvrbDUaI9_r for ; Thu, 15 Jun 2017 08:48:34 -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 E23131241FC for ; Thu, 15 Jun 2017 08:48:33 -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/56228) with ESMTP id v5FFmVw8026040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 15 Jun 2017 17:48:31 +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/56228) with ESMTP id v5FFmVc7026783 for ; Thu, 15 Jun 2017 17:48:31 +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 E36CDEB207 for ; Thu, 15 Jun 2017 17:48:31 +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 VyKFlfhAai1d; Thu, 15 Jun 2017 17:48:30 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 743B5EB201; Thu, 15 Jun 2017 17:48:30 +0200 (CEST) Date: Thu, 15 Jun 2017 17:48:30 +0200 Message-ID: <877f0ddzg1.wl-jch@irif.fr> From: Juliusz Chroboczek To: Matthieu Boutier Cc: Babel at IETF In-Reply-To: <7679DA79-5B56-4A19-95C3-8DE0CB2C8C12@irif.fr> References: <149753600138.12968.17430801165728958448.idtracker@ietfa.amsl.com> <7679DA79-5B56-4A19-95C3-8DE0CB2C8C12@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]); Thu, 15 Jun 2017 17:48:31 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 15 Jun 2017 17:48:31 +0200 (CEST) X-Miltered: at korolev with ID 5942AC4F.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5942AC4F.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5942AC4F.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5942AC4F.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 : 5942AC4F.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5942AC4F.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: Re: [babel] draft-boutier-babel-source-specific-02 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jun 2017 15:48:36 -0000 > I've submitted the 02 version. > https://datatracker.ietf.org/doc/draft-boutier-babel-source-specific/ Do people agree that this deserves a talk in Prague? I'm asking now because I need to start thinking about funding. -- Juliusz From nobody Thu Jun 15 08:49:25 2017 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 221F9128D2E for ; Thu, 15 Jun 2017 08:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 kbUp5KbjpcXu for ; Thu, 15 Jun 2017 08:49: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 7CC711241FC for ; Thu, 15 Jun 2017 08:49:22 -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/56228) with ESMTP id v5FFnK4O026972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 15 Jun 2017 17:49:20 +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/56228) with ESMTP id v5FFnKGF027532; Thu, 15 Jun 2017 17:49:20 +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 D3CD6EB206; Thu, 15 Jun 2017 17:49:20 +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 Wtb_BKHOfiai; Thu, 15 Jun 2017 17:49:19 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A6C24EB201; Thu, 15 Jun 2017 17:49:19 +0200 (CEST) Date: Thu, 15 Jun 2017 17:49:19 +0200 Message-ID: <8760fxdzeo.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: babel-users , Babel at IETF In-Reply-To: <8760fxz2da.fsf@alrua-x1> References: <149753600138.12968.17430801165728958448.idtracker@ietfa.amsl.com> <7679DA79-5B56-4A19-95C3-8DE0CB2C8C12@irif.fr> <8760fxz2da.fsf@alrua-x1> 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]); Thu, 15 Jun 2017 17:49:20 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 15 Jun 2017 17:49:20 +0200 (CEST) X-Miltered: at korolev with ID 5942AC80.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5942AC80.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5942AC80.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5942AC80.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 : 5942AC80.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5942AC80.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] [Babel-users] draft-boutier-babel-source-specific-02 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jun 2017 15:49:24 -0000 > Does this mean whatever we decide for wildcard requests applies to > wildcard updates as well? Yes, er, no, er, I have no idea. -- Juliusz From nobody Thu Jun 15 09:02:24 2017 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 5B69C1200CF for ; Thu, 15 Jun 2017 09:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 XInfnNn_kjPX for ; Thu, 15 Jun 2017 09:02:21 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 7DB71127B52 for ; Thu, 15 Jun 2017 09:02:21 -0700 (PDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1497542534; bh=/ObiVgSaMHTD6826Hbt5I1TAzutARyis+l+8pxG0S7Y=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=qA4MEKuY/3Ga/86mwew3aMQyOS1E0ULd4GHoTyGbpVSN3h9j+HgOX0E4WuGF0Vs4n xNBhCMgUy9OUh1UM5Nkn9LnGwC3VY6dethIuFVIYiNHZvMR1bZJohzSBxjXRJkqS0v kkHCUZf0GDp8gxQzOzjEBME8Db2Oasl4WqwgvZEvdvqygIIGp8QHfzWFdTRTpyJzQE eQhRfnR5VDigrwnquzWyvsqv2lzWniH4Q0XSPVnxYULTzZWyUkojW0m7lPtKsEQQWp 6vxj4li1jiXBJrt9KP5GQ2vhSvHUrAQ0rREygRLtjmjV6Ukhb1OUkJPILzk6KkztUC IInImLKFvNJRg== To: Juliusz Chroboczek Cc: babel-users , Babel at IETF References: <149753600138.12968.17430801165728958448.idtracker@ietfa.amsl.com> <7679DA79-5B56-4A19-95C3-8DE0CB2C8C12@irif.fr> <8760fxz2da.fsf@alrua-x1> <8760fxdzeo.wl-jch@irif.fr> Date: Thu, 15 Jun 2017 18:02:10 +0200 In-Reply-To: <8760fxdzeo.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Thu, 15 Jun 2017 17:49:19 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87wp8dxmrh.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] [Babel-users] draft-boutier-babel-source-specific-02 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jun 2017 16:02:23 -0000 Juliusz Chroboczek writes: >> Does this mean whatever we decide for wildcard requests applies to >> wildcard updates as well? > > Yes, er, no, er, I have no idea. I do always enjoy your elucidating comments... ;) -Toke From nobody Thu Jun 15 11:16:01 2017 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 EAD9F127011 for ; Thu, 15 Jun 2017 11:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 0kH1NpaNXl9x for ; Thu, 15 Jun 2017 11:15:55 -0700 (PDT) Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (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 602A4120726 for ; Thu, 15 Jun 2017 11:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497550554; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jlw1TCjFPlK/PJ+jjL1LR9/WYSrE/rh/UuJHUa1lFiY=; b=StsDSJaR6cl1tMo2k3wsjMRLAV8EZDltu7S91oSjjoCRihjNDtxZK9MPlwvowhqR DB/FOUmS5nH7z/qQkCwXSgjFCe/nYVFMHQEkQBx/RF4T70eC7aRcW6A0BZp1RuQz anhDgG48NT3ShaCd5msgCZxacgdyfeEoOUbZgGaVi8Mi7vy1Htegtx7UBqf0cIBT LsMyVFQYJ2BfIBWie/LcdhDdYbwsYLS6obNhFDFPJLecheS1OFggW57ANb6K101W QHESHeLs4zU7IzXwmq7pTXSu6KY6gHO/HPQhiShyvx2bruh1+FTT20JrNeX0nsVZ oXSsh9YHEXRqWRgCz7thUA==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id FB.0F.17842.ADEC2495; Thu, 15 Jun 2017 11:15:54 -0700 (PDT) X-AuditID: 11ab0218-4df929a0000045b2-c9-5942cedaed75 Received: from koseret (koseret.apple.com [17.151.62.39]) by relay7.apple.com (Apple SCV relay) with SMTP id 70.49.18088.9DEC2495; Thu, 15 Jun 2017 11:15:53 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ufkjAG2bhxPV6pRt001nwQ)" Received: from [17.153.78.222] (unknown [17.153.78.222]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORL0088GPEHWX20@koseret.apple.com>; Thu, 15 Jun 2017 11:15:53 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Thu, 15 Jun 2017 11:15:52 -0700 In-reply-to: <87k24dzk6t.fsf@alrua-x1> Cc: Juliusz Chroboczek , Babel at IETF To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUi2FCYqnvrnFOkQdd3NYsti7pZLOa3LmOz 2Pp+BbsDs8eSJT+ZPBZvecvoseXQRbYA5igum5TUnMyy1CJ9uwSujHNn4gtmZldM/D2ZqYFx QVQXIyeHhICJxIe7DexdjFwcQgJrmSQW3XzJDJPY3L2EGSKxilFi+c9LLCAJXgFBiR+T74HZ zAJhEm/mPGODKGplkrg0/zorSEJYQFqi68JdIJuDg01AS+LAGqMuRnagXhuJJTYgQWEBS4k3 R7xBalkEVCWmrocYzimgJrF59mUmiOEuEpuvbwCbJyJgL9H49QJYjZBAH6PEshWqEFfKStya fQnsSgmBJWwSZ87PZ53AKDQLyaGzkBw6C2g1s4C6xJQpuRBhbYkn7y6wQthqEgt/L2JCFl/A yLaKUTg3MTNHNzPPyEQvsaAgJ1UvOT93EyMoMlYzSexg/PLa8BCjAAejEg+vQoNTpBBrYllx Ze4hRmkOFiVx3gvNjpFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGGfKM8yckSQtq36OSXXb /USuF/ah/jlRHVfkWW8m6/uZxr7bFuZa993ewMTZ4ajLfzc/mQuTmhgTnr5KML4yr8HZ3Prs y9Rt+9ZM/WJxjTF9Wvy9bd9rGW9bnbVlZp6cvPSZVMwWmW2NKt2HJ+0V7/0hKcAWWefuXxcY 5PI9fFaXpBPj74kzlViKMxINtZiLihMBrRbvXm0CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUiON1OXffmOadIg+m/TC22LOpmsZjfuozN Yuv7FewOzB5Llvxk8li85S2jx5ZDF9kCmKO4bFJSczLLUov07RK4Ms6diS+YmV0x8fdkpgbG BVFdjJwcEgImEpu7lzB3MXJxCAmsYpRY/vMSC0iCV0BQ4sfke2A2s0CYxJs5z9ggilqZJC7N v84KkhAWkJbounAXyObgYBPQkjiwxqiLkR2o10ZiiQ1IUFjAUuLNEW+QWhYBVYmp6yGGcwqo SWyefZkJYriLxObrG8DmiQjYSzR+vQBWIyTQxyixbIUqxJWyErdmX2KewMg/C8lts5DcNgto G7OAusSUKbkQYW2JJ+8usELYahILfy9iQhZfwMi2ilGgKDUnsdJcL7GgICdVLzk/dxMjKIwb ClN3MDYutzrEKMDBqMTDy2zhGCnEmlhWXJl7iFGCg1lJhJdtI1CINyWxsiq1KD++qDQntfgQ ozQHi5I4b0mAU6SQQHpiSWp2ampBahFMlomDU6qBsfZsMQPXnZZdRy99iWrt+jC1e7GiifC3 cDYexR87izYWvwrbFb3UQiVE+m2d4ILX9+pm75JZzqT6bF+FnaLFdM09uSXO57SeXPZXdmd6 9+Xjr5lHav/0F/GsM1hy9KDEYvW9U753xe5gr/h3PmmtteqjZ0fKaq2bzF2+2qv3cK9ge8W3 4cbB40osxRmJhlrMRcWJAHl+xwhfAgAA Archived-At: Subject: Re: [babel] Cutoff date for rfc6126bis is 3 July X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jun 2017 18:16:00 -0000 --Boundary_(ID_ufkjAG2bhxPV6pRt001nwQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Thanks Toke, responses inline. > On Jun 15, 2017, at 02:14, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > David Schinazi writes: >=20 >> I've also added support for unicast Hellos, which I've renamed = Personal Hellos. >> I thought unicast/multicast were IP-level concepts and since these = Hellos have more >> interesting properties than their destination IP address, I named = them >> - Public Hellos -- which are multicast and equivalent to RFC6126 = Hellos >> - Personal Hellos -- which are unicast >=20 > For some reason I *really* don't like those names. Not sure why; too > anthropomorphic, perhaps? Anyway, that aside... [DS] I'm totally open to changing these, can you propose something other than unicast / multicast? >> I went with an approach different from Toke's, of having both of them >> co-exist. >=20 > Yeah, I guess you are right that just having them co-exist is better. >=20 >> Regarding packet encoding, I renamed the Reserved field in Hello TLVs >> to Flags, and added a PERSONAL flag (hex 8000). >=20 > I guess there's an implicit network-to-host byte order here; is that > always obvious when the field is not an integer field? That was the > reason why I opted for a 1-byte flags field. In either case we should > probably at least pick the same flag value... ;) [DS] I had the same thought, here's a clearer writeup based on the IKEv2 = RFC The Flags field is interpreted as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In the description below, a bit being 'set' means its value is '1', while 'cleared' means its value is '0'. 'X' bits MUST be cleared when sending and MUST be ignored on receipt. o P (PERSONAL) flag (8000 hexadecimal): if set, then this Hello represents a Personal Hello, otherwise it represents a Public Hello. I used 8000 because that's the leftmost one and in the Update TLV we = started from the left. >> It's a very early draft, but I think it conveys a possible solution. >=20 > A few things that I'm not sure are well-defined currently; consider > these questions that should be resolved: >=20 > - Is it allowed to not send multicast hellos at all (I think it should > be)? >=20 > - Is it legal for an implementation to completely ignore one type of > hello (probably should be, but could be problematic if we don't > guarantee that they are both always available, see below)? >=20 > - Is an implementation allowed to stop sending unicast hellos to a > neighbour after it started doing it? This could be problematic if the > other neighbour relies only on unicast to define neighbour > availability. >=20 > - When should a neighbour entry be expired? When we stop receiving > multicast hellos, or when we stop receiving any one type? [DS] I think the answer to these are intertwined. I see 3 aspects that = we can optimize for: - flexibility on the sender - flexibility on the receiver - interoperability between implementation strategies but we can't have all of these. I was initially thinking mainly about = interop, so on possible answer to these could be: (1) always send Public hellos (you can set the interval to 11 minutes) this allows interoperability with Public-only implementations (2) implementations can choose to ignore all Personal Hellos this makes it easy to make existing implementations compliant (3) implementations cannot ignore Public Hellos this allows interoperability with Public-only implementations implementations can give very high costs to neighbors with only = Public Hellos (4) if an implementation decides to use a given type of Hello, they MUST = honor the interval value they set (and keep sending) if they want to = participate (this is already somewhat implied by the definition of the Interval = field) (5) if we have received no hellos (neither Public nor Personal) from a = neighbor we MUST set their cost to infinite, and that's a good time to = consider expiring them The downside of this is that it forces Personal Hello implementations to = still support Public Hellos. Another strategy could be to change (1) nodes may decide to only send Personal Hellos (3) implementations may ignore all Public Hellos and add a note saying that doing so prevents interop and requires an = external discovery mechanism. What do people think? > - Should we recommend that IHUs be send the same way as the hello was > received? [DS] What's the rationale? Getting the multicast state of the link in both directions isn't particularly helpful the routing decisions mainly apply to unicast traffic. Thanks, David Schinazi= --Boundary_(ID_ufkjAG2bhxPV6pRt001nwQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Thanks Toke, responses inline.

On = Jun 15, 2017, at 02:14, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> = wrote:

David Schinazi <dschinazi@apple.com> writes:

I've also added support = for unicast Hellos, which I've renamed Personal Hellos.
I = thought unicast/multicast were IP-level concepts and since these Hellos = have more
interesting properties than their destination IP = address, I named them
- Public Hellos -- which are = multicast and equivalent to RFC6126 Hellos
- Personal = Hellos -- which are unicast

For = some reason I *really* don't like those names. Not sure why; too
anthropomorphic, perhaps? Anyway, that aside...

[DS] = I'm totally open to changing these, can you propose something = other
than unicast / multicast?

I went with an approach = different from Toke's, of having both of them
co-exist.

Yeah, I guess you are right that = just having them co-exist is better.

Regarding packet = encoding, I renamed the Reserved field in Hello TLVs
to = Flags, and added a PERSONAL flag (hex 8000).

I guess there's an implicit = network-to-host byte order here; is that
always obvious = when the field is not an integer field? That was the
reason = why I opted for a 1-byte flags field. In either case we should
probably at least pick the same flag value... ;)

[DS] = I had the same thought, here's a clearer writeup based on the IKEv2 = RFC

   The Flags =
field is interpreted as follows:
        =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        =
|P|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|
        =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   In the description below, a =
bit being 'set' means its value is '1',
   while 'cleared' =
means its value is '0'.  'X' bits MUST be cleared
   when sending and MUST be ignored on receipt.

   o  P (PERSONAL) flag (8000 hexadecimal): if set, then this Hello
      represents a Personal Hello, otherwise it represents a Public
      Hello.
I used 8000 because that's the = leftmost one and in the Update TLV we started from the = left.

It's a = very early draft, but I think it conveys a possible solution.

A few things that I'm not sure = are well-defined currently; consider
these questions that = should be resolved:

- Is it allowed to not = send multicast hellos at all (I think it should
=  be)?

- Is it legal for an = implementation to completely ignore one type of
=  hello (probably should be, but could be problematic if we don't
 guarantee that they are both always available, see = below)?

- Is an implementation allowed to = stop sending unicast hellos to a
 neighbour after it = started doing it? This could be problematic if the
=  other neighbour relies only on unicast to define neighbour
 availability.

- When = should a neighbour entry be expired? When we stop receiving
=  multicast hellos, or when we stop receiving any one type?

[DS] = I think the answer to these are intertwined. I see 3 aspects that we can = optimize for:
- flexibility on the sender
- = flexibility on the receiver
- interoperability between = implementation strategies
but we can't have all of these. I = was initially thinking mainly about interop,
so on possible = answer to these could be:
(1) always send Public hellos (you = can set the interval to 11 minutes)
    this allows = interoperability with Public-only implementations
(2) = implementations can choose to ignore all Personal = Hellos
    this makes it easy to make existing = implementations compliant
(3) implementations cannot ignore = Public Hellos
    this allows interoperability with = Public-only implementations
    implementations can = give very high costs to neighbors with only Public Hellos
(4) = if an implementation decides to use a given type of Hello, they MUST = honor
    the interval value they set (and keep = sending) if they want to participate
    (this is = already somewhat implied by the definition of the Interval = field)
(5) if we have received no hellos (neither Public nor = Personal) from a neighbor
    we MUST set their cost = to infinite, and that's a good time to consider expiring = them

The downside of this is that it = forces Personal Hello implementations to still support
Public = Hellos.

Another strategy could be to = change
(1) nodes may decide to only send Personal = Hellos
(3) implementations may ignore all Public = Hellos
and add a note saying that doing so prevents interop = and requires an external
discovery mechanism.

What do people think?

- Should we recommend that IHUs be send the same way as the = hello was
 received?

[DS] =  What's the rationale? Getting the multicast state of the = link
in both directions isn't particularly helpful the routing = decisions
mainly apply to unicast traffic.


Thanks,
David = Schinazi
= --Boundary_(ID_ufkjAG2bhxPV6pRt001nwQ)-- From nobody Thu Jun 15 11:43:32 2017 Return-Path: <7riw77@gmail.com> 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 4158A126CE8 for ; Thu, 15 Jun 2017 11:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 AgJk6snLEPsl for ; Thu, 15 Jun 2017 11:43:29 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 AD05A1200FC for ; Thu, 15 Jun 2017 11:43:29 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id m47so22983456iti.1 for ; Thu, 15 Jun 2017 11:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=5HJPpcCMuPgcTk5BI+oFvN/PBI+d8v3RzUc3YTRjNu4=; b=I60OBQCaInEcgrmC+3h+ZMW9NFruDCO8QF9Gc0jRIxRKNUeEu1TIo/A+ZoP1lc8xyu POAWrbSeaIf7GmCLCVTWJDZ26Aib8ze18/wCNDSpdz5TQECUuVr2/ULzbAcEjHTJF7xR mc42poOZ5Rpgs8YhoQdYDQdaAhwKclP3ciKDIkzm7+fpYdN7MlHNn4f4M90pFGgvcadQ GBtAH70El5udIY2IBCd+e965L/gWwMwl7CBHutGGOk0vCMShPnE2FjqrY2X3m3/WHdd+ ySYeTxfcHbtJVrR/VcfhbAeKdel2geVqc1NCltqnWPgQ3D22KE40morbE587P3DkoTBF VpsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=5HJPpcCMuPgcTk5BI+oFvN/PBI+d8v3RzUc3YTRjNu4=; b=Ojne4zTtivNaBH4pNuGSxTaOHz8WlhOe0vovzXTFwE+nVRbL7XpPOSY1A9XS2U/q5f 1vFiVmYLnTqyEBPhR/K1gW+aw1WBTkNLP9edBxKbE4iaN3OBf45pl0kMmX2Byte5wLuB unpY1JZwJ8OqAxHoN7RcxpWO+PVs3RN3m2TR6Is1fvd8ClKzL+XS2vk56y5bavDvgJyv UogStIGlMpxqQH1s2GUs0LK8l5U7UO+i7xy5ILSjKHb/bjVqkmFZT+z8xRHL9olynRmT Mu3ZYZiK3NtJNCMHHpBIsjoDUq0OhSsfdp8PV5ryrzfjs0oZICj+R30y0zneAqO9qSMi o88Q== X-Gm-Message-State: AKS2vOyivY6CwraP/C4+XPOF+tPqukhAfjQ7a9gsdM4g56H5ralloivM Fdabr8Fok7teORXa X-Received: by 10.36.225.142 with SMTP id n136mr6747424ith.64.1497552208937; Thu, 15 Jun 2017 11:43:28 -0700 (PDT) Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net. [108.78.210.25]) by smtp.gmail.com with ESMTPSA id z64sm441425ioe.61.2017.06.15.11.43.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 11:43:28 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'David Schinazi'" , =?UTF-8?Q?'Toke_H=C3=B8iland-J=C3=B8rgensen'?= Cc: "'Babel at IETF'" , "'Juliusz Chroboczek'" References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> In-Reply-To: Date: Thu, 15 Jun 2017 14:43:25 -0400 Message-ID: <037601d2e607$4671ac20$d3550460$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHcaZt+JfOUOhMIbEd5rEvBw0fjiAEtSNKoAb0/VRABysQ3GgHZvSuWod7C1PA= Content-Language: en-us Archived-At: Subject: Re: [babel] Cutoff date for rfc6126bis is 3 July X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jun 2017 18:43:31 -0000 =20 > [DS] I'm totally open to changing these, can you propose something = other > than unicast / multicast? What is wrong with unicast/multicast? I must have missed why these are = bad labels? =F0=9F=98=8A /r From nobody Thu Jun 15 12:08:32 2017 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 11939127866 for ; Thu, 15 Jun 2017 12:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 rfGujW0yssQ3 for ; Thu, 15 Jun 2017 12:08: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 79624127078 for ; Thu, 15 Jun 2017 12:08:27 -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/56228) with ESMTP id v5FJ8Mrx004138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 15 Jun 2017 21:08:22 +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/56228) with ESMTP id v5FJ8L2K020525; Thu, 15 Jun 2017 21:08:21 +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 967EEEB207; Thu, 15 Jun 2017 21:08:21 +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 LVqA-pEJ8HfZ; Thu, 15 Jun 2017 21:08:20 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 78E63EB206; Thu, 15 Jun 2017 21:08:20 +0200 (CEST) Date: Thu, 15 Jun 2017 21:08:20 +0200 Message-ID: <87wp8dcbmj.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , Babel at IETF In-Reply-To: References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> 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]); Thu, 15 Jun 2017 21:08:22 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 15 Jun 2017 21:08:22 +0200 (CEST) X-Miltered: at korolev with ID 5942DB26.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5942DB25.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5942DB26.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5942DB25.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 : 5942DB26.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5942DB25.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] Cutoff date for rfc6126bis is 3 July X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jun 2017 19:08:30 -0000 I need some more time to grok the fullness of the two proposals, but here are a few thoughts: Multicast/Unicast Hellos seem fine to me, I don't see any opportunity for confusion. There seems to be consensus to using a bit in the (newly defined) Flags field. I'm fine with that, if anyone has strong feelings, please yell now. I'm of opinion that we must support the Multicast Hellos-only case (meaning that an implementation MUST grok Unicast Hellos, but it MAY send Multicast Hellos only). I'm also of opinion that we must support the Unicast Hellos-only case (e.g. for NBMA links, where discovery is done by means external to the protocol -- Margaret, that's your hint). We must be extremely clear about the meaning of the intervals in Hellos. Does the Interval field of a Multicast Hello carry a promise to send another Multicast Hello, or does it carry a promise to send a Hello of any kind? (I believe that we need to implement it before you can have an opinion.) I've glanced across David's pull request, and it looks fine to me except for the issue in the last paragraph above. Toke, I'd be grateful if you could read it and let me know if there's anything in it you feel is wrong, or anything you wish to add. We want to get this or something similar merged and published in an I-D before the Prague cutoff (3 July). -- Juliusz From nobody Thu Jun 15 13:47:50 2017 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 0C581129455 for ; Thu, 15 Jun 2017 13:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 46TBT-Ber6Mo for ; Thu, 15 Jun 2017 13:47:47 -0700 (PDT) Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (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 130CB127ABE for ; Thu, 15 Jun 2017 13:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497559666; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1QPOe4AglJUujQDGzddbglBALeJapO+EAiSLe+UDHU0=; b=bqQTtnCQ8OkyBmK5iVpMpRyE+QounDYDcxS31Gtec/o5grNeSBES/tqxedsVBy81 5ZGWsNIkOGhZpHTU6eH4I4rSGSPnL20DL+PCJSYnzEfwsYUHcbdjv3ptbuel8IMJ /JWl3/ELmsyazsfL9GTEGkFJZQHJHi77B+d8KhJ+cdHMm/GCoMXQSKFM1OR8Lh3U VNk71QbLka7SYwnpu/AEeM5x94qjPOeJ/zxuOSpSZDrxs/e3aQnvrCMyhZqTvPD9 VJreicip0NtAHfZRBiLJcx/VZY3yZ+njVkxd3bB2/QfSGkc3wPuKXf4HSS2jlxP5 ugYeCavGEyWOrsdofciC3A==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id D5.B7.02110.172F2495; Thu, 15 Jun 2017 13:47:46 -0700 (PDT) X-AuditID: 11ab0219-f59fb7000000083e-cb-5942f27020dc Received: from koseret (koseret.apple.com [17.151.62.39]) by relay6.apple.com (Apple SCV relay) with SMTP id 17.F9.25627.072F2495; Thu, 15 Jun 2017 13:47:44 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_TaNP/YwxstUeUAHvhnqIxA)" Received: from da0602a-dhcp103.apple.com (da0602a-dhcp103.apple.com [17.226.23.103]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORL00052WFJOQ80@koseret.apple.com>; Thu, 15 Jun 2017 13:47:44 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Thu, 15 Jun 2017 13:47:43 -0700 In-reply-to: <87wp8dcbmj.wl-jch@irif.fr> Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Babel at IETF To: Juliusz Chroboczek References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUi2FAYpVv0ySnSYN0sfosti7pZLOa3LmOz 2Pp+BbsDs8eSJT+ZPBZvecvoseXQRbYA5igum5TUnMyy1CJ9uwSujAOrDzAVrDSpuDJ3FVsD 43btLkZODgkBE4llLS0sXYxcHEICa5gkZtxtZIRJdK3/AZVYxSixtfErC0iCV0BQ4sfke2A2 s0CYxLsdK5kgihYzSfS3fmYCSQgLSEt0XbjL2sXIwcEmoCVxYI0RRK+NxKyHl8DCwgKWEm+O eIOYLAKqEndeRoBUcApoSHy6eoAVYnqiRN/dP2C2iICKxPJpz9ghNt1llHhx8jIzxJ2yErdm X2IGSUgIrGGT2LD4O9sERqFZSE6dheRUCFtL4vujVqA4B5AtL3HwvCxEWFPi2b1P7BC2tsST dxdYFzCyrWIUzk3MzNHNzDMy1UssKMhJ1UvOz93ECIqP1UySOxi/vjY8xCjAwajEw6vQ4BQp xJpYVlyZe4hRmoNFSZz3UrNjpJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGc4sH7MpPqwPW fTtwdspLOQWmwIr0soy+/fdXn/z4XsJaTa7ix7uNFYkLNBcv+7Q72PeOeCBbVu+dPId1sxgP R5ROWS5T0eR4y121UONo7L5ELk4FWz/NRWLuB8+rnpLTjjAs9ZTjdKzt/MClviDPxH+lovvk vx+cG6amaGnNeGIWdHlfqocSS3FGoqEWc1FxIgCiQM9UcAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUiON1OXbfgk1OkQdNFMYsti7pZLOa3LmOz 2Pp+BbsDs8eSJT+ZPBZvecvoseXQRbYA5igum5TUnMyy1CJ9uwSujAOrDzAVrDSpuDJ3FVsD 43btLkZODgkBE4mu9T9Yuhi5OIQEVjFKbG38ygKS4BUQlPgx+R6YzSwQJvFux0omiKLFTBL9 rZ+ZQBLCAtISXRfusnYxcnCwCWhJHFhjBNFrIzHr4SWwsLCApcSbI94gJouAqsSdlxEgFZwC GhKfrh5ghZieKNF39w+YLSKgIrF82jN2iE13GSVenLzMDHGnrMSt2ZeYJzDyz0Jy3Swk10HY WhLfH7UCxTmAbHmJg+dlIcKaEs/ufWKHsLUlnry7wLqAkW0Vo0BRak5ipZleYkFBTqpecn7u JkZQMDcURu1gbFhudYhRgINRiYd3haljpBBrYllxZe4hRgkOZiUR3tvrgUK8KYmVValF+fFF pTmpxYcYpTlYlMR5iwOcIoUE0hNLUrNTUwtSi2CyTBycUg2Mgod7Jkz2+ztxeWFX5IqCBzI/ RMoEHZJzVCbtdMtTeh74jUN9rtDaU0dTqq6eqNv46qgER5PgTK553wXqtWqqLxcGXzyQvyA1 ZeOvq9+Ttx3Zu8Uv+NajIK3j6z9zzvAtLBG7/uKc1ocHp29lOh4uW6hwjmc106VHdvZPjxjZ X54mt/B3tsQiOyWW4oxEQy3mouJEAAnxdIViAgAA Archived-At: Subject: Re: [babel] Cutoff date for rfc6126bis is 3 July X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jun 2017 20:47:49 -0000 --Boundary_(ID_TaNP/YwxstUeUAHvhnqIxA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Thanks Juliusz, responses inline. David Schinazi > On Jun 15, 2017, at 12:08, Juliusz Chroboczek wrote: > > I need some more time to grok the fullness of the two proposals, but here > are a few thoughts: > > Multicast/Unicast Hellos seem fine to me, I don't see any opportunity for > confusion. [DS] I can live with that. I'll give people a few days to comment on this and I'll update the branch. > There seems to be consensus to using a bit in the (newly defined) Flags > field. I'm fine with that, if anyone has strong feelings, please yell > now. > > I'm of opinion that we must support the Multicast Hellos-only case > (meaning that an implementation MUST grok Unicast Hellos, but it MAY send > Multicast Hellos only). I'm also of opinion that we must support the > Unicast Hellos-only case (e.g. for NBMA links, where discovery is done by > means external to the protocol -- Margaret, that's your hint). [DS] If we're supporting Multicast-only and Unicast-only, then these will not interoperate. That's fine by me, we'll just need to add text to make that clear. > We must be extremely clear about the meaning of the intervals in Hellos. > Does the Interval field of a Multicast Hello carry a promise to send > another Multicast Hello, or does it carry a promise to send a Hello of any > kind? (I believe that we need to implement it before you can have an > opinion.) [DS] The way I implemented it (and what I tried to convey in the spec) is that the Interval and Seqno is specific to a Unicast vs Multicast. This is what I had on that topic for the Hello TLV: Interval An upper bound, expressed in centiseconds, on the time after which the sending node will send a new Hello TLV with the same setting of the PERSONAL flag. This MUST NOT be 0. I think this is absolutely necessary for Unicast and Multicast to share links. If it's not clear enough, should we mention this in other parts of the spec as well? > I've glanced across David's pull request, and it looks fine to me except > for the issue in the last paragraph above. Toke, I'd be grateful if you > could read it and let me know if there's anything in it you feel is wrong, > or anything you wish to add. We want to get this or something similar > merged and published in an I-D before the Prague cutoff (3 July). --Boundary_(ID_TaNP/YwxstUeUAHvhnqIxA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Thanks Juliusz, responses inline.

David Schinazi

On Jun 15, 2017, at 12:08, = Juliusz Chroboczek <jch@irif.fr> wrote:

I = need some more time to grok the fullness of the two proposals, but = here
are a few thoughts:

Multicast/Unicast Hellos seem fine to me, I don't see any = opportunity for
confusion.

[DS] = I can live with that. I'll give people a few days to comment on this = and
I'll update the branch.

There seems to = be consensus to using a bit in the (newly defined) Flags
field.  I'm fine with that, if anyone has strong = feelings, please yell
now.

I'm = of opinion that we must support the Multicast Hellos-only case
(meaning that an implementation MUST grok Unicast Hellos, but = it MAY send
Multicast Hellos only).  I'm also of = opinion that we must support the
Unicast Hellos-only case = (e.g. for NBMA links, where discovery is done by
means = external to the protocol -- Margaret, that's your hint).

[DS] = If we're supporting Multicast-only and Unicast-only, then these will = not
interoperate. That's fine by me, we'll just need to add = text to make that clear.

We must be extremely clear = about the meaning of the intervals in Hellos.
Does the = Interval field of a Multicast Hello carry a promise to send
another Multicast Hello, or does it carry a promise to send a = Hello of any
kind?  (I believe that we need to = implement it before you can have an
opinion.)

[DS] = The way I implemented it (and what I tried to convey in the spec) = is
that the Interval and Seqno is specific to a Unicast vs = Multicast. This is
what I had on that topic for the Hello = TLV:
Interval  An upper bound, expressed in centiseconds, on the =
time
          after which the sending node will send a new Hello TLV with
          the same setting of the PERSONAL flag.  This MUST NOT be =
0.
I think this is absolutely necessary for Unicast = and Multicast to share links.
If it's not clear = enough, should we mention this in other parts of the spec as = well?

I've glanced across David's pull request, and = it looks fine to me except
for the issue in the last = paragraph above.  Toke, I'd be grateful if you
could = read it and let me know if there's anything in it you feel is wrong,
or anything you wish to add.  We want to get this or = something similar
merged and published in an I-D before = the Prague cutoff (3 = July).
= --Boundary_(ID_TaNP/YwxstUeUAHvhnqIxA)-- From nobody Thu Jun 15 15:45:32 2017 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 584BA12EABA for ; Thu, 15 Jun 2017 15:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 EFRlVxLUcYNE for ; Thu, 15 Jun 2017 15:45:29 -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 2157F12946D for ; Thu, 15 Jun 2017 15:45:28 -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/56228) with ESMTP id v5FMjKnp023231; Fri, 16 Jun 2017 00:45:20 +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 79FE1EB206; Fri, 16 Jun 2017 00:45:20 +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 C5Mr9JpiBCnj; Fri, 16 Jun 2017 00:45:19 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9A93DEB201; Fri, 16 Jun 2017 00:45:17 +0200 (CEST) Date: Fri, 16 Jun 2017 00:45:17 +0200 Message-ID: <87shj0dg5e.wl-jch@irif.fr> From: Juliusz Chroboczek To: "Russ White" <7riw77@gmail.com> Cc: "'David Schinazi'" , "=?UTF-8?Q?'Toke_H=C3=B8iland-J=C3=B8rgensen'?=" , "'Babel at IETF'" In-Reply-To: <037601d2e607$4671ac20$d3550460$@gmail.com> References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <037601d2e607$4671ac20$d3550460$@gmail.com> 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]); Fri, 16 Jun 2017 00:45:22 +0200 (CEST) X-Miltered: at korolev with ID 59430E00.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59430E00.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 : 59430E00.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] Cutoff date for rfc6126bis is 3 July X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jun 2017 22:45:31 -0000 > What is wrong with unicast/multicast? I must have missed why these are > bad labels? I think David is concerned about the confusion between the network-layer destination address (unicast/multicast) and the types of application-layer packets (Unicast/Multicast Hellos). As a matter of fact, it is perfectly legal to send a Multicast Hello to all neighbours over multiple unicasts. While I understand David's unease, I don't think the confusion is likely to cause trouble, and unless somebody comes up with some absolutely perfect terminology that we all agree on, I suggest we stick to Unicast/Multicast Hellos. -- Juliusz From nobody Thu Jun 15 15:49:44 2017 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 B060E129465 for ; Thu, 15 Jun 2017 15:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 rwjXL3CV9c6t for ; Thu, 15 Jun 2017 15:49:41 -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 E717312946D for ; Thu, 15 Jun 2017 15:49:40 -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/56228) with ESMTP id v5FMnat0024198; Fri, 16 Jun 2017 00:49:36 +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 E2340EB2C1; Fri, 16 Jun 2017 00:49:36 +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 JE07nKeh_wrc; Fri, 16 Jun 2017 00:49:35 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B38F1EB28B; Fri, 16 Jun 2017 00:49:35 +0200 (CEST) Date: Fri, 16 Jun 2017 00:49:35 +0200 Message-ID: <87r2ykdfy8.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , Babel at IETF In-Reply-To: References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.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]); Fri, 16 Jun 2017 00:49:36 +0200 (CEST) X-Miltered: at korolev with ID 59430F00.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59430F00.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 : 59430F00.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] Cutoff date for rfc6126bis is 3 July X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jun 2017 22:49:43 -0000 > [DS] If we're supporting Multicast-only and Unicast-only, then these will not > interoperate. That's fine by me, we'll just need to add text to make that > clear. What I meant is that all implementations MUST be able to parse both kinds of Hellos, but an implementation may choose to only ever send Multicast Hellos. It may also choose to only send Unicast Hellos, but in that case you need some other discovery mechanism. > [DS] The way I implemented it (and what I tried to convey in the spec) is > that the Interval and Seqno is specific to a Unicast vs Multicast. This is > what I had on that topic for the Hello TLV: > Interval An upper bound, expressed in centiseconds, on the time > after which the sending node will send a new Hello TLV with > the same setting of the PERSONAL flag. This MUST NOT be 0. > I think this is absolutely necessary for Unicast and Multicast to share links. Fully agreed. Now what about an implementation that sends mostly Multicast Hellos, but occasionally sends a Unicast one? Such an implementation needs to express the notion that it makes no promise to ever send another Unicast hello. > If it's not clear enough, should we mention this in other parts of the > spec as well? Yes, I think we need an explanatory paragraph somewhere. -- Juliusz From nobody Thu Jun 15 16:39:46 2017 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 93EFC12951F for ; Thu, 15 Jun 2017 16:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 nB-pOAPX0ESt for ; Thu, 15 Jun 2017 16:39:41 -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 CDDCC1293F9 for ; Thu, 15 Jun 2017 16:39:40 -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/56228) with ESMTP id v5FNdc2S000585; Fri, 16 Jun 2017 01:39: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 72D2FEB201; Fri, 16 Jun 2017 01:39: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 cjIGDWKyVMBW; Fri, 16 Jun 2017 01:39:37 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3AB03EB209; Fri, 16 Jun 2017 01:39:36 +0200 (CEST) Date: Fri, 16 Jun 2017 01:39:35 +0200 Message-ID: <87k24cddmw.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake , Russ White CC: 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 [194.254.61.138]); Fri, 16 Jun 2017 01:39:38 +0200 (CEST) X-Miltered: at korolev with ID 59431ABA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59431ABA.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 : 59431ABA.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] What to do about the IANA registries? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jun 2017 23:39:43 -0000 Dear Chairs, Rfc6126bis is going to cause some upheaval to the Babel-related IANA registries: - due to the addition of the mandatory bit, the allocations in the sub-TLV registry are going to change (different reserved ranges); - a new registry will be required for Hello flags. Could you please explain how we should achieve these changes? Just put them in an IANA considerations section in rfc6126bis? Or is there a better way? Thanks, -- Juliusz From nobody Thu Jun 15 16:42:13 2017 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 B33F1127601 for ; Thu, 15 Jun 2017 16:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 SdP9MYKPMync for ; Thu, 15 Jun 2017 16:42:08 -0700 (PDT) Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (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 30DE412951F for ; Thu, 15 Jun 2017 16:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497570126; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=KG2pya/1j2KD1XPJflPyGhUGQO3jQobKS6jM47TTs4k=; b=YrBX3JUPbmjUFzMZe3MKVrtUWDgUJCbQR7mj074itpIUFvegHqKsifQucHS+LDf/ aa0ehr/58oq2DuB809BQywJWNQrB259dWOWE+x1H0N0G/R8FnqqQweiwgMWZxGOl s3jXAVEkEuTIXt2mnAk9FZxYP4js68qR/b3f+kS5kd7B933GAnZ6LiBGsQoxic+c Xan6y2rCvLhhNkubjOpz9BdAgpLUib+gWweSxN6Jz3DAQJn8f+RsDmuU+cjtqF/+ 90olhBcHzpvRai5rusxmcMDJJmgiYZSM+wNJE2Tyv3lG/BvsDcb7kK84y3Lmh8Se ZRB3NfTB9YKO5H1Uhp9biw==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id F8.76.03314.D4B13495; Thu, 15 Jun 2017 16:42:06 -0700 (PDT) X-AuditID: 11ab0215-fb1bb9a000000cf2-15-59431b4d6f83 Received: from kencur (kencur.apple.com [17.151.62.38]) by relay4.apple.com (Apple SCV relay) with SMTP id AB.8F.16411.D4B13495; Thu, 15 Jun 2017 16:42:05 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from da0602a-dhcp103.apple.com (da0602a-dhcp103.apple.com [17.226.23.103]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORM00LDL4I5I790@kencur.apple.com>; Thu, 15 Jun 2017 16:42:05 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87r2ykdfy8.wl-jch@irif.fr> Date: Thu, 15 Jun 2017 16:42:04 -0700 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Babel at IETF Message-id: <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUi2FAYrusn7RxpcPsFn8WWRd0sFvNbl7FZ bH2/gt2B2WPJkp9MHou3vGX02HLoIlsAcxSXTUpqTmZZapG+XQJXxtNft1gL1ohUbN22jLmB sVmgi5GTQ0LAROJ0zx/WLkYuDiGBNUwSR170s8EkHt16zw6RWMEo8aB1FzNIgldAUOLH5Hss XYwcHMwC8hIHz8uChJkFtCS+P2plAbGFBBYySUx/qANiCwtIS3RduMsKUi4sYCnx5og3iMkG VH5gjRFIBaeAhsSMd9sYQcIsAqoSz15KQgxMlOi7C3IZyE4biWMHTrLBXTm79SQ7SEJEQEVi +bRn7BAXy0rcmn2JGaRIQmAKm8Shff+YJjAKz0Jy9CyEo2chOXoBI/MqRuHcxMwc3cw8I0O9 xIKCnFS95PzcTYygUF/NJLqDcf4rw0OMAhyMSjy8FU1OkUKsiWXFlbmHGKU5WJTEeZX/AoUE 0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwMuml2/t3rD5XytJyouh2YTTPNLOo21JRGw+fb9m5 Zkfb9jkelXsE+4WvO9h4y12aL/cyxv11XhMPw4S27eYskd7pyrMOCWseXVabK6NyeF7ODa5K t+fcYZcPhAT8lsrOkvM4lXv1cU/ksT171pUI7PeeMVGLZ2MlR4A3v8PXjCvrJW6ac+5TYinO SDTUYi4qTgQASXoixlYCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUiON1OTddX2jnSYNY0RYsti7pZLOa3LmOz 2Pp+BbsDs8eSJT+ZPBZvecvoseXQRbYA5igum5TUnMyy1CJ9uwSujKe/brEWrBGp2LptGXMD Y7NAFyMnh4SAicSjW+/Zuxi5OIQEVjBKPGjdxQyS4BUQlPgx+R5LFyMHB7OAvMTB87IgYWYB LYnvj1pZQGwhgYVMEtMf6oDYwgLSEl0X7rKClAsLWEq8OeINYrIBlR9YYwRSwSmgITHj3TZG kDCLgKrEs5eSEAMTJfru/mGF2GkjcezASTaIY9YwScxuPckOkhARUJFYPu0ZO8TFshK3Zl9i nsAoMAvJnbMQ7pyF5M4FjMyrGAWKUnMSK030EgsKclL1kvNzNzGCArOhMHwH479lVocYBTgY lXh4GSwcI4VYE8uKK3MPMUpwMCuJ8N5eDxTiTUmsrEotyo8vKs1JLT7EKM3BoiTOWxLgFCkk kJ5YkpqdmlqQWgSTZeLglGpglL3HuDR/vptu1uOCVN/wok2F85a03iwIc/uXVHyNu/DPHI+k Q6vzt78rKHSd0pd6aGLi7/TU6LuPtoV8O5Fs9HLy2bnBuxT9I7Tbd8Y18Ot29gvequv//q16 e21j9aQj8tNUM8JnGG/jL3i9l1kmd+qPB7stpDY/VGdk2ObAEqw+Ue3QYf9PSizFGYmGWsxF xYkAUz3a9EgCAAA= Archived-At: Subject: Re: [babel] Cutoff date for rfc6126bis is 3 July X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jun 2017 23:42:12 -0000 > On Jun 15, 2017, at 15:49, Juliusz Chroboczek wrote: > >> [DS] If we're supporting Multicast-only and Unicast-only, then these will not >> interoperate. That's fine by me, we'll just need to add text to make that >> clear. > > What I meant is that all implementations MUST be able to parse both kinds > of Hellos, but an implementation may choose to only ever send Multicast > Hellos. It may also choose to only send Unicast Hellos, but in that case > you need some other discovery mechanism. Is there benefit in requiring all implementations to parse Multicast? If I only send Unicast and you only parse Multicast we're not going to interoperate anyway, so might as well remove the requirement that everyone needs to parse Multicast. >> [DS] The way I implemented it (and what I tried to convey in the spec) is >> that the Interval and Seqno is specific to a Unicast vs Multicast. This is >> what I had on that topic for the Hello TLV: >> Interval An upper bound, expressed in centiseconds, on the time >> after which the sending node will send a new Hello TLV with >> the same setting of the PERSONAL flag. This MUST NOT be 0. >> I think this is absolutely necessary for Unicast and Multicast to share links. > > Fully agreed. > > Now what about an implementation that sends mostly Multicast Hellos, but > occasionally sends a Unicast one? Such an implementation needs to express > the notion that it makes no promise to ever send another Unicast hello. I think the only way to allow occasional Unicast Hellos would be to allow the Interval to be 0 if the Hello is Unicast. I'm not sure that's reasonable, because if you only ever send Unicast and send it with an Interval of 0, I don't know when to expire you from my neighbor table. >> If it's not clear enough, should we mention this in other parts of the >> spec as well? > > Yes, I think we need an explanatory paragraph somewhere. I had added a paragraph to section 3.4.1 (Reverse Reachability Detection): The dichotomy between Public and Personal Hellos (and the fact that they have separate sequence numbers and intervals) allows implementations to use different intervals based on link properties. Public Hellos are sent over multicast, which allows discovery of new neighbors but may cause issues on link layers where multicast is degraded. Personal Hellos are sent over unicast, improving reliability on these networks. Perhaps that needs to be even more explicit on the topic of Intervals. Thanks, David Schinazi From nobody Thu Jun 15 23:10:57 2017 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 5D582124E15 for ; Thu, 15 Jun 2017 23:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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_LOW=-0.7, 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 8BFig0ZUQ6Ld for ; Thu, 15 Jun 2017 23:10:53 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 2D675126D45 for ; Thu, 15 Jun 2017 23:10:53 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id t87so24398410ioe.0 for ; Thu, 15 Jun 2017 23:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FqWluicE80m8ilqlh5DeB2pGgmIkVrJeuTES8W4eSFE=; b=iRxmGHTcUi8ttp3hhxqLeKcmfxnokDBsFXMDqqk1b5XqlJMw5eW4yfhX0TT8XOf2rc d5VBjCpXK83t2UGMN5NVpLxZAe0kYLMI8VmSV0TjQ6k1evv6czAUMzGyGzIAM3CaNNF4 ykywS6i8DyXV9rck8bMedZ8THQj6MevDshvSS5JrAqDGdcAusYvLRRtIEx22B2PWuX/Z EltaWt3agk8Sc8czESyz5OO9B3WHhQDAhbvVvQZ9y5NeYaTZKlgmX+Q0mokQ1dVAgSjw rIPEcsFPzyR7TqgPE2hdNsS9aq9xtp2GYbJx34fq4xy9guLbPzOBKLT8bbcz3gzWiWk3 hozw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FqWluicE80m8ilqlh5DeB2pGgmIkVrJeuTES8W4eSFE=; b=p/5pTMyttB3jgis88fQDZQhdaW4LvrVmALhP4q8bQbW0UzD/sAH3MEpx8cpvlwL/Rq I3PfycpuXgJE+u+WZZoiFOJHR8tO1NgbupGbKmaH1atPnaB/17ZgbrRViungt9ouRAK+ Ro/Gt93kMRVfPVGJf5LARJn6mnpGo1DQl0sFZaue0RZCbWsnRzNcIo35zASOiepdMkof hF0XcO56Vnwag9G4GW+Bj13Hg1jCkpGuXLOKDqp0U/j93fendJ9x4Fq0N0Ox5RoEKCvB 3Hy5hk85joJCU/9iHPdSOemTFIjUDG4ItA3qxMwPbQVqj3luNewHBDPBWshVZCY05r0N Qq4Q== X-Gm-Message-State: AKS2vOwWK1Qn6j91abItEfpNBNTvGzVNWFJUflgLsyAb7v5Bzgfp7ivx 3909gJSUSe3JXhwWXTV2ALrzly4mvg== X-Received: by 10.107.4.19 with SMTP id 19mr8311659ioe.95.1497593452450; Thu, 15 Jun 2017 23:10:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.131.152 with HTTP; Thu, 15 Jun 2017 23:10:36 -0700 (PDT) In-Reply-To: <87k24cddmw.wl-jch@irif.fr> References: <87k24cddmw.wl-jch@irif.fr> From: Donald Eastlake Date: Fri, 16 Jun 2017 02:10:36 -0400 Message-ID: To: Juliusz Chroboczek Cc: Russ White , Babel at IETF Content-Type: multipart/alternative; boundary="001a113ee748c097c805520da571" Archived-At: Subject: Re: [babel] What to do about the IANA registries? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jun 2017 06:10:55 -0000 --001a113ee748c097c805520da571 Content-Type: text/plain; charset="UTF-8" Hi Juliusz, On Thu, Jun 15, 2017 at 7:39 PM, Juliusz Chroboczek wrote: > > Dear Chairs, > > Rfc6126bis is going to cause some upheaval to the Babel-related IANA > registries: > > - due to the addition of the mandatory bit, the allocations in the > sub-TLV registry are going to change (different reserved ranges); > - a new registry will be required for Hello flags. Good point. > Could you please explain how we should achieve these changes? Just put > them in an IANA considerations section in rfc6126bis? Or is there > a better way? You basically want to put all the changes/augments to the IANA registries in the rfc6126bis draft. - If you are just adding code points, you should normally just refer to the IANA registry. - If you are changing something about a registry, then I think the draft needs to either say that it updates or obsoletes the RFC that previously set up So, a registry change to the Babel sub-TLV registry implies to me that the draft needs to at least update RFC 7557.However, since this is a new complete specification of 6126+7557, isn't it actually the case that it obsoletes both RFC 6126 and RFC 7557? If so, that should be noted on the title page and the IANA Considerations section should also direct that all references in the IANA Babel registries be changed to refer to the new document. > Thanks, > > -- Juliusz Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com --001a113ee748c097c805520da571 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Juliusz,

On Thu, Jun 15, 2017 at 7:39 PM, Julius= z Chroboczek <jch@irif.fr> wrote:<= br>>
> Dear Chairs,
>
> Rfc6126bis is going to cause s= ome upheaval to the Babel-related IANA
> registries:
>
> = =C2=A0 - due to the addition of the mandatory bit, the allocations in the> =C2=A0 =C2=A0 sub-TLV registry are going to change (different reserv= ed ranges);
> =C2=A0 - a new registry will be required for Hello flag= s.

Good point.

> Could you please explain how we should a= chieve these changes?=C2=A0 Just put
> them in an IANA considerations= section in rfc6126bis?=C2=A0 Or is there
> a better way?

You = basically want to put all the changes/augments to the IANA registries in th= e rfc6126bis draft.
  • If you are just adding code points, y= ou should normally just refer to the IANA registry.
  • If you are = changing something about a registry, then I think the draft needs to either= say that it updates or obsoletes the RFC that previously set up=C2=A0
    <= /li>
So, a registry change to the Babel sub-TLV registry imp= lies to me that the draft needs to at least update RFC 7557.However, since = this is a new complete specification of 6126+7557, isn't it actually th= e case that it obsoletes both RFC 6126 and RFC 7557? If so, that should be = noted on the title page and the IANA Considerations section should also dir= ect that all references in the IANA Babel registries be changed to refer to= the new document.

> Thanks,
>
> -- Juliusz
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 3= rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01= 757 USA
=C2=A0d3e3e3@gmail.com
--001a113ee748c097c805520da571-- From nobody Fri Jun 16 00:03:17 2017 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 3BC8E12EC99 for ; Fri, 16 Jun 2017 00:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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_LOW=-0.7, 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 ByFPs9agZ0rp for ; Fri, 16 Jun 2017 00:03:13 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 732BD12F4EA for ; Fri, 16 Jun 2017 00:03:11 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id m62so30242752itc.0 for ; Fri, 16 Jun 2017 00:03:11 -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; bh=Leii24S8bSSrGm9qccO+jcFmPJIijnQ+fCCKJxrHGn4=; b=UzAIfs6CzYDHwdCYtvLafxFq7vp/MMX2L73vipoP0IPXStJ3AdZV50KPjA0lOw4GGZ 9R1td+tGk81ZmS2gGx/SIAwNzjeEZenDD+MtRH0uwwCh0sPT8QoU4xijOQOgmkSHocpu blJWsLtX/KA4MyU31/aambhAOIsRKM7gHmnyM1dPOBQboXmUzv2Tu/yU0wIHg48yW1Ef KnCbh8bgj+duM/yO+ktZKKZCOanpOVG9ehss+C3+cAMqmf32qoexDr68yFEXgczhJ85x 5z0uW/4H1kbfIId8+mu3FveTGkxrRiIIv7iKJ9mz2FNizuGjZBf0MGuxtCexiwuwTbRT 9m6g== 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; bh=Leii24S8bSSrGm9qccO+jcFmPJIijnQ+fCCKJxrHGn4=; b=Gu3auwJGWgtMW4QD2vsifXiVRmA8FtyWejXWFSDoqOtftwMMetAQahNJDpQklCKcwL wLRoKPyO6fm+viVgrrsi2WmIdIOqB17juIyYWqHzS2Am3mknj+R1RMZIzKeloIpBIsjG Lx28I5ornq+4VlyOIuQG7r6beOYEs/rcovl64jjCHIKiFQ5b6VasS/V8DRsxJgKwENgd 3u4AzR84LEf1HHUQ3Mb0nzqzhZ1x1BR85pYJtCcRxVEPEsa3K8U/iqB3tMlZkwyeWkWW YT2ia9jPyhMVD+Z9xScryFn/0bLG6HDSJvQOk2ju4n5eFx9Cuov/1r4bwXXoEd0V9CDD D2Xw== X-Gm-Message-State: AKS2vOwsN35/UOA2TXAij+RrUHaqTiQIf4nBHOYuStXt/73ffdObtIoX D4A5jPUwAM/RZ1TVyycvDf3QRL5jcdWn+xg= X-Received: by 10.36.53.70 with SMTP id k67mr9114400ita.79.1497596590756; Fri, 16 Jun 2017 00:03:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.131.152 with HTTP; Fri, 16 Jun 2017 00:02:55 -0700 (PDT) From: Donald Eastlake Date: Fri, 16 Jun 2017 03:02:55 -0400 Message-ID: To: Babel at IETF Content-Type: multipart/alternative; boundary="001a114abeeccf1c0a05520e6030" Archived-At: Subject: [babel] Call for Babel presentations at IETF-99 in Prague X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jun 2017 07:03:15 -0000 --001a114abeeccf1c0a05520e6030 Content-Type: text/plain; charset="UTF-8" Hi, We expect to have a one hour Babel session at the IETF Prague meeting in July (see https://ietf.org/meeting/99/index.html). Please send email to babel-chairs@ietf.org or to this mailing list if you would like to present. Thanks, Donald [co-chair] =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com --001a114abeeccf1c0a05520e6030 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

We expect to have a one hour Babel = session at the IETF Prague meeting in July
(see=C2=A0https://ietf.org/meeting/99/index.ht= ml). Please send email to babe= l-chairs@ietf.org or to this mailing list if you would like to present.=

Thanks,Donald [co-chair]
=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=A0155 Beaver Street, Milford, MA 01757= USA
=C2=A0d3e3e3@= gmail.com
--001a114abeeccf1c0a05520e6030-- From nobody Fri Jun 16 01:44:13 2017 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 C9C771316CA for ; Fri, 16 Jun 2017 01:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46FV_3ZOLYSY for ; Fri, 16 Jun 2017 01:44:09 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 7EC091316C7 for ; Fri, 16 Jun 2017 01:44:09 -0700 (PDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1497602641; bh=kPpfaVhO2UGH79J2E0vz4duC1nE+wwLhDta2wD2ls8Q=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=dJJv0ixx+snGeuV9fAgosmvjTEVXxQKZSuGDktfmOvz9QnFj6cIiMqc0u+aRJN+NK xvuZiQStH0ydkWSNtGkdUFku8iB4J77LUmWZ7qpvmK2iqD4N2y90hSi3IJCxaIYAz1 rtetAyE4VaH8j0/ju+XVxEBNi/aDVJNf/cLLVv7PSTCiV5SsdArftVaG+jWTDGyQdU wYj01Eo4fMQle/cY1dxINb66x3bf4YEJWQBeUyDD0T3lYS+HvBEo67xmCnMNXQtwUi AchzH4Q9+Ge+/k1WksuharBaYpPxT2qEKVNYR85CQrCsR79LsUCimK4rmy/HCF035U WkdsIuaKoMYlA== To: David Schinazi Cc: Juliusz Chroboczek , Babel at IETF References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> Date: Fri, 16 Jun 2017 10:43:55 +0200 In-Reply-To: <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> (David Schinazi's message of "Thu, 15 Jun 2017 16:42:04 -0700") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87y3ss5nlg.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Cutoff date for rfc6126bis is 3 July X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jun 2017 08:44:12 -0000 David Schinazi writes: >> On Jun 15, 2017, at 15:49, Juliusz Chroboczek wrote: >> >>> [DS] If we're supporting Multicast-only and Unicast-only, then these will not >>> interoperate. That's fine by me, we'll just need to add text to make that >>> clear. >> >> What I meant is that all implementations MUST be able to parse both kinds >> of Hellos, but an implementation may choose to only ever send Multicast >> Hellos. It may also choose to only send Unicast Hellos, but in that case >> you need some other discovery mechanism. > > Is there benefit in requiring all implementations to parse Multicast? > If I only send Unicast and you only parse Multicast we're not going to > interoperate anyway, so might as well remove the requirement that > everyone needs to parse Multicast. If we require all implementations to understand both sorts of hello we ensure that there's always a way to get "in touch" with another implementation. I think the language on sending multicast hellos should be something like "SHOULD send multicast hellos unless there is another out-of-band discovery mechanism". >>> [DS] The way I implemented it (and what I tried to convey in the spec) is >>> that the Interval and Seqno is specific to a Unicast vs Multicast. This is >>> what I had on that topic for the Hello TLV: >>> Interval An upper bound, expressed in centiseconds, on the time >>> after which the sending node will send a new Hello TLV with >>> the same setting of the PERSONAL flag. This MUST NOT be 0. >>> I think this is absolutely necessary for Unicast and Multicast to share links. >> >> Fully agreed. >> >> Now what about an implementation that sends mostly Multicast Hellos, but >> occasionally sends a Unicast one? Such an implementation needs to express >> the notion that it makes no promise to ever send another Unicast hello. > > I think the only way to allow occasional Unicast Hellos would be to > allow the Interval to be 0 if the Hello is Unicast. I'm not sure > that's reasonable, because if you only ever send Unicast and send it > with an Interval of 0, I don't know when to expire you from my > neighbor table. What's the use case for "occasionally" sending a unicast hello, and can it not be covered by a high interval? -Toke From nobody Fri Jun 16 01:46:16 2017 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 73C5C1316DB for ; Fri, 16 Jun 2017 01:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 p0k77NHPDnfj for ; Fri, 16 Jun 2017 01:46:12 -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 021751316D8 for ; Fri, 16 Jun 2017 01:46:11 -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/56228) with ESMTP id v5G8kAoX023838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Jun 2017 10:46:10 +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/56228) with ESMTP id v5G8k9AJ027317; Fri, 16 Jun 2017 10:46:10 +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 EB49DEB207; Fri, 16 Jun 2017 10:46:09 +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 djpWvt7DcdMD; Fri, 16 Jun 2017 10:46:08 +0200 (CEST) Received: from mac-matthieu.lan (AAubervilliers-652-1-287-44.w82-121.abo.wanadoo.fr [82.121.84.44]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C97A6EB201; Fri, 16 Jun 2017 10:46:08 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Matthieu Boutier In-Reply-To: <8760fxz2da.fsf@alrua-x1> Date: Fri, 16 Jun 2017 10:46:08 +0200 Cc: Babel at IETF , babel-users Content-Transfer-Encoding: 7bit Message-Id: References: <149753600138.12968.17430801165728958448.idtracker@ietfa.amsl.com> <7679DA79-5B56-4A19-95C3-8DE0CB2C8C12@irif.fr> <8760fxz2da.fsf@alrua-x1> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3124) 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, 16 Jun 2017 10:46:10 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 16 Jun 2017 10:46:10 +0200 (CEST) X-Miltered: at korolev with ID 59439AD2.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 59439AD1.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59439AD2.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 59439AD1.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 : 59439AD2.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 59439AD1.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: Re: [babel] draft-boutier-babel-source-specific-02 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jun 2017 08:46:14 -0000 > Does this mean whatever we decide for wildcard requests applies to > wildcard updates as well? That seems logical, but that's not what I propose. When a node requests a full dump, it requests only the routes it understand, not really a full dump. Sending a full dump may include unsolicited updates. When a node retracts all its routes, the receiver, which has only considered the routes it understand, will only retracts these routes. Of course, like wildcard requests, we can say that to be really conservative, a wildcard retraction only retracts the routes defined in 6126bis. I see no use case for that. To conclude, whatever we decide for wildcard requests, I suggest we deprecate any-specific wildcard retractions. Matthieu From nobody Fri Jun 16 15:28:16 2017 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 BC1B51279EB for ; Fri, 16 Jun 2017 15:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 3w8Qn9VArR9u for ; Fri, 16 Jun 2017 15:28:14 -0700 (PDT) Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (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 46C40127B31 for ; Fri, 16 Jun 2017 15:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497652093; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9ybd9npudC24Y/o7tY33k08UCq1BoWtfYF6TjRnVM2I=; b=jyt7bSI00MlGe0AqDhFxuO3rJQIerDl/AMq8J2jpFZVpKElxBC65CPbgnXolB9J/ dLg8WoqGvbfG4P8AjQDbz6ZGBSrptncUHUjCYsYlSu9tywjzfERcVB0zo3d2B1Y2 IlhNhZvW1ezDFhYAUOI1nB9/1vBsRJIq398C8Yn+63/WLQr18mF3y70yz9Awb3TU FMde5LikbbsyBI9TDLWU+IWNX4L3wnplI0SmQdUdI+Te6oTdlVvZULzNsz9yO/i+ 4JIM7OPpoXVKXUNXjU1wGFouHj4rqB8/2pE2qmKZgu73Dd6RpzISy7ZSMN930mWG fmZ64SHuHmN/CbMe+SOp5A==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id 84.F1.02110.D7B54495; Fri, 16 Jun 2017 15:28:13 -0700 (PDT) X-AuditID: 11ab0219-4546b9a00000083e-41-59445b7d7be9 Received: from koseret (koseret.apple.com [17.151.62.39]) by relay7.apple.com (Apple SCV relay) with SMTP id 94.0A.18088.B7B54495; Fri, 16 Jun 2017 15:28:12 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_651YIbXwWOLE6+3D4+GpHw)" Received: from da0602a-dhcp103.apple.com (da0602a-dhcp103.apple.com [17.226.23.103]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORN00B4RVQYQK20@koseret.apple.com>; Fri, 16 Jun 2017 15:28:10 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <43C01567-B680-41AA-9B7D-6EAF3BEF69D1@apple.com> Date: Fri, 16 Jun 2017 15:28:10 -0700 In-reply-to: Cc: Babel at IETF , babel-chairs@ietf.org To: Donald Eastlake References: X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUi2FCYqlsb7RJpcGWissXp3lssFlsWdbNY HNyu6cDssXPWXXaPJUt+MgUwRXHZpKTmZJalFunbJXBl9Jz+y1owX6ri+g7HBsYF4l2MnBwS AiYS159tZuxi5OIQEljLJDFnwxPmLkYOsMTjhSUgNUICqxglDnWng9i8AoISPybfYwGxmQXC JNa83MMKUbOYSeL0E7B6YQFpia4Ld1lBxrAJaEkcWGMEYvIK2EjsmZEPUeEm8af9BNgUFgFV iUuTNzGC2JwCwRK7389hhZhuKXFw+RIwW0RATeL18gUsEJsCJB6dO8MOcb2sxK3Zl5hBrpcQ OMImcez+P/YJjEKzkFw6C8mlELaWxPdHrUBxDiBbXuLgeVmIsKbEs3uf2CFsbYkn7y6wLmBk W8UonJuYmaObmWdkqpdYUJCTqpecn7uJERQLq5kkdzB+fW14iFGAg1GJh3fFDedIIdbEsuLK 3EOM0hwsSuK8pyxcIoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwCq2aVBAiIbVR7Vvo2sj2 7XfzpM/oafk9n92WlZ3Bc2DbuxmzvnR/DDx9LVfvr/SV+wXhzuqSxvkS2h0OMoW/PRiN93T8 eLBWKm1bobwZ40aGk1aT/vusWsO0+9sEq7Ml2/Lu9tu6MS1ftYhvK3tQ7PJjP19KfjUNnaIr +zluy4I6zQiNThtlJZbijERDLeai4kQAAM9TUGYCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUiON1OXbcm2iXS4OwjRovTvbdYLLYs6max OLhd04HZY+esu+weS5b8ZApgiuKySUnNySxLLdK3S+DK6Dn9l7VgvlTF9R2ODYwLxLsYOTgk BEwkHi8s6WLk5BASWMUocag7HcTmFRCU+DH5HguIzSwQJrHm5R5WiJrFTBKnn4DVCwtIS3Rd uMsKMoZNQEviwBojEJNXwEZiz4x8iAo3iT/tJ8CmsAioSlyavIkRxOYUCJbY/X4OK8R0S4mD y5eA2SICahKvly9ggdgUIPHo3Bl2EFtCQFbi1uxLzBMY+WchOW4WkuMgbC2J749ageIcQLa8 xMHzshBhTYln9z6xQ9jaEk/eXWBdwMi2ilGgKDUnsdJcL7GgICdVLzk/dxMjKHAbClN3MDYu tzrEKMDBqMTDy2zhGCnEmlhWXJl7iFGCg1lJhJdtI1CINyWxsiq1KD++qDQntfgQ40RGoCcn MkuJJucD4yqvJN7QxMTAxNjYzNjY3MSclsJK4rwlAU6RQgLpiSWp2ampBalFMEcxcXBKNTBO eLiJ4YfMXPfNOrVHQ0Lau7avfukUUXL+S4Dz77Q3PVb7g45N5lhXrRJVuPaV270znXskKjsu 7mKVfF06V9591b8XKyfmzD4TyW3ZW3ROVvyMEENpz36+8OMcPQsbbsVe/9P7IMjj7/MrIZnB H46oWbn7T7PJ99/qVumwWvn0ZHH+lGrlj6uUWIozEg21mIuKEwGIbYXnzwIAAA== Archived-At: Subject: Re: [babel] Call for Babel presentations at IETF-99 in Prague X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jun 2017 22:28:16 -0000 --Boundary_(ID_651YIbXwWOLE6+3D4+GpHw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Donald, I'd like to present a proposal for Unicast Hellos, I think a 10 minute slot would make sense if possible. Thanks, David Schinazi > On Jun 16, 2017, at 00:02, Donald Eastlake wrote: > > Hi, > > We expect to have a one hour Babel session at the IETF Prague meeting in July > (see https://ietf.org/meeting/99/index.html ). Please send email to babel-chairs@ietf.org or to this mailing list if you would like to present. > > Thanks, > Donald [co-chair] > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --Boundary_(ID_651YIbXwWOLE6+3D4+GpHw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi Donald,

I'd like to present a proposal for Unicast Hellos,
I think a 10 minute slot would make sense if = possible.

Thanks,
David Schinazi


On = Jun 16, 2017, at 00:02, Donald Eastlake <d3e3e3@gmail.com> = wrote:

Hi,

We expect to have a one hour Babel session at the IETF Prague = meeting in July
(see https://ietf.org/meeting/99/index.html). Please send = email to babel-chairs@ietf.org or to this mailing list if you = would like to present.

Thanks,
Donald [co-chair]
=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)
 155 Beaver Street, = Milford, MA 01757 USA
 d3e3e3@gmail.com
_______________________________________________
babel = mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel

= --Boundary_(ID_651YIbXwWOLE6+3D4+GpHw)-- From nobody Fri Jun 16 15:53:04 2017 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 3087512946A; Fri, 16 Jun 2017 15:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 y3lYsxkW7K0A; Fri, 16 Jun 2017 15:53:01 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 36BFC1200C5; Fri, 16 Jun 2017 15:53:01 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v5GMjLtb036029; Fri, 16 Jun 2017 18:52:57 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2b4qse8v0s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Jun 2017 18:52:57 -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 v5GMquRA002975; Fri, 16 Jun 2017 18:52:56 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v5GMqpc0002868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Jun 2017 18:52:53 -0400 Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi132.aldc.att.com (RSA Interceptor); Fri, 16 Jun 2017 22:52:46 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.134]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0319.002; Fri, 16 Jun 2017 18:52:46 -0400 From: "STARK, BARBARA H" To: David Schinazi , Donald Eastlake CC: "babel-chairs@ietf.org" , Babel at IETF Thread-Topic: [babel] Call for Babel presentations at IETF-99 in Prague Thread-Index: AQHS5m6nTc8Z4kn0u0uVRIHFPCovo6IoVdsA///DmcA= Date: Fri, 16 Jun 2017 22:52:46 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB996D0@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <43C01567-B680-41AA-9B7D-6EAF3BEF69D1@apple.com> In-Reply-To: <43C01567-B680-41AA-9B7D-6EAF3BEF69D1@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.200.170] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114DB996D0GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-16_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706160388 Archived-At: Subject: Re: [babel] Call for Babel presentations at IETF-99 in Prague X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jun 2017 22:53:03 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114DB996D0GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And I'll be providing a WG -00 draft for the info model in a couple of days= and need maybe 5 minutes. Barbara From: babel [mailto:babel-bounces@ietf.org] On Behalf Of David Schinazi Sent: Friday, June 16, 2017 6:28 PM To: Donald Eastlake Cc: babel-chairs@ietf.org; Babel at IETF Subject: Re: [babel] Call for Babel presentations at IETF-99 in Prague Hi Donald, I'd like to present a proposal for Unicast Hellos, I think a 10 minute slot would make sense if possible. Thanks, David Schinazi On Jun 16, 2017, at 00:02, Donald Eastlake > wrote: Hi, We expect to have a one hour Babel session at the IETF Prague meeting in Ju= ly (see https://ietf.org/meeting/99/index.html). P= lease send email to babel-chairs@ietf.org or = to this mailing list if you would like to present. Thanks, Donald [co-chair] =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) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com _______________________________________________ babel mailing list babel@ietf.org https://www.ietf.org/mailman/listinfo/babel --_000_2D09D61DDFA73D4C884805CC7865E6114DB996D0GAALPA1MSGUSRBF_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And I’ll be providing a WG -00 = draft for the info model in a couple of days and need maybe 5 minutes.=

Barbara

 

From: babel [mailto:babel-bounces@ie= tf.org] On Behalf Of David Schinazi
Sent: Friday, June 16, 2017 6:28 PM
To: Donald Eastlake <d3e3e3@gmail.com>
Cc: babel-chairs@ietf.org; Babel at IETF <babel@ietf.org>
Subject: Re: [babel] Call for Babel presentations at IETF-99 in Prag= ue

 

Hi Donald,

 

I'd like to present a proposal for Unicast Hellos,

I think a 10 minute slot would make sense if possibl= e.

 

Thanks,

David Schinazi

 

 

On Jun 16, 2017, at 00:02, Donald Eastlake <d3e3e3@gmail.com> wrote:

 

Hi,

 

We expect to have a one hour Babel session at the IE= TF Prague meeting in July

(see https://ietf.org/meeting/99/index.html). Please send email to babel-chairs= @ietf.org or to this mailing list if you would like to present.


Thanks,
Donald [co-chair]
=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)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.co= m

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

 

--_000_2D09D61DDFA73D4C884805CC7865E6114DB996D0GAALPA1MSGUSRBF_-- From nobody Fri Jun 16 17:05:26 2017 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 B700D128D8B for ; Fri, 16 Jun 2017 17:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 0E5ReAnLRXlf for ; Fri, 16 Jun 2017 17:05:23 -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 C54A5128B51 for ; Fri, 16 Jun 2017 17:05:22 -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/56228) with ESMTP id v5H05JGM008470; Sat, 17 Jun 2017 02:05: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 217B8EB209; Sat, 17 Jun 2017 02:05: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 zw6C_6kE9zli; Sat, 17 Jun 2017 02:05:18 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id EB49CEB206; Sat, 17 Jun 2017 02:05:17 +0200 (CEST) Date: Sat, 17 Jun 2017 02:05:17 +0200 Message-ID: <87vanvwkaq.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , Babel at IETF In-Reply-To: <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> 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]); Sat, 17 Jun 2017 02:05:19 +0200 (CEST) X-Miltered: at korolev with ID 5944723F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5944723F.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 : 5944723F.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] Cutoff date for rfc6126bis is 3 July X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 00:05:25 -0000 >> What I meant is that all implementations MUST be able to parse both kinds >> of Hellos, but an implementation may choose to only ever send Multicast >> Hellos. It may also choose to only send Unicast Hellos, but in that case >> you need some other discovery mechanism. > Is there benefit in requiring all implementations to parse Multicast? > If I only send Unicast and you only parse Multicast we're not going to > interoperate anyway, so might as well remove the requirement that > everyone needs to parse Multicast. Require that all implementations parse *both*, but an implementation is not required to send either. So whether you send multicast or unicast doesn't matter, I still associate with you. The implementation cost is fairly moderate (one extra set of history per neighbour, 16 bits in my implementation), simple to specify, and ensures interoperability. Any counter-proposals? >> Now what about an implementation that sends mostly Multicast Hellos, but >> occasionally sends a Unicast one? Such an implementation needs to express >> the notion that it makes no promise to ever send another Unicast hello. > I think the only way to allow occasional Unicast Hellos would be to > allow the Interval to be 0 if the Hello is Unicast. I'm not sure that's > reasonable, because if you only ever send Unicast and send it with > an Interval of 0, I don't know when to expire you from my neighbor table. Well, I was thinking that an implementation MUST send either periodic Multicast Hellos or periodic Unicast Hellos, but it MAY send occasional Hellos of the other kind. Occasional Hellos do not participate in link-quality estimation. The main application is the RTT extension, which requires a Hello to be sent in the same packet as an IHU. If an implementation sends Multicast Hellos and Unicast IHU, it will want to send an "occasional" Unicast Hello together with each IHU. "Occasional" Hellos MAY be silently ignored, but any sub-TLVs must still be parsed. -- Juliusz From nobody Fri Jun 16 17:15:36 2017 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 45920128DE5 for ; Fri, 16 Jun 2017 17:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ckT1flKNrM5w for ; Fri, 16 Jun 2017 17:15:32 -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 6C3F3124C27 for ; Fri, 16 Jun 2017 17:15:32 -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/56228) with ESMTP id v5H0FSfH010156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Jun 2017 02:15:28 +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/56228) with ESMTP id v5H0FSRg022409; Sat, 17 Jun 2017 02:15:28 +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 3CFF9EB209; Sat, 17 Jun 2017 02:15:28 +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 fM6CUME572z6; Sat, 17 Jun 2017 02:15:27 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0BB5CEB207; Sat, 17 Jun 2017 02:15:27 +0200 (CEST) Date: Sat, 17 Jun 2017 02:15:26 +0200 Message-ID: <87tw3fwjtt.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: David Schinazi , Babel at IETF In-Reply-To: <87y3ss5nlg.fsf@alrua-x1> References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> <87y3ss5nlg.fsf@alrua-x1> 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]); Sat, 17 Jun 2017 02:15:28 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 17 Jun 2017 02:15:28 +0200 (CEST) X-Miltered: at korolev with ID 594474A0.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 594474A0.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 594474A0.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 594474A0.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 : 594474A0.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 594474A0.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: [babel] Unscheduled Hellos [was: Cutoff date for rfc6126bis is 3 July] X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 00:15:34 -0000 > What's the use case for "occasionally" sending a unicast hello, and can > it not be covered by a high interval? All of the TLVs defined in Babel are idempotent: sending multiple identical Updates, or multiple identical Requests, is equivalent to sending a single Update or Request. The only exception are Hellos, which are not idempotent, since they change the state used for link-quality estimation. This is the root cause of all of our troubles: we cannot send ordinary ("Multicast") Hellos over unicast, or else we desynchronise the link-quality estimation state. The other trouble this causes is with sub-TLVs: if some data is defined to be carried in a sub-TLV of a Hello, then it cannot be sent at arbitrary times, since that would change the link-quality estimation. We define an Unscheduled Hello as one that carries an Interval of 0. Such a Hello MAY be ignored for link-quality estimation purposed, and MAY be outright ignored upon reception; however, any sub-TLVs it carries are still parsed, and aced upon. The current application is the RTT metric, which requires a Hello to be sent together with each IHU (in order to carry a timestamp). In most implementations, IHUs are naturally sent together with Hellos, so nothing is required; however, if an implementation schedules IHUs independently of Hellos, then something needs to be done, either change the scheduling of Hellos (which might or might not be complicated), or send an Unscheduled Hello in order to carry the timestamp. Note that the above says MAY be silently ignored. If we end up finding a really smart link-quality estimation algorithm that needs to use unscheduled Hellos, this can be implemented in the future without requiring a specification change. -- Juliusz From nobody Sat Jun 17 18:44:07 2017 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 C686C124C27; Sat, 17 Jun 2017 18:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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_LOW=-0.7, 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 fVJwB1JYNvsX; Sat, 17 Jun 2017 18:44:03 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 AF74A1242F5; Sat, 17 Jun 2017 18:44:03 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id g184so7521684ita.0; Sat, 17 Jun 2017 18:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zbesN54epQvK5kkO8ciLRUnh+8roenvO7eH9+sPudts=; b=cuILziJeARrni/7Qhzk4tW4lgI+M7Y9UpkRodx4DMLYIM/YHfBYEsXzxmQXWPNqmQY xc2XqMBI+XEHvTyNheaqUSJm/4iC8XZ7J0AR9LYGqVWQP0t9G3oitGvcaVviFlYF9trG qgi+wkC8cgiZMSRBsPJJLbVXxOlj0ADeYuc0Za4bvFfm78pkJdCbPWPMAllPR3Z8Z/Oh KSdtcL8D7h3+gFgwxtfHCG1ooZjoxiiI2U+qJ0BNU7a84QC6osDVwhDaWZAOw4rqwRSv dMCTC8tCHc0J+BRnquWbJg1cyAPjj9oAxa+oW0S9PGCKx1cAEyWj9IgcsOz/rnjn9YSk H8gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zbesN54epQvK5kkO8ciLRUnh+8roenvO7eH9+sPudts=; b=Jze1X2901FcPLKoU2zT3mHX9zNU8kDJEatVHonjZlR08eIhyqx8r8WCGVxmWnMVuKK 2xCzKPxqz7L/zdTCWjjS8OOtBNnuPO21G73dLRF3G7vQzxz4lhalHGBIaeFdQC1gAG24 Wm5avNXc01zIl4lW/XGQVkqguyMaSzfpcc8FJxCzIaTgVnyyz/sNBocvYFhqVmUVz9Og Fb13zF/lUEb4lIZi9JQYHBGTEriJvuGLmU1w0JTpP6Ko3tbG+CeAHsmlFwrV1iZ1WQQE iFBAVeKNoAxedUZN/S/Wc5pIfPvsuQNBOChZQXlZi7RETUMMpfKW1glYt8XcMhLo9sOu /Kmg== X-Gm-Message-State: AKS2vOxQlzGsIeQhMt84TD8jZof0urM9eiq0ZEDczjb0irlP7DF/ZKeT 2VckwvFGJa2XH6oDcpvcF59+3WlTdw== X-Received: by 10.36.107.68 with SMTP id v65mr11149699itc.79.1497750243117; Sat, 17 Jun 2017 18:44:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.131.152 with HTTP; Sat, 17 Jun 2017 18:43:47 -0700 (PDT) In-Reply-To: <43C01567-B680-41AA-9B7D-6EAF3BEF69D1@apple.com> References: <43C01567-B680-41AA-9B7D-6EAF3BEF69D1@apple.com> From: Donald Eastlake Date: Sat, 17 Jun 2017 21:43:47 -0400 Message-ID: To: David Schinazi Cc: Babel at IETF , babel-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a114ab4243415f7055232272c" Archived-At: Subject: Re: [babel] Call for Babel presentations at IETF-99 in Prague X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 18 Jun 2017 01:44:06 -0000 --001a114ab4243415f7055232272c Content-Type: text/plain; charset="UTF-8" OK. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Fri, Jun 16, 2017 at 6:28 PM, David Schinazi wrote: > Hi Donald, > > I'd like to present a proposal for Unicast Hellos, > I think a 10 minute slot would make sense if possible. > > Thanks, > David Schinazi > > > On Jun 16, 2017, at 00:02, Donald Eastlake wrote: > > Hi, > > We expect to have a one hour Babel session at the IETF Prague meeting in > July > (see https://ietf.org/meeting/99/index.html). Please send email to > babel-chairs@ietf.org or to this mailing list if you would like to > present. > > Thanks, > Donald [co-chair] > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 <(508)%20333-2270> (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > > > --001a114ab4243415f7055232272c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK.

Thanks,
Don= ald
=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-3= 33-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0<= a href=3D"mailto:d3e3e3@gmail.com" target=3D"_blank">d3e3e3@gmail.com

On Fri, Jun 16, 2017 at 6:28 PM, David Schin= azi <dschinazi@apple.com> wrote:
Hi Donald,

= I'd like to present a proposal for Unicast Hellos,
I think a = 10 minute slot would make sense if possible.

Thank= s,
David Schinazi


On Jun 16, 2017, at 00:02, Donald = Eastlake <d3e3e3@g= mail.com> wrote:

Hi,=

We expect to have a one hour Babel session at the IETF = Prague meeting in July
(see=C2=A0https://ietf.org/meeting/99/index= .html). Please send email to babel-chairs@ietf.org or to this mailing list if you w= ould like to present.

Thanks,
Donald [co-chair]
=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 (c= ell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com
_______________________________________________
babel mailing list<= br>babel@ietf.orghttps://www.ietf.org/mailman/listinfo/babel


--001a114ab4243415f7055232272c-- From nobody Sat Jun 17 18:45:25 2017 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 C0A31127076; Sat, 17 Jun 2017 18:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.46 X-Spam-Level: X-Spam-Status: No, score=-0.46 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, 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 JvkhLSOys74I; Sat, 17 Jun 2017 18:45:21 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 790AA1242F5; Sat, 17 Jun 2017 18:45:21 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id m62so51280006itc.0; Sat, 17 Jun 2017 18:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5+MH91HPIEsh+31MzJSVY5p1Z8tNGlzKrtxHGEAsOVY=; b=h8r10w1nMSJXUSfNxDnWFutTpFf7psh5rMeCLj8rUyTFKr1XZJEpxrpa3TT8UIfh+h +awW+/umAoKZwavEtOo7vTieqdbiX2tZfmzBmmveSZGN67TeTF+2rtLrdeMvZFjMYOph zJU3z7KprMh7GVKiUHP5n39lvuoIFGa5zo+hXWlCipi9s1OHploiwjQwxw0m2RYnRY5/ Vm9oBbU0hTSFhHWGcVnPkO0r4NF2763VGb8bgpT0m9usTYm7bH1LSKQ6hr9XaT5Kbkuz 1JwjZreqyb5xbA6vdx3fjmULqDQa4+KAw6bvde4Ptao8T7a22PxgqGE+mq7Z15rionM8 NMCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5+MH91HPIEsh+31MzJSVY5p1Z8tNGlzKrtxHGEAsOVY=; b=SjtITbs617yRDZKEFda1+g0LwSCy3dBiC1jJGGlLz7A4dbU/4tI6gGa5jrTq0X2rpW C5Sqlxrwj6K5TRtBGZkpspUd0AHq2aS1F5C2izfu5OFFD0Z8eOoIXRtWAppNnI2EH1PG EMcibE11U1819kySs+lV9rN1AeWWYgDI/E5oXxhvAi1UfBKWlRDWlMEpo+m9k76uT+PJ HecwDoK97yYVsPMMCnpMpGNEdSruIwK20P2vr3WIgm3FOuJmRBlF1OTO6XL9y2urBHir x1ADT3dn7lhDXocGwpTqZyFUGadLpRsP++5NjbTjg/2if4Oiwc6bdoTL+t2mJAEhg10R QKgw== X-Gm-Message-State: AKS2vOyptu1+T9aGIqZZPdXyHDrBHKukP4wzTh1KIWkB53UhBg95g+7U 5XoxI0gIBGH22QQ6xeAcPASMGCUsCXO3 X-Received: by 10.36.53.70 with SMTP id k67mr16919808ita.79.1497750320896; Sat, 17 Jun 2017 18:45:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.131.152 with HTTP; Sat, 17 Jun 2017 18:45:05 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB996D0@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <43C01567-B680-41AA-9B7D-6EAF3BEF69D1@apple.com> <2D09D61DDFA73D4C884805CC7865E6114DB996D0@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Donald Eastlake Date: Sat, 17 Jun 2017 21:45:05 -0400 Message-ID: To: "STARK, BARBARA H" Cc: David Schinazi , "babel-chairs@ietf.org" , Babel at IETF Content-Type: multipart/alternative; boundary="001a114abeecd729930552322bcd" Archived-At: Subject: Re: [babel] Call for Babel presentations at IETF-99 in Prague X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 18 Jun 2017 01:45:24 -0000 --001a114abeecd729930552322bcd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK. 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) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Fri, Jun 16, 2017 at 6:52 PM, STARK, BARBARA H wrote: > And I=E2=80=99ll be providing a WG -00 draft for the info model in a coup= le of > days and need maybe 5 minutes. > > Barbara > > > > *From:* babel [mailto:babel-bounces@ietf.org] *On Behalf Of *David > Schinazi > *Sent:* Friday, June 16, 2017 6:28 PM > *To:* Donald Eastlake > *Cc:* babel-chairs@ietf.org; Babel at IETF > *Subject:* Re: [babel] Call for Babel presentations at IETF-99 in Prague > > > > Hi Donald, > > > > I'd like to present a proposal for Unicast Hellos, > > I think a 10 minute slot would make sense if possible. > > > > Thanks, > > David Schinazi > > > > > > On Jun 16, 2017, at 00:02, Donald Eastlake wrote: > > > > Hi, > > > > We expect to have a one hour Babel session at the IETF Prague meeting in > July > > (see https://ietf.org/meeting/99/index.html > ). > Please send email to babel-chairs@ietf.org or to this mailing list if you > would like to present. > > > Thanks, > Donald [co-chair] > =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 <(508)%20333-2270> (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > > > --001a114abeecd729930552322bcd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK.

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=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

On Fri, Jun 16, 2017 at 6:52 PM, STARK, BARB= ARA H <bs7652@att.com> wrote:

And I=E2=80=99ll be providing a WG -0= 0 draft for the info model in a couple of days and need maybe 5 minutes.=

Barbara

=C2=A0

From: babel [mailto:babel-bounces@ietf.org= ] On Behalf Of David Schinazi
Sent: Friday, June 16, 2017 6:28 PM
To: Donald Eastlake <d3e3e3@gmail.com>
Cc: babel= -chairs@ietf.org; Babel at IETF <babel@ietf.org>
Subject: Re: [babel] Call for Babel presentations at IETF-99 in Prag= ue

=C2=A0

Hi Donald,

=C2=A0

I'd like to present a proposal for Unicast Hello= s,

I think a 10 minute slot would make sense if possibl= e.

=C2=A0

Thanks,

David Schinazi

=C2=A0

=C2=A0

On Jun 16, 2017, at 00:02, Donald Eastlake <d3e3e3@gmail.com> w= rote:

=C2=A0

Hi,

=C2=A0

We expect to have a one hour Babel session at the IE= TF Prague meeting in July

(see=C2=A0https://ietf.org/meeting/99/ind= ex.html). Please send email to babel-chairs@ietf.org or to this mailing list if you would like t= o present.


Thanks,
Donald [co-chair]
=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=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.co= m

_______________________________________________=
babel mailing list
babel@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/babel

=C2=A0


--001a114abeecd729930552322bcd-- From nobody Sun Jun 18 07:47:44 2017 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 9147C128BB7 for ; Sun, 18 Jun 2017 07:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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_LOW=-0.7, 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 awqlapXSq5Ca for ; Sun, 18 Jun 2017 07:47:41 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 C2EEF128BB6 for ; Sun, 18 Jun 2017 07:47:41 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id y77so51394776ioe.3 for ; Sun, 18 Jun 2017 07:47:41 -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; bh=uF8y/hEGYjdJv7pVpGpFxJvj6aalbnNAU6fyruAdChg=; b=XwMrGlTM7Yg4Ksxhn0d3rX9DS69d/sKG2CaAvurYTjHpYKSyLRPI4KgJ5fuAO0F2sl b85fWRUOQfbaKws8voj86a2SZ0OKMudJCeJUZbcCaH9mAPqtfzKaM8JHky+qaxJNSDuj ooLiaY3CkW7rPbOHUaQJxX5L65X3k9q/KvPLzVjv8dqcsgMZVs+fx59GXAH6DiHrO43R tkf7Q1oYCADDg/lFR1x0cKHwCcueEkVR0LIEwUy1BHeMFQtIkvHnAHqGbs5LJvPO64Wo ldPG8SwLPIwrwv4bVnuOWuTLKO4ssz92q6jaOV+8QT9Q+cybWnzmN505AE71dEr2GykN fA7Q== 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; bh=uF8y/hEGYjdJv7pVpGpFxJvj6aalbnNAU6fyruAdChg=; b=TFTMv3BgtXUsGTBTJyOhOMbhufOg9T0/x6sX8tqCezkkzt7SF7WqHDdzhEyjrV0AvF kG/Br7f3KomCCGpx6PdwY1UBtrXAtE2Pt45y1cORnnZM8R8IBar59nkseN06t4YKPTL/ oahsi0dfO9xMoOC94A2RE9l2rwwlEs2q71Y/ZMAUmRgSFB+jPG984oC00057pXEa+a1i VwPkjNoFf7uAU3sRwy8PK73p4YkWxzv3T5YYtpDiHDdmIjeknxC0sXdTAg2Pw5n00z1V BNdi869NkuToF/Hn47PqUmn4V6D8T6sLSf5ktLHBrJ8z4EWDC2uJjEhlpw87G/e5AyXG VJ2g== X-Gm-Message-State: AKS2vOx39wofJGeVOnQuSVsKtlmD/GzX0D0BcX5l7ZleARnWA9DKzQXj IKeeB9F5D4RK6khlVrUekVV41Pu7hqSZhr4= X-Received: by 10.107.11.215 with SMTP id 84mr18901453iol.231.1497797260931; Sun, 18 Jun 2017 07:47:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.131.152 with HTTP; Sun, 18 Jun 2017 07:47:25 -0700 (PDT) From: Donald Eastlake Date: Sun, 18 Jun 2017 10:47:25 -0400 Message-ID: To: Babel at IETF Content-Type: multipart/alternative; boundary="001a113f8a74af1e9f05523d1988" Archived-At: Subject: [babel] Preliminary Babel agenda for Prague X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 18 Jun 2017 14:47:43 -0000 --001a113f8a74af1e9f05523d1988 Content-Type: text/plain; charset="UTF-8" Hi, A preliminary agenda, subject to change, for the Babel WG meeting at the upcoming July IETF Prague meeting has been uploaded. See the meeting materials page https://datatracker.ietf.org/meeting/99/materials Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com --001a113f8a74af1e9f05523d1988 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

A preliminary agenda, subject to ch= ange, for the Babel WG meeting at the upcoming July IETF Prague meeting has= been uploaded. See the meeting materials page

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. East= lake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford,= MA 01757 USA
=C2=A0d3e3e3@gmail.com
--001a113f8a74af1e9f05523d1988-- From nobody Mon Jun 19 15:59:46 2017 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 2CF4A129557; Mon, 19 Jun 2017 15:59: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, RCVD_IN_DNSWL_NONE=-0.0001, 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 gnh8x4S0KHVL; Mon, 19 Jun 2017 15:59:41 -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 86A421293DF; Mon, 19 Jun 2017 15:59:41 -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/56228) with ESMTP id v5JMxdSj014843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Jun 2017 00:59:39 +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/56228) with ESMTP id v5JMxcUI006495; Tue, 20 Jun 2017 00:59: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 D5B7FEB2CC; Tue, 20 Jun 2017 00:59: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 eWoSLrrmczNw; Tue, 20 Jun 2017 00:59:37 +0200 (CEST) Received: from mac-matthieu.lan (AAubervilliers-652-1-220-154.w83-112.abo.wanadoo.fr [83.112.107.154]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7CCA9EB2F0; Tue, 20 Jun 2017 00:59:37 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Matthieu Boutier In-Reply-To: Date: Tue, 20 Jun 2017 00:59:37 +0200 Cc: "babel-chairs@ietf.org" , Babel at IETF Content-Transfer-Encoding: quoted-printable Message-Id: <7578E84A-85F0-423D-83FF-40C4FBF8D9A4@irif.fr> References: <43C01567-B680-41AA-9B7D-6EAF3BEF69D1@apple.com> <2D09D61DDFA73D4C884805CC7865E6114DB996D0@GAALPA1MSGUSRBF.ITServices.sbc.com> To: Donald Eastlake X-Mailer: Apple Mail (2.3124) 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, 20 Jun 2017 00:59:39 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 20 Jun 2017 00:59:39 +0200 (CEST) X-Miltered: at korolev with ID 5948575B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5948575A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5948575B.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5948575A.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 : 5948575B.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5948575A.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] Call for Babel presentations at IETF-99 in Prague X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jun 2017 22:59:44 -0000 Hi, I would like to present my source-specific extension with mandatory bit = [1]. I think a 10 minute slot would be great. [1] = https://datatracker.ietf.org/doc/draft-boutier-babel-source-specific/ Thanks, Matthieu= From nobody Mon Jun 19 17:08:05 2017 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 3786A12960D for ; Mon, 19 Jun 2017 17:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 W9p3gnQrthd8 for ; Mon, 19 Jun 2017 17:08:02 -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 AE1721200E5 for ; Mon, 19 Jun 2017 17:08:00 -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/56228) with ESMTP id v5K07wW9024264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Jun 2017 02:07:58 +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/56228) with ESMTP id v5K07wr4014127; Tue, 20 Jun 2017 02:07:58 +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 8B4DEEB2CC; Tue, 20 Jun 2017 02:07:58 +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 RVHN0UAmVfhY; Tue, 20 Jun 2017 02:07:57 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 24705EB274; Tue, 20 Jun 2017 02:07:57 +0200 (CEST) Date: Tue, 20 Jun 2017 02:07:56 +0200 Message-ID: <87shivmsgz.wl-jch@irif.fr> From: Juliusz Chroboczek To: Matthieu Boutier Cc: babel-users@lists.alioth.debian.org, babel@ietf.org In-Reply-To: <87y3tdhy84.wl-jch@irif.fr> References: <87h90a9nlz.wl-jch@irif.fr> <70ED4D66-B6BF-4D29-B24F-32A2C6779789@irif.fr> <87y3tdhy84.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, 20 Jun 2017 02:07:59 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 20 Jun 2017 02:07:58 +0200 (CEST) X-Miltered: at korolev with ID 5948675E.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5948675E.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5948675E.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5948675E.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 : 5948675E.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5948675E.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] [Babel-users] source sub-tlv X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 00:08:04 -0000 >> - only keep (legacy) wildcard requests, and reply with a full dump. > That's reasonable, although slightly confusing. (Call that (1).) > 3. Send a non-specific wildcard request for non-specific routes, > a source-specific wildcard request for source-specific routes, etc. > I support (3). Last time I spoke to him, Toke supported (4). I am > opposed to (2). I can live with (1). After looking at the relevant code in babeld, I find that (1) is much simpler to implement. Matthieu's latest draft (-2) contains a good summary of the discussion. -- Juliusz From nobody Mon Jun 19 22:40:01 2017 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 1EA28127011 for ; Mon, 19 Jun 2017 22:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 QWs7vL9up7-F for ; Mon, 19 Jun 2017 22:39:57 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 5DC421242F7 for ; Mon, 19 Jun 2017 22:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497937197; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9FvdJQUNfnhrcRin8bmhds4Blmg8VT4WdgNaNfePv7w=; b=UdmUeHt4LGY1bn8YfbNwAJT9MEj12MXcx+oeC9BjPp/15rkudBzTxSsHHX3xgJ76 o96Gaa0oy2Xtf2P+iGzc9MMxAGsvhDi0UjZnS5yENA3HMt8i/3s44jUpeupWGBVJ xpccGtjGPEg2vdVf8UnvaJzWhdgxxjw0GCOVa9igDI8BtReSiq1WzaTldaF0L7yj Lyur5AA6NxPJ4XXuhA0CvAEa+sUp5GO7318ZipPPsxZkd8sVMTEF5SkMFvQjyClY ltzJSC9gukqL//kZRcOTVAAOpXdwCse0z3H0sQrynu/L9OQOgv+XQmDiryFmpbcC OSxV9LZM8uN2qyP1GISHFw==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id B7.79.07949.C25B8495; Mon, 19 Jun 2017 22:39:57 -0700 (PDT) X-AuditID: 11973e16-0c7789a000001f0d-27-5948b52d2796 Received: from koseret (koseret.apple.com [17.151.62.39]) by relay4.apple.com (Apple SCV relay) with SMTP id 53.74.01343.C25B8495; Mon, 19 Jun 2017 22:39:56 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Pa/cr37PCRo28IOw9XHDzA)" Received: from [17.235.21.221] (unknown [17.235.21.221]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORT00J4QZQJHO40@koseret.apple.com>; Mon, 19 Jun 2017 22:39:56 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <5CD7F43D-2FC0-4466-AFDE-FD968D9CC158@apple.com> Date: Mon, 19 Jun 2017 22:39:54 -0700 In-reply-to: <87tw3fwjtt.wl-jch@irif.fr> Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Babel at IETF To: Juliusz Chroboczek References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> <87y3ss5nlg.fsf@alrua-x1> <87tw3fwjtt.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUi2FAYrqu71SPS4Mx8Tosti7pZLOa3LmOz 2Pp+BbsDs8eSJT+ZPBZvecvoseXQRbYA5igum5TUnMyy1CJ9uwSujMWnWQsuOFfM2TOfqYHx hGUXIyeHhICJxP7Xp1m6GLk4hARWM0n8OLqeDSaxds0PZojEKkaJeRu3MIIkeAUEJX5MvscC YjMLhElM/bcQqruVSeLF09lMIAlhAWmJrgt3WbsYOTjYBLQkDqwxgui1kXh/eT4bREmoRFPr GnYQm0VAVWL/zH2sIDangIZE3+FfzBDzEyX67v4Bi4sIqEgsn/aMHWLXdGaJq8/7mSEulZW4 NfsS2KUSAtfZJG5vOsE+gVFoFpJjZyE5FsLWkvj+qBXI5gCy5SUOnpeFCGtKPLv3iR3C1pZ4 8u4C6wJGtlWMQrmJmTm6mXnmeokFBTmpesn5uZsYQfEx3U5sB+PDVVaHGAU4GJV4eBe8do8U Yk0sK67MPcQozcGiJM6bU+MRKSSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoExYV+8rHKH/XrG ZzsNY164chyL8dnabn3f1FoyfdOXmynRU3vC9j2WPKqb69Gjtu5FyamooHW5qZ2Bp5R/aD6S E1Q/nPKw7+NW8UcqT60y1/tuUnKePHnXlUXTLpUdKf/NfevSaf9Jtjdd5/h651q1bVjEwa4Z pn97Yurib0H8aYpXWlvnhb5VYinOSDTUYi4qTgQAWPivGXACAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUiON1OXVdnq0ekwfWvphZbFnWzWMxvXcZm sfX9CnYHZo8lS34yeSze8pbRY8uhi2wBzFFcNimpOZllqUX6dglcGYtPsxZccK6Ys2c+UwPj CcsuRk4OCQETibVrfjB3MXJxCAmsYpSYt3ELI0iCV0BQ4sfkeywgNrNAmMTUfwtZIIpamSRe PJ3NBJIQFpCW6Lpwl7WLkYODTUBL4sAaI4heG4n3l+ezQZSESjS1rmEHsVkEVCX2z9zHCmJz CmhI9B3+xQwxP1Gi7+4fsLiIgIrE8mnP2CF2TWeWuPq8nxniUlmJW7MvMU9g5J+F5L5ZSO6D sLUkvj9qBbI5gGx5iYPnZSHCmhLP7n1ih7C1JZ68u8C6gJFtFaNAUWpOYqWJXmJBQU6qXnJ+ 7iZGUDg3FIbvYPy3zOoQowAHoxIPr8dL90gh1sSy4srcQ4wSHMxKIrxPl3tECvGmJFZWpRbl xxeV5qQWH2KcyAj05URmKdHkfGC05ZXEG5qYGJgYG5sZG5ubmNNSWEmcd84UoIsE0hNLUrNT UwtSi2COYuLglGpgjP3qIGPPsf5iVcpNZu3cyil8qy6qrV0yrcnH6zfbWreuyaHc38vC112O zrZ8Xvx7wpqGCe81ON52vS4PD8/5WaAeuKI2fWHWnODv2xhK3nNExd/TnX4psua+/5w+g/YG x87Fnm/E76yIWJjeweiwRPB5OEv9hLeJ1wLXT1hr6rCZQUeG688sJZbijERDLeai4kQAs41+ 1toCAAA= Archived-At: Subject: Re: [babel] Unscheduled Hellos [was: Cutoff date for rfc6126bis is 3 July] X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 05:40:00 -0000 --Boundary_(ID_Pa/cr37PCRo28IOw9XHDzA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT That's an elegant solution. It reduces constraints on implementations but still allows the current model to work. I do have one question however: what does the seqno represent on unscheduled Hellos (UH)? If an implementation MAY ignore UH for the purpose of link-quality estimation, then incrementing the seqno on UH will confuse it. For that reason I propose that, for UH, seqno MUST be set to 0 when sending and MUST be ignored on reception. Also, the interface outgoing periodic Hello seqno MUST NOT be incremented when sending UH. >From my understanding, this is compatible with the RTT extension since that doesn't use the seqno or interval. Thoughts / counter-proposals? Also minor: we've used the terms "occasional" and "unscheduled" to denote Hellos with an Interval of zero. We should pick one for standardization, I personally prefer "unscheduled". We should also pick a term for Hellos with non-zero Intervals, I personally prefer "periodic". I tried to incorporate it into my pull request: https://github.com/jech/babel-drafts/pull/3/files Let me know what you think. Thanks, David Schinazi > On Jun 16, 2017, at 17:15, Juliusz Chroboczek wrote: > >> What's the use case for "occasionally" sending a unicast hello, and can >> it not be covered by a high interval? > > All of the TLVs defined in Babel are idempotent: sending multiple > identical Updates, or multiple identical Requests, is equivalent to > sending a single Update or Request. > > The only exception are Hellos, which are not idempotent, since they change > the state used for link-quality estimation. This is the root cause of > all of our troubles: we cannot send ordinary ("Multicast") Hellos over > unicast, or else we desynchronise the link-quality estimation state. > > The other trouble this causes is with sub-TLVs: if some data is defined to > be carried in a sub-TLV of a Hello, then it cannot be sent at arbitrary > times, since that would change the link-quality estimation. > > We define an Unscheduled Hello as one that carries an Interval of 0. Such > a Hello MAY be ignored for link-quality estimation purposed, and MAY be > outright ignored upon reception; however, any sub-TLVs it carries are > still parsed, and aced upon. > > The current application is the RTT metric, which requires a Hello to be > sent together with each IHU (in order to carry a timestamp). In most > implementations, IHUs are naturally sent together with Hellos, so nothing > is required; however, if an implementation schedules IHUs independently of > Hellos, then something needs to be done, either change the scheduling of > Hellos (which might or might not be complicated), or send an Unscheduled > Hello in order to carry the timestamp. > > Note that the above says MAY be silently ignored. If we end up finding > a really smart link-quality estimation algorithm that needs to use > unscheduled Hellos, this can be implemented in the future without > requiring a specification change. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --Boundary_(ID_Pa/cr37PCRo28IOw9XHDzA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
That's an elegant solution. It reduces = constraints on implementations
but still allows the current = model to work.

I do have one = question however: what does the seqno represent on
unscheduled = Hellos (UH)? If an implementation MAY ignore UH for
the = purpose of link-quality estimation, then incrementing the = seqno
on UH will confuse it.

For that reason I propose that, for UH, seqno MUST = be set to 0
when sending and MUST be ignored on reception. = Also, the
interface outgoing periodic Hello seqno MUST NOT = be
incremented when sending UH.
=46rom my = understanding, this is compatible with the RTT
extension since = that doesn't use the seqno or interval.

Thoughts / counter-proposals?

Also minor: we've used the terms "occasional" and = "unscheduled"
to denote Hellos with an Interval of zero. We = should pick one for
standardization, I personally prefer = "unscheduled". We should
also pick a term for Hellos with = non-zero Intervals, I personally
prefer = "periodic".

I tried to = incorporate it into my pull request:
Let me know what you think.

Thanks,
David Schinazi


On Jun 16, 2017, at 17:15, = Juliusz Chroboczek <jch@irif.fr> wrote:

What's the use case for = "occasionally" sending a unicast hello, and can
it not be = covered by a high interval?

All = of the TLVs defined in Babel are idempotent: sending multiple
identical Updates, or multiple identical Requests, is = equivalent to
sending a single Update or Request.

The only exception are Hellos, which are not = idempotent, since they change
the state used for = link-quality estimation.  This is the root cause of
all= of our troubles: we cannot send ordinary ("Multicast") Hellos over
unicast, or else we desynchronise the link-quality estimation = state.

The other trouble this causes is = with sub-TLVs: if some data is defined to
be carried in a = sub-TLV of a Hello, then it cannot be sent at arbitrary
times, since that would change the link-quality = estimation.

We define an Unscheduled Hello = as one that carries an Interval of 0.  Such
a Hello = MAY be ignored for link-quality estimation purposed, and MAY be
outright ignored upon reception; however, any sub-TLVs it = carries are
still parsed, and aced upon.

The current application is the RTT metric, which requires a = Hello to be
sent together with each IHU (in order to carry = a timestamp).  In most
implementations, IHUs are = naturally sent together with Hellos, so nothing
is = required; however, if an implementation schedules IHUs independently = of
Hellos, then something needs to be done, either change = the scheduling of
Hellos (which might or might not be = complicated), or send an Unscheduled
Hello in order to = carry the timestamp.

Note that the above = says MAY be silently ignored.  If we end up finding
a = really smart link-quality estimation algorithm that needs to use
unscheduled Hellos, this can be implemented in the future = without
requiring a specification change.

-- Juliusz

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

= --Boundary_(ID_Pa/cr37PCRo28IOw9XHDzA)-- From nobody Mon Jun 19 22:40:20 2017 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 3F12E124C27 for ; Mon, 19 Jun 2017 22:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 EZDvq5D0xOYh for ; Mon, 19 Jun 2017 22:40:17 -0700 (PDT) Received: from mail-in23.apple.com (mail-out23.apple.com [17.171.2.33]) (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 BBC741279EB for ; Mon, 19 Jun 2017 22:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497937203; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eu7gnH4JNBJ0ZwOuqhkjNbxJincohvse210qhgiD75E=; b=C4fkStJ8nZEa5PyPudFmJRfV7E/Q0FVWg4C0x04kEsie9NlPunzcRBe52n7jhdpq 4DWUBGiplPk4azbPemn+xV3N9qw2O8nQwcSqaFTqnEQk27mNV+dmF44EUw7h7qDA S81mf3BD3fR3LBQCvxHlrmEEhpCW0DOcE24K2BQ0EsYGgjDrT9ce63zBejo05y3v 1JAx5daYvSA8OjJeMjeWTB92IL30nayjazRTpjGA9728ITkajPEBsnfaN0TqrkXo IUYDK8BX2UZfP1buJqCsbLJa4z9icGvXjMBWODu6prkdgONo2llqmN8og2HwcY+6 ZjmkXL/YJbT2g7q9/HpO2g==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in23.apple.com (Apple Secure Mail Relay) with SMTP id 54.FA.08924.335B8495; Mon, 19 Jun 2017 22:40:03 -0700 (PDT) X-AuditID: 11ab0217-59a899a0000022dc-92-5948b5332790 Received: from koseret (koseret.apple.com [17.151.62.39]) by relay2.apple.com (Apple SCV relay) with SMTP id 77.EE.08566.335B8495; Mon, 19 Jun 2017 22:40:03 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ILCmDbeT2nxeoJWCe6jWDQ)" Received: from [17.235.21.221] (unknown [17.235.21.221]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORT00J4QZQJHO40@koseret.apple.com>; Mon, 19 Jun 2017 22:40:02 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <6369EBD9-6B59-4F3D-9796-FDE6D9E749C9@apple.com> Date: Mon, 19 Jun 2017 22:40:02 -0700 In-reply-to: <87vanvwkaq.wl-jch@irif.fr> Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Babel at IETF To: Juliusz Chroboczek References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> <87vanvwkaq.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUi2FDorGu81SPSYMlJM4sti7pZLOa3LmOz 2Pp+BbsDs8eSJT+ZPBZvecvoseXQRbYA5igum5TUnMyy1CJ9uwSujAXbvAv2eFRsuzmJrYHx kG0XIyeHhICJxJKvvcxdjFwcQgJrmCSazrSxdTFygCXOX+GFiK9ilHj75BQzSAOvgKDEj8n3 WEBsZoEwiZtz3kM1tzJJbPzRA5YQFpCW6LpwlxVkEJuAlsSBNUYQvTYSqxZdAAsLC1hKvDni DRJmEVCVWHz0PCuIzSmgIXGg6TwjxPhEib67f8DiIgIqEsunPWOHWPWbSWL/+13MEA/IStya fQnsBgmB62wSuxdsZpzAKDQLya2zkNwKYWtJfH/UChTnALLlJQ6el4UIa0o8u/eJHcLWlnjy 7gLrAka2VYzCuYmZObqZeUbGeokFBTmpesn5uZsYQdGxmkl8B+Pn14aHGAU4GJV4eBe8do8U Yk0sK67MPcQozcGiJM7bVuMRKSSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRlMlzYbP2S2V+ 7weKxYHlOd1MPG3LzjRJTjjQuTfoP4N+YPSsDXG7ypan5lxJ61lfFHmtwG3lpfBTpyeIRD4s Kt+0eqeJ3b94eeapE3/ZP5gk2G5nKh72+c8UH+HyeHmht1sXssn7feRJDDtqvlJxef3dV/cE X+XYWC4RX80pt750rsXrc8xKLMUZiYZazEXFiQDG9VyLbwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKIsWRmVeSWpSXmKPExsUiON1OXdd4q0ekwY7XQhZbFnWzWMxvXcZm sfX9CnYHZo8lS34yeSze8pbRY8uhi2wBzFFcNimpOZllqUX6dglcGQu2eRfs8ajYdnMSWwPj IdsuRg4OCQETifNXeLsYuTiEBFYxSrx9coq5i5GTg1dAUOLH5HssIDazQJjEzTnvmSGKWpkk Nv7oAUsIC0hLdF24ywoyiE1AS+LAGiOIXhuJVYsugIWFBSwl3hzxBgmzCKhKLD56nhXE5hTQ kDjQdJ4RYnyiRN/dP2BxEQEVieXTnrFDrPrNJLH//S6weyQEZCVuzb7EPIGRfxaS82YhOQ/C 1pL4/qgVKM4BZMtLHDwvCxHWlHh27xM7hK0t8eTdBdYFjGyrGAWKUnMSK430EgsKclL1kvNz NzGCQrmh0HkH47FlVocYBTgYlXh4PV66RwqxJpYVV+YeYpTgYFYS4X263CNSiDclsbIqtSg/ vqg0J7X4EONERqAvJzJLiSbnAyMtryTe0MTEwMTY2MzY2NzEnJbCSuK8c6YAXSSQnliSmp2a WpBaBHMUEwenVAOj2InT+ztDNnxRXbrm8ldOnkWCAlfNtzcHbmBpKVNmW7vxqIiGntqPaxWL 5vozOa6//CfYJH3xp29m/oUqDS7Lgu5178xY0Maw2O/kgn/hy9YEJXowv09aM3HN2b6Qew4q bV4SX9NY+ffebBVYtmLysomTVmb2GDnn6B+Y5VvE8LS26B3T3T4zJZbijERDLeai4kQAZoxV UtgCAAA= Archived-At: Subject: Re: [babel] Cutoff date for rfc6126bis is 3 July X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 05:40:19 -0000 --Boundary_(ID_ILCmDbeT2nxeoJWCe6jWDQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > On Jun 16, 2017, at 17:05, Juliusz Chroboczek wrote: > >>> What I meant is that all implementations MUST be able to parse both kinds >>> of Hellos, but an implementation may choose to only ever send Multicast >>> Hellos. It may also choose to only send Unicast Hellos, but in that case >>> you need some other discovery mechanism. > >> Is there benefit in requiring all implementations to parse Multicast? >> If I only send Unicast and you only parse Multicast we're not going to >> interoperate anyway, so might as well remove the requirement that >> everyone needs to parse Multicast. > > Require that all implementations parse *both*, but an implementation is > not required to send either. So whether you send multicast or unicast > doesn't matter, I still associate with you. [DS] This approach has several downsides, all of which minor enough that I still think you're right. 1) it makes implementations over unicast-only links non-compliant. I think we can solve this by adding text saying that the requirement to support Uni/Multicast only applies to link-layers that support Uni/Multicast, respectively. 2) It makes existing implementations non-compliant -- I'm fine with that 3) An implementation that only plans to use one type of Hello needs to do additional work to receive the other kind -- I'm fine with that But the upsides make it better than other proposals including mine: 1) Any two (modern) implementations sharing a link-layer interoperate 2) Implementors are absolutely free to pick what they send 3) The RTT extension still works in all cases So I support this change. I tried to incorporate it into my pull request: https://github.com/jech/babel-drafts/pull/3/files Let me know what you think. > The implementation cost is fairly moderate (one extra set of history per > neighbour, 16 bits in my implementation), simple to specify, and ensures > interoperability. > > Any counter-proposals? > >>> Now what about an implementation that sends mostly Multicast Hellos, but >>> occasionally sends a Unicast one? Such an implementation needs to express >>> the notion that it makes no promise to ever send another Unicast hello. > >> I think the only way to allow occasional Unicast Hellos would be to >> allow the Interval to be 0 if the Hello is Unicast. I'm not sure that's >> reasonable, because if you only ever send Unicast and send it with >> an Interval of 0, I don't know when to expire you from my neighbor table. > > Well, I was thinking that an implementation MUST send either periodic > Multicast Hellos or periodic Unicast Hellos, but it MAY send occasional > Hellos of the other kind. Occasional Hellos do not participate in > link-quality estimation. > > The main application is the RTT extension, which requires a Hello to be > sent in the same packet as an IHU. If an implementation sends Multicast > Hellos and Unicast IHU, it will want to send an "occasional" Unicast Hello > together with each IHU. > > "Occasional" Hellos MAY be silently ignored, but any sub-TLVs must still > be parsed. See other thread: "Re: [babel] Unscheduled Hellos [was: Cutoff date for rfc6126bis is 3 July]" Thanks, David Schinazi --Boundary_(ID_ILCmDbeT2nxeoJWCe6jWDQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable

On Jun 16, 2017, at 17:05, Juliusz Chroboczek <jch@irif.fr> = wrote:

What I meant is that all implementations MUST be able to = parse both kinds
of Hellos, but an implementation may = choose to only ever send Multicast
Hellos.  It may = also choose to only send Unicast Hellos, but in that case
you need some other discovery mechanism.

Is there benefit in requiring all = implementations to parse Multicast?
If I only send Unicast = and you only parse Multicast we're not going to
interoperate= anyway, so might as well remove the requirement that
everyone needs to parse Multicast.

Require that all implementations = parse *both*, but an implementation is
not required to = send either.  So whether you send multicast or unicast
doesn't matter, I still associate with you.

[DS] = This approach has several downsides, all of which minor enough = that
I still think you're right.
1) it makes = implementations over unicast-only links non-compliant.
  =   I think we can solve this by adding text saying that the = requirement
    to support Uni/Multicast only = applies to link-layers that support
    = Uni/Multicast, respectively.
2) It makes existing = implementations non-compliant -- I'm fine with that
3) An = implementation that only plans to use one type of Hello
  =   needs to do additional work to receive the other kind -- I'm fine = with that

But the upsides make it = better than other proposals including mine:
1) Any two = (modern) implementations sharing a link-layer interoperate
2) = Implementors are absolutely free to pick what they send
3) The = RTT extension still works in all cases

So I support this change.

I tried to incorporate it into my pull = request:
Let me know what you think.

The implementation cost is = fairly moderate (one extra set of history per
neighbour, = 16 bits in my implementation), simple to specify, and ensures
interoperability.

Any = counter-proposals?

Now what about an = implementation that sends mostly Multicast Hellos, but
occasionally sends a Unicast one? Such an implementation = needs to express
the notion that it makes no promise to = ever send another Unicast hello.

I think the only way to allow occasional = Unicast Hellos would be to
allow the Interval to be 0 if = the Hello is Unicast. I'm not sure that's
reasonable, = because if you only ever send Unicast and send it with
an = Interval of 0, I don't know when to expire you from my neighbor = table.

Well, I was thinking = that an implementation MUST send either periodic
Multicast = Hellos or periodic Unicast Hellos, but it MAY send occasional
Hellos of the other kind.  Occasional Hellos do not = participate in
link-quality estimation.

The main application is the RTT extension, which requires a = Hello to be
sent in the same packet as an IHU.  If an = implementation sends Multicast
Hellos and Unicast IHU, it = will want to send an "occasional" Unicast Hello
together = with each IHU.

"Occasional" Hellos MAY be = silently ignored, but any sub-TLVs must still
be = parsed.

See other thread:
"Re: [babel] = Unscheduled Hellos [was: Cutoff date for rfc6126bis is 3 = July]"

Thanks,
David = Schinazi

= --Boundary_(ID_ILCmDbeT2nxeoJWCe6jWDQ)-- From nobody Tue Jun 20 01:00:36 2017 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 99F47129400 for ; Tue, 20 Jun 2017 01:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eR0EwMfdj2Uf for ; Tue, 20 Jun 2017 01:00:32 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 A846E1293F9 for ; Tue, 20 Jun 2017 01:00:15 -0700 (PDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1497945612; bh=OPInWD5/tf+dJAuSNI+xD/dcGshhJtLcHjKX4ono+A8=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=FQvXWP6DDqPSkaESEciKCsBK+73ruBXYPCXI5nL5+kSuS29u8Ep/H3DQ3n5axvS5g IsDIjkGmA8tWCp8Jzv5jl7RMwj0zUtZvHkddvKixF2qUOpFI/3ADYhnN53yt9Hm+BS nv58qQB2qYTVaeicQGMhJzUFOCx0O1+qFfc++rEHEoZmG1AFsUu5RMxIcTLxia7Fdb OpiTpSX7zBoV08BHvIuY5noJC136l/VEadb0vzbjSlkTYidZn1TEReyzvBJWcQKOFM YSpLwJ/xj7PYBjarsyAbxXW69hpIwQYWqxk11gRRKbrW3lkORQqRaCbqnxbVBqUkGK cidxzYNEky9og== To: David Schinazi Cc: Juliusz Chroboczek , Babel at IETF References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> <87y3ss5nlg.fsf@alrua-x1> <87tw3fwjtt.wl-jch@irif.fr> <5CD7F43D-2FC0-4466-AFDE-FD968D9CC158@apple.com> Date: Tue, 20 Jun 2017 10:00:10 +0200 In-Reply-To: <5CD7F43D-2FC0-4466-AFDE-FD968D9CC158@apple.com> (David Schinazi's message of "Mon, 19 Jun 2017 22:39:54 -0700") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <8760fr5bsl.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Unscheduled Hellos [was: Cutoff date for rfc6126bis is 3 July] X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 08:00:35 -0000 David Schinazi writes: > That's an elegant solution. It reduces constraints on implementations > but still allows the current model to work. > > I do have one question however: what does the seqno represent on > unscheduled Hellos (UH)? If an implementation MAY ignore UH for > the purpose of link-quality estimation, then incrementing the seqno > on UH will confuse it. > > For that reason I propose that, for UH, seqno MUST be set to 0 > when sending and MUST be ignored on reception. Also, the > interface outgoing periodic Hello seqno MUST NOT be > incremented when sending UH. > From my understanding, this is compatible with the RTT > extension since that doesn't use the seqno or interval. > > Thoughts / counter-proposals? While it makes sense that we should have a "seqno-less" hello if we are going to be ignoring them, at this point it really feels like we are overloading hellos to the point that we are really defining two different TLVs in one. A hello is there to carry a seqno and an interval, and now we're defining one that carries neither... so it's basically a new TLV, no? If we want an idempotent discovery TLV, why not just define one, separate from Hello? -Toke From nobody Tue Jun 20 05:12:37 2017 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 BF5BA12E6A3 for ; Tue, 20 Jun 2017 05:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 VOXhvb_C2RB6 for ; Tue, 20 Jun 2017 05:12:32 -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 57DB112EA97 for ; Tue, 20 Jun 2017 05:10:57 -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/56228) with ESMTP id v5KCAqNr010116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Jun 2017 14:10:52 +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/56228) with ESMTP id v5KCApot029017; Tue, 20 Jun 2017 14:10:51 +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 C02EEEB2F0; Tue, 20 Jun 2017 14:10:51 +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 NCoh-KxjHJat; Tue, 20 Jun 2017 14:10:50 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E0D58EB2CC; Tue, 20 Jun 2017 14:10:49 +0200 (CEST) Date: Tue, 20 Jun 2017 14:10:49 +0200 Message-ID: <87shiusvue.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , Babel at IETF In-Reply-To: <6369EBD9-6B59-4F3D-9796-FDE6D9E749C9@apple.com> References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> <87vanvwkaq.wl-jch@irif.fr> <6369EBD9-6B59-4F3D-9796-FDE6D9E749C9@apple.com> 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, 20 Jun 2017 14:10:52 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 20 Jun 2017 14:10:52 +0200 (CEST) X-Miltered: at korolev with ID 594910CC.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 594910CB.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 594910CC.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 594910CB.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 : 594910CC.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 594910CB.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: Re: [babel] Cutoff date for rfc6126bis is 3 July X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 12:12:36 -0000 > 1) it makes implementations over unicast-only links non-compliant. > I think we can solve this by adding text saying that the requirement > to support Uni/Multicast only applies to link-layers that support > Uni/Multicast, respectively. I think it's okay to require that all implementations be able to parse both kinds of Hello; if an implementation never receives a Multicast Hello, then the requirement is vacuously satisfied. (What's more, it is legal to send a "Multicast" Hello over multiple Unicast to all neighbours, as Margaret's implementation does. So just because an implementation speaks NBMA only doesn't mean it'll never receive a Multicast Hello.) > 2) It makes existing implementations non-compliant -- I'm fine with that Agreed. > 3) An implementation that only plans to use one type of Hello needs to > do additional work to receive the other kind -- I'm fine with that Agreed, it's one extra 16-bit field per neighbour. > https://github.com/jech/babel-drafts/pull/3/files Thanks a lot, that's very helpful. > Let me know what you think. - the NBMA exception noted above is not needed in my opinion; - that's not the way ETX should work with two kinds of Hellos with different loss probabilities; - you're giving some implementation advice that is unproven ("Properties of Multicast and Unicast Hellos") - I don't agree that unscheduled Hellos should be seqno-less -- see other mail. I assume I have your permission to cherry-pick just some of your hunks and commit under your name. -- Juliusz From nobody Tue Jun 20 05:25:37 2017 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 324AF129C34 for ; Tue, 20 Jun 2017 05:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 gAIKwdM2QHf2 for ; Tue, 20 Jun 2017 05:25:32 -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 3884E129B1E for ; Tue, 20 Jun 2017 05:25:32 -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/56228) with ESMTP id v5KCPQUX019145; Tue, 20 Jun 2017 14:25:26 +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 9F723EB345; Tue, 20 Jun 2017 14:25:26 +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 ltGAVmqLITUU; Tue, 20 Jun 2017 14:25:25 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 5BCCAEB343; Tue, 20 Jun 2017 14:25:25 +0200 (CEST) Date: Tue, 20 Jun 2017 14:25:25 +0200 Message-ID: <87r2yesv62.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: David Schinazi , Babel at IETF In-Reply-To: <8760fr5bsl.fsf@alrua-x1> References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> <87y3ss5nlg.fsf@alrua-x1> <87tw3fwjtt.wl-jch@irif.fr> <5CD7F43D-2FC0-4466-AFDE-FD968D9CC158@apple.com> <8760fr5bsl.fsf@alrua-x1> 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, 20 Jun 2017 14:25:26 +0200 (CEST) X-Miltered: at korolev with ID 59491436.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59491436.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 : 59491436.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] Unscheduled Hellos X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 12:25:36 -0000 >> I do have one question however: what does the seqno represent on >> unscheduled Hellos (UH)? If an implementation MAY ignore UH for >> the purpose of link-quality estimation, then incrementing the seqno >> on UH will confuse it. It's ignored for the purposes of link-quality estimation, but it must still participate in seqno computation. So upon receiving an unscheduled Seqno, you do the following: if received seqno = expected seqno expected seqno := received seqno + 1 hello history remains unchanged else compute the amount of loss as usual. The only issue is that if unscheduled Hellos were lost, you might mistake them for scheduled Hellos. Not a big deal, but I must do an implementation before I'm sure. >> For that reason I propose that, for UH, seqno MUST be set to 0 >> when sending and MUST be ignored on reception. > While it makes sense that we should have a "seqno-less" hello if we are > going to be ignoring them, at this point it really feels like we are > overloading hellos to the point that we are really defining two > different TLVs in one. A hello is there to carry a seqno and an > interval, and now we're defining one that carries neither... so it's > basically a new TLV, no? > If we want an idempotent discovery TLV, why not just define one, > separate from Hello? Agreed -- but we should do one or the other, not both. Either a new TLV for seqno-less Hello, or the Unicast flag in Hellos. I'm strongly opposed to doing both. That was more or less my proposal in Chicago: define a new "Unicast Hello" TLV that is seqno-less and interval-less. This was rejected by David, who wants Unicast Hellos to have all the nice properties of ordinary (multicast) Hellos. Now, I'm rather sympathetic to David's concerns, but I want Unicast Hellos to fix the RTT extension when Hellos are sent over multicast and IHUs are sent over unicast (right now, RTT requires that Hellos and IHUs be sent together). I see three solutions: 1. redefine the RTT extension to allow timestamps in IHU; 2. allow unscheduled Hellos; 3. force all implementations of RTT to either send IHU over multicast or to participate in Unicast Hello link-quality estimation. (3) significantly complicates implementation of the RTT extension, which is successfully deployed in production and not something I'm willing to give up. What is more, I'm worried that using Unicast Hellos in link-quality estimation will break WiFi link-quality estimation -- I'll expand on that in another mail. So my choice would be to allow unscheduled Hellos. Right now, I see no good reason to make them seqno-less, but I might change my mind when I write the code. -- Juliusz From nobody Tue Jun 20 05:55:25 2017 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 A130412EB20 for ; Tue, 20 Jun 2017 05:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 mSHbHe5q6nW3 for ; Tue, 20 Jun 2017 05:55:21 -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 7E89A120724 for ; Tue, 20 Jun 2017 05:55:21 -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/56228) with ESMTP id v5KCtJ4A007573; Tue, 20 Jun 2017 14:55: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 1BDBEEB2F0; Tue, 20 Jun 2017 14:55: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 HESbiIODdTJV; Tue, 20 Jun 2017 14:55:17 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 49736EB2D0; Tue, 20 Jun 2017 14:55:17 +0200 (CEST) Date: Tue, 20 Jun 2017 14:55:16 +0200 Message-ID: <87podystsb.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org CC: 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 [194.254.61.138]); Tue, 20 Jun 2017 14:55:19 +0200 (CEST) X-Miltered: at korolev with ID 59491B37.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59491B37.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 : 59491B37.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] Unscheduled Unicast Hellos: some background on 802.11 link quality estimation X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 12:55:23 -0000 Dear all, Here's a little bit of background on WiFi link quality estimation. Please read at least the conclusions at the end. On networks comprising WiFi links, it is essential to perform link quality estimation. Consider the following topology: * * * | | | ----A-----B C Here A is your ISP-provided CPE, with a shitty WiFi interface. B is the nice router in your living-room, which is connected by Ethernet to A. C is the extra WiFi router with a big antenna that you put in your garden shed after your daughter complained about poor WiFi coverage in her treehouse. The route A---B...C has little packet loss, due to the nice WiFi interfaces in B and C. Unfortunately, A and C tend to associate, and if the routing protocol treats all wireless hops as equal, then the lossy route A...C is preferred to the almost lossless route A---B...C. This is not a theoretical argument -- it was a big problem with the first mesh protocols in the early noughts (Google "gray zones mesh routing"). The slogan is "shortest-path routing is worst path routing". The (automated) solution is to measure link quality. Doing this usefully requires taking two facts into account: 1. 802.11 performs ARQ on unicast frames, but not on multicast frames; 2. 802.11 uses adaptative rate control on unicast frames, but not on multicast frames. There are two approaches: A. send periodic multicast frames and measure multicast loss. Due to the lack of ARQ and the lack of rate adaptation on multicast frames, this provides reproducible and moderately useful results, but converges very slowly. ETX is the simplest useful algorithm. B. send periodic unicast frames and use the information from the lower-layer rate controller (Minstrel in the case of the ath9k driver on Linux). This converges very fast given sufficient unicast traffic, but tends to provide useless results on links with little unicast traffic (e.g. links not chosen by the routing protocol). Babel uses approach A, just like OLSR-ETX. ETX has some flaws (it tends to treat all lossless links as equal, whatever the rate chosen for unicast, and causes a slight feedback loop, leading to moderate routing instability), but it is simple to implement and works pretty well with Babel (which deals rather well with instabilities). Approach B is tricky to implement, since it requires interacting with the WiFi driver at a very low level. Nonetheless, there are at least two implementations of routing protocols that use approach B: BATMAN-adv and Lamparter's variant of IS-IS. The BATMAN-adv people do not speak about experimental results (at least to me), but Battlemesh experiments have reproducibly shown disappointing performance [1,2]. Lamparter's experiments [3,4] indicate that his link-quality algorithm converges much faster than ETX, but tends to mis-calculate the metric of idle links (due to too little feedback from unicast frames -- this might or might not be due to the lack of Unicast Hellos). [1] http://docs.battlemesh.org/v8/1-the-mesh-of-death-adversity.html#results [2] https://www.irif.fr/~jch//software/babel/battlemeshv10.html [3] David Lamparter, private communication in a bar. [4] Mikael Abrahamsson, posting to homenet@ietf that I'm too lazy to look up. Now the conclusions relevant to the Unicast Hello discussion: 1. Approach A is the one that is known to work reasonably well, and it MUST NOT be broken. This means making it possible to use Multicast Hellos for link-quality estimation without interference from Unicast Hellos -- hence the requirement for unscheduled Unicast Hellos. 2. While to my knowledge nobody has been able to make approach B work reliably, we do not want to prevent people from experimenting with it in Babel -- hence the desire for useful Unicast Hellos. Thanks for your attention, -- Juliusz From nobody Tue Jun 20 06:36:39 2017 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 11C4012EBC9 for ; Tue, 20 Jun 2017 06:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 djXAv5jnK89a for ; Tue, 20 Jun 2017 06:36:35 -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 1DE0712EBB8 for ; Tue, 20 Jun 2017 06:36:34 -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/56228) with ESMTP id v5KDaWbP001315; Tue, 20 Jun 2017 15:36: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 D5240EB36A; Tue, 20 Jun 2017 15:36: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 TY_qbgzTtAL1; Tue, 20 Jun 2017 15:36:31 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 8E9DDEB342; Tue, 20 Jun 2017 15:36:31 +0200 (CEST) Date: Tue, 20 Jun 2017 15:36:31 +0200 Message-ID: <87h8zasrvk.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org Cc: babel-users@lists.alioth.debian.org In-Reply-To: <87podystsb.wl-jch@irif.fr> References: <87podystsb.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, 20 Jun 2017 15:36:33 +0200 (CEST) X-Miltered: at korolev with ID 594924E0.00A by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 594924E0.00A 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 : 594924E0.00A 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] Unscheduled Unicast Hellos: some background on 802.11 link quality estimation X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 13:36:37 -0000 > [4] Mikael Abrahamsson, posting to homenet@ietf that I'm too lazy to look up. Mikael says: https://www.ietf.org/mail-archive/web/homenet/current/msg06322.html https://www.ietf.org/mail-archive/web/homenet/current/msg06360.html is my posting I believe you're looking for. Thanks! -- Juliusz From nobody Tue Jun 20 10:05:32 2017 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 E48CC131574 for ; Tue, 20 Jun 2017 10:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 rNxy_oabm96L for ; Tue, 20 Jun 2017 10:05:25 -0700 (PDT) Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (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 3D8E013157B for ; Tue, 20 Jun 2017 10:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497978312; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jTbuDwVd7sHcMhStnJ/rig+cEYU7rj9+D2xJwQjazsA=; b=Go9TzU9rH1oqH3mczf5LFWqTCrQBfmvyyt/TB6OEhqThCfwizMBfhKtqcx6eCPsw GtBJY4IssngDXWIvyHfX7GNJ+F0kv1IxKe65EmRJxvdzDA0ym4zxG3rx7rH6n3Le YAnC7anc5gdvuWpxgNtcQat538DZe+u0Xd/ZNpLW7escEVY3ExhSlLqemc/ndkRj hYOn11wvnrGb2ymQwMGR6xJnP+Ti+W1gazipvvSjRPxcH6JS24LqKzJArNS4jUs7 1jrtv7F6wBI3krt0ji1N2vcZWXaiH9RtrQSBR6/kqM09YkSgtvBxG5xVDCsUcu+w HT8atk6BCrdhFmt5ZXO/ig==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id 83.D3.02110.7C559495; Tue, 20 Jun 2017 10:05:12 -0700 (PDT) X-AuditID: 11ab0219-4546b9a00000083e-61-594955c7952c Received: from jimbu (jimbu.apple.com [17.151.62.37]) by relay6.apple.com (Apple SCV relay) with SMTP id 89.22.05199.7C559495; Tue, 20 Jun 2017 10:05:11 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_znQ82qXZnl7HTLqBRuAAhg)" Received: from [17.234.85.161] (unknown [17.234.85.161]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORU00E5JVGHT070@jimbu.apple.com>; Tue, 20 Jun 2017 10:05:11 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <7A8D8E73-C38E-48B0-8E09-04D8A4BC7805@apple.com> Date: Tue, 20 Jun 2017 10:05:04 -0700 In-reply-to: <87shiusvue.wl-jch@irif.fr> Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Babel at IETF To: Juliusz Chroboczek References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> <87vanvwkaq.wl-jch@irif.fr> <6369EBD9-6B59-4F3D-9796-FDE6D9E749C9@apple.com> <87shiusvue.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUi2FAYpXsi1DPS4NVxCYsti7pZLOa3LmOz 2Pp+BbsDs8eSJT+ZPBZvecvoseXQRbYA5igum5TUnMyy1CJ9uwSujNN/F7MX7DWvmDD3EHsD 43n9LkZODgkBE4nfU5+ygthCAmuYJL5OKISJd26YwNTFyAUUX8Yo8eTkDWaQBK+AoMSPyfdY QGxmgTCJx+vXM0MU/WeU6O3ewg6SEBaQlui6cBdoKgcHm4CWxIE1RhC9NhK7tn9jAgkLC1hK vDniDRJmEVCVmPtoE9h4TgENiUWvWqDGJ0r03f0DdpuIgIrE8mnP2CFWnWKWmNZwmRXiUFmJ W7Mvgd0gIXCdTaLzxRL2CYxCs5DcOgvJrRC2lsT3R61AcQ4gW17i4HlZiLCmxLN7n9ghbG2J J+8usC5gZFvFKJybmJmjm5lnZKqXWFCQk6qXnJ+7iREUH6uZJHcwfn1teIhRgINRiYc3Qtkz Uog1say4MvcQozQHi5I4b0eNR6SQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxtoOngW8n2Us 8xbf/ft+h+ET4/Xmix+rTEyTfCvR+fLr2u3rLh2Qq6uTCRA5v0XsnscSHb/MS3U84U8KlrRW nPhsLBt0+/0DycC0PE2hOSsvOyXeNBDg+5X7InW70rLPR3yqNl2bPClq2p+kjmOeR96ycufn vlkQyW7CtuLFP0H7jJjP5YVvTimxFGckGmoxFxUnAgDFq5tpcAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUiON1OVfd4qGekwbeJxhZbFnWzWMxvXcZm sfX9CnYHZo8lS34yeSze8pbRY8uhi2wBzFFcNimpOZllqUX6dglcGaf/LmYv2GteMWHuIfYG xvP6XYycHBICJhKdGyYwdTFycQgJLGOUeHLyBjNIgldAUOLH5HssIDazQJjE4/XrmSGK/jNK 9HZvYQdJCAtIS3RduMvaxcjBwSagJXFgjRFEr43Eru3fmEDCwgKWEm+OeIOEWQRUJeY+2gQ2 nlNAQ2LRqxao8YkSfXf/sILYIgIqEsunPWOHWHWKWWJaw2VWiENlJW7NvsQ8gZF/FpLzZiE5 D8LWkvj+qBUozgFky0scPC8LEdaUeHbvEzuErS3x5N0F1gWMbKsYBYpScxIrzfQSCwpyUvWS 83M3MYLCuaEwagdjw3KrQ4wCHIxKPLwMip6RQqyJZcWVuYcYJTiYlUR4nZyBQrwpiZVVqUX5 8UWlOanFhxgnMgJ9OZFZSjQ5HxhteSXxhiYmBibGxmbGxuYm5rQUVhLnnTfFI1JIID2xJDU7 NbUgtQjmKCYOTqkGRvG20pAMw8lV85IlvrD8n/HNYUX68e8/996yWSBn19Lxq75uh9qjzrhD MTtP7k/W/5spefN2hKfkiSa+HXPUD832+vatuuF3htDKb5suvE0zv6nbOdH32o1DhmJ3fi2x iPPZcsWy1iLj9YbCW5bLErQfBhnkGFxWuOjFr9V09lou/+/HPQ3PApRYijMSDbWYi4oTAYG1 ESvaAgAA Archived-At: Subject: Re: [babel] Cutoff date for rfc6126bis is 3 July X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 17:05:28 -0000 --Boundary_(ID_znQ82qXZnl7HTLqBRuAAhg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > On Jun 20, 2017, at 05:10, Juliusz Chroboczek wrote: > >> 1) it makes implementations over unicast-only links non-compliant. >> I think we can solve this by adding text saying that the requirement >> to support Uni/Multicast only applies to link-layers that support >> Uni/Multicast, respectively. > > I think it's okay to require that all implementations be able to parse > both kinds of Hello; if an implementation never receives a Multicast > Hello, then the requirement is vacuously satisfied. Fair enough, I removed that text. > (What's more, it is legal to send a "Multicast" Hello over multiple > Unicast to all neighbours, as Margaret's implementation does. So just > because an implementation speaks NBMA only doesn't mean it'll never > receive a Multicast Hello.) I agree, I changed the text to reflect that. >> 2) It makes existing implementations non-compliant -- I'm fine with that > > Agreed. > >> 3) An implementation that only plans to use one type of Hello needs to >> do additional work to receive the other kind -- I'm fine with that > > Agreed, it's one extra 16-bit field per neighbour. > >> https://github.com/jech/babel-drafts/pull/3/files > > Thanks a lot, that's very helpful. > >> Let me know what you think. > > - the NBMA exception noted above is not needed in my opinion; Agreed > - that's not the way ETX should work with two kinds of Hellos with > different loss probabilities; Continuing discussion on thread: "Unscheduled Unicast Hellos: some background on 802.11 link quality estimation" > - you're giving some implementation advice that is unproven ("Properties > of Multicast and Unicast Hellos") Fair enough, I still think we should provide rationale and advice on how to pick which type of Hello to use, can you suggest better text? > - I don't agree that unscheduled Hellos should be seqno-less -- see other > mail. Continuing discussion on thread: "Unscheduled Hellos" > I assume I have your permission to cherry-pick just some of your hunks and > commit under your name. Absolutely. David Schinazi --Boundary_(ID_znQ82qXZnl7HTLqBRuAAhg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
On Jun 20, 2017, at 05:10, Juliusz Chroboczek <jch@irif.fr> = wrote:

1) it makes = implementations over unicast-only links non-compliant.
I = think we can solve this by adding text saying that the requirement
to support Uni/Multicast only applies to link-layers that = support
Uni/Multicast, respectively.

I think it's okay to require that = all implementations be able to parse
both kinds of Hello; = if an implementation never receives a Multicast
Hello, = then the requirement is vacuously satisfied.

Fair = enough, I removed that text.

(What's more, = it is legal to send a "Multicast" Hello over multiple
Unicast to all neighbours, as Margaret's implementation does. =  So just
because an implementation speaks NBMA only = doesn't mean it'll never
receive a Multicast Hello.)

I = agree, I changed the text to reflect that.

2) It makes existing implementations = non-compliant -- I'm fine with that

Agreed.

3) An implementation that only plans to use one type of Hello = needs to
do additional work to receive the other kind -- = I'm fine with that

Agreed, = it's one extra 16-bit field per neighbour.

https://github.com/jech/babel-drafts/pull/3/files

Thanks a lot, that's very = helpful.

Let me know what you think.

- the NBMA exception noted above is not needed in my = opinion;

Agreed

- that's not the way ETX = should work with two kinds of Hellos with
=   different loss probabilities;

Continuing discussion on thread:
"Unscheduled Unicast Hellos: some background on 802.11 link = quality estimation"

- you're giving some = implementation advice that is unproven ("Properties
=   of Multicast and Unicast Hellos")

Fair = enough, I still think we should provide rationale and advice on = how
to pick which type of Hello to use, can you suggest better = text?

- I don't agree that unscheduled Hellos = should be seqno-less -- see other
  mail.

Continuing discussion on thread:
"Unscheduled Hellos"

I assume I have = your permission to cherry-pick just some of your hunks and
commit under your name.

Absolutely.

David Schinazi
= --Boundary_(ID_znQ82qXZnl7HTLqBRuAAhg)-- From nobody Tue Jun 20 10:26:26 2017 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 86267129C53 for ; Tue, 20 Jun 2017 10:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 QMtSbDRoX1bs for ; Tue, 20 Jun 2017 10:26:23 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 BA30F131582 for ; Tue, 20 Jun 2017 10:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497979580; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IaZKzhHU3d5P6bqtSSCTswSoAVPRa0VR4LkVpWnuC+g=; b=F+/spbN0T+rOd580dpy2R8oOHEGsMWpXlD1vz8UULJYkIJFk8loy8UAQdKE6iVMn q6wT+4Zw58xQgY8YUem7IatdOBvRDIXB++b9Wi0ETGmoeatbKmvq8XvqphXDx1wI xqD3r6Z5ToibLQmJurAzbLfYQ/Q4M/HqFHZT3OfF16naF2kyQTzJTBy+kvvu9aWy yMiYjBMXA1gtjwCcSlxaXpuQL1N+OS0pkDYz5rHLXIS5IaLr7EcJbCkxMyRzzeMC GeDv4QKT+F3XrISqsx9u39p5dRzQpQ1SatohuA/34QN8tfujLGFG3ZGlNR6X5yMo a7R8d2cLnDwoZMfKo6Uw3w==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id FD.A0.07949.ABA59495; Tue, 20 Jun 2017 10:26:20 -0700 (PDT) X-AuditID: 11973e16-be3ff70000001f0d-6b-59495abaf44d Received: from koseret (koseret.apple.com [17.151.62.39]) by relay2.apple.com (Apple SCV relay) with SMTP id A7.FE.08566.ABA59495; Tue, 20 Jun 2017 10:26:18 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.234.85.161] (unknown [17.234.85.161]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORU00EE6WFQ1J50@koseret.apple.com>; Tue, 20 Jun 2017 10:26:18 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87h8zasrvk.wl-jch@irif.fr> Date: Tue, 20 Jun 2017 10:26:13 -0700 Cc: babel@ietf.org, babel-users@lists.alioth.debian.org Message-id: References: <87podystsb.wl-jch@irif.fr> <87h8zasrvk.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUi2FDorLsnyjPS4NweKYuvnxtYLLYs6max mN+6jM2B2WPJkp9MHou3vGX0eHOojyWAOYrLJiU1J7MstUjfLoEr4938GawFH9grji0LbmDc xNbFyMkhIWAiceLGIuYuRi4OIYHVTBIfdmxmhkn8be5mh0isYpT4sug4E0iCV0BQ4sfkeyxd jBwczALyEgfPy4KEmQW0JL4/amWBqG9lkrj9vo8VJCEsIC3RdeEulF0k8Xr2MnaQXjaghgNr jEDCnAIaEgeX7gErYRFQlXg0azMjxExzibOX3kCttZFo/XqKHcQWEnCWmPtnAZgtIqAisXza M3aIm2Ulbs2+BPaMhMAWNolHD++yTWAUnoXk7FkIZ89CcvYCRuZVjEK5iZk5upl55nqJBQU5 qXrJ+bmbGEGhPt1ObAfjw1VWhxgFOBiVeHgjlD0jhVgTy4orcw8xSnOwKInz5tR4RAoJpCeW pGanphakFsUXleakFh9iZOLglGpgLJV4ynf0wo829qmpF2593Nmh2i2o0vxVuf/37nBjGcZK 1wlRP8tt/lksN+Ga963n6w5l8zfzuIUydK6HRgn33p3Ise37FOWN4akunVrCXN+6N54OZDm3 VilvZkrfJ9ad0xbwfFd9FhYrbecVfC2b3UNd+oqy/74NEd7BXh6fOf+yhG0uaZqsxFKckWio xVxUnAgALhEMHVYCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUiON1OXXdXlGekwZ8eUYuvnxtYLLYs6max mN+6jM2B2WPJkp9MHou3vGX0eHOojyWAOYrLJiU1J7MstUjfLoEr4938GawFH9grji0LbmDc xNbFyMkhIWAi8be5m72LkYtDSGAVo8SXRceZQBK8AoISPybfY+li5OBgFpCXOHheFiTMLKAl 8f1RKwtEfSuTxO33fawgCWEBaYmuC3eh7CKJ17OXsYP0sgE1HFhjBBLmFNCQOLh0D1gJi4Cq xKNZmxkhZppLnL30BmqtjUTr11PsILaQgLPE3D8LwGwRARWJ5dOesUPcLCtxa/Yl5gmMArOQ XDoL4dJZSC5dwMi8ilGgKDUnsdJIL7GgICdVLzk/dxMjKDQbCp13MB5bZnWIUYCDUYmHl0HR M1KINbGsuDL3EKMEB7OSCK+TM1CINyWxsiq1KD++qDQntfgQYxXQ/ROZpUST84Fxk1cSb2hi YmBibGxmbGxuYk4VYSVx3jlTPCKFBNITS1KzU1MLUotgljNxcEo1MDqdlnOIUVRgWmH/4JmL 7xPf+VfK8zacFStau/BFt47TFaaXVxi9F0zvCi9yKtyRPveOX7T3YW6JPCVh50lCFZd/rz9R d/JRtWiciDAD++OKrdlWC+9eknz1bX9zykm7p7UvJ3nXT2Q4ebvijNDym4F1buyZc14v3jf3 g8zyzbz3Hr0uFmrffFiJpTgj0VCLuag4EQCgx+ExqAIAAA== Archived-At: Subject: Re: [babel] [Babel-users] Unscheduled Unicast Hellos: some background on 802.11 link quality estimation X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 17:26:24 -0000 Juliusz, Thanks for the explanation, it makes sense to me. It also helped me realize that my text about combining the Unicast and Multicasts costs is incorrect. I think a lot of what you wrote in the previous email would be a valuable addition to the spec. One could imagine using Multicast + ETX to determine the loss rate and unicast + driver information to distinguish between different lossless links. Can you provide text? David > On Jun 20, 2017, at 06:36, Juliusz Chroboczek wrote: > >> [4] Mikael Abrahamsson, posting to homenet@ietf that I'm too lazy to look up. > > Mikael says: > > https://www.ietf.org/mail-archive/web/homenet/current/msg06322.html > https://www.ietf.org/mail-archive/web/homenet/current/msg06360.html > > is my posting I believe you're looking for. > > Thanks! > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Tue Jun 20 10:41:37 2017 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 70F6513159C for ; Tue, 20 Jun 2017 10:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 KzGmm3-56Hke for ; Tue, 20 Jun 2017 10:41:32 -0700 (PDT) Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (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 B9CE0131599 for ; Tue, 20 Jun 2017 10:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497980491; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=D7xoxyXirVjujqlfgFGJA2So+k699jFQuyKJf3SFfWs=; b=KxKnZ/KGiWSQx+uKcrVxRsrOvi/SBvRxv7+HIIqWs3kyw502lQhrlqOib9vnASke neOJoRiExs1TbxyJ3XL26SDRICHnjkOaYy4d6rgVnnwFIpzwnIMLyZX17QLxVRq9 GBaeuMQwbR8yyFKx1Rdhvt5vQFZ2Tuzss83PT9dTqtpqeadacOgFCaxwAacBh6lA EhVGHLxQuu1rpx/R1V+LJj6MT/MNiRyrglYsZ0Roya+2RgqZpRHxRh5jiVL8SoVL O9+ynw+U4gdWEm+jrjbYtMH+NZD2G6FABY99OKtpOCSeKgaZSImZfF58lsxBaOfH PuBLLZU7NHTrRQE20E690g==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id 2A.9B.17842.B4E59495; Tue, 20 Jun 2017 10:41:31 -0700 (PDT) X-AuditID: 11ab0218-4df929a0000045b2-27-59495e4b368b Received: from koseret (koseret.apple.com [17.151.62.39]) by relay8.apple.com (Apple SCV relay) with SMTP id 9C.AF.05704.B4E59495; Tue, 20 Jun 2017 10:41:31 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.234.85.161] (unknown [17.234.85.161]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORU00EYNX541J50@koseret.apple.com>; Tue, 20 Jun 2017 10:41:31 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87r2yesv62.wl-jch@irif.fr> Date: Tue, 20 Jun 2017 10:41:28 -0700 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Babel at IETF Message-id: <9EE24349-90A8-4855-A572-13C06C7D85D7@apple.com> References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> <87y3ss5nlg.fsf@alrua-x1> <87tw3fwjtt.wl-jch@irif.fr> <5CD7F43D-2FC0-4466-AFDE-FD968D9CC158@apple.com> <8760fr5bsl.fsf@alrua-x1> <87r2yesv62.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUi2FCYpusd5xlpcOSolcWWRd0sFvNbl7FZ bH2/gt2B2WPJkp9MHou3vGX02HLoIlsAcxSXTUpqTmZZapG+XQJXxvaP85kKXipVXH+4hLmB sVO6i5GTQ0LARGLDioksXYxcHEICa5kk7q7+zg6TOHblACNEYhWjRN++aWAJXgFBiR+T7wF1 cHAwC8hLHDwvCxJmFtCS+P6oFWpQK5PEoobFYPXCAtISXRfuskLY6hI7309gBellA2o4sMYI JMwpoCHxe/ZJJhCbRUBV4taqgywQMxMl+u7+YYVYayNx8t9zdoj5DSwSba9+gBWJCKhILJ/2 DOpoWYlbsy8xgxRJCGxhkzhw7SfjBEbhWUjunoVw9ywkdy9gZF7FKJybmJmjm5lnZKKXWFCQ k6qXnJ+7iREU8KuZJHYwfnlteIhRgINRiYc3QtkzUog1say4MvcQozQHi5I4b0+NR6SQQHpi SWp2ampBalF8UWlOavEhRiYOTqkGxl5Fu2gV2W8zi8vfW6+Y7HKMifGS8YZpLRdu9s5WuiP7 W3XOXW1nzaPLOB+vmvvJ9f/qh8cN3huoaYXsNBeLOnHAVvJxOedK4Vr1pxZ6fHuNZhueeS/x c+Nb/f0xLkviJ8m1RUxfsG5B90Jm7f09R1n+8T4ScZeSvHIqdpVdnrW924/u49VT85VYijMS DbWYi4oTATKg9KNZAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUiON1OXdc7zjPSYNNXWYsti7pZLOa3LmOz 2Pp+BbsDs8eSJT+ZPBZvecvoseXQRbYA5igum5TUnMyy1CJ9uwSujO0f5zMVvFSquP5wCXMD Y6d0FyMnh4SAicSxKwcYuxi5OIQEVjFK9O2bxg6S4BUQlPgx+R5LFyMHB7OAvMTB87IgYWYB LYnvj1pZIOpbmSQWNSwGqxcWkJbounCXFcJWl9j5fgIrSC8bUMOBNUYgYU4BDYnfs08ygdgs AqoSt1YdZIGYmSjRd/cPK8RaG4mT/56zQ8xvYJFoe/UDrEhEQEVi+bRn7BBHy0rcmn2JeQKj wCwkp85COHUWklMXMDKvYhQoSs1JrLTQSywoyEnVS87P3cQICs+GwrQdjE3LrQ4xCnAwKvHw Mih6RgqxJpYVV+YeYpTgYFYS4XVyBgrxpiRWVqUW5ccXleakFh9irAJ6YCKzlGhyPjB28kri DU1MDEyMjc2Mjc1NzKkirCTOO2eKR6SQQHpiSWp2ampBahHMciYOTqkGRtGQxx+8XF3rX0c+ Klr9qfLCI0Ne4yUJu8X9391etjVSreOMrMjKklviPUUzFm6bX2VUZatctP6pX0i5XkBS1a9H lokplyJXTpKS6nUONo293N0+e5nm7uvPVjPyvDjy2nG9Zdjsulb/xlnrOTxOZE+/28EtNL2+ vC1vlfOqCwKu4tPU5s93UWIpzkg01GIuKk4EAPDKXS6qAgAA Archived-At: Subject: Re: [babel] Unscheduled Hellos X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 17:41:35 -0000 I agree with Juliusz in that I'd rather not have a new TLV for Unscheduled Hellos. I'd like Periodic Unicast Hellos to have a seqno so a Unicast-only implementation can still perform similar link-cost estimation. Also, the main goal of Unscheduled Hellos in my mind is to support the RTT extension and similar sub-TLVs, which need to be sent on the Hello TLV. I also agree that Unscheduled Hello are simpler than changing the RTT extension. Regarding the seqno on Unscheduled Hellos, we have two options: 1) Keep the seqno (send it and increment it) Upsides: Hello carries some more information (?) Downsides: Hello parsing code becomes slightly more complex Missing an Unscheduled Hello is indistinguishable from missing a Periodic Hello 2) Remove the seqno (send 0, ignore it, do not increment) Upsides: Implementations can simply ignore them An implementation can avoid having seqnos at all for outgoing Unicast Hellos if using Periodic Multicast Hellos. Downsides: Hello carries less information (?) Overloads fields in the Hello TLV I have a preference for (2) because it fits all our requirements and was simpler than (1) to implement. Does someone see other upsides to (1) or downsides to (2) that I'm missing? Thanks, David Schinazi > On Jun 20, 2017, at 05:25, Juliusz Chroboczek wrote: > >>> I do have one question however: what does the seqno represent on >>> unscheduled Hellos (UH)? If an implementation MAY ignore UH for >>> the purpose of link-quality estimation, then incrementing the seqno >>> on UH will confuse it. > > It's ignored for the purposes of link-quality estimation, but it must > still participate in seqno computation. So upon receiving an unscheduled > Seqno, you do the following: > > if received seqno = expected seqno > expected seqno := received seqno + 1 > hello history remains unchanged > else > compute the amount of loss as usual. > > The only issue is that if unscheduled Hellos were lost, you might mistake > them for scheduled Hellos. Not a big deal, but I must do an > implementation before I'm sure. > >>> For that reason I propose that, for UH, seqno MUST be set to 0 >>> when sending and MUST be ignored on reception. > >> While it makes sense that we should have a "seqno-less" hello if we are >> going to be ignoring them, at this point it really feels like we are >> overloading hellos to the point that we are really defining two >> different TLVs in one. A hello is there to carry a seqno and an >> interval, and now we're defining one that carries neither... so it's >> basically a new TLV, no? > >> If we want an idempotent discovery TLV, why not just define one, >> separate from Hello? > > Agreed -- but we should do one or the other, not both. Either a new TLV > for seqno-less Hello, or the Unicast flag in Hellos. I'm strongly opposed > to doing both. > > That was more or less my proposal in Chicago: define a new "Unicast Hello" > TLV that is seqno-less and interval-less. This was rejected by David, who > wants Unicast Hellos to have all the nice properties of ordinary > (multicast) Hellos. > > Now, I'm rather sympathetic to David's concerns, but I want Unicast Hellos > to fix the RTT extension when Hellos are sent over multicast and IHUs are > sent over unicast (right now, RTT requires that Hellos and IHUs be sent > together). I see three solutions: > > 1. redefine the RTT extension to allow timestamps in IHU; > 2. allow unscheduled Hellos; > 3. force all implementations of RTT to either send IHU over multicast or > to participate in Unicast Hello link-quality estimation. > > (3) significantly complicates implementation of the RTT extension, which > is successfully deployed in production and not something I'm willing to > give up. What is more, I'm worried that using Unicast Hellos in > link-quality estimation will break WiFi link-quality estimation -- I'll > expand on that in another mail. > > So my choice would be to allow unscheduled Hellos. Right now, I see no > good reason to make them seqno-less, but I might change my mind when > I write the code. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Tue Jun 20 11:36:14 2017 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 54D3C1315D8 for ; Tue, 20 Jun 2017 11:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Y2dt7GID1HNr for ; Tue, 20 Jun 2017 11:36:10 -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 06482129445 for ; Tue, 20 Jun 2017 11:36:09 -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/56228) with ESMTP id v5KIa2TR017737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Jun 2017 20:36:02 +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/56228) with ESMTP id v5KIa282017930; Tue, 20 Jun 2017 20:36:02 +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 60424EB2D0; Tue, 20 Jun 2017 20:36:02 +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 DmjIWPzBQX3t; Tue, 20 Jun 2017 20:36:00 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 75D8EEB274; Tue, 20 Jun 2017 20:36:00 +0200 (CEST) Date: Tue, 20 Jun 2017 20:35:59 +0200 Message-ID: <874lvav75c.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: babel@ietf.org, babel-users@lists.alioth.debian.org In-Reply-To: References: <87podystsb.wl-jch@irif.fr> <87h8zasrvk.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, 20 Jun 2017 20:36:03 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 20 Jun 2017 20:36:02 +0200 (CEST) X-Miltered: at korolev with ID 59496B12.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 59496B12.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59496B12.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 59496B12.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 : 59496B12.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 59496B12.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] Unscheduled Unicast Hellos: some background on 802.11 link quality estimation X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 18:36:12 -0000 > Can you provide text? Yes, I will do. Please focus on specifying the on-the-wire bits, I'll take care of the appendix. -- Juliusz From nobody Tue Jun 20 12:00:06 2017 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 7E4641293E1 for ; Tue, 20 Jun 2017 12:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Jpr8LsHOALlZ for ; Tue, 20 Jun 2017 12:00: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 9F7DA128D19 for ; Tue, 20 Jun 2017 12:00:03 -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/56228) with ESMTP id v5KIxvxG022721; Tue, 20 Jun 2017 20:59:57 +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 E3F21EB2F0; Tue, 20 Jun 2017 20:59:57 +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 Ewa6hoKllLmI; Tue, 20 Jun 2017 20:59:57 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E0568EB2CC; Tue, 20 Jun 2017 20:59:56 +0200 (CEST) Date: Tue, 20 Jun 2017 20:59:56 +0200 Message-ID: <8737auv61f.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , Babel at IETF In-Reply-To: <9EE24349-90A8-4855-A572-13C06C7D85D7@apple.com> References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> <87y3ss5nlg.fsf@alrua-x1> <87tw3fwjtt.wl-jch@irif.fr> <5CD7F43D-2FC0-4466-AFDE-FD968D9CC158@apple.com> <8760fr5bsl.fsf@alrua-x1> <87r2yesv62.wl-jch@irif.fr> <9EE24349-90A8-4855-A572-13C06C7D85D7@apple.com> 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, 20 Jun 2017 20:59:58 +0200 (CEST) X-Miltered: at korolev with ID 594970AD.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 594970AD.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 : 594970AD.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] Unscheduled Hellos X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 19:00:05 -0000 > Regarding the seqno on Unscheduled Hellos, we have two options: Either makes sense, either solves the problem. Implement both, look at code complexity? (I'd expect it to be roughly equal, but one sometimes has surprises.) -- Juliusz From nobody Tue Jun 20 12:20:44 2017 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 4C50A131608 for ; Tue, 20 Jun 2017 12:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 RM4atqGvDFPd for ; Tue, 20 Jun 2017 12:20: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 CCAD5126CD6 for ; Tue, 20 Jun 2017 12:20: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/56228) with ESMTP id v5KJKa3F027725; Tue, 20 Jun 2017 21:20:36 +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 339D7EB2FC; Tue, 20 Jun 2017 21:20:36 +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 hGXHKus9MIeP; Tue, 20 Jun 2017 21:20:35 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1F5F9EB2CC; Tue, 20 Jun 2017 21:20:35 +0200 (CEST) Date: Tue, 20 Jun 2017 21:20:34 +0200 Message-ID: <87vanqtqil.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , Babel at IETF In-Reply-To: <9EE24349-90A8-4855-A572-13C06C7D85D7@apple.com> References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> <87y3ss5nlg.fsf@alrua-x1> <87tw3fwjtt.wl-jch@irif.fr> <5CD7F43D-2FC0-4466-AFDE-FD968D9CC158@apple.com> <8760fr5bsl.fsf@alrua-x1> <87r2yesv62.wl-jch@irif.fr> <9EE24349-90A8-4855-A572-13C06C7D85D7@apple.com> 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, 20 Jun 2017 21:20:37 +0200 (CEST) X-Miltered: at korolev with ID 59497584.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59497584.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 : 59497584.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] Unscheduled Hellos X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 19:20:43 -0000 > Does someone see other upsides to (1) or downsides to (2) that I'm missing? The spec is somewhat simpler if unscheduled Hellos increment seqno -- it removes a lot of special-casing in your text. (Not a conclusive argument, IMHO, but a strong argument nonetheless.) -- Juliusz From nobody Tue Jun 20 12:30:41 2017 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 EAC8F129470 for ; Tue, 20 Jun 2017 12:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Q0Pu-xsf6yF7 for ; Tue, 20 Jun 2017 12:30:38 -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 1B62A128B93 for ; Tue, 20 Jun 2017 12:30:37 -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/56228) with ESMTP id v5KJUYT0029991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Jun 2017 21:30:34 +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/56228) with ESMTP id v5KJUXkT027522; Tue, 20 Jun 2017 21:30:34 +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 EE064EB2F0; Tue, 20 Jun 2017 21:30:33 +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 WhJ6DXFsmWEa; Tue, 20 Jun 2017 21:30:32 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A1061EB2D0; Tue, 20 Jun 2017 21:30:32 +0200 (CEST) Date: Tue, 20 Jun 2017 21:30:32 +0200 Message-ID: <87shiutq1z.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Babel at IETF In-Reply-To: <5CD7F43D-2FC0-4466-AFDE-FD968D9CC158@apple.com> References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> <87y3ss5nlg.fsf@alrua-x1> <87tw3fwjtt.wl-jch@irif.fr> <5CD7F43D-2FC0-4466-AFDE-FD968D9CC158@apple.com> 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, 20 Jun 2017 21:30:34 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 20 Jun 2017 21:30:34 +0200 (CEST) X-Miltered: at korolev with ID 594977DA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 594977D9.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 594977DA.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 594977D9.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 : 594977DA.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 594977D9.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] Unscheduled Hellos [was: Cutoff date for rfc6126bis is 3 July] X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 19:30:40 -0000 > I tried to incorporate it into my pull request: > https://github.com/jech/babel-drafts/pull/3/files > Let me know what you think. Rather than "Periodic Hello", I'm going to use "Scheduled Hello". This is consistent with Updates, and doesn't imply that jitter is illegal. I'm sorely tempted to keep the seqno in unscheduled Hellos, since it makes the text simpler. We can remove them later when we have implementation experience. It is always legal to send a scheduled Hello ahead of schedule -- the protocol explicitly allows varying the Hello interval. Unscheduled Hellos are only really useful for implementations that never send scheduled Hellos of a given kind. The way to deal with Unscheduled Hellos for link-quality estimation should not be normative -- the only normative condition is that a link that has not received a Hello recently (of any kind) has infinite cost. The term "link-quality" should not appear in the normative part of the document. I'm going to redo Appendix A, since I disagree with much of your advice. Ok? -- Juliusz From nobody Tue Jun 20 13:13:16 2017 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 8FE9913153E for ; Tue, 20 Jun 2017 13:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPV-_W1SKtp8 for ; Tue, 20 Jun 2017 13:13:13 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 8F512129BA2 for ; Tue, 20 Jun 2017 13:13:13 -0700 (PDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1497989586; bh=1LwVxxyq8KkYSQ0wLr0/PJDYOm/+daH3gbshaw4XWPw=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=e7+uq3/if/ikPPTi9RpVa1Be4RQ6W0toqZu4QB8WmHyTtlDt3pPsbtncPfal37J+x p/9/HaZ9Xn7mL6QQr33pHN1B/5fURf00b+LyqUAfb/OoS96Q3QDcLyezvzJyJ8QH2+ VYORxNdYtpgyc/MbvFyWTnTrAYvCEj/jDamlUgc/aeGiD6FylDSlUIUpSBR4piD23m lQsGPdSV/8Y7g0VfHpKeeF3gxxTgDBQllJykvKYy+R36mfWsNjUOsj8G0yvnye+prw 7j2pKYBBjzIz8SXHJKSmU3TL0QmKXOvUAi7GN+5BAOPMVkJ/AKJavSuT5XhkBqin0X OL79O/22mM4TA== To: Juliusz Chroboczek Cc: David Schinazi , Babel at IETF References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> <87y3ss5nlg.fsf@alrua-x1> <87tw3fwjtt.wl-jch@irif.fr> <5CD7F43D-2FC0-4466-AFDE-FD968D9CC158@apple.com> <8760fr5bsl.fsf@alrua-x1> <87r2yesv62.wl-jch@irif.fr> <9EE24349-90A8-4855-A572-13C06C7D85D7@apple.com> <87vanqtqil.wl-jch@irif.fr> Date: Tue, 20 Jun 2017 22:13:04 +0200 In-Reply-To: <87vanqtqil.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Tue, 20 Jun 2017 21:20:34 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87wp864dv3.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Unscheduled Hellos X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 20:13:16 -0000 Juliusz Chroboczek writes: >> Does someone see other upsides to (1) or downsides to (2) that I'm missing? > > The spec is somewhat simpler if unscheduled Hellos increment seqno -- it > removes a lot of special-casing in your text. (Not a conclusive argument, > IMHO, but a strong argument nonetheless.) I agree. And I don't think the downside to being unable to distinguish between the two types of loss is that big; I mean, a packet loss is a packet loss. Do we really need the interval=0 spec? I mean if you send a hello at T=0 promising to send another at T=4, and then decide to send an unscheduled one at T=2, couldn't you just use the remaining time (2 in this case) as the interval? Or is that too complicated to implement (depends on the timer implementation, I guess)? -Toke From nobody Tue Jun 20 13:33:18 2017 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 51307131636 for ; Tue, 20 Jun 2017 13:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 StbbBUXcYEIk for ; Tue, 20 Jun 2017 13:33:15 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 0B029128954 for ; Tue, 20 Jun 2017 13:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497990794; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XY/EsF10xvLkapX7afLF5sBMMXDgw6NdFoxNu4xxKxs=; b=PaU4IiZ/127f/bNerRVEKD5g3vDlPZ83XHwpdeqU/Ys2KRhsCeWTX6FwwjjaqhuU kr3phTuUzce8oymvbUH9KT6Jootmkw/4XXQqNa6GPEmv4ryfpCSJjqpWf6hVMcGU PpdZif0m/x1LDGXeqVH2r8SVGyq3ykPoZgu2+frKHk6/YYBEzQUfbm8h87WW9EJN Fk9RLEISbqlbHf9cs6kRUDZHnuMRm/uztbnZYqLi3+U+ls4ggLHTVSneHYn1kPvJ hgPt+9vE/Y2tZkVTkk1+ni0w8s+J6rG/niDq2qp58Lqzxnv5bys9lA8TTKY6KU0Q hJJrKUJvhgIVZ7zXYlwWbw==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id F7.07.01595.A8689495; Tue, 20 Jun 2017 13:33:14 -0700 (PDT) X-AuditID: 11973e13-caa429a00000063b-fd-5949868a0022 Received: from jimbu (jimbu.apple.com [17.151.62.37]) by relay3.apple.com (Apple SCV relay) with SMTP id CA.CE.04862.A8689495; Tue, 20 Jun 2017 13:33:14 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.234.89.32] (unknown [17.234.89.32]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORV000CA53EN840@jimbu.apple.com>; Tue, 20 Jun 2017 13:33:14 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <874lvav75c.wl-jch@irif.fr> Date: Tue, 20 Jun 2017 13:33:14 -0700 Cc: babel-users@lists.alioth.debian.org, babel@ietf.org Message-id: References: <87podystsb.wl-jch@irif.fr> <87h8zasrvk.wl-jch@irif.fr> <874lvav75c.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUi2FAYrNvV5hlp8PqNtsXXzw0sFlsWdbNY zG9dxubA7LFkyU8mj8Vb3jJ6vDnUxxLAHMVlk5Kak1mWWqRvl8CV0X/+MXvBD8aKR6tfsDcw 7mPsYuTkkBAwkdiy4xpTFyMXh5DAaiaJpY93scEkZk66wQaRWMYosef6bRaQBK+AoMSPyfeA bA4OZgF5iYPnZUHCzAJaEt8ftbJA1P9llOj8c5cZJCEsIC3RdeEuK4RdJPF69jJ2kF42oIYD a4xAwpwCGhIzj54BK2cRUJX4fnM5I8RMc4nTR5cxQ6y1kfg8dRozxPxJjBI/3+8BKxIRUJFY Pu0ZO8TRshK3Zl8CK5IQmMAmceLwRuYJjMKzkNw9C+HuWUjuXsDIvIpRKDcxM0c3M89UL7Gg ICdVLzk/dxMjKNyn2wnvYDy9yuoQowAHoxIPb4SyZ6QQa2JZcWXuIUZpDhYlcd7cGo9IIYH0 xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyezuGz/z6db+l2o/+Ch/w847PFFkLPb/jdjVFtvTZh 3kMvwf5tVSuOsuquX+xtmXLp45N1lirpCcszvx0rz7OMOeNWfLyr7Y1yz/rEgk3T645e1Sq4 mWE/YWtdq/jE5eF3bh7v2im//dhTsVwBrrwAmeeNixXmt9l5X7n6eG/m6pk7bFsyL6QqsRRn JBpqMRcVJwIA/VCOZ1gCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUiON1OVberzTPS4OMhJYuvnxtYLLYs6max mN+6jM2B2WPJkp9MHou3vGX0eHOojyWAOYrLJiU1J7MstUjfLoEro//8Y/aCH4wVj1a/YG9g 3MfYxcjJISFgIjFz0g22LkYuDiGBZYwSe67fZgFJ8AoISvyYfA/I5uBgFpCXOHheFiTMLKAl 8f1RKwtE/V9Gic4/d5lBEsIC0hJdF+6yQthFEq9nL2MH6WUDajiwxggkzCmgITHz6BmwchYB VYnvN5czQsw0lzh9dBkzxFobic9TpzFDzJ/EKPHz/R6wIhEBFYnl056xQxwtK3Fr9iXmCYwC s5CcOgvh1FlITl3AyLyKUaAoNSex0lgvsaAgJ1UvOT93EyMoPBsKg3cw/llmdYhRgINRiYeX QdEzUog1say4MvcQowQHs5IIr1wcUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvnCkekUIC6Ykl qdmpqQWpRTBZJg5OqQbGxYsNNm+0n8ozKcCzMz5kWVntVP9Ze4WLvQ45V+3eNSdn4b3tl865 p1z/41H2ONBJ7UbSjVVZ33z3FpUerG3nUT26d27vgSCR+rzJEV5xPQbP9J8VFeskB1+QNVu1 7np20RNVHocLfI8nzaxRqJK++jBDuUdtdqzfk5a03wdtw7d/1tT3/bJYiaU4I9FQi7moOBEA BlB9jUsCAAA= Archived-At: Subject: Re: [babel] [Babel-users] Unscheduled Unicast Hellos: some background on 802.11 link quality estimation X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 20:33:16 -0000 > On Jun 20, 2017, at 11:35, Juliusz Chroboczek wrote: > >> Can you provide text? > > Yes, I will do. Please focus on specifying the on-the-wire bits, I'll > take care of the appendix. Sounds good to me. David Schinazi From nobody Tue Jun 20 13:37:39 2017 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 1698D128954 for ; Tue, 20 Jun 2017 13:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 49wDmgCUaQjM for ; Tue, 20 Jun 2017 13:37:36 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 BD591129494 for ; Tue, 20 Jun 2017 13:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497991056; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=E0k9UdXfUpareFINmgu+cay8VVqsuXs4260oUpJAtlk=; b=ZDwiJeVnEcEX1HVjFdkQLAgLwFR7MKOhPuOu3reAPRvVl7caGcrrM4WC+4AieY+4 nPXmrY+p0K1FIGP4o322riulfWiW688pEAnxeGVAeU9eAnaEcWJAR4d7FZZobtHR njFD/LhJkR23yV4bIUDYwSZdZq8ucFadHierHjGGUSF/p0Mn9UMTsJC7nnRqWdNC BDt6ydNaYggr/RoBSeNQQS923iRNJPaTTXnGD90xkhO4hhwlyFjdADAdFuRAGoeV keQN6lGLZztXwOCtQJscyw5yBOsCVfj0V5xeTYDM/rvyZwcyk0Ljoyom3imTwgjV NJPxXDDIMKMHk43n/gwiLQ==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 6F.92.07949.09789495; Tue, 20 Jun 2017 13:37:36 -0700 (PDT) X-AuditID: 11973e16-0c7789a000001f0d-e7-59498790b223 Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay5.apple.com (Apple SCV relay) with SMTP id 2D.5E.09344.09789495; Tue, 20 Jun 2017 13:37:36 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.234.89.32] (unknown [17.234.89.32]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORV00FH05ADUL40@nwk-phonehomebzp-sz01.apple.com>; Tue, 20 Jun 2017 13:37:35 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87wp864dv3.fsf@alrua-x1> Date: Tue, 20 Jun 2017 13:37:25 -0700 Cc: Juliusz Chroboczek , Babel at IETF Content-transfer-encoding: quoted-printable Message-id: <4F3EF1D6-A92A-40D5-BF2F-C8B34A5B57C0@apple.com> References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> <87y3ss5nlg.fsf@alrua-x1> <87tw3fwjtt.wl-jch@irif.fr> <5CD7F43D-2FC0-4466-AFDE-FD968D9CC158@apple.com> <8760fr5bsl.fsf@alrua-x1> <87r2yesv62.wl-jch@irif.fr> <9EE24349-90A8-4855-A572-13C06C7D85D7@apple.com> <87vanqtqil.wl-jch@irif.fr> <87wp864dv3.fsf@alrua-x1> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUi2FAYoTuh3TPSYPIaSYsti7pZLOa3LmOz 2Pp+BbsDs8eSJT+ZPBZvecvoseXQRbYA5igum5TUnMyy1CJ9uwSujMcvfjEVLGOt2PFhEUsD 4wyWLkZODgkBE4lHq1czdzFycQgJrGaSWHlsGhtMYu6TPhaIxDFGiZnnJjKCJHgFBCV+TL4H lODgYBZQl5gyJReiZj6TxKW365lBaoQFpCW6LtxlhbDVJXa+n8AKUs8moCVxYI0RSJhTQE3i 9e0GsBIWAVWJl8vfgu1lFnCR2Hx9AyuErS3x5N0FVoi1NhIds7eyQ+x6zSLxbutGdpCEiIC9 ROPXC1DfyErcmn2JGcLuYZP4uj1qAqPwLCRnz0I4exaSFQsYmVcxCuUmZuboZuaZ6yUWFOSk 6iXn525iBAX7dDuxHYwPV1kdYhTgYFTi4Y1Q9owUYk0sK67MPcQozcGiJM6bU+MRKSSQnliS mp2aWpBaFF9UmpNafIiRiYNTqoGR45bwyQ3yr43unYvu/pJ+6Kky88LcoMbGvxOt6qVtmb4e 3bU8wq/rx8Rt7SlZpw5tObRoH+vLuxonQhxvXX7wVqYzbvZGPa21sudlDr0/emkan+L97sro +QxRLKafcuWkQ4SYNq590JtTzODQJR/G0KKjLpTF2Vv3tfzuD9t1P+v4gkUXz5qlxFKckWio xVxUnAgAJeobJVcCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUiON3OQXdCu2ekwd55whZbFnWzWMxvXcZm sfX9CnYHZo8lS34yeSze8pbRY8uhi2wBzFFcNimpOZllqUX6dglcGY9f/GIqWMZasePDIpYG xhksXYycHBICJhJzn/QB2VwcQgLHGCVmnpvICJLgFRCU+DH5HlCCg4NZQF1iypRciJr5TBKX 3q5nBqkRFpCW6LpwlxXCVpfY+X4CK0g9m4CWxIE1RiBhTgE1ide3G8BKWARUJV4uf8sGYjML uEhsvr6BFcLWlnjy7gIrxFobiY7ZW9khdr1mkXi3dSM7SEJEwF6i8esFqKNlJW7NvsQ8gVFg FpJTZyGcOgvJ2AWMzKsYBYpScxIrTfUSCwpyUvWS83M3MYLCs6EwYgfj/2VWhxgFOBiVeHgZ FD0jhVgTy4orcw8xSnAwK4nwysUBhXhTEiurUovy44tKc1KLDzFKc7AoifPOm+IRKSSQnliS mp2aWpBaBJNl4uCUamC02uqq/Fs/dtEZn1r9jmjJ7+U5F895snVImrF1S2V0+1xmaUv7dexy WRO73fqeFf0MLjOfv+tp0Pje+k5c5Z/NX+mz4r3q5y6dU+A3y2jnz5jnuiO05rGGV0ysVuVi xZ9nHOOvat+b9nKm2mvvuXu9MivP3bN568AsteVgB8+86CLRxlXSrkosxRmJhlrMRcWJADw2 wThLAgAA Archived-At: Subject: Re: [babel] Unscheduled Hellos X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 20:37:38 -0000 > On Jun 20, 2017, at 13:13, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Do we really need the interval=3D0 spec? I mean if you send a hello at = T=3D0 > promising to send another at T=3D4, and then decide to send an = unscheduled > one at T=3D2, couldn't you just use the remaining time (2 in this = case) as > the interval? Or is that too complicated to implement (depends on the > timer implementation, I guess)? That may cause inefficiencies because if I receive your Hello at T=3D2 = with I=3D2 and then don't hear anything until T=3D21 then I'll think I missed 9 = Hellos whereas in reality I only missed 5 Hellos. David Schinazi= From nobody Tue Jun 20 13:41:16 2017 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 9F02C1294B8 for ; Tue, 20 Jun 2017 13:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 GrpS5Nj_310n for ; Tue, 20 Jun 2017 13:41:12 -0700 (PDT) Received: from gna.vfn-nrw.de (gna.vfn-nrw.de [62.141.34.117]) (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 39C87131633 for ; Tue, 20 Jun 2017 13:41:11 -0700 (PDT) Received: from authenticated-user (unknown [::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ruben@vfn-nrw.de) by gna.vfn-nrw.de (Postfix) with ESMTPSA id 289F01610AF; Tue, 20 Jun 2017 22:41:08 +0200 (CEST) Content-Type: multipart/signed; boundary=Apple-Mail-F99B7E32-A87E-4E9E-A2D7-7464C01621D3; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Ruben In-Reply-To: <87podystsb.wl-jch@irif.fr> Date: Tue, 20 Jun 2017 22:41:06 +0200 Cc: babel@ietf.org, babel-users@lists.alioth.debian.org Content-Transfer-Encoding: 7bit Message-Id: <0F1E4094-C782-45C1-8E95-A466F8F17FF4@vfn-nrw.de> References: <87podystsb.wl-jch@irif.fr> To: Juliusz Chroboczek X-Virus-Scanned: clamav-milter 0.99.2 at gna.vfn-nrw.de X-Virus-Status: Clean Archived-At: Subject: Re: [babel] [Babel-users] Unscheduled Unicast Hellos: some background on 802.11 link quality estimation X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 20:41:15 -0000 --Apple-Mail-F99B7E32-A87E-4E9E-A2D7-7464C01621D3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hello Juliusz, > Am 20.06.2017 um 14:55 schrieb Juliusz Chroboczek : >=20 > 2. 802.11 uses adaptative rate control on unicast frames, but not on > multicast frames. This is not entirely true, since hostapd is able to send multicast as unicas= t-frames. Best regards=20 Ruben= --Apple-Mail-F99B7E32-A87E-4E9E-A2D7-7464C01621D3 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFPDCCBTgw ggQgoAMCAQICEQCRaWia1ifWCTZrmH1t+u7nMA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTcwNDA0MDAwMDAwWhcNMTgwNDA0MjM1 OTU5WjAhMR8wHQYJKoZIhvcNAQkBFhBydWJlbkB2Zm4tbnJ3LmRlMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEApFiHMuCR46zQEVa4cOJ/qux0nUrk5yMn8/8sMrceVvqWmYoD+Y+f5aWd VAFVjEuQgFnoW7sgd+zcjOvsbg2q9bQwGWAyvXwtbsYw8EjCKb05SWpQyL4dUnGK387QYIBj5nQV FsVcIht0z47eaY3E3KgGmUs2MojIKmg5rploY7Ao54FTUPAxQg1/Ky63TOmTZIcPkWfFskvMlGuB /gd6gEYGivD7g5J8HL8jTUNhdLifamtO8wJODzA319SeWUksY+GU7ZuBHSFbqRAWya03SX8PD/ug noXLXcAEFe66OSTfZWH7UNQMPAEJtmIziiuykGqudvafYpaguwqbDXZQTQIDAQABo4IB7jCCAeow HwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFLxdRkcjp8chjUbk51O0 b6HBC7JZMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwME BgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIB AQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYDVR0fBFYw VDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYIKwYBBQUH MAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh LmNvbTAbBgNVHREEFDASgRBydWJlbkB2Zm4tbnJ3LmRlMA0GCSqGSIb3DQEBCwUAA4IBAQAZdeXU wvhpOs4CABXRfSQNpZfXRyaj6wHz/eSnjxANognUccLdrVmqvxzZe7Q7Twell1r9LJgAdSdx8/O1 Cw04N0pPtG3D1iZPyJoptDIGUoAjWgb2m7Xnft5K5/i7tTR7mH5j3Ws2/lbM5rvPjY7dGch/l7IG +Wg2uRWVG1CNYMViW/h2i0x8pPB5Sfcs/htulYsbZXYEoahXDmnWb5qywiVUZnFFteV95UCj31Ti iqv7st4t/vcM8r5tibAoHddFLfsqbgIRk7r6poCW7twfpF4awYqboy1okqiws1ihgil6tOAcUxAc HsKQ0ecCthQvy6SGzbDdg5O1xWjlYOp3MYIDxjCCA8ICAQEwgbEwgZsxCzAJBgNVBAYTAkdCMRsw GQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJFpaJrWJ9YJNmuYfW367ucwCQYFKw4DAhoFAKCC AekwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNjIwMjA0MTA2 WjAjBgkqhkiG9w0BCQQxFgQUM1Edfg+iKp2JbYqWWcmQ+7LmQuMwgcIGCSsGAQQBgjcQBDGBtDCB sTCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMH U2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEt MjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkWlomtYn1gk2 a5h9bfru5zCBxAYLKoZIhvcNAQkQAgsxgbSggbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5k IFNlY3VyZSBFbWFpbCBDQQIRAJFpaJrWJ9YJNmuYfW367ucwDQYJKoZIhvcNAQEBBQAEggEAnndB ronTjvFu+CKLbPvecXiP5b3yxV0yAvQZ5aLpYphOWWNEmjUYhlUAM4clm8OO8vAevpaZwsXT4vFQ zH65tlkbv8d7qUzQZqbB+x3rIrrzA2YVI0UlDDgI2dc+zkFgnf0nImhjBfHbYUlYz44stcLXd5DP H3sIIMpISCrNOX5mZ+/85FW5PMGyofmcaDgZmTddL/Z2gqvlq5Tq76WfWpQEMnynivEPn6SyD8k2 u9HM1zT4IKdApEorNIh34PI2O/jgmqrFW47U4wHlwPogzTj1UZE5KrGSgCxvYdFVOPTMdolrE4VV CAZEHTNre8Y6vaCC3b6pbLMv7MRmbT1qcgAAAAAAAA== --Apple-Mail-F99B7E32-A87E-4E9E-A2D7-7464C01621D3-- From nobody Tue Jun 20 14:14:57 2017 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 5A5CB1294DC for ; Tue, 20 Jun 2017 14:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 g3AkzF_G33Gh for ; Tue, 20 Jun 2017 14:14:54 -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 4EB76129486 for ; Tue, 20 Jun 2017 14:14:54 -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/56228) with ESMTP id v5KLEocb020257; Tue, 20 Jun 2017 23:14: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 5C330EB342; Tue, 20 Jun 2017 23:14: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 2VZWUAtlT86c; Tue, 20 Jun 2017 23:14:49 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D3FB6EB2F0; Tue, 20 Jun 2017 23:14:48 +0200 (CEST) Date: Tue, 20 Jun 2017 23:14:48 +0200 Message-ID: <87mv92tl87.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: David Schinazi , Babel at IETF In-Reply-To: <87wp864dv3.fsf@alrua-x1> References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> <87y3ss5nlg.fsf@alrua-x1> <87tw3fwjtt.wl-jch@irif.fr> <5CD7F43D-2FC0-4466-AFDE-FD968D9CC158@apple.com> <8760fr5bsl.fsf@alrua-x1> <87r2yesv62.wl-jch@irif.fr> <9EE24349-90A8-4855-A572-13C06C7D85D7@apple.com> <87vanqtqil.wl-jch@irif.fr> <87wp864dv3.fsf@alrua-x1> 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, 20 Jun 2017 23:14:50 +0200 (CEST) X-Miltered: at korolev with ID 5949904A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5949904A.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 : 5949904A.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] Unscheduled Hellos X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 21:14:56 -0000 > Do we really need the interval=0 spec? I mean if you send a hello at T=0 > promising to send another at T=4, and then decide to send an unscheduled > one at T=2, couldn't you just use the remaining time (2 in this case) as > the interval? Or is that too complicated to implement (depends on the > timer implementation, I guess)? It's much simpler than that. If you're sending every 4 seconds and then decide to send a Hello at t=2, you just send it with interval=4. Then you reschedule the next Hello to be sent at t=6 instead of t=4, and you've resynchronised. And if the Hello at t=2 is lost, you'll still detect the loss, just two seconds late. And even if you f*ck up (e.g. by failing to reschedule), it doesn't matter, since the Hello history will resynchronise the next time you get a seqno (check the "undoing history" bit in Appendix A), and your hysteresis algorithm will swallow the short-lived variation in link quality. The case I'm concerned about is that of an implementation that only sends scheduled Hellos of a given kind but occasionally needs to send a Hello of the other kind. For example, an implementation only sends Multicast Hellos, but then at some point decides to send a Timestamp sub-TLV over unicast, which needs to be attached to a Hello. If it sends a normal Unicast Hello, then the peer might start doing accounting of Unicast Hellos, and spuriously detect loss when the Interval expires. Attaching the sub-TLV to an unscheduled Hello avoids the spurious variation in link quality. Conversely, consider an implementation that usually sends Unicast Hellos, but sends a bunch of unscheduled Multicast Hellos when the link layer indicates that a new station has joined the BSS (or when it receives an ICMPv6 packet from a new IP, or when MARS indicates that a new node has joined the Emulated LAN, or whatever). Since the link-layer event is unpredictable, there is no way to choose a good interval for Multicast Hellos, and sending a non-zero Interval might cause peers to start doing link-quality estimation using Multicast Hellos. Folks, I'd really like to avoid the need for Interval=0. If you can find a good way to implement the two use cases above with the existing mecha- nisms, I'll be thrilled. On the other hand, Interval=0 is just a small amount of spec (don't reset the timer when Interval=0, and don't tweak the Hello history), and a very small amount of code, so we might as well go for it. -- Juliusz From nobody Tue Jun 20 15:06:45 2017 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 812BF128A32 for ; Tue, 20 Jun 2017 15:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 gEeBMwHT6e1j for ; Tue, 20 Jun 2017 15:06:40 -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 D4A12127B52 for ; Tue, 20 Jun 2017 15:06:39 -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/56228) with ESMTP id v5KM6cO5029223; Wed, 21 Jun 2017 00:06: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 09B20EB2F8; Wed, 21 Jun 2017 00:06: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 yGQw958efgbg; Wed, 21 Jun 2017 00:06:35 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C8573EB2CC; Wed, 21 Jun 2017 00:06:33 +0200 (CEST) Date: Wed, 21 Jun 2017 00:06:33 +0200 Message-ID: <87h8zatity.wl-jch@irif.fr> From: Juliusz Chroboczek To: Ruben Cc: babel@ietf.org, babel-users@lists.alioth.debian.org In-Reply-To: <0F1E4094-C782-45C1-8E95-A466F8F17FF4@vfn-nrw.de> References: <87podystsb.wl-jch@irif.fr> <0F1E4094-C782-45C1-8E95-A466F8F17FF4@vfn-nrw.de> 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, 21 Jun 2017 00:06:38 +0200 (CEST) X-Miltered: at korolev with ID 59499C6E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59499C6E.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 : 59499C6E.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] [Babel-users] Unscheduled Unicast Hellos: some background on 802.11 link quality estimation X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 22:06:42 -0000 >> 2. 802.11 uses adaptative rate control on unicast frames, but not on >> multicast frames. > This is not entirely true, since hostapd is able to send multicast as > unicast-frames. And this will cause Babel's link-quality estimation to yield incorrect values. Dynamically computed metrics are an open area of research, and one that is sadly neglected by the scientific community. I believe that it is important, but it is very difficult to publish in that area (FWIW, our paper about the RTT metric was rejected twice). ETX is an elegant hack that uses the fact that 802.11 multicast isn't subject to ARQ. As you justly note, Ruben, this assumption can fail in edge cases, and there's nothing that can be done about it. The obvious solution would be to have explicit cross-layer signalling, as in the case of Lamparter's variant of IS-IS. Doing that right is not easy, and might (or might not) require changes to the link-layer. I'm personally interested in that area of research, and I'll probably have a fair amount of funding in the near future. However, since the area is not fashionable, I cannot promise that we'll be able to publish. -- Juliusz From nobody Tue Jun 20 15:55:52 2017 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 3DC611294C8 for ; Tue, 20 Jun 2017 15:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 O-RTCC88M30e for ; Tue, 20 Jun 2017 15:55:47 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 C8AFD126C0F for ; Tue, 20 Jun 2017 15:55:46 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id c11so55240980wrc.3 for ; Tue, 20 Jun 2017 15:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aisE06ep+qjkdAeW6Hsz6qYDk5OAEGu/1Rr6N8v7ZZ0=; b=sn3sBpketn2ELwMSX1bZqGRfOqM+DRwSu8jeit+3i6141j+ZNURk2txbtPxBL710zy zHLEpScYZGrENWG8uX031TeHCQx+JshSi3Q1iD3H/3xPpJTkWpIiomKJS9mDvfD2Qdfa mqiOVK23ZjEJLMxTE2xmdsNnU5J7LEPx7U0FEHYW05t9I5sbBA6+F3oc1/1HhsaXIdeI LW+XcqD76p7RSMNjOWJNoWNCziND4ktZufrpTIvzHi/sKEVpGVKZE1ueskLk+2Jpb8nR qJPDf/9AetxnPm0A79eR3ZjLCEyEjiMrif44NS2ZfAoD+2PIUjaiqaa9qRVbGVALTeJP G96A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aisE06ep+qjkdAeW6Hsz6qYDk5OAEGu/1Rr6N8v7ZZ0=; b=T3uMcKNByrHjkhObEE4IBS9BDhhNRxO8ku9SyWmrDlEMnhibEBzvYS8Ql4Eldmrmec UrCVrTQmcx4A9QqWmuCJV7DjDm9Qy+xJlptwTUfnnbkAhhfi3DE6J1ePN5Fcz+5PouDq oPuBWXnFF1Vl4ay2m72bX3egxLAP3YebEfJOgqlss8yD7gIeuPnzeCJY8K+JjG6xwn+L 6lOI99uuk6XBc+7Gcjwu2uN+hd3+210hSZU2/7ZRBkL3XMqA6+1aUB+eGZ9uA0ODHtw9 brIVLXbYQltLeTcp388HSVC8o9W2+HrtTnxL79TjhRFtzzBgwVJ8tvR8uxlC3sTkNYne Oqrg== X-Gm-Message-State: AKS2vOyNuKclfSXK9WKfZLXcPwNDDKjpJindgLFrDXLZxEzSY8kAm7Sj u5XyRAF035wrNWhLua2MbZ9S2G4WlQ== X-Received: by 10.28.132.210 with SMTP id g201mr4519464wmd.26.1497999345325; Tue, 20 Jun 2017 15:55:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.134.189 with HTTP; Tue, 20 Jun 2017 15:55:44 -0700 (PDT) In-Reply-To: <87h8zatity.wl-jch@irif.fr> References: <87podystsb.wl-jch@irif.fr> <0F1E4094-C782-45C1-8E95-A466F8F17FF4@vfn-nrw.de> <87h8zatity.wl-jch@irif.fr> From: Jehan Tremback Date: Tue, 20 Jun 2017 15:55:44 -0700 Message-ID: To: Juliusz Chroboczek Cc: Ruben , babel-users@lists.alioth.debian.org, babel@ietf.org Content-Type: multipart/alternative; boundary="001a11441ffcda1c3005526c2684" Archived-At: Subject: Re: [babel] [Babel-users] Unscheduled Unicast Hellos: some background on 802.11 link quality estimation X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 22:55:49 -0000 --001a11441ffcda1c3005526c2684 Content-Type: text/plain; charset="UTF-8" I'm wondering... what if, in the hypothetical routing protocol "Babble", one got rid of multicast hellos and ETX entirely, and routed using RTT measured by unicast hellos. Wouldn't this take delays from ARQ'ed packet loss into account have results somehow similar to ETX? On Tue, Jun 20, 2017 at 3:06 PM, Juliusz Chroboczek wrote: > >> 2. 802.11 uses adaptative rate control on unicast frames, but not on > >> multicast frames. > > > This is not entirely true, since hostapd is able to send multicast as > > unicast-frames. > > And this will cause Babel's link-quality estimation to yield incorrect > values. > > Dynamically computed metrics are an open area of research, and one that is > sadly neglected by the scientific community. I believe that it is > important, but it is very difficult to publish in that area (FWIW, our > paper about the RTT metric was rejected twice). > > ETX is an elegant hack that uses the fact that 802.11 multicast isn't > subject to ARQ. As you justly note, Ruben, this assumption can fail in > edge cases, and there's nothing that can be done about it. The obvious > solution would be to have explicit cross-layer signalling, as in the case > of Lamparter's variant of IS-IS. Doing that right is not easy, and might > (or might not) require changes to the link-layer. > > I'm personally interested in that area of research, and I'll probably have > a fair amount of funding in the near future. However, since the area is > not fashionable, I cannot promise that we'll be able to publish. > > -- Juliusz > > _______________________________________________ > Babel-users mailing list > Babel-users@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users > --001a11441ffcda1c3005526c2684 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm wondering... what if, in the hypothetical routing = protocol "Babble", one got rid of multicast hellos and ETX entire= ly, and routed using RTT measured by unicast hellos. Wouldn't this take= delays from ARQ'ed packet loss into account have results somehow simil= ar to ETX?

O= n Tue, Jun 20, 2017 at 3:06 PM, Juliusz Chroboczek <jch@irif.fr> w= rote:
>> 2. 802.11= uses adaptative rate control on unicast frames, but not on
>> multicast frames.

> This is not entirely true, since hostapd is able to send multicast as<= br> > unicast-frames.

And this will cause Babel's link-quality estimation to yield inc= orrect values.

Dynamically computed metrics are an open area of research, and one that is<= br> sadly neglected by the scientific community.=C2=A0 I believe that it is
important, but it is very difficult to publish in that area (FWIW, our
paper about the RTT metric was rejected twice).

ETX is an elegant hack that uses the fact that 802.11 multicast isn't subject to ARQ.=C2=A0 As you justly note, Ruben, this assumption can fail i= n
edge cases, and there's nothing that can be done about it.=C2=A0 The ob= vious
solution would be to have explicit cross-layer signalling, as in the case of Lamparter's variant of IS-IS.=C2=A0 Doing that right is not easy, an= d might
(or might not) require changes to the link-layer.

I'm personally interested in that area of research, and I'll probab= ly have
a fair amount of funding in the near future.=C2=A0 However, since the area = is
not fashionable, I cannot promise that we'll be able to publish.

-- Juliusz

_______________________________________________
Babel-users mailing list
Babel-users@lists.al= ioth.debian.org
http://lists.alioth.debian.o= rg/cgi-bin/mailman/listinfo/babel-users

--001a11441ffcda1c3005526c2684-- From nobody Tue Jun 20 16:01:36 2017 Return-Path: <7riw77@gmail.com> 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 9F5641200FC for ; Tue, 20 Jun 2017 16:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Fe7ZAMsqQtbT for ; Tue, 20 Jun 2017 16:01:34 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 0775B1293EE for ; Tue, 20 Jun 2017 16:01:34 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id m62so22927290itc.0 for ; Tue, 20 Jun 2017 16:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=Tx7/PPSme1UQj/Fg6SXRxymEu9icoLPQ47DDrYaiY00=; b=IW9vCSLW6aIdqff+OV6K19p/a3153AnM8HEBVcKh1aSqa4m/xb6r4UYAg7QEt9QG2u peD6tTv8pEr4K6FJKorSweaI14sl4iuMoBwrwDvUZTQfIVVPUh9hIvJHUG4UNr8J60ny kbvH81Gd2YOMhtYbTzRQb93prYsRLDs28QxJDhMnyeRBZUV1KDzaz8fU8W5M6a93c74M ZnDch/153c+So8p+kgSJDyxD0qB/VLBNFBE0sHqMI0GM6bjGrHbI9rHznhNSiWbGL54U 9zSz7kvckl4rEsP8eNMRq5yS45pwTxl++Zmn7PH7ah4w976FAFzPCO/SGBVLduEyBKVG rOBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Tx7/PPSme1UQj/Fg6SXRxymEu9icoLPQ47DDrYaiY00=; b=q9tel7GLxfrXRtk7hzCTEEGCjB4BY17DhDvg919hrE15uXrYytsNz/mL+f1nBwWgnd +aP1rZNXXcQz/a/OOuznd3u4cv38CdwtDKNZoFquSwtuAp/im97OUJkVp5JPVlq+Suqm rw77knFPG+UwZ6NLDD74I7FCkG/aCoP57imD3PGwgs8kGRnQztp59m26pr2ltlAGactL USG5N9zw51SExSYD9FlweilnADDtHXKX0unK4Itlffo/2f1ylOXHJ4aU4eeFyvFVLu5R aLUoujhYiHHr1E0REw9xPhj85QBBy/yFo2bNpVDnN1EXSZPIyFHTYaEuNRW3krSR1NZJ n2PA== X-Gm-Message-State: AKS2vOxuRHpIpSwFUjUCjJLE1+Ot3up90kOL+qtX4+uwzdywrmwc7U5v q6DJF2vBeR+QJv6O X-Received: by 10.36.67.211 with SMTP id s202mr5946555itb.48.1497999693179; Tue, 20 Jun 2017 16:01:33 -0700 (PDT) Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net. [108.78.210.25]) by smtp.gmail.com with ESMTPSA id j62sm53364iod.29.2017.06.20.16.01.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jun 2017 16:01:32 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Juliusz Chroboczek'" , =?utf-8?Q?'Toke_H=C3=B8iland-J=C3=B8rgensen'?= Cc: "'David Schinazi'" , "'Babel at IETF'" References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> <87y3ss5nlg.fsf@alrua-x1> <87tw3fwjtt.wl-jch@irif.fr> <5CD7F43D-2FC0-4466-AFDE-FD968D9CC158@apple.com> <8760fr5bsl.fsf@alrua-x1> <87r2yesv62.wl-jch@irif.fr> <9EE24349-90A8-4855-A572-13C06C7D85D7@apple.com> <87vanqtqil.wl-jch@irif.fr> <87wp864dv3.fsf@alrua-x1> <87mv92tl87.wl-jch@irif.fr> In-Reply-To: <87mv92tl87.wl-jch@irif.fr> Date: Tue, 20 Jun 2017 19:01:18 -0400 Message-ID: <054701d2ea19$274cc3f0$75e64bd0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHcaZt+JfOUOhMIbEd5rEvBw0fjiAEtSNKoAb0/VRABysQ3GgHZvSuWAUyeS1cDRJAy7wIKiHvmAwNyu04BjLD94QDDZXnsAg+V870B4QhzrgGyWqHcAhG7FJICfZl64gGvl3awAZD3m1ahG9RyYA== Content-Language: en-us Archived-At: Subject: Re: [babel] Unscheduled Hellos X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 23:01:36 -0000 > The case I'm concerned about is that of an implementation that only = sends > scheduled Hellos of a given kind but occasionally needs to send a = Hello of the > other kind. For example, an implementation only sends Multicast = Hellos, but > then at some point decides to send a Timestamp sub-TLV over unicast, = which > needs to be attached to a Hello. If it sends a normal Unicast Hello, = then the > peer might start doing accounting of Unicast Hellos, and spuriously = detect > loss when the Interval expires. Attaching the sub-TLV to an = unscheduled > Hello avoids the spurious variation in link quality. >=20 > Conversely, consider an implementation that usually sends Unicast = Hellos, > but sends a bunch of unscheduled Multicast Hellos when the link layer > indicates that a new station has joined the BSS (or when it receives = an > ICMPv6 packet from a new IP, or when MARS indicates that a new node = has > joined the Emulated LAN, or whatever). Since the link-layer event is > unpredictable, there is no way to choose a good interval for Multicast = Hellos, > and sending a non-zero Interval might cause peers to start doing = link-quality > estimation using Multicast Hellos. >=20 > Folks, I'd really like to avoid the need for Interval=3D0. If you can = find a good > way to implement the two use cases above with the existing mecha- = nisms, > I'll be thrilled. On the other hand, Interval=3D0 is just a small = amount of spec > (don't reset the timer when Interval=3D0, and don't tweak the Hello = history), > and a very small amount of code, so we might as well go for it. You could solve with an extra bit -- but I think interval =3D=3D 0 is = the simplest way to solve it. =F0=9F=98=8A /r From nobody Tue Jun 20 16:06:07 2017 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 334CF1294E2 for ; Tue, 20 Jun 2017 16:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 u8B60RLS2PVi for ; Tue, 20 Jun 2017 16:06:03 -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 78D2B1294F0 for ; Tue, 20 Jun 2017 16:06:03 -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/56228) with ESMTP id v5KN61HK006818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Jun 2017 01:06:01 +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/56228) with ESMTP id v5KN61BP028322; Wed, 21 Jun 2017 01:06:01 +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 2A479EB2D0; Wed, 21 Jun 2017 01:06:01 +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 DOXpMA93_P6r; Wed, 21 Jun 2017 01:06:00 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 06E51EB2F0; Wed, 21 Jun 2017 01:05:59 +0200 (CEST) Date: Wed, 21 Jun 2017 01:05:59 +0200 Message-ID: <87a852tg2w.wl-jch@irif.fr> From: Juliusz Chroboczek To: Jehan Tremback Cc: babel-users@lists.alioth.debian.org, babel@ietf.org In-Reply-To: References: <87podystsb.wl-jch@irif.fr> <0F1E4094-C782-45C1-8E95-A466F8F17FF4@vfn-nrw.de> <87h8zatity.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=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]); Wed, 21 Jun 2017 01:06:01 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 21 Jun 2017 01:06:01 +0200 (CEST) X-Miltered: at korolev with ID 5949AA59.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5949AA59.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5949AA59.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5949AA59.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 : 5949AA59.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5949AA59.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] Unscheduled Unicast Hellos: some background on 802.11 link quality estimation X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 23:06:05 -0000 > I'm wondering... what if, in the hypothetical routing protocol "Babble", > one got rid of multicast hellos and ETX entirely, and routed using RTT > measured by unicast hellos. Interesting idea. I think that's a perfectly legitimate implementation of Babel with Unicast Hellos: we're leaving the cost computation algorithm unspecified, ETX is just an implementation suggestion in Appendix A. > Wouldn't this take delays from ARQ'ed packet oss into account have > results somehow similar to ETX? 802.11 has a default ARQ timeout of 1µs, which is likely to be drowned by congestion. I guess the only way to find out is to try it out. You'll need to change the packet format of the ETX extension, which only has 1µs granularity. -- Juliusz From nobody Tue Jun 20 17:18:17 2017 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 6327412957C for ; Tue, 20 Jun 2017 17:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 F3vR-Dqd1j3X for ; Tue, 20 Jun 2017 17:18:14 -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 EFD9D12956D for ; Tue, 20 Jun 2017 17:18:13 -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/56228) with ESMTP id v5L0IAs5016729; Wed, 21 Jun 2017 02:18:10 +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 7DB25EB2D0; Wed, 21 Jun 2017 02:18:10 +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 axsi8PRT1b4V; Wed, 21 Jun 2017 02:18:09 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1E0D1EB274; Wed, 21 Jun 2017 02:18:09 +0200 (CEST) Date: Wed, 21 Jun 2017 02:18:08 +0200 Message-ID: <87y3smry67.wl-jch@irif.fr> From: Juliusz Chroboczek To: Matthieu Boutier Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , Babel at IETF In-Reply-To: References: <149753600138.12968.17430801165728958448.idtracker@ietfa.amsl.com> <7679DA79-5B56-4A19-95C3-8DE0CB2C8C12@irif.fr> <8760fxz2da.fsf@alrua-x1> 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, 21 Jun 2017 02:18:12 +0200 (CEST) X-Miltered: at korolev with ID 5949BB42.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5949BB42.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 : 5949BB42.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] draft-boutier-babel-source-specific-02 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jun 2017 00:18:15 -0000 > When a node retracts all its routes, the receiver, which has only > considered the routes it understand, will only retracts these routes. You're right. RFC 6126 defines wildcard retractions to apply to both IPv4 and IPv6 routes. While 6126 does not deal with other address families or routes with mandatory TLVs, the intent is clearly that a wildcard retraction also applies to any other routes that this node may have announced. Think of a wildcard retraction as saying "I'm shutting down really soon now, please route around me." By the way -- it's not essential -- the node that's shutting down could just as well send individual retractions for all the routes it advertised previously. Or it could send a Hello with a very small interval so that it expires from the neighbour list of any peer. I'd have no problem with deprecating wildcard retractions. If people don't believe that wildcard requests are useful, we might as well deprecate AE 0. -- Juliusz From nobody Tue Jun 20 22:49:55 2017 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 D1A97131602 for ; Tue, 20 Jun 2017 22:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 LL8tkMw0tJH7 for ; Tue, 20 Jun 2017 22:49:50 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 DE6901294F3 for ; Tue, 20 Jun 2017 22:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498024190; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ka5HQxds53RhTioU5t5UUxUF20NiX6cLE7/vBPDJYF0=; b=TsRvWceJ0Cis/cGd7p1Kx29kERNs/M5I0hOM0xYvHWvTNax/6sz4GS8cf4D2A4LX /oUL58NChyURGF3xQW1qUUUjdYzX4kWq/C6lAArNgpU4v9au/8lBmQHqQ/UTXonH 1h+ZH0naX7uc7WLqz2EAmf2Wldbnl5tNCNAWqBTEhfmsxddLtOkO9IF4xJHmv0CC E/vx8Vepj6mQxv2rSf9Bm6g/bJFpLrHUyASpYLgucwH1yEZxMOZ3ih6b646hNqxe gZM5uj3k21+7sRi9kGhtorJRyrEm/PSlhAGIuSIS7DT0mZBdSujQK3g6zjQLUe8W 0yDriLc7YVx9/Re7yAGtIQ==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 9E.4C.07949.CF80A495; Tue, 20 Jun 2017 22:49:50 -0700 (PDT) X-AuditID: 11973e16-bf3fb70000001f0d-ee-594a08fc5eac Received: from koseret (koseret.apple.com [17.151.62.39]) by relay5.apple.com (Apple SCV relay) with SMTP id E4.57.09344.CF80A495; Tue, 20 Jun 2017 22:49:48 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_S90p42la3ei4ZiXnGllUvA)" Received: from [17.234.37.68] (unknown [17.234.37.68]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORV00CTTUUXIK00@koseret.apple.com>; Tue, 20 Jun 2017 22:49:47 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <57176DCB-8539-4DDB-8D89-15A991D83C9A@apple.com> Date: Tue, 20 Jun 2017 22:49:45 -0700 In-reply-to: <87shiutq1z.wl-jch@irif.fr> Cc: Babel at IETF To: Juliusz Chroboczek References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> <87y3ss5nlg.fsf@alrua-x1> <87tw3fwjtt.wl-jch@irif.fr> <5CD7F43D-2FC0-4466-AFDE-FD968D9CC158@apple.com> <87shiutq1z.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUi2FAYofuPwyvSoPm2isWWRd0sFvNbl7E5 MHksWfKTyWPxlreMAUxRXDYpqTmZZalF+nYJXBnbn95jLZiiVbFhxxz2BsYPyl2MnBwSAiYS yw9eZexi5OIQEljNJLFh+z52mMTvD23MEIlVjBJbn25kA0nwCghK/Jh8jwXEZhYIkzjesJMd oqiZSeLM3GZWkISwgLRE14W7QDYHB5uAlsSBNUYQvTYSz3bsZIcoCZVoal0DZrMIqEq8XzeH CcTmFNCQ2LLuFTvEfCWJ1d/uMIPYIgIqEsunPQOLCwk8Y5aY1y8LcaisxK3Zl5gh7CNsEpd+ Gk9gFJqF5NRZSE6FsLUkvj9qBYpzANnyEgfPy0KENSWe3fsEVaIt8eTdBdYFjGyrGIVyEzNz dDPzzPUSCwpyUvWS83M3MYIiYbqd2A7Gh6usDjEKcDAq8fBGKHtGCrEmlhVX5h5ilOZgURLn 1dkMFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDovKLXh/f/IoFmn59/6tKFFXYc239qye8N zyx2TW78yv5Th1GM3+PeF18HSc75q+/zzHiuETlJt1LXkeNp2k6h3R+6j3ZnhURN6J56oPbA 2uub84u47zbxa7z2bpyn5RXqYbx+4wulO3+KpsR8atK3TOTSWpeteuaF4NFNuxu2zJ5WsHLl xin/lFiKMxINtZiLihMBKwmxX2UCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUiON1OXfcPh1ekwZNbYhZbFnWzWMxvXcbm wOSxZMlPJo/FW94yBjBFcdmkpOZklqUW6dslcGVsf3qPtWCKVsWGHXPYGxg/KHcxcnJICJhI /P7QxtzFyMUhJLCKUWLr041sIAleAUGJH5PvsYDYzAJhEscbdrJDFDUzSZyZ28wKkhAWkJbo unAXyObgYBPQkjiwxgii10bi2Q6QepCSUImm1jVgNouAqsT7dXOYQGxOAQ2JLetesUPMV5JY /e0OM4gtIqAisXzaM7C4kMAzZol5/bIQh8pK3Jp9iXkCI/8sJOfNQnIehK0l8f1RK1CcA8iW lzh4XhYirCnx7N4nqBJtiSfvLrAuYGRbxShQlJqTWGmql1hQkJOql5yfu4kRFLoNhRE7GP8v szrEKMDBqMTDy6DoGSnEmlhWXJl7iFGCg1lJhFf7LVCINyWxsiq1KD++qDQntfgQ40RGoCcn MkuJJucDIyuvJN7QxMTAxNjYzNjY3MSclsJK4rx904EuEkhPLEnNTk0tSC2COYqJg1OqgXHW Bp67Jh3HTwb15Ba8OPzwxZGGjo3//nWL9j691dV6KC74YHZ58NKDvy/aTZM8eDWvin91ONfV tVPEJ7rLLi8zeX7sGrtlf/gnhzNvTn/N1GWrzkqfMcFib/3aPV4TUrwCzt7n9Yr2kbKOi91z Um1L9TeHFdFhplv+Zggbcb/tt3nIpzBtQqwSS3FGoqEWc1FxIgCxwVEg0AIAAA== Archived-At: Subject: Re: [babel] Unscheduled Hellos [was: Cutoff date for rfc6126bis is 3 July] X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jun 2017 05:49:53 -0000 --Boundary_(ID_S90p42la3ei4ZiXnGllUvA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > On Jun 20, 2017, at 12:30, Juliusz Chroboczek wrote: > > Rather than "Periodic Hello", I'm going to use "Scheduled Hello". This is > consistent with Updates, and doesn't imply that jitter is illegal. Sure, I updated the branch. > I'm sorely tempted to keep the seqno in unscheduled Hellos, since it makes > the text simpler. We can remove them later when we have implementation > experience. I thought about this, implemented it, thought about it some more, and I feel less strongly about it now. Keeping the seqno does not make the code that much more complex and does simplify the spec. So I changed the branch to reflect that. > Folks, I'd really like to avoid the need for Interval=0. If you can find a good > way to implement the two use cases above with the existing mecha- nisms, > I'll be thrilled. On the other hand, Interval=0 is just a small amount of spec > (don't reset the timer when Interval=0, and don't tweak the Hello history), > and a very small amount of code, so we might as well go for it. I agree, but couldn't come up with a better way without unscheduled hellos. Unscheduled hellos (with seqno) seem like a good solution to me. > The way to deal with Unscheduled Hellos for link-quality estimation should > not be normative -- the only normative condition is that a link that has > not received a Hello recently (of any kind) has infinite cost. The term > "link-quality" should not appear in the normative part of the document. Agreed, I fixed that > I'm going to redo Appendix A, since I disagree with much of your advice. > > Ok? Send some text! Updated branch is here: https://github.com/jech/babel-drafts/pull/3/files David Schinazi --Boundary_(ID_S90p42la3ei4ZiXnGllUvA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
On Jun 20, 2017, at 12:30, Juliusz Chroboczek <jch@irif.fr> = wrote:

Rather than = "Periodic Hello", I'm going to use "Scheduled Hello".  This is
consistent with Updates, and doesn't imply that jitter is = illegal.

Sure, I updated the branch.

I'm sorely tempted to keep the seqno in unscheduled Hellos, = since it makes
the text simpler.  We can remove them = later when we have implementation
experience.

I = thought about this, implemented it, thought about it some more, = and
I feel less strongly about it now. Keeping the seqno does = not make the
code that much more complex and does simplify the = spec.
So I changed the branch to reflect that.

Folks, = I'd really like to avoid the need for Interval=3D0.  If you can = find a good
way to implement the two use cases above with = the existing mecha- nisms,
I'll be thrilled.  On the = other hand, Interval=3D0 is just a small amount of spec
(don't reset the timer when Interval=3D0, and don't tweak the = Hello history),
and a very small amount of code, so we = might as well go for it.

I agree, but couldn't come up with a better way = without unscheduled hellos.
Unscheduled hellos (with seqno) = seem like a good solution to me.

The way to deal with Unscheduled Hellos for link-quality = estimation should
not be normative -- the only normative = condition is that a link that has
not received a Hello = recently (of any kind) has infinite cost.  The term
"link-quality" should not appear in the normative part of the = document.

Agreed, I fixed that

I'm going to = redo Appendix A, since I disagree with much of your advice.

Ok?

Send some = text!


Updated branch is here:

David Schinazi
= --Boundary_(ID_S90p42la3ei4ZiXnGllUvA)-- From nobody Tue Jun 20 23:26:17 2017 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 3F57D1314E1 for ; Tue, 20 Jun 2017 23:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 vGtg9cAVcMkj for ; Tue, 20 Jun 2017 23:26:14 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 7693F127B31 for ; Tue, 20 Jun 2017 23:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498026374; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=O9LJaU0E/nYxblzcfyl2qELNV0ozC+Na4QEMsOWTIWE=; b=FV0TVPAiodD54iz29jSZJ8VmiiB+P4Ryinz8CqveAmHPC+wQexQfQx9smBLiBPfa 8/LLOU5cEngIOI+VNZlyduE+m+k4MWYP3VRdrfbW3rTJ+eNtXt+PYHLypzofkCJ8 Eum2qdMeeMARmETrBjeLJTLFt/yV4JUYoq2KQBvbi5MAxUJbtZvDnUztrq0QJbJ3 sqteJkyv+CE1Hx0UQFENd11wZG+qKb2l3/FGxcHZiYnVHIUYAqTxrZTwJNc7rFo8 LKfnvLRgNcma2ybGS42ErwqXN/Eq20DJdOj6rrURDH3jyWNnle7wiQq4wkgsrh4/ DAXcPkGr22ZHBU2ykb9ddw==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 53.45.01052.6811A495; Tue, 20 Jun 2017 23:26:14 -0700 (PDT) X-AuditID: 11973e12-7285e9a00000041c-39-594a1186f256 Received: from kencur (kencur.apple.com [17.151.62.38]) by relay5.apple.com (Apple SCV relay) with SMTP id 4A.04.09344.6811A495; Tue, 20 Jun 2017 23:26:14 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_tnCgLdaIfA8AB3JqbzzGEA)" Received: from [100.116.169.73] (75.sub-70-213-4.myvzw.com [70.213.4.75]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORV00BKGWJP4X10@kencur.apple.com>; Tue, 20 Jun 2017 23:26:13 -0700 (PDT) Sender: dschinazi@apple.com X-Apple-Base-Url: x-msg://46/ X-Universally-Unique-Identifier: AD2F372F-5FCB-4152-B45F-485B5B063145 X-Apple-Mail-Remote-Attachments: YES X-Apple-Auto-Saved: 1 From: David Schinazi X-Mailer: iPhone Mail (14G40) In-reply-to: <87shivmsgz.wl-jch@irif.fr> X-Apple-Windows-Friendly: 1 Date: Tue, 20 Jun 2017 23:26:13 -0700 Cc: Matthieu Boutier , babel-users@lists.alioth.debian.org, babel@ietf.org X-Apple-Mail-Signature: Message-id: <24969E1C-512C-4465-AC50-8889866A87FA@apple.com> References: <87h90a9nlz.wl-jch@irif.fr> <70ED4D66-B6BF-4D29-B24F-32A2C6779789@irif.fr> <87y3tdhy84.wl-jch@irif.fr> <87shivmsgz.wl-jch@irif.fr> X-Uniform-Type-Identifier: com.apple.mail-draft To: Juliusz Chroboczek X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUi2FAYodsm6BVpsG2igMXXzw0sFlsWdbNY HP7SyGIxv3UZmwOLx5IlP5k8Fm95y+jx5lAfSwBzFJdNSmpOZllqkb5dAlfG5AnfmAqOGFc8 /OnZwNiq3cXIySEhYCLRcfA7SxcjF4eQwGomiZ5355lgEhsXTmeGSKxglDjX+J4RJMErICjx Y/I9oA4ODmaBMIk7VxUgaqYwSax9s5wdpEZYQFqi68JdVgjbUOJqQwcbxFBZiW/LdjND2K4S VztnQtkqEqu6t7BD2KISSx/tYwWZzyagJXFgjRGICdL6caUUSAWngIbE6V3tUJ3SEk8+rgA7 mUVAVaJnXyPYlcwCsRKX/89lhKgRl2jd8ocJ4nobiWPHe1ghTp7EKHHp0Us2iPn6Ej1PJEFq RICuWT7tGdQ1y9glnr4wmsAoOQvJ87MQnp8Ftk1L4vujVqiwvMTB87IQYU2JZ/c+sUPY2hJP 3l1gXcDItopRKDcxM0c3M89EL7GgICdVLzk/dxMjKI6n2wntYDy1yuoQowAHoxIPb6SyZ6QQ a2JZcWXuIUZpDhYlcV6tzUAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjBNWq/52+7TsvYdm wXen2+sDJ+fpvNWdfln9cUC5xe0M9qkm4qr9nnt0bv/QLJ9U/bk0KnHzBBPZKOcbIlpJnsk9 JyZsL2O0XXVtoWntStFrxZ3vojcHWj+YHR+56VlguErUM521J+cfOXq+NnlLV/7D1f6uE28k XLWQevB197WIioncb2d8/avEUpyRaKjFXFScCABpyXnJxAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUiON1OTbdN0CvSYOpPLouvnxtYLLYs6max OPylkcVifusyNgcWjyVLfjJ5LN7yltHjzaE+lgDmKC6blNSczLLUIn27BK6MyRO+MRUcMa54 +NOzgbFVu4uRk0NCwERi48LpzF2MXBxCAisYJc41vmcESfAKCEr8mHyPpYuRg4NZIEzizlUF iJopTBJr3yxnB6kRFpCW6LpwlxXCNpS42tDBBjFUVuLbst3MELarxNXOmVC2isSq7i3sELao xNJH+1hB5rMJaEkcWGMEYoK0flwpBVLBKaAhcXpXO1SntMSTjyuYQGwWAVWJnn2NYFcyC8RK XP4/lxGiRlyidcsfJojrbSSOHe9hhTh5EqPEpUcv2SDm60v0PJEEqREBumb5tGfsExjFZiF5 eBbCw7PANmhJfH/UChWWlzh4XhYirCnx7N4ndghbW+LJuwusCxjZVjEKFKXmJFaa6iUWFOSk 6iXn525iBEVeQ2HEDsb/y6wOMQpwMCrx8DIoekYKsSaWFVfmHmKU4GBWEuH15/WKFOJNSays Si3Kjy8qzUktPsQ4kRHo34nMUqLJ+cC0kFcSb2hiYmBibGxmbGxuYk5LYSVx3r7pQEcKpCeW pGanphakFsEcxcTBKdXAuJxl5UP9Qq8tR278n7y49tjTV7s0tn9efPLQDA9PuW2dbqlSVjLl 7vtYNew3mMxL2cRbsth8Yl3TymjJ7OM575tbxOU/cylWXyvd91S3WuMjk71Mwh3ZBZe3PAm9 HVyaKfl64VJm2eqsh/U29/+5Tr/02kHYTm3Nd96PfzOLX7ev5j6x5lzMHSWW4oxEQy3mouJE AKeoTSAvAwAA Archived-At: Subject: Re: [babel] [Babel-users] source sub-tlv X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jun 2017 06:26:16 -0000 --Boundary_(ID_tnCgLdaIfA8AB3JqbzzGEA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT I've read draft-boutier-babel-source-specific-02 and I do agree that (3) isn't that simple to define. However I still do find (1) wasteful. How about Proposal 5, which I define as: By default, a vanilla wildcard request triggers a dump of all regular routes (by regular I mean from the original spec so not source-specific). We define a new non-mandatory sub-TLV on Route Requests called "Requested Route Types" that contains an array of all the types of routes this request is requesting. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD | Length | RR Type 1 | RR Type 2... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- We also create a registry of Requested Route (RR) types: 0 = Regular 1 = Source-Specific 2 = TOS-specific etc. For example, if you send: [Type = TBD, Length=2, 0, 1] it means that you'd like all regular and source-specific routes. This does make it easy to add new extensions without each extension knowing about other extensions. I do realize this is more complex than option (1) but could be worth it as it reduces overhead of extensions which allows better scalability in the number of future extensions. Thoughts? David Schinazi > On Jun 19, 2017, at 17:07, Juliusz Chroboczek wrote: > >>> - only keep (legacy) wildcard requests, and reply with a full dump. > >> That's reasonable, although slightly confusing. (Call that (1).) > >> 3. Send a non-specific wildcard request for non-specific routes, >> a source-specific wildcard request for source-specific routes, etc. > >> I support (3). Last time I spoke to him, Toke supported (4). I am >> opposed to (2). I can live with (1). > > After looking at the relevant code in babeld, I find that (1) is much > simpler to implement. > > Matthieu's latest draft (-2) contains a good summary of the discussion. > > -- Juliusz > > _______________________________________________ > Babel-users mailing list > Babel-users@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users --Boundary_(ID_tnCgLdaIfA8AB3JqbzzGEA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
I've read = ;draft-boutier-babel-source-specific-02 and I do agree that (3)
isn't th= at simple to define. However I still do find (1) wasteful.

How about Proposal 5, which I define as:

By d= efault, a vanilla wildcard request triggers a dump of all
regular r= outes (by regular I mean from the original spec so
not source-spec= ific). We define a new non-mandatory sub-TLV
on Route Requests cal= led "Requested Route Types" that
contains an array of all the type= s of routes this request is requesting.

On Jun 19, 2017, at 17:07, Juliusz Chroboczek <jch@irif.fr> wrote:

- only keep (legacy) wildcard requests, and reply with a full dump= .

That's reasonable, although slightly confusing.  (Cal= l that (1).)

 3. Send a non-specific wildcard request for non-speci= fic routes,
    a source-specific wildcar= d request for source-specific routes, etc.

I support (3).  Last time= I spoke to him, Toke supported (4).  I am
opposed to (2)= .  I can live with (1).

After= looking at the relevant code in babeld, I find that (1) is much
simpler to implement.

Matthieu's latest draf= t (-2) contains a good summary of the discussion.

-- Juliusz

_________________________________= ______________
Babel-users mailing list
Babel-users@lists.alioth.debian= .org
http://lists.alioth.debian.org/cgi-bin/mailman/li= stinfo/babel-users

= --Boundary_(ID_tnCgLdaIfA8AB3JqbzzGEA)-- From nobody Wed Jun 21 02:39:07 2017 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 D2B2E131CB2 for ; Wed, 21 Jun 2017 02:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 027R8GOeVdQB for ; Wed, 21 Jun 2017 02:39:03 -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 704A3131CAA for ; Wed, 21 Jun 2017 02:39:03 -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/56228) with ESMTP id v5L9cxbl032559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Jun 2017 11:38:59 +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/56228) with ESMTP id v5L9cxNj006763; Wed, 21 Jun 2017 11:38:59 +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 13DD2EB2FC; Wed, 21 Jun 2017 11:38:59 +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 4T7vjdthWhdl; Wed, 21 Jun 2017 11:38:58 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B6A6AEB2F8; Wed, 21 Jun 2017 11:38:57 +0200 (CEST) Date: Wed, 21 Jun 2017 11:38:57 +0200 Message-ID: <87fuethe8e.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Babel at IETF In-Reply-To: <57176DCB-8539-4DDB-8D89-15A991D83C9A@apple.com> References: <7ir2ynlrxs.wl-jch@irif.fr> <87wp8fzhqn.fsf@alrua-x1> <1E478C33-747C-4451-93D7-754EB9C59CD5@apple.com> <87k24dzk6t.fsf@alrua-x1> <87wp8dcbmj.wl-jch@irif.fr> <87r2ykdfy8.wl-jch@irif.fr> <957DC386-7C82-4B1A-9D28-174E821CC823@apple.com> <87y3ss5nlg.fsf@alrua-x1> <87tw3fwjtt.wl-jch@irif.fr> <5CD7F43D-2FC0-4466-AFDE-FD968D9CC158@apple.com> <87shiutq1z.wl-jch@irif.fr> <57176DCB-8539-4DDB-8D89-15A991D83C9A@apple.com> 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]); Wed, 21 Jun 2017 11:38:59 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 21 Jun 2017 11:38:59 +0200 (CEST) X-Miltered: at korolev with ID 594A3EB3.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 594A3EB3.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 594A3EB3.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 594A3EB3.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 : 594A3EB3.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 594A3EB3.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Unscheduled Hellos [was: Cutoff date for rfc6126bis is 3 July] X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jun 2017 09:39:06 -0000 > Sure, I updated the branch. Sorry I wasn't clearer -- I was in the midst of editing. Please don't touch the branch until I've merged your text (hopefully before midnight). -- Juliusz From nobody Wed Jun 21 04:36:18 2017 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 CA9B8128DE7 for ; Wed, 21 Jun 2017 04:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 2SbfAsRFUDHh for ; Wed, 21 Jun 2017 04:36:15 -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 310CB1243F3 for ; Wed, 21 Jun 2017 04:36:15 -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/56228) with ESMTP id v5LBaDgW008273 for ; Wed, 21 Jun 2017 13:36:13 +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 4C386EB2CC for ; Wed, 21 Jun 2017 13:36:13 +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 rI1iFnyuxTnP for ; Wed, 21 Jun 2017 13:36:12 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 22F0FEB274 for ; Wed, 21 Jun 2017 13:36:10 +0200 (CEST) Date: Wed, 21 Jun 2017 13:36:10 +0200 Message-ID: <8760fph8t1.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 [194.254.61.138]); Wed, 21 Jun 2017 13:36:13 +0200 (CEST) X-Miltered: at korolev with ID 594A5A2D.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 594A5A2D.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 : 594A5A2D.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: [babel] Merged Unicast Hellos into rfc6126bis X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jun 2017 11:36:17 -0000 David, Thanks a lot for your text, I'm pretty happy with the technical content. I've merged and pushed your copy, I'll modify it tonight. What I'm going to do tonight: - remove language that says that (scheduled) Hellos are periodic -- the interval is an upper bound on the time of the next Hello; - the terminology introduced by David is a little heavy, but I don't see a good way to keep it precise; more thought is needed; - rewrite Section "Reverse Reachability detection", which is way too verbose for my taste; - rewrite Appendix "Cost computation", including an introduction about 802.11 specifics; - remove the paragraph "Properties of Multicast and Unicast Hellos", which is too vague to be useful; - remove timing advice for Unicast Hellos in Appendix B, since we have no implementation experience yet; - rewrite the simplified implementations section; - flesh out the "Changes since -02" section. If anyone disagrees with anything in David's text, please speak now. -- Juliusz From nobody Wed Jun 21 09:16:04 2017 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 1E6D7128961 for ; Wed, 21 Jun 2017 09:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 tZW3KTvfmtVR for ; Wed, 21 Jun 2017 09:16:01 -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 A6E271276AF for ; Wed, 21 Jun 2017 09:16:00 -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/56228) with ESMTP id v5LGFsWR017713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Jun 2017 18:15:54 +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/56228) with ESMTP id v5LGFsKB004447; Wed, 21 Jun 2017 18:15:54 +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 664B2EB2CC; Wed, 21 Jun 2017 18:15:54 +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 6YWyI3c8y5RV; Wed, 21 Jun 2017 18:15:49 +0200 (CEST) Received: from eduroam-prg-sg-1-47-64.net.univ-paris-diderot.fr (eduroam-prg-sg-1-47-64.net.univ-paris-diderot.fr [172.28.47.64]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0010BEB2F8; Wed, 21 Jun 2017 18:15:48 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Matthieu Boutier In-Reply-To: <24969E1C-512C-4465-AC50-8889866A87FA@apple.com> Date: Wed, 21 Jun 2017 18:15:49 +0200 Cc: Juliusz Chroboczek , babel-users@lists.alioth.debian.org, babel@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <5CE399F9-8065-49D3-B32D-965D4A03EFB0@irif.fr> References: <87h90a9nlz.wl-jch@irif.fr> <70ED4D66-B6BF-4D29-B24F-32A2C6779789@irif.fr> <87y3tdhy84.wl-jch@irif.fr> <87shivmsgz.wl-jch@irif.fr> <24969E1C-512C-4465-AC50-8889866A87FA@apple.com> To: David Schinazi X-Mailer: Apple Mail (2.3124) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 21 Jun 2017 18:15:54 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 21 Jun 2017 18:15:54 +0200 (CEST) X-Miltered: at korolev with ID 594A9BBA.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 594A9BBA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 594A9BBA.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 594A9BBA.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 : 594A9BBA.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 594A9BBA.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] source sub-tlv X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jun 2017 16:16:03 -0000 > I still do find (1) wasteful. I really would like to feel your intuition. From my point of view: - either you'll have very few some-specific routes, in which case the waste is negligible (isn't it the case of multihomed networks ?), - or you'll have so much some-specific routes that non-specific routers will be almost useless (and so you'll have to update them). > (3) isn't that simple to define. > How about Proposal 5, which I define as: > > By default, a vanilla wildcard request triggers a dump of all > regular routes (by regular I mean from the original spec so > not source-specific). We define a new non-mandatory sub-TLV > on Route Requests called "Requested Route Types" that > contains an array of all the types of routes this request is requesting. You need to say that routes resulting in a combination of extensions are sent if each type of the extension is understood. (and if the node understand such combination, but this is straightforward). > 0 = Regular > 1 = Source-Specific > 2 = TOS-specific > etc. > > For example, if you send: > [Type = TBD, Length=2, 0, 1] > it means that you'd like all regular and source-specific routes. and if you send [type = RRT, length=2, 1, 2], it means that you'd like source-specific routes, ToS-routes and source-tos-routes. Of course, if the requesting node doesn't understand the combination, it might receive a some wasteful routes... And, even if state is evil, this request can be encoded as the following by requesting that wildcard requests are combined in the whole message. [Wildcard Route Request + source-specific sub-TLV] [Wildcard Route Request + ToS-specific sub-TLV] In the babeld code, I would just put an int to handle that... Does this make a 6th proposition ? > Thoughts? Summary: 1. Put one Wildcard Route Request (WRR). May waste routes. No parser state. 3. Put one WRR per extension and per combinations. No wasted routes. No parser state. 5. Define a new sub-TLV with one field per extension. Send understood combinations. Might waste routes. No parser state. 6. Put one WRR per extension. Send understood combinations. Might waste routes. Have a parser state (an int is clearly sufficient). I think I prefer 6 over 5. (My preferences are: 1 < 6 < 5 < 3). Matthieu From nobody Thu Jun 22 12:21:17 2017 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 EF29A124D85 for ; Thu, 22 Jun 2017 12:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ROThC1Bw154h for ; Thu, 22 Jun 2017 12:21:12 -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 61A59126B7E for ; Thu, 22 Jun 2017 12:21:12 -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/56228) with ESMTP id v5MJLAtE030288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 22 Jun 2017 21:21:10 +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/56228) with ESMTP id v5MJLA0u003402 for ; Thu, 22 Jun 2017 21:21:10 +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 2DFFDEB2D0 for ; Thu, 22 Jun 2017 21:21:10 +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 LtIPBIqSMkbi for ; Thu, 22 Jun 2017 21:21:09 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 2473EEB2CC for ; Thu, 22 Jun 2017 21:21:08 +0200 (CEST) Date: Thu, 22 Jun 2017 21:21:08 +0200 Message-ID: <87fuerx1zv.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]); Thu, 22 Jun 2017 21:21:10 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 22 Jun 2017 21:21:10 +0200 (CEST) X-Miltered: at korolev with ID 594C18A6.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 594C18A6.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 594C18A6.003 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 594C18A6.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 : 594C18A6.003 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 594C18A6.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] Unicast Hellos: please specify your usage scenarios X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jun 2017 19:21:15 -0000 I'm re-reading the text I've written for Unicast Hellos, and I'd like to make sure we get it right. Could the people who are in favour of adding Unicast Hellos to the spec please be so kind as to restate your usage scenarios? More precisely: if you're planning to implement or to use Unicast Hellos, could you please say why, how you intend to schedule your Unicast and Multicast Hellos, and how you intend to use the received Hellos. Please. It's important we get this right. -- Juliusz From nobody Thu Jun 22 14:24:56 2017 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 3818F12949A for ; Thu, 22 Jun 2017 14:24:55 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 MC9fKlc-06Il for ; Thu, 22 Jun 2017 14:24:53 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 ECE67129B81 for ; Thu, 22 Jun 2017 14:24:52 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id e7so14294911pfk.0 for ; Thu, 22 Jun 2017 14:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4OkLdqbd+cCHnqs/9aZALpF78BeSPElE8utpmn0kXhk=; b=pAnghjnn0V0g1gNmk4SssOTisMd55NVt9gnwX/qbmBEgcHHb0IZ+fe6VEyqr89F/7N ThFB9xl4LVl8/aoJfPFqG0L/AL4/xkSpngmn8t03H6AAueZvGM1+3I06CnqUhYYT+Wsj V7r9cJMxvXJlVLe2Mj3rIAj/WQEqs91koEi4ZjG1ot7xhxz6VlA16nlGXCpLepfNP4GK tHOJlb8ZL2Xq8T4v25TilBCoZYPka6S2tjt76uR+vRPW1mrn53N640JUh3BI3Ng5EREA 996f6tvfXGwqhpdtpOuGTywzEY+Iwr57I9jZeHoRy2DtaKI5/UH4TDamjZu4b8VMnnIB fzQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4OkLdqbd+cCHnqs/9aZALpF78BeSPElE8utpmn0kXhk=; b=jFglyxf50v+O7m2WwdmTG1OcXBwvA6Ffj2rWyZJ46p/opUhBBTDRbPfNAY21WPjlvu EtXKOJMOJ4Rc/OaAeXAiEBXmY97qZZHqJLWVJzFZkH4njc+j44TYSSVk8sNR/BeMozpV sJ8BvnGSXHO6aSp5HSVp7nsf4c9yNq3m5Lo5HvoXS6BsEcw177UmjTU8VTNR48YTKkra GSl6s+QapVPpcSgMW2kKwE62Q1frQM0XfvYzDlc9P1g+ecB9cAf5f/4iasld0wz8aUcL z0b03W7dD37l7FkuTbm1VCjIGI1rpUrrgnSIXnvXyoi2jFsYVzimFdjw+L8IC7bY896a Ic1A== X-Gm-Message-State: AKS2vOyBb/6lHJnoZOdQddu+44WTjSa0y/jqyB8vZEmpwhs6CztTZH4I MuHlwKyLt8LWcjq2ibPxyt92SUnxmo/C X-Received: by 10.84.164.165 with SMTP id w34mr5080804pla.54.1498166692583; Thu, 22 Jun 2017 14:24:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.178.2 with HTTP; Thu, 22 Jun 2017 14:24:51 -0700 (PDT) Received: by 10.100.178.2 with HTTP; Thu, 22 Jun 2017 14:24:51 -0700 (PDT) In-Reply-To: <87fuerx1zv.wl-jch@irif.fr> References: <87fuerx1zv.wl-jch@irif.fr> From: Ted Lemon Date: Thu, 22 Jun 2017 17:24:51 -0400 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF Content-Type: multipart/alternative; boundary="94eb2c199d4e86acb90552931de4" Archived-At: Subject: Re: [babel] Unicast Hellos: please specify your usage scenarios X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jun 2017 21:24:55 -0000 --94eb2c199d4e86acb90552931de4 Content-Type: text/plain; charset="UTF-8" I want them fo the pairwise keying use case. On Jun 22, 2017 2:21 PM, "Juliusz Chroboczek" wrote: > I'm re-reading the text I've written for Unicast Hellos, and I'd like to > make sure we get it right. Could the people who are in favour of adding > Unicast Hellos to the spec please be so kind as to restate your usage > scenarios? > > More precisely: if you're planning to implement or to use Unicast Hellos, > could you please say why, how you intend to schedule your Unicast and > Multicast Hellos, and how you intend to use the received Hellos. > > Please. It's important we get this right. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --94eb2c199d4e86acb90552931de4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I want them fo the pairwise =C2=A0keying use case.=C2=A0<= /div>

On Jun 22, 2= 017 2:21 PM, "Juliusz Chroboczek" <jch@irif.fr> wrote:
I'm re-reading the text I've written f= or Unicast Hellos, and I'd like to
make sure we get it right.=C2=A0 Could the people who are in favour of addi= ng
Unicast Hellos to the spec please be so kind as to restate your usage
scenarios?

More precisely: if you're planning to implement or to use Unicast Hello= s,
could you please say why, how you intend to schedule your Unicast and
Multicast Hellos, and how you intend to use the received Hellos.

Please.=C2=A0 It's important we get this right.

-- Juliusz

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--94eb2c199d4e86acb90552931de4-- From nobody Thu Jun 22 14:39:27 2017 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 6F6AB129484 for ; Thu, 22 Jun 2017 14:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 jdOyPH9DeFvq for ; Thu, 22 Jun 2017 14:39:24 -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 DDE54126CBF for ; Thu, 22 Jun 2017 14:39:23 -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/56228) with ESMTP id v5MLdLsj002963; Thu, 22 Jun 2017 23:39:21 +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 78764EB2F0; Thu, 22 Jun 2017 23:39:21 +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 p1B8eWcIzhag; Thu, 22 Jun 2017 23:39:20 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 70D11EB2CC; Thu, 22 Jun 2017 23:39:20 +0200 (CEST) Date: Thu, 22 Jun 2017 23:39:20 +0200 Message-ID: <878tkjwvlj.wl-jch@irif.fr> From: Juliusz Chroboczek To: Ted Lemon Cc: Babel at IETF In-Reply-To: References: <87fuerx1zv.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]); Thu, 22 Jun 2017 23:39:21 +0200 (CEST) X-Miltered: at korolev with ID 594C3909.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 594C3909.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 : 594C3909.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] Unicast Hellos: please specify your usage scenarios X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jun 2017 21:39:25 -0000 > I want them fo the pairwise keying use case. Can you please explain how Unicast Hellos are used in an implementation that does pairwise keying, and why you believe pairwise keying cannot be done without Unicast Hellos? (I have my ideas on the subject, I'm just trying to make sure that my ideas are congruent to yours.) -- Juliusz From nobody Thu Jun 22 17:40:54 2017 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 DBC19129BCB for ; Thu, 22 Jun 2017 17:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fugue-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 Zk7oq5jW961N for ; Thu, 22 Jun 2017 17:40:51 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 CFE5B126C83 for ; Thu, 22 Jun 2017 17:40:50 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id b6so17961231oia.1 for ; Thu, 22 Jun 2017 17:40:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8qsZgrfYwqj256zvFykg0/fdLxYs1+pXZDMjspIVO+k=; b=DZL5IRkVX+8NzXomOMbpdIA/UhFPl9UK8EKhuaO4KVbDP2/fdher4xJ35TUmuT30ms we/Qi1k3l/88ykyp2TderpH8g8wUflbzlrMABLOTGcGGZGkIiZ9LyY4Rh5jxqeT4ayIM T5k+MVPjVlsQGTVcQXtBDqJ+fTV6RAy8RWbVkBibWJS0WSOb7wQjuKjcjl0Z3TaBKHpz GOD0M5pbvAQQNMs9kcwi/2rzpyqy77uSL3mD8hbc9XPHhrOyDWiJaFLVt83wpZneNcPg ycYJrVvWVT9rND8jhrQ06RHIhjnbLAYihDZdUHK6PvjRiorkysm/8PfORfErZq6C9/Fg 9shw== 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=8qsZgrfYwqj256zvFykg0/fdLxYs1+pXZDMjspIVO+k=; b=GqmzoZUWHMadZsr/exDXiIaiF6Y91gnJCWstFuieu7I8t8zRlWLElrEJ7DvqvII9Z9 ucOsWKG7A/O5nI3G5qpeHaDN04Xq0jpRM4LAFnuiKHxJ/DsJ+dAjFEyYxBXwN9gKkiwO t75MFH5jhWRxYRnkvcui4K9Sofv2PqfIvq1apgtC7sDPBP4pekuAuKSvJLnTPm3gE3kR L8lkzwGdAs8rgYkH4DkcG3OXZCHYtePaT5B7VWgeBbK164M6QxAqqoQ+dvzHjzZLuRyz hSG4AH22Gu3WerQtonaMsUUTuJP5bJ2QY6ePO/wNZ7FQfaEi8o3nzPrmTN9yK1pqGKdV VJUw== X-Gm-Message-State: AKS2vOwt8INTaycTYkrgzRYHox2SeGiZIszBuw9gB4esiycyFS7OK3si ZM/PWcLgQjvGvY3r X-Received: by 10.202.80.197 with SMTP id e188mr946007oib.50.1498178450275; Thu, 22 Jun 2017 17:40:50 -0700 (PDT) Received: from [10.254.52.237] (rrcs-98-6-54-194.sw.biz.rr.com. [98.6.54.194]) by smtp.gmail.com with ESMTPSA id 64sm1468326otw.34.2017.06.22.17.40.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Jun 2017 17:40:49 -0700 (PDT) From: Ted Lemon Message-Id: <46947543-A3A4-4B09-86D7-8D917E767099@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_08F1431E-1F3E-4346-93F9-28A16EA2B995" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 22 Jun 2017 19:40:48 -0500 In-Reply-To: <878tkjwvlj.wl-jch@irif.fr> Cc: Babel at IETF To: Juliusz Chroboczek References: <87fuerx1zv.wl-jch@irif.fr> <878tkjwvlj.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [babel] Unicast Hellos: please specify your usage scenarios X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 23 Jun 2017 00:40:53 -0000 --Apple-Mail=_08F1431E-1F3E-4346-93F9-28A16EA2B995 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 22, 2017, at 4:39 PM, Juliusz Chroboczek wrote: > Can you please explain how Unicast Hellos are used in an = implementation > that does pairwise keying, and why you believe pairwise keying cannot = be > done without Unicast Hellos? Hm. Well, in thinking about this, the question arises, how large is = the scope for babel multicast? If it's link scope, then actually = including one signature per possible recipient might be okay. For = unicast hellos to work, it's necessary to know the addresses of any = servers that will receive the hello. The number of babel listeners on = a particular link can be expected to be quite constrained. So, perhaps it would be best to clarify whether this is actually an = issue before making bold statements as I did previously. --Apple-Mail=_08F1431E-1F3E-4346-93F9-28A16EA2B995 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jun 22, 2017, at 4:39 PM, Juliusz Chroboczek <jch@irif.fr> = wrote:
Can you please = explain how Unicast Hellos are used in an implementation
that does pairwise keying, and why you believe = pairwise keying cannot be
done without = Unicast Hellos?

Hm.   Well, in thinking about this, the question arises, = how large is the scope for babel multicast?   If it's link scope, = then actually including one signature per possible recipient might be = okay.   For unicast hellos to work, it's necessary to know the = addresses of any servers that will receive the hello.   The number = of babel listeners on a particular link can be expected to be quite = constrained.

So,= perhaps it would be best to clarify whether this is actually an issue = before making bold statements as I did previously.

= --Apple-Mail=_08F1431E-1F3E-4346-93F9-28A16EA2B995-- From nobody Fri Jun 23 17:09:16 2017 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 22739129B5F; Fri, 23 Jun 2017 17:07:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: babel@ietf.org, akatlas@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826282113.7840.10068471607706713499.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:01 -0700 Archived-At: Subject: [babel] babel - Requested session has been scheduled for IETF 99 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:01 -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:00) Monday, Afternoon Session III 1740-1840 Room Name: Athens/Barcelona size: 100 --------------------------------------------- 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: 45 Conflicts to Avoid: First Priority: netconf netmod rtgwg idr lpwan homenet manet mptcp Second Priority: dnsop dnssd 6man v6ops trill i2rs Third Priority: saag isis ospf People who must be present: Donald E. Eastlake 3rd Russ White Alia Atlas Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Jun 25 10:20:22 2017 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 B38171273B1 for ; Sun, 25 Jun 2017 10:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] 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 gEXESOzGLEEv for ; Sun, 25 Jun 2017 10:20:19 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB2C1201F2 for ; Sun, 25 Jun 2017 10:20:18 -0700 (PDT) Received: from wwinf1f22 ([10.232.36.46]) by mwinf5d27 with ME id d5LG1v00F0zk7Pu035LGHb; Sun, 25 Jun 2017 19:20:16 +0200 X-ME-Helo: wwinf1f22 X-ME-Auth: eWl5b3BAd2FuYWRvby5mcg== X-ME-Date: Sun, 25 Jun 2017 19:20:16 +0200 X-ME-IP: 129.199.159.135 Date: Sun, 25 Jun 2017 19:20:16 +0200 (CEST) From: Gwendoline Reply-To: Gwendoline To: babel@ietf.org Message-ID: <1414368409.6714.1498411216418.JavaMail.www@wwinf1f22> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6713_1857906027.1498411216418" X-Originating-IP: [129.199.159.135] X-WUM-FROM: |~| X-WUM-TO: |~| X-WUM-REPLYTO: |~| Archived-At: Subject: [babel] Changing the route retraction X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 25 Jun 2017 17:20:22 -0000 ------=_Part_6713_1857906027.1498411216418 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Dear all, I'm implementing the extension for ToS that I designed for Babel. It is quite similar to the source-specific extension that Matthieu designed, but routes are indexed by (prefix, ToS). I came across the fact that when a route with a ToS t is retracted, then all packets with ToS t that should have followed this route are dropped for 110 seconds, according to section 3.5.5 in RFC 6126, even if there is a installed route without ToS. This is satisfying enough for the source-specific extension, since when a source-specific route is retracted, we don't want to follow another one. However, in the case of a low-delay ToS for example, we'd like to switch right then to a non ToS-specific route. I thought about a way to reduce this delay in most cases in the non-tos-specific case. I think I found one: When a Babel node retracts a route, it maintains the route unreachable only until the first event between (a) the node received an acknowledgement or the same route retraction from each of its neighbours (b) it's been more than 110 seconds (to avoid blocking indefinitely because of weird neighbours). This solution would reduce delays even with neighbours that don't implement it. It would be the first use of the acknowledgements defined in Babel. A node should send an acknowledgement for a route retraction even if it isn't feasible or installed. We think it works in theory, but we don't know whether it will work in practice. Could you please tell your thoughts on this? ------=_Part_6713_1857906027.1498411216418 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 
Dear all,

I'm implementing the extension for ToS that I designed for Babel. 
It is quite similar to the source-specific extension that Matthieu designed, 
but routes are indexed by (prefix, ToS).  I came across the fact that when 
a route with a ToS t is retracted, then all packets with ToS t that should 
have followed this route  are dropped for 110 seconds, according to section
3.5.5 in RFC 6126, even if there is a installed route without ToS.

This is satisfying enough for the source-specific extension, since when a 
source-specific route is retracted, we don't want to follow another one. However, 
in the case of a low-delay ToS for example, we'd like to switch right
then to a non ToS-specific route. 


I thought about a way to reduce this delay in most cases in the
non-tos-specific case. I think I found one:

When a Babel node retracts a route, it maintains the route unreachable
only until the first event between
(a) the node received an acknowledgement or the same
route retraction from each of its neighbours
(b) it's been more than 110 seconds (to avoid blocking indefinitely
because of weird neighbours).

This solution would reduce delays even with neighbours that don't
implement it.
It would be the first use of the acknowledgements defined in Babel.
A node should send an acknowledgement for a route retraction even if it
isn't feasible or installed.

We think it works in theory, but we don't know whether it will work in practice.
Could you please tell your thoughts on this?
------=_Part_6713_1857906027.1498411216418-- From nobody Sun Jun 25 18:23:32 2017 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 C306E124B0A for ; Sun, 25 Jun 2017 18:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 XL9R6bZzERxn for ; Sun, 25 Jun 2017 18:23:28 -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 72EF812441E for ; Sun, 25 Jun 2017 18:23:28 -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/56228) with ESMTP id v5Q1NQte009175; Mon, 26 Jun 2017 03:23:26 +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 68FA8EB2D0; Mon, 26 Jun 2017 03:23:26 +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 nGUxt8Llw8DP; Mon, 26 Jun 2017 03:23:25 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 02E9CEB274; Mon, 26 Jun 2017 03:23:24 +0200 (CEST) Date: Mon, 26 Jun 2017 03:23:24 +0200 Message-ID: <87a84vy22b.wl-jch@irif.fr> From: Juliusz Chroboczek To: Gwendoline Cc: babel@ietf.org In-Reply-To: <1414368409.6714.1498411216418.JavaMail.www@wwinf1f22> References: <1414368409.6714.1498411216418.JavaMail.www@wwinf1f22> 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]); Mon, 26 Jun 2017 03:23:26 +0200 (CEST) X-Miltered: at korolev with ID 5950620E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5950620E.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 : 5950620E.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] Changing the route retraction X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jun 2017 01:23:31 -0000 > We think it works in theory, but we don't know whether it will work in > practice. The theoretical argument goes as follows. Let nh_A(P) be A's next-hop for prefix P. Babel's loop-freedom argument relies on the following invariant: if nh_A(P) = B then B has a selected route for prefix P. Obviously, this invariant can fail just after B retracts a route for prefix P and before the retraction has reached A, which is why RFC 6126 requires installing an unreachable route after receiving a retraction and keeping it around for a couple of minutes (Section 3.5.5). Gwendoline has noted that the invariant can be satisfied without respecting a Hold Time by sending the retraction reliably; as soon as all neighbours have sent the acknowledgement, node B as no longer the next-hop for any neighbour, and hence the unreachable entry can be removed. > When a Babel node retracts a route, it maintains the route unreachable > only until the first event between > (a) the node received an acknowledgement or the same > route retraction from each of its neighbours > (b) it's been more than 110 seconds (to avoid blocking indefinitely > because of weird neighbours). I think we can add a case -- it is okay to remove the entry as soon as each node has either sent the right acknowledgement or send a route retraction for prefix P. I think that we can put this as an optional algorithm in rfc6126bis. It would be nice to have an implementation, though. > This solution would reduce delays even with neighbours that don't > implement it. It would be the first use of the acknowledgements defined > in Babel. A node should send an acknowledgement for a route retraction > even if it isn't feasible or installed. Right on all counts. -- Juliusz From nobody Tue Jun 27 11:23:30 2017 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 6380712EAEA for ; Tue, 27 Jun 2017 11:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 cen1jXsMsCD5 for ; Tue, 27 Jun 2017 11:23:27 -0700 (PDT) Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (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 9D762129C07 for ; Tue, 27 Jun 2017 11:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498587806; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jucEyDBvbJd4yirMC9KMHySLyEzQPKmhSgGNz7BUuMg=; b=QmfoNQj6a4qfhi0tyIAUjB2mi4K5QGBK9igiBnOZNjshGjIojojaKzPO+ExxRFT+ ZAcqjGxz7Uh/2gvw0psQIYsCygaD0zKA/DsKjwdnX6K0Rr+8TVMiy0KipMwxvU3F KdDXRJsg8m8WZirPQxhaRHQqAO+NsE9wYwUQPtEg/d1G03weNctPMgPA0LdxBDyd +36e2lV+K9544khS7C4P+IgINfbsMbI5FVyJrfhyNrP3Sv/653BvA1BZoutIXw1b XTYDZyXyC/ovT8FHY6u58iCr0LhgbCGnk2ZFl43hAN7wb0M41pc09H54pnwQw68v qjXUuMN+7qpx6l77m2Zxyg==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id 67.55.17842.E92A2595; Tue, 27 Jun 2017 11:23:26 -0700 (PDT) X-AuditID: 11ab0218-4df929a0000045b2-17-5952a29ec7d5 Received: from jimbu (jimbu.apple.com [17.151.62.37]) by relay5.apple.com (Apple SCV relay) with SMTP id F8.F7.09344.D92A2595; Tue, 27 Jun 2017 11:23:26 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.114.153.254] (unknown [17.114.153.254]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OS7007SNXR10K70@jimbu.apple.com>; Tue, 27 Jun 2017 11:23:25 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <5CE399F9-8065-49D3-B32D-965D4A03EFB0@irif.fr> Date: Tue, 27 Jun 2017 11:23:25 -0700 Cc: babel@ietf.org, babel-users@lists.alioth.debian.org, Juliusz Chroboczek Message-id: <708CCBF5-EC6C-471A-BF38-6926FBE2F482@apple.com> References: <87h90a9nlz.wl-jch@irif.fr> <70ED4D66-B6BF-4D29-B24F-32A2C6779789@irif.fr> <87y3tdhy84.wl-jch@irif.fr> <87shivmsgz.wl-jch@irif.fr> <24969E1C-512C-4465-AC50-8889866A87FA@apple.com> <5CE399F9-8065-49D3-B32D-965D4A03EFB0@irif.fr> To: Matthieu Boutier X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUi2FAYoTtvUVCkQWeLocXXzw0sFlsWdbNY HP7SyGIxv3UZmwOLx5IlP5k8Fm95y+jx5lAfSwBzFJdNSmpOZllqkb5dAlfG/Mk3WAquSlZc udbA3sD4QbiLkZNDQsBEYvLOT2xdjFwcQgJrmCS65q0AcjjAEpM2ykDElzFKvOm+yAbSwCsg KPFj8j0WkBpmAXmJg+dlQcLMAloS3x+1soDYQgKNTBL7+3JAbGEBaYmuC3dZIWwjidmNv5hB WtmA6g+sMQIJcwpYS3w4NRuslUVAVeLmqbksECOjJVbv+88IsdVG4u2+3+wQ53xhlGjetI4V ZI6IgJrEs7uJEK/IStyafYkZpEZCYAabxPHJ9xknMArPQnL1LISrZyG5egEj8ypG4dzEzBzd zDwjE73EgoKcVL3k/NxNjKCgX80ksYPxy2vDQ4wCHIxKPLwakUGRQqyJZcWVuYcYpTlYlMR5 p84JjBQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAyJz2sOIm40yN83klAUxPq1KZDe5LTM5a v1vKVdNG8KXT58fWzW2fW2cu8CgWnuuziVPhzb+FjELTptqsVGn+O3/ewzePRMQK5JgSHDSd 7Gf1lWxPFj8rlCX8tV9QRvneiv8eM8S3BJmE7bhWec0sy9Fo9mWLF9VNMS+21LJddLrGfoix ssJAiaU4I9FQi7moOBEAOoBZT1sCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUiON1OVXfeoqBIg8kPOSy+fm5gsdiyqJvF 4vCXRhaL+a3L2BxYPJYs+cnksXjLW0aPN4f6WAKYo7hsUlJzMstSi/TtErgy5k++wVJwVbLi yrUG9gbGD8JdjBwcEgImEpM2ynQxcnEICSxjlHjTfZGti5GTg1dAUOLH5HssIDXMAvISB8/L goSZBbQkvj9qZQGxhQQamST29+WA2MIC0hJdF+6yQthGErMbfzGDtLIB1R9YYwQS5hSwlvhw ajZYK4uAqsTNU3NZIEZGS6ze958RYquNxNt9v9khzvnCKNG8aR0ryBwRATWJZ3cTQWokBGQl bs2+xDyBUWAWkkNnIRw6C8mhCxiZVzEKFKXmJFaa6iUWFOSk6iXn525iBIVoQ2HEDsb/y6wO MQpwMCrx8GpEBkUKsSaWFVfmHmKU4GBWEuHN7wUK8aYkVlalFuXHF5XmpBYfYpTmYFES55Xu AUoJpCeWpGanphakFsFkmTg4pRoYj3jFnzeJz6hf1fV8spnSJ9/LbzRK1NybRYOLvjxmWfoz 2Efrr9n20O6UK7PU4u90f9pzWnROwGcGNU8Lk/7Q25wxd4wcPj2/9YxX7dQ3bk4zmUsnjc5E mYgI+TKI3uoKUbqv8YpRYxHPYq64KqlzilN9+L9OSLT447ZqvtbmLLmdC0wZ7mgosRRnJBpq MRcVJwIAFC8h5k0CAAA= Archived-At: Subject: Re: [babel] [Babel-users] source sub-tlv X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jun 2017 18:23:29 -0000 > On Jun 21, 2017, at 09:15, Matthieu Boutier wrote: > >> I still do find (1) wasteful. > > I really would like to feel your intuition. From my point of view: > > - either you'll have very few some-specific routes, in which case the > waste is negligible (isn't it the case of multihomed networks ?), > > - or you'll have so much some-specific routes that non-specific routers > will be almost useless (and so you'll have to update them). You're right to call it an intuition, I do not have any experimental data or back of the envelope math to prove this. To be fair it might be overkill for me to worry about this at all. Because option (5) is built using a sub-TLV, it could always be added as an optimization later. >> (3) isn't that simple to define. > >> How about Proposal 5, which I define as: >> > >> By default, a vanilla wildcard request triggers a dump of all >> regular routes (by regular I mean from the original spec so >> not source-specific). We define a new non-mandatory sub-TLV >> on Route Requests called "Requested Route Types" that >> contains an array of all the types of routes this request is requesting. > > You need to say that routes resulting in a combination of extensions are > sent if each type of the extension is understood. (and if the node > understand such combination, but this is straightforward). > >> 0 = Regular >> 1 = Source-Specific >> 2 = TOS-specific >> etc. >> >> For example, if you send: >> [Type = TBD, Length=2, 0, 1] >> it means that you'd like all regular and source-specific routes. > > and if you send [type = RRT, length=2, 1, 2], it means that you'd like > source-specific routes, ToS-routes and source-tos-routes. Of course, > if the requesting node doesn't understand the combination, it might > receive a some wasteful routes... I think it's a safe assumption that if an implementation supports both extension A and extension B, it should support routes that combine both. > And, even if state is evil, this request can be encoded as the following > by requesting that wildcard requests are combined in the whole message. > > [Wildcard Route Request + source-specific sub-TLV] > [Wildcard Route Request + ToS-specific sub-TLV] > > In the babeld code, I would just put an int to handle that... Does this > make a 6th proposition ? > >> Thoughts? > > Summary: > > 1. Put one Wildcard Route Request (WRR). May waste routes. No parser > state. > > 3. Put one WRR per extension and per combinations. No wasted routes. > No parser state. > > 5. Define a new sub-TLV with one field per extension. Send understood > combinations. Might waste routes. No parser state. > > 6. Put one WRR per extension. Send understood combinations. Might > waste routes. Have a parser state (an int is clearly sufficient). > > I think I prefer 6 over 5. (My preferences are: 1 < 6 < 5 < 3). (6) feels more complicated than 5 to me, but it does have the benefit of being even more specific. All in all I can live with (1), especially if people agree that if (1) becomes a problem we'll work together to build an extension that fixes said problems. Thanks, David Schinazi From nobody Tue Jun 27 11:54:39 2017 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 47C1412EB05 for ; Tue, 27 Jun 2017 11:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 gsBqJHufjmdy for ; Tue, 27 Jun 2017 11:54:35 -0700 (PDT) Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (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 62AE5129AD5 for ; Tue, 27 Jun 2017 11:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498589674; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=oIpc/RBth/hlGFIF39Q+btqRIRLEbBZOtGLt4WsSnvo=; b=e3S2QM1BkG1RjgxI7BLRu1qvOueB4LKmGUh0Y0Ypj+6Er3X4UYKxbcgsd3u85cuU gw18aQg4YR70IbVYZC7qQCbQQLbjWOJf/hMULTIJYIeNyUzfEr7+zg5QVwuAXO/F cFUX3G9tkKjRJoOD0tWO0DxnH5lGm9LJFjDU8g35oVQZoy/oNsAOqWrT8+P4Bv0O H7ItiJD80Az1P5rZCltmXzudGMHot8pQEE4MK9ru6Zf59ZtXql7tKX40rMI8D1AO sFju4+wF3L4euwvEUv2cwqmKpDW/fV4uex4Xjxb8z68BjogJFHxDHD0yclPtDIfk 7aIgFpKEx7AFRNkNx7YjaQ==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id A5.CF.02110.AE9A2595; Tue, 27 Jun 2017 11:54:34 -0700 (PDT) X-AuditID: 11ab0219-4546b9a00000083e-2a-5952a9ea0a28 Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay2.apple.com (Apple SCV relay) with SMTP id 0F.31.08566.9E9A2595; Tue, 27 Jun 2017 11:54:33 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.236.16.223] (unknown [17.236.16.223]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OS7003QFZ6XYW60@nwk-phonehomebzp-sz01.apple.com>; Tue, 27 Jun 2017 11:54:33 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87a84vy22b.wl-jch@irif.fr> Date: Tue, 27 Jun 2017 11:54:32 -0700 Cc: Gwendoline , babel@ietf.org Message-id: <26BBC923-0896-46A0-8A37-6CEDEBE83484@apple.com> References: <1414368409.6714.1498411216418.JavaMail.www@wwinf1f22> <87a84vy22b.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUi2FDorPtqZVCkwbZTchZbFnWzWMxvXcZm 8fb4QzYHZo8lS34yeSze8pbR4/Pd9awBzFFcNimpOZllqUX6dglcGVPWrmQqmCdc0dFS3MC4 gL+LkZNDQsBEYse+5ewgtpDAGiaJKf+ruhjZweJ7tboYuYCixxglzi18yAhSwisgKPFj8j2W LkYODmYBeYmD52VBwswCWhLfH7WyQNQvZJLYd+QWC0hCWEBaouvCXVYI20jiZetsZpBeNqCG A2uMQMKcAhoSU09vAitnEVCV+Ph0JjvETEOJfau/s0CstZFYd2cWK8SVCRK3F19iA7FFBFQk lk97xg7xiazErdmXmEFukBDYwiax4ct61gmMwrOQnD0L4exZSM5ewMi8ilE4NzEzRzczz8hU L7GgICdVLzk/dxMjKMxXM0nuYPz62vAQowAHoxIPr0ZkUKQQa2JZcWXuIUZpDhYlcd6pcwIj hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTCqJW5sWvvjHeOerBlmYpt2u/S/+HPV4v/J3ZvP BCzsfNNTaMi0+uLHtVmXLZ+8Y3/77syps0Vu9lki644WMp74Yna4cplqaEZIs437lYi0Xs4D W+xrJr7oecL/QenbHU+T0+kvz8eGH4k2O/fH7/Leo2/bfmsLbte/cvdctHuKv7jxtP0GfApb lFiKMxINtZiLihMB8/Z7p1QCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUiON3OQfflyqBIgzW7bSy2LOpmsZjfuozN 4u3xh2wOzB5Llvxk8li85S2jx+e761kDmKO4bFJSczLLUov07RK4MqasXclUME+4oqOluIFx AX8XIzuHhICJxF6tLkYuDiGBY4wS5xY+ZOxi5OTgFRCU+DH5HksXIwcHs4C8xMHzsiBhZgEt ie+PWlkg6hcySew7cosFJCEsIC3RdeEuK4RtJPGydTYzSC8bUMOBNUYgYU4BDYmppzeBlbMI qEp8fDqTHWKmocS+1d9ZINbaSKy7MwtsjJBAgsTtxZfYQGwRARWJ5dOegdVLCMhK3Jp9iXkC o8AsJJfOQrh0FpJLFzAyr2IUKErNSaw00kssKMhJ1UvOz93ECArLhkLnHYzHllkdYhTgYFTi 4dWIDIoUYk0sK67MPcQowcGsJMKb3wsU4k1JrKxKLcqPLyrNSS0+xFgFdP9EZinR5HxgzOSV xBuamBiYGBubGRubm5hTRVhJnFeqB2izQHpiSWp2ampBahHMciYOTqkGRjX2+BOHta+aO6wO n17Z/SY8cMncKqvst6vkDOe+ZJQPPm0ROCmCT4rX1uxJY1/HTIMyCyvXiNZf3yPysgPY17Mx H6vq2j9/Re6RY2skJljeSp2sMMGo2Hg6646/zjL2ttrME/evefjVRGh5xVHZEyybVianZ9ep TLHwLtyt+TTP7kjxM54tSizFGYmGWsxFxYkATqo5x6YCAAA= Archived-At: Subject: Re: [babel] Changing the route retraction X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jun 2017 18:54:37 -0000 Gwendoline, Juliusz, Thanks for writing this up! To me, this sounds like a good idea that improves the protocol and as far as I can tell seems mathematically sound. The only remaining question is: will it fit nicely into the spec? Can you provide a PR against RFC6126bis? (I do agree with Juliusz that we'll want an implementation as well) Thanks, David Schinazi > On Jun 25, 2017, at 18:23, Juliusz Chroboczek wrote: > >> We think it works in theory, but we don't know whether it will work in >> practice. > > The theoretical argument goes as follows. Let nh_A(P) be A's next-hop for > prefix P. Babel's loop-freedom argument relies on the following > invariant: > > if nh_A(P) = B then B has a selected route for prefix P. > > Obviously, this invariant can fail just after B retracts a route for > prefix P and before the retraction has reached A, which is why RFC 6126 > requires installing an unreachable route after receiving a retraction and > keeping it around for a couple of minutes (Section 3.5.5). > > Gwendoline has noted that the invariant can be satisfied without > respecting a Hold Time by sending the retraction reliably; as soon as all > neighbours have sent the acknowledgement, node B as no longer the next-hop > for any neighbour, and hence the unreachable entry can be removed. > >> When a Babel node retracts a route, it maintains the route unreachable >> only until the first event between >> (a) the node received an acknowledgement or the same >> route retraction from each of its neighbours >> (b) it's been more than 110 seconds (to avoid blocking indefinitely >> because of weird neighbours). > > I think we can add a case -- it is okay to remove the entry as soon as > each node has either sent the right acknowledgement or send a route > retraction for prefix P. > > I think that we can put this as an optional algorithm in rfc6126bis. > It would be nice to have an implementation, though. > >> This solution would reduce delays even with neighbours that don't >> implement it. It would be the first use of the acknowledgements defined >> in Babel. A node should send an acknowledgement for a route retraction >> even if it isn't feasible or installed. > > Right on all counts. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Tue Jun 27 16:27:22 2017 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 CD6991287A7 for ; Tue, 27 Jun 2017 16:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 rTwclLwIIgcJ for ; Tue, 27 Jun 2017 16:27:18 -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 9E4CB128B91 for ; Tue, 27 Jun 2017 16:27:18 -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/56228) with ESMTP id v5RNRDxl014860; Wed, 28 Jun 2017 01:27:13 +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 33BA0EB2F0; Wed, 28 Jun 2017 01:27:13 +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 poC4FmUyejoE; Wed, 28 Jun 2017 01:27:12 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E9491EB2D0; Wed, 28 Jun 2017 01:27:11 +0200 (CEST) Date: Wed, 28 Jun 2017 01:27:11 +0200 Message-ID: <871sq56mgg.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Gwendoline , babel@ietf.org In-Reply-To: <26BBC923-0896-46A0-8A37-6CEDEBE83484@apple.com> References: <1414368409.6714.1498411216418.JavaMail.www@wwinf1f22> <87a84vy22b.wl-jch@irif.fr> <26BBC923-0896-46A0-8A37-6CEDEBE83484@apple.com> 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, 28 Jun 2017 01:27:13 +0200 (CEST) X-Miltered: at korolev with ID 5952E9D1.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5952E9D1.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 : 5952E9D1.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] Changing the route retraction X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jun 2017 23:27:21 -0000 > The only remaining question is: will it fit nicely into the spec? > Can you provide a PR against RFC6126bis? Yeah, we'll do that. Unfortunately it's exam season right now, so I'm suffering a mild case of work overload. -- Juliusz From nobody Wed Jun 28 09:36:31 2017 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 1A8B7129B53 for ; Wed, 28 Jun 2017 09:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 gOGJSGcVlKAB for ; Wed, 28 Jun 2017 09:36: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 6D3E1129ADF for ; Wed, 28 Jun 2017 09:36:27 -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/56228) with ESMTP id v5SGaPOj004130 for ; Wed, 28 Jun 2017 18:36:25 +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 85FC1EB2CC for ; Wed, 28 Jun 2017 18:36:25 +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 ZDdDIL8SUmgm for ; Wed, 28 Jun 2017 18:36:24 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3EDD3EB274 for ; Wed, 28 Jun 2017 18:36:23 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.89) (envelope-from ) id 1dQFx1-0002Af-L4 for babel@ietf.org; Wed, 28 Jun 2017 18:36:23 +0200 Date: Wed, 28 Jun 2017 18:36:23 +0200 Message-ID: <7itw30rrw8.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 [194.254.61.138]); Wed, 28 Jun 2017 18:36:25 +0200 (CEST) X-Miltered: at korolev with ID 5953DB09.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5953DB09.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 : 5953DB09.002 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] Making aggregation possible in Babel (Chouasne's algorithm) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 28 Jun 2017 16:36:30 -0000 I've just written up the algorithm that allows using aggregation in Babel without endangering loop-freedom. I've chosen to MUST the very minimal behaviour that has a chance to avoid loops, and to SHOULD either the old behaviour (hold time) or Chouasne's algorithm, either of which guarantees the absence of loops in this case. Please see https://github.com/jech/babel-drafts/commit/ee693a718f18925b7a1c1fdcf5a578511be6744f I'm not very happy with the wording. -- Juliusz From nobody Wed Jun 28 16:40:12 2017 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 8FBD8126BF0 for ; Wed, 28 Jun 2017 16:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 JSJ-jPGecY3Y for ; Wed, 28 Jun 2017 16:40:08 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 6438512EC1A for ; Wed, 28 Jun 2017 16:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498693207; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=G53nPp5SkkdpEgSXtZce+gCPvKkU6tj1jR7Gl5C3Hsw=; b=j5cexTHjd/KEZfit5eiutG27FaPZHYJx5ujfKl/mpK0Su1P41hN3SboW6rX1o5WP uwL9fSHN6lNYH+xpFQw2L32Z7by87ObSVvUxQ9Q25mbwzuVB7Jp1LpDkZLkQ3Bol dTcpCCnvOa5PztJq2mLT64zSma2/LfVzSjW79Ut8G+wK0v9fC8XSl3tJH4ddPfBR SP/zwc3+mCr9isRGzcXfQXwtBqCKiLFyFyrUf5z3pSk+ewX4TFMnDS+yx+vqR9W4 BX19zraXRh7BdEj6iJ55DMjwtQ13QQJk2u2RvUmLxQuqKlNbIZoUVIrFK14fq1f5 hJqVOC88bqPoUAuuEbJRUA==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id A0.F0.06195.75E34595; Wed, 28 Jun 2017 16:40:07 -0700 (PDT) X-AuditID: 11973e16-405ff70000001833-13-59543e576e29 Received: from kencur (kencur.apple.com [17.151.62.38]) by relay5.apple.com (Apple SCV relay) with SMTP id 89.E0.09344.65E34595; Wed, 28 Jun 2017 16:40:07 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Ko8n/eiuu6jfr1xsnrRCPA)" Received: from da0602a-dhcp207.apple.com (da0602a-dhcp207.apple.com [17.226.23.207]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OSA008VD72U7Q40@kencur.apple.com>; Wed, 28 Jun 2017 16:40:06 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Wed, 28 Jun 2017 16:40:06 -0700 In-reply-to: <7itw30rrw8.wl-jch@irif.fr> Cc: babel@ietf.org To: Juliusz Chroboczek References: <7itw30rrw8.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUi2FAYoRtuFxJp0L2Ux2LLom4Wi/mty9gc mDyWLPnJ5LF4y1vGAKYoLpuU1JzMstQifbsEroxJXzYwFxxwrJjy7xNTA+Mr8y5GTg4JAROJ 7idXmLsYuTiEBFYzSXQt6mWHSXzc/4MFIrGCUeJq92EmkASvgKDEj8n3WEBsZoEwiUtvH7FC FC1kkvgw5QkjSEJYQFqi68JdoAQHB5uAlsSBNUYgJq+AjcTZlboQFQES338tAqtmEVCVeHzg M9heTgENiX0vFrFBjBeSOHNtBtgqEQEVieXTnoHVCAmoS8xrX8ECcaesxK3Zl8AekBA4wSax 4dIP9gmMQrOQnDoLyakQtpbE90etQHEOIFte4uB5WYiwpsSze5/YIWxtiSfvLrAuYGRbxSiU m5iZo5uZZ66XWFCQk6qXnJ+7iREUCdPtxHYwPlxldYhRgINRiYd3xargSCHWxLLiytxDjNIc LErivF+0QiKFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MHZpZghwrig92BdiNlNnxakvbWLb LnbrvyheJ/y7sreAqcNw1lmpgIdc8+6rl9ge2H52X5jlp1Wxi2omyXt2y4V39jlKNjZoNzCL BeTOnKZzt6t0jUaagsF8Pu6+WfNq6ja0npjTYDLxwaUTjql15pmZa8vDfnj7ePBU/LZaJOJm eazGdts2JZbijERDLeai4kQAkPavw2UCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUiON1OTTfcLiTSYMJHdosti7pZLOa3LmNz YPJYsuQnk8fiLW8ZA5iiuGxSUnMyy1KL9O0SuDImfdnAXHDAsWLKv09MDYyvzLsYOTkkBEwk Pu7/wdLFyMUhJLCCUeJq92EmkASvgKDEj8n3WEBsZoEwiUtvH7FCFC1kkvgw5QkjSEJYQFqi 68JdoAQHB5uAlsSBNUYgJq+AjcTZlboQFQES338tAqtmEVCVeHzgMzuIzSmgIbHvxSI2iPFC EmeuzQBbJSKgIrF82jOwGiEBdYl57StYIO6Ulbg1+xLzBEb+WUium4XkOghbS+L7o1agOAeQ LS9x8LwsRFhT4tm9T+wQtrbEk3cXWBcwsq1iFChKzUmsNNVLLCjISdVLzs/dxAgK3IbCiB2M /5dZHWIU4GBU4uFdsSo4Uog1say4MvcQowQHs5IIL5d5SKQQb0piZVVqUX58UWlOavEhxomM QE9OZJYSTc4HxlVeSbyhiYmBibGxmbGxuYk5LYWVxHlX3AY6UiA9sSQ1OzW1ILUI5igmDk6p BsZLW1ZVJ7bvXCNwx+CxbIeHjJDquR59vUmiq4JkZz294OyRuGfxN8Mf6RGJ5mu477R/uiw8 Pbrw/p9Wpm3LMzbvPCr0wXiZZsSJG8yKii9e6xUlX3zefM8wWkqQZY7C5Ot+EhzPPsytavaa vnVvlfnycu2K32H7/1qVuXieuf18qeSL7ef7vvApsRRnJBpqMRcVJwIANPuWZc8CAAA= Archived-At: Subject: Re: [babel] Making aggregation possible in Babel (Chouasne's algorithm) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 28 Jun 2017 23:40:10 -0000 --Boundary_(ID_Ko8n/eiuu6jfr1xsnrRCPA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Juliusz, Thanks for writing this up! The wording does feel heavy though. Here's an attempt at refactoring it based on your text: https://github.com/jech/babel-drafts/pull/4/files Here's the resulting text, let me know what you think. 3.5.5. Hold Time When a prefix P is retracted, because all routes are unfeasible or have an infinite metric (whether due to the expiry timer or to other reasons), and a shorter prefix P' that covers P is reachable, P' cannot in general be used for routing packets destined to P without running the risk of creating a routing loop (Section 2.8). To avoid this issue, whenever a prefix P is retracted, a routing table entry with infinite metric is inserted as described in Section 3.5.4 above. As long as this entry is maintained, packets destined to an address within P MUST NOT be forwarded by following a route for a shorter prefix. The infinite metric entry MUST be maintained at least until it is guaranteed that no neighbour has selected the current node as next-hop for prefix P. This can be achieved by either: o waiting until the route's expiry timer has expired (Section 3.5.4) o sending a retraction with an acknowledgement request (Section 3.3) to every neighbour that has not explicitly retracted prefix P and waiting for all acknowledgements The former option is simpler and ensures that at that point, any routes for prefix P pointing at the current node have expired. However, since the expiry time can be as high as a few minutes, doing that prevents automatic aggregation by creating spurious black-holes for aggregated routes. The latter option is RECOMMENDED as it reduces convergence time. Additionally, if a finite-metric feasible update for prefix P is received and the resulting route selected, the infinite-metric entry is overridden and removed. Thanks, David Schinazi > On Jun 28, 2017, at 09:36, Juliusz Chroboczek wrote: > > I've just written up the algorithm that allows using aggregation in Babel > without endangering loop-freedom. I've chosen to MUST the very minimal > behaviour that has a chance to avoid loops, and to SHOULD either the old > behaviour (hold time) or Chouasne's algorithm, either of which guarantees > the absence of loops in this case. > > Please see > > https://github.com/jech/babel-drafts/commit/ee693a718f18925b7a1c1fdcf5a578511be6744f > > I'm not very happy with the wording. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --Boundary_(ID_Ko8n/eiuu6jfr1xsnrRCPA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Juliusz,

Thanks for writing this up! The wording does feel heavy = though.

Here's = an attempt at refactoring it based on your text:
https://github.com/jech/babel-drafts/pull/4/files

Here's the resulting = text, let me know what you think.

3.5.5.  Hold = Time

  =  When a prefix P is retracted, because all routes are unfeasible = or
   have an infinite metric (whether = due to the expiry timer or to other
  =  reasons), and a shorter prefix P' that covers P is reachable, = P'
   cannot in general be used for = routing packets destined to P without
  =  running the risk of creating a routing loop (Section = 2.8).

  =  To avoid this issue, whenever a prefix P is retracted, a = routing
   table entry with infinite = metric is inserted as described in
  =  Section 3.5.4 above.  As long as this entry is maintained, = packets
   destined to an address within = P MUST NOT be forwarded by following a
  =  route for a shorter prefix.  The infinite metric entry MUST = be
   maintained at least until it is = guaranteed that no neighbour has
  =  selected the current node as next-hop for prefix P.  This can = be
   achieved by either:

   o =  waiting until the route's expiry timer has expired (Section = 3.5.4)

  =  o  sending a retraction with an acknowledgement request = (Section 3.3)
      to every = neighbour that has not explicitly retracted prefix P and
      waiting for all = acknowledgements

   The former option is simpler and ensures that at = that point, any
   routes for prefix P = pointing at the current node have expired.
  =  However, since the expiry time can be as high as a few minutes, = doing
   that prevents automatic = aggregation by creating spurious black-holes
  =  for aggregated routes.  The latter option is RECOMMENDED as = it
   reduces convergence time.

  =  Additionally, if a finite-metric feasible update for prefix P = is
   received and the resulting route = selected, the infinite-metric entry
   is = overridden and removed.


Thanks,
David Schinazi


On = Jun 28, 2017, at 09:36, Juliusz Chroboczek <jch@irif.fr> = wrote:

I've just written up the algorithm that allows using = aggregation in Babel
without endangering loop-freedom. =  I've chosen to MUST the very minimal
behaviour that = has a chance to avoid loops, and to SHOULD either the old
behaviour (hold time) or Chouasne's algorithm, either of = which guarantees
the absence of loops in this case.

Please see

=  https://github.com/jech/babel-drafts/commit/ee693a718f18925b7a1= c1fdcf5a578511be6744f

I'm not very = happy with the wording.

-- Juliusz

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

= --Boundary_(ID_Ko8n/eiuu6jfr1xsnrRCPA)-- From nobody Wed Jun 28 18:27:53 2017 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 8D1BF129A9C for ; Wed, 28 Jun 2017 18:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 ixiaz4cI9Qlj for ; Wed, 28 Jun 2017 18:27:50 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (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 E9D59127B5A for ; Wed, 28 Jun 2017 18:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498699670; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vGuh9eNUWNCy3vl8iTsEHigzZIxdJG+0aJs4USJPI5A=; b=GjJtDp3fJ+FEQ8q2t5Xv+vkjVoq80v/DQQJUiweGpiufdEn5rheOqiJnxM09jejP qBb1wPPzJs47iNyPzAWx77obPzB+jDSZhfiDHfJn8DO2ivioeJ6WPVKrlgYFTDw9 STuVCaTH9LgdYsOmPS+lr7Hq6BA4sYF5j5oUh5SxjHFESYpHGetNT/5Rfm/IqfQU XlNC1AgWf8euwt0DCQXRsAiXbtMnmXwgIRzvxj626MiHByfKsTQFLKA4Kz1Hy04U FEQWjw2m/6OuZGAXoxcoT82pbs3ujK44DIPdNSzu5hRalN7RP8nmp4J+iyF7oeoC fN1wCGNiO0kXZbU70lrMeg==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id B6.41.06961.69754595; Wed, 28 Jun 2017 18:27:50 -0700 (PDT) X-AuditID: 11973e15-9dace9c000001b31-7e-5954579622a5 Received: from koseret (koseret.apple.com [17.151.62.39]) by relay4.apple.com (Apple SCV relay) with SMTP id AE.49.01343.69754595; Wed, 28 Jun 2017 18:27:50 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_tOxk/MNS8zI0Wf1VVEfoRA)" Received: from da0602a-dhcp207.apple.com (da0602a-dhcp207.apple.com [17.226.23.207]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OSA00A3LC2EHQ00@koseret.apple.com>; Wed, 28 Jun 2017 18:27:50 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Wed, 28 Jun 2017 18:27:50 -0700 Cc: Babel at IETF To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUi2FAYrjstPCTS4MZVI4sti7pZLOa3LmNz YPJYsuQnk8fiLW8ZA5iiuGxSUnMyy1KL9O0SuDJOd9xgLpjAWfHx4j+WBsYFHF2MHBwSAiYS 31uSuxi5OIQEVjNJrO2czN7FyAkWf9s3lxEisYpR4srGz2wgCV4BQYkfk++xgNjMAmES8y6e ZIIoWswksXDnK7BuYQFpia4Ld1lBNrAJaEkcWGMEETaTuHHuLCPEHBuJ99f2MYPYLAKqErcO nmKHmKkksfrbHbC4iICKxPJpz6AOkpW4NfsSM8guCYEVbBLtD4+wTGAUmIXkpllIboKwtSS+ P2oFinMA2fISB8/LQoQ1JZ7d+8SOJLyAkW0Vo1BuYmaObmaemV5iQUFOql5yfu4mRlBYT7cT 3cF4ZpXVIUYBDkYlHt4Vq4IjhVgTy4orcw8xSnOwKInzftUKiRQSSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXAGLXmtsdDVo+IxgdPP9+9Xf78t78hb2i6Yxqj5J9rVzW3/nl35WhN8TT9P29X dT+qLZl+uzdxl8RH64rEJEtZrkPXde+9449t2PKtOV2rnef3749f+6K3X79wZHXRzmMy6ROW FO8RVFB+FhYRGCa/1XqGQME/3m3pngvnWJYKP+Tg/rz3YurWUCWW4oxEQy3mouJEAOv14gVM AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUiON1OXXdaeEikwfVf+hZbFnWzWMxvXcbm wOSxZMlPJo/FW94yBjBFcdmkpOZklqUW6dslcGWc7rjBXDCBs+LjxX8sDYwLOLoYOTkkBEwk 3vbNZexi5OIQEljFKHFl42c2kASvgKDEj8n3WEBsZoEwiXkXTzJBFC1mkli48xU7SEJYQFqi 68Jd1i5GDg42AS2JA2uMIMJmEjfOnWWEmGMj8f7aPmYQm0VAVeLWwVPsEDOVJFZ/uwMWFxFQ kVg+7Rk7xEGyErdmX2KewMg7C8kZs5CcAWFrSXx/1AoU5wCy5SUOnpeFCGtKPLv3iR1JeAEj 2ypGgaLUnMRKE73EgoKcVL3k/NxNjKBAbCgM38H4b5nVIUYBDkYlHt4Vq4IjhVgTy4orcw8x SnAwK4nwcpmHRArxpiRWVqUW5ccXleakFh9inMgI9MtEZinR5HxgnOSVxBuamBiYGBubGRub m5jTUlhJnHfFbaAjBdITS1KzU1MLUotgjmLi4JRqYAyaluFhfT3y/PvYqFeLGm03h65329xd WG5+zSjMa/Lf1/cfHhaWnVGavLUgy3fpoc/f1q8Nuz9X8l/hV3utYjcryfztzsGX1qQtvPC+ Nl/B08IwfPvZCQ7RG44ebovhPrhop+jzrH39zgclRe4uC3n9Vy6QIehNzqfF/TIqIkec3A62 Pr12eqcSS3FGoqEWc1FxIgD1SZzstwIAAA== Archived-At: Subject: [babel] Minor edits to draft-ietf-babel-rfc6126bis-02 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 01:27:52 -0000 --Boundary_(ID_tOxk/MNS8zI0Wf1VVEfoRA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Juliusz, I sent out a PR with a flurry of minor edits to the doc: https://github.com/jech/babel-drafts/pull/5/files Let me know what you think. Thanks, David Schinazi --Boundary_(ID_tOxk/MNS8zI0Wf1VVEfoRA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Juliusz,

I sent out a PR with a flurry of minor edits to the doc:

Let me know what you think.

Thanks,
David Schinazi
--Boundary_(ID_tOxk/MNS8zI0Wf1VVEfoRA)-- From nobody Wed Jun 28 18:38:27 2017 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 4A35012EAEF for ; Wed, 28 Jun 2017 18:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 cWFFICGNcxrp for ; Wed, 28 Jun 2017 18:38:24 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 8D046127F0E for ; Wed, 28 Jun 2017 18:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498700304; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/t/HcLORADPr1a1VNwuWtWfY4oXbltsR9W/x02/6qrI=; b=ygW+QuASs9mPdRWr4D1GZVvh5mlL3b4tl63HAQ5OX4I0GAAAOIABl0TLWTWkmWTY U6NOwI+TM1eryujuMuPnST/P+QPGJ+5bEdVZNUzu63M51WK7Gmf6py/TPIp4hVK5 YbdMhKMAxpxsXfgRMkY2ULp0WOMKtXAaoy278mTakJyUf0KB1Vk9auxpkznI+8CT sm94HY+b56QMjbmwZfbxL+f7zzIA806lFKeh8ThIYSzHtDrkaHxKzAR7pZn15/oQ ZOutt07O6bA7qtecFxAIa7nMMwevzjejZeaUWZ0tMi+Q4hH8LCW4gahugQRk1sLO P8+ftpD7fwU4Ki2NXyeF0A==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 03.B7.07214.01A54595; Wed, 28 Jun 2017 18:38:24 -0700 (PDT) X-AuditID: 11973e11-7d2f59c000001c2e-43-59545a10f4da Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay4.apple.com (Apple SCV relay) with SMTP id 73.07.01343.F0A54595; Wed, 28 Jun 2017 18:38:24 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_YY8iIZdnvnj7wLiTCpVJaA)" Received: from da0602a-dhcp207.apple.com (da0602a-dhcp207.apple.com [17.226.23.207]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OSA005GVCJZ0Z20@nwk-phonehomebzp-sz01.apple.com> for babel@ietf.org; Wed, 28 Jun 2017 18:38:23 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Wed, 28 Jun 2017 18:38:23 -0700 To: Babel at IETF X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FAYrisQFRJpMOehuMWWRd0sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKOPTvCXvBLMWKpVPmsTUwNsh2MXJySAiYSGw79pGli5GLQ0hg NZPEh0/HWGASN9tnskIkjjFK/Oh5xQ6S4BUQlPgx+R5YEbNAmETv6bVMEEUXmCTOnp8OViQs IC3RdeEuUDcHB5uAlsSBNUYQYSWJ2793sUHMsZG4uLiRCaSERUBV4naXDUhYBKhk882fzBA3 yErcmn2JGWS8hEAPm8Str7fZJjDyz0JyxiwkZ0DYWhLfH7UCxTmAbHmJg+dlIcKaEs/ufWKH sLUlnry7wLqAkW0Vo1BuYmaObmaekV5iQUFOql5yfu4mRlCwTrcT3MF4fJXVIUYBDkYlHt4V q4IjhVgTy4orcw8xSnOwKInzftcKiRQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAuED8M8fd 6kgB3qa7s51CS0VvZ944t+LXjhivpZX+Hes3Ckyw2zQt5NJpdYWmFdyToj9M/3pqcVH+lprX 51mSX079p+TSZpi7+2pNOnv3YqMCnhopTrPZ5ja8rLefhl8Vuvd/tVD+xdq3Wz/uizQw9MqZ 73n+8ZMLzW9TH17OykkQ/vGCU3DzMyWW4oxEQy3mouJEAESPdbc3AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42IRnG7noCsQFRJpcHmrsMWWRd0sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKOPTvCXvBLMWKpVPmsTUwNsh2MXJySAiYSNxsn8naxcjFISRw jFHiR88rdpAEr4CgxI/J91hAbGaBMIne02uZIIouMEmcPT8drEhYQFqi68JdoG4ODjYBLYkD a4wgwkoSt3/vYoOYYyNxcXEjE0gJi4CqxO0uG5CwCFDJ5ps/mSFukJW4NfsS8wRGnllINs9C shnC1pL4/qgVKM4BZMtLHDwvCxHWlHh27xM7hK0t8eTdBdYFjGyrGAWKUnMSK030EgsKclL1 kvNzNzGCgquhMHwH479lVocYBTgYlXh4V6wKjhRiTSwrrsw9xCjBwawkwstlHhIpxJuSWFmV WpQfX1Sak1p8iHEiI9D9E5mlRJPzgaGfVxJvaGJiYGJsbGZsbG5iTkthJXHeFbeBjhRITyxJ zU5NLUgtgjmKiYNTqoGxqbI++KmtjN6DbYz3zswOm5yTGFf/nLfz217dr4L3PjY7vdNa+OBk iXuaiK3o40Oi6a1Rs/35VdSyvB5XnT8/Q6RddGl91JkuiUILZvlWdwXNxL7yg7K/RRU3Z3E/ ejlHnjWdn7fZSD31ZCJ7zGQ+XfGQ/Goh3VbT8v2LYviWld7VY5kvqsRSnJFoqMVcVJwIABcj IMShAgAA Archived-At: Subject: [babel] Forwarding Seqno Requests X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 01:38:26 -0000 --Boundary_(ID_YY8iIZdnvnj7wLiTCpVJaA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi everyone, I'm resurrecting a conversation from a long time ago: https://www.ietf.org/mail-archive/web/babel/current/msg00455.html Section 3.8.1.2 (Seqno Requests) contains the following: A node SHOULD maintain a list of recently forwarded requests and forward the reply (an update with a sufficiently large seqno) in a timely manner. A node SHOULD compare every incoming request against its list of recently forwarded requests and avoid forwarding it if it is redundant. However it does not clearly define what redundant means here, what should this table be indexed on? Should the table of pending seqno requests be indexed by routerID too? Should the table of pending seqno requests also contain the destination neighbor we sent it to? This would allow to ensure we do not send it to more than one neighbor, which is a MUST in the spec. Thanks, David Schinazi --Boundary_(ID_YY8iIZdnvnj7wLiTCpVJaA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi everyone,

I'm resurrecting a conversation from a long time = ago:
https://www.ietf.org/mail-archive/web/babel/current/msg00455.ht= ml

Section 3.8.1.2 (Seqno Requests) contains the = following:

   A node SHOULD = maintain a list of recently forwarded requests and
  =  forward the reply (an update with a sufficiently large seqno) in = a
   timely manner.  A node SHOULD compare every = incoming request against
   its list of = recently forwarded requests and avoid forwarding it if = it
   is redundant.

However it = does not clearly define what redundant means here, what
should this = table be indexed on?

Should the = table of pending seqno requests be indexed by routerID = too?

Should the = table of pending seqno requests also contain the destination
neighbor we sent it to? This would allow to ensure we do not = send it to
more than one neighbor, = which is a MUST in the spec.

Thanks,
David = Schinazi
= --Boundary_(ID_YY8iIZdnvnj7wLiTCpVJaA)-- From nobody Wed Jun 28 18:44:31 2017 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 EA229129AE9 for ; Wed, 28 Jun 2017 18:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 GiDhZx0_bASL for ; Wed, 28 Jun 2017 18:44:28 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 5CDA4127419 for ; Wed, 28 Jun 2017 18:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498700668; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IaO+zh9/GIaBFvuRAMm+UXLiOYSRAleC73LHuZmEZYY=; b=o1A7MGcfJ00b2H14mp+tocQHaq+TBqveaCX6R4TYOyqO5JP8TpdDdHFKTASX0Bda uvDMTIr/Igae+hjXTO3ULB0bvA4eSGsjALnK9hPVBnohPV4b2kGc+wInh8sp9Aly IkLNTsv0AQGT3erPY4RG8+2e8hXIE+oQVPbduLgkr/b0WjIsIXXek5pm6SZfC4XQ 2KoN57hLSfEHf9VZnC4OE/mYO8sRcrahvGJZ1YzZl6J1iNwFcHz5lxF//qhjBTHB AuF/kgYF0KsKTFcAlCoRi+5ciF3x1YjI33110ATL3R6L55YN0SdTfPS9n6fO98Hu xJ6RErNHn1/7RrqD1nz0ZA==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id DF.93.06336.C7B54595; Wed, 28 Jun 2017 18:44:28 -0700 (PDT) X-AuditID: 11973e12-c4dff700000018c0-e9-59545b7c31c0 Received: from jimbu (jimbu.apple.com [17.151.62.37]) by relay8.apple.com (Apple SCV relay) with SMTP id 19.E6.05704.B7B54595; Wed, 28 Jun 2017 18:44:28 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_fSv9zDWJRRUJq5Ij5rn6uQ)" Received: from da0602a-dhcp207.apple.com (da0602a-dhcp207.apple.com [17.226.23.207]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OSA005C9CU3A720@jimbu.apple.com> for babel@ietf.org; Wed, 28 Jun 2017 18:44:27 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Wed, 28 Jun 2017 18:44:27 -0700 To: Babel at IETF X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FCYplsTHRJpcOUtp8WWRd0sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKmLp0AlPBfuGKn1ffMDcw/hfoYuTkkBAwkfiw4ARLFyMXh5DA GiaJ7l/n2GESd2c9ZoJILGOU+LD+ICNIgldAUOLH5HssIDazQJjEhiVbwOJCAhuYJI6drASx hQWkJbou3GXtYuTgYBPQkjiwxggibC1xv+c51BgbidZHp5hBbBYBVYkFLZfAbBEBJYnNN38y Q9wgK3FrNkicC8iewiYxe+p51gmM/LOQnDELyRkQtpbE90etQHEOIFte4uB5WYiwpsSze5/Y IWxtiSfvLrAuYGRbxSiUm5iZo5uZZ6KXWFCQk6qXnJ+7iREUrNPthHYwnlpldYhRgINRiYeX YW1wpBBrYllxZe4hRmkOFiVx3i9aIZFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGGUni9sX 6G+dNetwZ/riuSZp8Y/bbNcus51ttu64/6urdhmiPeyJa1bpfcietdZLR8zV60v//7OV7GIn eJOqTm3e9Ey1ba+XwvHre56yCR37Z35wxU2z6zsvRmR7f9l+bFViwkL/griFmy5Nv/IrJiam nF+FfYm2ZNF/xb6TN77f1j5lVTjvbawSS3FGoqEWc1FxIgBKVZOvNwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42IRnG6nqlsTHRJp8PoFq8WWRd0sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKmLp0AlPBfuGKn1ffMDcw/hfoYuTkkBAwkbg76zFTFyMXh5DA MkaJD+sPMoIkeAUEJX5MvscCYjMLhElsWLIFLC4ksIFJ4tjJShBbWEBaouvCXdYuRg4ONgEt iQNrjCDC1hL3e55DjbGRaH10ihnEZhFQlVjQcgnMFhFQkth88yczxA2yErdmX2KewMgzC8nm WUg2Q9haEt8ftQLFOYBseYmD52UhwpoSz+59YoewtSWevLvAuoCRbRWjQFFqTmKlhV5iQUFO ql5yfu4mRlBwNRSm7WBsWm51iFGAg1GJh3fFquBIIdbEsuLK3EOMEhzMSiK8XOYhkUK8KYmV ValF+fFFpTmpxYcYJzICPTCRWUo0OR8Y+nkl8YYmJgYmxsZmxsbmJua0FFYS511xG+hIgfTE ktTs1NSC1CKYo5g4OKUaGK+/mB/xYx0XY/gK7rfr1+R1Ml/RNI5yS3xY9WT2l2h1sfith2c1 LHFYFH6l0SmlJryy5vKekjsfGP5+PDiRn2HhpJ/60/+wBMSnvhULs1TVEP5l4RpjOs2n58Ht Gw1smj/3Lb/rpbpN8+mOhN2+23RbHvZPfv83Z+pNzULJ9btyXpVJu9VbSSuxFGckGmoxFxUn AgCVNZrjoQIAAA== Archived-At: Subject: [babel] Sub-TLVs, flags and Isolation in the IANA registry X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 01:44:30 -0000 --Boundary_(ID_fSv9zDWJRRUJq5Ij5rn6uQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi everyone, Currently the Babel IANA registry contains one registry for sub-TLVs and one registry for flags. https://www.iana.org/assignments/babel/babel.xhtml The RFC6126 flags are meant for the Update TLV. The current work-in-progress version of the draft introduces Hello Flags and got me thinking: 1) Should we have two separate registries: - Hello Flags (16 bits) - Update Flags (8 bits) 2) Should we have one sub-TLV registry per TLV? The majority of currently defined sub-TLVs only make sense for one TLV, so I wonder if sharing the space will cause us to run out of sub-TLVs prematurely. Thoughts? Thanks, David Schinazi --Boundary_(ID_fSv9zDWJRRUJq5Ij5rn6uQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi everyone,

Currently the Babel IANA registry contains one registry for = sub-TLVs and one registry for flags.
https://www.iana.org/assignments/babel/babel.xhtml
The RFC6126 flags are meant for the Update TLV.

The current = work-in-progress version of the draft introduces Hello Flags and got me = thinking:

1) = Should we have two separate registries:
- Hello = Flags (16 bits)
- Update Flags (8 bits)

2) Should we have one = sub-TLV registry per TLV?
The majority of currently = defined sub-TLVs only make sense for one TLV,
so I = wonder if sharing the space will cause us to run out of sub-TLVs = prematurely.

Thoughts?

Thanks,
David = Schinazi
= --Boundary_(ID_fSv9zDWJRRUJq5Ij5rn6uQ)-- From nobody Wed Jun 28 21:45:19 2017 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 43C10129B3A; Wed, 28 Jun 2017 21:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCdMrs9RI7wh; Wed, 28 Jun 2017 21:45:17 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 D180A129562; Wed, 28 Jun 2017 21:45:16 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id k192so882151ith.1; Wed, 28 Jun 2017 21:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5XwH6tyDmxlUaPVAUO+oRKVB3RwPeyQkkC5doYqwTxc=; b=HqfioUmt4YL3/EU1y7v42vRxoq/yriFgr5a6K2xhDFdb/2qm1AbQ2E9pEB/YIBiKYw /4YELvqYxiY0SCCZK/rMRbiogO0Saoq1nbZv6ADREDpo9oJqVWyMtInIeaxUAgeWD0g/ +Szm+Bl/ZCQEZQ5EAFsaJeKyED9TME6VB4dl/kz20QUJdUntP9H7MiW6IlhLuKSCODtI 4DWC899dSFpyAm2GsFOVkKl2xvwvBMALZcltRT9Ij0fUloCteFRf4ot6PYqDhfSYM2DR R0FIi/BY6LX5z0PEqWcxVpT8xrjgnEacJ+UUwc89DjxHN1hdixC9YzTbK1Q2OAiUOOP+ 7f2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5XwH6tyDmxlUaPVAUO+oRKVB3RwPeyQkkC5doYqwTxc=; b=AtVVviz5Yx/vXxXoDQW8mW2HVtC+yQLRS466YpmUSeSzTQ8kjKtXMJgREvm3QqkIiY x0z/J9VjFKRJFuNC4P4bl7fxMb6BgDBqL4/abya2j7adw31ZkE3J/+RvzrMlY7eRyfnJ jsAY+t/r0jZvNprCdeFqA7ofglxf9aTWe2bpVtFSqW4IrUkrnPbvPOCCNY+9FFiA1eZd 3yXL1ZghdEM80Yadxv2G5QJUVFNfSUBuESocatRw6ZcNdl2VrYrq1qZmyj7RjDmTGjej 7Z2O7h9DT36dx8SeQmVrrNtocue4tvl3bnJEhdqJPpFZmqlsshk2UsC+1ZiZPOwDtl3X 5CsA== X-Gm-Message-State: AKS2vOxvZ9QHRGmq/id23thH/rTqmGp/XuE5i0BMnVC5I6KmUMPmVv0d pRwv5DF/zyiJyvVCS4s41XA2xMTX3Q== X-Received: by 10.36.150.133 with SMTP id z127mr12602560itd.104.1498711516174; Wed, 28 Jun 2017 21:45:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.221 with HTTP; Wed, 28 Jun 2017 21:45:00 -0700 (PDT) In-Reply-To: <7578E84A-85F0-423D-83FF-40C4FBF8D9A4@irif.fr> References: <43C01567-B680-41AA-9B7D-6EAF3BEF69D1@apple.com> <2D09D61DDFA73D4C884805CC7865E6114DB996D0@GAALPA1MSGUSRBF.ITServices.sbc.com> <7578E84A-85F0-423D-83FF-40C4FBF8D9A4@irif.fr> From: Donald Eastlake Date: Thu, 29 Jun 2017 00:45:00 -0400 Message-ID: To: Matthieu Boutier Cc: "babel-chairs@ietf.org" , Babel at IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] Call for Babel presentations at IETF-99 in Prague X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 04:45:18 -0000 Hi, Sorry for the delay in replying. The Babel session is pretty full. We have added you as the last item (see https://datatracker.ietf.org/meeting/99/agenda/babel/) so there is some risk to your presentation, depending on future changes to the agenda and/or if earlier items run over. Although it is possible this will change, it is very likely the Babel session at the IETF Prague meeting will be 17:40 to 18:40 Monday afternoon. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Mon, Jun 19, 2017 at 6:59 PM, Matthieu Boutier wrote: > Hi, > > I would like to present my source-specific extension with mandatory bit [1]. I think > a 10 minute slot would be great. > > [1] https://datatracker.ietf.org/doc/draft-boutier-babel-source-specific/ > > Thanks, > Matthieu From nobody Thu Jun 29 10:59:00 2017 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 C7046127735 for ; Thu, 29 Jun 2017 10:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 DZ08_2aFqi93 for ; Thu, 29 Jun 2017 10:58:57 -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 4053B126B7E for ; Thu, 29 Jun 2017 10:58:57 -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/56228) with ESMTP id v5THwqnm008901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Jun 2017 19:58:52 +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/56228) with ESMTP id v5THwq0n012304; Thu, 29 Jun 2017 19:58:52 +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 38318EB2F0; Thu, 29 Jun 2017 19:58:52 +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 ScROeDdYajBb; Thu, 29 Jun 2017 19:58:50 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 47E7DEB2D0; Thu, 29 Jun 2017 19:58:50 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.89) (envelope-from ) id 1dQdiL-0003EC-S8; Thu, 29 Jun 2017 19:58:50 +0200 Date: Thu, 29 Jun 2017 19:58:49 +0200 Message-ID: <7i8tkasmjq.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Babel at IETF In-Reply-To: References: 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]); Thu, 29 Jun 2017 19:58:52 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 29 Jun 2017 19:58:52 +0200 (CEST) X-Miltered: at korolev with ID 59553FDC.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 59553FDC.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59553FDC.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 59553FDC.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 : 59553FDC.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 59553FDC.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] Sub-TLVs, flags and Isolation in the IANA registry X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 17:59:00 -0000 Hi David, > 1) Should we have two separate registries: > - Hello Flags (16 bits) > - Update Flags (8 bits) Yes. > 2) Should we have one sub-TLV registry per TLV? No. > The majority of currently defined sub-TLVs only make sense for one TLV, RFC 7557 Section 2.3 says: An extension MAY be assigned one or more sub-TLV types. Sub-TLV types are assigned independently from TLV types: the same numeric type can be assigned to a TLV and a sub-TLV. Sub-TLV types are assigned globally: once an extension is assigned a given sub-TLV number, it MAY use this number within any TLV. However, the interpretation of a given sub-TLV type can depend on which particular TLV it is embedded within. So if you define a new extension, you get a sub-TLV number. It's your own, no other extension will get the same number. You can use it with multiple TLVs, you can use it with just one TLV. It's up to you, it's your extension. The advantage is that there is just one registry, and that when you see a sub-TLV, you immediately know which extension it comes from. Another advantage is that sub-TLVs can be used with any TLV, even TLVs that were not defined at the time the registry has been set up. > so I wonder if sharing the space will cause us to run out of sub-TLVs prematurely. I don't think even IS-IS has more than 220 extensions ;-) If we ever run out of sub-TLV numbers, we'll switch to 16-bit sub-TLV numbers: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Subtype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Body +-+-+-+-+-+-+-+-+- Type is 127 or 255, depending on whether the mandatory bit is set. Subtype is a 16-bit integer that defines the sub-TLV. And by the time we run out of 16-bit sub-TLV numbers, I'll be dead, so I won't care any more. But somebody who's still alive will define a format for 32-bit sub-TLV numbers: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Subtype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-subtype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Body +-+-+-+-+-+-+-+-+- -- Juliusz From nobody Thu Jun 29 11:49:28 2017 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 E3A7B129B8C for ; Thu, 29 Jun 2017 11:49:26 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 thO7W1AMDyfD for ; Thu, 29 Jun 2017 11:49:25 -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 12134129B4F for ; Thu, 29 Jun 2017 11:49:24 -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/56228) with ESMTP id v5TInKjO023505; Thu, 29 Jun 2017 20:49:20 +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 C34A5EB2CC; Thu, 29 Jun 2017 20:49:20 +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 pixiwAlTDEeu; Thu, 29 Jun 2017 20:49:19 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 4BA05EB274; Thu, 29 Jun 2017 20:49:19 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.89) (envelope-from ) id 1dQeVC-0003Kh-WE; Thu, 29 Jun 2017 20:49:19 +0200 Date: Thu, 29 Jun 2017 20:49:18 +0200 Message-ID: <7i4luysk7l.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: babel@ietf.org In-Reply-To: References: <7itw30rrw8.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]); Thu, 29 Jun 2017 20:49:20 +0200 (CEST) X-Miltered: at korolev with ID 59554BB0.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59554BB0.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 : 59554BB0.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] Making aggregation possible in Babel (Chouasne's algorithm) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 18:49:27 -0000 > https://github.com/jech/babel-drafts/pull/4/files Pulled, thanks. The only problem with your text is how you had pushed the overriding case to the end, I've moved it backwards. Feel free to do more word-smithing. -- Juliusz From nobody Thu Jun 29 12:23:27 2017 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 00D8412EAB6 for ; Thu, 29 Jun 2017 12:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 w2HzESk6B4XQ for ; Thu, 29 Jun 2017 12:23:23 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 598E212EAB8 for ; Thu, 29 Jun 2017 12:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498764202; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bDGPIZ0h5FRNh1ZRTFd9MGEkAJeKwfJQJWH4i7NlXdY=; b=X2gXkClVlOXfTk3SBPEgJfhbevK36hIFMFT8WKOKfOr6b5qpl7POx/izsz4C9v0x H3QmOia6/nF0q5APUAMLGJTtjOkqkELJPAJu3Ih0sjlhyIHURVZqJ9+1syps8dnX DeHik8iL1XMt/EBxgNXsrqietqJt5zbNsRxmtBjH9l3G45S6DzAcgPTXYrzBQxW6 EQJOounjcpckli0QwP6XwL6IOih3NExKANUPbW7s6jwwQcvAxh0dtt0QssFxVwYX +T0kmJc2klqPBgHKF//U9MfCMXeCV85Nixhjw+qwrUSNZFelZIe5/hiQK8hU120W eaG35Ta0SaRuaaSvMcD0HA==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id FB.4C.06195.AA355595; Thu, 29 Jun 2017 12:23:22 -0700 (PDT) X-AuditID: 11973e16-8b5f19c000001833-70-595553aa309c Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay8.apple.com (Apple SCV relay) with SMTP id A3.41.05704.9A355595; Thu, 29 Jun 2017 12:23:22 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.234.28.37] (unknown [17.234.28.37]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OSB004ZQPUXP060@nwk-phonehomebzp-sz01.apple.com>; Thu, 29 Jun 2017 12:23:21 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <7i4luysk7l.wl-jch@irif.fr> Date: Thu, 29 Jun 2017 12:23:21 -0700 Cc: babel@ietf.org Message-id: <0128A194-425D-4FF6-A89B-F69A7B07A94F@apple.com> References: <7itw30rrw8.wl-jch@irif.fr> <7i4luysk7l.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUi2FCYprsqODTS4McHTosti7pZLOa3LmNz YPJYsuQnk8fiLW8ZA5iiuGxSUnMyy1KL9O0SuDJm/T/DWLCYpeLiomtMDYx7mLsYOTkkBEwk Xm/ax97FyMUhJLCGSeJw11o2mMSq3lOsILaQwDFGiV+v1UBsXgFBiR+T77F0MXJwMAvISxw8 LwsSZhbQkvj+qJUFYs58Jon2F4tZQBLCAtISXRfuskLYARLffy1iBOllA2o4sMYIJMwpoCFx //tndpAwi4CqRMs9O4iRQhJnrs1ggdhqI3Hw1Amoa8okDi6fAXa+iICKxPJpz9ghLpaVuDX7 EtRbS9gktu2XmMAoPAvJ0bMQjp6F5OgFjMyrGIVyEzNzdDPzzPUSCwpyUvWS83M3MYJCerqd 2A7Gh6usDjEKcDAq8fBu0AiNFGJNLCuuzD3EKM3BoiTO+0UrJFJIID2xJDU7NbUgtSi+qDQn tfgQIxMHp1QDI+PjsP326lOO39ad8LDB03vvyYfLwueuW53s6sUZ+naKYem1Ox8i+K9Nn3B9 28viPdInO2ukFexm3TK0mPrj+Nyz/XtPfXgQo/XUwYtDQTXyC7Oes/aD5mNZNp7PH4pNfDRb x3OO0OeJxeIiDWVBL1i9u369Onp14vefzzb+m/fFodPiC0tQXb4SS3FGoqEWc1FxIgAjHrud SgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42IRnG7noLsqODTSYE83u8WWRd0sFvNbl7E5 MHksWfKTyWPxlreMAUxRXDYpqTmZZalF+nYJXBmz/p9hLFjMUnFx0TWmBsY9zF2MnBwSAiYS q3pPsYLYQgLHGCV+vVYDsXkFBCV+TL7H0sXIwcEsIC9x8LwsSJhZQEvi+6NWoDAXUPl8Jon2 F4tZQBLCAtISXRfuskLYARLffy1iBOllA2o4sMYIJMwpoCFx//tndpAwi4CqRMs9O4iRQhJn rs1ggdhqI3Hw1Amoa8okDi6fAXaliICKxPJpz9ghLpaVuDX7EvMERoFZSA6dhXDoLCSHLmBk XsUoUJSak1hpoZdYUJCTqpecn7uJERSEDYVpOxibllsdYhTgYFTi4d2gERopxJpYVlyZe4hR goNZSYS3yhEoxJuSWFmVWpQfX1Sak1p8iLEK6PyJzFKiyfnACMkriTc0MTEwMTY2MzY2NzGn irCSOO+K28GRQgLpiSWp2ampBalFMMuZODilGhirVCMyD7DvS9G7VJE8a79FXkHbOeZZ/12K Dq7w3nTu2+lDdxU0ZmoVKIqHBnCcYV1jefrF3K+1ZrtOB2Rd+7TzhKhITsAHxivzd2hd/mnw OrvjzJNHEjMZXAK1S5elGGfdLQ24tKO+W+hyiZzRtckMk8vP33oo+uwl78spt3ktLbfcsN16 n2GuEktxRqKhFnNRcSIArhv2M50CAAA= Archived-At: Subject: Re: [babel] Making aggregation possible in Babel (Chouasne's algorithm) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 19:23:25 -0000 The reordering you performed makes sense to me, thanks! David Schinazi > On Jun 29, 2017, at 11:49, Juliusz Chroboczek wrote: > >> https://github.com/jech/babel-drafts/pull/4/files > > Pulled, thanks. The only problem with your text is how you had pushed the > overriding case to the end, I've moved it backwards. Feel free to do more > word-smithing. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Thu Jun 29 12:28:17 2017 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 2513E12EAB2 for ; Thu, 29 Jun 2017 12:28:15 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 81f413op5eH8 for ; Thu, 29 Jun 2017 12:28:13 -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 1308B129B55 for ; Thu, 29 Jun 2017 12:28:12 -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/56228) with ESMTP id v5TJS83S012051; Thu, 29 Jun 2017 21:28:08 +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 8F35FEB2D0; Thu, 29 Jun 2017 21:28:08 +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 ogz0pWsL_GPK; Thu, 29 Jun 2017 21:28:07 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1FF87EB2CC; Thu, 29 Jun 2017 21:28:07 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.89) (envelope-from ) id 1dQf6k-0003sa-Rb; Thu, 29 Jun 2017 21:28:06 +0200 Date: Thu, 29 Jun 2017 21:28:06 +0200 Message-ID: <7i1sq2siex.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Babel at IETF In-Reply-To: References: 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]); Thu, 29 Jun 2017 21:28:08 +0200 (CEST) X-Miltered: at korolev with ID 595554C8.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 595554C8.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 : 595554C8.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] Minor edits to draft-ietf-babel-rfc6126bis-02 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 19:28:15 -0000 > I sent out a PR with a flurry of minor edits to the doc: > https://github.com/jech/babel-drafts/pull/5/files I did some cherry picking. Here's the hunks that I've rejected. Please let me know if I've missed anything else. > - > + I prefer to edit the date manually whenever I submit a new I-D. Sorry. > -"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > -document are to be interpreted as described in . > +"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > +"OPTIONAL" in this document are to be interpreted as described in +target="RFC2119"/>. Let's leave the boilerplate as it stands. > -updates. > +updates. Note that the IHU and update timers may be part of the neighbour > +table if the Babel node is sending those TLVs over unicast. Right. But the way you've inserted it seems a little bit of an afterthought. At any rate, the Unicast Hellos stuff needs more work. > +Note that the source (prefix, plen, router-id) in the route table is > +not a reference to a source in the source table since their seqnos and > +metrics can differ. That's not correct. (prefix, plen, router-id) is a reference to the sourge table. The point here is that there are two (seqno, metric) pairs -- the route's distance, in the route table, and the feasibility distance, in the source table. Since this is one of the main insights behind Babel, it does deserve being stressed, so perhaps something like Note that there are two (seqno, metric) pairs associated to each route -- the route's distance, in the route table, and the feasibility distance, stored in the source table and shared between all routes with the same source. But I'm not sure that we've introduced the notion of distance (a (seqno, metric) pair) at that point, and I'm too tired to check. > -target="PACKETBB"/>. > +target="PACKETBB"/>. Babel only supports one method of address > +compression, which is the Omitted field of the Update TLV ( +target="update"/>). Seems redundant to me. If you really think it's needed, please put it earlier in the paragraph. > -ignored. > +ignored. An IHU TLV with AE set to 0 MUST NOT be sent to a multicast > +address. Disagree. An IHU TLV with AE 0 is perfectly valid, although NOT RECOMMENDED. > +a new TLV, or by adding a new sub-TLV to an existing TLV. If an extension > +makes incompatible changes to the meaning of a TLV, it should use a > +mandatory sub-TLV to ensure that the whole TLV is thrown away if the > +extension data is not understood. New TLVs should only be used when the > +extension adds semantics that do not map to existing TLVs. I'm keeping this around, for when I rewrite this section. -- Juliusz From nobody Thu Jun 29 12:31:33 2017 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 CB3B41205D3 for ; Thu, 29 Jun 2017 12:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 gyY8H18FlbWV for ; Thu, 29 Jun 2017 12:31:30 -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 8EF5312EAB5 for ; Thu, 29 Jun 2017 12:31: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/56228) with ESMTP id v5TJVIMj012820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Jun 2017 21:31:18 +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/56228) with ESMTP id v5TJVHqg004455; Thu, 29 Jun 2017 21:31:17 +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 E8E5AEB2CC; Thu, 29 Jun 2017 21:31:17 +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 NJz970sDTqZq; Thu, 29 Jun 2017 21:31:16 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E587BEB2F0; Thu, 29 Jun 2017 21:31:16 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.89) (envelope-from ) id 1dQf9o-0003sf-Ln; Thu, 29 Jun 2017 21:31:16 +0200 Date: Thu, 29 Jun 2017 21:31:16 +0200 Message-ID: <7izicqr3p7.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Babel at IETF In-Reply-To: References: 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]); Thu, 29 Jun 2017 21:31:18 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 29 Jun 2017 21:31:17 +0200 (CEST) X-Miltered: at korolev with ID 59555586.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 59555585.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59555586.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 59555585.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 : 59555586.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 59555585.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Forwarding Seqno Requests X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 19:31:32 -0000 > However it does not clearly define what redundant means here, what > should this table be indexed on? Right. It's the same notion as the indexing of the table of pending requests. > Should the table of pending seqno requests be indexed by routerID too? Yes, probably. I don't think it matters much. > Should the table of pending seqno requests also contain the destination > neighbor we sent it to? This would allow to ensure we do not send it to > more than one neighbor, which is a MUST in the spec. Well, the intent here is that a given request MUST NOT be duplicated (either by unicasting it to multiple neighbours or by multicasting it), but it MAY be resent to a different neighbour. If you can clean up the wording, go for it. -- Juliusz From nobody Thu Jun 29 15:11:24 2017 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 B3A8C129B1A for ; Thu, 29 Jun 2017 15:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 TLTI5WzjK38W for ; Thu, 29 Jun 2017 15:11:18 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 755F8129AA3 for ; Thu, 29 Jun 2017 15:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498774278; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=yMHFGAsl+VPTix/yzF6VrCQCwzO0CORo0ojH4gvaaas=; b=qViClDX2JfeMBjB/S52uJdDu9zvk4YvxVhTwga5NuJG3T6+/j1mqpqbn9BzNSIkJ Mn81NZzf/+HeNtslkVllICJlAxMRcFzzxSeWH/cALCBzXO2h+YiZsEIGRT0IrEDU ZWn8xARK3Z0rBNWHD11iVUrxseRchf6QbES2l2tAGCz3mFIugZnxD5flw3RoJA3t qauNtiRmz9xueIpjCtR61Mb4RSVsKgJhmKy1U+Q4Cge7ZzKuKoKs8ApECIKK+hYR 1HtvcK8nTc6vAw8OTlT/qEzqWhC6TOuqG//3ESHulqAxUJkuQpP0JHC4bm3PqeKG MHA2Z8uPcnfc0g3NzBveRA==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 3A.E6.06802.60B75595; Thu, 29 Jun 2017 15:11:18 -0700 (PDT) X-AuditID: 11973e13-e30ed9c000001a92-d3-59557b069d8e Received: from koseret (koseret.apple.com [17.151.62.39]) by relay3.apple.com (Apple SCV relay) with SMTP id A9.B3.04862.50B75595; Thu, 29 Jun 2017 15:11:18 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_TUzDTkCG/X2uQieHY76z7g)" Received: from da0602a-dhcp166.apple.com (da0602a-dhcp166.apple.com [17.226.23.166]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OSB005LYXMTKA00@koseret.apple.com>; Thu, 29 Jun 2017 15:11:17 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Thu, 29 Jun 2017 15:11:17 -0700 In-reply-to: <7i1sq2siex.wl-jch@irif.fr> Cc: Babel at IETF To: Juliusz Chroboczek References: <7i1sq2siex.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUi2FAYrMtWHRppMPO6iMWWRd0sFvNbl7E5 MHksWfKTyWPxlreMAUxRXDYpqTmZZalF+nYJXBmL230KXqZWLP31ibmBcUNYFyMnh4SAicTx z//Zuxi5OIQEVjNJzNvQww6TWHXhDlRiFaNEU/s/JpAEr4CgxI/J91hAbGaBMIk9h96wQBQt ZpKY39vECJIQFpCW6Lpwl7WLkYODTUBL4sAaI4heG4kvK/axgISFBZwkJu5TBAmzCKhK9M6a wg4S5hTQkOhcmg0xXUli9bc7zCC2iICKxPJpz8BKhASiJNZ9q4C4Ulbi1uxLzCAHSAgcYZO4 3/SXZQKj0Cwkh85CciiErSXx/VErkM0BZMtLHDwvCxHWlHh27xM7hK0t8eTdBdYFjGyrGIVy EzNzdDPzTPUSCwpyUvWS83M3MYJiYLqd8A7G06usDjEKcDAq8fBGqIVGCrEmlhVX5h5ilOZg URLn/aIVEikkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBkftKQe7RJt0Fc8/K3vUKaOiJqOur 3Lt0zloLw3/9Fqfafr9lOqQtOOtpzIXgQ9khqZ/TZRceUuBSj39qw/NMT8p+RgrHfLkz29+9 /rhq74yjh38Hl+3t29/dmXMm/FaZeO+z52F/VCYbHFHJVtj3sOTuoiZ+t39zBI422B650Z1T z66oedPviBJLcUaioRZzUXEiAGXJSHZiAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUiON1OXZetOjTS4N5Lfosti7pZLOa3LmNz YPJYsuQnk8fiLW8ZA5iiuGxSUnMyy1KL9O0SuDIWt/sUvEytWPrrE3MD44awLkZODgkBE4lV F+6wdzFycQgJrGKUaGr/xwSS4BUQlPgx+R4LiM0sECax59AbFoiixUwS83ubGEESwgLSEl0X 7rJ2MXJwsAloSRxYYwTRayPxZcU+FpCwsICTxMR9iiBhFgFVid5ZU9hBwpwCGhKdS7MhpitJ rP52hxnEFhFQkVg+7RlYiZBAlMS6bxUQV8pK3Jp9iXkCI/8sJLfNQnIbhK0l8f1RK5DNAWTL Sxw8LwsR1pR4du8TO4StLfHk3QXWBYxsqxgFilJzEiuN9RILCnJS9ZLzczcxgkK2oTB4B+Of ZVaHGAU4GJV4eDdohEYKsSaWFVfmHmKU4GBWEuGtcgQK8aYkVlalFuXHF5XmpBYfYpzICPTi RGYp0eR8YETllcQbmpgYmBgbmxkbm5uY01JYSZx3xe3gSCGB9MSS1OzU1ILUIpijmDg4pRoY lys/WpCxOnHjpkuuXI/8zTxM9z76dun2cadrQWxy08WYWdlyes7IS2Q/EpDlnr/6CsvKu/dq NuvUK++MP2WYYd2k5+1hJLf+0womcSepqq/l9lnf3ly/FTZrXszyf8FrP8x9d+FDDOPHQ/LJ Os8u/pjE4O70yrfp7YeObHEVJu8nD/4kKEw/rMRSnJFoqMVcVJwIAEO6XY3MAgAA Archived-At: Subject: Re: [babel] Minor edits to draft-ietf-babel-rfc6126bis-02 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 22:11:22 -0000 --Boundary_(ID_TUzDTkCG/X2uQieHY76z7g) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > On Jun 29, 2017, at 12:28, Juliusz Chroboczek wrote: > >> I sent out a PR with a flurry of minor edits to the doc: >> https://github.com/jech/babel-drafts/pull/5/files > > I did some cherry picking. Here's the hunks that I've rejected. Please > let me know if I've missed anything else. > >> - >> + > > I prefer to edit the date manually whenever I submit a new I-D. Sorry. Sure, no strong preference. >> -"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> -document are to be interpreted as described in . >> +"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and >> +"OPTIONAL" in this document are to be interpreted as described in > +target="RFC2119"/>. > > Let's leave the boilerplate as it stands. There is a verified erratum on RFC 2119 that I believe we should follow because of how obvious it is. https://www.rfc-editor.org/errata_search.php?rfc=2119&eid=499 >> -updates. >> +updates. Note that the IHU and update timers may be part of the neighbour >> +table if the Babel node is sending those TLVs over unicast. > > Right. But the way you've inserted it seems a little bit of an > afterthought. At any rate, the Unicast Hellos stuff needs more work. I tried to mimic the "Note that" at the end of the Neighbour Table section that adds guidance for implementors as an afterthought. That said, this is unrelated to unicast Hellos, my implementation sent IHU unicast from the start. >> +Note that the source (prefix, plen, router-id) in the route table is >> +not a reference to a source in the source table since their seqnos and >> +metrics can differ. > > That's not correct. (prefix, plen, router-id) is a reference to the > sourge table. The point here is that there are two (seqno, metric) > pairs -- the route's distance, in the route table, and the feasibility > distance, in the source table. > > Since this is one of the main insights behind Babel, it does deserve being > stressed, so perhaps something like > > Note that there are two (seqno, metric) pairs associated to each > route -- the route's distance, in the route table, and the feasibility > distance, stored in the source table and shared between all routes with > the same source. > > But I'm not sure that we've introduced the notion of distance (a (seqno, > metric) pair) at that point, and I'm too tired to check. Feasibility distance is defined as (seqno, metric) in Section 2.4 / 2.5, the Data Structures are in Section 3.2 so we're good. In a way those are somewhat equivalent, you can have a pointer to the source table or keep the router ID here and use it as a lookup key into the source table. Your text allows both and clears my confusion. >> -target="PACKETBB"/>. >> +target="PACKETBB"/>. Babel only supports one method of address >> +compression, which is the Omitted field of the Update TLV (> +target="update"/>). > > Seems redundant to me. If you really think it's needed, please put it > earlier in the paragraph. For some strange reason figuring out what "address compression" means in this spec was a pain point for me when first implementing. I saw the PACKETBB reference and ended up trying to figure out how to plumb PACKETBB into Babel TLVs. Maybe we could replace that reference with one to the encoding of Update TLVs section, and only mention PACKETBB in the Acknowledgments section (the one that thanks people, not TLV type 3). >> -ignored. >> +ignored. An IHU TLV with AE set to 0 MUST NOT be sent to a multicast >> +address. > > Disagree. An IHU TLV with AE 0 is perfectly valid, although NOT > RECOMMENDED. What's the benefit of allowing these? They break bidirectional reachability detection -- if one node's wireless radio is stronger than another and packets only flow in one direction, bad things will happen. >> +a new TLV, or by adding a new sub-TLV to an existing TLV. If an extension >> +makes incompatible changes to the meaning of a TLV, it should use a >> +mandatory sub-TLV to ensure that the whole TLV is thrown away if the >> +extension data is not understood. New TLVs should only be used when the >> +extension adds semantics that do not map to existing TLVs. > > I'm keeping this around, for when I rewrite this section. Sounds good, I wasn't very happy with my text but wanted to make sure we update that section to properly reflect mandatory sub-TLVs. Thanks, David Schinazi --Boundary_(ID_TUzDTkCG/X2uQieHY76z7g) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
On Jun 29, 2017, at 12:28, Juliusz Chroboczek <jch@irif.fr> = wrote:

I sent out a PR with a = flurry of minor edits to the doc:
https://github.com/jech/babel-drafts/pull/5/files

I did some cherry picking. =  Here's the hunks that I've rejected.  Please
let = me know if I've missed anything else.

-<date day=3D"19" = month=3D"June" year=3D"2017"/>
+<date/>

I prefer to edit the date = manually whenever I submit a new I-D.  Sorry.

Sure, = no strong preference.

-"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" = in this
-document are to be interpreted as described in = <xref target=3D"RFC2119"/>.</t>
+"SHOULD", = "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+"OPTIONAL" in this document are to be interpreted as = described in <xref
+target=3D"RFC2119"/>.</t>

Let's leave the boilerplate as = it stands.

There is a verified erratum on RFC 2119 that I = believe we should follow
because of how obvious it = is.

-updates.</t>
+updates.  Note that = the IHU and update timers may be part of the neighbour
+table if the Babel node is sending those TLVs over = unicast.</t>

Right. =  But the way you've inserted it seems a little bit of an
afterthought.  At any rate, the Unicast Hellos stuff = needs more work.

I tried to mimic the "Note that" at the end of the = Neighbour Table section that
adds guidance for implementors as = an afterthought. That said, this is unrelated to
unicast = Hellos, my implementation sent IHU unicast from the start.

+<t>Note that the = source (prefix, plen, router-id) in the route table is
+not = a reference to a source in the source table since their seqnos and
+metrics can differ.</t>

That's not correct.  (prefix, plen, router-id) is a = reference to the
sourge table.  The point here is = that there are two (seqno, metric)
pairs -- the route's = distance, in the route table, and the feasibility
distance, = in the source table.

Since this is one of = the main insights behind Babel, it does deserve being
stressed, so perhaps something like

 Note that there are two (seqno, metric) pairs = associated to each
 route -- the route's distance, = in the route table, and the feasibility
 distance, = stored in the source table and shared between all routes with
 the same source.

But I'm = not sure that we've introduced the notion of distance (a (seqno,
metric) pair) at that point, and I'm too tired to check.

Feasibility distance is defined as (seqno, metric) = in Section 2.4 / 2.5,
the Data Structures are in Section 3.2 = so we're good.
In a way those are somewhat equivalent, you can = have a pointer to the
source table or keep the router ID here = and use it as a lookup key into the
source table. Your text = allows both and clears my confusion.

-target=3D"PACKETBB"/>.</t>
+target=3D"PACKETBB"/>.  Babel only supports one = method of address
+compression, which is the Omitted field = of the Update TLV (<xref
+target=3D"update"/>).</t>

Seems redundant to me.  If = you really think it's needed, please put it
earlier in the = paragraph.

For some strange reason figuring out what "address = compression"
means in this spec was a pain point for me when = first implementing.
I saw the PACKETBB reference and ended up = trying to figure out
how to plumb PACKETBB into Babel TLVs. = Maybe we could replace
that reference with one to the encoding = of Update TLVs section, and
only mention PACKETBB in the = Acknowledgments section (the one
that thanks people, not TLV = type 3).

-ignored.</t>
+ignored.  An IHU TLV = with AE set to 0 MUST NOT be sent to a multicast
+address.</t>

Disagree.  An IHU TLV with AE 0 is perfectly valid, = although NOT
RECOMMENDED.

What's = the benefit of allowing these? They break bidirectional = reachability
detection -- if one node's wireless radio is = stronger than another and packets
only flow in one direction, = bad things will happen.

+a new TLV, or by adding a new sub-TLV to an existing TLV. =  If an extension
+makes incompatible changes to the = meaning of a TLV, it should use a
+mandatory sub-TLV to = ensure that the whole TLV is thrown away if the
+extension = data is not understood.  New TLVs should only be used when the
+extension adds semantics that do not map to existing = TLVs.</t>

I'm keeping = this around, for when I rewrite this section.

Sounds= good, I wasn't very happy with my text but wanted to make sure we
update that section to properly reflect mandatory = sub-TLVs.

Thanks,
David = Schinazi
= --Boundary_(ID_TUzDTkCG/X2uQieHY76z7g)-- From nobody Thu Jun 29 16:40:04 2017 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 2BF9412EB1B for ; Thu, 29 Jun 2017 16:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 vPdc6u_fQqNs for ; Thu, 29 Jun 2017 16:40:00 -0700 (PDT) Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (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 2A21E12EB11 for ; Thu, 29 Jun 2017 16:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498779599; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=AH/av0r/sVOvSsK/BOw9K3yonbFUdcgUwrxUFpR33+k=; b=njAxX3s6aLvj2Qi6yGUx8CeqyO4ZsrFM3nG5eyIG40Arxh67ciD0meG8g4/HjFH3 +F7DCGFlkDB41CZ6WPWhb9WCJjT3p9fGPJon8e6Hnz70Kx25S+ocOjh96ykckGd7 gnCAOnNuqP1DqNZf+zxGjT/DqvJOP377LyVySA/G0Tw8QFyqFedCpPB+dy7uFZWU 3VrQioTYli8qf0WPGFUlIrfjBY8HIGKtiMVbwUCMxCE3iYDj+iFHQBmSl3UiNxen zC0hp/vk/G0zKW3Em8xKzk2C9ulRrqpL2T5FTngKYiW21uH14vmqOabisTQppIzB Qeza6MUfZmi0vcNuAoX7LQ==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id DC.23.05744.FCF85595; Thu, 29 Jun 2017 16:39:59 -0700 (PDT) X-AuditID: 11ab0219-8e5ff70000001670-5e-59558fcec83e Received: from jimbu (jimbu.apple.com [17.151.62.37]) by relay7.apple.com (Apple SCV relay) with SMTP id F4.6B.30728.ECF85595; Thu, 29 Jun 2017 16:39:58 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_sTD8mGyi4mAWmGWBnfgQRA)" Received: from da0602a-dhcp166.apple.com (da0602a-dhcp166.apple.com [17.226.23.166]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OSC00HI81QL0150@jimbu.apple.com>; Thu, 29 Jun 2017 16:39:57 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <746E7126-6096-4A32-BE58-6D0D7D69A243@apple.com> Date: Thu, 29 Jun 2017 16:39:57 -0700 In-reply-to: <7izicqr3p7.wl-jch@irif.fr> Cc: Babel at IETF To: Juliusz Chroboczek References: <7izicqr3p7.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUi2FCYqnu+PzTSYMNSSYsti7pZLOa3LmNz YPJYsuQnk8fiLW8ZA5iiuGxSUnMyy1KL9O0SuDLOH7rPXvBSuuLN2p1sDYyvxbsYOTkkBEwk Lu56ydzFyMUhJLCWSeLk2nvsMIl1jxcwQSSWMUocn9LCCpLgFRCU+DH5HguIzSwQJvHycxdU 0Vwmic37esG6hQWkJbou3AVq4OBgE9CSOLDGCKLXRmL1wfuMECV6Eos/PAOzWQRUJT4+bQaz OQU0JHY++8cOMV9JYvW3O8wgtoiAisTyac/A4kICURInrv5lgjhUVuLW7EtgH0gIHGGTuLV/ I/sERqFZSG6dheRWCFtL4vujVqA4B5AtL3HwvCxEWFPi2b1P7BC2tsSTdxdYFzCyrWIUzk3M zNHNzDMy1UssKMhJ1UvOz93ECIqG1UySOxi/vjY8xCjAwajEw7tBIzRSiDWxrLgy9xCjNAeL kjivqnZIpJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGhheNz/dsPnV+TruF6InLzPbZq7Ot bi3Y/61uxYWPx3Z+Xi2xbNW9f4t+7I79/17pfnKATUWBeGXbvZkKBW/TRI7/dr5s0Lh7hkXC DFVRp2lendrHluXbRF07Ynxzetf09T6m2zdO/9bx4mfTwU9/OO02f824PMlx1t+aDTeeXs3i kl3+NWFzwwYlluKMREMt5qLiRABL++U9ZwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUiON1OVfdcf2ikQdc9cYsti7pZLOa3LmNz YPJYsuQnk8fiLW8ZA5iiuGxSUnMyy1KL9O0SuDLOH7rPXvBSuuLN2p1sDYyvxbsYOTkkBEwk 1j1ewNTFyMUhJLCMUeL4lBZWkASvgKDEj8n3WEBsZoEwiZefu6CK5jJJbN7Xyw6SEBaQlui6 cBeogYODTUBL4sAaI4heG4nVB+8zQpToSSz+8AzMZhFQlfj4tBnM5hTQkNj57B87xHwlidXf 7jCD2CICKhLLpz0DiwsJREmcuPqXCeJQWYlbsy8xT2Dkn4XkvFlIzoOwtSS+P2oFinMA2fIS B8/LQoQ1JZ7d+8QOYWtLPHl3gXUBI9sqRoGi1JzESnO9xIKCnFS95PzcTYyg0G0oTN3B2Ljc 6hCjAAejEg/vBo3QSCHWxLLiytxDjBIczEoivK/bgUK8KYmVValF+fFFpTmpxYcYJzICPTmR WUo0OR8YWXkl8YYmJgYmxsZmxsbmJua0FFYS511xOzhSSCA9sSQ1OzW1ILUI5igmDk6pBsbt iV6RXeufc36YqWmz5vlsjechnR3nfz7TWyk4TcvH/Prr7TU3J7seVjbbYZ5wKKr/7j6v5+8Z 7pzQXauWYNH6x9qlecbM3yZWxj33hXSkpPacrlkssuhGyK4ZD5gOR0tc//C802Ffr2bRJSPZ vY4PWQVnpy3VSEvjcIwPPjRtbsCLvNrNj9YqsRRnJBpqMRcVJwIAlKNWndACAAA= Archived-At: Subject: Re: [babel] Forwarding Seqno Requests X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 23:40:02 -0000 --Boundary_(ID_sTD8mGyi4mAWmGWBnfgQRA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Juliusz, Here's an attempt at text for this: https://github.com/jech/babel-drafts/pull/6/ Thanks, David Schinazi > On Jun 29, 2017, at 12:31, Juliusz Chroboczek wrote: > >> However it does not clearly define what redundant means here, what >> should this table be indexed on? > > Right. It's the same notion as the indexing of the table of pending > requests. > >> Should the table of pending seqno requests be indexed by routerID too? > > Yes, probably. I don't think it matters much. > >> Should the table of pending seqno requests also contain the destination >> neighbor we sent it to? This would allow to ensure we do not send it to >> more than one neighbor, which is a MUST in the spec. > > Well, the intent here is that a given request MUST NOT be duplicated > (either by unicasting it to multiple neighbours or by multicasting it), > but it MAY be resent to a different neighbour. If you can clean up the > wording, go for it. > > -- Juliusz --Boundary_(ID_sTD8mGyi4mAWmGWBnfgQRA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
Juliusz,

Here's an attempt at text for this:
https://github.com/jech/babel-drafts/pull/6/

Thanks,
David Schinazi


On Jun 29, 2017, at 12:31, = Juliusz Chroboczek <jch@irif.fr> wrote:

However it does not = clearly define what redundant means here, what
should this = table be indexed on?

Right. =  It's the same notion as the indexing of the table of pending
requests.

Should the table of pending seqno requests be = indexed by routerID too?

Yes, = probably.  I don't think it matters much.

Should the table of = pending seqno requests also contain the destination
neighbor= we sent it to? This would allow to ensure we do not send it to
more than one neighbor, which is a MUST in the spec.

Well, the intent here is that a = given request MUST NOT be duplicated
(either by unicasting = it to multiple neighbours or by multicasting it),
but it = MAY be resent to a different neighbour.  If you can clean up the
wording, go for it.

-- = Juliusz
= --Boundary_(ID_sTD8mGyi4mAWmGWBnfgQRA)--