[Int-area] Comments on current MPvD draft.

Ted Lemon <mellon@fugue.com> Wed, 15 November 2017 06:52 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFA11274D0 for <int-area@ietfa.amsl.com>; Tue, 14 Nov 2017 22:52:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6yM6Gck2U_U for <int-area@ietfa.amsl.com>; Tue, 14 Nov 2017 22:52:31 -0800 (PST)
Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93EF51270A0 for <int-area@ietf.org>; Tue, 14 Nov 2017 22:52:31 -0800 (PST)
Received: by mail-pg0-x22b.google.com with SMTP id s75so17354792pgs.0 for <int-area@ietf.org>; Tue, 14 Nov 2017 22:52:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=SRybZO0wv+O1zgGEHbWVOS5XJXOrx6R+lO0AcuJCgI0=; b=O00Gah5T1L7nPE+OVOt3JROZaWQuqsj3cyoFYLG79q+ZwFntMQoejjqKPi5T76XPBQ bHtbaf6l94AiVMz3p97XYcdeEqkAdn2mSoJQZIHFPYMhgGc1MfU2d2uXEHnaqRhA5fAk +8yGuZwpgfPJNvxDSkhZ9R0E38SPJWf4Raldz9p3EC/VJksvCHD/4P+3HZJUZ9xa9VWb HY5IXihZhng4kpfptwuPdLeo28WGzZPcNdpb/qLUttHp4yLT18YpcmVnflk00+3N+BfW +MWMYftPeWc4UrkYzvzPve5Qmd7uEnLiqRlXu9irCcVPIhMAdmjd++n+PFN1qExNcBgM XVqw==
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:message-id:date:to; bh=SRybZO0wv+O1zgGEHbWVOS5XJXOrx6R+lO0AcuJCgI0=; b=dbrYhlsiyYaf4t5hco84cUzjZtbHMiKDVpg7xYWmnpF3abeYW4LdfDeSHZ3oukAQrz TYpXs+5U2VY7REPT1qQmkPnHpoPhuRksh9Hj2mHMyXFMWZWfc5QLTfTFIsllRglxZQQz X7QXYC0p9FkpZg7NfAe+/1J+z0IYGWwZvW5agp2wUhL5rnr8JzrjHia8usU4TWwfm2qh 7fyS66Z77QhcmktsCsskrXadvzSI62g6K9ejfLXB3g6lGLMpx5cZRHNx+ArZ5euBEDTj EIizYyqLXHnx0dCN2JGo0p5au9X6r8zGCN1zDdBD2qtIKBSXhSkkvVgnU04vjTlJTrhi C6xQ==
X-Gm-Message-State: AJaThX7smBdzKe18LPH2Wf8bJytjpEBgsggNfE+HVk7h+tscVCVSIj06 02fXlytSpdin+jIbn7iTLjANUGGgSXM=
X-Google-Smtp-Source: AGs4zMbHXPesAEd3GbP5EymV0WTp/SXakGcivYMNnXHApUocU6/y4dPju9gA1KHG48TmTByxLXCQAQ==
X-Received: by 10.98.73.196 with SMTP id r65mr16288884pfi.169.1510728750920; Tue, 14 Nov 2017 22:52:30 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:961:9ce7:8fd5:1ecf? ([2001:67c:370:1998:961:9ce7:8fd5:1ecf]) by smtp.gmail.com with ESMTPSA id p87sm24792241pfi.95.2017.11.14.22.52.29 for <int-area@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 22:52:30 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_139E496D-B1A5-405C-A672-0D57C9CD2E3F"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <45957315-A9A2-4E11-9069-5C41C7397034@fugue.com>
Date: Wed, 15 Nov 2017 14:52:27 +0800
To: int-area <int-area@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/87PIzEleNEsT6-E5z7LogilpadI>
Subject: [Int-area] Comments on current MPvD draft.
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2017 06:52:33 -0000

I'd like to have a bit of discussion today on the architectural choices in the current draft, if possible.

There are two issues I want to discuss:
The assumption that each PvD will have its own router
The expected behavior of hosts that do not support MPvD in the presence of multiple routers

The first assumption is problematic in the sense that in most cases (I think), it will actually be the case that the multiple provisioning domains will both be on the other side of a leaf router from the host that is accessing them.   In this case, requiring multiple RAs with different link-local addresses is fairly heavyweight.

The second issue isn't, strictly speaking, an MPvD problem, but I think it implicates MPvD because I think the behavior in this case is undefined.   E.g., if both routers advertise a set of name servers, what does the host do?

We've been looking at this in Homenet, and this came up as a serious concern: if the host chooses one set of name servers, it may not be able to access services in the other PvD.  And yet if the host does support MPvD, we kind of want it to use different name servers per PvD.   So what we concluded is that we want to be able to give hosts that do not support MPvD a clear answer that is different than the answer we give out for each PvD.

This would not be possible with the current proposal.   It's not a hard problem to solve, but we need to consider whether or not, and how, to solve it.