Re: [mif] FW: I-D Action: draft-ietf-mif-mpvd-arch-03.txt

Dmitry Anipko <> Sun, 10 August 2014 03:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 223E61A0414 for <>; Sat, 9 Aug 2014 20:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t7XYHuD3CZNz for <>; Sat, 9 Aug 2014 20:23:38 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00E1E1A040F for <>; Sat, 9 Aug 2014 20:23:37 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.995.11; Sun, 10 Aug 2014 03:23:35 +0000
Received: from ([]) by ([]) with mapi id 15.00.0995.011; Sun, 10 Aug 2014 03:23:35 +0000
From: Dmitry Anipko <>
To: GangChen <>
Thread-Topic: [mif] FW: I-D Action: draft-ietf-mif-mpvd-arch-03.txt
Thread-Index: AQHPstw95wCld6ApKUGrNO/9P6+LMpvJLDLT
Date: Sun, 10 Aug 2014 03:23:34 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2601:8:b000:17f:7d90:2ad2:f727:683f]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 029976C540
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(51704005)(13464003)(377424004)(199002)(189002)(36756003)(15975445006)(74662001)(101416001)(107046002)(21056001)(85306004)(15202345003)(83072002)(19580395003)(2656002)(92726001)(85852003)(20776003)(83322001)(19580405001)(80022001)(4396001)(81342001)(77982001)(31966008)(79102001)(87936001)(74502001)(92566001)(64706001)(81542001)(99396002)(110136001)(46102001)(54356999)(76176999)(50986999)(1411001)(105586002)(106116001)(76482001)(106356001)(86362001)(86612001)(77096002)(95666004)(99286002)(22906005); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB079;; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en;
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: MIF Mailing List <>
Subject: Re: [mif] FW: I-D Action: draft-ietf-mif-mpvd-arch-03.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 10 Aug 2014 03:23:41 -0000

Hi Gang,

for some reason I didn't receive the original email. 

My 2 cents on these questions: PVD architecture, among other things, enables a) consistent use of networking configuration and, in some cases, b) improves selection of the networking configuration. I think 1) below is about selection, while 2) is about consistent use.

For selection, if multiple PVDs advertise the same DNS suffix, there are 2 cases: 1.1 all these PVDs are not trusted, 1.2 some of the PVDs are trusted.
In 1.1, IMO the most reasonable minimal behavior would be to generally ignore the suffix for purposes of the PVD selection, since the information is not trusted. In 1.2, if there is only one such trusted PVD, then this information can be meaningfully used in the PVD selection process. If there is > 1 such trusted PVD, then it is either misconfiguration, or any of these multiple trusted PVDs can be equally used, as far as selection by the suffix is concerned, and other factors (cost, speed etc) may be decisive.

For consistency, I'm not sure I understand the concern: if the specific route happens to be associated with the PVD, which the host already decided to use, then that specific route will affect the route lookup process. If the specific route happens to be in a different PVD, then it will be ignored (same approach as with multiple default routes).

Let me know if this answers your question.

Thank you,

From: GangChen <>
Sent: Friday, August 08, 2014 12:41 AM
To: Dmitry Anipko
Cc: MIF Mailing List
Subject: Re: [mif] FW: I-D Action: draft-ietf-mif-mpvd-arch-03.txt

Hello Dmitry,

I posted the questions in other two threads, but didn't get response.
Could you kindly consider following questions into WGLC comments

Is there any conclusion if PVD rules conflict with RFC6731 and RFC4191?

Two particular cases are:

1)  Name resolution

Let's say, host A receives RDNSS Selection DHCPv6 Option with domain
name of on interface 1.
It also receives PVD-ID of on interface 2.

If the host A makes query for, which interface should be selected

2) next hop

draft-ietf-mif-mpvd-arch-01 states:

   For each obtained destination
   address, the node shall perform a next-hop lookup among routers,
   associated with that PVD.



2014-08-07 9:53 GMT+08:00, Dmitry Anipko <>om>:
> This revision should address the WGLC comments. If there are no additional
> comments, we'll do the language review (thanks Ian for the kind offer), and
> I'm following up with authors of the 2 IDs mentioned in the text, which have
> expired, for the proper replacements.
> -Dmitry
> -----Original Message-----
> From: mif [] On Behalf Of
> Sent: Wednesday, August 6, 2014 6:49 PM
> To:
> Cc:
> Subject: [mif] I-D Action: draft-ietf-mif-mpvd-arch-03.txt
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Multiple Interfaces Working Group of the
>         Title           : Multiple Provisioning Domain Architecture
>         Author          : Dmitry Anipko
>       Filename        : draft-ietf-mif-mpvd-arch-03.txt
>       Pages           : 22
>       Date            : 2014-08-06
> Abstract:
>    This document is a product of the work of MIF architecture design
>    team.  It outlines a solution framework for some of the issues,
>    experienced by nodes that can be attached to multiple networks.  The
>    framework defines the notion of a Provisioning Domain (PvD) - a
>    consistent set of network configuration information, and PvD-aware
>    nodes - nodes which learn PvDs from the attached network(s) and/or
>    other sources and manage and use multiple PvDs for connectivity
>    separately and consistently.
> The IETF datatracker status page for this draft is:
> There's also a htmlized version available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> mif mailing list
> _______________________________________________
> mif mailing list