From nobody Mon Apr 3 01:49:59 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 EDD0B126DC2 for ; Mon, 3 Apr 2017 01:49:57 -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 bxJt8ifvJoK3 for ; Mon, 3 Apr 2017 01:49:55 -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 CB3EC128954 for ; Mon, 3 Apr 2017 01:49: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 v338nqpD012718; Mon, 3 Apr 2017 10:49: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 AA246D79DD; Mon, 3 Apr 2017 10:49: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 smz972ZS7J0a; Mon, 3 Apr 2017 10:49:51 +0200 (CEST) Received: from ijon.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 5A056D79D6; Mon, 3 Apr 2017 10:49:51 +0200 (CEST) Date: Mon, 03 Apr 2017 03:50:13 -0500 Message-ID: <87a87xooxm.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org, babel-users@lists.alioth.debian.org User-Agent: Wanderlust/2.15.9 Reply-To: babel@ietf.org 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, 03 Apr 2017 10:49:52 +0200 (CEST) X-Miltered: at korolev with ID 58E20CB0.006 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58E20CB0.006 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 : 58E20CB0.006 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] Unicast 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: Mon, 03 Apr 2017 08:49:58 -0000 Dear all, [This message is crossposted between both mailing lists, followups to babel@ietf, please.] I think there are at least four people interested in making a unicast-only version of Babel, and that requires adding support to the protocol for sending Hellos over unicast. We had a discussion on this subject with David Schinazi on Friday, let's please continue on the list. Background ========== Babel was designed so that the choice between sending a given TLV over unicast or multicast is purely an implementation decision: all TLVs can be sent over either, and have exactly the same meaning whether they are sent over unicast or multicast. There is however one limitation to that: Hellos carry a per-interface sequence number, and unless they are sent to all neighbours on a given interface, the seqnos will get out of synch. More on that below. At the time, it didn't seem important to be able to send unicast Hellos. After all, Hellos are used for both neighbour discovery and neighbourship maintenance, and discovery can only happen over multicast. However, once a neighbour has been discovered (either through multicast Hellos or through means exterior to the protocol), then unicast Hellos can be used to maintain the neighbour relationship. People have found good reasons to use unicast for Hellos: 1. Toke and Dave have a passionate hatred of multicast, and want to avoid it whenever possible; 2. others want to protect Babel with DTLS or IPSec, and these protocols only work for unicast; 3. Margaret is using Babel over a non-broadcast network, where multicast is not supported at all. All of these are legitimate applications, and as I mentioned in Chicago, it would be a terrible wasted opportunity if we didn't get unicast Hellos into the spec in time for Prague. The issue ========= Every Hello contains two pieces of information: the Interval, a 16-bit number of centiseconds (ranging from 10ms to 11 minutes), and a 16-bit Seqno, which is an integer modulo 2^16. The Interval is a promise to send another Hello within a given time; babeld uses it to derive a hold time (3*Interval, if memory serves). The Seqno is incremented with each Hello, and allows for reliable accounting of packet loss. A Babel speaker maintains a single Hello Seqno per interface, which is incremented whenever a (multicast) Hello is sent. If a Hello is sent over multicast to a single neighbour, the expected Seqno will become desynchronised between the various neighbours, which will cause spurious detection of packet loss. A Hello also carries a 16-bit Reserved field, which currently must be zero on transmission, and is silently ignored on reception. David suggests that this field could be repurposed as a flags field. Possible solutions ================== It is my opinion that it is allowable to add an incompatible extension as long as it does not break existing networks and does not require a flag day. If a unicast-only speaker fails to establish an adjacency with a legacy speaker, that's fine with me, as long as it does not break the rest of the network. Given that constraint, David and I see the following ways to add unicast Hellos. Allow unicast, no other protocol changes **************************************** Margaret suggests that we should allow unicast Hellos, but require that the same number of Hellos be sent to all neighbours on a given interface. In other words, whenever a Hello is sent, it is either sent over multicast, or the same Hello is sent to all neighbours over unicast. This is tempting, since it doesn't require any changes to the protocol, just minor editorial changes. While it meets Margaret's use case, it might not be flexible enough for all the uses of unicast Hellos. I also dislike the fact that the receiver cannot distinguish unicast from multicast without checking the destination address -- this would be the only place in the protocol where the destination address is needed. Make the Hello counter per-neighbour ************************************ No protocol changes, just require that the Hello counter be per-neighbour. This means that an implementation must either send all Hellos over multicast, so all per-neighbour counters are equal, or all Hellos over unicast. Once a Hello has been sent over unicast and the counters have become unsynchronised, it is impossible to send a Hello over multicast. This is not acceptable to me, since sending Hellos over multicast is the only in-band way to perform neighbour discovery. Two kinds of Hellos, distinguished using a flag *********************************************** David suggests that we have two Seqno counters: a per-interface and a per-neighbour counter. The two kinds of counters run independently. A flag in the Hello packet's Reserved field serves to distinguish the two. This is simple, elegant, and require few protocol changes. Unfortunately, legacy implementations that don't parse the Reserved field will get confused, and spuriously tear down neighbour associations when they see discontinuities in the seqno. However, no flag day is necessary: we first deploy implementations that understand the Reserved field, but don't send any unicast Hellos. At a later date, when legacy implementations have disappeared, we start sending unicast Hellos. This is currently my preferred solution. Two kinds of Hellos, using different TLV types ********************************************** My suggestion was to have two Seqno counters, just like in David's proposal, but use a new TLV number for Unicast hellos. This avoids the compatibility issue -- unicast Hellos will be ignored by legacy implementations, so unless an implementation periodically sends multicast Hellos, it will be ignored by legacy implementations. This used to be my preferred solution. David has convinced me to use a flag, but I'm willing to reconsider. Use empty packets ***************** Russ suggested that we interpret every Babel packet as a Hello. This way, sending an empty packet (just the packet header) will play the role of a Hello. This has two significant flaws: - there is no seqno or interval in the Babel header; - there is no way to attach a sub-TLV to an empty packet, most notably a timestamp. This is not acceptable to me. Something else? *************** Other ideas? Other issues ============ What does Interval mean? ************************ Currently, the Interval field of a (multicast) Hello is a promise to send another (multicast) Hello within the given time. If we switch to having two kinds of Hello, what does Interval mean? Is it a promise to send any kind of Hello in the given interval, or a promise to send the same kind of Hello within the given interval. The former makes more sense to me, but I'm willing to be convinced otherwise. How is link quality estimated? ****************************** Most implementations of Babel use Hello history to derive a link quality for each neighbourship association; this is described in Appendix A of RFC 6126. How is link quality computed in the presence of two kinds of Hellos? Please consider that at least in 802.11, unicast is protected by ARQ while multicast isn't. From nobody Mon Apr 3 10:12:03 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 60E17129476 for ; Mon, 3 Apr 2017 10:12:01 -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_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 lFs_BJs-DH7O for ; Mon, 3 Apr 2017 10:11:59 -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 3ACFE128D69 for ; Mon, 3 Apr 2017 10:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491239517; 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=gxDLto2lfrpnpfnYQcc+a/pFFcj46Sv7RbUDmRUfaVA=; b=gi8ed35LH3gW9DaZ9ADxTW3Sx8PeQZQW1W+tf5kYD10+caTt0z9OW/HY4EntFjeU e/2Zzch5PGeScxKyMWeIpUOyZ2KuPhkeHX+OiwykvY6n7Ijk+YzSJhAgjZa/w0hi ddQ4o6hg+5M0QeQAaa81aTbXAvRoBW02gFAQkPnGhOT15NX6Y/D3NK3eIsR/tl23 XFJp1J5SV7M6WjNyHOqPFKAzedWlgiffJgX3fioag/dIW6CyXWEGu5hJAL0dsJE3 yShSqmmm9Lr7/bWbJvXJWA3l7KCiceUXJyFB2Kj4h882Z1uPJ8cxVOuCC0AHJw+B m/4KOCPBKe+0DwkAKi2ZVw==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id 4C.8E.01216.D5282E85; Mon, 3 Apr 2017 10:11:57 -0700 (PDT) X-AuditID: 11ab0218-2dfdb9a0000004c0-f5-58e2825de383 Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay4.apple.com (Apple SCV relay) with SMTP id 92.3C.03007.C5282E85; Mon, 3 Apr 2017 10:11:57 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.71.197] (unknown [17.153.71.197]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONU004XNFROJI20@nwk-phonehomebzp-sz01.apple.com> for babel@ietf.org; Mon, 03 Apr 2017 10:11:56 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Date: Mon, 03 Apr 2017 10:11:46 -0700 References: <87a87xooxm.wl-jch@irif.fr> To: Babel at IETF In-reply-to: <87a87xooxm.wl-jch@irif.fr> Message-id: <82AF6CF4-F062-43D4-AC02-D412D1AF76BE@apple.com> X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FAYrhvb9CjCoHWajMWWRd0sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK+NP7jrngoWPFjuNXmBoYj5l0MXJySAiYSLxYfIO9i5GLQ0hg H6PEg4Pn2WESz4+eYYRIHGOUWLtzOliCV0BQ4sfkeyxdjBwczALyEgfPy4KEmQW0JL4/amWB qN/CJNG67B8zSEJYQFqi68JdVpB6NqCiA2uMIMKaErP2/2UDsVkEVCWOntjIBGILCahLPJzY DNYqIqAksfnmTzCbU0BDYkLbETaIE2wkDrU8ZIO4U1bi0/OfYA9ICExgk5j0roltAqPQLCSn zkI4dRaSUxcwMq9iFM5NzMzRzcwzMtFLLCjISdVLzs/dxAgK19VMEjsYv7w2PMQowMGoxMM7 of5RhBBrYllxZe4hRmkOFiVxXom79yKEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MG7478/p t6U8oeqp6aQvTlFH2+dYy9QWTFjDeXBa4YwXZzr9JB+o7pGcs3KvqryIhLef/Z7MNtNjMzI5 dRVde2zsZwWW7doV02YuOa8gab1b0q0nJV4qzVYGq628TlzRm2QZldLtE3vW9B6L/fqW9/dt Il7sc1jObr9V7f6Rn9qTUx5kK8cKKbEUZyQaajEXFScCAHaJ1mM4AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUiON3OQTe26VGEweIuVosti7pZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8af3HXPBQ8eKHcevMDUwHjPpYuTkkBAwkXh+9AxjFyMXh5DA MUaJtTuns4MkeAUEJX5MvsfSxcjBwSwgL3HwvCxImFlAS+L7o1YWiPotTBKty/4xgySEBaQl ui7cZQWpZwMqOrDGCCKsKTFr/182EJtFQFXi6ImNTCC2kIC6xMOJzWCtIgJKEptv/gSzOQU0 JCa0HWGDOMFG4lDLQzaIO2UlPj3/yT6BkX8WkutmIVw3C8l1CxiZVzEKFKXmJFaa6CUWFOSk 6iXn525iBAVXQ2H4DsZ/y6wOMQpwMCrx8C5wehQhxJpYVlyZe4hRgoNZSYSXIx4oxJuSWFmV WpQfX1Sak1p8iLEK6P6JzFKiyfnAwM8riTc0MTEwMTY2MzY2NzGnirCSOG92+b0IIYH0xJLU 7NTUgtQimOVMHJxSDYyNVxYuOi0ddNz7/7w8wb6QPyFHL74y09+1Ytb2j5eOe+SWfO8RqTZN KP7bszRorrnW5FfLjj0RYH5qqztbqWx9//N98cy1H9v+vXpouFe7ON284XZLTU/nr7fJm73T +NimRCs+2/TL3aiif9Kz2BPp3Y8n8pyc3MmTxO/nnt4z44niyznVV88qsRRnJBpqMRcVJwIA p4i/Y4kCAAA= Archived-At: Subject: Re: [babel] [Babel-users] Unicast 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: Mon, 03 Apr 2017 17:12:01 -0000 Hi Juliusz, thanks for writing this up! I agree with your problem statement and preferred solution using a flag, and I like the 2-step deployment plan. It has the advantage that further down the road we won't have to explain to our grandchildren why we have a separate TLV for unicast Hellos. I can volunteer to write draft text towards adding this to the document, if there is consensus on the list. Thanks, David > On Apr 3, 2017, at 01:50, Juliusz Chroboczek wrote: > > Dear all, > > [This message is crossposted between both mailing lists, followups to > babel@ietf, please.] > > I think there are at least four people interested in making a unicast-only > version of Babel, and that requires adding support to the protocol for > sending Hellos over unicast. We had a discussion on this subject with > David Schinazi on Friday, let's please continue on the list. > > Background > ========== > > Babel was designed so that the choice between sending a given TLV over > unicast or multicast is purely an implementation decision: all TLVs can be > sent over either, and have exactly the same meaning whether they are sent > over unicast or multicast. There is however one limitation to that: > Hellos carry a per-interface sequence number, and unless they are sent to > all neighbours on a given interface, the seqnos will get out of synch. > More on that below. > > At the time, it didn't seem important to be able to send unicast Hellos. > After all, Hellos are used for both neighbour discovery and neighbourship > maintenance, and discovery can only happen over multicast. However, once > a neighbour has been discovered (either through multicast Hellos or > through means exterior to the protocol), then unicast Hellos can be used > to maintain the neighbour relationship. > > People have found good reasons to use unicast for Hellos: > > 1. Toke and Dave have a passionate hatred of multicast, and want to > avoid it whenever possible; > 2. others want to protect Babel with DTLS or IPSec, and these protocols > only work for unicast; > 3. Margaret is using Babel over a non-broadcast network, where multicast > is not supported at all. > > All of these are legitimate applications, and as I mentioned in Chicago, > it would be a terrible wasted opportunity if we didn't get unicast Hellos > into the spec in time for Prague. > > The issue > ========= > > Every Hello contains two pieces of information: the Interval, a 16-bit > number of centiseconds (ranging from 10ms to 11 minutes), and a 16-bit > Seqno, which is an integer modulo 2^16. The Interval is a promise to send > another Hello within a given time; babeld uses it to derive a hold time > (3*Interval, if memory serves). The Seqno is incremented with each Hello, > and allows for reliable accounting of packet loss. > > A Babel speaker maintains a single Hello Seqno per interface, which is > incremented whenever a (multicast) Hello is sent. If a Hello is sent over > multicast to a single neighbour, the expected Seqno will become > desynchronised between the various neighbours, which will cause spurious > detection of packet loss. > > A Hello also carries a 16-bit Reserved field, which currently must be zero > on transmission, and is silently ignored on reception. David suggests > that this field could be repurposed as a flags field. > > Possible solutions > ================== > > It is my opinion that it is allowable to add an incompatible extension as > long as it does not break existing networks and does not require a flag > day. If a unicast-only speaker fails to establish an adjacency with > a legacy speaker, that's fine with me, as long as it does not break the > rest of the network. Given that constraint, David and I see the following > ways to add unicast Hellos. > > Allow unicast, no other protocol changes > **************************************** > > Margaret suggests that we should allow unicast Hellos, but require that > the same number of Hellos be sent to all neighbours on a given interface. > In other words, whenever a Hello is sent, it is either sent over > multicast, or the same Hello is sent to all neighbours over unicast. > > This is tempting, since it doesn't require any changes to the protocol, > just minor editorial changes. While it meets Margaret's use case, it > might not be flexible enough for all the uses of unicast Hellos. I also > dislike the fact that the receiver cannot distinguish unicast from > multicast without checking the destination address -- this would be the > only place in the protocol where the destination address is needed. > > Make the Hello counter per-neighbour > ************************************ > > No protocol changes, just require that the Hello counter be per-neighbour. > This means that an implementation must either send all Hellos over > multicast, so all per-neighbour counters are equal, or all Hellos over > unicast. Once a Hello has been sent over unicast and the counters have > become unsynchronised, it is impossible to send a Hello over multicast. > > This is not acceptable to me, since sending Hellos over multicast is the > only in-band way to perform neighbour discovery. > > Two kinds of Hellos, distinguished using a flag > *********************************************** > > David suggests that we have two Seqno counters: a per-interface and > a per-neighbour counter. The two kinds of counters run independently. > A flag in the Hello packet's Reserved field serves to distinguish the two. > > This is simple, elegant, and require few protocol changes. Unfortunately, > legacy implementations that don't parse the Reserved field will get > confused, and spuriously tear down neighbour associations when they see > discontinuities in the seqno. However, no flag day is necessary: we first > deploy implementations that understand the Reserved field, but don't send > any unicast Hellos. At a later date, when legacy implementations have > disappeared, we start sending unicast Hellos. > > This is currently my preferred solution. > > Two kinds of Hellos, using different TLV types > ********************************************** > > My suggestion was to have two Seqno counters, just like in David's > proposal, but use a new TLV number for Unicast hellos. This avoids the > compatibility issue -- unicast Hellos will be ignored by legacy > implementations, so unless an implementation periodically sends multicast > Hellos, it will be ignored by legacy implementations. > > This used to be my preferred solution. David has convinced me to use > a flag, but I'm willing to reconsider. > > Use empty packets > ***************** > > Russ suggested that we interpret every Babel packet as a Hello. This way, > sending an empty packet (just the packet header) will play the role of > a Hello. This has two significant flaws: > > - there is no seqno or interval in the Babel header; > - there is no way to attach a sub-TLV to an empty packet, most notably > a timestamp. > > This is not acceptable to me. > > Something else? > *************** > > Other ideas? > > Other issues > ============ > > What does Interval mean? > ************************ > > Currently, the Interval field of a (multicast) Hello is a promise to send > another (multicast) Hello within the given time. If we switch to having > two kinds of Hello, what does Interval mean? Is it a promise to send any > kind of Hello in the given interval, or a promise to send the same kind of > Hello within the given interval. The former makes more sense to me, but > I'm willing to be convinced otherwise. > > How is link quality estimated? > ****************************** > > Most implementations of Babel use Hello history to derive a link quality > for each neighbourship association; this is described in Appendix A of > RFC 6126. How is link quality computed in the presence of two kinds of > Hellos? Please consider that at least in 802.11, unicast is protected by > ARQ while multicast isn't. > > _______________________________________________ > Babel-users mailing list > Babel-users@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users From nobody Mon Apr 3 10:39: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 90F9C124281 for ; Mon, 3 Apr 2017 10:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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 dzbb0SArq3dV for ; Mon, 3 Apr 2017 10:39:17 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 BE2641294BE for ; Mon, 3 Apr 2017 10:39:15 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id h67so22126038qke.0 for ; Mon, 03 Apr 2017 10:39:15 -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 :content-transfer-encoding; bh=pua1OQI39JSRGjF/9ijQuWzGgcVFGPmeY1TCoR9c5pM=; b=Uw00sJ3hXOz6ZN2ozzTaDv//gVrsAODTkF+s6dyT2WqsH0wq8SO72sEoF7Px8qUte/ ODAnTk9rpC0hGnWHmhMMR7i5xGhNksaaR8nQtKqBYi+5X/9CZ+j2tIS6ubPXiygjwJi/ w/nV1l3vDpf2Bw1WjFohDaVAPvqknb6kfv7qv63aU+LTKyTzKjba9dE0xixM1/zpXCkQ u7Memz8alvnbHHtS5W3GkDcAYpZp0zD4BESznQyllRDqtFgjkuOOM54HQVcU32FR6lnO yzrxZcevxHSO6lLRbzmOXr4f4exoLIXJSksZZD5WER0uqVUWTALgzvMp3B3nrL+BN3Gb +vIg== 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:content-transfer-encoding; bh=pua1OQI39JSRGjF/9ijQuWzGgcVFGPmeY1TCoR9c5pM=; b=YMIkEaPZFPk0EJrrvYiGuO76+0hdrs5aH2FbjkpF8KyC7wFpu2WBjX6PEls9pkw/4E bNuwBfPfXGh1bD1kYSnlEDc5wueHVdnNnOLdIPy+ePKDqe5BAHREtx1yg8mL7nlrVkHT zYFNlGwUIVezJciwin6lCFrpA9MgqT2M29GMqft//jwnQvn3IaG2ljqrcteytfahtTAX DiyZgF6hu/YEAgpW20enUITPB5aNXQ2cfwX8q8bcBmE8SW5pJoZAZCY1Q9fyF3QmKwyw u0cEyzkZa4dKP5sPIpbj+g0uot6ZGhPJ3WP339tHIB5IN5YdTmV0sN72RruNpn8VzS+U E4Ug== X-Gm-Message-State: AFeK/H393fk7pFSTfboALOPNoSQDAxzg8zzBa4NP0mPsl/rgDbwx/1hT7VXybDIYumR6QYIdUwA+F37nqON4nQ== X-Received: by 10.55.27.95 with SMTP id b92mr13015016qkb.196.1491241154230; Mon, 03 Apr 2017 10:39:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.140.8 with HTTP; Mon, 3 Apr 2017 10:39:13 -0700 (PDT) In-Reply-To: <87a87xooxm.wl-jch@irif.fr> References: <87a87xooxm.wl-jch@irif.fr> From: Dave Taht Date: Mon, 3 Apr 2017 10:39:13 -0700 Message-ID: To: Babel at IETF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Unicast 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: Mon, 03 Apr 2017 17:39:21 -0000 On Mon, Apr 3, 2017 at 1:50 AM, Juliusz Chroboczek wrote: > Dear all, > > [This message is crossposted between both mailing lists, followups to > babel@ietf, please.] > > I think there are at least four people interested in making a unicast-onl= y > version of Babel, and that requires adding support to the protocol for > sending Hellos over unicast. We had a discussion on this subject with > David Schinazi on Friday, let's please continue on the list. > > Background > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Babel was designed so that the choice between sending a given TLV over > unicast or multicast is purely an implementation decision: all TLVs can b= e > sent over either, and have exactly the same meaning whether they are sent > over unicast or multicast. There is however one limitation to that: > Hellos carry a per-interface sequence number, and unless they are sent to > all neighbours on a given interface, the seqnos will get out of synch. > More on that below. > > At the time, it didn't seem important to be able to send unicast Hellos. > After all, Hellos are used for both neighbour discovery and neighbourship > maintenance, and discovery can only happen over multicast. In the case of a p2p tunnel I could see explicitly identifying each end, th= us eliminating the need to use multicast for discovery. > However, once > a neighbour has been discovered (either through multicast Hellos or > through means exterior to the protocol), then unicast Hellos can be used > to maintain the neighbour relationship. > > People have found good reasons to use unicast for Hellos: > > 1. Toke and Dave have a passionate hatred of multicast, and want to > avoid it whenever possible; Well, I do hope we get around to making at least one wifi chipset queue and drop multicast more sanely sometime this year. > 2. others want to protect Babel with DTLS or IPSec, and these protocols > only work for unicast; I would like to be able to run babel over wireguard one day, as it evolves. > 3. Margaret is using Babel over a non-broadcast network, where multicas= t > is not supported at all. > > All of these are legitimate applications, and as I mentioned in Chicago, > it would be a terrible wasted opportunity if we didn't get unicast Hellos > into the spec in time for Prague. > > The issue > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > Every Hello contains two pieces of information: the Interval, a 16-bit > number of centiseconds (ranging from 10ms to 11 minutes), and a 16-bit > Seqno, which is an integer modulo 2^16. The Interval is a promise to sen= d > another Hello within a given time; babeld uses it to derive a hold time > (3*Interval, if memory serves). The Seqno is incremented with each Hello= , > and allows for reliable accounting of packet loss. > > A Babel speaker maintains a single Hello Seqno per interface, which is > incremented whenever a (multicast) Hello is sent. If a Hello is sent ove= r > multicast to a single neighbour, the expected Seqno will become > desynchronised between the various neighbours, which will cause spurious > detection of packet loss. > > A Hello also carries a 16-bit Reserved field, which currently must be zer= o > on transmission, and is silently ignored on reception. David suggests > that this field could be repurposed as a flags field. > > Possible solutions > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > It is my opinion that it is allowable to add an incompatible extension as > long as it does not break existing networks and does not require a flag > day. If a unicast-only speaker fails to establish an adjacency with > a legacy speaker, that's fine with me, as long as it does not break the > rest of the network. Given that constraint, David and I see the followin= g > ways to add unicast Hellos. > > Allow unicast, no other protocol changes > **************************************** > > Margaret suggests that we should allow unicast Hellos, but require that > the same number of Hellos be sent to all neighbours on a given interface. > In other words, whenever a Hello is sent, it is either sent over > multicast, or the same Hello is sent to all neighbours over unicast. > > This is tempting, since it doesn't require any changes to the protocol, > just minor editorial changes. While it meets Margaret's use case, it > might not be flexible enough for all the uses of unicast Hellos. I also > dislike the fact that the receiver cannot distinguish unicast from > multicast without checking the destination address -- this would be the > only place in the protocol where the destination address is needed. > > Make the Hello counter per-neighbour > ************************************ > > No protocol changes, just require that the Hello counter be per-neighbour= . > This means that an implementation must either send all Hellos over > multicast, so all per-neighbour counters are equal, or all Hellos over > unicast. Once a Hello has been sent over unicast and the counters have > become unsynchronised, it is impossible to send a Hello over multicast. > > This is not acceptable to me, since sending Hellos over multicast is the > only in-band way to perform neighbour discovery. > > Two kinds of Hellos, distinguished using a flag > *********************************************** > > David suggests that we have two Seqno counters: a per-interface and > a per-neighbour counter. The two kinds of counters run independently. > A flag in the Hello packet's Reserved field serves to distinguish the two= . > > This is simple, elegant, and require few protocol changes. Unfortunately= , > legacy implementations that don't parse the Reserved field will get > confused, and spuriously tear down neighbour associations when they see > discontinuities in the seqno. However, no flag day is necessary: we firs= t > deploy implementations that understand the Reserved field, but don't send > any unicast Hellos. At a later date, when legacy implementations have > disappeared, we start sending unicast Hellos. > > This is currently my preferred solution. I hope nobody has flag days as difficult as mine, which involve climbing a lot of trees! > Two kinds of Hellos, using different TLV types > ********************************************** > > My suggestion was to have two Seqno counters, just like in David's > proposal, but use a new TLV number for Unicast hellos. This avoids the > compatibility issue -- unicast Hellos will be ignored by legacy > implementations, so unless an implementation periodically sends multicast > Hellos, it will be ignored by legacy implementations. > > This used to be my preferred solution. David has convinced me to use > a flag, but I'm willing to reconsider. I lean towards a new unicast type, but can probably be convinced otherwise. > > Use empty packets > ***************** > > Russ suggested that we interpret every Babel packet as a Hello. This way= , > sending an empty packet (just the packet header) will play the role of > a Hello. This has two significant flaws: > > - there is no seqno or interval in the Babel header; > - there is no way to attach a sub-TLV to an empty packet, most notably > a timestamp. > > This is not acceptable to me. > > Something else? > *************** > > Other ideas? > > Other issues > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > What does Interval mean? > ************************ > > Currently, the Interval field of a (multicast) Hello is a promise to send > another (multicast) Hello within the given time. If we switch to having > two kinds of Hello, what does Interval mean? Is it a promise to send any > kind of Hello in the given interval, or a promise to send the same kind o= f > Hello within the given interval. The former makes more sense to me, but > I'm willing to be convinced otherwise. > > How is link quality estimated? > ****************************** > > Most implementations of Babel use Hello history to derive a link quality > for each neighbourship association; this is described in Appendix A of > RFC 6126. How is link quality computed in the presence of two kinds of > Hellos? Please consider that at least in 802.11, unicast is protected by > ARQ while multicast isn't. To me, this is the bigger problem, in general. the quantity of control traffic is very sparse and thus difficult to get a more reliable signal out of. In the case of unicast and ARQ, we don't (generally) get any packet loss at all, just delay, except in the case where the network has completely severed connectivity. You elided the rtt estimation extension from the above discussion, and I tend to think that that is part of a way out, and must be part of the unicast hello. There are other options regarding transfers that might provide more "signal" as to the quality of the link - notably doing a unicast route transfer and observing how long it took, (or observing this more generally by periodically sending another message and asking for a response). or (in the known unreliable cases) asking the receiver how many routes it got via multicast vs how many were sent. I kind of like bits of this latter option, a router advertising that it "had default routes" or "had lots of routes", but it's way outside the current scope of the protocol. > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org From nobody Mon Apr 3 10:59:03 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 52C2E124281 for ; Mon, 3 Apr 2017 10:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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 MEYZoPjxCsKi for ; Mon, 3 Apr 2017 10:59:00 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 BC13B12946D for ; Mon, 3 Apr 2017 10:58:57 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id p22so121434433qka.3 for ; Mon, 03 Apr 2017 10:58:57 -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 :content-transfer-encoding; bh=94qgrerZ8HW14TUd3mB0ku/zzaJqWEHbJqx2eMn4ZTQ=; b=enyd/2mDoHKqjvhcxn/WEZh0KhOIj3UMndVbO/weYJT78ctp/s1QkdIEMrdWHveUYW Kcjdsa8FPZgd4kIikBTkunA+eneoaHumOwOpNnC27Lwb2YSc65QOwpqHmtqNV3MIalqk lb3EXnQk9P+rDeNALDrxIMyVSjjhZ/KTUkJB/iBK+felcA/QX7t/H7B9j1sOk3TdyQMk ch3g1d0VRClkJCDQfjAMv588b6QKo58OzYIlBmrlhiNvxsq+WVYRmJ83DdM8r7uwzVU+ yXQ1JIGNex/LQuKqqQwSjT7bxR8g5YBRN2nAb1X+9+LU8/3nnmiysjg2PvshCoc2H/si 06Cg== 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:content-transfer-encoding; bh=94qgrerZ8HW14TUd3mB0ku/zzaJqWEHbJqx2eMn4ZTQ=; b=Z7c3k/4f84OmITq18+E6CBUWzFzsFYQWfciJqqq3Y9GArOEQG4c5GR2Fe9O+0G3W5G 4dOCmMjDzDdTUowXPuOc6H9jDgSlrnuqzZhBOpQeVQHPUPHARJW8bXnrvHvvNDRaYPDE TPG6maZU3/6t086BchYlLmL06OqmWI7U6xeDM+9mtXnT1JI0IhNambaTqdHvmstDIyQh /VtF6O3KgWQmnuYCJUZANZb6stX6/dYp6nKpF99OHy0J3Pwhh4QYdLOtCvxazjBoLzFw sGn2xFj+NVKHjuXuzvRFdjc0lG/EDus3ZIJ0DHbsgLL9kj0qTA1Qy5G9VHw9kdV0R+kf 0/ZA== X-Gm-Message-State: AFeK/H2cYCLazaHDD9AOASNoOF+OrGOo+q9BjTiuUH4byGVKEfz8fT4RIix4sLn2Eh03Vvtreg29YtrhUlLL4g== X-Received: by 10.55.15.162 with SMTP id 34mr13963667qkp.114.1491242336698; Mon, 03 Apr 2017 10:58:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.140.8 with HTTP; Mon, 3 Apr 2017 10:58:56 -0700 (PDT) In-Reply-To: <87a87xooxm.wl-jch@irif.fr> References: <87a87xooxm.wl-jch@irif.fr> From: Dave Taht Date: Mon, 3 Apr 2017 10:58:56 -0700 Message-ID: To: Babel at IETF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Unicast 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: Mon, 03 Apr 2017 17:59:02 -0000 > Make the Hello counter per-neighbour > ************************************ > > No protocol changes, just require that the Hello counter be per-neighbour= . > This means that an implementation must either send all Hellos over > multicast, so all per-neighbour counters are equal, or all Hellos over > unicast. Once a Hello has been sent over unicast and the counters have > become unsynchronised, it is impossible to send a Hello over multicast. > > This is not acceptable to me, since sending Hellos over multicast is the > only in-band way to perform neighbour discovery. There is another possibility here. On startup both unicast and multicast hellos are sent with the same seqno (what does babel do presently with duplicate packets?). If a unicast IHU comes in response, the receiver has proven itself capable of taking unicast hello. If all the connections on that interface prove unicast capable, we switch to unicast consistently throughout that interface, otherwise we stick with multicast. (I don't regard the overhead of checking the dest address inside the hello routine as all that much) > > Two kinds of Hellos, distinguished using a flag > *********************************************** > > David suggests that we have two Seqno counters: a per-interface and > a per-neighbour counter. The two kinds of counters run independently. > A flag in the Hello packet's Reserved field serves to distinguish the two= . > > This is simple, elegant, and require few protocol changes. Unfortunately= , > legacy implementations that don't parse the Reserved field will get > confused, and spuriously tear down neighbour associations when they see > discontinuities in the seqno. However, no flag day is necessary: we firs= t > deploy implementations that understand the Reserved field, but don't send > any unicast Hellos. At a later date, when legacy implementations have > disappeared, we start sending unicast Hellos. > > This is currently my preferred solution. > > Two kinds of Hellos, using different TLV types > ********************************************** > > My suggestion was to have two Seqno counters, just like in David's > proposal, but use a new TLV number for Unicast hellos. This avoids the > compatibility issue -- unicast Hellos will be ignored by legacy > implementations, so unless an implementation periodically sends multicast > Hellos, it will be ignored by legacy implementations. > > This used to be my preferred solution. David has convinced me to use > a flag, but I'm willing to reconsider. > > Use empty packets > ***************** > > Russ suggested that we interpret every Babel packet as a Hello. This way= , > sending an empty packet (just the packet header) will play the role of > a Hello. This has two significant flaws: > > - there is no seqno or interval in the Babel header; > - there is no way to attach a sub-TLV to an empty packet, most notably > a timestamp. > > This is not acceptable to me. > > Something else? > *************** > > Other ideas? > > Other issues > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > What does Interval mean? > ************************ > > Currently, the Interval field of a (multicast) Hello is a promise to send > another (multicast) Hello within the given time. If we switch to having > two kinds of Hello, what does Interval mean? Is it a promise to send any > kind of Hello in the given interval, or a promise to send the same kind o= f > Hello within the given interval. The former makes more sense to me, but > I'm willing to be convinced otherwise. > > How is link quality estimated? > ****************************** > > Most implementations of Babel use Hello history to derive a link quality > for each neighbourship association; this is described in Appendix A of > RFC 6126. How is link quality computed in the presence of two kinds of > Hellos? Please consider that at least in 802.11, unicast is protected by > ARQ while multicast isn't. > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org From nobody Mon Apr 3 16:36:58 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 21B761294EE for ; Mon, 3 Apr 2017 16:36:52 -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 cE7GNaoktnB1 for ; Mon, 3 Apr 2017 16:36:49 -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 3B7AE1289C3 for ; Mon, 3 Apr 2017 16:36:49 -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 v33NakBp004266; Tue, 4 Apr 2017 01:36:46 +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 4FFF2D78B7; Tue, 4 Apr 2017 01:36:46 +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 BtBauDG-k8yc; Tue, 4 Apr 2017 01:36:45 +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 37165D78F6; Tue, 4 Apr 2017 01:36:44 +0200 (CEST) Date: Tue, 04 Apr 2017 01:37:11 +0200 Message-ID: <878tnhcbbs.wl-jch@irif.fr> From: Juliusz Chroboczek To: Dave Taht Cc: Babel at IETF In-Reply-To: References: <87a87xooxm.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, 04 Apr 2017 01:36:46 +0200 (CEST) X-Miltered: at korolev with ID 58E2DC8E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58E2DC8E.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 : 58E2DC8E.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 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, 03 Apr 2017 23:36:52 -0000 > You elided the rtt estimation extension from the above discussion, and > I tend to think that that is part of a way out, and must be part of > the unicast hello. Of course, we want any sub-RTT of Hello to apply to unicast Hello. This applies to the RTT extension, and hence makes it possible to use unicast Hello, unicast IHU, and RTT all in the same packet. This happens automatically if unicast Hello is just a variant of Hello. If there's a new TLV, it requires just a minor update to the RTT extension. -- Juliusz From nobody Mon Apr 3 16:37: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 8B92E129527 for ; Mon, 3 Apr 2017 16:37: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 ulsnV5E-EzIS for ; Mon, 3 Apr 2017 16:37:55 -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 D0C23129455 for ; Mon, 3 Apr 2017 16:37: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 v33NbnN4004392; Tue, 4 Apr 2017 01:37: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 BEC0CD78C3; Tue, 4 Apr 2017 01:37:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id DjbYNSe90BIv; Tue, 4 Apr 2017 01:37: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 D4F84D78B7; Tue, 4 Apr 2017 01:37:48 +0200 (CEST) Date: Tue, 04 Apr 2017 01:38:16 +0200 Message-ID: <877f31cb9z.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Babel at IETF In-Reply-To: <82AF6CF4-F062-43D4-AC02-D412D1AF76BE@apple.com> References: <87a87xooxm.wl-jch@irif.fr> <82AF6CF4-F062-43D4-AC02-D412D1AF76BE@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, 04 Apr 2017 01:37:50 +0200 (CEST) X-Miltered: at korolev with ID 58E2DCCD.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58E2DCCD.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 : 58E2DCCD.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] Unicast 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: Mon, 03 Apr 2017 23:37:56 -0000 > I can volunteer to write draft text towards adding this to the document, > if there is consensus on the list. Noted, thanks. But let's have an implementation first. -- Juliusz From nobody Mon Apr 3 19:15:02 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 93BA412953C for ; Mon, 3 Apr 2017 19:15:00 -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 Ar9I0TxaKFiq for ; Mon, 3 Apr 2017 19:14:58 -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 7DE0C12953B for ; Mon, 3 Apr 2017 19:14:58 -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 v342EuUF026457; Tue, 4 Apr 2017 04:14:56 +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 F094CD78B7; Tue, 4 Apr 2017 04:14:55 +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 hH7BF6W1u8Da; Tue, 4 Apr 2017 04:14:54 +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 7B394D78F6; Tue, 4 Apr 2017 04:14:54 +0200 (CEST) Date: Tue, 04 Apr 2017 04:14:54 +0200 Message-ID: <87zifwc40x.wl-jch@irif.fr> From: Juliusz Chroboczek To: Dave Taht Cc: Babel at IETF In-Reply-To: References: <87a87xooxm.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, 04 Apr 2017 04:14:56 +0200 (CEST) X-Miltered: at korolev with ID 58E301A0.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58E301A0.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 : 58E301A0.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 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, 04 Apr 2017 02:15:00 -0000 > There is another possibility here. On startup both unicast and > multicast hellos are sent with the same seqno (what does babel do > presently with duplicate packets?). If a unicast IHU comes in > response, the receiver has proven itself capable of taking unicast > hello. Babel doesn't currently do negotiation: every Babel TLV is designed so that it can be silently ignored if it is not understood. I'm rather keen on it staying that way. If there is consensus that negotiation is the way to go for unicast Hellos, then we should rename the Reserved field of Hello to "Capabilities". Or add a new Capabilities sub-TLV, but at any rate make the negotiation explicit. > (I don't regard the overhead of checking the dest address inside the > hello routine as all that much) No, it's not a lot of work, but it makes Babel dependent on yet another API which might or might not be available on your platform. For the record, here's what it looks like for Sockets: https://github.com/jech/shncpd/blob/master/shncpd.c#L666 -- Juliusz From nobody Mon Apr 3 19:20: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 DA4CA12953B for ; Mon, 3 Apr 2017 19:20:30 -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, RCVD_IN_DNSWL_MED=-2.3, 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=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 HC60Qi9zp8j8 for ; Mon, 3 Apr 2017 19:20:29 -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 0AE6A129537 for ; Mon, 3 Apr 2017 19:20: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=1491272427; 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=S+fof0qBNnJn1ZeqGbMu5F6H/Iy/Y3mcEGParjfOKfU=; b=k4DHuXPVEbh6dblglhoMRpFp7IIbHmlgrzHCmi1QsrBwvxLWsF5mFlT21qYA2wVl mDCgqHiT9zhXlbhpqFngncQrjTLInx4uxhE/ddwuBb21VEvKc+2y7A4Z/M01bs2N l1BhSgtkHy2S4rvurhXOT5oTZJ++lXgivdhjt3aPNqC02O18RcQ4Ix5fiC/5C1of LqicnlE3mTs5cxc3quAaOi+1IEs7TBFmJw+6I7wKu6qfNrMQqu0Fcm/cScysncKu pllBUDOJHM+R7Gp+gJANqEvjBp3pMZKvjLHF2Aze877Gd3RcncTCgPKMyBry3kTQ KYdmeKbsm5jQPTk1roOeow==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id E9.24.23264.9E203E85; Mon, 3 Apr 2017 19:20:27 -0700 (PDT) X-AuditID: 11ab0216-8abfb70000005ae0-76-58e302e90c49 Received: from jimbu (jimbu.apple.com [17.151.62.37]) by relay5.apple.com (Apple SCV relay) with SMTP id 8B.CA.06491.8E203E85; Mon, 3 Apr 2017 19:20:25 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.82.72] (unknown [17.153.82.72]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONV00IPX55X8D20@jimbu.apple.com> for babel@ietf.org; Mon, 03 Apr 2017 19:20:24 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Date: Mon, 03 Apr 2017 19:20:20 -0700 References: <87a87xooxm.wl-jch@irif.fr> <87zifwc40x.wl-jch@irif.fr> To: Babel at IETF In-reply-to: <87zifwc40x.wl-jch@irif.fr> Message-id: X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FAYofua6XGEQe8iEYsti7pZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVceXobJaCLdwVTxe/YWpg7OfsYuTkkBAwkVhy/TdLFyMXh5DA PkaJnz9+M8Ekjl18zQiRWMYo8WdWMyNIgldAUOLH5HtAHRwczALyEgfPy4KEmQW0JL4/aoUa NIFJYtmkBywgCWEBaYmuC3dZQerZgIoOrDGCCCtLzHv7hBXEZhFQlbjz9xLUrj5GidXTVrOB JEQElCQ23/zJDNLLKaAh0bSPE+IEG4lFp36xQdwpK/Hp+U92kF4JgQlsEs+3PGKewCg0C8mp sxBOnYXk1AWMzKsYhXMTM3N0M/OMjPQSCwpyUvWS83M3MYLCdTWT2A7Ge68NDzEKcDAq8fAG 3H0UIcSaWFZcmXuIUZqDRUmcV+TuvQghgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjFLHnQt8 VvZmxC4xO7dSZmJ3XtOCni8vznclO6um+rivXhL18diz/qVcal8co1N2zlDaHNNhFLl+xq6C x+nrJio96f664aTwtkl/7lVefLBavzVaOXzhEp3HAu1VsW3Vc5e+1Wvl136wU9s46mSZ2+3G yV4zZrrlPn4xa+2m+l3RW5k6r4XmGCixFGckGmoxFxUnAgBWUF25OAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUiON1OVfcl0+MIg3MLeSy2LOpmcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpWjs1kKtnBXPF38hqmBsZ+zi5GTQ0LAROLYxdeMXYxcHEIC yxgl/sxqZgRJ8AoISvyYfI+li5GDg1lAXuLgeVmQMLOAlsT3R60sEPUTmCSWTXrAApIQFpCW 6LpwlxWkng2o6MAaI4iwssS8t09YQWwWAVWJO38vQe3qY5RYPW01G0hCREBJYvPNn8wgvZwC GhJN+zghTrCRWHTqFxvEnbISn57/ZJ/AyD8LyXWzEK6bheS6BYzMqxgFilJzEitN9RILCnJS 9ZLzczcxgoKroTBiB+P/ZVaHGAU4GJV4eBc4PYoQYk0sK67MPcQowcGsJMJ7ZSJQiDclsbIq tSg/vqg0J7X4EGMV0P0TmaVEk/OBgZ9XEm9oYmJgYmxsZmxsbmJOFWElcd6c8nsRQgLpiSWp 2ampBalFMMuZODilGhgvOX04Nn/tR2f+DckN9XpHVHasmheu/FNuX0BU2Tb90Ah52aj5xq17 Z/Fefqcxjyna62wAX2X6hbmaBtfu3ZzEsvnehqVXvytbhs5g7HufwHv/9tmUywwL2HjyeFJv p4bPvyNsEudzN3XVRF8lz4g3hbH+b55um992LuNARdq34xfmMrJ0X2NSYinOSDTUYi4qTgQA TFnzN4kCAAA= Archived-At: Subject: Re: [babel] Unicast 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, 04 Apr 2017 02:20:31 -0000 I'd rather keep Babel free of capability negotiation if we can, and unicast hellos can be safely deployed without them. David > On Apr 3, 2017, at 19:14, Juliusz Chroboczek wrote: > >> There is another possibility here. On startup both unicast and >> multicast hellos are sent with the same seqno (what does babel do >> presently with duplicate packets?). If a unicast IHU comes in >> response, the receiver has proven itself capable of taking unicast >> hello. > > Babel doesn't currently do negotiation: every Babel TLV is designed so > that it can be silently ignored if it is not understood. I'm rather keen > on it staying that way. > > If there is consensus that negotiation is the way to go for unicast Hellos, > then we should rename the Reserved field of Hello to "Capabilities". Or > add a new Capabilities sub-TLV, but at any rate make the negotiation > explicit. > >> (I don't regard the overhead of checking the dest address inside the >> hello routine as all that much) > > No, it's not a lot of work, but it makes Babel dependent on yet another > API which might or might not be available on your platform. For the > record, here's what it looks like for Sockets: > > https://github.com/jech/shncpd/blob/master/shncpd.c#L666 > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Tue Apr 4 03:04:35 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 E485F128896 for ; Tue, 4 Apr 2017 03:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 jlxYJ18KJxyp for ; Tue, 4 Apr 2017 03:04:33 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (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 AB609129420 for ; Tue, 4 Apr 2017 03:04:31 -0700 (PDT) Received: from mail.toke.dk (localhost.localdomain [127.0.0.1]) by mail.toke.dk (Postfix) with ESMTPS id 8FF90B0A40; Tue, 4 Apr 2017 12:04:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1491300267; bh=kpOpGTEuxp6dtM7JNKjdyewij9FGPnM5WW/72iSbPEU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=vtXnZFHUkTZF7vNK3JHZ5sUJnhOb8zw9F7E8Z4DW+xt3YzLNF2/Pg5TbSpvZP4zuT Rv5rR7SSucqwm19TJ6WSZtbbjmW/iF2buJPTE4Bpl4lG8t2qGQfQe4Ni45q6rLWFdF wQVcc5x8M1Zgd1AM5GtSzhO7AY8dkqRTP+XFugSuTExTOkyTILYKotuuu1qalGqWKs T7QQLEyK5pHKnNxPvULSS81xKZnOjMQxrd9ShbdurgO0sVs6zM/HA+VroXGXUeffgB 7cLaCtg2Xe1RnJZR6Ve50TeKZGTIRlRevFtqM8uZqAGmBiZpT5tzxwmdIchUlHVFi7 jcGfSdndt1UIA== Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id F0B72C4027C; Tue, 4 Apr 2017 12:04:25 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: David Schinazi Cc: Babel at IETF References: <87a87xooxm.wl-jch@irif.fr> <82AF6CF4-F062-43D4-AC02-D412D1AF76BE@apple.com> Date: Tue, 04 Apr 2017 12:04:25 +0200 In-Reply-To: <82AF6CF4-F062-43D4-AC02-D412D1AF76BE@apple.com> (David Schinazi's message of "Mon, 03 Apr 2017 10:11:46 -0700") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <874ly4wkt2.fsf@alrua-kau> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] [Babel-users] Unicast 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, 04 Apr 2017 10:04:35 -0000 David Schinazi writes: > Hi Juliusz, thanks for writing this up! > > I agree with your problem statement and preferred solution using a > flag, and I like the 2-step deployment plan. It has the advantage that > further down the road we won't have to explain to our grandchildren > why we have a separate TLV for unicast Hellos. I like the "two different types of Hellos" approach; I think a flag is probably the simpler approach, but don't have strong opinions either way. -Toke From nobody Tue Apr 4 17:30: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 AA7E812950B for ; Tue, 4 Apr 2017 17:30:13 -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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po49ml8hGyoW for ; Tue, 4 Apr 2017 17:30:11 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 51E34129459 for ; Tue, 4 Apr 2017 17:30:11 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id i5so25704789pfc.2 for ; Tue, 04 Apr 2017 17:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=+yAQhEKhqPnUIG8KMPQg5f08KmiK4XPBzsYIC72AidE=; b=Z7m8crQJxfunMKtJBy15VLy/QRowiWOh+13W2xuUqsGfzTWpnL3k6AF1TMJ8FkW+5N kXFnViOXDXzkZ/nGVIARqUoYonPMGNwb0cmR0WFVrqgIhuQUN+UXw4MXBD1Lt/MbXI3z wU9USKGa6DejDFfGuwADQqfc4R+Nrm1eKtec726AS3zHY11Bw+kndTVv7J4+YveJHs7/ TiHCzhj8UrCRtgmthXTZEDYwovj/8BkeIkH//NxAIeLiKH9CFsXprqua7F8d8kJGMyTB NbT+HTLnf/R77L46E/LaIvlwIM8Bhu4g/g4CkxQCSIvmD4cdlUqCjhZNKU+IoribqM6u YHxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=+yAQhEKhqPnUIG8KMPQg5f08KmiK4XPBzsYIC72AidE=; b=C1eVbk9fznyoL1HP4E3BwKf0gJVuzZvoSKx3iw74niCu9oRPqOJp6SIyhW0G/o2jO7 Mw3z5BNujnUyqv+ZaTu7/2dUX5NBBCTLjIC5Pz+T6X5ZgECUwPmlo5bOrhewxRTPHNpK qNP/AgT+n6wNNcXO1SSAxjcBAh5MfpeLElUk+GPE4XjED8uGBLdcCMVUulffM100ozwl gBjuaKYVKwGEOHyO/If1S6FjH4/GYpfuw1+MyXn9kw4hf2QeS7vSgJjNIyCgZwgD7rZL il98Pkp46x4rB2v9IZWrPuk1qRtEu6KzjZxGhjol5ALb+RNRQwOBQg3Jd5B4lGwlqo3O fxdg== X-Gm-Message-State: AFeK/H1rReSiKQuvaqtYCFwtKS52FyOcyBASiHkZD6M6fTBBPDqNhJPTj0x3Q5RVSI1Es0Xd X-Received: by 10.84.231.201 with SMTP id g9mr32830298pln.1.1491352210499; Tue, 04 Apr 2017 17:30:10 -0700 (PDT) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id r13sm33772755pfg.55.2017.04.04.17.30.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 17:30:09 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_0ED10953-AC13-400E-AE81-5762297D9F8E" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 4 Apr 2017 17:30:08 -0700 References: <87a87xooxm.wl-jch@irif.fr> To: babel@ietf.org, babel-users@lists.alioth.debian.org In-Reply-To: <87a87xooxm.wl-jch@irif.fr> Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [babel] Unicast 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: Wed, 05 Apr 2017 00:30:14 -0000 --Apple-Mail=_0ED10953-AC13-400E-AE81-5762297D9F8E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 3, 2017, at 01:50, Juliusz Chroboczek wrote: >=20 > Something else? > *************** >=20 > Other ideas? I want to explore the idea of finding the minimum possible change to the = protocol to make the necessary refinement and still permit multicast = Hello for in-band neighbor acquisition. Without any changes to the protocol, I=E2=80=99m not sure it=E2=80=99s = strictly true that it=E2=80=99s impossible to multicast a Hello after = unicasting with different intervals and desynchronized Hello seqno = progressions to two or more different neighbours. Yes, the reverse = reachability detection logic says that when a Babel speaker receives a = Hello, when it can determine that a previous Hello seqno was not = received, it recomputes the association cost and recommences the route = selection procedure. Accordingly, it could be prohibitively costly to = force a discontinuity in the Hello seqno at every periodic multicast in = any system where, except for neighbor acquisition, speakers normally = send only unicast Hello messages, so judiciously redefining the 16-bit = reserved field in the Hello message to help with that problem may be = warranted. One approach is to define a (D)ISCONTINUITY flag for use only in unicast = Hello messages, which a Babel speaker would use to signal to its = neighbours that a Hello seqno discontinuity SHOULD be expected in = processing this message, therefore recomputing the association cost and = recommencing the route selection procedure is NOT RECOMMENDED. Instead = neighbours would update their history information in the Neighbor Table = entry for the speaker to disregard the discontinuity and make no = adjustment to the rxcost. Babel speakers that can send both unicast and multicast Hello messages = would immediately precede every multicast (interval=3DT, seqno=3DN) by = unicasting (D=3D1, interval=3DT, seqno=3DN-1) to each neighbour that was = most previously unicast a Hello other than (seqno=3DN-1). Speakers = SHOULD choose N to minimize the number of independent unicasts preceding = a multicast. The interval MUST be the same in all the unicasts and the = multicast, so every neighbour will store the correct interval value in = their Neighbour Table for use in recomputing the association cost, which = happens for each neighbour as one of three possible cases: 1) the = unicast message with (D=3D1, seqno=3DN-1) is lost and the multicast = (D=3D0, seqno=3DN) is received and N is recognized as discontinuous, = adjusting rxcost to account for the loss of one unicast Hello packet, 2) = the multicast message with (D=3D0, seqno=3DN) is lost, the unicast (D=3D0,= seqno=3DN+1) in the succeeding message is received, and N+1 is then = recognized as discontinuous, adjusting rxcost to account for the loss of = one multicast Hello packet, or 3) both unicast and multicast messages = are lost, in which case the discontinuity will be recognized and rxcost = adjusted by at least two messages (except in the rare case that the most = recently sent Hello seqno for the neighbor is N, when the next delivered = unicast will be seqno=3DN+1, and no adjustment to rxcost will be made, = despite the loss of two packets). In any Babel system where unicast or multicast are used exclusively, no = Hello messages need the D=3D1 signal. In any Babel system with two or = fewer speakers, no Hello messages need the D=3D1 signal. In any Babel = system where every speaker sends the same number Hello messages to every = neighbour it acquires, no Hello messages need the D=3D1 signal. The D=3D1 = signal is only required in a Babel system where 1) a speaker has two or = more neighbours, 2) it unicasts Hello to two or more of them with = different interval and Hello seqno progressions, then 3) it later needs = to multicast a Hello without forcing all but one of the neighbors to = recompute their association costs and recommence their route selection = procedure. Admittedly, I haven=E2=80=99t yet implemented my own Babel speaker, so = I=E2=80=99m not sure this idea is well-formed. I think this proposal = works even in the case where no multicast is used at all and neighbour = discovery proceeds out of band. --james woodyatt > --Apple-Mail=_0ED10953-AC13-400E-AE81-5762297D9F8E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 3, 2017, at 01:50, Juliusz Chroboczek <jch@irif.fr> wrote:

Something else?
***************

Other = ideas?

I want to explore the idea of finding the = minimum possible change to the protocol to make the necessary refinement = and still permit multicast Hello for in-band neighbor = acquisition.

Without any changes to = the protocol, I=E2=80=99m not sure it=E2=80=99s strictly true that = it=E2=80=99s impossible to multicast a Hello after unicasting with = different intervals and desynchronized Hello seqno progressions to two = or more different neighbours. Yes, the reverse reachability detection = logic says that when a Babel speaker receives a Hello, when it can = determine that a previous Hello seqno was not received, it recomputes = the association cost and recommences the route selection procedure. = Accordingly, it could be prohibitively costly to force a discontinuity = in the Hello seqno at every periodic multicast in any system where, = except for neighbor acquisition, speakers normally send only unicast = Hello messages, so judiciously redefining the 16-bit reserved field in = the Hello message to help with that problem may be = warranted.

One approach is to define = a (D)ISCONTINUITY flag for use only in unicast Hello messages, which a = Babel speaker would use to signal to its neighbours that a Hello seqno = discontinuity SHOULD be expected in processing this message, therefore = recomputing the association cost and recommencing the route selection = procedure is NOT RECOMMENDED. Instead neighbours would update their = history information in the Neighbor Table entry for the speaker to = disregard the discontinuity and make no adjustment to the = rxcost.

Babel speakers that can send = both unicast and multicast Hello messages would immediately precede = every multicast (interval=3DT, seqno=3DN) by unicasting (D=3D1, = interval=3DT, seqno=3DN-1) to each neighbour that was most previously = unicast a Hello other than (seqno=3DN-1). Speakers SHOULD choose N to = minimize the number of independent unicasts preceding a multicast. The = interval MUST be the same in all the unicasts and the multicast, so = every neighbour will store the correct interval value in their Neighbour = Table for use in recomputing the association cost, which happens for = each neighbour as one of three possible cases: 1) the unicast message = with (D=3D1, seqno=3DN-1) is lost and the multicast (D=3D0, seqno=3DN) = is received and N is recognized as discontinuous, adjusting rxcost to = account for the loss of one unicast Hello packet, 2) the multicast = message with (D=3D0, seqno=3DN) is lost, the unicast (D=3D0, seqno=3DN+1) = in the succeeding message is received, and N+1 is then recognized as = discontinuous, adjusting rxcost to account for the loss of one multicast = Hello packet, or 3) both unicast and multicast messages are lost, in = which case the discontinuity will be recognized and rxcost adjusted by = at least two messages (except in the rare case that the most recently = sent Hello seqno for the neighbor is N, when the next delivered unicast = will be seqno=3DN+1, and no adjustment to rxcost will be made, despite = the loss of two packets).

In any = Babel system where unicast or multicast are used exclusively, no Hello = messages need the D=3D1 signal. In any Babel system with two or fewer = speakers, no Hello messages need the D=3D1 signal. In any Babel system = where every speaker sends the same number Hello messages to every = neighbour it acquires, no Hello messages need the D=3D1 signal. The D=3D1 = signal is only required in a Babel system where 1) a speaker has two or = more neighbours, 2) it unicasts Hello to two or more of them with = different interval and Hello seqno progressions, then 3) it later needs = to multicast a Hello without forcing all but one of the neighbors to = recompute their association costs and recommence their route selection = procedure.

Admittedly, I haven=E2=80=99= t yet implemented my own Babel speaker, so I=E2=80=99m not sure this = idea is well-formed. I think this proposal works even in the case where = no multicast is used at all and neighbour discovery proceeds out of = band.

--james woodyatt <jhw@google.com>

= --Apple-Mail=_0ED10953-AC13-400E-AE81-5762297D9F8E-- From nobody Wed Apr 5 21:50:10 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 7BA531293FC for ; Wed, 5 Apr 2017 21:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 lLYOJ821begr for ; Wed, 5 Apr 2017 21:50:06 -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 32584129409 for ; Wed, 5 Apr 2017 21:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491454205; 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=6wdOW0zZc0bfKLptCYRGvhUr3876nLgR0eY1HfyFupA=; b=lbaBqdcufrnlNNpVVpNIZeVBBvqK/Z16mVF5s0bTAwf/vdFRrX6SUDhwEob8fQM4 tsnbmCZJNGJb3FnY/jKxdTPoSiMgvI03zqEwViIb2XL9ymSHZ5azq6OyZHj6mmWP wmDy9f35MYQrlF/LqCYjJccooGzWUTQ45gSmPgB8R2wxlrg3yJRdtTtaQ77Ugvtk cxpw5FsHzEkxSU6mwzqOU6PbSAuTnwDip5ErQizpjczYjPl39rD8D031UFLpWi3E quaNukDCceyBESzMKUV7TZJ0EB1ozpketjxcg8SFV0paXvWpznOJMRpFbaMcLAVf Z+dEG6X4SMJt68XVlTUbOA==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id 3A.41.09505.CF8C5E85; Wed, 5 Apr 2017 21:50:05 -0700 (PDT) X-AuditID: 11ab0219-dc2b19a000002521-db-58e5c8fce46e Received: from koseret (koseret.apple.com [17.151.62.39]) by relay5.apple.com (Apple SCV relay) with SMTP id 86.17.06491.BF8C5E85; Wed, 5 Apr 2017 21:50:04 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_dLNo3pA7Z2+2P/YmjedUig)" Received: from [17.153.39.228] (unknown [17.153.39.228]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONZ00M921FE3R60@koseret.apple.com>; Wed, 05 Apr 2017 21:50:03 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Wed, 05 Apr 2017 21:50:02 -0700 In-reply-to: Cc: Babel at IETF To: james woodyatt References: <87a87xooxm.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUi2FAYofv3xNMIgze3eS22LOpmsfjZdojZ gcljwaZSjyVLfjIFMEVx2aSk5mSWpRbp2yVwZfS1n2YrmJBU0fp+EUsD46+gLkZODgkBE4mF 3/Yzg9hCAvsYJZpvV8PEp515xNrFyAUUX8UosX72WXaQBK+AoMSPyfdYQGxmgTCJnuUXmCGK WpkkDl1/ATZJWEBaouvCXaBuDg42AS2JA2uMIHptJNYfPQlVYihx+sJNNpASFgFViT8rVUBM TgE7iS3ndSCmK0ms/nYHrFpEQFni+oFfUGdGS6w6uJMV4kxZiU/Pf7KDXCAh8JtN4vvnLUwT GIVmIbl0FpJLZwGtYBZQl5gyJRcirC3x5N0FVghbTWLh70VMyOILGNlWMQrnJmbm6GbmGZnq JRYU5KTqJefnbmIERcFqJskdjF9fGx5iFOBgVOLhDTB9GiHEmlhWXJl7iFGag0VJnHdnCVBI ID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo9Mhhrfnm0WXFgU9mWpukMGd9mLiGgnOlqJZiyYs Zy/2LY7+ciNbttz6uNAd2UuBfV/+Kyh8zd0neb/r+uXsovRFh+q9OC7GPfh38ora22w1truT 48603H+4Vsfmxda5IfL3mjYE1E2xbNRf/uuAfcXZNdf9VH/MvfnqVYrZhDlPbqx7ndludEiJ pTgj0VCLuag4EQCHAUBqYwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUiON1OXffPiacRBo1rlCy2LOpmsfjZdojZ gcljwaZSjyVLfjIFMEVZ26TlF5UnFqUoFCUXlNgqFWckpuSXx1saG5k6JBYU5KTqJefnKunb 2aSk5mSWpRYhsxKsM/raT7MVTEiqaH2/iKWB8VdQFyMnh4SAicS0M49Yuxi5OIQEVjFKrJ99 lh0kwSsgKPFj8j0WEJtZIEyiZ/kFZoiiViaJQ9dfMIMkhAWkJbou3AXq5uBgE9CSOLDGCKLX RmL90ZNQJYYSpy/cZAMpYRFQlfizUgXE5BSwk9hyXgdiupLE6m93wKpFBJQlrh/4BWYLCURL rDq4kxXiTFmJT89/sk9g5J+F5LhZSI6bBTSVWUBdYsqUXIiwtsSTdxdYIWw1iYW/FzEhiy9g ZFvFKFCUmpNYaaoHD7xNjKC4aCiM2MH4f5nVIUYBDkYlHt4FT59ECLEmlhVX5h5ilOBgVhLh TZ/9NEKINyWxsiq1KD++qDQntfgQ435GoBcnMkuJJucDozavJN7Q2MLY0sTCwMDE0syEsLCJ iYGJsbGZsbG5iTkthZXEeTfeexwhJJCeWJKanZpakFoE8wITB6dUA2OZvvblonkfO2wSW0+X r5nrMy9Go9O8eudN/uITqVc54nL+fv177nDt3BKbYsaOp67PBF8yZKkxVn7OYjBfnPFB/tf6 txEfNP0kPW538n99vVyYe4n2IWUV6SQ2b6k/c7Y+dbs1zY9Vp0d0u798/olwyQXbd7FEO+iv ucngM/3Nw8e7+fTSZyqxAJO2oRZzUXEiAGJdp9gsAwAA Archived-At: Subject: Re: [babel] [Babel-users] Unicast 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: Thu, 06 Apr 2017 04:50:09 -0000 --Boundary_(ID_dLNo3pA7Z2+2P/YmjedUig) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi James, I'm not sure this will work, especially if a speaker sends unicast and = multicast at similar frequencies. Having two seqno counters is simpler, and allows speakers to know the = drop rate on both unicast and multicast. I'm also not sure your proposal is a smaller change to the protocol. David > On Apr 4, 2017, at 17:30, james woodyatt wrote: >=20 > On Apr 3, 2017, at 01:50, Juliusz Chroboczek > wrote: >>=20 >> Something else? >> *************** >>=20 >> Other ideas? >=20 > I want to explore the idea of finding the minimum possible change to = the protocol to make the necessary refinement and still permit multicast = Hello for in-band neighbor acquisition. >=20 > Without any changes to the protocol, I=E2=80=99m not sure it=E2=80=99s = strictly true that it=E2=80=99s impossible to multicast a Hello after = unicasting with different intervals and desynchronized Hello seqno = progressions to two or more different neighbours. Yes, the reverse = reachability detection logic says that when a Babel speaker receives a = Hello, when it can determine that a previous Hello seqno was not = received, it recomputes the association cost and recommences the route = selection procedure. Accordingly, it could be prohibitively costly to = force a discontinuity in the Hello seqno at every periodic multicast in = any system where, except for neighbor acquisition, speakers normally = send only unicast Hello messages, so judiciously redefining the 16-bit = reserved field in the Hello message to help with that problem may be = warranted. >=20 > One approach is to define a (D)ISCONTINUITY flag for use only in = unicast Hello messages, which a Babel speaker would use to signal to its = neighbours that a Hello seqno discontinuity SHOULD be expected in = processing this message, therefore recomputing the association cost and = recommencing the route selection procedure is NOT RECOMMENDED. Instead = neighbours would update their history information in the Neighbor Table = entry for the speaker to disregard the discontinuity and make no = adjustment to the rxcost. >=20 > Babel speakers that can send both unicast and multicast Hello messages = would immediately precede every multicast (interval=3DT, seqno=3DN) by = unicasting (D=3D1, interval=3DT, seqno=3DN-1) to each neighbour that was = most previously unicast a Hello other than (seqno=3DN-1). Speakers = SHOULD choose N to minimize the number of independent unicasts preceding = a multicast. The interval MUST be the same in all the unicasts and the = multicast, so every neighbour will store the correct interval value in = their Neighbour Table for use in recomputing the association cost, which = happens for each neighbour as one of three possible cases: 1) the = unicast message with (D=3D1, seqno=3DN-1) is lost and the multicast = (D=3D0, seqno=3DN) is received and N is recognized as discontinuous, = adjusting rxcost to account for the loss of one unicast Hello packet, 2) = the multicast message with (D=3D0, seqno=3DN) is lost, the unicast (D=3D0,= seqno=3DN+1) in the succeeding message is received, and N+1 is then = recognized as discontinuous, adjusting rxcost to account for the loss of = one multicast Hello packet, or 3) both unicast and multicast messages = are lost, in which case the discontinuity will be recognized and rxcost = adjusted by at least two messages (except in the rare case that the most = recently sent Hello seqno for the neighbor is N, when the next delivered = unicast will be seqno=3DN+1, and no adjustment to rxcost will be made, = despite the loss of two packets). >=20 > In any Babel system where unicast or multicast are used exclusively, = no Hello messages need the D=3D1 signal. In any Babel system with two or = fewer speakers, no Hello messages need the D=3D1 signal. In any Babel = system where every speaker sends the same number Hello messages to every = neighbour it acquires, no Hello messages need the D=3D1 signal. The D=3D1 = signal is only required in a Babel system where 1) a speaker has two or = more neighbours, 2) it unicasts Hello to two or more of them with = different interval and Hello seqno progressions, then 3) it later needs = to multicast a Hello without forcing all but one of the neighbors to = recompute their association costs and recommence their route selection = procedure. >=20 > Admittedly, I haven=E2=80=99t yet implemented my own Babel speaker, so = I=E2=80=99m not sure this idea is well-formed. I think this proposal = works even in the case where no multicast is used at all and neighbour = discovery proceeds out of band. >=20 > --james woodyatt > >=20 > _______________________________________________ > Babel-users mailing list > Babel-users@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users --Boundary_(ID_dLNo3pA7Z2+2P/YmjedUig) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi James,

I'm not sure this will work, especially if a speaker sends = unicast and multicast at similar frequencies.
Having = two seqno counters is simpler, and allows speakers to know the drop rate = on both unicast and multicast.
I'm also not sure = your proposal is a smaller change to the protocol.

David


On = Apr 4, 2017, at 17:30, james woodyatt <jhw@google.com> = wrote:

On Apr 3, = 2017, at 01:50, Juliusz Chroboczek <jch@irif.fr> wrote:

Something else?
***************

Other = ideas?

I want to explore the idea of = finding the minimum possible change to the protocol to make the = necessary refinement and still permit multicast Hello for in-band = neighbor acquisition.

Without any changes to the protocol, I=E2=80=99m not sure = it=E2=80=99s strictly true that it=E2=80=99s impossible to multicast a = Hello after unicasting with different intervals and desynchronized Hello = seqno progressions to two or more different neighbours. Yes, the reverse = reachability detection logic says that when a Babel speaker receives a = Hello, when it can determine that a previous Hello seqno was not = received, it recomputes the association cost and recommences the route = selection procedure. Accordingly, it could be prohibitively costly to = force a discontinuity in the Hello seqno at every periodic multicast in = any system where, except for neighbor acquisition, speakers normally = send only unicast Hello messages, so judiciously redefining the 16-bit = reserved field in the Hello message to help with that problem may be = warranted.

One = approach is to define a (D)ISCONTINUITY flag for use only in unicast = Hello messages, which a Babel speaker would use to signal to its = neighbours that a Hello seqno discontinuity SHOULD be expected in = processing this message, therefore recomputing the association cost and = recommencing the route selection procedure is NOT RECOMMENDED. Instead = neighbours would update their history information in the Neighbor Table = entry for the speaker to disregard the discontinuity and make no = adjustment to the rxcost.

Babel speakers that can send both unicast and multicast Hello = messages would immediately precede every multicast (interval=3DT, = seqno=3DN) by unicasting (D=3D1, interval=3DT, seqno=3DN-1) to each = neighbour that was most previously unicast a Hello other than = (seqno=3DN-1). Speakers SHOULD choose N to minimize the number of = independent unicasts preceding a multicast. The interval MUST be the = same in all the unicasts and the multicast, so every neighbour will = store the correct interval value in their Neighbour Table for use in = recomputing the association cost, which happens for each neighbour as = one of three possible cases: 1) the unicast message with (D=3D1, = seqno=3DN-1) is lost and the multicast (D=3D0, seqno=3DN) is received = and N is recognized as discontinuous, adjusting rxcost to account for = the loss of one unicast Hello packet, 2) the multicast message with = (D=3D0, seqno=3DN) is lost, the unicast (D=3D0, seqno=3DN+1) in the = succeeding message is received, and N+1 is then recognized as = discontinuous, adjusting rxcost to account for the loss of one multicast = Hello packet, or 3) both unicast and multicast messages are lost, in = which case the discontinuity will be recognized and rxcost adjusted by = at least two messages (except in the rare case that the most recently = sent Hello seqno for the neighbor is N, when the next delivered unicast = will be seqno=3DN+1, and no adjustment to rxcost will be made, despite = the loss of two packets).

In any Babel system where unicast or multicast are used = exclusively, no Hello messages need the D=3D1 signal. In any Babel = system with two or fewer speakers, no Hello messages need the D=3D1 = signal. In any Babel system where every speaker sends the same number = Hello messages to every neighbour it acquires, no Hello messages need = the D=3D1 signal. The D=3D1 signal is only required in a Babel system = where 1) a speaker has two or more neighbours, 2) it unicasts Hello to = two or more of them with different interval and Hello seqno = progressions, then 3) it later needs to multicast a Hello without = forcing all but one of the neighbors to recompute their association = costs and recommence their route selection procedure.

Admittedly, I haven=E2=80=99= t yet implemented my own Babel speaker, so I=E2=80=99m not sure this = idea is well-formed. I think this proposal works even in the case where = no multicast is used at all and neighbour discovery proceeds out of = band.

--james woodyatt <jhw@google.com>

_____________________________________________= __
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-u= sers

= --Boundary_(ID_dLNo3pA7Z2+2P/YmjedUig)-- From nobody Thu Apr 6 11:27: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 5A63112741D for ; Thu, 6 Apr 2017 11:27:04 -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, 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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzuOqTnvYx66 for ; Thu, 6 Apr 2017 11:27:02 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 80548127775 for ; Thu, 6 Apr 2017 11:27:02 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id y18so31146421itc.1 for ; Thu, 06 Apr 2017 11:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gZ6yelrGLm+5xEKS5bTrlz5FufXkFZgnAE81DDS2gYY=; b=urZ9Va1YcCz3VqHT2GURGyw/AipqRO/DQ/cFVPNC10awsx+0q5UuujmahKQzzERaoh 4VZr+cEMDvvZUnurjO8aCjlXgwYI8ik+IiE/mFhzQq5lfXyEMJzRUGqjUwekSnmC4Ops Q4ZNZrdnXDaRxpisX/V2hEtIxHcqO/ZrjVTBDIjoXan3Yl38S+oDF7+cv9K933VW5O/P 4b41ehY3L/1bI1l5BuwmXxgwdBkFvoTBse5Jt+uoQg3kPBC9dhCjm5rOCy/5RU7Tn01w vQQfL1YV5Ik4rp6wwKLd3A6VyXXDh7vT9X9LXNPAuKcnROeIBWYYHsPfFFDbr/KJqEJA DQ8w== 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=gZ6yelrGLm+5xEKS5bTrlz5FufXkFZgnAE81DDS2gYY=; b=ckpOLe5eIiVAbAzBANM8jkgun9SPVrURjxiGwGkaQ8QRfeiR4qI+SvtE1qVeKZQ1JE vOmC4tKz9sm/Htr5WaWBBJSMWxYbLpzXZGdEcdlPK92WgIpkU+7oCTt6G0VfhWJPqiVG yramt2OUIOyMWGQD85SVcOooAMXySIUQb0tWJ6woU1veNKNy66Y8LIT77bqThWinU8vp DRsHt4CeanJ8p7mFb5Upp8bVUnT0ZF+GUp7fVF9HToiiEj9+cKjXLDivX+mf+oHWtAb3 dCwxMs1B4X/kKsQoD4S+9qO2QMnx14KEikLv9EFXp9gxZb1LZ6HwUrrr2mfLwgxyU7nc XhAg== X-Gm-Message-State: AFeK/H2Yf5CqF/w96tDOFMzhbfcy4QT85oqdDsqk5axZIDb4AQxF23Jk7fjZLkZ6IWonEYtR X-Received: by 10.36.123.16 with SMTP id q16mr22924499itc.52.1491503221655; Thu, 06 Apr 2017 11:27:01 -0700 (PDT) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id b132sm1271836iob.6.2017.04.06.11.26.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 11:27:00 -0700 (PDT) From: james woodyatt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DB607A02-5A0F-4557-B0B0-1AC6BC5F37B4" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 6 Apr 2017 11:26:34 -0700 In-Reply-To: Cc: Babel at IETF To: David Schinazi References: <87a87xooxm.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [babel] [Babel-users] Unicast 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: Thu, 06 Apr 2017 18:27:04 -0000 --Apple-Mail=_DB607A02-5A0F-4557-B0B0-1AC6BC5F37B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 5, 2017, at 21:50, David Schinazi wrote: >=20 > I'm not sure this will work, especially if a speaker sends unicast and = multicast at similar frequencies. I thought pretty hard about that problem, and I don=E2=80=99t think I = see why it shouldn=E2=80=99t work. Please elaborate. > Having two seqno counters is simpler, and allows speakers to know the = drop rate on both unicast and multicast. > I'm also not sure your proposal is a smaller change to the protocol. So I tried pretty hard to keep from having to make major changes to the = data structures in section 3.2. In particular, this is why I didn=E2=80=99= t propose adding flags to the IHU message to invite neighbours to send = unicasts potentially with D=3D1. I wanted to be confident that existing = implementations could receive unicast Hello messages and everything = would still work despite them ignoring the D=3D1 signal. I agree that it = would be nice for Babel speakers to have two separate rxcost metrics, = one for unicast and another for multicast, but it doesn=E2=80=99t right = now, and I thought proposals to add that would be too much of a = departure. Even proposing to change the structure of the Neighbour Table = entry to add a second type of Hello seqno seemed like a big change with = serous interoperability considerations. Can you be more specific about what you think my proposal will break? --james woodyatt > --Apple-Mail=_DB607A02-5A0F-4557-B0B0-1AC6BC5F37B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 5, 2017, at 21:50, David Schinazi <dschinazi@apple.com>= wrote:

I'm not sure this will = work, especially if a speaker sends unicast and multicast at similar = frequencies.

I thought pretty hard about that problem, and I = don=E2=80=99t think I see why it shouldn=E2=80=99t work. Please = elaborate.

Having two seqno counters is simpler, and allows speakers to = know the drop rate on both unicast and = multicast.
I'm also not sure your proposal is a smaller = change to the protocol.

So I tried pretty hard to keep from having to make = major changes to the data structures in section 3.2. In particular, this = is why I didn=E2=80=99t propose adding flags to the IHU message to = invite neighbours to send unicasts potentially with D=3D1. I wanted to = be confident that existing implementations could receive unicast Hello = messages and everything would still work despite them ignoring the D=3D1 = signal. I agree that it would be nice for Babel speakers to have two = separate rxcost metrics, one for unicast and another for multicast, but = it doesn=E2=80=99t right now, and I thought proposals to add that would = be too much of a departure. Even proposing to change the structure of = the Neighbour Table entry to add a second type of Hello seqno seemed = like a big change with serous interoperability = considerations.

Can you be more = specific about what you think my proposal will break?


--james woodyatt <jhw@google.com>



= --Apple-Mail=_DB607A02-5A0F-4557-B0B0-1AC6BC5F37B4-- From nobody Thu Apr 6 14:49: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 6287C129682 for ; Thu, 6 Apr 2017 14:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, 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 7-0rTZf3djKo for ; Thu, 6 Apr 2017 14:49:48 -0700 (PDT) Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.229]) by ietfa.amsl.com (Postfix) with ESMTP id 7B50012967F for ; Thu, 6 Apr 2017 14:49:48 -0700 (PDT) Received: from poro.lan (80.220.131.63) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 58A591F80115BF8E for babel@ietf.org; Fri, 7 Apr 2017 00:49:47 +0300 From: Markus Stenberg Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 7 Apr 2017 00:49:46 +0300 References: <87a87xooxm.wl-jch@irif.fr> To: babel@ietf.org In-Reply-To: <87a87xooxm.wl-jch@irif.fr> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [babel] Unicast 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: Thu, 06 Apr 2017 21:49:51 -0000 On 3 Apr 2017, at 11.50, Juliusz Chroboczek wrote: > Two kinds of Hellos, using different TLV types > ********************************************** >=20 > My suggestion was to have two Seqno counters, just like in David's > proposal, but use a new TLV number for Unicast hellos. This avoids = the > compatibility issue -- unicast Hellos will be ignored by legacy > implementations, so unless an implementation periodically sends = multicast > Hellos, it will be ignored by legacy implementations. >=20 > This used to be my preferred solution. David has convinced me to use > a flag, but I=E2=80=99m willing to reconsider. In general having both unicast and multicast hellos seems worthwhile = just to estimate both types of payloads=E2=80=99 characteristics on the = link.=20 This is my preference of the listed options. Flag based correct behavior = feels bit dangerous. I am not sure I am entirely happy with any of the listed options though. = I have considered slightly different scheme treating unicast and = multicast as separate logical links for hello purposes (=3D> disjoint = sequence number spaces) but that leads to issues in mixed environments = with both legacy implementations and ones supporting unicast hello spec. = If writing v2 version of protocol without backwards compatibility = requirements, I would probably lean that way (on the wire, hellos would = look same, but sequence # spaces would work bit differently based on = uni<>multicast). Cheers, -Markus= From nobody Thu Apr 6 18:21: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 E07A21296CE for ; Thu, 6 Apr 2017 18:21:09 -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 LkCmKaUO2Ka9 for ; Thu, 6 Apr 2017 18:21:07 -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 97358126FB3 for ; Thu, 6 Apr 2017 18:21:06 -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 v371L1EK014038; Fri, 7 Apr 2017 03:21: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 188E9D78B7; Fri, 7 Apr 2017 03:21: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 3xjbca72J-dL; Fri, 7 Apr 2017 03:21: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 55607D79B8; Fri, 7 Apr 2017 03:20:58 +0200 (CEST) Date: Fri, 07 Apr 2017 03:20:54 +0200 Message-ID: <87tw61rp1l.wl-jch@irif.fr> From: Juliusz Chroboczek To: james woodyatt Cc: David Schinazi , Babel at IETF In-Reply-To: References: <87a87xooxm.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=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 07 Apr 2017 03:21:01 +0200 (CEST) X-Miltered: at korolev with ID 58E6E97D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58E6E97D.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 : 58E6E97D.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] Unicast 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: Fri, 07 Apr 2017 01:21:10 -0000 Yeah, unicast Hellos are surprisingly tricky -- I thought about them when I initially designed Babel, and decided they're not worth the complexity. Unfortunately I was wrong. > I'm not sure this will work, especially if a speaker sends unicast and > multicast at similar frequencies. > I thought pretty hard about that problem, and I don’t think I see why it > shouldn’t work. Please elaborate. If the sender alternates unicast/multicast, then every single packet will be discontinuous, in effect making seqnos useless. This is similar to a proposal I had, which consisted in removing the seqno from Hellos altogether. I'm also worried about what happens if the D=1 indication is lost. > Having two seqno counters is simpler, and allows speakers to know the drop > rate on both unicast and multicast. For the sender, no changes are needed -- it remains perfectly legal to never send a unicast Hello. If a peer wants to send Unicast Hellos, it must maintain, in addition to the global Seqno, a per-peer Seqno. The receiver, on the other hand, must maintain some form of unicast Hello history, in addition to the current multicast history. What I'm planning to do in the reference implementation is the following: - for wired links, 2/3 link sensing for both multicast and unicast, an association is up if either is good; - for wifi links, ETX for multicast and 2/3 for unicast, if ETX yields infinity but 2/3 is good, assume an abysmally bad but usable link. I don't think the extra complexity is prohibitive. > I'm also not sure your proposal is a smaller change to the protocol. It is a smaller change since it requires no new data structures. However, I don't think the extra complexity of having an extra history is prohibitive. -- Juliusz From nobody Thu Apr 6 18:26:08 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 934E2129687 for ; Thu, 6 Apr 2017 18:26:06 -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 bnKUCRYu33Cp for ; Thu, 6 Apr 2017 18:26:05 -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 DC084129551 for ; Thu, 6 Apr 2017 18:26:04 -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 v371Q2Pr014954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Apr 2017 03:26:03 +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 v371Q2Y3003343; Fri, 7 Apr 2017 03:26: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 5A999D78B7; Fri, 7 Apr 2017 03:26: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 3WsqhWRX3EZx; Fri, 7 Apr 2017 03:26:01 +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 41DD8D78F6; Fri, 7 Apr 2017 03:25:53 +0200 (CEST) Date: Fri, 07 Apr 2017 03:25:54 +0200 Message-ID: <87shllrot9.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: babel@ietf.org In-Reply-To: References: <87a87xooxm.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]); Fri, 07 Apr 2017 03:26:03 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 07 Apr 2017 03:26:02 +0200 (CEST) X-Miltered: at korolev with ID 58E6EAAA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58E6EAAA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58E6EAAA.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58E6EAAA.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 : 58E6EAAA.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58E6EAAA.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] Unicast 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: Fri, 07 Apr 2017 01:26:07 -0000 > This is my preference of the listed options. Flag based correct behavior > feels bit dangerous. Can you clarify please? > I am not sure I am entirely happy with any of the listed options > though. I have considered slightly different scheme treating unicast and > multicast as separate logical links for hello purposes (=> disjoint > sequence number spaces) but that leads to issues in mixed environments > with both legacy implementations and ones supporting unicast hello > spec. I think the plan is to have disjoint seqno spaces. What else do you envision? > If writing v2 version of protocol without backwards compatibility > requirements, I would probably lean that way (on the wire, hellos would > look same, but sequence # spaces would work bit differently based on > uni<>multicast). Could you please clarify? By using a different TLV, a unicast-unaware node will simply fail to route through a unicast-only node. If using a flag, a unicast unaware node will have completely crazy link cost, which means that it will not route through a unicast-sending cost. Since sending unicast remains optional, I don't think either compatibility issue is prohibitive -- our implementations just refrain from sending unicasts by default for a couple of years. -- Juliusz From nobody Thu Apr 6 22:51: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 728F312702E for ; Thu, 6 Apr 2017 22:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 xep7i7EMwocA for ; Thu, 6 Apr 2017 22:51:51 -0700 (PDT) Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.203]) by ietfa.amsl.com (Postfix) with ESMTP id ECBCF124D37 for ; Thu, 6 Apr 2017 22:51:50 -0700 (PDT) Received: from poro.lan (80.220.131.63) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 58A591F801171D62; Fri, 7 Apr 2017 08:51:48 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Markus Stenberg In-Reply-To: <87shllrot9.wl-jch@irif.fr> Date: Fri, 7 Apr 2017 08:51:47 +0300 Cc: babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1C9736D3-1204-402B-BCF4-50B321624BA0@iki.fi> References: <87a87xooxm.wl-jch@irif.fr> <87shllrot9.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [babel] Unicast 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: Fri, 07 Apr 2017 05:51:53 -0000 On 7 Apr 2017, at 4.25, Juliusz Chroboczek wrote: >> This is my preference of the listed options. Flag based correct = behavior >> feels bit dangerous. > Can you clarify please? Well, given default in RFC6126 is ignore, backwards compatibility with = that means that the flag is ignored by those nodes. What are we exactly = getting out of sending the flag only to the =E2=80=99new, enlightened=E2=80= =99 peers? Anything not already embedded in the IP header? >> I am not sure I am entirely happy with any of the listed options >> though. I have considered slightly different scheme treating unicast = and >> multicast as separate logical links for hello purposes (=3D> disjoint >> sequence number spaces) but that leads to issues in mixed = environments >> with both legacy implementations and ones supporting unicast hello >> spec. > I think the plan is to have disjoint seqno spaces. What else do you > envision? If we can enable the functionality only with new peers present, there is = no value in the flag itself as currently the unicast+hello is not = currently specified and if we assume all new implementations, they can = just note it=E2=80=99s unicast and move on with that.=20 -> having bit OR TLV is redundant _if_ you are willing to live with the = anomalies you note. The bit leads to same anomalies (legacy receiver not understanding the = bit will misbehave). TLV does not. >> If writing v2 version of protocol without backwards compatibility >> requirements, I would probably lean that way (on the wire, hellos = would >> look same, but sequence # spaces would work bit differently based on >> uni<>multicast). >=20 > Could you please clarify? >=20 > By using a different TLV, a unicast-unaware node will simply fail to = route > through a unicast-only node. >=20 > If using a flag, a unicast unaware node will have completely crazy = link > cost, which means that it will not route through a unicast-sending = cost. >=20 > Since sending unicast remains optional, I don't think either = compatibility > issue is prohibitive -- our implementations just refrain from sending > unicasts by default for a couple of years. For disjoint seqno spaces, I see 3 options: - TLV on the wire - reserved bit on the wire - detect by dst (no encoding change in payload) In terms of =E2=80=98legacy=E2=80=99 compatibility, bit-in-reserved and = detect-by-dst are equivalent. I am not fond of the anomalies involved = with it, but I assume you are willing to live with it if your current = favourite option is the reserved bit one. =E2=80=98jurassic socket = APIs=E2=80=99 is valid concern but I think anything modern has to have = way of getting datagram destination address, as e.g. DTLS does not work = without it. Cheers, -Markus= From nobody Fri Apr 7 07:59:15 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 458FE1294CD for ; Fri, 7 Apr 2017 07:59: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 ReEKBHb1rbPy for ; Fri, 7 Apr 2017 07:59:11 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD0051287A0 for ; Fri, 7 Apr 2017 07:59: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 v37Ex8eR029748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 7 Apr 2017 16:59: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 v37Ex8YB026338 for ; Fri, 7 Apr 2017 16:59: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 78852D78B7 for ; Fri, 7 Apr 2017 16:59: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 jv7WYsGg6om0 for ; Fri, 7 Apr 2017 16:59:07 +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 67864D78F6 for ; Fri, 7 Apr 2017 16:59:06 +0200 (CEST) Date: Fri, 07 Apr 2017 16:59:07 +0200 Message-ID: <87y3vcuuv8.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]); Fri, 07 Apr 2017 16:59:08 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 07 Apr 2017 16:59:08 +0200 (CEST) X-Miltered: at korolev with ID 58E7A93C.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58E7A93C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58E7A93C.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58E7A93C.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 : 58E7A93C.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58E7A93C.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] Unicast Hellos -- conclusions so far 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, 07 Apr 2017 14:59:14 -0000 Thanks to all for the discussion. Here's my current thinking: 1. There are two kinds of Hellos, explicitly distinguished. They are called Hello and Unicast Hello. Hello MUST be sent over multicast or multi-unicast, Unicast Hello MUST be sent over unicast. On the sending side, there's a per-interface seqno for Hello, and a per-peer seqno for Unicast Hello. It is legal to never send Unicast Hellos, in which case the per-peer seqno is not needed. 2. The on-the-wire encoding remains to be determined. Markus and myself are in favour of a separate TLV, David prefers a flag in Hello, Toke and Margaret havn't expressed an opinion (these are the people who are known to have an implementation). I'll treat this point in a separate mail. 3. The interval field carries a promise to send a Hello of the same type within the given interval. (The alternative, a Hello of any kind within the interval, is not useful -- it doesn't allow to do link estimation reliably.) 4. Unicast Hellos are allowed to set Interval to 0, meaning that this is an unscheduled Hello (used e.g. for carrying a timestamp sub-TLV, not necessarily for link maintenance) and we don't promise to send another one. I haven't decided whether allow Interval 0 in ordinary (multicast) Hellos. 5. Informational algorithms for Appendix A2: for wired links: - perform 2/3 for multicast hellos; - perform 2/3 for unicast hellos; - assume link is up if either instance of 2/3 says it's up. for wireless links: - perform ETX for multicast hellos; - perform 2/3 for unicast hellos; - if multicast ETX is finite, use that; - otherwise, if unicast 2/3 says the link is up, assume the link is up but with a horribly high cost. We'll want to have at least two independent interoperable implementations in time for Prague. Do we have consensus? -- Juliusz From nobody Fri Apr 7 08:14:51 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 882C5127BA3 for ; Fri, 7 Apr 2017 08:14:48 -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 TH_OPQD1lj1o for ; Fri, 7 Apr 2017 08:14:46 -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 80CDD127F0E for ; Fri, 7 Apr 2017 08:14:42 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v37FEegS005259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 7 Apr 2017 17:14:40 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id v37FEevT032428 for ; Fri, 7 Apr 2017 17:14: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 D4A9CD78F6 for ; Fri, 7 Apr 2017 17:14: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 Ez8RUVUBMVbq for ; Fri, 7 Apr 2017 17:14:39 +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 E9D00D78B7 for ; Fri, 7 Apr 2017 17:14:39 +0200 (CEST) Date: Fri, 07 Apr 2017 17:14:41 +0200 Message-ID: <87wpawuu5a.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]); Fri, 07 Apr 2017 17:14:40 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 07 Apr 2017 17:14:40 +0200 (CEST) X-Miltered: at korolev with ID 58E7ACE0.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58E7ACE0.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58E7ACE0.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58E7ACE0.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 : 58E7ACE0.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58E7ACE0.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] Unicast Hellos: on-the-wire encoding 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, 07 Apr 2017 15:14:48 -0000 I see three reasonable options for the on-the-wire encoding of Unicast Hellos: 1. Use a new TLV type Pros: - Unicast Hellos are silently ignored by existing implementations. Cons: - the TLV range becomes discontiguous, and we'll need to explain that to our grandchildren; - every extension needs to specify whether a given sub-TLV is allowed for Hello, for Unicast Hello, or for both. 2. Use the Hello type, with a bit in the Reserved field to specify unicast. Pros: - the TLV range remains congiguous; - every sub-TLV is allowed for both kinds of Hello unless specified otherwise; - David likes it. Cons: - existing implementations get confused by Unicast Hellos, links drop on each M->U or U->M transition; - Markus doesn't like it. 3. Don't distinguish in-band, use the destination address Pros: - no changes to the packet format; - Markus likes it. Cons: - this is the only place where a Babel implementation requires the destination address; - it is impossible to send a (multicast) Hello over multi-unicast; - Babel might be deployed in places where the destination address is not available; - Juliusz hates it. I'm okay with either (1) or (2), with a mild preference for (1). If there's no new argument, I think I'm going to go with a new TLV. -- Juliusz From nobody Fri Apr 7 09:10: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 9265C126DED for ; Fri, 7 Apr 2017 09:10:03 -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, RCVD_IN_DNSWL_MED=-2.3, 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=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 wRRLVpvPIYha for ; Fri, 7 Apr 2017 09:10:01 -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 09782124282 for ; Fri, 7 Apr 2017 09:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491581400; 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=beOwsQMTwNZmgV7uG6xoXXZFB/XcHa4kqssKHfvzfz0=; b=wJWGW3GwPURaOwK/ab7zgJmSZTIe5V7K/TTpmn1f1lg5f3trH4Zy7VPJQZmPYiAh 1tEyjTBL9n6XD/8yhB4TGIK8sL6fsqOwZAd0sWPIjjK7yDxxbYnzGpLTz7sOB3Gt l6Fo7wD8PJa2dWsEFZEODekIl/4ro2ITyEgS1nLGorCVMoxfIjO64uionE6boLhX TqE3kjMjRIUirRjERe5Mil+T05bjLrZHb9EghRH5VV7gb7GP7RPsWH9Sf4FKxgtN y/v2MYqeK1Z/c9dV7j5GHze5ur5+9WUbRCLXQnTNG3reQbhmvOONhls40fq2hjH1 AFl2b+BukO+LIVzR6Olhpg==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id CB.10.18333.8D9B7E85; Fri, 7 Apr 2017 09:10:00 -0700 (PDT) X-AuditID: 11973e16-bbf9d9a00000479d-9e-58e7b9d829b4 Received: from jimbu (jimbu.apple.com [17.151.62.37]) by relay2.apple.com (Apple SCV relay) with SMTP id 6B.2A.06512.7D9B7E85; Fri, 7 Apr 2017 09:10:00 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_JetKUOeTpOAn0/cTJV5a0g)" Received: from [17.153.36.212] (unknown [17.153.36.212]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OO1007W1RKIXZ10@jimbu.apple.com>; Fri, 07 Apr 2017 09:09:59 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <42839652-ED6A-4002-8397-FD6BE2D38499@apple.com> Date: Fri, 07 Apr 2017 09:09:54 -0700 In-reply-to: <1C9736D3-1204-402B-BCF4-50B321624BA0@iki.fi> Cc: Juliusz Chroboczek , babel@ietf.org To: Markus Stenberg References: <87a87xooxm.wl-jch@irif.fr> <87shllrot9.wl-jch@irif.fr> <1C9736D3-1204-402B-BCF4-50B321624BA0@iki.fi> X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUi2FDorHtj5/MIgy2LjS22LOpmsZjfuozN Yu/cFSwOzB5Llvxk8jj8dSGLx+ItbxkDmKO4bFJSczLLUov07RK4Mpbu6GIvWHOEsWLDxQNs DYxvVjF2MXJySAiYSGz9uJu5i5GLQ0hgL6PE1Sdn4RJ7901gg0gsY5TY/vQEM0iCV0BQ4sfk eywgNrNAmMT7XbuYIIr+M0pcftbJBJIQFpCW6Lpwl7WLkYODTUBL4sAaIxCTV8BG4udebogK ZYl5b5+wgtgsAqoSk1qawfZyClhJXF8yjQ1ivInE0r9HwWwRAR2JC58OskKsWswo0fz9DTvE obISn57/hLKvs0n0rHGfwCg0C8mps5CcOgvoDGYBdYkpU3IhwtoST95dYIWw1SQW/l7EhCy+ gJFtFaNQbmJmjm5mnrleYkFBTqpecn7uJkZQhEy3E9vB+HCV1SFGAQ5GJR7eH13PI4RYE8uK K3MPMUpzsCiJ8+ovAQoJpCeWpGanphakFsUXleakFh9iZOLglGpgdBROtY1kdX/mkPCed2a4 wJ/DfrF/TD7EfvV8d49F4rXAi1Jnt41tf5gq72lles9zsv41cTbLR493gY1derx/F6dH/X/P s/3Y9Z8WN48ufHP1/FvXgoMaM2xVuWt07y0JLbu7b4GzRHXkDJtf7mdcUj/dP+55aKGB+I7j JxgaVspp/XkQbqHRqsRSnJFoqMVcVJwIAKxB/hFxAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUiON1OVffGzucRBhtbVS22LOpmsZjfuozN Yu/cFSwOzB5Llvxk8jj8dSGLx+ItbxkDmKO4bFJSczLLUov07RK4Mpbu6GIvWHOEsWLDxQNs DYxvVjF2MXJySAiYSOzdN4Gti5GLQ0hgGaPE9qcnmEESvAKCEj8m32MBsZkFwiTe79rFBFH0 n1Hi8rNOJpCEsIC0RNeFu6xdjBwcbAJaEgfWGIGYvAI2Ej/3ckNUKEvMe/uEFcRmEVCVmNTS DLaXU8BK4vqSaWwQ400klv49CmaLCOhIXPh0kBVi1WJGiebvb9ghDpWV+PT8J/sERv5ZSM6b heS8WUCrmQXUJaZMyYUIa0s8eXeBFcJWk1j4exETsvgCRrZVjAJFqTmJlUZ6iQUFOal6yfm5 mxhBId1Q6LyD8dgyq0OMAhyMSjy8Ab3PI4RYE8uKK3MPMUpwMCuJ8B7YARTiTUmsrEotyo8v Ks1JLT7EOJER6MuJzFKiyfnAiMsriTc0MTEwMTY2MzY2NzGnpbCSOO+1xUAXCaQnlqRmp6YW pBbBHMXEwSnVwJjmd0p6/sqFoayidhnikxhip31RXMJ1nsfsxNqzrzKSbf9MsfUP7vNJecjl We73w4PhxfxJdgeXMnT7Wm9ZfCiF+c7/rSs0w3/cfXYqS3/6r0vL/q/OE0zo2y2t2VKiP1VJ ZIXG/pDonxwtE3YkKrns3+K4b6vno2ktJ07lH121JXFznY+BkI8SS3FGoqEWc1FxIgCkJRGp 3AIAAA== Archived-At: Subject: Re: [babel] Unicast 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: Fri, 07 Apr 2017 16:10:04 -0000 --Boundary_(ID_JetKUOeTpOAn0/cTJV5a0g) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable I agree that reserved bit is equivalent to checking dst address. My implementation checks the address so it can live with both, but I don't mind burning one bit of the 16 we have if it makes some other implementer's life easier. David > On Apr 6, 2017, at 22:51, Markus Stenberg = wrote: >=20 > On 7 Apr 2017, at 4.25, Juliusz Chroboczek > wrote: >>> This is my preference of the listed options. Flag based correct = behavior >>> feels bit dangerous. >> Can you clarify please? >=20 > Well, given default in RFC6126 is ignore, backwards compatibility with = that means that the flag is ignored by those nodes. What are we exactly = getting out of sending the flag only to the =E2=80=99new, enlightened=E2=80= =99 peers? Anything not already embedded in the IP header? >=20 >>> I am not sure I am entirely happy with any of the listed options >>> though. I have considered slightly different scheme treating unicast = and >>> multicast as separate logical links for hello purposes (=3D> = disjoint >>> sequence number spaces) but that leads to issues in mixed = environments >>> with both legacy implementations and ones supporting unicast hello >>> spec. >> I think the plan is to have disjoint seqno spaces. What else do you >> envision? >=20 > If we can enable the functionality only with new peers present, there = is no value in the flag itself as currently the unicast+hello is not = currently specified and if we assume all new implementations, they can = just note it=E2=80=99s unicast and move on with that.=20 >=20 > -> having bit OR TLV is redundant _if_ you are willing to live with = the anomalies you note. >=20 > The bit leads to same anomalies (legacy receiver not understanding the = bit will misbehave). TLV does not. >=20 >>> If writing v2 version of protocol without backwards compatibility >>> requirements, I would probably lean that way (on the wire, hellos = would >>> look same, but sequence # spaces would work bit differently based on >>> uni<>multicast). >>=20 >> Could you please clarify? >>=20 >> By using a different TLV, a unicast-unaware node will simply fail to = route >> through a unicast-only node. >>=20 >> If using a flag, a unicast unaware node will have completely crazy = link >> cost, which means that it will not route through a unicast-sending = cost. >>=20 >> Since sending unicast remains optional, I don't think either = compatibility >> issue is prohibitive -- our implementations just refrain from sending >> unicasts by default for a couple of years. >=20 > For disjoint seqno spaces, I see 3 options: >=20 > - TLV on the wire > - reserved bit on the wire > - detect by dst (no encoding change in payload) >=20 > In terms of =E2=80=98legacy=E2=80=99 compatibility, bit-in-reserved = and detect-by-dst are equivalent. I am not fond of the anomalies = involved with it, but I assume you are willing to live with it if your = current favourite option is the reserved bit one. =E2=80=98jurassic = socket APIs=E2=80=99 is valid concern but I think anything modern has to = have way of getting datagram destination address, as e.g. DTLS does not = work without it. >=20 > Cheers, >=20 > -Markus > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel = --Boundary_(ID_JetKUOeTpOAn0/cTJV5a0g) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable I agree that reserved bit is equivalent to checking dst = address.
My implementation checks the address so it can = live with both,
but I don't mind burning one bit of = the 16 we have if it makes
some other implementer's = life easier.

David


On Apr 6, 2017, at 22:51, Markus Stenberg <markus.stenberg@iki.fi> wrote:

On 7 Apr 2017, at 4.25, Juliusz Chroboczek = <jch@irif.fr> wrote:
This is my preference of the listed options. Flag based = correct behavior
feels bit dangerous.
Can you clarify please?

Well, given default in RFC6126 is ignore, = backwards compatibility with that means that the flag is ignored by = those nodes. What are we exactly getting out of sending the flag only to = the =E2=80=99new, enlightened=E2=80=99 peers? Anything not already = embedded in the IP header?

I am not sure I am entirely happy with any of the listed = options
though. I have considered slightly different = scheme treating unicast and
multicast as separate logical = links for hello purposes (=3D> disjoint
sequence number = spaces) but that leads to issues in mixed environments
with = both legacy implementations and ones supporting unicast hello
spec.
I think the plan is to have = disjoint seqno spaces.  What else do you
envision?

If we can enable the functionality only with new = peers present, there is no value in the flag itself as currently the = unicast+hello is not currently specified and if we assume all new = implementations, they can just note it=E2=80=99s unicast and move on = with that. 

-> having bit OR TLV is redundant _if_ = you are willing to live with the anomalies you note.

The bit leads to same anomalies (legacy = receiver not understanding the bit will misbehave). TLV does = not.

If writing v2 version of = protocol without backwards compatibility
requirements, I = would probably lean that way (on the wire, hellos would
look= same, but sequence # spaces would work bit differently based on
uni<>multicast).

Could you please clarify?

By = using a different TLV, a unicast-unaware node will simply fail to = route
through a unicast-only node.

If using a flag, a unicast unaware node will have completely = crazy link
cost, which means that it will not route = through a unicast-sending cost.

Since = sending unicast remains optional, I don't think either compatibility
issue is prohibitive -- our implementations just refrain from = sending
unicasts by default for a couple of years.

For disjoint seqno spaces, I see 3 = options:

- TLV on the = wire
- reserved bit on the wire
- detect by dst (no = encoding change in payload)

In terms of =E2=80=98legacy=E2=80=99 = compatibility, bit-in-reserved and detect-by-dst are equivalent. I am = not fond of the anomalies involved with it, but I assume you are willing = to live with it if your current favourite option is the reserved bit = one.  =E2=80=98jurassic socket APIs=E2=80=99 is valid concern but I = think anything modern has to have way of getting datagram destination = address, as e.g. DTLS does not work without it.

Cheers,

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

= --Boundary_(ID_JetKUOeTpOAn0/cTJV5a0g)-- From nobody Fri Apr 7 09:17:40 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 E7D7812949A for ; Fri, 7 Apr 2017 09:17:39 -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, RCVD_IN_DNSWL_MED=-2.3, 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=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 GXdDRpYXi0rC for ; Fri, 7 Apr 2017 09:17:38 -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 8A9E71294B8 for ; Fri, 7 Apr 2017 09:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491581851; 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=wLHLoTaIio2ywCJcHc72Qp505gFGlqrFskTi58IUJoU=; b=g+PS7HRETNuvUlYHYu28M8DBMHJ/ZdRXsg4i6rxKp+b9zgaT5REDaFzId9/wpFiq F0t99AQjZgyQ+NuN/PkR6dRB+2DozKD+AzAVb3gl+8s41ztP+BJqrxWXoIHvh4Kf u7j/pM+UixplSkZtfk6yp/ORa8nXRlF7ZZ1S6wnxbFMi5nPKMrsfEh0f9F8uih7s kXFVxthNLEhDXFjKZeStEQ6zdXjIb0Xkt7AY4JHWWPulVARdddZMLkKubTxlB4Xy RzE0WZzdgxSz7nFV9VDQBRdVxGuZJxGJkkNDB/3iji2XmIAR6vwcruzb4eCmAAsj t8d8dSfHgpH+NiFFbzPffQ==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id E8.F0.18333.99BB7E85; Fri, 7 Apr 2017 09:17:31 -0700 (PDT) X-AuditID: 11973e16-683ff7000000479d-93-58e7bb998f58 Received: from kencur (kencur.apple.com [17.151.62.38]) by relay4.apple.com (Apple SCV relay) with SMTP id 1A.66.03007.99BB7E85; Fri, 7 Apr 2017 09:17:29 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.36.212] (unknown [17.153.36.212]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OO1006KPRWV2100@kencur.apple.com>; Fri, 07 Apr 2017 09:17:29 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87y3vcuuv8.wl-jch@irif.fr> Date: Fri, 07 Apr 2017 09:17:18 -0700 Cc: babel@ietf.org Message-id: <2D6CD8C2-8A95-4C26-A282-2C32F81487DD@apple.com> References: <87y3vcuuv8.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUi2FAYrjt79/MIg5aL0hZbFnWzWMxvXcbm wOSxZMlPJo/FW94yBjBFcdmkpOZklqUW6dslcGW0HlrLWLBGuGLDr4+MDYwT+bsYOTkkBEwk pq05ytjFyMUhJLCXUeLh1BYmmETH0qPsEIkVjBKLGtYygiR4BQQlfky+x9LFyMHBLCAvcfC8 LEiYWUBL4vujVhaI+mYmiembuthAEsIC0hJdF+6yQtiWEqcv3mAF6WUDajiwxggkzCmgIfF9 xTawchYBVYmTd2axQswUkjhzbQYLxFobifa+a+wgtpCAusSthb/BbBEBFYnl056xQ9wsK/Hp +U+wmyUEVrBJ3P29jXUCo/AsJGfPQjh7FpKzFzAyr2IUyk3MzNHNzDPXSywoyEnVS87P3cQI CuzpdmI7GB+usjrEKMDBqMTD+6PreYQQa2JZcWXuIUZpDhYlcV79JUAhgfTEktTs1NSC1KL4 otKc1OJDjEwcnFINjBfnqB0UiUv6yS7qoLthq3ahsc6srbHLLvRWbo2+9KChYaeUoKL3h2cf tZ9dkfkTeo+zMFPpzSQdhZknC56/6jrzw7B8RWqC7tOPnU3376rFGRXsXME34XvIjfvRlzyn p+83nhspa7o7j798kVDpnTM2jCWmP89nzz/J/u+FcHLwugMnmk5fm6jEUpyRaKjFXFScCAAF qdfhTQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42IRnG6npjtz9/MIg76D5hZbFnWzWMxvXcbm wOSxZMlPJo/FW94yBjBFcdmkpOZklqUW6dslcGW0HlrLWLBGuGLDr4+MDYwT+bsYOTkkBEwk OpYeZe9i5OIQEljBKLGoYS0jSIJXQFDix+R7LF2MHBzMAvISB8/LgoSZBbQkvj9qZYGob2aS mL6piw0kISwgLdF14S4rhG0pcfriDVaQXjaghgNrjEDCnAIaEt9XbAMrZxFQlTh5ZxYrxEwh iTPXZrBArLWRaO+7xg5iCwmoS9xa+BvMFhFQkVg+7Rk7xM2yEp+e/2SfwCgwC8mlsxAunYXk 0gWMzKsYBYpScxIrTfQSCwpyUvWS83M3MYICsaEwfAfjv2VWhxgFOBiVeHh/dD2PEGJNLCuu zD3EKMHBrCTCe2AHUIg3JbGyKrUoP76oNCe1+BBjFdD9E5mlRJPzgVGSVxJvaGJiYGJsbGZs bG5iThVhJXHea4uBNgukJ5akZqemFqQWwSxn4uCUamC0a1u6RYZJqvZwmWJXm9Ym4dM6C5lf 3lSYzfRuZXTAzJjiY1EPN3S+C6h+VGrNp55k8OtF3ya9bb7xm8z7antOdXdGNVyR/7tj4uIw iSXVKZahsaeyDFY3LGRwN/nndnOb/vdbO/1zvTyX3f714eSEN4Xn5ui1su21X7vsctLCzI8s 7NXJehxKLMUZiYZazEXFiQDQBKZJnwIAAA== Archived-At: Subject: Re: [babel] Unicast Hellos -- conclusions so far 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, 07 Apr 2017 16:17:40 -0000 I agree with this plan. Regarding allowing Interval = 0, I think the rationale to allow or disallow them applies equally to unicast and multicast, so it should be allowed or disallowed equally for both types of Hellos. Or tell me if I'm missing something. David > On Apr 7, 2017, at 07:59, Juliusz Chroboczek wrote: > > Thanks to all for the discussion. Here's my current thinking: > > 1. There are two kinds of Hellos, explicitly distinguished. They are > called Hello and Unicast Hello. Hello MUST be sent over multicast or > multi-unicast, Unicast Hello MUST be sent over unicast. On the sending > side, there's a per-interface seqno for Hello, and a per-peer seqno for > Unicast Hello. It is legal to never send Unicast Hellos, in which case > the per-peer seqno is not needed. > > 2. The on-the-wire encoding remains to be determined. Markus and myself > are in favour of a separate TLV, David prefers a flag in Hello, Toke and > Margaret havn't expressed an opinion (these are the people who are known > to have an implementation). I'll treat this point in a separate mail. > > 3. The interval field carries a promise to send a Hello of the same type > within the given interval. (The alternative, a Hello of any kind within > the interval, is not useful -- it doesn't allow to do link estimation > reliably.) > > 4. Unicast Hellos are allowed to set Interval to 0, meaning that this is > an unscheduled Hello (used e.g. for carrying a timestamp sub-TLV, not > necessarily for link maintenance) and we don't promise to send another > one. I haven't decided whether allow Interval 0 in ordinary (multicast) > Hellos. > > 5. Informational algorithms for Appendix A2: > > for wired links: > - perform 2/3 for multicast hellos; > - perform 2/3 for unicast hellos; > - assume link is up if either instance of 2/3 says it's up. > > for wireless links: > - perform ETX for multicast hellos; > - perform 2/3 for unicast hellos; > - if multicast ETX is finite, use that; > - otherwise, if unicast 2/3 says the link is up, assume the link is up > but with a horribly high cost. > > We'll want to have at least two independent interoperable implementations > in time for Prague. Do we have consensus? > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Fri Apr 7 09:22: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 E998F1294E0 for ; Fri, 7 Apr 2017 09:22:31 -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, RCVD_IN_DNSWL_MED=-2.3, 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=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 Npeo8jpMSj4u for ; Fri, 7 Apr 2017 09:22:30 -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 457061294DB for ; Fri, 7 Apr 2017 09:22: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=1491582128; 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=v6pI2Ee8S1nTMUHaCPRa6n0+VmQZpisx/wqZO9wk7FA=; b=hrVGyWxt8fLTHSerxvBKoyiNe36C6pmwwE5JcbZSOlWStNXtdG8F1SyHzxE5xQT1 YYO0dPWbFn18VTaqs8FFKOq9RR9A97dN3jg2cfyw/gfJDOyP0K5Ovs0wEUBuOMNa b7i3DXy10O5AfE+gDmm9EUQmZA3K+Ho1TI6xYEX16iWsW4HKYhHiQlU4IMwcuMTa uU1rei92dpFIhKKK/Xd2zfwj1zuiGBSIR3ezh/W523FPJ8uxH2fEy6izFyCHbB/K TDFPD1IhoWByywYJFZHXoXhkBeEtGvL08IhxlACy9eC1SueCQyrUNYU5ik27TKQN CiAeFGlUM7UFRvedpMuceA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 4B.58.29635.0BCB7E85; Fri, 7 Apr 2017 09:22:08 -0700 (PDT) X-AuditID: 11973e15-e17fb700000073c3-2e-58e7bcb0eba4 Received: from jimbu (jimbu.apple.com [17.151.62.37]) by relay6.apple.com (Apple SCV relay) with SMTP id 33.41.31597.FACB7E85; Fri, 7 Apr 2017 09:22:07 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.36.212] (unknown [17.153.36.212]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OO10074BS4SXZ20@jimbu.apple.com>; Fri, 07 Apr 2017 09:22:07 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87wpawuu5a.wl-jch@irif.fr> Date: Fri, 07 Apr 2017 09:22:03 -0700 Cc: babel@ietf.org Message-id: <8CF6B77E-3378-40EE-BDC2-812E184DE3B2@apple.com> References: <87wpawuu5a.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUi2FAYpbthz/MIg9W7OS22LOpmsZjfuozN gcljyZKfTB6Lt7xlDGCK4rJJSc3JLEst0rdL4MpY9/IRc8EJ/opnU/4wNzD+5O5i5OSQEDCR +PbjE3MXIxeHkMBeRokHc2azwiS+33rEApFYxijx9tgNZpAEr4CgxI/J94ASHBzMAvISB8/L goSZBbQkvj9qhar/zyhx834/2CBhAWmJrgt3oWxLiZ5t85hBetmAGg6sMQIJcwpoSJy6cQQs zCKgKnF4siPESCGJM9dmsEBstZE4PuML2AVCAuoSXU1z2UBsEQEVieXTnrFDnCwr8en5T3aQ EyQEFrBJ3DlxinkCo/AsJFfPQrh6FpKrFzAyr2IUyk3MzNHNzDPTSywoyEnVS87P3cQICuvp dqI7GM+ssjrEKMDBqMTDG9D7PEKINbGsuDL3EKM0B4uSOK/6EqCQQHpiSWp2ampBalF8UWlO avEhRiYOTqkGxsNSWxccvmixz9b+0PNLElZHA57ZiivdfLMy8unPX9YN5zhP7MyZuOZjkV5s MdPsC0c38H5wybpwu//ZgpD3WntMwhy6nriYTzleb7fuweeIqjOStedy7KK5Sg6o1/Od/Dz9 3iUFsyNWUz6k3pnXfcX818b1XUe9rz4tOnDvak/ojwmsK1a6V5krsRRnJBpqMRcVJwIAx1Nm RkwCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42IRnG6nqrthz/MIgzUeFlsWdbNYzG9dxubA 5LFkyU8mj8Vb3jIGMEVx2aSk5mSWpRbp2yVwZax7+Yi54AR/xbMpf5gbGH9ydzFyckgImEh8 v/WIpYuRi0NIYBmjxNtjN5hBErwCghI/Jt8DSnBwMAvISxw8LwsSZhbQkvj+qBWq/j+jxM37 /awgCWEBaYmuC3ehbEuJnm3zmEF62YAaDqwxAglzCmhInLpxBCzMIqAqcXiyI8RIIYkz12aw QGy1kTg+4wvYBUIC6hJdTXPZQGwRARWJ5dOesUOcLCvx6flP9gmMArOQHDoL4dBZSA5dwMi8 ilGgKDUnsdJML7GgICdVLzk/dxMjKAgbCqN2MDYstzrEKMDBqMTD+6PreYQQa2JZcWXuIUYJ DmYlEd4DO4BCvCmJlVWpRfnxRaU5qcWHGKuAzp/ILCWanA+MkLySeEMTEwMTY2MzY2NzE3Oq CCuJ815fDLRZID2xJDU7NbUgtQhmORMHp1QDY5Xvt3ut9ReeT3d9/U8q5Ezxx3MPlj7L4Hp0 5/+8k7Lv+ORdjLNd3K+JuPpefOnz/eHiVpc9ia6iF/66WcXPEVKdlbo+as4qS61oO7G7vd3M 70stvjULBGvf2LqwxnpG9zvubV9+nn1zyPBMoUxUv1CVz8+P7xcoeVt5x02XYuBpif/d7iuT osRSnJFoqMVcVJwIAKi+cGWdAgAA Archived-At: Subject: Re: [babel] Unicast Hellos: on-the-wire encoding 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, 07 Apr 2017 16:22:32 -0000 I think the argument between (1) and (2) is a tradeoff between backwards compatibility and sanity of the protocol long-term. I have a strong preference for (2), because I think it's early enough in the lifetime of this standard that we should be able to make the tough calls to improve things long term. David > On Apr 7, 2017, at 08:14, Juliusz Chroboczek wrote: > > I see three reasonable options for the on-the-wire encoding of Unicast Hellos: > > > 1. Use a new TLV type > > Pros: > - Unicast Hellos are silently ignored by existing implementations. > > Cons: > - the TLV range becomes discontiguous, and we'll need to explain that to > our grandchildren; > - every extension needs to specify whether a given sub-TLV is allowed > for Hello, for Unicast Hello, or for both. > > > 2. Use the Hello type, with a bit in the Reserved field to specify > unicast. > > Pros: > - the TLV range remains congiguous; > - every sub-TLV is allowed for both kinds of Hello unless specified otherwise; > - David likes it. > > Cons: > - existing implementations get confused by Unicast Hellos, links drop on > each M->U or U->M transition; > - Markus doesn't like it. > > > 3. Don't distinguish in-band, use the destination address > > Pros: > - no changes to the packet format; > - Markus likes it. > > Cons: > - this is the only place where a Babel implementation requires the > destination address; > - it is impossible to send a (multicast) Hello over multi-unicast; > - Babel might be deployed in places where the destination address is not > available; > - Juliusz hates it. > > > I'm okay with either (1) or (2), with a mild preference for (1). If > there's no new argument, I think I'm going to go with a new TLV. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Fri Apr 7 14: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 9DF18127097 for ; Fri, 7 Apr 2017 14:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bc31M739U4DX for ; Fri, 7 Apr 2017 14:54:26 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 8ED46128B92 for ; Fri, 7 Apr 2017 14:54:22 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id g2so76489013pge.3 for ; Fri, 07 Apr 2017 14:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=r9n6nsI/V8QMAodaz2dTmE1Hi+lxMtjHEqitoz86T4A=; b=NoKIAHm2EpdRl0sAHr4VrZzeOCK6OMgGrVPyDu99aaQM9VssJX3moU1yEm6FvkNYiD DwwxPtawvJirUnKPpjdX7nYx8DZtCGgEN1YjgnMHeM/61VyHL17U0aM3maCAaBrDicPt TQK8ov/J+xKtAQE7fvXVPBWACHn2Zq7SHebl+jryo+MyS8SMt07acW6QihQykqMIG7lE KcaIu+qEGNbI8vKUHyF+fef0FC6wRvazy8X5aVaQS7+VR5p5GrnAn0RN2c2+cWxtSIiT DzrhbMQSO/C0Kd97o7XZvChW0zu6WHQlbN/coDk4P5fj03glsBHx1rHNTXRP7OKIJcmC lqGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=r9n6nsI/V8QMAodaz2dTmE1Hi+lxMtjHEqitoz86T4A=; b=XqHZIHA9cSzyJvnXCM/VfVtWC8Q9fTRAv8SRQdaSnKNxJ7qXY8c1Fn16o8r99NUjyC pIxPrbaw3J8Pc0HrnFAwtUtUqqUvREp+cWz8fvm6VpE1/d6Bfl89/360jPrGkg6YX/H7 PemDWLb5OtEZaZwKStX+2ZVAKgMlRVKO6barp5M1ySYSgpvRlc0avNip1vgW1EiBU9K8 MXFNMkwhYvQJMwrKtMQyjWrzYdyv3BLnKZ4nXqGSN0GFBfHS5FyVCjdIbRAgdeccaCTs yH1gvfBvxiFPBd1TCKSQX1QbGRWBEaDhYTxkubh5IEqCrREB9EtxxlLh01dmwk3I9n9M z0ZQ== X-Gm-Message-State: AFeK/H19m0LThfl8p/bNWcjNWUeVv+OZ68gTGmQ9Hx3nXijknmNORu+9woK0+FvsisVltmE7 X-Received: by 10.99.101.132 with SMTP id z126mr30160815pgb.218.1491602061837; Fri, 07 Apr 2017 14:54:21 -0700 (PDT) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id l1sm11335445pfk.8.2017.04.07.14.54.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 14:54:21 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_11A964F0-CDF9-426E-9FCD-45D3A220F3B3" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 7 Apr 2017 14:54:20 -0700 References: <87a87xooxm.wl-jch@irif.fr> <87tw61rp1l.wl-jch@irif.fr> To: Babel at IETF In-Reply-To: <87tw61rp1l.wl-jch@irif.fr> Message-Id: <97B6D014-96B8-45F7-AE78-162D2248CBF1@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [babel] [Babel-users] Unicast 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: Fri, 07 Apr 2017 21:54:34 -0000 --Apple-Mail=_11A964F0-CDF9-426E-9FCD-45D3A220F3B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 6, 2017, at 18:20, Juliusz Chroboczek wrote: >=20 > Yeah, unicast Hellos are surprisingly tricky -- I thought about them = when > I initially designed Babel, and decided they're not worth the = complexity. > Unfortunately I was wrong. It was good of you to try. >> I'm not sure this will work, especially if a speaker sends unicast = and >> multicast at similar frequencies. >=20 >> I thought pretty hard about that problem, and I don=E2=80=99t think I = see why it >> shouldn=E2=80=99t work. Please elaborate. >=20 > If the sender alternates unicast/multicast, then every single packet = will > be discontinuous, in effect making seqnos useless. Only at Babel speakers that are ignoring the D=3D1 flag, which is = designed to allow retaining the utility of the Hello seqno by marking = the ones that are intentionally discontinuous. > This is similar to > a proposal I had, which consisted in removing the seqno from Hellos > altogether. >=20 > I'm also worried about what happens if the D=3D1 indication is lost. The same thing that happens at legacy Babel speakers that ignore the D=3D1= indication. They see the discontinuity as a signal to recompute the = association cost and recommence the route selection procedure. > [=E2=80=A6] > The receiver, on the other hand, must maintain some form of unicast = Hello > history, in addition to the current multicast history. What I'm = planning > to do in the reference implementation is the following: >=20 > - for wired links, 2/3 link sensing for both multicast and unicast, = an > association is up if either is good; > - for wifi links, ETX for multicast and 2/3 for unicast, if ETX = yields > infinity but 2/3 is good, assume an abysmally bad but usable link. >=20 > I don't think the extra complexity is prohibitive. I don=E2=80=99t either, but in a constrained node [RFC 7228], the extra = unicast history present in every Neighbour Table entry will carry some = cost in additional RAM. Not prohibitive, but significant. >> I'm also not sure your proposal is a smaller change to the = protocol. >=20 > It is a smaller change since it requires no new data structures. = However, > I don't think the extra complexity of having an extra history is = prohibitive. I=E2=80=99m glad I was able to offer an alternative for comparison. = Always good to have multiple options on the table from which to choose. --james woodyatt > --Apple-Mail=_11A964F0-CDF9-426E-9FCD-45D3A220F3B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 6, 2017, at 18:20, Juliusz Chroboczek <jch@irif.fr> wrote:

Yeah, = unicast Hellos are surprisingly tricky -- I thought about them when
I initially designed Babel, and decided they're not worth the = complexity.
Unfortunately I was wrong.

It = was good of you to try.

   I'm not sure this will work, especially if = a speaker sends unicast and
   multicast = at similar frequencies.

I thought pretty hard = about that problem, and I don=E2=80=99t think I see why it
shouldn=E2=80=99t work. Please elaborate.

If the sender alternates = unicast/multicast, then every single packet will
be = discontinuous, in effect making seqnos = useless.

Only at = Babel speakers that are ignoring the D=3D1 flag, which is designed to = allow retaining the utility of the Hello seqno by marking the ones that = are intentionally discontinuous.

This is similar = to
a proposal I had, which consisted in removing the seqno = from Hellos
altogether.

I'm = also worried about what happens if the D=3D1 indication is lost.

The = same thing that happens at legacy Babel speakers that ignore the D=3D1 = indication. They see the discontinuity as a signal to recompute the = association cost and recommence the route selection procedure.

[=E2=80=A6]
The receiver, on the other hand, must maintain some form of = unicast Hello
history, in addition to the current = multicast history.  What I'm planning
to do in the = reference implementation is the following:

=  - for wired links, 2/3 link sensing for both multicast and = unicast, an
   association is up if either = is good;
 - for wifi links, ETX for multicast and = 2/3 for unicast, if ETX yields
   infinity = but 2/3 is good, assume an abysmally bad but usable link.

I don't think the extra complexity is = prohibitive.

I don=E2=80=99t either, but in a constrained node = [RFC 7228], the extra unicast history present in every Neighbour Table = entry will carry some cost in additional RAM. Not prohibitive, but = significant.

=    I'm also not sure your proposal is a smaller change to = the protocol.

It is a smaller = change since it requires no new data structures.  However,
I don't think the extra complexity of having an extra history = is prohibitive.

I=E2=80=99= m glad I was able to offer an alternative for comparison. Always good to = have multiple options on the table from which to choose.

--james woodyatt <jhw@google.com>



= --Apple-Mail=_11A964F0-CDF9-426E-9FCD-45D3A220F3B3-- From nobody Fri Apr 7 15:17: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 2E40312714F for ; Fri, 7 Apr 2017 15:17:19 -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 TLC12v8KMqSm for ; Fri, 7 Apr 2017 15:17: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 CD95112947A for ; Fri, 7 Apr 2017 15:16: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 v37MGqSi015378; Sat, 8 Apr 2017 00:16: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 7E60DD78F6; Sat, 8 Apr 2017 00:16: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 1RrlGlAtYFbk; Sat, 8 Apr 2017 00:16:51 +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 6B83DD78C3; Sat, 8 Apr 2017 00:16:51 +0200 (CEST) Date: Sat, 08 Apr 2017 00:16:52 +0200 Message-ID: <87efx3ualn.wl-jch@irif.fr> From: Juliusz Chroboczek To: james woodyatt Cc: Babel at IETF In-Reply-To: <97B6D014-96B8-45F7-AE78-162D2248CBF1@google.com> References: <87a87xooxm.wl-jch@irif.fr> <87tw61rp1l.wl-jch@irif.fr> <97B6D014-96B8-45F7-AE78-162D2248CBF1@google.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 08 Apr 2017 00:16:52 +0200 (CEST) X-Miltered: at korolev with ID 58E80FD4.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58E80FD4.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 : 58E80FD4.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] Unicast 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: Fri, 07 Apr 2017 22:17:19 -0000 > If the sender alternates unicast/multicast, then every single packet will > be discontinuous, in effect making seqnos useless. > Only at Babel speakers that are ignoring the D=1 flag, which is designed to > allow retaining the utility of the Hello seqno by marking the ones that are > intentionally discontinuous. I'm a little confused. If the sender alternates M/U, then every Hello will carry D=1, right? So the receiver cannot use any of the sequence numbers, right? > I'm also worried about what happens if the D=1 indication is lost. > The same thing that happens at legacy Babel speakers that ignore the D=1 > indication. They see the discontinuity as a signal to recompute the association > cost and recommence the route selection procedure. Right. > I don’t either, but in a constrained node [RFC 7228], the extra unicast history > present in every Neighbour Table entry will carry some cost in additional RAM. That's 2 bytes per neighbour. (James, if you're working on Babel for constrained nodes, and are allowed to tell me about it, then I'd really like to hear about the hardware you're considering -- amount of RAM, kind of CPU, etc.) -- Juliusz From nobody Fri Apr 7 15:20: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 D6F01127B5A for ; Fri, 7 Apr 2017 15:20:02 -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 uMcpZEKoacfU for ; Fri, 7 Apr 2017 15:19:55 -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 03343129439 for ; Fri, 7 Apr 2017 15:19:47 -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 v37MJjZp015832; Sat, 8 Apr 2017 00:19:45 +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 DE3F1D78B7; Sat, 8 Apr 2017 00:19:45 +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 gN4E6VCi29It; Sat, 8 Apr 2017 00:19:33 +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 96D85D79B8; Sat, 8 Apr 2017 00:19:33 +0200 (CEST) Date: Sat, 08 Apr 2017 00:19:34 +0200 Message-ID: <87bms7uah5.wl-jch@irif.fr> From: Juliusz Chroboczek To: james woodyatt Cc: Babel at IETF In-Reply-To: <87efx3ualn.wl-jch@irif.fr> References: <87a87xooxm.wl-jch@irif.fr> <87tw61rp1l.wl-jch@irif.fr> <97B6D014-96B8-45F7-AE78-162D2248CBF1@google.com> <87efx3ualn.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]); Sat, 08 Apr 2017 00:19:45 +0200 (CEST) X-Miltered: at korolev with ID 58E81081.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58E81081.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 : 58E81081.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: Re: [babel] [Babel-users] Unicast 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: Fri, 07 Apr 2017 22:20:03 -0000 >> present in every Neighbour Table entry will carry some cost in additional RAM. > That's 2 bytes per neighbour. Er, 8. (2 byte expected seqno, 16 bit hello history, 4 byte timestamp.) From nobody Sat Apr 8 01:01: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 0DED3126CE8 for ; Sat, 8 Apr 2017 01:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=inf-net-nl.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 Dm2nyQeGINAK for ; Sat, 8 Apr 2017 01:01:19 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 75C09126DD9 for ; Sat, 8 Apr 2017 01:01:18 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id u2so6251402wmu.0 for ; Sat, 08 Apr 2017 01:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inf-net-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jSFPxAh1YIsy5WkMK8Bxd1UjDVuCLGh/dcd41cDH90c=; b=RMoBxydtIIsSImT44fNRY6mcKBNvzZReo4HLosqpmVjGiY8lt7JgByf9YyE66wINEo acVQ4qh5lSL3EPCInKCDJjETdm88MJTFJXDQRoCy7LfLQjOebp+snGw7WK9Z+7C+BJN6 3xVCwTO0vKnM5HOCWfOOdaEtntf6qju0wI2JG+VE+CSO1l2RtxWhmRRNAEGnfxUPjCsV jg/OjFfWdEaqaUsvU5U9fBwDS6H4ifx2Wx9j8XLFq+3Tny4FA/vIEzinGhZ9rESEfwW4 itFK6dbMy7z6yW0+CF0pvKo1T+QQj4Hsw9Mrl5O/UNjAFx51/yv46YqdH5np5dFbky8l pW+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jSFPxAh1YIsy5WkMK8Bxd1UjDVuCLGh/dcd41cDH90c=; b=A4TL/8ycj1u077jNCBd53JYtlOZYu7YAQwwQj6D5p2JkijVpdMOfvOwnP0704+LppU G4cs6WWx17JWj4Kb+ndPBpn1WMxwfKVYtPd460oxEqlD5bJPkcEpxX3LfCVTpovph0jy zDV8xv89ZwNMWWDdfZ0Iw5lXNGW/+E1ZiJqwG59b1mskT2kocoOp3gYt40QZq7zCRdao tpZip8CZGfSeVW763ZtIFtMxrGM+KA0MlvhgpHeqOjSNztpAR0DNyZXOB6a3DkeD9Zof La9J7RPvC7CtR1OzO0QN2PoPgcvQmSpslzLCAQ/FIAVYnM2OXipEF9cJsCiZKPH2nbs4 1ebA== X-Gm-Message-State: AN3rC/70Mc5ywdBm8EU9r5MBrdJVD/2w8r+AigAxMu23kDEVITh6Wh4k8h8YJrgBbQq8kQ== X-Received: by 10.28.111.3 with SMTP id k3mr2427900wmc.39.1491638477106; Sat, 08 Apr 2017 01:01:17 -0700 (PDT) Received: from [192.168.3.43] ([217.171.231.173]) by smtp.gmail.com with ESMTPSA id g78sm8979250wrd.11.2017.04.08.01.01.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 08 Apr 2017 01:01:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Teco Boot In-Reply-To: <87y3vcuuv8.wl-jch@irif.fr> Date: Sat, 8 Apr 2017 10:01:09 +0200 Cc: babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1344FE29-570C-4ECA-83C4-8AC400A347D6@inf-net.nl> References: <87y3vcuuv8.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [babel] Unicast Hellos -- conclusions so far 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, 08 Apr 2017 08:01:22 -0000 > Op 7 apr. 2017, om 16:59 heeft Juliusz Chroboczek het = volgende geschreven: >=20 > Thanks to all for the discussion. Here's my current thinking: >=20 > 1. There are two kinds of Hellos, explicitly distinguished. They are > called Hello and Unicast Hello. Hello MUST be sent over multicast or > multi-unicast, Unicast Hello MUST be sent over unicast. On the = sending > side, there's a per-interface seqno for Hello, and a per-peer seqno = for > Unicast Hello. It is legal to never send Unicast Hellos, in which = case > the per-peer seqno is not needed. >=20 > 2. The on-the-wire encoding remains to be determined. Markus and = myself > are in favour of a separate TLV, David prefers a flag in Hello, Toke = and > Margaret havn't expressed an opinion (these are the people who are = known > to have an implementation). I'll treat this point in a separate mail. >=20 > 3. The interval field carries a promise to send a Hello of the same = type > within the given interval. (The alternative, a Hello of any kind = within > the interval, is not useful -- it doesn't allow to do link estimation > reliably.) >=20 > 4. Unicast Hellos are allowed to set Interval to 0, meaning that this = is > an unscheduled Hello (used e.g. for carrying a timestamp sub-TLV, not > necessarily for link maintenance) and we don't promise to send another > one. I haven't decided whether allow Interval 0 in ordinary = (multicast) > Hellos. >=20 > 5. Informational algorithms for Appendix A2: >=20 > for wired links: > - perform 2/3 for multicast hellos; > - perform 2/3 for unicast hellos; > - assume link is up if either instance of 2/3 says it's up. Appendix A2 is for Cost Computation, right?=20 Link Up depends on IHU. OK, link from Hello sender to Hello receiver is assumed up. Or is this "Link Up" equivalent to "it has recently heard a Hello"=20 in rfc6126bis section-2.1? I couldn't find a precise definition=20 that quickly. What means recently? > for wireless links: > - perform ETX for multicast hellos; > - perform 2/3 for unicast hellos; > - if multicast ETX is finite, use that; > - otherwise, if unicast 2/3 says the link is up, assume the link is = up > but with a horribly high cost. Same comment. Teco > We'll want to have at least two independent interoperable = implementations > in time for Prague. Do we have consensus? >=20 > -- Juliusz >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Sat Apr 8 07:14: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 7526C127010 for ; Sat, 8 Apr 2017 07:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 bE5EjNiiiZkG for ; Sat, 8 Apr 2017 07:14: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 8D7EE1200F1 for ; Sat, 8 Apr 2017 07:14:08 -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 v38EE5v8007178; Sat, 8 Apr 2017 16:14:06 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id E2FDBD79D5; Sat, 8 Apr 2017 16:14:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id b-cyUzkcrDrE; Sat, 8 Apr 2017 16:14:04 +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 0C3CDD79B8; Sat, 8 Apr 2017 16:14:03 +0200 (CEST) Date: Sat, 08 Apr 2017 16:14:05 +0200 Message-ID: <87lgrb0yxe.wl-jch@irif.fr> From: Juliusz Chroboczek To: Teco Boot Cc: babel@ietf.org In-Reply-To: <1344FE29-570C-4ECA-83C4-8AC400A347D6@inf-net.nl> References: <87y3vcuuv8.wl-jch@irif.fr> <1344FE29-570C-4ECA-83C4-8AC400A347D6@inf-net.nl> 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, 08 Apr 2017 16:14:06 +0200 (CEST) X-Miltered: at korolev with ID 58E8F02D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58E8F02D.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 : 58E8F02D.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 -- conclusions so far 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, 08 Apr 2017 14:14:10 -0000 >> - perform 2/3 for multicast hellos; >> - perform 2/3 for unicast hellos; >> - assume link is up if either instance of 2/3 says it's up. > Appendix A2 is for Cost Computation, right? > Link Up depends on IHU. > OK, link from Hello sender to Hello receiver is assumed up. > Or is this "Link Up" equivalent to "it has recently heard a Hello" > in rfc6126bis section-2.1? I couldn't find a precise definition > that quickly. Yes, that's what I meant. > What means recently? In the reference implementation -- within three times the interval advertised by the most recent Hello. -- Juliusz From nobody Sat Apr 8 07:26: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 266AF1273B1 for ; Sat, 8 Apr 2017 07:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.55 X-Spam-Level: X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[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 lLJVrS_bMt5I for ; Sat, 8 Apr 2017 07:26:24 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 4D505127010 for ; Sat, 8 Apr 2017 07:26:24 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id p68so56860278qke.1 for ; Sat, 08 Apr 2017 07:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sFyms30Eq1YhzTehbx6FcnM4kTMB7roIdhOSHa9j8v0=; b=ijfiLnNBRKqT/RwxsFH1VShLmu5rRBUWA6/uqm9ivY0IlS25x/7X/DB9BvvHCvJljo hQ+PY20wfcB7NEZGPlrhSs3SE4FyVYmEwZCSVK9XfvtmcgE2NcAZeWxTbMB7nvfarUTN r+zuwN1xbb5sZdK0aQmiEI0tf0nj+uLQHFqi+koiTl/ZtEyFbDbq7MAo+dtymTNl/3RD qv3c26jzUSeKspY/76E8nBCKXY2RP2WX56inrJWsIrk/q2ue55YNBvaTQlh0bnPeqRsf XRgjIkkcS4oUgIWzOPZ+yZB/7VJBYcDJ/HaxmYwcCuKYWvLkZfmjwqOs09341D3btPIa PBlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sFyms30Eq1YhzTehbx6FcnM4kTMB7roIdhOSHa9j8v0=; b=Beo+KmfBfd8dPv3cJrLLdelpZc2IDprK0xlyAtXYSImG3NIH/Wvnpk42UmXGbLomlt NvlzI67MJUmHYB/MqB8sT9VJQa3Rfc+1f4H6sDIFZCtCcZP9wxirgVjE8hMzNzGiSfaL 31obRM2mxqZWu5F0uzPlt8JVyxhNWQVdex34BW712nw5BXlCx78zArWAq/ehm90ac+JC EIGXQgxXjeMM0Kk/WeqD5A06DRtDAxCNZfvsOk7kxIgCBQCI4H/bTw8jQCN/UQZrTlVH C5E3Dt82qLWurwfHSYgBnLYoCS8RZ3bo73A1dnb9mruqqytqR0TwDGjSmN1QGuj+eREI atEQ== X-Gm-Message-State: AN3rC/6117sHeL5z9Cvn73Pn/mtOCFcwYcNMJPCmquUTGPPn+Lg3kEg/EMLvUXO37xM/SA== X-Received: by 10.55.158.215 with SMTP id h206mr26410095qke.154.1491661583248; Sat, 08 Apr 2017 07:26:23 -0700 (PDT) Received: from ?IPv6:2607:fb90:e61:525e:e877:44d1:437e:7516? ([2607:fb90:e61:525e:e877:44d1:437e:7516]) by smtp.gmail.com with ESMTPSA id 1sm76747qtm.59.2017.04.08.07.26.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Apr 2017 07:26:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: mrcullen42@gmail.com X-Mailer: iPhone Mail (14D27) In-Reply-To: <1344FE29-570C-4ECA-83C4-8AC400A347D6@inf-net.nl> Date: Sat, 8 Apr 2017 10:26:21 -0400 Cc: Juliusz Chroboczek , babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <73C8A005-98F7-4E0F-AF96-D083905EBD22@gmail.com> References: <87y3vcuuv8.wl-jch@irif.fr> <1344FE29-570C-4ECA-83C4-8AC400A347D6@inf-net.nl> To: Teco Boot Archived-At: Subject: Re: [babel] Unicast Hellos -- conclusions so far 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, 08 Apr 2017 14:26:26 -0000 I still think we would do better, in the limited cases where Unicast hellos a= re needed because broadcast/multicast hellos are not possible (secure links b= etween neighbors or NBMA links) to just serialize any hellos that would have= been broadcast on those links with the serialization feature enabled on a l= ink-by-link basis. It has the benefit of being very simple to implement, and being completely c= ompatible with the current protocol. Why do we want to support a mix of uni= cast and multicast hellos on a single link? Margaret Sent from my iPhone On Apr 8, 2017, at 4:01 AM, Teco Boot wrote: >> Op 7 apr. 2017, om 16:59 heeft Juliusz Chroboczek het volge= nde geschreven: >>=20 >> Thanks to all for the discussion. Here's my current thinking: >>=20 >> 1. There are two kinds of Hellos, explicitly distinguished. They are >> called Hello and Unicast Hello. Hello MUST be sent over multicast or >> multi-unicast, Unicast Hello MUST be sent over unicast. On the sending >> side, there's a per-interface seqno for Hello, and a per-peer seqno for >> Unicast Hello. It is legal to never send Unicast Hellos, in which case >> the per-peer seqno is not needed. >>=20 >> 2. The on-the-wire encoding remains to be determined. Markus and myself >> are in favour of a separate TLV, David prefers a flag in Hello, Toke and >> Margaret havn't expressed an opinion (these are the people who are known >> to have an implementation). I'll treat this point in a separate mail. >>=20 >> 3. The interval field carries a promise to send a Hello of the same type >> within the given interval. (The alternative, a Hello of any kind within >> the interval, is not useful -- it doesn't allow to do link estimation >> reliably.) >>=20 >> 4. Unicast Hellos are allowed to set Interval to 0, meaning that this is >> an unscheduled Hello (used e.g. for carrying a timestamp sub-TLV, not >> necessarily for link maintenance) and we don't promise to send another >> one. I haven't decided whether allow Interval 0 in ordinary (multicast) >> Hellos. >>=20 >> 5. Informational algorithms for Appendix A2: >>=20 >> for wired links: >> - perform 2/3 for multicast hellos; >> - perform 2/3 for unicast hellos; >> - assume link is up if either instance of 2/3 says it's up. >=20 > Appendix A2 is for Cost Computation, right?=20 > Link Up depends on IHU. > OK, link from Hello sender to Hello receiver is assumed up. >=20 > Or is this "Link Up" equivalent to "it has recently heard a Hello"=20 > in rfc6126bis section-2.1? I couldn't find a precise definition=20 > that quickly. What means recently? >=20 >=20 >> for wireless links: >> - perform ETX for multicast hellos; >> - perform 2/3 for unicast hellos; >> - if multicast ETX is finite, use that; >> - otherwise, if unicast 2/3 says the link is up, assume the link is up >> but with a horribly high cost. >=20 > Same comment. >=20 > Teco >=20 >=20 >> We'll want to have at least two independent interoperable implementations= >> in time for Prague. Do we have consensus? >>=20 >> -- Juliusz >>=20 >> _______________________________________________ >> babel mailing list >> babel@ietf.org >> https://www.ietf.org/mailman/listinfo/babel >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Sat Apr 8 08:29: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 AF39C1243F3 for ; Sat, 8 Apr 2017 08:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 YFSYiVxIQKdv for ; Sat, 8 Apr 2017 08:29:51 -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 35D531201F8 for ; Sat, 8 Apr 2017 08:29:51 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v38FTm9U021026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 8 Apr 2017 17:29:49 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id v38FTmo4013455; Sat, 8 Apr 2017 17:29:48 +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 AE351D78B7; Sat, 8 Apr 2017 17:29:48 +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 Xm3v31P2IIYf; Sat, 8 Apr 2017 17:29:47 +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 72FAAD78C3; Sat, 8 Apr 2017 17:29:47 +0200 (CEST) Date: Sat, 08 Apr 2017 17:29:49 +0200 Message-ID: <87inme29zm.wl-jch@irif.fr> From: Juliusz Chroboczek To: mrcullen42@gmail.com Cc: babel@ietf.org In-Reply-To: <73C8A005-98F7-4E0F-AF96-D083905EBD22@gmail.com> References: <87y3vcuuv8.wl-jch@irif.fr> <1344FE29-570C-4ECA-83C4-8AC400A347D6@inf-net.nl> <73C8A005-98F7-4E0F-AF96-D083905EBD22@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 [IPv6:2001:660:3301:8000::1:2]); Sat, 08 Apr 2017 17:29:49 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 08 Apr 2017 17:29:48 +0200 (CEST) X-Miltered: at korolev with ID 58E901EC.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58E901EC.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58E901EC.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58E901EC.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 : 58E901EC.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58E901EC.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] Rationale for mixed unicast/multicast 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: Sat, 08 Apr 2017 15:29:54 -0000 > I still think we would do better, in the limited cases where Unicast > hellos are needed because broadcast/multicast hellos are not possible > (secure links between neighbors or NBMA links) to just serialize any > hellos that would have been broadcast on those links with the > serialization feature enabled on a link-by-link basis. I know that's your use case, Margaret, but I'm trying to design a protocol extension that meets the three uses cases outlined in my mail dated 3 April 2017. I'll get into a little more detail below. > It has the benefit of being very simple to implement, and being > completely compatible with the current protocol. Agreed. > Why do we want to support a mix of unicast and multicast hellos on > a single link? The basic issue is that multicast Hellos are the only way to perform in-band discovery. (Not a concern for you, Margaret, since you do out-of-band discovery in your implementation.) Consider an implementation that performs authentication by sending all the protocol traffic over unicast and protecting it with DTLS. Such an implementation would send updates aggregated into large unicast packets, and occasionally piggyback a Hello/IHU pair into such a unicast packet. However, it would still want to announce itself to any new peers, so occasionally it would send an unauthentified multicast Hello on each interface. Now it would be possible to require that Hellos be sent to all peers on an interface, whether over multicast or multiple unicast, so that seqnos remain in sync. (I believe you're the one who suggested that, Margaret, or at least you're the person who gave me the idea.) I've considered that, but it has four problems: it complicates the implementation by adding a special case to the packet scheduler, it requires sending extra traffic to some unicast peers (think battery-powered devices that have a higher update interval than other peers), it breaks multicast link-quality estimation (in 802.11, ETX only works well over multicast), and finally it breaks the RTT extension (which is only effective if Hello and IHU are sent in the same packet, so the receiver can correlate timestamps). Altogether, I think that adding a new packet type for Unicast Hellos is the right tradeoff: it makes a weakly compatible protocol change (legacy implementations will fail to associate with unicast-only peers, but nothing will break), and finally it's conceptually manageable, without any fragile special cases. -- Juliusz From nobody Sat Apr 8 16:41:09 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 3B018124D37 for ; Sat, 8 Apr 2017 16:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 azVz5jdIklVF for ; Sat, 8 Apr 2017 16:41:06 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 A16EB12947B for ; Sat, 8 Apr 2017 16:32:21 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id f133so69318618qke.2 for ; Sat, 08 Apr 2017 16:32:21 -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=Rr8u6y0mcscgXFfOkznwdiweLUEcRyLds0fLQ1CJHaA=; b=GewT05n9D8JCIq3T6VZf+cKt9BQa7EqENSHfckIIT5qy7xWSNp3t/rDaQ5sIc91QXg 5QNwXBXoFrZB93AXhBoKOy1UreS1tHxXOA0Rc0L1SiAUFhkupupWtQG5Sfes+8Hp87Gl cN9Pn2z/wy9w8b5aZI/4sG/I01GpsvsVxdEIZQt8JBuV65AFpQlAv5dvNuDlAd699qxR +tRzSwPDPbJJEDyyElz7mx6xfNPZt8sG6T1HukkXkAW/10AGpVth3nT7zYfUsmJLFd3b pQRTz+YiTztnT1Ig2bBNQq6oZS1el6+e0NUmuJS9le1DLk9Ya0WsweVf8W3c4WtKLFhU KjoQ== 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=Rr8u6y0mcscgXFfOkznwdiweLUEcRyLds0fLQ1CJHaA=; b=XPUbZyqMwvla8W5UpExQ6mbApIy/0PVGiCqEDOUOOnyIt43xA+7z0PU0+UBKSY6S8p O9kxEW82QUTde9iutrFL7ytwlmyEOjqeadkS/4gMY9Er22YLYmKCuUGt0IcM9xy6gEvm +77dx75hREAQ1PLMhfFUUKIbkBb8XGWCxm5ZvSL6qkN3vec3PjGWBqvFjfNTD/j9OP1N NjcVPU6zAv+XEo5uzMD9otyUCXylsiqv1FX51yR+cp9x6Bzjxf4yQFzkT6xlbBVwZhqw I3Hiz8nc6l2dZJO44C40e5cf+4Qve3tVIIkklDy3+lXJbG88Mx5luvGTajdmG71FR23K 7sLA== X-Gm-Message-State: AN3rC/46SlamZ+zbEc9Hz9wKowCchRGe+VFgDnyqMwjWbBA4c764o1zkDBlIhiTcIm3HnA== X-Received: by 10.55.71.137 with SMTP id u131mr14138234qka.317.1491694340802; Sat, 08 Apr 2017 16:32:20 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id j4sm5880399qkc.40.2017.04.08.16.32.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Apr 2017 16:32:19 -0700 (PDT) From: Ted Lemon Message-Id: <46FA0043-086B-4EEF-B35D-FB6D7BEEF912@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5AA79C77-5972-469C-9B85-8AFE43430275" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 8 Apr 2017 19:32:17 -0400 In-Reply-To: <87inme29zm.wl-jch@irif.fr> Cc: mrcullen42@gmail.com, babel@ietf.org To: Juliusz Chroboczek References: <87y3vcuuv8.wl-jch@irif.fr> <1344FE29-570C-4ECA-83C4-8AC400A347D6@inf-net.nl> <73C8A005-98F7-4E0F-AF96-D083905EBD22@gmail.com> <87inme29zm.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [babel] Rationale for mixed unicast/multicast 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: Sat, 08 Apr 2017 23:41:07 -0000 --Apple-Mail=_5AA79C77-5972-469C-9B85-8AFE43430275 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Apr 8, 2017, at 11:29 AM, Juliusz Chroboczek wrote: > The basic issue is that multicast Hellos are the only way to perform > in-band discovery. (Not a concern for you, Margaret, since you do > out-of-band discovery in your implementation.) Is there actually a need for in-band discovery if you have HNCP? --Apple-Mail=_5AA79C77-5972-469C-9B85-8AFE43430275 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 8, 2017, at 11:29 AM, Juliusz Chroboczek <jch@irif.fr> = wrote:
The basic issue is = that multicast Hellos are the only way to perform
in-band discovery.  (Not a concern for you, = Margaret, since you do
out-of-band = discovery in your implementation.)

Is there actually a need for in-band = discovery if you have HNCP?

= --Apple-Mail=_5AA79C77-5972-469C-9B85-8AFE43430275-- From nobody Sat Apr 8 17:11: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 B78C7128B90 for ; Sat, 8 Apr 2017 17:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 vmODfgw4-O8e for ; Sat, 8 Apr 2017 17:11: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 90CBF127871 for ; Sat, 8 Apr 2017 17:11: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 v390Bbnh021553; Sun, 9 Apr 2017 02:11:37 +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 7688ED78C3; Sun, 9 Apr 2017 02:11:37 +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 eFjy-GcXP64G; Sun, 9 Apr 2017 02:11:03 +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 E2A76D78B7; Sun, 9 Apr 2017 02:11:02 +0200 (CEST) Date: Sun, 09 Apr 2017 02:11:04 +0200 Message-ID: <87lgrazbhj.wl-jch@irif.fr> From: Juliusz Chroboczek To: Ted Lemon Cc: mrcullen42@gmail.com, babel@ietf.org In-Reply-To: <46FA0043-086B-4EEF-B35D-FB6D7BEEF912@fugue.com> References: <87y3vcuuv8.wl-jch@irif.fr> <1344FE29-570C-4ECA-83C4-8AC400A347D6@inf-net.nl> <73C8A005-98F7-4E0F-AF96-D083905EBD22@gmail.com> <87inme29zm.wl-jch@irif.fr> <46FA0043-086B-4EEF-B35D-FB6D7BEEF912@fugue.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]); Sun, 09 Apr 2017 02:11:37 +0200 (CEST) X-Miltered: at korolev with ID 58E97C39.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58E97C39.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 : 58E97C39.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] Rationale for mixed unicast/multicast 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: Sun, 09 Apr 2017 00:11:44 -0000 > The basic issue is that multicast Hellos are the only way to perform > in-band discovery. (Not a concern for you, Margaret, since you do > out-of-band discovery in your implementation.) > Is there actually a need for in-band discovery if you have HNCP? Babel is used in places where HNCP doesn't run (such as wireless community meshes). Even if HNCP is available, in-band discovery makes for better fate-sharing properties. And I'm rather attached to having the coupling between the protocols as loose as possible -- right now the coupling is very clean and elegant, see slide 7 of https://www.ietf.org/proceedings/93/slides/slides-93-homenet-2.pdf I think that giving up on in-band discovery would make Babel a much more limited protocol. -- Juliusz From nobody Sat Apr 8 17:56: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 460241287A7 for ; Sat, 8 Apr 2017 17:56:24 -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 VhfjDeB3L1lQ for ; Sat, 8 Apr 2017 17:56:22 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 DA8AF128B92 for ; Sat, 8 Apr 2017 17:56:21 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id p22so86944311qka.3 for ; Sat, 08 Apr 2017 17:56:21 -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=/LB+75W2xmq++pzS+l0OPIrKWjCLj1NWnE9sKFmpypQ=; b=wNO/ZhJq1/XuRQkUm/78pi/GVVY9ETJG9Sw/IyATPQO2sqJxqpeywE1SJPW1MnI41r 4WlYPiBiQcnUiQYppMI2Hsw25j1Jsg3URcegSqfGyGomQp8SeQhiCvqxVx8isZab/1fH RXcWjkXlmTAcXcVzWx/7wHolmYgq4i0of3wcn/2gbrZR/SqKN7L7uK32/n4faEL+ZSWQ FAh5gSd3JAfXfS0sWyFBpGX5Vc4gpLHvLuEZanV2etqd3T6VQSTwma8yN4ndAN4h7rRK X1CR9xA+W3boJDpBjqEco1D5oXepwDcrqlVQ7KP3rCS/Uvnb0ZLZL1O8WQPSjZ29il65 PDvQ== 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=/LB+75W2xmq++pzS+l0OPIrKWjCLj1NWnE9sKFmpypQ=; b=l0KRYDjy5mgqxnio5TZlophRCbA8GaH20NHZqyEXJNzYs9C14A+6rJ4q3m1bpZQQQm vxA+pcEyqjBPDlCKrzSymSVn3zDc085o/dvcHKU3HgOcoCEPgoZfilXZ5LpQTyGNmjd4 zTl1douXYS0XXTFR0cmXMGvCfuUs0iHO8diXH4DCZgAwsc3q0HMOUn3kpH3eUvKY+Tem QSlgMpym31f2FR4oREVOIxQ4Mn0HoRadhzvs+hRP3d904Du2WO2Qqho+o5qwEBhxE7gc qxPnhwl4v1g1IXmjcjHdfXwLPRAqgImY+WAhEiRWaKcoFl/JfFDw7zIcmLMq46MACjwo raMA== X-Gm-Message-State: AFeK/H3B+Xjv3v9SwiIf3cvmlkuX04HsLr36YRzBP6Sg5tz5vfJaUHdUyr45VYDINhJ8Ow== X-Received: by 10.55.151.199 with SMTP id z190mr49232501qkd.138.1491699380959; Sat, 08 Apr 2017 17:56:20 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id n195sm784889qke.28.2017.04.08.17.56.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Apr 2017 17:56:20 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_37E04669-2BF2-445F-9B41-CD3BDD0A43C3" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 8 Apr 2017 20:56:18 -0400 In-Reply-To: <87lgrazbhj.wl-jch@irif.fr> Cc: Margaret Cullen , babel@ietf.org To: Juliusz Chroboczek References: <87y3vcuuv8.wl-jch@irif.fr> <1344FE29-570C-4ECA-83C4-8AC400A347D6@inf-net.nl> <73C8A005-98F7-4E0F-AF96-D083905EBD22@gmail.com> <87inme29zm.wl-jch@irif.fr> <46FA0043-086B-4EEF-B35D-FB6D7BEEF912@fugue.com> <87lgrazbhj.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [babel] Rationale for mixed unicast/multicast 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: Sun, 09 Apr 2017 00:56:24 -0000 --Apple-Mail=_37E04669-2BF2-445F-9B41-CD3BDD0A43C3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Apr 8, 2017, at 8:11 PM, Juliusz Chroboczek wrote: > Even if HNCP is available, in-band discovery makes for better > fate-sharing properties. Right, forgot about that. Thanks. :) --Apple-Mail=_37E04669-2BF2-445F-9B41-CD3BDD0A43C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 8, 2017, at 8:11 PM, Juliusz Chroboczek <jch@irif.fr> = wrote:
Even if HNCP is = available, in-band discovery makes for better
fate-sharing = properties.

Right, forgot about that.  Thanks.   :)

= --Apple-Mail=_37E04669-2BF2-445F-9B41-CD3BDD0A43C3-- From nobody Tue Apr 11 15:16: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 58D68128656 for ; Tue, 11 Apr 2017 15:16: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 FX2-z1qGsiW8 for ; Tue, 11 Apr 2017 15:16: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 D416C126DEE for ; Tue, 11 Apr 2017 15:16:29 -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 v3BMGRJk015713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 12 Apr 2017 00:16: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 v3BMGR95032604 for ; Wed, 12 Apr 2017 00:16:27 +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 A30DAD7924 for ; Wed, 12 Apr 2017 00:16:27 +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 l9HAQXefn1Tl; Wed, 12 Apr 2017 00:16: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 A71AFD7891; Wed, 12 Apr 2017 00:16:25 +0200 (CEST) Date: Wed, 12 Apr 2017 00:16:28 +0200 Message-ID: <87o9w2egjn.wl-jch@irif.fr> From: Juliusz Chroboczek To: Matthieu Boutier Cc: babel@ietf.org In-Reply-To: <9882A041-900A-4414-BA7D-1EC4C1D3A63C@irif.fr> References: <87a87xooxm.wl-jch@irif.fr> <9882A041-900A-4414-BA7D-1EC4C1D3A63C@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]); Wed, 12 Apr 2017 00:16:28 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 12 Apr 2017 00:16:27 +0200 (CEST) X-Miltered: at korolev with ID 58ED55BB.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58ED55BB.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58ED55BB.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58ED55BB.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 : 58ED55BB.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58ED55BB.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] Unicast 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, 11 Apr 2017 22:16:31 -0000 > Then put the corresponding Hello TLV where you want. For compatibility > purposes, you should send a unicast Hello with the Multicast Hello > Interval sub-TLV attached. Use the last Interval value used in > a (really) multicast Hello as Interval. > The two reserved bytes of the legacy Hello will just cover the type and > length of the multicast TLV. A legacy implementation will see nothing > but a just well formed legacy 8-bytes-Hello TLV. Way too clever, Matthieu, and I don't see what problem it solves -- it has just the same compatibility issues as David's proposal, while creating a much more complex encoding. I'm also at a loss how to specify that. How should a node react to a Hello TLV with no sub-TLV? If the intent is that the proposed Hello TLV MUST be accompanied with exactly one of the two proposed sub-TLVs, then this is the first time that we'll define a mandatory sub-TLV in Babel. Unless it actually solves a real problem, I'd rather we avoid this kind of complexity. -- Juliusz From nobody Tue Apr 11 18:17: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 7F2791293D8 for ; Tue, 11 Apr 2017 18:17:13 -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_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 t0bOvnTXnNVc for ; Tue, 11 Apr 2017 18:17:12 -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 E43011293E1 for ; Tue, 11 Apr 2017 18:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491959822; 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=eQkN3ImH5zCL77t3Av62d5g1KBVQjLKBwu40Af/VqPs=; b=nzig9h3jr4wwV8FbvcrufSUgHnu2eOyUQUcuUVnZwV+Dnh/3V8UqNZLpWEpSDZjq 9yGN+wRfWZtN2Nixn7qRdbMpD+wTHkYgI79kSSpmFt1je0LeADblUNd9Yv0F2LOh Z6xhhU2pELjXDJkL95sK2dgT0Y+F8DHy76J7LsYRHeob42AxnjR8Rnh8KfQOqP3b ogXmao+lwrBn26pKgd4tXe4Af4N6exTxPyXXgq5BtGoP4KuYvAm69hhl1LzjC2s3 jJ9CQOvETcR0e2YTZnhTcywqsnh1nHme+/I/E50VS38a0S8xe90G/7NIBjBuzh8R WKSYxK4VDRwX7B3HP6Z4cQ==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id 69.8C.23264.D008DE85; Tue, 11 Apr 2017 18:17:02 -0700 (PDT) X-AuditID: 11ab0216-8abfb70000005ae0-a6-58ed800d52f9 Received: from koseret (koseret.apple.com [17.151.62.39]) by relay3.apple.com (Apple SCV relay) with SMTP id C5.A8.03951.D008DE85; Tue, 11 Apr 2017 18:17:01 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.69.143] (unknown [17.153.69.143]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OO900LZ7VJZDV30@koseret.apple.com>; Tue, 11 Apr 2017 18:17:01 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87o9w2egjn.wl-jch@irif.fr> Date: Tue, 11 Apr 2017 18:16:46 -0700 Cc: Matthieu Boutier , babel@ietf.org Message-id: References: <87a87xooxm.wl-jch@irif.fr> <9882A041-900A-4414-BA7D-1EC4C1D3A63C@irif.fr> <87o9w2egjn.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUi2FAYrMvX8DbCYNc2Y4sti7pZLA5/aWSx mN+6jM2B2WPJkp9MHou3vGUMYIrisklJzcksSy3St0vgynh1ZC9jwVOuih/7t7E0MJ7i6GLk 5JAQMJG4de0mWxcjF4eQwD5GiS+PZrPDJBbOPMEMkVjFKNG0+AYrSIJXQFDix+R7LF2MHBzM AvISB8/LgoSZBbQkvj9qZYGob2WSaPj7gAkkISwgLdF14S4rhG0k8WTFS7BeNqCGA2uMQMKc AhoSP7/+YwOxWQRUJZ4+aWKEmGkmcfLSeqi1NhItt/cyg9hCAiUSix6sBLNFBFQklk97BnWz rMSt2ZfAbpYQ2MAmsXbpA9YJjMKzkJw9C+HsWUjOXsDIvIpRODcxM0c3M8/ISC+xoCAnVS85 P3cTIyjIVzOJ7WC899rwEKMAB6MSD69AzdsIIdbEsuLK3EOM0hwsSuK8f5SBQgLpiSWp2amp BalF8UWlOanFhxiZODilGhhrUkJETnN/cvIMzKpYc8NMdaLVAxsRgzeVHHPXLb/ksFV/TWTb kf45Eoq7F66786Kdy1NGYt3kRaL9bfuVZkR9PfnYvUFOzn33moZXpeVNl525Kpp8frhcYHsb t3/TXmX7dn9WifAp85Iy59n9Ont3wrbKRKF7PHpHV5Tt5lFNm/rtinSa2mslluKMREMt5qLi RAAFruGJUwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUiON1OXZe34W2Ewe6jKhZbFnWzWBz+0shi Mb91GZsDs8eSJT+ZPBZvecsYwBTFZZOSmpNZllqkb5fAlfHqyF7GgqdcFT/2b2NpYDzF0cXI ySEhYCKxcOYJ5i5GLg4hgVWMEk2Lb7CCJHgFBCV+TL7H0sXIwcEsIC9x8LwsSJhZQEvi+6NW Foj6ViaJhr8PmEASwgLSEl0X7rJC2EYST1a8BOtlA2o4sMYIJMwpoCHx8+s/NhCbRUBV4umT JkaImWYSJy+th1prI9Fyey8ziC0kUCKx6MFKMFtEQEVi+bRn7BA3y0rcmn2JeQKjwCwkl85C uHQWkksXMDKvYhQoSs1JrDTWSywoyEnVS87P3cQICsmGwuAdjH+WWR1iFOBgVOLh9TjzJkKI NbGsuDL3EKMEB7OSCG+Ly9sIId6UxMqq1KL8+KLSnNTiQ4xVQPdPZJYSTc4HxkteSbyhiYmB ibGxmbGxuYk5VYSVxHkvigAdI5CeWJKanZpakFoEs5yJg1OqgVFfbV64Ib9C/kn5KM3N60wV r+c0iDIqO9yRqKmZu+3EJWYT3jCtd/9Mtl+e+sr3/+3WnoBdm11PVS1IYpyl8fL0S/7r8bMy v707sV2mSviKdb723FdfxU6tmfiB6azauocPPxrPutLDvfdSasuLBz67o+wM/dgv75TgnGG/ VPV0lVrrtLWeXziVWIozEg21mIuKEwHPQzsXpAIAAA== Archived-At: Subject: Re: [babel] [Babel-users] Unicast 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: Wed, 12 Apr 2017 01:17:14 -0000 I agree with Juliusz, the same result can be achieved with less complexity. David > On Apr 11, 2017, at 15:16, Juliusz Chroboczek wrote: > >> Then put the corresponding Hello TLV where you want. For compatibility >> purposes, you should send a unicast Hello with the Multicast Hello >> Interval sub-TLV attached. Use the last Interval value used in >> a (really) multicast Hello as Interval. > >> The two reserved bytes of the legacy Hello will just cover the type and >> length of the multicast TLV. A legacy implementation will see nothing >> but a just well formed legacy 8-bytes-Hello TLV. > > Way too clever, Matthieu, and I don't see what problem it solves -- it has > just the same compatibility issues as David's proposal, while creating > a much more complex encoding. > > I'm also at a loss how to specify that. How should a node react to > a Hello TLV with no sub-TLV? If the intent is that the proposed Hello TLV > MUST be accompanied with exactly one of the two proposed sub-TLVs, then > this is the first time that we'll define a mandatory sub-TLV in Babel. > > Unless it actually solves a real problem, I'd rather we avoid this kind of > complexity. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From boutier@irif.fr Mon Apr 10 14:47: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 A3E07128B51 for ; Mon, 10 Apr 2017 14:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 EtHcw9cq4pqY for ; Mon, 10 Apr 2017 14:47:43 -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 6A8D4128708 for ; Mon, 10 Apr 2017 14:47:43 -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 v3ALlfkY030114; Mon, 10 Apr 2017 23:47:41 +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 49EF9D79B2; Mon, 10 Apr 2017 23:47:41 +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 ckPqbVn1jOou; Mon, 10 Apr 2017 23:47:39 +0200 (CEST) Received: from mac-matthieu.lan (AAubervilliers-652-1-166-120.w82-121.abo.wanadoo.fr [82.121.213.120]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B44C3D798C; Mon, 10 Apr 2017 23:47:39 +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: <87a87xooxm.wl-jch@irif.fr> Date: Mon, 10 Apr 2017 23:47:38 +0200 Cc: babel-users@lists.alioth.debian.org Content-Transfer-Encoding: quoted-printable Message-Id: <9882A041-900A-4414-BA7D-1EC4C1D3A63C@irif.fr> References: <87a87xooxm.wl-jch@irif.fr> To: babel@ietf.org 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]); Mon, 10 Apr 2017 23:47:41 +0200 (CEST) X-Miltered: at korolev with ID 58EBFD7D.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58EBFD7D.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 : 58EBFD7D.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: X-Mailman-Approved-At: Wed, 12 Apr 2017 08:04:24 -0700 Subject: Re: [babel] Unicast 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: Mon, 10 Apr 2017 21:49:21 -0000 Hi, > Something else? > *************** >=20 > Other ideas? Perhaps. Let the new Hello be: 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 =3D 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ And define 2 new sub-TLVs: 1. Unicast Hello Interval 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 =3D X | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seqno | Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2. Multicast Hello Interval 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 =3D Y | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seqno | Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Then put the corresponding Hello TLV where you want. For compatibility = purposes, you should send a unicast Hello with the Multicast Hello = Interval sub-TLV attached. Use the last Interval value used in a = (really) multicast Hello as Interval. The two reserved bytes of the legacy Hello will just cover the type and = length of the multicast TLV. A legacy implementation will see nothing = but a just well formed legacy 8-bytes-Hello TLV. Matthieu From nobody Thu Apr 13 08:55: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 AE6C71294CC for ; Thu, 13 Apr 2017 08:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 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, RCVD_IN_SORBS_SPAM=0.5, 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 7HbZIxWCqAME for ; Thu, 13 Apr 2017 08:55:16 -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 66B061294B3 for ; Thu, 13 Apr 2017 08:55:04 -0700 (PDT) Received: from wwinf1g30 ([10.232.37.104]) by mwinf5d39 with ME id 7rv11v00R2EpRBe03rv1RT; Thu, 13 Apr 2017 17:55:01 +0200 X-ME-Helo: wwinf1g30 X-ME-Auth: eWl5b3BAd2FuYWRvby5mcg== X-ME-Date: Thu, 13 Apr 2017 17:55:01 +0200 X-ME-IP: 81.194.27.158 Date: Thu, 13 Apr 2017 17:55:01 +0200 (CEST) From: Gwendoline Reply-To: Gwendoline To: babel@ietf.org Message-ID: <2004672991.20876.1492098901620.JavaMail.www@wwinf1g30> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_20875_591453501.1492098901614" X-Originating-IP: [81.194.27.158] X-WUM-FROM: |~| X-WUM-TO: |~| X-WUM-CCI: |~| X-WUM-REPLYTO: |~| Archived-At: Subject: [babel] Source and ToS-specific routing for Babel : request for comments 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, 13 Apr 2017 15:55:20 -0000 ------=_Part_20875_591453501.1492098901614 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all, I have just started working with Juliusz, and I hope to design and implemen= t a ToS-specific routing extension for Babel, so that we have another example o= f=20 Babel extension to decide if rfc6126bis is neither too restrictive nor too= =20 permissive regarding extensions. As explained during the Chicago meeting, we think that the packet format=20 for the source-specific routing extension for Babel, implemented=20 by Matthieu, could be better (for now, it consists of 3 new TLVs and they h= ave=20 too many fields, see slides 11-13 https://www.ietf.org/proceedings/98/slide= s/slides-98-babel-about-some-babel-drafts-00.pdf ) We want to redefine TLVs for the source-specific routing and the ToS-specific routing Babel extensions. We want to profit of Juliusz' future editing of RFC 6126bis, and use new AE= values: Interpreting a source-specific (resp. ToS-specific) update message as a cla= ssic update message by ignoring the source information (resp. ToS information) a= nd considering the update it announces as a classical update might cause routi= ng loops. That's why there's nothing a classical router should do with a source-speci= fic (resp. ToS-specific) update message. Since RFC 6126 specifies that any TLV with an unknown AE must be ignored, w= e want to use new AE values for source-specific and ToS-specific updates.=20 For example, we could use the following values: =C2=A0=C2=A0 o=C2=A0 AE 5: Source-specific for IPV4 =C2=A0=C2=A0 o=C2=A0 AE 6: Source-specific for IPV6 =C2=A0=C2=A0 o=C2=A0 AE 7: ToS-specific for IPV4 =C2=A0=C2=A0 o=C2=A0 AE 8: ToS-specific for IPV6 They would use it in the 3 TLVs whose meaning is changed by the extensions:= Update, Route Request and Seqno Request. For Source-Specific Routing, TLVs would be (adding a source=20 prefix and its length): UPDATE: 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0=C2=A0 Type =3D 8=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Length=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AE=3D6=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0 Reserved=C2=A0=C2=A0=C2=A0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Plen=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0 Omitted=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Interval=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S= eqno=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Metric=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0 Source Plen=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Prefi= x... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Source prefix... +-+-+-+-+-+-+-+-+-+-+-+- ROUTE REQUEST: 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0=C2=A0 Type =3D 9=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Length=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AE=3D6=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Plen=C2=A0=C2=A0=C2=A0=C2=A0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0 Source Plen=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Prefi= x... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Source prefix... +-+-+-+-+-+-+-+-+-+-+-+- SEQNO REQUEST: 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0=C2=A0 Type =3D 10=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Length=C2=A0=C2= =A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AE=3D6=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Plen=C2=A0=C2=A0=C2=A0=C2=A0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S= eqno=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0=C2=A0 Hop Count=C2=A0=C2=A0 |=C2=A0=C2=A0 Reserved=C2=A0=C2=A0= =C2=A0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Router-Id=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 + |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0 Source Plen=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Prefi= x... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Source prefix... +-+-+-+-+-+-+-+-+-+-+-+- For ToS-Specific Routing, TLVs would be (adding of a ToS field=20 right before the prefix): UPDATE: 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0=C2=A0=C2=A0 Type =3D 8=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Length=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AE=3D8=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0 Flags=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0=C2=A0=C2=A0=C2=A0 Plen=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0 Omitted=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Interval=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S= eqno=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Met= ric=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ToS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0 Prefix ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ROUTE REQUEST: 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0=C2=A0=C2=A0 Type =3D 9=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Length=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AE=3D8=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 Plen=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ToS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0 Prefix ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SEQNO REQUEST: 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0=C2=A0=C2=A0 Type =3D 10=C2=A0 |=C2=A0=C2=A0=C2=A0 Length=C2=A0=C2= =A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AE=3D8=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0 Plen=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S= eqno=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0 Hop Count=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 Reserved=C2=A0=C2=A0= =C2=A0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Router-Id=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 + |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ToS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0 Prefix ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The bit that worries me is what to do if we want to use=20 Source-and-ToS-specific routing (or the intersection with any=20 future extension that also uses a new AE)? This choice suggests that we would need a new AE for any combination of existing extensions (and any future extension must define those new AE values, deciding which other extensions are compatible). However, a whole octet looks enough to code all these possibilities. Could you please tell your thoughts on this? ------=_Part_20875_591453501.1492098901614 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear all,


I have just started working with Juliusz, and= I hope to design and implement a
ToS-specific routing extension for B= abel, so that we have another example of
Babel extension to decide if= rfc6126bis is neither too restrictive nor too
permissive regarding e= xtensions.


As explained during the Chicago meeting, we thi= nk that the packet format
for the source-specific routing extension f= or Babel, implemented
by Matthieu, could be better (for now, it consi= sts of 3 new TLVs and they have
too many fields, see slides 11-13 htt= ps://www.ietf.org/proceedings/98/slides/slides-98-babel-about-some-babel-dr= afts-00.pdf )
We want to redefine TLVs for the source-specific routing= and the
ToS-specific routing Babel extensions.

We want to = profit of Juliusz' future editing of RFC 6126bis, and use new AE values:Interpreting a source-specific (resp. ToS-specific) update message as a = classic
update message by ignoring the source information (resp. ToS i= nformation) and
considering the update it announces as a classical upd= ate might cause routing loops.
That's why there's nothing a classical = router should do with a source-specific
(resp. ToS-specific) update me= ssage.
Since RFC 6126 specifies that any TLV with an unknown AE must b= e ignored, we want
to use new AE values for source-specific and ToS-sp= ecific updates.


For example, we could use the following v= alues:


=C2=A0=C2=A0 o=C2=A0 AE 5: Source-specific for IPV4=
=C2=A0=C2=A0 o=C2=A0 AE 6: Source-specific for IPV6

=C2=A0= =C2=A0 o=C2=A0 AE 7: ToS-specific for IPV4
=C2=A0=C2=A0 o=C2=A0 AE 8: = ToS-specific for IPV6



They would use it in the 3 TLV= s whose meaning is changed by the extensions: Update, Route Request
an= d Seqno Request.

For Source-Specific Routing, TLVs would be (add= ing a source
prefix and its length):


UPDATE:
0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=C2=A0=C2=A0 Type =3D 8=C2=A0=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0 Length=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 AE=3D6=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 Reserved=C2=A0=C2= =A0=C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Plen=C2=A0=C2=A0=C2=A0=C2=A0 |= =C2=A0=C2=A0=C2=A0 Omitted=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Interval=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Seqno=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Metric=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=C2=A0 Source Plen=C2=A0 |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Prefix...
+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Sourc= e prefix...
+-+-+-+-+-+-+-+-+-+-+-+-


ROUTE REQUEST:
0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=C2=A0=C2=A0 Type =3D 9=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Length=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 AE=3D6=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Plen=C2=A0=C2=A0=C2=A0=C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=C2=A0 Source Plen=C2=A0 |=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Source pref= ix...
+-+-+-+-+-+-+-+-+-+-+-+-


SEQNO REQUEST:
0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=C2=A0=C2=A0 Type =3D 10=C2=A0=C2=A0 |= =C2=A0=C2=A0=C2=A0 Length=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 AE=3D6=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Plen= =C2=A0=C2=A0=C2=A0=C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Seqno=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 Hop Count=C2=A0=C2=A0 |=C2=A0= =C2=A0 Reserved=C2=A0=C2=A0=C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Router-Id=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|=C2=A0 Source Plen=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 P= refix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Source prefix...
+-+-+-+-+-+-+-+-+-+-+-= +-


For ToS-Specific Routing, TLVs would be (adding of a To= S field
right before the prefix):

UPDATE:


0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+
|=C2=A0=C2=A0=C2=A0 Type =3D 8=C2=A0=C2=A0 |= =C2=A0=C2=A0=C2=A0 Length=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 AE=3D8=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Flags=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
|=C2=A0=C2=A0=C2=A0=C2=A0 Plen=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Omitted=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Interval=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Seqno=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Metric=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 ToS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Prefix ...<= br />+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


ROUTE REQUEST:
0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=C2=A0=C2=A0=C2=A0 Type =3D 9=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Length=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 AE=3D8=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0= Plen=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ToS= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Prefix ...
+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+



SEQNO REQUEST:

0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+
|=C2=A0=C2=A0=C2=A0 Type =3D 10=C2=A0 |=C2= =A0=C2=A0=C2=A0 Length=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 AE=3D8=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Plen=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Seqno=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Hop Count=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0 Reserved=C2=A0=C2=A0=C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Router-Id=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +
|= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |<= br />+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ToS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0 Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The bit that worries me is what to do if we want to use
Source-and= -ToS-specific routing (or the intersection with any
future extension = that also uses a new AE)?
This choice suggests that we would need a ne= w AE for any combination
of existing extensions (and any future extens= ion must define those
new AE values, deciding which other extensions a= re compatible).
However, a whole octet looks enough to code all these = possibilities.

Could you please tell your thoughts on this?










------=_Part_20875_591453501.1492098901614-- From nobody Thu Apr 13 09:51:59 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 2B099129505 for ; Thu, 13 Apr 2017 09:51:58 -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 TGIQR1T5rRNq for ; Thu, 13 Apr 2017 09:51:56 -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 84C8F129AFE for ; Thu, 13 Apr 2017 09:51:53 -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 v3DGppAR021980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 13 Apr 2017 18:51:51 +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 v3DGpptt029881 for ; Thu, 13 Apr 2017 18:51: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 A9B89D79B2 for ; Thu, 13 Apr 2017 18:51: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 J9sbV7HKdJE6 for ; Thu, 13 Apr 2017 18:51: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 B5F6ED793F for ; Thu, 13 Apr 2017 18:51:50 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.88) (envelope-from ) id 1cyhyI-00074E-FK for babel@ietf.org; Thu, 13 Apr 2017 18:51:50 +0200 Date: Thu, 13 Apr 2017 18:51:50 +0200 Message-ID: <7i8tn4mes9.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, 13 Apr 2017 18:51:51 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 13 Apr 2017 18:51:51 +0200 (CEST) X-Miltered: at korolev with ID 58EFACA7.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58EFACA7.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58EFACA7.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58EFACA7.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 : 58EFACA7.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58EFACA7.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: [babel] rfc6126bis updates 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, 13 Apr 2017 16:51:58 -0000 Dear all, I've integrated the extension mechanism into rfc6126, and did some work on making updates more extensible. It's not finished yet, but I'm starting to get an XML overload, so it's time to go do something else. Comments welcome, of course, although you may want to wait until I've finished. Thanks, -- Juliusz From nobody Thu Apr 13 10:38: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 BC06212EAAF for ; Thu, 13 Apr 2017 10:38:29 -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 OKy9oQSvJcE3 for ; Thu, 13 Apr 2017 10:38:28 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 8FA4512EAC4 for ; Thu, 13 Apr 2017 10:38:26 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id n46so51245283qta.2 for ; Thu, 13 Apr 2017 10:38:26 -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=nnyrXeBqBPWsW/ls00Uwo3wAXt6uBDA9Mk5aP1RWWQ8=; b=oW2/4YbUk3a2x/8blbd38fwdzFll7SOTJK4ZKRwsbYhoknDrA6UgOWm3jczbK9eS9H 58/SAjlQ+zScwOPclawPenfe6LZxtxuyaJk3FPLW+yOeLmqMNIn+l3BqrW5/z1OjJh83 BNapCZO2MJW9+tEHtd3nixz64uyBgqg2FlN9+K1v6g4PW12XwoVhfapFW6OSzXXZgdjo LjZPnmqcvMG+1aLYmBqZodxSkP7rwOx8GlfUtPc3zh2mqvRTWATEntupiFzNqQON7/s0 IueAdCoedl3/drHZnxoMZUyf8BSPmTNO0a44EpLhmx7JKMRXCUtUAQdGTIEK6IoEFh3G T15g== 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=nnyrXeBqBPWsW/ls00Uwo3wAXt6uBDA9Mk5aP1RWWQ8=; b=EPWNVYaa7NBsboqwA/HgGg7jS6oza8PvJU0ZGV/2cWsMEGyqvaoEIWq1bCrWh2efW4 QEnC2yjVvHF9aH6jZPvWa01fhzEY0HqTtPYkt8aamQv0HVd5z+Y7j6hUrMXrF0udeDNh BNbkGxmHKrGvHo3caNkbHEXEVMhvyLgUSy+VGZC+fzQ5SdCjnZR+MIjxdxpotQG5lpF9 N/EhwUS0KBM/CqKAvjEp7MqN4zK2jGRZV4LztPF0i+kj0X4c69JFLcgkUaCQkppt0Qzs Ykr7a0DUirSb0QHRC4rpK4XMIB3zNtX1dOaa9HUlusdZTg14W5hj7XRPylTW+sGN6VDr dzaw== X-Gm-Message-State: AN3rC/71vQqDD6ewhC6xJrDtlzP+La+t7MYzbdWCOLTKMWrEn7GQaLEd wmqUYU3xU8/6EZlcuu7fyP6d5WH0cg== X-Received: by 10.237.62.125 with SMTP id m58mr3512237qtf.36.1492105105693; Thu, 13 Apr 2017 10:38:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.140.8 with HTTP; Thu, 13 Apr 2017 10:38:25 -0700 (PDT) In-Reply-To: <7i8tn4mes9.wl-jch@irif.fr> References: <7i8tn4mes9.wl-jch@irif.fr> From: Dave Taht Date: Thu, 13 Apr 2017 10:38:25 -0700 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [babel] rfc6126bis updates 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, 13 Apr 2017 17:38:30 -0000 >From an rfc front, if your eyes are bleeding from xml, we used kramdown format for these: https://github.com/dtaht/bufferbloat-rfcs/tree/master/fq_codel But it's hard to review a draft in progress if we don't know where it is. From nobody Thu Apr 13 11:45: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 DF78A1315A8 for ; Thu, 13 Apr 2017 11:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 maGiTH4ab_RM for ; Thu, 13 Apr 2017 11:45: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 788F712EAAE for ; Thu, 13 Apr 2017 11:45: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 v3DIjecb024005; Thu, 13 Apr 2017 20:45: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 3AD27D798C; Thu, 13 Apr 2017 20:45: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 HwvRM4RkbcUF; Thu, 13 Apr 2017 20:45: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 69EE3D793F; Thu, 13 Apr 2017 20:45:36 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.88) (envelope-from ) id 1cyjkO-00077s-5s; Thu, 13 Apr 2017 20:45:36 +0200 Date: Thu, 13 Apr 2017 20:45:36 +0200 Message-ID: <7i4lxsm9in.wl-jch@irif.fr> From: Juliusz Chroboczek To: Dave Taht Cc: Babel at IETF In-Reply-To: References: <7i8tn4mes9.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, 13 Apr 2017 20:45:40 +0200 (CEST) X-Miltered: at korolev with ID 58EFC754.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58EFC754.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 : 58EFC754.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] rfc6126bis updates 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, 13 Apr 2017 18:45:44 -0000 > But it's hard to review a draft in progress if we don't know where it is. https://github.com/jech/babel-drafts From nobody Thu Apr 13 21:38:29 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 3E0B71294BF for ; Thu, 13 Apr 2017 21:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iGAG8kQB7S-4 for ; Thu, 13 Apr 2017 21:38:26 -0700 (PDT) Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38A2127241 for ; Thu, 13 Apr 2017 21:38:26 -0700 (PDT) Received: from nemesis.taht.net (unknown [IPv6:2601:646:8501:df5:2e0:4cff:fec1:1206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id DD6431F9D9 for ; Fri, 14 Apr 2017 04:38:24 +0000 (UTC) From: Dave Taht To: babel@ietf.org Date: Thu, 13 Apr 2017 21:38:23 -0700 Message-ID: <87o9vzfvsw.fsf@nemesis.taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [babel] source and tos routing thoughts 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, 14 Apr 2017 04:38:28 -0000 >The bit that worries me is what to do if we want to use >Source-and-ToS-specific routing (or the intersection with any >future extension that also uses a new AE)? >This choice suggests that we would need a new AE for any combination >of existing extensions (and any future extension must define those >new AE values, deciding which other extensions are compatible). >However, a whole octet looks enough to code all these possibilities. >Could you please tell your thoughts on this? A) TOS is an obsolete term, dscp or diffserv are more current, and have a specific meaning of 64 values, of which, something like 23 are defined. Two bits of the former tos field are reserved for ECN. This asks the question - do you intend "tos routing" to be on those 64 values or the whole shmere? B) What are your promotion/demotion rules for the TOS routed links? If no AF42 route is available, do you go to AF41? to best effort? Drop the packets on the floor? Do you have to cover the entire 256 values in the protocol? This explosion of what is already 34 bytes of data (src/dst plen/plen) into (potentially) a set of routing tables 256 times bigger that might prove troublesome. C) Presently, in linux, you can set ecn capability on and off on a per route basis, which is used, for example, along with congctl, to make DCTCP work in places where it is safe to run it on a portion of the network, and unsafe elsewhere. ip route is showing the following options these days: OPTIONS := FLAGS [ mtu NUMBER ] [ advmss NUMBER ] [ as [ to ] ADDRESS ] [ rtt TIME ] [ rttvar TIME ] [ reordering NUMBER ] [ window NUMBER] [ cwnd NUMBER ] [ initcwnd NUMBER ] [ ssthresh NUMBER ] [ realms REALM ] [ src ADDRESS ] [ rto_min TIME ] [ hoplimit NUMBER ] [ initrwnd NUMBER ] [ features FEATURES ] [ quickack BOOL ] [ congctl NAME ] [ pref PREF ] FEATURES: ecn Somewhat offtopic: D) There are a lot of other characteristics of routes that are "interesting". In my case, for example, I'd rather dearly love it if initcwd (& ssthresh) could be massively reduced for routes exiting the default gw on slow networks. (initcwnd of 2, etc) Similarly, mtu could be advertised instead of probing. Back on topic So while "tos" can be represented, what are the use cases for it? From nobody Fri Apr 14 10:00:42 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 6EB1C129AE8 for ; Fri, 14 Apr 2017 10:00:41 -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 42FegM_0JW-i for ; Fri, 14 Apr 2017 10:00:39 -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 530B512946C for ; Fri, 14 Apr 2017 10:00: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 v3EH0b4h024447; Fri, 14 Apr 2017 19:00:37 +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 8EF3DD798C; Fri, 14 Apr 2017 19:00:37 +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 u8zkfssqso8G; Fri, 14 Apr 2017 19:00:36 +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 779CAD7924; Fri, 14 Apr 2017 19:00:35 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.88) (envelope-from ) id 1cz4aJ-0007q7-2p; Fri, 14 Apr 2017 19:00:35 +0200 Date: Fri, 14 Apr 2017 19:00:35 +0200 Message-ID: <7iy3v2x6to.wl-jch@irif.fr> From: Juliusz Chroboczek To: Dave Taht Cc: babel@ietf.org In-Reply-To: <87o9vzfvsw.fsf@nemesis.taht.net> References: <87o9vzfvsw.fsf@nemesis.taht.net> 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, 14 Apr 2017 19:00:37 +0200 (CEST) X-Miltered: at korolev with ID 58F10035.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F10035.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 : 58F10035.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: Re: [babel] source and tos routing thoughts 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, 14 Apr 2017 17:00:41 -0000 > B) What are your promotion/demotion rules for the TOS routed links? As far as I can tell at that early stage, any ordering would work. Gwendoline and I have slightly different opinions here -- I'd like her to do the simple thing first (TOS exact match, or use non-specific route), while she'd like to do something more exciting. > a set of routing tables 256 times bigger that might prove troublesome. The idea is that just a small set of TOS are announced, the remainder follow the non-specific route. See the use-case below. > C) Presently, in linux, you can set ecn capability on and off on a per > route basis I'm not sure how that's related to routing. You are not seriously suggesting that packets should be routed differently depending on the value of the ECN bits? > So while "tos" can be represented, what are the use cases for it? The main use case is due to Nexedi. They're considering a network with multiple edge links, some of which have low latency and jitter but are expensive (MPLS leased lines, most probably), some of which are cheap but jittery (tunnels over the public Internet). They want voice traffic to flow over the expensive links, and data traffic to use the cheap ones. They're not using source-specific routing in their network, and they only really care about IPv6, which makes the problem somewhat more tractable. -- Juliusz From nobody Fri Apr 14 10:29: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 131651292AE for ; Fri, 14 Apr 2017 10:29:55 -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, RCVD_IN_DNSWL_MED=-2.3, 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=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 lgiMDJ9bPHVe for ; Fri, 14 Apr 2017 10:29:52 -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 C771C1294A5 for ; Fri, 14 Apr 2017 10:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1492190992; 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=eIARlhZ+o4pIEbGc6Ibc+4jCPptSDQnzhqawaJYnBR0=; b=NQkI6wpCjCHNhgvf98fSM2r9iphPb9A7QWEOp6Qzl9Ayvyx7VTS3ByXa1KS3CB0u 3OrniORjw9kWXQnPWlTeph/Y1gh4vpGfvZNWgOWU9YwuB8bX638H3wGbQ21EugwM GuuRX2CghFg7jscofstpo3RXJBd87EReJ+6C1N5PzeQSrdjiy+oBISn/+FHhR4OZ 8SZxtlF1ikZ7fA+7NO/No+iMCn3DvZ3QlUhq/SiLdhycHvCp9lboUvKNhryREyb/ XnM0yVZcI60C9LIsUQvS8Lpo5yOrymigIv2K/GwWRZWum3lLlLYOuqyYuGdBY/lg 4OBtFPd3g/dteLfiQSM7UQ==; 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 D4.50.23870.01701F85; Fri, 14 Apr 2017 10:29:52 -0700 (PDT) X-AuditID: 11973e12-9ea929a000005d3e-4c-58f10710711c Received: from kencur (kencur.apple.com [17.151.62.38]) by relay8.apple.com (Apple SCV relay) with SMTP id 0B.3C.26253.F0701F85; Fri, 14 Apr 2017 10:29:52 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_UOLFUL0touMr6RV3AnxHsQ)" Received: from [17.153.95.198] (unknown [17.153.95.198]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OOE002NFTXNSP20@kencur.apple.com>; Fri, 14 Apr 2017 10:29:51 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <2A6A6A8E-04F6-4353-AA1F-752CD75A10BB@apple.com> Date: Fri, 14 Apr 2017 10:29:45 -0700 In-reply-to: <2004672991.20876.1492098901620.JavaMail.www@wwinf1g30> Cc: babel@ietf.org To: Gwendoline References: <2004672991.20876.1492098901620.JavaMail.www@wwinf1g30> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUi2FCYpivA/jHCoOOxusWWRd0sFm+PP2Rz YPJYsuQnk8fnu+tZA5iiuGxSUnMyy1KL9O0SuDJu39zNUrD6JGPFrqMKDYzHVjB2MXJySAiY SEx6dJKli5GLQ0hgDZPEl+sT4RL/7txih0isYJTo7gRxODl4BQQlfky+xwJiMwuESWy6dJ4N oqiZSeLfg81g3cIC0hJdF+6ydjFycLAJaEkcWGME0WsjsW/SGzaIknCJw+umgpWzCKhK7Dj3 FSzOKeAi0fXvAiPEfCGJM9dmgO0SEVCU+Dx1JVhcSMBZ4trJ3ewQh8pK3Jp9iRnkBgmBI2wS y0/NY5zAKDQLya2zkNwKYWtJfH/UChTnALLlJQ6el4UIa0o8u/eJHcLWlnjy7gLrAka2VYxC uYmZObqZeSZ6iQUFOal6yfm5mxhB0TDdTmgH46lVVocYBTgYlXh4Lxz/ECHEmlhWXJl7iFGa g0VJnHfClHcRQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjlmiVrWtWuLPnWLVWzwfR53Ymr qUx6SXdzq48naCXxumXwfxeZ84ntUIA5k0j/W8O7uwWrQ459Dm1699mmJ8TA24qlS2nCd/bj VusiZC4GOX66E8D6f9P0KbEyd9pY1YQCNkks2yD9f5F21WLJJWei7j0K0L6uapoao+eQzvfz /brngR+irymxFGckGmoxFxUnAgCVq4JkZwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUiON1OTVeA/WOEQctUJYsti7pZLN4ef8jm wOSxZMlPJo/Pd9ezBjBFcdmkpOZklqUW6dslcGXcvrmbpWD1ScaKXUcVGhiPrWDsYuTkkBAw kfh35xZ7FyMXh5DACkaJ7k4Qh5ODV0BQ4sfkeywgNrNAmMSmS+fZIIqamST+PdgM1i0sIC3R deEuaxcjBwebgJbEgTVGEL02EvsmvWGDKAmXOLxuKlg5i4CqxI5zX8HinAIuEl3/LjBCzBeS OHNtBtguEQFFic9TV4LFhQScJa6d3M0OcaisxK3Zl5gnMPLPQnLeLCTnQdhaEt8ftQLFOYBs eYmD52UhwpoSz+59YoewtSWevLvAuoCRbRWjQFFqTmKlhV5iQUFOql5yfu4mRlDwNhSm7WBs Wm51iFGAg1GJh7fi6IcIIdbEsuLK3EOMEhzMSiK8k/4BhXhTEiurUovy44tKc1KLDzFOZAR6 ciKzlGhyPjC28kriDU1MDEyMjc2Mjc1NzGkprCTO278b6CKB9MSS1OzU1ILUIpijmDg4pRoY Zy4te3firkn7Yz2pCQJbfRq5d6wXPW46ydo5m3sBo86GlK5VBcwf5wmtcvvfyPZwVuT1XTUu OsWXF9pe38MyLeHQC+nvd97kLdD1m5/K+EioQH8ja4b8X03PoOaw9glae0/cezZz+XQmjnIp 4WLXRwmG56RrTCL77m26X7TT+eB1tc6W0x6vlViKMxINtZiLihMBOqMILNECAAA= Archived-At: Subject: Re: [babel] Source and ToS-specific routing for Babel : request for comments 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, 14 Apr 2017 17:29:55 -0000 --Boundary_(ID_UOLFUL0touMr6RV3AnxHsQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Gwendoline, First of all, thanks for writing this up, this is cool! I believe there are use cases where this is really useful. While I really like the idea of using AE instead of new TLVs, I am slightly worried by the inability to combine these. As you discussed, one may want to route based on both ToS and Source. I think there's only one solution to this problem, which would be to use sub-TLVs instead of AE, with a flag telling the receiver to ignore any Update containing unknown sub TLVs. Sadly this feels overly complicated to me. So, if we agree to burn a new AE for each combination, which I think I can live with, then this proposals sounds great! I think we may want to add text saying that this is DiffServ routing, you really want to avoid routing differently based on the ECN bits (we've seen that in the field, it triggers TCP PAWS and bad things happen). Thanks, David > On Apr 13, 2017, at 08:55, Gwendoline wrote: > > Dear all, > > > I have just started working with Juliusz, and I hope to design and implement a > ToS-specific routing extension for Babel, so that we have another example of > Babel extension to decide if rfc6126bis is neither too restrictive nor too > permissive regarding extensions. > > > As explained during the Chicago meeting, we think that the packet format > for the source-specific routing extension for Babel, implemented > by Matthieu, could be better (for now, it consists of 3 new TLVs and they have > too many fields, see slides 11-13 https://www.ietf.org/proceedings/98/slides/slides-98-babel-about-some-babel-drafts-00.pdf ) > We want to redefine TLVs for the source-specific routing and the > ToS-specific routing Babel extensions. > > We want to profit of Juliusz' future editing of RFC 6126bis, and use new AE values: > Interpreting a source-specific (resp. ToS-specific) update message as a classic > update message by ignoring the source information (resp. ToS information) and > considering the update it announces as a classical update might cause routing loops. > That's why there's nothing a classical router should do with a source-specific > (resp. ToS-specific) update message. > Since RFC 6126 specifies that any TLV with an unknown AE must be ignored, we want > to use new AE values for source-specific and ToS-specific updates. > > > For example, we could use the following values: > > > o AE 5: Source-specific for IPV4 > o AE 6: Source-specific for IPV6 > > o AE 7: ToS-specific for IPV4 > o AE 8: ToS-specific for IPV6 > > > > They would use it in the 3 TLVs whose meaning is changed by the extensions: Update, Route Request > and Seqno Request. > > For Source-Specific Routing, TLVs would be (adding a source > prefix and its length): > > > UPDATE: > > 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 = 8 | Length | AE=6 | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Plen | Omitted | Interval | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Seqno | Metric | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source Plen | Prefix... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > | Source prefix... > +-+-+-+-+-+-+-+-+-+-+-+- > > > ROUTE REQUEST: > > 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 = 9 | Length | AE=6 | Plen | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source Plen | Prefix... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > | Source prefix... > +-+-+-+-+-+-+-+-+-+-+-+- > > > SEQNO REQUEST: > > 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 = 10 | Length | AE=6 | Plen | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Seqno | Hop Count | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Router-Id + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source Plen | Prefix... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > | Source prefix... > +-+-+-+-+-+-+-+-+-+-+-+- > > > For ToS-Specific Routing, TLVs would be (adding of a ToS field > right before the prefix): > > UPDATE: > > > 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 = 8 | Length | AE=8 | Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Plen | Omitted | Interval | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Seqno | Metric | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ToS | Prefix ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > ROUTE REQUEST: > > 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 = 9 | Length | AE=8 | Plen | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ToS | Prefix ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > SEQNO REQUEST: > > 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 = 10 | Length | AE=8 | Plen | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Seqno | Hop Count | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Router-Id + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ToS | Prefix ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The bit that worries me is what to do if we want to use > Source-and-ToS-specific routing (or the intersection with any > future extension that also uses a new AE)? > This choice suggests that we would need a new AE for any combination > of existing extensions (and any future extension must define those > new AE values, deciding which other extensions are compatible). > However, a whole octet looks enough to code all these possibilities. > > Could you please tell your thoughts on this? > > > > > > > > > > > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --Boundary_(ID_UOLFUL0touMr6RV3AnxHsQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi Gwendoline,

First of all, thanks for writing this up, this is = cool!
I believe there are use cases where this is = really useful.

While I really like the idea of using AE instead of new = TLVs,
I am slightly worried by the inability to = combine these.
As you discussed, one may want to = route based on both ToS and Source.

I think there's only one solution to = this problem, which would be to use
sub-TLVs = instead of AE, with a flag telling the receiver to ignore any = Update
containing unknown sub TLVs. Sadly this = feels overly complicated to me.

So, if we agree to burn a new AE for = each combination, which I think I can
live with, = then this proposals sounds great!

I think we may want to add text saying = that this is DiffServ routing,
you really want to = avoid routing differently based on the ECN bits
(we've seen that in the field, it triggers TCP PAWS and bad = things happen).

Thanks,
David


On Apr 13, 2017, at 08:55, = Gwendoline <yiyop@wanadoo.fr> wrote:

Dear = all,


I have just started = working with Juliusz, and I hope to design and implement a
ToS-specific routing extension for Babel, so that we have = another example of
Babel extension to decide if = rfc6126bis is neither too restrictive nor too
permissive = regarding extensions.


As = explained during the Chicago meeting, we think that the packet format =
for the source-specific routing extension for Babel, = implemented
by Matthieu, could be better (for now, it = consists of 3 new TLVs and they have
too many fields, see = slides 11-13 https://www.ietf.org/proceedings/98/slides/slides-98-babel-abou= t-some-babel-drafts-00.pdf )
We want to redefine TLVs = for the source-specific routing and the
ToS-specific = routing Babel extensions.

We want to profit = of Juliusz' future editing of RFC 6126bis, and use new AE values:
Interpreting a source-specific (resp. ToS-specific) update = message as a classic
update message by ignoring the source = information (resp. ToS information) and
considering the = update it announces as a classical update might cause routing loops.
That's why there's nothing a classical router should do with = a source-specific
(resp. ToS-specific) update message.
Since RFC 6126 specifies that any TLV with an unknown AE must = be ignored, we want
to use new AE values for = source-specific and ToS-specific updates.


For example, we could use the following = values:


   o  = AE 5: Source-specific for IPV4
   o  AE 6: = Source-specific for IPV6

   = o  AE 7: ToS-specific for IPV4
   o  = AE 8: ToS-specific for IPV6



They would use it in the 3 TLVs whose meaning = is changed by the extensions: Update, Route Request
and = Seqno Request.

For Source-Specific Routing, = TLVs would be (adding a source
prefix and its length):


UPDATE:

0          &n= bsp;        = 1            &= nbsp;      = 2            &= nbsp;      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 =3D 8    = |    Length     = |      AE=3D6     = |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
|      = Plen     |    = Omitted    = |            = Interval           = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
|          &n= bsp;  = Seqno           &nb= sp; = |             = Metric            = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
|  Source Plen  = |        Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|        Source = prefix...
+-+-+-+-+-+-+-+-+-+-+-+-


ROUTE REQUEST:

0          &n= bsp;        = 1            &= nbsp;      = 2            &= nbsp;      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 =3D 9    = |    Length     = |      AE=3D6     = |      Plen     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
|  Source Plen  = |        Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|        Source = prefix...
+-+-+-+-+-+-+-+-+-+-+-+-


SEQNO REQUEST:

0          &n= bsp;        = 1            &= nbsp;      = 2            &= nbsp;      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 =3D 10   = |    Length     = |      AE=3D6     = |      Plen     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
|          &n= bsp;  = Seqno           &nb= sp; |   Hop Count   |   = Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
|          &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;   |
+          &n= bsp;           &nbs= p;    = Router-Id           = ;            &= nbsp;   +
|          &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
|  Source Plen  = |        Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|        Source = prefix...
+-+-+-+-+-+-+-+-+-+-+-+-


For ToS-Specific Routing, TLVs would be = (adding of a ToS field
right before the prefix):

UPDATE:


0          &n= bsp;        = 1            &= nbsp;      = 2            &= nbsp;      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 =3D 8   = |    Length     = |      AE=3D8     = |    Flags      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
|     = Plen      |    = Omitted    = |            = Interval           = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
|          &n= bsp;  = Seqno           &nb= sp; |            = Metric           &n= bsp; |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
|      = ToS      |    Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


ROUTE REQUEST:

0          &n= bsp;        = 1            &= nbsp;      = 2            &= nbsp;      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 =3D 9   = |    Length     = |      AE=3D8     = |     Plen      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
|      = ToS      |    Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



SEQNO REQUEST:

0          &n= bsp;        = 1            &= nbsp;      = 2            &= nbsp;      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 =3D 10  = |    Length     = |      AE=3D8     = |    Plen       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
|          &n= bsp;  = Seqno           &nb= sp; |  Hop Count    |   = Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
|          &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;   |
+          &n= bsp;           &nbs= p;   = Router-Id           = ;            &= nbsp;    +
|          &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
|      = ToS      |    Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The bit that worries me is what to do if we = want to use
Source-and-ToS-specific routing (or the = intersection with any
future extension that also uses a = new AE)?
This choice suggests that we would need a new AE = for any combination
of existing extensions (and any future = extension must define those
new AE values, deciding which = other extensions are compatible).
However, a whole octet = looks enough to code all these possibilities.

Could you please tell your thoughts on this?









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

= --Boundary_(ID_UOLFUL0touMr6RV3AnxHsQ)-- From nobody Fri Apr 14 10:43:10 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 24CA41294F0 for ; Fri, 14 Apr 2017 10:43:09 -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, RCVD_IN_DNSWL_MED=-2.3, 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=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 0H28TDTKuMhu for ; Fri, 14 Apr 2017 10:43:07 -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 7584E1294F5 for ; Fri, 14 Apr 2017 10:43: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=1492191786; 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=R9LOiOeoSX2jIx2WP807Pb1CYKqkebk5dsdj1Hn6pvU=; b=LtCyUTyng+TUHnfZnaPBWjqpBHtcOQVj6+aZ4YeLcqeSUANlCmNFBL0kjJ4xKrmF rEMTT2oXIR3xkxlj4E3BraUMEJPt4trXo7Pow7Mx11/3bx5xJfZ3a3OGylLUxIOv n4hQaqsMdtruz4/aDU1fNCcrYINqdzWLZN30IKKdvONNUAhZ7fLjkTOL92etufKz 1ObTfO2ySqxUWmCH2Zq4P640Ds0H0rGkPFEYT+RL87O7YMwx1gLrlmite8AzUw16 Nx9+S7/7qC5GQ8lRYoc1V+KRue2Bduh5oOvpKOTJt+o8+JggOiteCqClfYVHH7TV DYIP2lA4k9CkKBrh1rIanA==; 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 81.BF.05645.A2A01F85; Fri, 14 Apr 2017 10:43:06 -0700 (PDT) X-AuditID: 11ab0216-be1fb9a00000160d-68-58f10a2a4a11 Received: from jimbu (jimbu.apple.com [17.151.62.37]) by relay8.apple.com (Apple SCV relay) with SMTP id 7D.E7.26253.A2A01F85; Fri, 14 Apr 2017 10:43:06 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.95.198] (unknown [17.153.95.198]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OOE0035QUJS3U60@jimbu.apple.com>; Fri, 14 Apr 2017 10:43:05 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <7i4lxsm9in.wl-jch@irif.fr> Date: Fri, 14 Apr 2017 10:43:01 -0700 Cc: Dave Taht , Babel at IETF Message-id: <0E559D8A-39B4-4354-8175-D9B2BA67DA37@apple.com> References: <7i8tn4mes9.wl-jch@irif.fr> <7i4lxsm9in.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUi2FCYpqvF9THC4HSfnsWWRd0sFns2nmSx mN+6jM2B2WPnrLvsHkuW/GTyWLzlLWMAcxSXTUpqTmZZapG+XQJXxpFfe9kK/rBUHFkzl72B sZGli5GTQ0LARGLO4S3sXYxcHEICa5kkXnfPZYJJTJxyiBUisYxR4t+qA8wgCV4BQYkfk+8B dXNwMAvISxw8LwsSZhbQkvj+qBVsqJDAf0aJwyuFQGxhAWmJrgt3WSFsdYmv/5+ygbSyAdUf WGMEEuYU0JBYtvE12HQWAVWJe9O7mSFGOkt8afrPBLHVRuJpxwo2iHN6GCW2720FS4gIqEgs n/aMHeJmWYlbsy8xgxRJCGxhk7h6aArTBEbhWUjOnoVw9iwkZy9gZF7FKJybmJmjm5lnZKSX WFCQk6qXnJ+7iREU7quZxHYw3ntteIhRgINRiYf3wvEPEUKsiWXFlbmHGKU5WJTEeVdMfRch JJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTF1+fnqR0uainWnH53fabg2S+ky44QT805/PifK 1t99S1jkqOwSvkLutJD/m1R1maLlmupYnonE85Y8NU/XWj3RIuQ6+2yeziD5lAqXL8onv3Vk 19zKm6/458SmcK6/E7K89Us96hf0b9u8e1pGwgmDMy0z1u249vnBrGoH5qikyY7eW8713lBi Kc5INNRiLipOBAA7IhAnWAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUiON1OVVeL62OEwe3/PBZbFnWzWOzZeJLF Yn7rMjYHZo+ds+6yeyxZ8pPJY/GWt4wBzFFcNimpOZllqUX6dglcGUd+7WUr+MNScWTNXPYG xkaWLkZODgkBE4mJUw6xdjFycQgJLGOU+LfqADNIgldAUOLH5HtARRwczALyEgfPy4KEmQW0 JL4/agXrFRL4zyhxeKUQiC0sIC3RdeEuK4StLvH1/1M2kFY2oPoDa4xAwpwCGhLLNr4Gm84i oCpxb3o3M8RIZ4kvTf+ZILbaSDztWMEGcU4Po8T2va1gCREBFYnl056xQ9wsK3Fr9iXmCYwC s5BcOgvh0llILl3AyLyKUaAoNSex0kIvsaAgJ1UvOT93EyMoOBsK03YwNi23OsQowMGoxMNb cfRDhBBrYllxZe4hRgkOZiUR3kn/gEK8KYmVValF+fFFpTmpxYcYq4AemMgsJZqcD4ycvJJ4 QxMTAxNjYzNjY3MTc6oIK4nz9u8G2iyQnliSmp2aWpBaBLOciYNTqoFxAtf8t7GdfRffKOgE v3ofU71zubTh28JTS5fycx55Lq3aLRVwif3h47vdJbL+M7Lc13kYcc8N6jdW//C3dD6/2iO5 7xMOPj+h4aNeMWmX0763j/5d8qxctnl/vT9Hf8t+YyfzfnaeFWG9n7/rbXI8t3/LKkfuvjYm t3f/tknzT7eqCs6PmvFTiaU4I9FQi7moOBEAbDnzoakCAAA= Archived-At: Subject: Re: [babel] rfc6126bis updates 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, 14 Apr 2017 17:43:09 -0000 Juliusz, I read the edits, and they look good to me. In the "Considerations for protocol extensions" section, we could say that adding AEs is another way to extend the protocol. Maybe that can wait until we rephrase how AEs work, such as compression being specific to an AE. David > On Apr 13, 2017, at 11:45, Juliusz Chroboczek wrote: > >> But it's hard to review a draft in progress if we don't know where it is. > > https://github.com/jech/babel-drafts > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Fri Apr 14 11:58: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 B5A3E12953D for ; Fri, 14 Apr 2017 11:58:50 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOls4hY3i4mR for ; Fri, 14 Apr 2017 11:58:49 -0700 (PDT) Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C533F129521 for ; Fri, 14 Apr 2017 11:58:48 -0700 (PDT) Received: from nemesis.taht.net (unknown [IPv6:2601:646:8501:df5:2e0:4cff:fec1:1206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id C1A8721B1C; Fri, 14 Apr 2017 18:58:45 +0000 (UTC) From: Dave Taht To: Juliusz Chroboczek Cc: babel@ietf.org References: <87o9vzfvsw.fsf@nemesis.taht.net> <7iy3v2x6to.wl-jch@irif.fr> Date: Fri, 14 Apr 2017 11:58:43 -0700 In-Reply-To: <7iy3v2x6to.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Fri, 14 Apr 2017 19:00:35 +0200") Message-ID: <87a87ig6jg.fsf@nemesis.taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] source and tos routing thoughts 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, 14 Apr 2017 18:58:51 -0000 Juliusz Chroboczek writes: >> B) What are your promotion/demotion rules for the TOS routed links? > > As far as I can tell at that early stage, any ordering would work. > Gwendoline and I have slightly different opinions here -- I'd like her to > do the simple thing first (TOS exact match, or use non-specific route), > while she'd like to do something more exciting. > >> a set of routing tables 256 times bigger that might prove troublesome. > > The idea is that just a small set of TOS are announced, the remainder > follow the non-specific route. See the use-case below. I do like the idea of solving for each best route for a different goal(s). ( https://github.com/dtaht/libv6/tree/master/clients/bellman-ford ) > >> C) Presently, in linux, you can set ecn capability on and off on a per >> route basis > > I'm not sure how that's related to routing. You are not seriously > suggesting that packets should be routed differently depending on the > value of the ECN bits? Me? Serious? *never*. :) The properties of a route announcement via babel are potentially different from the actual encoding of the packets on the wire. Here what you are proposing is a 1x2 (if you have a more specific tos, use that, otherwise, best effort)... in which case you don't need 256 values for it, 64, or 23. And that tos alone as a determination of what to do with a route doesn't seem like enough. actual example, from my case. BBR doesn't support ECN, and stuff going out my default gateway gets initcwnd cut, and another portion of the network uses dctcp and ecn. root@nemesis:~# ip route default via 172.22.232.1 dev enp2s0 proto babel initcwnd 2 features congctl bbr ... 172.22.148.0/22 via 172.22.232.154 dev enp2s0 proto babel rtt 1ms features ecn congctl dctcp ... > >> So while "tos" can be represented, what are the use cases for it? > > The main use case is due to Nexedi. They're considering a network with > multiple edge links, some of which have low latency and jitter but are > expensive (MPLS leased lines, most probably), some of which are cheap but > jittery (tunnels over the public Internet). They want voice traffic to > flow over the expensive links, and data traffic to use the cheap ones. > They're not using source-specific routing in their network, and they only > really care about IPv6, which makes the problem somewhat more tractable. Recently (4.11) much progress was made towards disambiguating tunneled voice and bulk traffic through fq_codel'd bottleneck backhaul links. The behavior before, included 100+ms of induced latency and jitter: http://www.taht.net/~d/ipsec_fq_codel/oldqos.png The behavior afterwards, was 2ms: http://www.taht.net/~d/ipsec_fq_codel/newqos.png We haven't added this feature to sch_cake, per se, as that does also already respect the dscp bits with similar results. Still, this strikes me as a good addition to the network and lessens the need to do much with "tos as tos" in the routing protocol. I know, of course, that convincing the world to just run fq_codel on everything is something of an uphill battle, my meta-point is merely that if you wish to solve for two different goals (high bandwidth vs low latency), and then express that in the routing protocol, that it doesn't need to be a direct representation of the tos bits. You'd express "this bit represents a low latency, expensive, low bandwidth route", and then map a selection of tos bits on top of it to go out that way. > -- Juliusz From nobody Fri Apr 14 16:12: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 83A07129A96 for ; Fri, 14 Apr 2017 16:12:18 -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 9svoV7P9LDCT for ; Fri, 14 Apr 2017 16:12: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 88CC9128616 for ; Fri, 14 Apr 2017 16:12:16 -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 v3ENCEBQ004008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 15 Apr 2017 01:12:14 +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 v3ENCElV021466; Sat, 15 Apr 2017 01:12:14 +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 21A4CD7924; Sat, 15 Apr 2017 01:12:14 +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 3EZu5vNQEE4b; Sat, 15 Apr 2017 01:12:13 +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 CD16AD7891; Sat, 15 Apr 2017 01:12:12 +0200 (CEST) Date: Sat, 15 Apr 2017 01:12:18 +0200 Message-ID: <87shlazir1.wl-jch@irif.fr> From: Juliusz Chroboczek To: Dave Taht Cc: babel@ietf.org In-Reply-To: <87a87ig6jg.fsf@nemesis.taht.net> References: <87o9vzfvsw.fsf@nemesis.taht.net> <7iy3v2x6to.wl-jch@irif.fr> <87a87ig6jg.fsf@nemesis.taht.net> 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, 15 Apr 2017 01:12:14 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 15 Apr 2017 01:12:14 +0200 (CEST) X-Miltered: at korolev with ID 58F1574E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58F1574E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F1574E.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58F1574E.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 : 58F1574E.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58F1574E.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] source and tos routing thoughts 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, 14 Apr 2017 23:12:18 -0000 > Recently (4.11) much progress was made towards disambiguating tunneled > voice and bulk traffic through fq_codel'd bottleneck backhaul links. Dave, you must distinguish queueing/forwarding from routing. Routing is about deciding where a packet is sent; forwarding is about actually sending it that way, which might involve queueing. Gwendoline's work is about TOS-sensitive *routing*, and is completely orthogonal to the queueing policy. Let me be even more specific. Gwendoline's work is about using the ToS octet as part of the decision where to send a given packet. Once Gwendoline has decided where the packet goes, then your favourite AQM kicks in to forward the packet -- but that's none of Gwendoline's business. -- Juliusz From nobody Fri Apr 14 16:37:58 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 A856B12702E for ; Fri, 14 Apr 2017 16:37: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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-SspZOCrRPY for ; Fri, 14 Apr 2017 16:37:54 -0700 (PDT) Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1492126DC2 for ; Fri, 14 Apr 2017 16:37:54 -0700 (PDT) Received: from nemesis.taht.net (unknown [IPv6:2601:646:8501:df5:2e0:4cff:fec1:1206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id C354C22283; Fri, 14 Apr 2017 23:37:52 +0000 (UTC) From: Dave Taht To: Juliusz Chroboczek Cc: babel@ietf.org References: <87o9vzfvsw.fsf@nemesis.taht.net> <7iy3v2x6to.wl-jch@irif.fr> <87a87ig6jg.fsf@nemesis.taht.net> <87shlazir1.wl-jch@irif.fr> Date: Fri, 14 Apr 2017 16:37:51 -0700 In-Reply-To: <87shlazir1.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Sat, 15 Apr 2017 01:12:18 +0200") Message-ID: <87fuhah86o.fsf@nemesis.taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] source and tos routing thoughts 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, 14 Apr 2017 23:37:56 -0000 Juliusz Chroboczek writes: >> Recently (4.11) much progress was made towards disambiguating >> tunneled >> voice and bulk traffic through fq_codel'd bottleneck backhaul links. > > Dave, you must distinguish queueing/forwarding from routing. Routing > is > about deciding where a packet is sent; forwarding is about actually > sending it that way, which might involve queueing. Gwendoline's work I certainly do distinguish between the two, I was pointing out the demand for this use case sprung from a choice of route types caused (in part) by bad queuing. To me this factors into a different way to calculate the metric (optimizing for jitter and latency for a given route) and to come up with a "best route" for that. rather than into any direct tos representation. > is > about TOS-sensitive *routing*, and is completely orthogonal to the > queueing policy. > > Let me be even more specific. Gwendoline's work is about using the > ToS > octet as part of the decision where to send a given packet. Once > Gwendoline has decided where the packet goes, then your favourite AQM > kicks in to forward the packet -- but that's none of Gwendoline's > business. Well, for the stated use case of optimizing for voice traffic, "VA" - voice admit, and EF - are two of the most common markings. I've also seen CS2, CS3 (sip), CS4, CS5 (originally intended for video), CS6, and desparate folk, even trying CS7. Google has put "goog" congestion control into their webrtc, which uses AF41 for both voice and video on the same tuple. There is a working group, stalled out on something even more complex: https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-18 So a single dcsp value, carried by the routing protocol, cannot cover the stated use case, except in limited, highly controlled circumstances. Perhaps shipping a list of tos values per that route? Or, as I was suggesting, using up a bit (somewhere) as a tag saying, please use this for voice traffic. and then the daemon would insert appropriate routes based on all the needed dscp values. see also https://datatracker.ietf.org/doc/rfc7657/?include_text=1 https://en.wikipedia.org/wiki/Differentiated_services About the only dscp value I like is CS1, which means background, except where it doesn't. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Fri Apr 14 17:50: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 04B2E1294B9 for ; Fri, 14 Apr 2017 17:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.433 X-Spam-Level: * X-Spam-Status: No, score=1.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 K6rezW2CIAAb for ; Fri, 14 Apr 2017 17:50:04 -0700 (PDT) Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 405F6124234 for ; Fri, 14 Apr 2017 17:50:04 -0700 (PDT) Received: from nemesis.taht.net (unknown [IPv6:2601:646:8501:df5:2e0:4cff:fec1:1206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 4CD3B221EC for ; Sat, 15 Apr 2017 00:50:02 +0000 (UTC) From: Dave Taht To: babel@ietf.org Date: Fri, 14 Apr 2017 17:50:00 -0700 Message-ID: <87bmryh4uf.fsf@nemesis.taht.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [babel] AEs 5 & 6 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, 15 Apr 2017 00:50:05 -0000 I am hoping the wg is agreeable to proposed AEs 5 and 6, which replace the existing need for the source specific routing tlvs? (does silence mean assent?) (I am) (well, what does a plen of 0 or > 128 mean? Could > 128 mean something?) I'd like to start coding those up, unless someone has already beat me to it. From nobody Fri Apr 14 17:58:02 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 426D5126CC7 for ; Fri, 14 Apr 2017 17:58:01 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cf8JzcZKhjU1 for ; Fri, 14 Apr 2017 17:58:00 -0700 (PDT) Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C1B124234 for ; Fri, 14 Apr 2017 17:57:59 -0700 (PDT) Received: from nemesis.taht.net (unknown [IPv6:2601:646:8501:df5:2e0:4cff:fec1:1206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 7B2F0221EC for ; Sat, 15 Apr 2017 00:57:58 +0000 (UTC) From: Dave Taht To: babel@ietf.org Date: Fri, 14 Apr 2017 17:57:57 -0700 Message-ID: <8760i6h4h6.fsf@nemesis.taht.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [babel] A babel service code 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, 15 Apr 2017 00:58:01 -0000 As I've tried to demonstrate in the earlier thread, I think a simple direct map of a babel "TOS" to the DSCP tos is hopeless, as far more than one dscp field is in common use, and different ones are used at the same time for signalling and for data. So.... as for AEs 7, 8, which include the "Tos" field: Here's a semi-concrete counter proposal: A) Map those 8 extra bits into something more abstract and useful than TOS, call it a "BST" - babel service tag, which has bits defined for voice, video, and whatnot, which then get mapped down to the appropriate set of dscp-enabled services. or: B) Drop the notion of specific AE numbers including a "TOS" or "BST", and add a TLV with the notion of a "tag" or "label" describing the desired and/or available service characteristics on that route. Of the two, I prefer B. And I'd imagine that generally it would only be used on a very few gateways advertising specific services, and thus propagated minimally through the protocol. Either way, one code would then map to as many actual tos values in the routing table as needed. (... or make suitable modifications to how a given metric is calculated which is a bit fuzzier to me at the moment than I'd like ) Either way that "tag" seems to be a bunch of bits more expressive than just tos. ... In either case, there is a problem in defining the "fallback" characteristics against a given "tag". Where you distinguish between "use this route for voice", and "this for data", and the data route is down, you can't get enough dns/webrtc/whathaveyou to initiate the connection, in the first place. So I think a soft preference, rather than hard, for the best route, is needed. However there may be circumstances where "All lines are busy now", is an appropriate response, that rather than provide bad service over a busy link. And thus I do not define the format of that new sub-tlv "tag" today. ... PS https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-01 may also be of interest. the vlan priority field is arguably more often used than dscp values and can be considered part of a packet as much, or - actually - far more, than the dscp field, these days. Most switches, for example, respect the vlan priority field, out of the box, and have to be configured specially to respect dscp. Presently, within modern networks, you will see often see voice configured on it's own high priority vlan. /me dons flame retardant clothing From nobody Fri Apr 14 18:19: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 5BEFE129B34 for ; Fri, 14 Apr 2017 18:19:38 -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 BLdySUbZJZDB for ; Fri, 14 Apr 2017 18:19:36 -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 6CC8C129B30 for ; Fri, 14 Apr 2017 18:19:36 -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 v3F1JYYv018573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 15 Apr 2017 03:19: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 v3F1JYZj001236; Sat, 15 Apr 2017 03:19: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 A6A6DD798C; Sat, 15 Apr 2017 03:19:34 +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 Eu-Gg2nIkio0; Sat, 15 Apr 2017 03:19:33 +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 48BC7D79B3; Sat, 15 Apr 2017 03:19:33 +0200 (CEST) Date: Sat, 15 Apr 2017 03:19:38 +0200 Message-ID: <87lgr2zcut.wl-jch@irif.fr> From: Juliusz Chroboczek To: Dave Taht Cc: babel@ietf.org In-Reply-To: <87bmryh4uf.fsf@nemesis.taht.net> References: <87bmryh4uf.fsf@nemesis.taht.net> 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, 15 Apr 2017 03:19:34 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 15 Apr 2017 03:19:34 +0200 (CEST) X-Miltered: at korolev with ID 58F17526.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58F17526.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F17526.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58F17526.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 : 58F17526.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58F17526.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] AEs 5 & 6 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, 15 Apr 2017 01:19:38 -0000 > I am hoping the wg is agreeable to proposed AEs 5 and 6, which replace > the existing need for the source specific routing tlvs? I think that should be 4 and 5 -- Gwendoline, I don't remember -- was there a reason to skip 4? As to registering these values, I think I f*cked up in RFC 7557 -- I didn't ask for the creation of an AE registry: https://tools.ietf.org/html/rfc7557#section-5 The friendly chairs will correct me if I'm wrong, but it is my understanding that what the WG can decide is to create an AE registry. Once the AE registry is created, we can allocate the relevant AEs according to the proposed policy. Question to the WG -- are we agreed on a policy of Specification Needed? Note that this implies that we cannot register 4 through 7 until Matthieu and Gwendoline publish they respective drafts -- Specification Needed implies we need a specification. (I support Specification Needed, which is consistent with the other Babel registries.) Question to Donald and Russ -- is this mail enough to establish the registry, is it enough to put it in an Internet-Draft, or do we need to wait for rfc6126bis to be published? As to implementations -- the proper thing to do would be to use the Experimental range. However, since most of the Babel development community is present on this list, I wouldn't be opposed to using the unregistered values for now, as long as we are agreed that we might change them if something happens before registration. Okay, so let's put that into RFC-ese (I'm getting good at that, which I find worrying): IANA Considerations ******************* IANA is instructed to create a new registry, called "Babel Address Encodings (AEs)". The allocation policy for this registry is Specification Required [RFC5226]. The initial values in the Babel Address Encodings are as follows: +---------+-----------------------------------------+---------------+ | Type | Name | Reference | +---------+-----------------------------------------+---------------+ | 0 | Wildcard | [RFC6126] | | | | | | 1 | IPv4 | [RFC6126] | | | | | | 2 | IPv6 | [RFC6126] | | | | | | 3 | Link-local IPv6 address | [RFC6126] | | | | | | 224-254 | Reserved for Experimental Use | this document | | | | | | 255 | Reserved for expansion of the AE space | this document | +---------+-----------------------------------------+---------------+ The following values MIGHT or MIGHT NOT be registered when the relevant documents get published: +---------+-----------------------------------------+---------------+ | Type | Name | Reference | +---------+-----------------------------------------+---------------+ | 4 | Source-specific IPv4 | [Boutier] | | | | | | 5 | Source-specific IPv6 | [Boutier] | | | | | | 6 | TOS-sensitive IPv4 | [Chouasne] | | | | | | 7 | TOS-sensitive IPv6 | [Chouasne] | +---------+-----------------------------------------+---------------+ (We need to update RFC 2119 with MIGHT, MIGHT NOT and IF SOMEBODY CARES ENOUGH.) -- Juliusz From nobody Sat Apr 15 17:52: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 281FF1270FC for ; Sat, 15 Apr 2017 17:52:45 -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 kgZlUyBVOMlh for ; Sat, 15 Apr 2017 17:52:43 -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 B39FF1274D2 for ; Sat, 15 Apr 2017 17:52:42 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v3G0qeZl002050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 16 Apr 2017 02:52:40 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id v3G0qeqQ028848 for ; Sun, 16 Apr 2017 02:52: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 41217D79B3 for ; Sun, 16 Apr 2017 02:52: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 u8QUNEwfEc71 for ; Sun, 16 Apr 2017 02:52:39 +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 252BED79B2 for ; Sun, 16 Apr 2017 02:52:38 +0200 (CEST) Date: Sun, 16 Apr 2017 02:52:43 +0200 Message-ID: <87pogduqas.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]); Sun, 16 Apr 2017 02:52:40 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 16 Apr 2017 02:52:40 +0200 (CEST) X-Miltered: at korolev with ID 58F2C058.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58F2C058.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F2C058.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58F2C058.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 : 58F2C058.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58F2C058.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] About mandatory bits 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, 16 Apr 2017 00:52:45 -0000 Dear all, As some of you have hinted (more or less rudely), there is an alternative to the AE-based encoding of source-specific and TOS-sensitive routes that I suggested: adding a mandatory bit to sub-TLVs. The mandatory bit has a number of advantages, and a number of cons when compared to the multiplication of AEs. Here are my thoughts on the subject -- I'm very much interested in your opinions. Encoding ******** The mandatory bit could be encoded as the top-order bit of the sub-TLV type octet. The sub-TLV format would then become: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- This reduces the sub-TLV type space, but that is not a problem since the type space is extensible -- if we run out of sub-TLV numbers, 16-bit TLVs can be encoded in a backwards compatible manner as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| 127 | Length + 2 | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+- Semantics ********* Mandatory and non-mandatory sub-TLVs are allocated separately -- mandatory sub-TLV 2 does not necessarily have any relation with non-mandatory sub-TLV 2. An implementation MUST parse all the sub-TLVs of any TLV it does not ignore, and if a TLV contains an unknown mandatory sub-TLV, then the whole TLV MUST be silently ignored. There's an implementation cost here: every implementation, even if it doesn't do any extensions, MUST learn to parse all sub-TLVs, and to drop TLVs that contain unknown mandatory sub-TLVs. Compatibility ************* No existing extensions are broken by mandatory bits: since all currently defined sub-TLVs have small type numbers, they appear as non-mandatory sub-TLVs, which preserves their semantics. On the other hand, mandatory sub-TLVs stretch the weak compatibility that we decided on in London. Legacy implementations will get confused by mandatory TLVs, treating them as non-mandatory, and, by mis-interpreting updates with mandatory TLVs, might create routing loops. I am not sure whether this is acceptable at that stage. Encoding of exciging extensions ******************************* Mandatory bits allow a very simple encoding of both source-specific and TOS-specific updates: a source-specific update is just a normal update with a mandatory source-prefix sub-TLV, while a TOS-specific update just carries a mandatory TOS sub-TLV. The extensions combine easily -- just put both mandatory sub-TLVs. Cost for implementations ************************ All implementations -- even minimal ones such as sbabeld or pybabel -- MUST learn to parse sub-TLVs in order to detect mandatory ones. This is an implementation cost, but one that only applies to minimal implementations, since full-fledged implementations most likely already know how to parse sub-TLVs. This implementation cost is not outrageous -- we're speaking of a dozen lines of C code or so. Other applications ****************** The Italian mesh communities have requested the ability to tag routes with opaque tags. They want to be able to filter routes without configuring each router with a list of prefixes, e.g. to have all Roman routers originate routes with a "Roma" tag, and just configure non-Roman routers to filter out the Roman routes. Mandatory bits encode this easily. Mandatory bits on Hello TLVs prevent associating with routers that don't implement a given extension. This allows an easy way to perform feature negotiation, with no new mechanism. Cultural compatibility ********************** Mandatory bits are familiar from BGP and OSPF. That puts people at ease. Elegance ******** Elegance is in the eye of the beholder, but to my eyes mandatory sub-TLVs are more elegant than the multiplication of AEs. Conclusion ********** Unless I'm missing something, mandatory bits are a simple, elegant and powerful mechanism that fits well in Babel. However, they silently break compatibility in a manner that might or might not be unacceptable to our user base. Opinions? -- Juliusz From nobody Sun Apr 16 04:42: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 08E05124D6C for ; Sun, 16 Apr 2017 04:42:00 -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 3vViHUExlaRd for ; Sun, 16 Apr 2017 04:41:58 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (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 498A0126E3A for ; Sun, 16 Apr 2017 04:41:51 -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=1492342908; bh=R59qZdiGs7TLPM7pBu3zMJiTv7PaH9uXiFYjHnvtzA4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=cFZb2XlqrWpkE7O+Nst8AhwslEx3SnanpuM6wUnuva9Zf5jpZWmWWGbIEa+JV1ulj xyyRVzO4fXsGiyRd8Sh1Imd9mRcBtPSCIOuW98vaVYwZkNDwCL8A0jbrfptwJfaJd8 Ic/lxTqmwAspBpXRTB5XypeKdonDiaMCvUBzMnFdj3nG0wptFgEeVmxJW2z0Tm0t4B /4UwLeVzrFUPGfy388uUE8YOhXSenjMydcF2SPfR91exiWb/MRmgBUam3amSTzp5P+ R5rPPnR/lhlXQVf3obDk5lnvrubS/30LYXY8dwgRXi7j031JK3v2Kdm0KpSPlKUYIi 4BOJiyWgAhwRw== To: Juliusz Chroboczek Cc: babel@ietf.org References: <87pogduqas.wl-jch@irif.fr> Date: Sun, 16 Apr 2017 13:41:45 +0200 In-Reply-To: <87pogduqas.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Sun, 16 Apr 2017 02:52:43 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87pogcmveu.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] About mandatory bits 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, 16 Apr 2017 11:42:00 -0000 Juliusz Chroboczek writes: > As some of you have hinted (more or less rudely), there is an > alternative to the AE-based encoding of source-specific and > TOS-sensitive routes that I suggested: adding a mandatory bit to > sub-TLVs. The mandatory bit has a number of advantages, and a number > of cons when compared to the multiplication of AEs. Here are my > thoughts on the subject -- I'm very much interested in your opinions. I like the fact that it can save us from combinatorial explosion. As far as a flag day is concerned, that is probably going to be necessary in many cases, since people running babeld using the source-specific extension are still going to experience incompatibility (I know that's the case for my network). And, well, if we are going to introduce backwards-incompatible changes for the good of the future of the protocol, now would be the time. To me, the greatest drawback of this approach is that it raises the bar for the minimum viable implementation. The current spec is dead simple in this regard, and this would obviously change that, as you remark. However, I would probably lean towards this cost being worth it... > Semantics > ********* > > Mandatory and non-mandatory sub-TLVs are allocated separately -- mandatory > sub-TLV 2 does not necessarily have any relation with non-mandatory > sub-TLV 2. Is this just to save on sub-TLV numbers? Because I would think it is bound to create confusion, which is probably not worth the few numbers we could save on it. -Toke From nobody Sun Apr 16 10:45: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 600D71270AC for ; Sun, 16 Apr 2017 10:45:44 -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 PlP76bQYdDBx for ; Sun, 16 Apr 2017 10:45: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 401C6126C22 for ; Sun, 16 Apr 2017 10:45:42 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v3GHjb79022795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 16 Apr 2017 19:45: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 v3GHjaY3010698; Sun, 16 Apr 2017 19:45: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 A419BD798C; Sun, 16 Apr 2017 19:45: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 YOaWjU3thBO0; Sun, 16 Apr 2017 19:45: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 AA0D4D79D7; Sun, 16 Apr 2017 19:45:34 +0200 (CEST) Date: Sun, 16 Apr 2017 19:45:40 +0200 Message-ID: <878tn01c1n.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: babel@ietf.org In-Reply-To: <87pogcmveu.fsf@alrua-x1> References: <87pogduqas.wl-jch@irif.fr> <87pogcmveu.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]); Sun, 16 Apr 2017 19:45:40 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 16 Apr 2017 19:45:37 +0200 (CEST) X-Miltered: at korolev with ID 58F3ADC1.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58F3ADC0.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F3ADC1.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58F3ADC0.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 : 58F3ADC1.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58F3ADC0.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] About mandatory bits 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, 16 Apr 2017 17:45:44 -0000 So I take it that you prefer mandatory bits to new AEs? Markus, Margaret, David, I'd really like to hear your respective opinions. > As far as a flag day is concerned, that is probably going to be > necessary in many cases, since people running babeld using the > source-specific extension are still going to experience incompatibility > (I know that's the case for my network). Plan is: babeld-1.9: sends the old format, parses both; babeld-2.0: sends the new format. > And, well, if we are going to introduce backwards-incompatible changes > for the good of the future of the protocol, now would be the time. Probably. > To me, the greatest drawback of this approach is that it raises the bar > for the minimum viable implementation. The current spec is dead simple > in this regard, and this would obviously change that, as you remark. > However, I would probably lean towards this cost being worth it... I'll add sub-TLV parsing to sbabeld, see how much it bloats the code. Does your implementation parse sub-TLVs? >> Semantics >> ********* >> >> Mandatory and non-mandatory sub-TLVs are allocated separately -- mandatory >> sub-TLV 2 does not necessarily have any relation with non-mandatory >> sub-TLV 2. > Is this just to save on sub-TLV numbers? Yes. > Because I would think it is bound to create confusion, which is probably > not worth the few numbers we could save on it. Noted. I think this needs more discussion. -- Juliusz From nobody Sun Apr 16 11:47:38 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 9D0B912422F for ; Sun, 16 Apr 2017 11:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bSQvAGgj_Zqb for ; Sun, 16 Apr 2017 11:47:35 -0700 (PDT) Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672F6120046 for ; Sun, 16 Apr 2017 11:47:35 -0700 (PDT) Received: from nemesis.taht.net (unknown [IPv6:2601:646:8501:df5:2e0:4cff:fec1:1206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 4B50321438; Sun, 16 Apr 2017 18:47:29 +0000 (UTC) From: Dave Taht To: Juliusz Chroboczek Cc: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= , babel@ietf.org References: <87pogduqas.wl-jch@irif.fr> <87pogcmveu.fsf@alrua-x1> <878tn01c1n.wl-jch@irif.fr> Date: Sun, 16 Apr 2017 11:47:28 -0700 In-Reply-To: <878tn01c1n.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Sun, 16 Apr 2017 19:45:40 +0200") Message-ID: <87a87gjikf.fsf@nemesis.taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] About mandatory bits 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, 16 Apr 2017 18:47:37 -0000 Juliusz Chroboczek writes: > So I take it that you prefer mandatory bits to new AEs? I preferred an AE that was unambigious - so AEs 4 and 5 for source specific seemed ok. > Markus, Margaret, David, I'd really like to hear your respective > opinions. I'm going to assume you mean apple's "david", as I am "dave". >> Because I would think it is bound to create confusion, which is >> probably not worth the few numbers we could save on it. > > Noted. I think this needs more discussion. As you noted (and I was unaware of), the italian communities wanted something similar to BGP, however I do not know how "tagging everything with a Roma tag would work". (?) Are there other latent requests out there? BGP in particular is chock full of features that have ended up in it over time, some proven useful by the test of time, others, not. I would certainly like to draw inspiration from the good things in bgp and other routing protocols, while still keeping things simple, robust, and well defined. From nobody Mon Apr 17 09:53: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 01264131670 for ; Mon, 17 Apr 2017 09:53:47 -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 ZgqHidSMxfxx for ; Mon, 17 Apr 2017 09:53:44 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (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 A115313166F for ; Mon, 17 Apr 2017 09:53:37 -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=1492448014; bh=DxLBo668T6f5UtKtXucvxd76zlTZ2hUOY11SDFfrZIM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=WCD9NaRu4olQrtUocvdlJK7RJttf6ehSRZwGvIiwxRniiIagNhrndpCqv5qYwIMkw PZs7I1QOOwLTcbXQnvxX71Ymhmi6qI/1TV+4eflqrU+B50n/rcuT41AYZSBRmeziTX iCxApmsavRDeoB1Lu1nBnSevHPWjLwefFMceLMMmJKPTGm02SHTC1CC3NDwOL3eKCZ 4w9vk+2UHEt70J/trP81lwwCI2X/7Vj7LB5lI+tPZlf4/37nRw/hBZQ9qR25D2xC3Z LghSABBjVP+o/bwdL3fv1UGK2DkAMx+Ouq42YQ6nTfyIdz8+ukMc78uIkZ2g7KTck0 sn2jR/UZEE78Q== To: Juliusz Chroboczek Cc: babel@ietf.org References: <87pogduqas.wl-jch@irif.fr> <87pogcmveu.fsf@alrua-x1> <878tn01c1n.wl-jch@irif.fr> Date: Mon, 17 Apr 2017 18:53:30 +0200 In-Reply-To: <878tn01c1n.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Sun, 16 Apr 2017 19:45:40 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87wpaj3rhx.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] About mandatory bits 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, 17 Apr 2017 16:53:47 -0000 Juliusz Chroboczek writes: > So I take it that you prefer mandatory bits to new AEs? Well, if we are just talking about source specific routing, I think I like the separate AE numbers better. That fits well with what my mental model of a source-specific route is. However, I can see your point that there could be other uses for mandatory sub-TLVs, so introducing those is probably a good idea in any case. >> As far as a flag day is concerned, that is probably going to be >> necessary in many cases, since people running babeld using the >> source-specific extension are still going to experience incompatibility >> (I know that's the case for my network). > > Plan is: > > babeld-1.9: sends the old format, parses both; > babeld-2.0: sends the new format. What about making it configurable in 1.9 and just change the default for 2.0? >> To me, the greatest drawback of this approach is that it raises the bar >> for the minimum viable implementation. The current spec is dead simple >> in this regard, and this would obviously change that, as you remark. >> However, I would probably lean towards this cost being worth it... > > I'll add sub-TLV parsing to sbabeld, see how much it bloats the code. > Does your implementation parse sub-TLVs? No, Babel in Bird 1.6 will be left confused by the introduction of mandatory sub-TLVs. When I do actually get around to implementing source-specific routing I'm planning to just do whatever encoding we end up agreeing on, obviously... -Toke From nobody Mon Apr 17 10:13:08 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 287A01316B4 for ; Mon, 17 Apr 2017 10:13:07 -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, RCVD_IN_DNSWL_MED=-2.3, 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=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 JbDWpBvOGgzz for ; Mon, 17 Apr 2017 10:13:05 -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 8A1D113169A for ; Mon, 17 Apr 2017 10:12: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=1492449177; 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=qU21zmFqIIdjaoaR/JI7YhcUPc+SgDHnDieko5BLe/k=; b=RoARbZVxeg2L1OcGSGjcs67CW7yZiWUVZjQWzDjQySb71IQJRYne3dQITn/Qbgy0 Bhl6Y+uuccpSCPhPL+8sidcP4QtBa/shZ8dupx6lj4+L4ZH+v/8W6rKJK+skfNT1 GBbXXKUFqPtOanaLUDNKrnWSgC7Wj/eH+KqHleGb4j0aejx6hmrE8Rzr5ue0QD6p k8Ww/gXCQJHhClTszAP58q1UY8KCBnm4kHQZiqUEEVQvkal9R48V5ErWyISdipTK noGno+2Zb+pU5A0F8K5JGmTe9vaAPDp2TqjlAvIWh400c3a8IJkJB4E89bWnCVv5 oSs5u7gDoobxtDD63y0qdQ==; 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-in2.apple.com (Apple Secure Mail Relay) with SMTP id D9.0E.27293.997F4F85; Mon, 17 Apr 2017 10:12:57 -0700 (PDT) X-AuditID: 11973e11-a39e49a000006a9d-fd-58f4f7994699 Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay2.apple.com (Apple SCV relay) with SMTP id F5.AE.22324.897F4F85; Mon, 17 Apr 2017 10:12:57 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_/Vv24X4T0WyBIKEeMGDf1g)" Received: from [17.153.22.28] (unknown [17.153.22.28]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OOK00LM2D59DH00@nwk-phonehomebzp-sz01.apple.com>; Mon, 17 Apr 2017 10:12:56 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Mon, 17 Apr 2017 10:12:37 -0700 In-reply-to: <87lgr2zcut.wl-jch@irif.fr> Cc: Dave Taht , babel@ietf.org To: Juliusz Chroboczek References: <87bmryh4uf.fsf@nemesis.taht.net> <87lgr2zcut.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUi2FDorDvz+5cIg+YWIYsti7pZLJqXNrJZ zG9dxubA7LFkyU8mj8Vb3jJ6fFo8ky2AOYrLJiU1J7MstUjfLoEr4/fBjewFG5sYK27cf8DY wHgit4uRk0NCwERiyo55jF2MXBxCAquZJDp6vjDBJJbuWcQOkTjGKLF44g8WkASvgKDEj8n3 gGwODmaBMImlm4wgauYzSSy4OokVpEZYQFqi68JdVpAaNgEtiQNrjCBabSRWP2xhgyiRk3j+ 8BbYLhYBVYnpfx4zgticAhoS29edZAexmQV0JfZ97AdbKyKgIrF82jN2kJFCAp4S23Z5Qpwp K3Fr9iVmkBMkBK6zSUxfco11AqPQLCSXzkK4dBbYVC2J749aocLyEgfPy0KENSWe3fvEDmFr Szx5d4F1ASPbKkah3MTMHN3MPCO9xIKCnFS95PzcTYyg2JhuJ7iD8fgqq0OMAhyMSjy8DAe/ RAixJpYVV+YeYpTmYFES55Vb+TlCSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2Ou4XbHVTmc IR8iNqSvDznrkHD0Q8WMM2/u/TY5dPVbbPz+5iZO/XXv9t/YP980JSNW4erNDXk9F94IJ/R5 nqpfcbmuq3Fd8psF7Ae2N2p/fylhfO8nh4CpaUu33npL/9I9LNd8KqJZbqr3TRDiC5qlvWbm 7aaJHXpKJVf2Pn+0/rxReeytZH4lluKMREMt5qLiRACUOpR/bgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKIsWRmVeSWpSXmKPExsUiON3OQXfm9y8RBr9uc1lsWdTNYtG8tJHN Yn7rMjYHZo8lS34yeSze8pbR49PimWwBzFFcNimpOZllqUX6dglcGb8PbmQv2NjEWHHj/gPG BsYTuV2MnBwSAiYSS/csYu9i5OIQEjjGKLF44g8WkASvgKDEj8n3gGwODmaBMImlm4wgauYz SSy4OokVpEZYQFqi68JdVpAaNgEtiQNrjCBabSRWP2xhgyiRk3j+8BYTiM0ioCox/c9jRhCb U0BDYvu6k+wgNrOArsS+j/1ga0UEVCSWT3vGDjJSSMBTYtsuT4gzZSVuzb7EPIGRfxaS42Yh HDcLbJCWxPdHrVBheYmD52UhwpoSz+59YoewtSWevLvAuoCRbRWjQFFqTmKlkV5iQUFOql5y fu4mRlAoNxQ672A8tszqEKMAB6MSDy/DwS8RQqyJZcWVuYcYJTiYlUR4jz4BCvGmJFZWpRbl xxeV5qQWH2KcyAj04kRmKdHkfGCk5ZXEG5qYGJgYG5sZG5ubmNNSWEmctyUd6CKB9MSS1OzU 1ILUIpijmDg4pRoYJz2XuS2leDTqlIH0cpU4i3Px73x+dIfUmBfYVFp33FTnX3L1tEzXAhNu 0+1dtvF5a6X0Tk0UFqr/uvb497eLSnqkfDu8jTgkAo5bFlk0uE15k2YwMeKb7uule+IeHW6f 9XhC5bJvtbGnLCvXnHHL31cto/o3iE/o2+s7M8Mc16/8FdDh8NNFiaU4I9FQi7moOBEAiEVG 7tgCAAA= Archived-At: Subject: Re: [babel] AEs 5 & 6 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, 17 Apr 2017 17:13:07 -0000 --Boundary_(ID_/Vv24X4T0WyBIKEeMGDf1g) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT I'm in favor of an IANA registry of registration procedure "Specification Required", especially since you only need to publish a draft to assign a value, not necessarily an RFC. That would match the existing registries: https://www.iana.org/assignments/babel/babel.xhtml David > On Apr 14, 2017, at 18:19, Juliusz Chroboczek wrote: > >> I am hoping the wg is agreeable to proposed AEs 5 and 6, which replace >> the existing need for the source specific routing tlvs? > > I think that should be 4 and 5 -- Gwendoline, I don't remember -- was > there a reason to skip 4? > > As to registering these values, I think I f*cked up in RFC 7557 -- > I didn't ask for the creation of an AE registry: > > https://tools.ietf.org/html/rfc7557#section-5 > > The friendly chairs will correct me if I'm wrong, but it is my > understanding that what the WG can decide is to create an AE registry. > Once the AE registry is created, we can allocate the relevant AEs > according to the proposed policy. > > Question to the WG -- are we agreed on a policy of Specification Needed? > Note that this implies that we cannot register 4 through 7 until Matthieu > and Gwendoline publish they respective drafts -- Specification Needed > implies we need a specification. (I support Specification Needed, which > is consistent with the other Babel registries.) > > Question to Donald and Russ -- is this mail enough to establish the > registry, is it enough to put it in an Internet-Draft, or do we need to > wait for rfc6126bis to be published? > > As to implementations -- the proper thing to do would be to use the > Experimental range. However, since most of the Babel development > community is present on this list, I wouldn't be opposed to using the > unregistered values for now, as long as we are agreed that we might change > them if something happens before registration. > > Okay, so let's put that into RFC-ese (I'm getting good at that, which > I find worrying): > > IANA Considerations > ******************* > > IANA is instructed to create a new registry, called "Babel Address > Encodings (AEs)". The allocation policy for this registry is > Specification Required [RFC5226]. > > The initial values in the Babel Address Encodings are as follows: > > +---------+-----------------------------------------+---------------+ > | Type | Name | Reference | > +---------+-----------------------------------------+---------------+ > | 0 | Wildcard | [RFC6126] | > | | | | > | 1 | IPv4 | [RFC6126] | > | | | | > | 2 | IPv6 | [RFC6126] | > | | | | > | 3 | Link-local IPv6 address | [RFC6126] | > | | | | > | 224-254 | Reserved for Experimental Use | this document | > | | | | > | 255 | Reserved for expansion of the AE space | this document | > +---------+-----------------------------------------+---------------+ > > The following values MIGHT or MIGHT NOT be registered when the relevant > documents get published: > > +---------+-----------------------------------------+---------------+ > | Type | Name | Reference | > +---------+-----------------------------------------+---------------+ > | 4 | Source-specific IPv4 | [Boutier] | > | | | | > | 5 | Source-specific IPv6 | [Boutier] | > | | | | > | 6 | TOS-sensitive IPv4 | [Chouasne] | > | | | | > | 7 | TOS-sensitive IPv6 | [Chouasne] | > +---------+-----------------------------------------+---------------+ > > (We need to update RFC 2119 with MIGHT, MIGHT NOT and IF SOMEBODY CARES ENOUGH.) > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --Boundary_(ID_/Vv24X4T0WyBIKEeMGDf1g) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable I'm in favor of an IANA registry of registration = procedure
"Specification Required", especially since you = only need
to publish a draft to assign a value, not = necessarily an RFC.

That would match the existing = registries:
https://www.iana.org/assignments/babel/babel.xhtml

David


On = Apr 14, 2017, at 18:19, Juliusz Chroboczek <jch@irif.fr> = wrote:

I am hoping the wg is = agreeable to proposed AEs 5 and 6, which replace
the = existing need for the source specific routing tlvs?

I think that should be 4 and 5 -- = Gwendoline, I don't remember -- was
there a reason to skip = 4?

As to registering these values, I think = I f*cked up in RFC 7557 --
I didn't ask for the creation = of an AE registry:

 https://tools.ietf.org/html/rfc7557#section-5

The friendly chairs will correct me if I'm = wrong, but it is my
understanding that what the WG can = decide is to create an AE registry.
Once the AE registry = is created, we can allocate the relevant AEs
according to = the proposed policy.

Question to the WG -- = are we agreed on a policy of Specification Needed?
Note = that this implies that we cannot register 4 through 7 until Matthieu
and Gwendoline publish they respective drafts -- = Specification Needed
implies we need a specification. =  (I support Specification Needed, which
is consistent = with the other Babel registries.)

Question = to Donald and Russ -- is this mail enough to establish the
registry, is it enough to put it in an Internet-Draft, or do = we need to
wait for rfc6126bis to be published?

As to implementations -- the proper thing to = do would be to use the
Experimental range.  However, = since most of the Babel development
community is present = on this list, I wouldn't be opposed to using the
unregistered values for now, as long as we are agreed that we = might change
them if something happens before = registration.

Okay, so let's put that into = RFC-ese (I'm getting good at that, which
I find = worrying):

IANA Considerations
*******************

IANA is = instructed to create a new registry, called "Babel Address
Encodings (AEs)".  The allocation policy for this = registry is
Specification Required [RFC5226].

The initial values in the Babel Address = Encodings are as follows:

=   +---------+-----------------------------------------+---------= ------+
  | Type    | Name =             &n= bsp;           &nbs= p;          | = Reference     |
=   +---------+-----------------------------------------+---------= ------+
  | 0 =       | Wildcard =             &n= bsp;           &nbs= p;      | [RFC6126] =     |
  | =         | =             &n= bsp;           &nbs= p;            =    | =             &n= bsp; |
  | 1 =       | IPv4 =             &n= bsp;           &nbs= p;          | = [RFC6126]     |
  | =         | =             &n= bsp;           &nbs= p;            =    | =             &n= bsp; |
  | 2 =       | IPv6 =             &n= bsp;           &nbs= p;          | = [RFC6126]     |
  | =         | =             &n= bsp;           &nbs= p;            =    | =             &n= bsp; |
  | 3 =       | Link-local IPv6 address =             &n= bsp;   | [RFC6126]     |
=   |         | =             &n= bsp;           &nbs= p;            =    | =             &n= bsp; |
  | 224-254 | Reserved for = Experimental Use =           | this = document |
  | =         | =             &n= bsp;           &nbs= p;            =    | =             &n= bsp; |
  | 255     | = Reserved for expansion of the AE space  | this document |
=   +---------+-----------------------------------------+---------= ------+

The following values MIGHT or MIGHT = NOT be registered when the relevant
documents get = published:

=   +---------+-----------------------------------------+---------= ------+
  | Type    | Name =             &n= bsp;           &nbs= p;          | = Reference     |
=   +---------+-----------------------------------------+---------= ------+
  | 4 =       | Source-specific IPv4 =             &n= bsp;      | [Boutier] =     |
  | =         | =             &n= bsp;           &nbs= p;            =    | =             &n= bsp; |
  | 5 =       | Source-specific IPv6 =             &n= bsp;      | [Boutier] =     |
  | =         | =             &n= bsp;           &nbs= p;            =    | =             &n= bsp; |
  | 6 =       | TOS-sensitive IPv4 =             &n= bsp;        | [Chouasne] =    |
  | =         | =             &n= bsp;           &nbs= p;            =    | =             &n= bsp; |
  | 7 =       | TOS-sensitive IPv6 =             &n= bsp;        | [Chouasne] =    |
=   +---------+-----------------------------------------+---------= ------+

(We need to update RFC 2119 with = MIGHT, MIGHT NOT and IF SOMEBODY CARES ENOUGH.)

-- Juliusz

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

= --Boundary_(ID_/Vv24X4T0WyBIKEeMGDf1g)-- From nobody Mon Apr 17 10:13:29 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 C420F1316B4 for ; Mon, 17 Apr 2017 10:13:27 -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, RCVD_IN_DNSWL_MED=-2.3, 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=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 QKIq2TJOxKnj for ; Mon, 17 Apr 2017 10:13:26 -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 E33B9129329 for ; Mon, 17 Apr 2017 10:13: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=1492449194; 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=ccf08ATadSB+lH+QuSzYFdmRV4upfX6Tvm48MPa51/0=; b=NgHs+l6YLQTRuJH7COu4i8R2tR8A8AX6BdGS9iV/pKS/ttwzNkZqDQbAGUgFlIBD yjgro2LrS7B236QoNCLhquOnDFF4sno2vlCwGxKmiQARPBgbfzCLPqh4/CbrvZ1m xxq6qpBYnvGMQEbjORWQiI7coNrPweQOjU+vC3mkL11QEJoNrJwNfqEFzzj50DV0 iVw5yAZLKb6cpIZSS4eMQ64mJ67c8bNObdkbLw2RspsFXq3y6hKgp6flh5CbWSA5 WFG5I9puuftWmw0UH2U7w2SRpfcQJ5mhdEn/irGuJ28iLcRYSmwXQsC2D6Umqey8 VwXpkPK7THrNjDAnserJPw==; 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 88.0B.23870.AA7F4F85; Mon, 17 Apr 2017 10:13:14 -0700 (PDT) X-AuditID: 11973e12-9ea929a000005d3e-72-58f4f7aabc14 Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay8.apple.com (Apple SCV relay) with SMTP id D7.43.26253.AA7F4F85; Mon, 17 Apr 2017 10:13:14 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.153.22.28] (unknown [17.153.22.28]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OOK00LM2D59DH00@nwk-phonehomebzp-sz01.apple.com>; Mon, 17 Apr 2017 10:13:14 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87wpaj3rhx.fsf@alrua-x1> Date: Mon, 17 Apr 2017 10:13:09 -0700 Cc: Juliusz Chroboczek , babel@ietf.org Content-transfer-encoding: quoted-printable Message-id: <453BCC66-4ADE-4407-9E95-C3BAB356EFDE@apple.com> References: <87pogduqas.wl-jch@irif.fr> <87pogcmveu.fsf@alrua-x1> <878tn01c1n.wl-jch@irif.fr> <87wpaj3rhx.fsf@alrua-x1> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUi2FCYprvq+5cIg/WbtS22LOpmsZjfuozN Yuv7FewOzB5Llvxk8li85S2jx5ZDF9kCmKO4bFJSczLLUov07RK4MqY9nM1S0ClccXSCZAPj Yv4uRk4OCQETiRnblzB1MXJxCAmsYZJYuec+C0zi9pQjUIljjBLPnr5kBUnwCghK/Jh8D6iI g4NZQF1iypRciJr5TBLd324ygtQIC0hLdF24ywpha0qc3raIDaSeTUBL4sAaI5Awp4CaxMFP 78DKWQRUJXZ/3QhWzgy0d+nfo2wQtrbEk3cXWEFaeQVsJA72FIOEhQQqJVY+PcEOYosI2Es0 fr0AdbKsxK3Zl5hBzpEQ2MImsWnaRNYJjMKzkFw9C+HqWUg2LGBkXsUolJuYmaObmWeil1hQ kJOql5yfu4kRFOjT7YR2MJ5aZXWIUYCDUYmHd8W+LxFCrIllxZW5hxilOViUxHnlV36OEBJI TyxJzU5NLUgtii8qzUktPsTIxMEp1cCY6Cw5X+lry6ywTdIdctVLLe3+lembi3074lY92/RH Tm38qgTHVcbSM5XPxVf7G2SYeTPGKL9tWdEZ8Enn6U2D2qPZ8mHvDHi+8Xo8/VI2K+7lrltv Grp5tl/40n1P5PWCV5t0jt8R4TL8OMdw161unmTb6z6tTCJW6zx5b9w7b7ZS/fGtyXeVWIoz Eg21mIuKEwHDFzdtVQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUiON3OQXfV9y8RBk/Oq1tsWdTNYjG/dRmb xdb3K9gdmD2WLPnJ5LF4y1tGjy2HLrIFMEdx2aSk5mSWpRbp2yVwZUx7OJuloFO44ugEyQbG xfxdjJwcEgImErenHGHqYuTiEBI4xijx7OlLVpAEr4CgxI/J91i6GDk4mAXUJaZMyYWomc8k 0f3tJiNIjbCAtETXhbusELamxOlti9hA6tkEtCQOrDECCXMKqEkc/PQOrJxFQFVi99eNYOXM QHuX/j3KBmFrSzx5d4EVpJVXwEbiYE8xSFhIoFJi5dMT7CC2iIC9ROPXCywQJ8tK3Jp9iXkC o8AsJIfOQjh0FpKhCxiZVzEKFKXmJFZa6CUWFOSk6iXn525iBAVmQ2HaDsam5VaHGAU4GJV4 eBkOfokQYk0sK67MPcQowcGsJMJ79AlQiDclsbIqtSg/vqg0J7X4EGMV0CsTmaVEk/OBUZNX Em9oYmJgYmxsZmxsbmJOFWElcd6WdKDNAumJJanZqakFqUUwy5k4OKUaGAM9CzM1H+RfvWZe EHWp6mbxwjPTrVVe+jukL1BTMfd31Q5fJL3txpugjcpF/XGcj/ozbu9LFbDapuIf+dF+9p6Z 8859fvZcdJf39N7E/quPZi6938uu1dold7nlTefuTektdz/J2Pcz2ueEJbnwTdWSt+VNNHee FKLVek00odZbWuNZe7uXEktxRqKhFnNRcSIAJ/DQA6cCAAA= Archived-At: Subject: Re: [babel] About mandatory bits 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, 17 Apr 2017 17:13:28 -0000 I do agree that a mandatory bit is a clean solution to enable more = extensibility without incurring the combinatorial explosion of AEs. The downside is = that it requires minimal implementations (such as mine) to parse sub-TLVs, which mine didn't do until now. I can live with that. I see mandatory bits as = a reasonable tradeoff between simplicity and extensibility. I have no = strong opinion, only a slight preference for the mandatory bits, as I have a gut feeling = they'll come in handy somewhere down the line. David > On Apr 17, 2017, at 09:53, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Juliusz Chroboczek writes: >=20 >> So I take it that you prefer mandatory bits to new AEs? >=20 > Well, if we are just talking about source specific routing, I think I > like the separate AE numbers better. That fits well with what my = mental > model of a source-specific route is. >=20 > However, I can see your point that there could be other uses for > mandatory sub-TLVs, so introducing those is probably a good idea in = any > case. >=20 >>> As far as a flag day is concerned, that is probably going to be >>> necessary in many cases, since people running babeld using the >>> source-specific extension are still going to experience = incompatibility >>> (I know that's the case for my network). >>=20 >> Plan is: >>=20 >> babeld-1.9: sends the old format, parses both; >> babeld-2.0: sends the new format. >=20 > What about making it configurable in 1.9 and just change the default = for > 2.0? >=20 >>> To me, the greatest drawback of this approach is that it raises the = bar >>> for the minimum viable implementation. The current spec is dead = simple >>> in this regard, and this would obviously change that, as you remark. >>> However, I would probably lean towards this cost being worth it... >>=20 >> I'll add sub-TLV parsing to sbabeld, see how much it bloats the code. >> Does your implementation parse sub-TLVs? >=20 > No, Babel in Bird 1.6 will be left confused by the introduction of > mandatory sub-TLVs. When I do actually get around to implementing > source-specific routing I'm planning to just do whatever encoding we = end > up agreeing on, obviously... >=20 > -Toke >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Tue Apr 18 06:39:29 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 BF37412EC21 for ; Tue, 18 Apr 2017 06:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, 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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOkDjQFM0g4i for ; Tue, 18 Apr 2017 06:39:25 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 2C1B512EC42 for ; Tue, 18 Apr 2017 06:39:25 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id r190so15038231wme.1 for ; Tue, 18 Apr 2017 06:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LOH2uKSiK95f+GFJQvO4N6L/+ECtnOrjVZCzadgbYpw=; b=Ivp5Xxv4aQ/kiu0GPwOqlewKtAMhvwINl6CvgFvtSKItiOBkO7ugfWDl/gEEcFM6fJ 0t5Z/dnzLC70YAN7XCvvy2wKzo8w3Y1v3emToOrAn+fMFYno5s+sdElN+C+K2dTfLAmj gjChzJDfjffHIQYkN1pOJVWA/Qn4IcwdNOkUk/ujVdMFYjeZOTf2aTSaQOTkjCN16UJv ggOWw2Wpq9NGCWR4KXWFn8skQJpjXqnCSJN5359W7A5msViAf/ma4YsEHmbBK3lB8tFD jn30f+LczgA83PBWwQNq8orgoxIzFAG9doCIylSKb+k8zS+6d1cuRFJea5M822G2tY71 FlxQ== 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=LOH2uKSiK95f+GFJQvO4N6L/+ECtnOrjVZCzadgbYpw=; b=XU7dNMXO9hzktQt5yIIC2Bqq2C49rlZ90t6bsoZ4jif0IVanRuT8XvvzT6cn4gPfQL 2KUOz2Ob/1JjyYU7UCgtDeiqq7JmxqmzIBmyWVcGi6pKDamumHuGT8MLg0VDvIrD+1pW ul7JLWgCWBZfFn5Q0mHKwwMVsn0l2E1CtZVznVmlOp0VlqZXBIiTyHRJ0YepywYgmTsJ 7f8xhKXfiOz8bjG4FWCJdBmf5I/YYcU+cCULm18EiO0VHJVAVF7FgddXakoFhKOhwTyf b7DHmIxkLy4+rmn/li5pdo3JXc+dcdVroiZxJBQLNvZkLd34aQP/Z+YrEUi9Lvo5IEX4 AogQ== X-Gm-Message-State: AN3rC/5U/bWcQzROFWNxdNAvCo1uQzfrLfG1QZulK1r5h3jDyAuKKi8P hx+UZStSIkndWqhz02Prpno65C79pstsosU= X-Received: by 10.28.150.86 with SMTP id y83mr1786867wmd.46.1492522763581; Tue, 18 Apr 2017 06:39:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.159.139 with HTTP; Tue, 18 Apr 2017 06:38:42 -0700 (PDT) In-Reply-To: <87y3vcuuv8.wl-jch@irif.fr> References: <87y3vcuuv8.wl-jch@irif.fr> From: Gabriel Kerneis Date: Tue, 18 Apr 2017 15:38:42 +0200 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF Content-Type: multipart/alternative; boundary=001a114b33e4250454054d710941 Archived-At: Subject: Re: [babel] Unicast Hellos -- conclusions so far 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, 18 Apr 2017 13:39:28 -0000 --001a114b33e4250454054d710941 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 4:59 PM, Juliusz Chroboczek wrote: > > 4. Unicast Hellos are allowed to set Interval to 0, meaning that this is > an unscheduled Hello (used e.g. for carrying a timestamp sub-TLV, not > necessarily for link maintenance) and we don't promise to send another > one. > This needs clarification. What should a receiver do upon seeing a first Hello with Interval=42 followed, in a timely manner, by one with Interval=0: - does the latter hello count as a fulfillment of the promise made by the former one? - does it cancel the promise made by the former one? - is it simply ignored as far as link estimation is concerned? Best, Gabriel --001a114b33e4250454054d710941 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 7, 2017 at 4:59 PM, Juliusz Chroboczek <jch@irif.fr> wrote= :
4. Unicast Hellos are allowed to set Interval to 0, meaning that this is an unscheduled Hello (used e.g. for carrying a timestamp sub-TLV, not
necessarily for link maintenance) and we don't promise to send another<= br> one.

This needs clarification. What sho= uld a receiver do upon seeing a first Hello with Interval=3D42 followed, in= a timely manner, by one with Interval=3D0:
  • does the latt= er hello count as a fulfillment of the promise made by the former one?
    • =
  • does it cancel the promise made by the former one?
  • is it simply= ignored as far as link estimation is concerned?
Best,
G= abriel=C2=A0
--001a114b33e4250454054d710941-- From nobody Tue Apr 18 07:19: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 12DF012EC2F for ; Tue, 18 Apr 2017 07:19: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 Ke4AbE05-JDH for ; Tue, 18 Apr 2017 07:19: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 ECA3E12EE45 for ; Tue, 18 Apr 2017 07:19:20 -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 v3IEJI73021672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Apr 2017 16:19: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 v3IEJI50015743; Tue, 18 Apr 2017 16:19: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 2C469D78E4; Tue, 18 Apr 2017 16:19:18 +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 nu4ueBNE80-V; Tue, 18 Apr 2017 16:19:17 +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 0D573D7885; Tue, 18 Apr 2017 16:19:16 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.88) (envelope-from ) id 1d0TyN-0002ON-Ob; Tue, 18 Apr 2017 16:19:15 +0200 Date: Tue, 18 Apr 2017 16:19:15 +0200 Message-ID: <7i8tmxx0gs.wl-jch@irif.fr> From: Juliusz Chroboczek To: Gabriel Kerneis Cc: Babel at IETF In-Reply-To: References: <87y3vcuuv8.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, 18 Apr 2017 16:19:18 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 18 Apr 2017 16:19:18 +0200 (CEST) X-Miltered: at korolev with ID 58F62066.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58F62066.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F62066.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58F62066.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 : 58F62066.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58F62066.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] Unicast Hellos -- conclusions so far 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, 18 Apr 2017 14:19:23 -0000 > 4. Unicast Hellos are allowed to set Interval to 0, meaning that this is > an unscheduled Hello (used e.g. for carrying a timestamp sub-TLV, not > necessarily for link maintenance) and we don't promise to send another > one. > This needs clarification. Yes. > What should a receiver do upon seeing a first Hello with Interval=42 > followed, in a timely manner, by one with Interval=0: > * does the latter hello count as a fulfillment of the promise made by the > former one? > * does it cancel the promise made by the former one? > * is it simply ignored as far as link estimation is concerned? I'd say 1 + 3: it fulfills the promise but doesn't establish a new deadline. -- Juliusz From nobody Tue Apr 18 07:49:42 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 AA10212EBFB for ; Tue, 18 Apr 2017 07:49:40 -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 d4m06T8MWksz for ; Tue, 18 Apr 2017 07:49:39 -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 87CAC1273E2 for ; Tue, 18 Apr 2017 07:49: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 v3IEnWe3008666; Tue, 18 Apr 2017 16:49: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 53646D7952; Tue, 18 Apr 2017 16:49: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 yb8GwxJSEqOc; Tue, 18 Apr 2017 16:49:26 +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 6B43ED7924; Tue, 18 Apr 2017 16:49:26 +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: <453BCC66-4ADE-4407-9E95-C3BAB356EFDE@apple.com> Date: Tue, 18 Apr 2017 16:49:26 +0200 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Babel at IETF , Juliusz Chroboczek Content-Transfer-Encoding: quoted-printable Message-Id: <7D568520-A73A-4D7B-B506-465A811BEB1A@irif.fr> References: <87pogduqas.wl-jch@irif.fr> <87pogcmveu.fsf@alrua-x1> <878tn01c1n.wl-jch@irif.fr> <87wpaj3rhx.fsf@alrua-x1> <453BCC66-4ADE-4407-9E95-C3BAB356EFDE@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 [194.254.61.138]); Tue, 18 Apr 2017 16:49:35 +0200 (CEST) X-Miltered: at korolev with ID 58F6277C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F6277C.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 : 58F6277C.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] About mandatory bits 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, 18 Apr 2017 14:49:41 -0000 I support mandatory bits. Being incompatible is the only long-term = *clean* solution I see. I will provide an implementation of = source-specific routing with mandatory sub-TLV (for babeld). Matthieu From nobody Tue Apr 18 09:18: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 DD7E912EC86 for ; Tue, 18 Apr 2017 09:18: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 QxofSKxJRYOL for ; Tue, 18 Apr 2017 09:18: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 6018C12EC81 for ; Tue, 18 Apr 2017 09:18: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 v3IGId2Z030028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 18 Apr 2017 18:18: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 v3IGId6n024850 for ; Tue, 18 Apr 2017 18:18:39 +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 6D2F9D7936 for ; Tue, 18 Apr 2017 18:18:39 +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 R-S9XQBKNch3 for ; Tue, 18 Apr 2017 18:18:38 +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 94253D7891 for ; Tue, 18 Apr 2017 18:18:38 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.88) (envelope-from ) id 1d0Vpt-0002aM-Vf for babel@ietf.org; Tue, 18 Apr 2017 18:18:38 +0200 Date: Tue, 18 Apr 2017 18:18:37 +0200 Message-ID: <7ivaq1vgde.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]); Tue, 18 Apr 2017 18:18: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, 18 Apr 2017 18:18:39 +0200 (CEST) X-Miltered: at korolev with ID 58F63C5F.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58F63C5F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F63C5F.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58F63C5F.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 : 58F63C5F.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58F63C5F.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] Mandatory bits and compression 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, 18 Apr 2017 16:18:44 -0000 An Update TLV with an unknown mandatory sub-TLV cannot be simply ignored -- it must be parsed and the compression state updated accordingly, only then can it be thrown away. Otherwise implementations end up with different compression states depending on the set of extensions they understand. Matthieu suggests dropping support for compression, but compression reduces the number of packets by close to 40% in large double-stack networks, so I'm a little wary of letting it go. -- Juliusz From nobody Tue Apr 18 10:13: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 A66B512EBF6 for ; Tue, 18 Apr 2017 10:13:31 -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_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 GkVVJ3bsRMfd for ; Tue, 18 Apr 2017 10:13:30 -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 4D96F128BB6 for ; Tue, 18 Apr 2017 10:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1492535610; 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=KTC8pUfjEO2yWpEzRWmUmsbAJ/ZNePOKONZHHoPWDp0=; b=wVFUgTGav4nl+KmCUo4IBSMWAg2AEklXhIv228yrw7NblXE6kjCLs/bO3hpz+NcY QL1wiQ1myEtTXjKPdJWNssM2Kj02B1/NfyfbxbL7m2C2IYtqZDRzHuczKGibJi/W sH4yORz9YbTDyNe+Ga/M2CTXH4ogHkv6KuSK2INfJrY1v9Hll12SuClgzFD7AR3A FvIIFeju6LPiKL+xBX8LvJQo7zneSP2aP/pk8O7cSTbqZepa6rc6VJ5qUTSygZiT SAnue2swnUo0jUXrRnpfE2rRMdA8T20y5SnoocdgvDBbrpObHPvVQhntllxmkZ0u cIZ6dRD5N3PFhOmB8cQJXA==; 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-in5.apple.com (Apple Secure Mail Relay) with SMTP id 4D.CA.17501.A3946F85; Tue, 18 Apr 2017 10:13:30 -0700 (PDT) X-AuditID: 11973e13-2b09e9a00000445d-70-58f6493ad954 Received: from kencur (kencur.apple.com [17.151.62.38]) by relay4.apple.com (Apple SCV relay) with SMTP id EC.1F.13512.93946F85; Tue, 18 Apr 2017 10:13:30 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.82.13] (unknown [17.153.82.13]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OOM008IH7UFEW40@kencur.apple.com>; Tue, 18 Apr 2017 10:13:29 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <7ivaq1vgde.wl-jch@irif.fr> Date: Tue, 18 Apr 2017 10:13:26 -0700 Cc: babel@ietf.org Message-id: <9D753523-4350-41CD-AF37-49012DCAC2EE@apple.com> References: <7ivaq1vgde.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUi2FAYrmvl+S3C4Oxnbosti7pZLOa3LmNz YPJYsuQnk8fiLW8ZA5iiuGxSUnMyy1KL9O0SuDIe/rjNVPCYveLHkWeMDYwr2LoYOTkkBEwk dvz8z9jFyMUhJLCaSaL92QJWmMSimVMZQWwhgRWMEvvbpEFsXgFBiR+T77F0MXJwMAvISxw8 LwsSZhbQkvj+qJUFYk4jk8T57f+ZQRLCAtISXRfuskLYxhJPN/QwgfSyATUcWGMEYnIKaEg0 nbEDqWARUJX4e6+ZBWKkkMSZazNYILbaSGz4sYAN4hp1idmtm8AuExFQkVg+7Rk7xMWyErdm X2IGOUFCYAmbRMumA6wTGIVnIbl6FsLVs5BcvYCReRWjUG5iZo5uZp6pXmJBQU6qXnJ+7iZG UFBPtxPewXh6ldUhRgEORiUeXgPxbxFCrIllxZW5hxilOViUxHmXR3yNEBJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cAYsllMOcY8t97PP0hU84qdxerjz4oVhffnBfquXMpSErL0Ypo9w3rz 64pXXTblte7elTcxL2J6nppk8P3pvvasjpdN35xPNL5xc5uPZOz/9xftdspzlbvdP3DlU3vV tEdiLX5SDTKlD0L9GvqizS7Z7fp96hZXndHGuLh6FXZ7l/76KWbGH5RYijMSDbWYi4oTAYyP OnNLAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42IRnG6npmvl+S3C4OdyVosti7pZLOa3LmNz YPJYsuQnk8fiLW8ZA5iiuGxSUnMyy1KL9O0SuDIe/rjNVPCYveLHkWeMDYwr2LoYOTkkBEwk Fs2cyghiCwmsYJTY3yYNYvMKCEr8mHyPpYuRg4NZQF7i4HlZkDCzgJbE90etQGEuoPJGJonz 2/8zgySEBaQlui7cZYWwjSWebuhhAullA2o4sMYIxOQU0JBoOmMHUsEioCrx914zC8RIIYkz 12awQGy1kdjwYwEbxDXqErNbN4FdJiKgIrF82jN2iItlJW7NvsQ8gVFgFpJDZyEcOgvJoQsY mVcxChSl5iRWmuglFhTkpOol5+duYgQFYUNh+A7Gf8usDjEKcDAq8fAaiH+LEGJNLCuuzD3E KMHBrCTCu8IKKMSbklhZlVqUH19UmpNafIixCuj+icxSosn5wAjJK4k3NDExMDE2NjM2Njcx p4qwkjhvS/qXCCGB9MSS1OzU1ILUIpjlTBycUg2MaVUvHK9bvj0155qSvPWv9vyjLUpKwt9l X/SrG+xlnyt6/+TrJYuEdzy3X8q19edjObF+yblqE5MvbNgj2FGfOlkv5fe0MudvvY0T48+f vbKqQkclael2xd0ymrNel/UpzUi8Lum9fn6C+I3mv41zav6vMpsbZmvV9T33StRcrUPXoiZu T7o3XYmlOCPRUIu5qDgRAPgbtwedAgAA Archived-At: Subject: Re: [babel] Mandatory bits and compression 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, 18 Apr 2017 17:13:32 -0000 I think there's value in compression, and updating the decompressor state before checking for unknown mandatory sub-TLVs shouldn't add complexity to the code. As long as we clearly define this in the spec, I'm fine with your proposal. David > On Apr 18, 2017, at 09:18, Juliusz Chroboczek wrote: > > An Update TLV with an unknown mandatory sub-TLV cannot be simply > ignored -- it must be parsed and the compression state updated > accordingly, only then can it be thrown away. Otherwise implementations > end up with different compression states depending on the set of > extensions they understand. > > Matthieu suggests dropping support for compression, but compression > reduces the number of packets by close to 40% in large double-stack > networks, so I'm a little wary of letting it go. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Tue Apr 18 10:33: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 E576A12922E for ; Tue, 18 Apr 2017 10:33: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, 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 OF1KY2tQmf9a for ; Tue, 18 Apr 2017 10:33:33 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (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 DE4E412FB9C for ; Tue, 18 Apr 2017 10:33:26 -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=1492536804; bh=7z3aAakjWUjGQ9MPlB6aMYckRtj6hj9iF62vrGZL2i4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=nXvAcMpeCkjzF76d4pdJJGdjXhaz/3kMUH41Qspn27hdQSj21bF+kPGt8zVDCsTfY hdK+oGNIONEL1r9Kx0m7n5IG9Lm6H+Z8DPi2yyY3M87Z8bhvIJmgmW/7f6Y2rT6OLb LtfFFiWqi+3VtPkjBD4A9RQSokUfqUQPmBXGeUjBvn3pZeRm/gksZAUV51QvLApLTR 8oMPhjAuEKnVkDrTnjIOE//SoXE3eUttyiQhRIpeNSiW5vFHuYhuWLfWPamn64tGt5 n8TdmjOt/1EF+iPyzxIrrTmQ+24RLBMuO4Z2AdkYlA5Ds2O+C2NSeVPKntBYr6aFRz N+Pw/dzngdjqw== To: Juliusz Chroboczek Cc: babel@ietf.org References: <7ivaq1vgde.wl-jch@irif.fr> Date: Tue, 18 Apr 2017 19:33:23 +0200 In-Reply-To: <7ivaq1vgde.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Tue, 18 Apr 2017 18:18:37 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87d1c94o4c.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Mandatory bits and compression 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, 18 Apr 2017 17:33:38 -0000 Juliusz Chroboczek writes: > An Update TLV with an unknown mandatory sub-TLV cannot be simply > ignored -- it must be parsed and the compression state updated > accordingly, only then can it be thrown away. Otherwise > implementations end up with different compression states depending on > the set of extensions they understand. Hmm, while in principle that's not too onerous, I wonder if it is something that is likely to be overlooked by implementers. Which would lead to subtle and hard to debug bugs... > Matthieu suggests dropping support for compression, but compression > reduces the number of packets by close to 40% in large double-stack > networks, so I'm a little wary of letting it go. >From what to what? Absolute numbers matter. I didn't bother to implement compression on the sender side for Bird (but it will parse it, of course). Have not looked into how much of a difference it makes for my use cases, just put it on the "later" list to avoid the complexity. How does the prefix compression compare to just gzip'ing the whole packet? ;) -Toke From nobody Tue Apr 18 10:37:08 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 54B8A12EBE2 for ; Tue, 18 Apr 2017 10:37:07 -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 279JXRMWy5Hn for ; Tue, 18 Apr 2017 10:37:05 -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 14B5A12922E for ; Tue, 18 Apr 2017 10:37:04 -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 v3IHb3Ww019374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 18 Apr 2017 19:37:03 +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 v3IHb3XL020780 for ; Tue, 18 Apr 2017 19:37:03 +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 46BD5D7891 for ; Tue, 18 Apr 2017 19:37: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 HM5FHtcZgMvY for ; Tue, 18 Apr 2017 19:37:02 +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 07EF5D7885 for ; Tue, 18 Apr 2017 19:37:02 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.88) (envelope-from ) id 1d0X3l-0002pN-Ox for babel@ietf.org; Tue, 18 Apr 2017 19:37:01 +0200 Date: Tue, 18 Apr 2017 19:37:01 +0200 Message-ID: <7ir30pvcqq.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]); Tue, 18 Apr 2017 19:37: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, 18 Apr 2017 19:37:03 +0200 (CEST) X-Miltered: at korolev with ID 58F64EBF.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58F64EBF.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F64EBF.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58F64EBF.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 : 58F64EBF.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58F64EBF.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Mandatory bit in sbabeld 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, 18 Apr 2017 17:37:07 -0000 I've just implemented support for the mandatory bit in sbabeld: $ git diff --stat master mandatory sbabeld.c | 45 +++++++++++++++++++++++++++++++++++++++------ 1 file changed, 39 insertions(+), 6 deletions(-) Code size is as follows: sbabeld sbabeld(mandatory) LOC 1213 1241 text size (x86-64) 12320 12592 stripped binary size 18824 18824 The patch is here: https://github.com/jech/sbabeld/commit/027bf9b32cf4fd28322572bccf186e131ee8a9e1 -- Juliusz From nobody Tue Apr 18 11:13: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 9DFB91293DA for ; Tue, 18 Apr 2017 11:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 aPLq_tJbiVdn for ; Tue, 18 Apr 2017 11:13:45 -0700 (PDT) Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.234]) by ietfa.amsl.com (Postfix) with ESMTP id 4667D12EB20 for ; Tue, 18 Apr 2017 11:13:42 -0700 (PDT) Received: from poro.lan (80.220.131.63) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 58A591F80151E0A9; Tue, 18 Apr 2017 21:13:39 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Markus Stenberg In-Reply-To: <87d1c94o4c.fsf@alrua-x1> Date: Tue, 18 Apr 2017 21:13:35 +0300 Cc: Juliusz Chroboczek , babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <19A8123B-1721-44C3-8E68-697E97DE0CC5@iki.fi> References: <7ivaq1vgde.wl-jch@irif.fr> <87d1c94o4c.fsf@alrua-x1> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [babel] Mandatory bits and compression 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, 18 Apr 2017 18:13:48 -0000 On 18 Apr 2017, at 20.33, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: > How does the prefix compression compare to just gzip'ing the whole > packet? ;) Ironically enough this is exactly what I was thinking of (although = something with less computationally heavy compression would be = preferable on my opinion).=20 Just for amusement value, I did quick study: pybabel unittests generate = 287 (roughly) packets. Of them, only 36 compress better with gzip than = with the default prefix encoding, but actually _every_ update I can = briefly see compresses better with gzip. For them, typically size of = packet roughly halves.=20 (gzip doesn=E2=80=99t help much with small packets, which the rest of = the packets are.) At a guess, every payload > 80 bytes, gzip wins hands down based on my = very limited dataset. e.g. former: raw Babel encoding. later: Babel encoding gzipped. 52 / 56 58 / 70 67 / 66 67 / 67 92 / 73 92 / 75=20 117 / 80 117 / 83 142 / 89 158 / 99 167 / 93 192 / 94 208 / 106 208 / 107 208 / 108 224 / 109 224 / 111 If one really cared about size of stuff on the link, I=E2=80=99d specify = something like optional LZ4 with first bit on the wire indicating = compression or not. Use compressed version if it is smaller, and = non-compressed otherwise. Cheers, -Markus= From nobody Tue Apr 18 13:47: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 767E6128796 for ; Tue, 18 Apr 2017 13:47:18 -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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4V4mTHx_rUZL for ; Tue, 18 Apr 2017 13:47:13 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 C8C9C13147A for ; Tue, 18 Apr 2017 13:47:12 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id l28so2879240wre.0 for ; Tue, 18 Apr 2017 13:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GjzbYNwFS0lIzRU3Qzg3bPgZ0QGe2Y/UJBLnitVkqKA=; b=XjebSv9d4+QdUH91s5xnM472CH53LHIWa3ZzJ1U2Oq/z13er/8EhHtpc/ckR9gFVFS s1WtyDg056PcDCpt/Ysxhe68A4LhrL/1oWQBYcvzU4FssBlgZP0nskAR0UeUz73ptO/d J97KeNRt/7FbQr4eovsmwtckEsB7pkomlRbmhJosoaKldLhwPdZ2x+KJfG0qXNQsnVcJ HKKhqrCWGlx78EO/FWq8x8eUy35YF6+gqL++yBjXGsfuJEF73VurqgJj4uoOajkvGzXE tEHBjPHaOg6YNGczS0FB9TZdoFGs7WMWBb2kdcDopaSIk6D1TvJKYI2Ry+ylwysSTLJq A95w== 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=GjzbYNwFS0lIzRU3Qzg3bPgZ0QGe2Y/UJBLnitVkqKA=; b=RQvY1IpwBQkqC+YGEI6/uwtiGb5yNQD05ULblTX6iZTWdkT6Zck8QkMSCy4ataDTO1 hYVG6jCALUAQJ9EC0940+z3N7yeBmchPqe3yDvmklDsG0ueYtn2MV5/zFD92LjcOISCf /r1NnLNZ8yVbwjvPyuWWpx1fabPN0UPB28yUZFwlgFclWlghTo5exj9Ah3g02BrgRrYt qRY+N3XJwwGtboJyJQFIkxVmoVLX9Pmnmdz6cbNJK/9YkWDRO0jHY+tOOrGC5CFkJMt7 /nG/z9RdlmpZVqtL4a0ltHExnYmfbQtzP//r/J/ZW/iooA7OU9yy2BoeizXkh6JFQGVn eDfA== X-Gm-Message-State: AN3rC/7ww+0H3uCihyXXxnh2qOVNtilZ6ff/4Lw6q8MeZMZC4caSOKz8 butcMimW4pRpGCR13vv0m+kYklzglQ/x X-Received: by 10.223.162.147 with SMTP id s19mr23561806wra.142.1492548431289; Tue, 18 Apr 2017 13:47:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.159.139 with HTTP; Tue, 18 Apr 2017 13:46:30 -0700 (PDT) In-Reply-To: <19A8123B-1721-44C3-8E68-697E97DE0CC5@iki.fi> References: <7ivaq1vgde.wl-jch@irif.fr> <87d1c94o4c.fsf@alrua-x1> <19A8123B-1721-44C3-8E68-697E97DE0CC5@iki.fi> From: Gabriel Kerneis Date: Tue, 18 Apr 2017 22:46:30 +0200 Message-ID: To: Markus Stenberg Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Babel at IETF , Juliusz Chroboczek Content-Type: multipart/alternative; boundary=f403045ea34e0f15d3054d7703c4 Archived-At: Subject: Re: [babel] Mandatory bits and compression 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, 18 Apr 2017 20:47:19 -0000 --f403045ea34e0f15d3054d7703c4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 18, 2017 at 8:13 PM, Markus Stenberg wrote: > If one really cared about size of stuff on the link, I=E2=80=99d specify = something > like optional LZ4 with first bit on the wire indicating compression or no= t. > Use compressed version if it is smaller, and non-compressed otherwise. > Meaning every babeld implementation needs to embed a gzip decoder (or you need some feature negotiation mechanism, ahem). I'm not saying it is necessarily a bad idea, but several people here seem to care about minimal and simple implementations. Gabriel --f403045ea34e0f15d3054d7703c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 18, 2017 at 8:13 PM, Markus Stenberg <markus.stenberg@iki.fi= > wrote:
If one really care= d about size of stuff on the link, I=E2=80=99d specify something like optio= nal LZ4 with first bit on the wire indicating compression or not. Use compr= essed version if it is smaller, and non-compressed otherwise.

Meaning every babeld implementation needs to embed a= gzip decoder (or you need some feature negotiation mechanism, ahem). I'= ;m not saying it is necessarily a bad idea, but several people here seem to= care about minimal and simple implementations.

Ga= briel=C2=A0

--f403045ea34e0f15d3054d7703c4-- From nobody Tue Apr 18 18:50: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 51B8F1205F1 for ; Tue, 18 Apr 2017 18:50:18 -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 0Eutbljhoy42 for ; Tue, 18 Apr 2017 18:50: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 1833A1200DF for ; Tue, 18 Apr 2017 18:50:14 -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 v3J1oAuZ014605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 Apr 2017 03:50:13 +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 v3J1o8XC019095; Wed, 19 Apr 2017 03:50: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 34659D78E4; Wed, 19 Apr 2017 03:50: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 nwILmOKuIOOa; Wed, 19 Apr 2017 03:50:07 +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 06165D7885; Wed, 19 Apr 2017 03:50:04 +0200 (CEST) Date: Wed, 19 Apr 2017 03:50:12 +0200 Message-ID: <87efwpb1yj.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , babel@ietf.org In-Reply-To: <19A8123B-1721-44C3-8E68-697E97DE0CC5@iki.fi> References: <7ivaq1vgde.wl-jch@irif.fr> <87d1c94o4c.fsf@alrua-x1> <19A8123B-1721-44C3-8E68-697E97DE0CC5@iki.fi> 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, 19 Apr 2017 03:50:13 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 19 Apr 2017 03:50:10 +0200 (CEST) X-Miltered: at korolev with ID 58F6C252.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58F6C250.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F6C252.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58F6C250.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 : 58F6C252.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58F6C250.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] About compression [was: Mandatory bits and compression] 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, 19 Apr 2017 01:50:18 -0000 Is there a proposal for rfc6126bis here, or are you guys just enjoying slagging off my poor taste ;-) FWIW, if I were to redo Babel today in a completely incompatible manner, I'd probably keep the stateful parser. Sharing router-ids and next hops between Update TLVs is a simple and effective optimisation, and once you have a stateful parser anyway, adding prefix compression doesn't add a lot of complexity. I'd probably encode it differently, with the Router-ID and Next-Hop TLVs replaced with sub-TLVs of Update, but these are mere details. (Matthieu has suggested that the stateful parser should be replaced with a dictionary of router-ids at the beginning of a packet. While simple to parse, that's a little more complicated to generate, so I'm not sure where the tradeoff lies.) I think the problem with compression is not the implementation complexity, but the fragility of the state -- compression tends to make extensions more difficult to design and specify. I'm not sure that justifies avoiding compression, it just means that extensions should not be over-optimised, they should simply avoid using compression. -- Juliusz From nobody Tue Apr 18 19:04: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 3DE87127843 for ; Tue, 18 Apr 2017 19:03:58 -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 ByzU-w0FlQoL for ; Tue, 18 Apr 2017 19:03: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 1EBDF1200DF for ; Tue, 18 Apr 2017 19:03:56 -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 v3J23tqL027348 for ; Wed, 19 Apr 2017 04:03:55 +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 7CF94D7891 for ; Wed, 19 Apr 2017 04:03:55 +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 r6KaoulC7sF4 for ; Wed, 19 Apr 2017 04:03:54 +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 959A1D7885 for ; Wed, 19 Apr 2017 04:03:54 +0200 (CEST) Date: Wed, 19 Apr 2017 04:04:02 +0200 Message-ID: <87bmrtb1bh.wl-jch@irif.fr> From: Juliusz Chroboczek To: Babel at IETF In-Reply-To: References: <7ivaq1vgde.wl-jch@irif.fr> <87d1c94o4c.fsf@alrua-x1> <19A8123B-1721-44C3-8E68-697E97DE0CC5@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 19 Apr 2017 04:03:55 +0200 (CEST) X-Miltered: at korolev with ID 58F6C58B.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F6C58B.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 : 58F6C58B.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: Re: [babel] Mandatory bits and compression 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, 19 Apr 2017 02:03:58 -0000 >> If one really cared about size of stuff on the link, I’d specify something >> like optional LZ4 with first bit on the wire indicating compression or >> not. Use compressed version if it is smaller, and non-compressed >> otherwise. Point is, the main purpose of compression is to reduce the number of link-layer frames being used for a full table dump (think WiFi, with its outrageous per-frame overhead; yeah, I know about frame aggregation). So in order to compress effectively, you need to keep track of the number of bytes accumulated in the compressed buffer, so that you flush your buffer just before you reach the MTU. Not saying this couldn't be done with LZ4 or something, but it's not a simple matter of accumulating a packet and sending it off to the compressor. > Meaning every babeld implementation needs to embed a gzip decoder (or > you need some feature negotiation mechanism, ahem). Agreed. -- Juliusz From nobody Wed Apr 19 05:24:34 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 8BF7912951B for ; Wed, 19 Apr 2017 05:24:32 -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 mDkxQc--kwx3 for ; Wed, 19 Apr 2017 05:24: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 89025129513 for ; Wed, 19 Apr 2017 05:24:30 -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 v3JCOQKs022980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 Apr 2017 14:24: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 v3JCONH9008336; Wed, 19 Apr 2017 14:24:23 +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 8DAD5D7891; Wed, 19 Apr 2017 14:24:23 +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 e3bK70u3x6Kb; Wed, 19 Apr 2017 14:24:22 +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 0817DD7885; Wed, 19 Apr 2017 14:24:20 +0200 (CEST) Date: Wed, 19 Apr 2017 14:24:28 +0200 Message-ID: <87shl4k2kj.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: babel@ietf.org In-Reply-To: <87pogcmveu.fsf@alrua-x1> References: <87pogduqas.wl-jch@irif.fr> <87pogcmveu.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]); Wed, 19 Apr 2017 14:24:28 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 19 Apr 2017 14:24:26 +0200 (CEST) X-Miltered: at korolev with ID 58F756FA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58F756F7.004 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F756FA.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58F756F7.004 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 : 58F756FA.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58F756F7.004 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] About mandatory bits 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, 19 Apr 2017 12:24:33 -0000 >> Mandatory and non-mandatory sub-TLVs are allocated separately -- mandatory >> sub-TLV 2 does not necessarily have any relation with non-mandatory >> sub-TLV 2. > Is this just to save on sub-TLV numbers? Because I would think it is > bound to create confusion, which is probably not worth the few numbers > we could save on it. After reflexion, I think that Toke has a point, but I'm still in favour of separate allocation, since this avoids ambiguity when sending a mandatory sub-TLV as non-mandatory and vice-versa. How do people feel about that? -- Juliusz From nobody Wed Apr 19 05:31: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 355F6129524 for ; Wed, 19 Apr 2017 05:31:30 -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 e6sUAWQhrHPN for ; Wed, 19 Apr 2017 05:31:28 -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 AF58E127077 for ; Wed, 19 Apr 2017 05:31:28 -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=1492605086; bh=oPY2Fvw+jEunAcz1E+fWOfy61VrYkT9Zx7dJtVOVZW4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=viOr2O4IlqVhmcrW7LqT8s8DCYAmZdxUqF0D81CzzsvWZXmJ6U8rMVJPgjJsXcDmz h+2GIbukHA4LVT6jUhgIjPc7Pyxqt0yMySfHuLid1DbHr5fryCBGbUY+kHbVlRa1xJ HYurzeMGdSVuZAycU7b2nIYNyEj9pU/KAP0fz97vUV/+jTxe8Lstk3Ql54glKIIhnp 1nIk14jvCcUpKM0tev+qhVM7mH95YnWxTx9ihwJ3UULWi5rBNOwuZaCW7j8qM4ZhUJ fv8gSpQvYPqJbOhgKoKt4mEc/FPVft6brFm7z2DLjzbdn95TBCq9XzAnTWGTQOWbz2 4PIeQxB19YFLQ== To: Juliusz Chroboczek Cc: babel@ietf.org References: <87pogduqas.wl-jch@irif.fr> <87pogcmveu.fsf@alrua-x1> <87shl4k2kj.wl-jch@irif.fr> Date: Wed, 19 Apr 2017 14:31:24 +0200 In-Reply-To: <87shl4k2kj.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Wed, 19 Apr 2017 14:24:28 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87r30ok28z.fsf@alrua-kau> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] About mandatory bits 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, 19 Apr 2017 12:31:30 -0000 Juliusz Chroboczek writes: >>> Mandatory and non-mandatory sub-TLVs are allocated separately -- mandatory >>> sub-TLV 2 does not necessarily have any relation with non-mandatory >>> sub-TLV 2. > >> Is this just to save on sub-TLV numbers? Because I would think it is >> bound to create confusion, which is probably not worth the few numbers >> we could save on it. > > After reflexion, I think that Toke has a point, but I'm still in favour of > separate allocation, since this avoids ambiguity when sending a mandatory > sub-TLV as non-mandatory and vice-versa. Shouldn't the mandatory bit just be a part of the allocation? I.e. "sub-tlv XX MUST be sent as mandatory", and setting the bit wrong should be considered a format error? That would be the most unambiguous, in my opinion. If you have another sub-TLV with the same number, you can end up sending something you did not intend to send if you get the bit wrong. E.g., "your timestamp is now a source prefix". That would be bad, I think? :) -Toke From nobody Wed Apr 19 08:08: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 3E128129ADD for ; Wed, 19 Apr 2017 08: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 NbAmhOYTjbSX for ; Wed, 19 Apr 2017 08:08: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 C302C129AD7 for ; Wed, 19 Apr 2017 08:08:02 -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 v3JF7wx3005155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 Apr 2017 17:08:00 +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 v3JF7tJg026545; Wed, 19 Apr 2017 17:07:55 +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 C7A8FD7936; Wed, 19 Apr 2017 17:07:55 +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 kPb1si-g2uSO; Wed, 19 Apr 2017 17:07:54 +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 31CBAD7924; Wed, 19 Apr 2017 17:07:52 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.88) (envelope-from ) id 1d0rCx-0003bW-Tm; Wed, 19 Apr 2017 17:07:52 +0200 Date: Wed, 19 Apr 2017 17:07:51 +0200 Message-ID: <7ivaq0bflk.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: babel@ietf.org In-Reply-To: <87r30ok28z.fsf@alrua-kau> References: <87pogduqas.wl-jch@irif.fr> <87pogcmveu.fsf@alrua-x1> <87shl4k2kj.wl-jch@irif.fr> <87r30ok28z.fsf@alrua-kau> 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, 19 Apr 2017 17:08: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, 19 Apr 2017 17:07:58 +0200 (CEST) X-Miltered: at korolev with ID 58F77D4E.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58F77D4B.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F77D4E.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58F77D4B.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 : 58F77D4E.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58F77D4B.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] About mandatory bits 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, 19 Apr 2017 15:08:04 -0000 > Shouldn't the mandatory bit just be a part of the allocation? I.e. > "sub-tlv XX MUST be sent as mandatory", and setting the bit wrong should > be considered a format error? That would be the most unambiguous, in my > opinion. The way I think of it is TLV numbers 0-127 are non-mandatory; TLV numbers 128-255 are mandatory. > If you have another sub-TLV with the same number, you can end up sending > something you did not intend to send if you get the bit wrong. E.g., > "your timestamp is now a source prefix". That would be bad, I think? :) You're probably going to detect the format error in any case, since the sub-TLV will have the wrong length. So I'm really not convinced that it's worth dividing the space by two. Perhaps somebody else has an opinion? -- Juliusz From nobody Wed Apr 19 08:25: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 079B2129AFC for ; Wed, 19 Apr 2017 08:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMcDjckrQ-nP for ; Wed, 19 Apr 2017 08:25:17 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 14A70129AE5 for ; Wed, 19 Apr 2017 08:25:17 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id y18so18448964wmh.0 for ; Wed, 19 Apr 2017 08:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i8CFIjQT4mGOf8Yr8Mx0jLazkJSK/IbG1X7uubO+c8I=; b=tgWIC6vsU0drY6ZGpcbdEBPAuhm/e+jx08DUAFHvFjI8JTdYUWlnj1oEdzdXkS3ew/ kUGrlMwv9cT95lL9K5mAdDcgQ/xaHi1Q1oUM8MkgYBH87M89pqpB1kSwN04f/aRxUie0 TftpdxyGHL5lo/G7T8Q1+xxxV16lVxHChWCVfvDywRH4O2QrNfWndeCY+5pbEUIw6OHf +LMqVdPkK+hayjAI/TfGHVxQL6qk+jv86BNH/8ez+wTBqOakhvzrCpOHQK8MbDOwOmoD /X7iTwhmIK2RVJa9YPuGlgO1EjAZ9YrsgZcs4HkRG5opJ3ek4nYh1BOrMecawu9WAyiP cuag== 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=i8CFIjQT4mGOf8Yr8Mx0jLazkJSK/IbG1X7uubO+c8I=; b=LV91Taaz147mChRgDswwp3vQN84G02YsdQcrGXtIqOlc4VVVKCerLPcpdNxnWDxc3+ Pdv28P3kzLk0QptGETikSgbky6x0hyxzXzK6mnNSItOc0Oz20gTmxb6oBMmc3ehmdk5p KsvXRL8iwfOkghjlNKg6czy2BajtBGMQdmOZTqHYmFNhbJeo18FqPCP/RT7nhj509RMC 8n5sRNWJ5OsUYhmNOqF95NDQx3/U4xt8CwDJxuKrZv/bSk8dq/ZW+U8NXcY4bEKGIRp9 gfBP09rs0pLCUgvccK+JvxN4nSuorfLu8bZAIYWYEbqaaaLdvRtYSIGtjG7u9bo07FPr 0VtQ== X-Gm-Message-State: AN3rC/45g3fMmEQr8nZlqw92oaCHXjDlIC9yY4JIIfLQ7va3cB4PPfB2 Xq3rPeq/pL26tgtr2A2uYP80755tDMuO X-Received: by 10.28.10.67 with SMTP id 64mr3602809wmk.126.1492615515405; Wed, 19 Apr 2017 08:25:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.159.139 with HTTP; Wed, 19 Apr 2017 08:24:34 -0700 (PDT) In-Reply-To: <7ivaq0bflk.wl-jch@irif.fr> References: <87pogduqas.wl-jch@irif.fr> <87pogcmveu.fsf@alrua-x1> <87shl4k2kj.wl-jch@irif.fr> <87r30ok28z.fsf@alrua-kau> <7ivaq0bflk.wl-jch@irif.fr> From: Gabriel Kerneis Date: Wed, 19 Apr 2017 17:24:34 +0200 Message-ID: To: Juliusz Chroboczek Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Babel at IETF Content-Type: multipart/alternative; boundary=001a11466e5e95ab12054d86a1f5 Archived-At: Subject: Re: [babel] About mandatory bits 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, 19 Apr 2017 15:25:19 -0000 --001a11466e5e95ab12054d86a1f5 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 19, 2017 at 5:07 PM, Juliusz Chroboczek wrote: > > Shouldn't the mandatory bit just be a part of the allocation? I.e. > > "sub-tlv XX MUST be sent as mandatory", and setting the bit wrong should > > be considered a format error? That would be the most unambiguous, in my > > opinion. > > The way I think of it is > > TLV numbers 0-127 are non-mandatory; > TLV numbers 128-255 are mandatory. > This makes sense, and this is how I thought about it too (except 255 is neither mandatory nor non-mandatory, or 127 needs to be reserved too, depending on how you want to deal with mandatory extended TLVs). > > If you have another sub-TLV with the same number, you can end up sending > > something you did not intend to send if you get the bit wrong. E.g., > > "your timestamp is now a source prefix". That would be bad, I think? :) > > You're probably going to detect the format error in any case, since the > sub-TLV will have the wrong length. So I'm really not convinced that it's > worth dividing the space by two. > > Perhaps somebody else has an opinion? > But the problem Toke mentions bothers me too if you think of the mandatory bit as an extra bit of information orthogonal to the TLV number. Since I have not implemented a babel daemon myself, I'm not sure what approach is more natural. A related question is whether would it ever make sense to have a TLV that would sometimes be sent as mandatory and sometimes not (eg. because it would be safe to ignore some of the time based on the surrounding context). If yes, then go with a shared pool. Otherwise, separate allocation makes more sense. Gabriel --001a11466e5e95ab12054d86a1f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 19, 2017 at 5:07 PM, Juliusz Chroboczek <jch@irif.fr> wrot= e:
> Shouldn't th= e mandatory bit just be a part of the allocation? I.e.
> "sub-tlv XX MUST be sent as mandatory", and setting the bit = wrong should
> be considered a format error? That would be the most unambiguous, in m= y
> opinion.

The way I think of it is

=C2=A0 TLV numbers 0-127 are non-mandatory;
=C2=A0 TLV numbers 128-255 are mandatory.

This makes sense, and this is how I thought about it too (except 255 is = neither mandatory nor non-mandatory, or 127 needs to be reserved too, depen= ding on how you want to deal with mandatory extended TLVs).
=C2= =A0
> If you have another sub-TLV with the same number, you can end up sendi= ng
> something you did not intend to send if you get the bit wrong. E.g., > "your timestamp is now a source prefix". That would be bad, = I think? :)

You're probably going to detect the format error in any case, si= nce the
sub-TLV will have the wrong length.=C2=A0 So I'm really not convinced t= hat it's
worth dividing the space by two.

Perhaps somebody else has an opinion?

B= ut the problem Toke mentions bothers me too if you think of the mandatory b= it as an extra bit of information orthogonal to the TLV number. Since I hav= e not implemented a babel daemon myself, I'm not sure what approach is = more natural.

A related question is whether would = it ever make sense to have a TLV that would sometimes be sent as mandatory = and sometimes not (eg. because it would be safe to ignore some of the time = based on the surrounding context). If yes, then go with a shared pool. Othe= rwise, separate allocation makes more sense.

Gabri= el
--001a11466e5e95ab12054d86a1f5-- From nobody Wed Apr 19 09:57: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 C4AE5129B3F for ; Wed, 19 Apr 2017 09:57:17 -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, RCVD_IN_DNSWL_MED=-2.3, 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=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 Vxv34uHpnBwU for ; Wed, 19 Apr 2017 09:57:16 -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 32D8512941D for ; Wed, 19 Apr 2017 09:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1492621035; 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=+2j4lIEGCbE9O9RcUIm1PcULiiYAwZ05cG8Rb4+7IZY=; b=R4k2uNFgJT9Xm/mnVhTZrmMUjcGtlgI+nFK3L9fxM6IhPrSuargfo2I+TjhUZaae 7vbkaQtp0jTHcBUup8x+2J5+S8JgMz9hFG43jgbFxWRppgA2R+vUlXsA9lBCvzV6 sypKiDyGPlxKDm8c+mSkSDqQqY1mMRXGue0C7eGd6gTslisemRcWCptkimWRlXM4 QSR7cPhJMwBqgHoRJVFG+1xIMGSAO+DyhF0X7V9howgUFkQPokA3cabIERxUFlRp ktdPL9I+l5h2yxtevMB44gxtoCCPM4Ve6xb4gR15c614jbw4NDMJDjBvyAfRPvRK hdjxZE6xIpVt2CRTMaNEUg==; 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-in22.apple.com (Apple Secure Mail Relay) with SMTP id 84.BE.05645.AE697F85; Wed, 19 Apr 2017 09:57:15 -0700 (PDT) X-AuditID: 11ab0216-be1fb9a00000160d-b5-58f796ead4bd Received: from kencur (kencur.apple.com [17.151.62.38]) by relay5.apple.com (Apple SCV relay) with SMTP id D3.34.06221.AE697F85; Wed, 19 Apr 2017 09:57:14 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_i5Wv4Lg8QKepmApjWKpEaA)" Received: from [17.153.53.126] (unknown [17.153.53.126]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OOO007P51QY7G90@kencur.apple.com>; Wed, 19 Apr 2017 09:57:14 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Wed, 19 Apr 2017 09:56:55 -0700 In-reply-to: Cc: Juliusz Chroboczek , =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Babel at IETF To: Gabriel Kerneis References: <87pogduqas.wl-jch@irif.fr> <87pogcmveu.fsf@alrua-x1> <87shl4k2kj.wl-jch@irif.fr> <87r30ok28z.fsf@alrua-kau> <7ivaq0bflk.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUi2FAYoft62vcIg63npSy2LOpmsZjfuozN 4s75BewWW9+vYHdg8ViwqdRjyZKfTB6Lt7xl9Nhy6CJbAEsUl01Kak5mWWqRvl0CV8bvdT9Y ClqNKv6eu8LawDhBq4uRg0NCwETiwEOTLkYuDiGBNUwSOy//Zexi5ASLL700nRUisYJR4s6d R2AJXgFBiR+T77GA2MwCYRIH2xqgipqZJOZ9fwyWEBaQlui6cJcVZAObgJbEgTVGEL02Etsu z2SEKNGUOL1tERuIzSKgKvHuxgRmEJtTIFiiZftORpCZzAKtjBIfe7ewgiREBDQk2jr/sUEs u88osfjqOyaIU2Ulbs2+xAySkBBYxi5x7MtPpgmMQrOQXDsLybUQtpbE90etQHEOIFte4uB5 WYiwpsSze5/YIWxtiSfvLrAuYGRbxSicm5iZo5uZZ2Skl1hQkJOql5yfu4kRFDWrmcR2MN57 bXiIUYCDUYmHNyLte4QQa2JZcWXuIUZpDhYlcV7ntG8RQgLpiSWp2ampBalF8UWlOanFhxiZ ODilGhiVrFfvZmn/OU/44DZWj7xSqaJNt3LOcQQIBPwSXPPc9+DfX4/vXSrskr5cu3O/aMei hn3KpYevrDbI7zmqunjPDNYWjgafhbzmYsG3ePh3N58pXs8Y98TI+sHp0qWOlxeGCXyztV1e cCGkUuXyrIeuflnPc52jl8oEnX+Rsb5atYXHddaKN5+VWIozEg21mIuKEwF10MVSewIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIKsWRmVeSWpSXmKPExsUiON1OTffVtO8RBk9OalhsWdTNYjG/dRmb xZ3zC9gttr5fwe7A4rFgU6nHkiU/mTwWb3nL6LHl0EW2AJYoa5u0/KLyxKIUhaLkghJbpeKM xJT88nhLYyNTh8SCgpxUveT8XCV9O5uU1JzMstQiZFaCdcbvdT9YClqNKv6eu8LawDhBq4uR k0NCwERi6aXprF2MXBxCAisYJe7cecQIkuAVEJT4MfkeC4jNLBAmcbCtAaqomUli3vfHYAlh AWmJrgt3gRIcHGwCWhIH1hhB9NpIbLs8kxGiRFPi9LZFbCA2i4CqxLsbE5hBbE6BYImW7TsZ QWYyC7QySnzs3cIKkhAR0JBo6/zHBrHsPqPE4qvvmCBOlZW4NfsS8wRG/llIDpyF5EAIW0vi +6NWoDgHkC0vcfC8LERYU+LZvU/sELa2xJN3F1gXMLKtYhQoSs1JrDTVgwfgJkZQHDUURuxg /L/M6hCjAAejEg9vRNr3CCHWxLLiytxDjBIczEoivKFdQCHelMTKqtSi/Pii0pzU4kOM+xmB 3pzILCWanA+M8rySeENjC2NLEwsDAxNLMxPCwiYmBibGxmbGxuYm5rQUVhLnbU7/EiEkkJ5Y kpqdmlqQWgTzAhMHp1QD45qOh8KLP22+ylmotLijVsXT6W/a4Wazf7a3trbUMiZkb5d+9uzW 1EPhjOJz54fE9m+IjKlZcdmqakqNobLQghBhTe2XjHesBNkSl1bPyfV5vz2bx+SbNc+mVzt9 FpfLLJ3EXz4vcoaBtGBgzhuZuR5f4k/EuN2551M9jzdzssnj6ZOUXJ9wKLEAk7ehFnNRcSIA jCcLK0QDAAA= Archived-At: Subject: Re: [babel] About mandatory bits 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, 19 Apr 2017 16:57:18 -0000 --Boundary_(ID_i5Wv4Lg8QKepmApjWKpEaA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT It feels more natural to me have the mandatory part of the allocation number. It's easier for an implementation to check equality on bytes than 7 bits. I don't think we should divide the space in two. David > On Apr 19, 2017, at 08:24, Gabriel Kerneis wrote: > > On Wed, Apr 19, 2017 at 5:07 PM, Juliusz Chroboczek > wrote: > > Shouldn't the mandatory bit just be a part of the allocation? I.e. > > "sub-tlv XX MUST be sent as mandatory", and setting the bit wrong should > > be considered a format error? That would be the most unambiguous, in my > > opinion. > > The way I think of it is > > TLV numbers 0-127 are non-mandatory; > TLV numbers 128-255 are mandatory. > > This makes sense, and this is how I thought about it too (except 255 is neither mandatory nor non-mandatory, or 127 needs to be reserved too, depending on how you want to deal with mandatory extended TLVs). > > > If you have another sub-TLV with the same number, you can end up sending > > something you did not intend to send if you get the bit wrong. E.g., > > "your timestamp is now a source prefix". That would be bad, I think? :) > > You're probably going to detect the format error in any case, since the > sub-TLV will have the wrong length. So I'm really not convinced that it's > worth dividing the space by two. > > Perhaps somebody else has an opinion? > > But the problem Toke mentions bothers me too if you think of the mandatory bit as an extra bit of information orthogonal to the TLV number. Since I have not implemented a babel daemon myself, I'm not sure what approach is more natural. > > A related question is whether would it ever make sense to have a TLV that would sometimes be sent as mandatory and sometimes not (eg. because it would be safe to ignore some of the time based on the surrounding context). If yes, then go with a shared pool. Otherwise, separate allocation makes more sense. > > Gabriel > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --Boundary_(ID_i5Wv4Lg8QKepmApjWKpEaA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
It feels more natural to me have the = mandatory part of the allocation number.
It's = easier for an implementation to check equality on bytes than 7 = bits.
I don't think we should divide the space in = two.

David


On = Apr 19, 2017, at 08:24, Gabriel Kerneis <kerneis@google.com> = wrote:

On Wed, Apr 19, 2017 at 5:07 PM, Juliusz = Chroboczek <jch@irif.fr> wrote:
> = Shouldn't the mandatory bit just be a part of the allocation? I.e.
> "sub-tlv XX MUST be sent as mandatory", and setting the bit wrong = should
> be considered a format error? That would be the most unambiguous, = in my
> opinion.

The way I think of it is

  TLV numbers 0-127 are non-mandatory;
  TLV numbers 128-255 are mandatory.

This makes sense, and = this is how I thought about it too (except 255 is neither mandatory nor = non-mandatory, or 127 needs to be reserved too, depending on how you = want to deal with mandatory extended TLVs).
 
> If you have another sub-TLV with the same number, you can end up = sending
> something you did not intend to send if you get the bit wrong. = E.g.,
> "your timestamp is now a source prefix". That would be bad, I = think? :)

You're probably going to detect the format error in any case, = since the
sub-TLV will have the wrong length.  So I'm really not convinced = that it's
worth dividing the space by two.

Perhaps somebody else has an opinion?

But the problem Toke = mentions bothers me too if you think of the mandatory bit as an extra = bit of information orthogonal to the TLV number. Since I have not = implemented a babel daemon myself, I'm not sure what approach is more = natural.

A = related question is whether would it ever make sense to have a TLV that = would sometimes be sent as mandatory and sometimes not (eg. because it = would be safe to ignore some of the time based on the surrounding = context). If yes, then go with a shared pool. Otherwise, separate = allocation makes more sense.

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

= --Boundary_(ID_i5Wv4Lg8QKepmApjWKpEaA)-- From nobody Wed Apr 19 12:14: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 D14E812945A for ; Wed, 19 Apr 2017 12:14: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 grmfz34re5vI for ; Wed, 19 Apr 2017 12:14: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 8516D129C12 for ; Wed, 19 Apr 2017 12:14: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 v3JJEHQu014412; Wed, 19 Apr 2017 21:14: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 B3C27D78E4; Wed, 19 Apr 2017 21:14: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 ZH9w_6Xcl1Zv; Wed, 19 Apr 2017 21:14: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 B7B09D7885; Wed, 19 Apr 2017 21:14:16 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.88) (envelope-from ) id 1d0v3Q-000425-GA; Wed, 19 Apr 2017 21:14:16 +0200 Date: Wed, 19 Apr 2017 21:14:16 +0200 Message-ID: <7iinm0b46v.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]); Wed, 19 Apr 2017 21:14:17 +0200 (CEST) X-Miltered: at korolev with ID 58F7B709.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F7B709.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 : 58F7B709.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] Mandatory bits in babeld 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, 19 Apr 2017 19:14:22 -0000 Hi, I've just done a first draft of mandatory bits in babeld. The code is in branch "mandatory" of the github repository. It doesn't look *that* bad. If nobody objects too loudly, I'm going to write the protocol up in the rfc6126bis draft, then merge the mandatory branch into master. Please scream loudly now, or forever hold your peace. -- Juliusz From nobody Wed Apr 19 15:03: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 7C6AF129445 for ; Wed, 19 Apr 2017 15:03:53 -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 ZWbCwoXvd-cP for ; Wed, 19 Apr 2017 15:03:52 -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 E8F29127010 for ; Wed, 19 Apr 2017 15:03:51 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v3JM3lLK010234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Apr 2017 00:03:49 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id v3JM3iB3019321; Thu, 20 Apr 2017 00:03:44 +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 514F0D7891; Thu, 20 Apr 2017 00:03:44 +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 rMmkYx4SEtfc; Thu, 20 Apr 2017 00:03:43 +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 494A5D7885; Thu, 20 Apr 2017 00:03:38 +0200 (CEST) Date: Thu, 20 Apr 2017 00:03:46 +0200 Message-ID: <87lgqwawcd.wl-jch@irif.fr> From: Juliusz Chroboczek To: Gabriel Kerneis Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , Babel at IETF In-Reply-To: References: <87pogduqas.wl-jch@irif.fr> <87pogcmveu.fsf@alrua-x1> <87shl4k2kj.wl-jch@irif.fr> <87r30ok28z.fsf@alrua-kau> <7ivaq0bflk.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]); Thu, 20 Apr 2017 00:03:49 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 20 Apr 2017 00:03:47 +0200 (CEST) X-Miltered: at korolev with ID 58F7DEC3.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58F7DEC0.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F7DEC3.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58F7DEC0.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 : 58F7DEC3.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58F7DEC0.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] About mandatory bits 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, 19 Apr 2017 22:03:53 -0000 > The way I think of it is > TLV numbers 0-127 are non-mandatory; > TLV numbers 128-255 are mandatory. > This makes sense, and this is how I thought about it too (except 255 is > neither mandatory nor non-mandatory, or 127 needs to be reserved too, The latter. The plan is: 0 -- special format (Pad1); 1-111 -- non-mandatory, specification required; 112-126 -- non-mandatory, local and experimental use; 127 -- reserved for expansion of the non-mandatory space; 128-239 -- mandatory, specification required; 240-254 -- mandatory, local and experimental use; 255 -- reserved for expansion of the mandatory space. For what it's worth, Gwendoline is currently using 240. > depending on how you want to deal with mandatory extended TLVs). Oh, I think they need to have the mandatory bit at the same place, hence the 127/255 scheme above. If you have other suggestions, I listen. > But the problem Toke mentions bothers me too if you think of the mandatory > bit as an extra bit of information orthogonal to the TLV number. Since I have > not implemented a babel daemon myself, I'm not sure what approach is more > natural. As David mentioned, the natural thing is to match on the whole type octet. The implementation I just posted does something like: while(i < whatever) { type = buf[i]; len = buf[i + 1]; switch(type) { ... default: if((type & 0x80) != 0) return -1; } i += len + 2; } Not a big deal, but the natural way to deal with it. > A related question is whether would it ever make sense to have a TLV > that would sometimes be sent as mandatory and sometimes not Interesting idea. I'll tell you if something comes to mind. -- Juliusz From nobody Wed Apr 19 15:11:29 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 0F5AB128708 for ; Wed, 19 Apr 2017 15:11:28 -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 w7JT318Uyx_q for ; Wed, 19 Apr 2017 15:11: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 2D1AF129457 for ; Wed, 19 Apr 2017 15:11:26 -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 v3JMBOix016177 for ; Thu, 20 Apr 2017 00:11:24 +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 98698D78E4 for ; Thu, 20 Apr 2017 00:11:24 +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 X54N6CxvgwV4 for ; Thu, 20 Apr 2017 00:11:23 +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 8A884D7891 for ; Thu, 20 Apr 2017 00:11:23 +0200 (CEST) Date: Thu, 20 Apr 2017 00:11:32 +0200 Message-ID: <87h91kavzf.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]); Thu, 20 Apr 2017 00:11:24 +0200 (CEST) X-Miltered: at korolev with ID 58F7E08C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F7E08C.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 : 58F7E08C.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] About unicast 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: Wed, 19 Apr 2017 22:11:28 -0000 Is anyone working on unicast Hellos? We'd really need implementation experience before we can write it down. Open issues: - new TLV or bit in Reserved; - what's the exact semantics of interval=0? (Support for interval=0 is required, since we really do want to be able to send an occasional unicast Hello while doing link quality over multicast, especially when simultaneously doing RTT estimation.) -- Juliusz From nobody Thu Apr 20 02:05: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 2380512EBAE for ; Thu, 20 Apr 2017 02:05:52 -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 XE3x5_J5xLW6 for ; Thu, 20 Apr 2017 02:05:48 -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 9105212EBAD for ; Thu, 20 Apr 2017 02:05:48 -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=1492679145; bh=N/CQ0DmIUV09RllSjUQrhI0FVX2MRe37z2Yx5bf8AXs=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=cAfu++7zDH/myzqux5WgMKYNl6nHoOHGDLhPwSQTN9x1CegGTjlT3VFBaEbDZiibP 6sLD9kVFN+MT7qS33A5AunIVkFPU+PAJdJI4L8zzS6m2D90D2UC9ey+PFDOyJ6WO6w 4ZL8j32rPrrVQOWB0/DqYYcpY0lAz2YjCl6/spp8kwki3SLqEm3+a5DdhpjwbNBvnK aL9votF91+cPsD+kZXqPWIHGI3r6l7qks0QKlf7qLmAoJgySc7VkPYMjLdTx3Canyq HlH/iVmu3eMxxRSGKKueory64CeKk9okW/4kaC09naiocpcAiTM7fSC8rpSd1KWyEN UPjd85U3qmmPA== To: Juliusz Chroboczek Cc: babel@ietf.org References: <87pogduqas.wl-jch@irif.fr> <87pogcmveu.fsf@alrua-x1> <87shl4k2kj.wl-jch@irif.fr> <87r30ok28z.fsf@alrua-kau> <7ivaq0bflk.wl-jch@irif.fr> Date: Thu, 20 Apr 2017 11:05:43 +0200 In-Reply-To: <7ivaq0bflk.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Wed, 19 Apr 2017 17:07:51 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87r30n30uw.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] About mandatory bits 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, 20 Apr 2017 09:05:52 -0000 Juliusz Chroboczek writes: >> Shouldn't the mandatory bit just be a part of the allocation? I.e. >> "sub-tlv XX MUST be sent as mandatory", and setting the bit wrong should >> be considered a format error? That would be the most unambiguous, in my >> opinion. > > The way I think of it is > > TLV numbers 0-127 are non-mandatory; > TLV numbers 128-255 are mandatory. Ah, right. Gotcha. I was thinking of it basically like this: bool mandatory = tlv[0] & 0x80 u8 type = tlv[0] & 0x7f where the contents of type would be what was specified in the RFC. That would lead to two different "TLV type 2" being defined. But if it's defined in terms of ranges of TLV numbers I see no problem in assigning them separately :) -Toke From nobody Thu Apr 20 12:08:52 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 93CBB131553; Thu, 20 Apr 2017 12:08:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org, akatlas@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149271532951.22369.2216208388630657588.idtracker@ietfa.amsl.com> Date: Thu, 20 Apr 2017 12:08:49 -0700 Archived-At: Subject: [babel] babel - New Meeting Session Request 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: Thu, 20 Apr 2017 19:08:50 -0000 A new meeting session request has just been submitted by Donald E. Eastlake 3rd, a Chair of the babel working group. --------------------------------------------------------- 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: manet homenet lpwan idr rtgwg netmod netconf 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 Thu Apr 20 13:18:30 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 46D26129C19; Thu, 20 Apr 2017 13:18:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org, akatlas@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149271950819.22277.6463624335407031368.idtracker@ietfa.amsl.com> Date: Thu, 20 Apr 2017 13:18:28 -0700 Archived-At: Subject: [babel] babel - Update to a Meeting Session Request 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: Thu, 20 Apr 2017 20:18:28 -0000 An update to a meeting session request has just been submitted by Donald E. Eastlake 3rd, a Chair of the babel working group. --------------------------------------------------------- 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: manet homenet lpwan idr rtgwg netmod netconf 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 Sat Apr 22 05:19: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 E9181129C04 for ; Sat, 22 Apr 2017 05:19:48 -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 QyiQAzeLgDJV for ; Sat, 22 Apr 2017 05:19:46 -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 9CE25129BEE for ; Sat, 22 Apr 2017 05:19:46 -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 v3MCJhl4019984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 22 Apr 2017 14:19:43 +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 v3MCJhNJ017907 for ; Sat, 22 Apr 2017 14:19:43 +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 7485FD7935 for ; Sat, 22 Apr 2017 14:19:43 +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 oPH41G-FqEzH for ; Sat, 22 Apr 2017 14:19:42 +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 790DAD793F for ; Sat, 22 Apr 2017 14:19:41 +0200 (CEST) Date: Sat, 22 Apr 2017 14:19:53 +0200 Message-ID: <87zif8d47q.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]); Sat, 22 Apr 2017 14:19:43 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 22 Apr 2017 14:19:43 +0200 (CEST) X-Miltered: at korolev with ID 58FB4A5F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58FB4A5F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58FB4A5F.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58FB4A5F.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 : 58FB4A5F.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58FB4A5F.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] Mandatory bits and compression 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, 22 Apr 2017 12:19:49 -0000 Hi, I've received a few worried mails about the interaction of compression and mandatory bits, please let me describe my thoughts on the subject. There's a slight contradiction between mandatory bits and compression. On the one hand, the effect of mandatory bits is to ignore a subset of TLVs, a subset that depends on the implementation. On the other hand, the compression state must be the same on all implementations, no matter which TLVs are ignored. Hence, there are three possibilities: 1. Deprecate compression. An implementation MUST NOT send compressed TLVs, although of course it MAY implement decompression for compatibility with RFC 6126. An effect is that compression and mandatory bits will never appear in the same packet. 2. Limit compression. A TLV with a mandatory bit MUST NOT change the compression state. 3. Put compression "below" mandatory bits, in the sense that a TLV does change the compression state even if it gets ignored due to a mandatory bit. Now it turns out that (2) is very difficult to specify -- the conditions that ensure that an Update gets parsed identically no matter which TLVs get ignored are not easy to write up, so unless somebody has a smart idea, we're left with (1) and (3). (3) is surprising at first, but it's actually very easy to implement. In order to find the first sub-TLV, you must parse the compressed prefix. So what you do is: - parse the compressed prefix and update compression state; - parse all sub-TLVs; - use the prefix or drop it, depending on the mandatory bits. That's only a slight change from what happens without mandatory bits: - parse the compressed prefix and update compression state; - parse all sub-TLVs; - use the prefix. Because it's so natural from an implementation point of view, my current plan is to try to specify (3) precisely, and see how it goes. However, I've been known to change my mind before (I used to be strongly opposed to mandatory bits until last week-end, for one), so please don't hesitate to tell me if you hold a different opinion. -- Juliusz From nobody Mon Apr 24 10:28: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 06CBB1318D2 for ; Mon, 24 Apr 2017 10:28:03 -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_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 YnDnZ92gXm_n for ; Mon, 24 Apr 2017 10:28:01 -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 3475A1318CF for ; Mon, 24 Apr 2017 10:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1493054880; 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=1bupL0bdKjLHTNpGGnYytj8M1rbvdG3wyDR1nd17KoE=; b=iGFquoMZwSTBRskofukKraiXEFhIx9uWbFKFL0QgTjqKCn1s4YeejnutBUL+oUxf UuCcu0xA5dpG3mZNYYoHJz6uB/ZyDd2EcfeL0eu1lt4uL8ib9VU0wACpoSf8DBGi +Up2G1pP297qWWCmLGTWERy2s6zm883gqoiPBXaLrqJYBO8WjVUgRDeHPjmTuT4k T1GqXZfuE6mVddk2lVacXNH7UrWgLJVFmUUjg7Z8PJh73uK0UeBi7krwK/d32D0q 4kT14KTzNsN7RxYiNWW8X5+i0JhvMCaAYJAEaTk2KS3Pf1F5kSYyTrfimRTQomLq hmM3iOBhNR7lGloxRNLP2w==; 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-in21.apple.com (Apple Secure Mail Relay) with SMTP id 3C.67.00415.0A53EF85; Mon, 24 Apr 2017 10:28:00 -0700 (PDT) X-AuditID: 11ab0215-5afd59a00000019f-a5-58fe35a0457f Received: from koseret (koseret.apple.com [17.151.62.39]) by relay5.apple.com (Apple SCV relay) with SMTP id 4F.AC.28467.F953EF85; Mon, 24 Apr 2017 10:28:00 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.32.160] (unknown [17.153.32.160]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OOX0001SCILJG40@koseret.apple.com>; Mon, 24 Apr 2017 10:27:59 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87zif8d47q.wl-jch@irif.fr> Date: Mon, 24 Apr 2017 10:27:56 -0700 Cc: babel@ietf.org Message-id: <64E65CB4-6FB2-4807-A62B-C4D7F62BABAB@apple.com> References: <87zif8d47q.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUi2FAYobvA9F+EQf9fKYsti7pZLOa3LmNz YPJYsuQnk8fiLW8ZA5iiuGxSUnMyy1KL9O0SuDIe/D7NWvBRuKJ/6U3mBsZD/F2MnBwSAiYS 2+9NYO9i5OIQEljDJLHoXTMjXOLZH1aIxCpGiTUXesASvAKCEj8m32PpYuTgYBaQlzh4XhYk zCygJfH9USsLRH0rk0Tns3esIAlhAWmJrgt3oWxjiacbephAetmAGg6sMQIJcwpoSFw52MkG YrMIqEp0X9vNAjFTSOLMtRksEGttJN7MuQ12gpCAukTvwdfMILaIgIrE8mnP2CFulpW4NfsS M4S9hE3icpPmBEbhWUiunoVw9SwkVy9gZF7FKJybmJmjm5lnZKiXWFCQk6qXnJ+7iREU2KuZ RHcwzn9leIhRgINRiYf3gPG/CCHWxLLiytxDjNIcLErivOW6QCGB9MSS1OzU1ILUovii0pzU 4kOMTBycUg2M/px1Dgc+JPFVi9+ft+shI8NODZV3bqu57ot377U+HLim9tKH5V8qSh5mbI7g rpKRX/nI+8fpnLkPHqzXkDdsiXxVdWXL2gsKGWK+co/uLVx3xPNk1OUT27kMMpXr1bNXvGv7 PI1h8dMbHqa97lqFMbGNRf07UkTOrrzewHlz0kL1CUfW/4i/ocRSnJFoqMVcVJwIACoQGQRN AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42IRnG6nrrvA9F+EwWEniy2Lulks5rcuY3Ng 8liy5CeTx+ItbxkDmKK4bFJSczLLUov07RK4Mh78Ps1a8FG4on/pTeYGxkP8XYycHBICJhLb n/1h7WLk4hASWMUoseZCDyNIgldAUOLH5HssXYwcHMwC8hIHz8uChJkFtCS+P2plgahvZZLo fPaOFSQhLCAt0XXhLpRtLPF0Qw8TSC8bUMOBNUYgYU4BDYkrBzvZQGwWAVWJ7mu7WSBmCkmc uTaDBWKtjcSbObfBThASUJfoPfiaGcQWEVCRWD7tGTvEzbISt2ZfYp7AKDALyaWzEC6dheTS BYzMqxgFilJzEitN9RILCnJS9ZLzczcxgsKwoTBiB+P/ZVaHGAU4GJV4eDuY/kUIsSaWFVfm HmKU4GBWEuFtkgQK8aYkVlalFuXHF5XmpBYfYqwCun8is5Rocj4wRvJK4g1NTAxMjI3NjI3N TcypIqwkzlukDbRZID2xJDU7NbUgtQhmORMHp1QD43wGk8dBLw5aCsxRTbbZ3rbzu9+Zo9eZ HdTcbdVap3DPEeHaYzPJj31V/nTN9WW7F3/KmBJuK+HIz6EW4ma+0HLCjvrO5Wby0tfUdrJF 7DCL6Q40KFl4UfmK1WlvSxeJE3xvdbacYjNhCty/S42ZL2f3skadTVf1PrYViCxclmT5ODhu v+R2JZbijERDLeai4kQAa859Gp4CAAA= Archived-At: Subject: Re: [babel] Mandatory bits and compression 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, 24 Apr 2017 17:28:03 -0000 I agree, option 3 feels natural, powerful, and easy to implement. David > On Apr 22, 2017, at 05:19, Juliusz Chroboczek wrote: > > Hi, > > I've received a few worried mails about the interaction of compression and > mandatory bits, please let me describe my thoughts on the subject. > > There's a slight contradiction between mandatory bits and compression. On > the one hand, the effect of mandatory bits is to ignore a subset of TLVs, > a subset that depends on the implementation. On the other hand, the > compression state must be the same on all implementations, no matter which > TLVs are ignored. Hence, there are three possibilities: > > 1. Deprecate compression. An implementation MUST NOT send compressed > TLVs, although of course it MAY implement decompression for > compatibility with RFC 6126. An effect is that compression and > mandatory bits will never appear in the same packet. > > 2. Limit compression. A TLV with a mandatory bit MUST NOT change the > compression state. > > 3. Put compression "below" mandatory bits, in the sense that a TLV does > change the compression state even if it gets ignored due to > a mandatory bit. > > Now it turns out that (2) is very difficult to specify -- the conditions > that ensure that an Update gets parsed identically no matter which TLVs > get ignored are not easy to write up, so unless somebody has a smart idea, > we're left with (1) and (3). > > (3) is surprising at first, but it's actually very easy to implement. In > order to find the first sub-TLV, you must parse the compressed prefix. So > what you do is: > > - parse the compressed prefix and update compression state; > - parse all sub-TLVs; > - use the prefix or drop it, depending on the mandatory bits. > > That's only a slight change from what happens without mandatory bits: > > - parse the compressed prefix and update compression state; > - parse all sub-TLVs; > - use the prefix. > > Because it's so natural from an implementation point of view, my current > plan is to try to specify (3) precisely, and see how it goes. However, > I've been known to change my mind before (I used to be strongly opposed to > mandatory bits until last week-end, for one), so please don't hesitate to > tell me if you hold a different opinion. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Wed Apr 26 15:11: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 2AFB3126CE8 for ; Wed, 26 Apr 2017 15:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 S6-HyMezkRuu for ; Wed, 26 Apr 2017 15:11:51 -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 F2E2B1270FC for ; Wed, 26 Apr 2017 15:11:50 -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 v3QMBmjX001631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Apr 2017 00:11:48 +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 v3QMBmY0012230; Thu, 27 Apr 2017 00:11:48 +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 249CED789E; Thu, 27 Apr 2017 00:11:48 +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 LODL1KVtzO-b; Thu, 27 Apr 2017 00:11:47 +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 4B0B7D789F; Thu, 27 Apr 2017 00:11:46 +0200 (CEST) Date: Thu, 27 Apr 2017 00:12:02 +0200 Message-ID: <87fuguom31.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org Cc: babel-users@lists.alioth.debian.org In-Reply-To: <7iinm0b46v.wl-jch@irif.fr> References: <7iinm0b46v.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]); Thu, 27 Apr 2017 00:11:48 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 27 Apr 2017 00:11:48 +0200 (CEST) X-Miltered: at korolev with ID 59011B24.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 59011B24.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59011B24.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 59011B24.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 : 59011B24.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 59011B24.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] Mandatory bits in babeld 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, 26 Apr 2017 22:11:53 -0000 > I've just done a first draft of mandatory bits in babeld. The code is in > branch "mandatory" of the github repository. It doesn't look *that* bad. Matthieu and Gwendoline have fixed some bugs, so if you're tracking that branch, please pull. -- Juliusz From nobody Fri Apr 28 12:48: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 52047129484 for ; Fri, 28 Apr 2017 12:47:58 -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 a-KZVS6nNAdp for ; Fri, 28 Apr 2017 12:47:55 -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 34DFF129488 for ; Fri, 28 Apr 2017 12:46:54 -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 v3SJkqw8007204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Apr 2017 21:46: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 v3SJkq2Q008358; Fri, 28 Apr 2017 21:46: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 762C6D7935; Fri, 28 Apr 2017 21:46: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 cKCIeUuPAGsr; Fri, 28 Apr 2017 21:46:51 +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 283CBD78B7; Fri, 28 Apr 2017 21:46:51 +0200 (CEST) Date: Fri, 28 Apr 2017 21:47:07 +0200 Message-ID: <8737cs1fic.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org, babel-users@lists.alioth.debian.org References: <441b9bbe-c05b-8db3-6aac-01c5ffef5f6c@bellis.me.uk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: message/rfc822 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, 28 Apr 2017 21:46:52 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 28 Apr 2017 21:46:52 +0200 (CEST) X-Miltered: at korolev with ID 59039C2C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 59039C2C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59039C2C.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 59039C2C.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 : 59039C2C.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 59039C2C.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] Fwd: [homenet] Mailing list for Homenet Babel Security design team 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, 28 Apr 2017 19:47:58 -0000 Delivered-To: jch@irif.fr DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1493394947; bh=pl3Ic6mSvqk0ssD08i7zULAv5pIYGxjvyC7CUTP6WkY=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=nwBTO6vLU096qMJLYzPGQhdBjB88CVnCgH6zH4l0KH9lU9bIhfQh6qgEsjbqKelvT xNiiQzhxRy/GCod7TBH/oGKuU44JmMukBiA7/WSkJ//i+qcFCvWtaG639UuTuhEJVg MzEWdAWUEQcuVdjkYxXiP8+jQ+s2iowcOlnjlPNs= X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com To: HOMENET From: Ray Bellis Message-ID: <441b9bbe-c05b-8db3-6aac-01c5ffef5f6c@bellis.me.uk> Date: Fri, 28 Apr 2017 16:52:20 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Archived-At: Subject: [homenet] Mailing list for Homenet Babel Security design team X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: homenet-bounces@ietf.org Sender: "homenet" There is now a mailing list for the design team specifying the integration of HNCP and Babel security. The list address is homenet-babel-sec@ietf.org We have added those people that had initial discussions around this during IETF 97. Ray and Mark _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet