Re: [mif] AD review of MPVD Architecture ***feedback needed from MIF working group participants ***

Ted Lemon <Ted.Lemon@nominum.com> Wed, 14 January 2015 15:58 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BF51A8954 for <mif@ietfa.amsl.com>; Wed, 14 Jan 2015 07:58:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 oGDy6aFQPQ6A for <mif@ietfa.amsl.com>; Wed, 14 Jan 2015 07:58:11 -0800 (PST)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.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 97DDD1A8832 for <mif@ietf.org>; Wed, 14 Jan 2015 07:58:11 -0800 (PST)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 7E88BDA00D6 for <mif@ietf.org>; Wed, 14 Jan 2015 15:58:11 +0000 (UTC)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 6804053E07C; Wed, 14 Jan 2015 07:58:11 -0800 (PST)
Received: from divertimento.ddns.nominum.com (64.89.225.28) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 14 Jan 2015 07:58:11 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <CACurXJgLxXBud27b+CnQNkrXBJkunJ_x5J7iKa8A3+OsmMHJBQ@mail.gmail.com>
Date: Wed, 14 Jan 2015 07:58:04 -0800
Content-Transfer-Encoding: quoted-printable
Message-ID: <931A7C39-6DAE-43C0-BF2E-3B6DC08F1F5A@nominum.com>
References: <9071C858-BBCA-483C-94CD-E7C2584980F0@nominum.com> <CACurXJhq5PyogN=J-kHBjqiNO1VTFsm_F9e-YdK+Q9Zqy_pKjw@mail.gmail.com> <27E34197-0DCA-4328-98A8-CD5C1A3534A9@nominum.com> <CACurXJgLxXBud27b+CnQNkrXBJkunJ_x5J7iKa8A3+OsmMHJBQ@mail.gmail.com>
To: Dmitry Anipko <dmitry.anipko@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [64.89.225.28]
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/xb1cAWhVTR9soNACgubXuxc8IgQ>
Cc: "mif@ietf.org List" <mif@ietf.org>
Subject: Re: [mif] AD review of MPVD Architecture ***feedback needed from MIF working group participants ***
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jan 2015 15:58:13 -0000

On Jan 13, 2015, at 11:17 PM, Dmitry Anipko <dmitry.anipko@gmail.com> wrote:
> My best recollection is that the contributors believed that there may be a need to deploy multiple PVDs, applicable to different nodes/node groups, and hence to avoid having to do broadcast propagation of all of those, a node could have an ability to specify which ones the node is capable to understand.

That sounds highly problematic.   How does the node know which pvds to list for a particular network?   What about the privacy implications?   I think this should just be taken out of the architecture and left as future work when someone is enthusiastic and has a use case for it.