IETF Logo Mail Archive

Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host

Ole Troan <otroan@employees.org> Tue, 04 July 2017 20:36 UTC

Return-Path: <otroan@employees.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FF9131754 for <v6ops@ietfa.amsl.com>; Tue, 4 Jul 2017 13:36:06 -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 FWTpwRrwM1Yw for <v6ops@ietfa.amsl.com>; Tue, 4 Jul 2017 13:36:04 -0700 (PDT)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0DB613171C for <v6ops@ietf.org>; Tue, 4 Jul 2017 13:36:04 -0700 (PDT)
Received: from [10.221.197.128] (77.16.69.128.tmi.telenormobil.no [77.16.69.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id F23952D502B; Tue, 4 Jul 2017 20:36:01 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Ole Troan <otroan@employees.org>
X-Mailer: iPhone Mail (14G5057a)
In-Reply-To: <c00acac9-da2e-0952-1c56-134813620dd7@gmail.com>
Date: Tue, 04 Jul 2017 22:35:56 +0200
Cc: Ted Lemon <mellon@fugue.com>, v6ops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A1B0327-CAA2-40B6-8BC2-30586A64E8AD@employees.org>
References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es> <CAKD1Yr1UNvfrozET0Ay4LCtZe-NSBAGwbCcpye7JhGtpzyT2Sg@mail.gmail.com> <645EA227-F9E8-4B15-878B-83BC8FD9809A@employees.org> <DCB3CF45-C552-4A37-B7A2-E90C080170BD@fugue.com> <07EE34C2-A479-41EB-B983-D8F2D585E306@employees.org> <071E625C-7B68-4E9F-98C6-262A1052CBF1@fugue.com> <310527F9-C27E-4EA0-B655-9B20878DC459@employees.org> <3cc51f51-139d-940d-bf05-6e449528f8b1@gmail.com> <F8DA8CE5-7D8A-4513-8F1B-601AB96141D6@employees.org> <C62AC675-F128-45A5-8F72-A54144AD7C09@fugue.com> <1E8426B8-1622-42EF-97E2-D81F70A78493@employees.org> <958452FD-2F9F-4057-BCB9-D62F2DC2127A@fugue.com> <2254408d-0382-fda6-aabf-2fefe033c4cc@gmail.com> <ACE9A0A9-33D4-4C64-BE28-80E2FB9D8646@employees.org> <c00acac9-da2e-0952-1c56-134813620dd7@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/t5407-yL_fhuoWC_3qwfaeNiqBM>
Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jul 2017 20:36:06 -0000

Brian,

>> Since we have to solve the problem for multiple links anyway, does it then make a difference that logical topology follows physical topology and each host is on its own link?
> 
> If the discovery traffic is a very small proportion of total traffic, it probably doesn't matter exactly which solution you adopt. But (as Tim implies for DNSSD), I think you should use link-local multicast when it's available. Are we disagreeing?

Are you implying there are links where link-local multicast aren't available?
If course on the link type I describe there is ever only two nodes connected. 

If we can't do better than require every link to have a service discovery "helper" then sure link-local multicast is fine ( benefit is well known addresses).

Ole

v2.23.0 | Report a Bug | By Email