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

GangChen <phdgang@gmail.com> Sun, 10 August 2014 07:47 UTC

Return-Path: <phdgang@gmail.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 376621A0688 for <mif@ietfa.amsl.com>; Sun, 10 Aug 2014 00:47:25 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 qblH8PkiJcIh for <mif@ietfa.amsl.com>; Sun, 10 Aug 2014 00:47:23 -0700 (PDT)
Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E841A0686 for <mif@ietf.org>; Sun, 10 Aug 2014 00:47:22 -0700 (PDT)
Received: by mail-qa0-f44.google.com with SMTP id f12so7029034qad.31 for <mif@ietf.org>; Sun, 10 Aug 2014 00:47:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lIk4bF+t5QIWKhgsTLYWTj6HkeNH33KNLKaxwWq1KGE=; b=HUEGEx8+wOke/c+33s9/JbD5m1ZK9qiXljMqI4FpULBzf1HwBPkj2BB0kOh6TA5Rip uFSSEttmoAwCm8H+XpKhB+f3Il4Bnh/JAcJ2mYcKVU8gIPbjMLXhM/0EBilbZqJdNrxC 3LdxRnyVo+Dpyz47fTW7fmnbVU1r4ZN7ZsCgkYZTMa3cmXziVz8wiS6YRZcooIFsqF75 r/OCAku4OR+d83FchKV1LTdvAYo4X217ZgOO3Td2yMNIFz1Khh6UonEsR7gCmSuToqO6 xmXxTI97NjnrOPu1B4JC92GE0aKHLBLZ8eVqH9nrhVbfj0dsgiCtkl5M4g/B+c/9VqA/ oraA==
MIME-Version: 1.0
X-Received: by 10.140.40.210 with SMTP id x76mr36979369qgx.61.1407656842027; Sun, 10 Aug 2014 00:47:22 -0700 (PDT)
Received: by 10.224.46.10 with HTTP; Sun, 10 Aug 2014 00:47:21 -0700 (PDT)
In-Reply-To: <1407641018403.33302@microsoft.com>
References: <20140807014913.4706.73259.idtracker@ietfa.amsl.com> <220fd568124845328a43e21bf5d31e28@SN2PR03MB077.namprd03.prod.outlook.com> <CAM+vMETqu8n0YDWQvFNy_1RvkrELjQREr1t=mQ2JDWdtz+cTUA@mail.gmail.com> <1407641018403.33302@microsoft.com>
Date: Sun, 10 Aug 2014 15:47:21 +0800
Message-ID: <CAM+vMEQi4CN+sxOpycwYBg0URcOSWU0MAfpCgg9GbWNHm-x-ew@mail.gmail.com>
From: GangChen <phdgang@gmail.com>
To: Dmitry Anipko <Dmitry.Anipko@microsoft.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/mif/NhvlflnjKH5UELz5Cm8I8JASE9w
Cc: MIF Mailing List <mif@ietf.org>
Subject: Re: [mif] FW: I-D Action: draft-ietf-mif-mpvd-arch-03.txt
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: Sun, 10 Aug 2014 07:47:25 -0000

Hi Dmitry,

Thank you for the feedback.

2014-08-10 11:23 GMT+08:00, Dmitry Anipko <Dmitry.Anipko@microsoft.com>om>:
> 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.

RFC6731 doesn't carry PVD information. Let's assume int#1 and int#2 on
a PVD-aware node receive RDNSS Selection DHCPv6 Option and PVD
Container Option respectively. And both are trusted.

int#1 receives RDNSS Selection DHCPv6 Option with domain name of example.com
int#2 receives PVD-ID named as example.com.

As far as trust and suffix are concerned, should it be equally used?


> 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).

A network provision a PVD-aware node that targeting to 2001::1 should
only take int#1. However, the int#2 on the node receives RA carry
Route Information Option indicating 2001::1 with high priority.

Should the node ignore int#2 and select int#1?

Gang


> Let me know if this answers your question.
>
> Thank you,
> Dmitry
>
>
> ________________________________________
> From: GangChen <phdgang@gmail.com>
> 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 example.com on interface 1.
> It also receives PVD-ID of example.com on interface 2.
>
> If the host A makes query for a.example.com, 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.
>
>
> BRs
>
> Gang
>
> 2014-08-07 9:53 GMT+08:00, Dmitry Anipko <Dmitry.Anipko@microsoft.com>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 [mailto:mif-bounces@ietf.org] On Behalf Of
>> internet-drafts@ietf.org
>> Sent: Wednesday, August 6, 2014 6:49 PM
>> To: i-d-announce@ietf.org
>> Cc: mif@ietf.org
>> 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
>> IETF.
>>
>>         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:
>> https://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-mif-mpvd-arch-03
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mif-mpvd-arch-03
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> mif mailing list
>> mif@ietf.org
>> https://www.ietf.org/mailman/listinfo/mif
>>
>> _______________________________________________
>> mif mailing list
>> mif@ietf.org
>> https://www.ietf.org/mailman/listinfo/mif
>>
>