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

Dmitry Anipko <Dmitry.Anipko@microsoft.com> Wed, 13 August 2014 01:17 UTC

Return-Path: <Dmitry.Anipko@microsoft.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 D4C601A6F7F for <mif@ietfa.amsl.com>; Tue, 12 Aug 2014 18:17:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 Zw2kCgCwLUbe for <mif@ietfa.amsl.com>; Tue, 12 Aug 2014 18:17:14 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328D01A6F7E for <mif@ietf.org>; Tue, 12 Aug 2014 18:17:14 -0700 (PDT)
Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB079.namprd03.prod.outlook.com (10.255.175.155) with Microsoft SMTP Server (TLS) id 15.0.995.11; Wed, 13 Aug 2014 01:17:11 +0000
Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.2.120]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.2.120]) with mapi id 15.00.0995.011; Wed, 13 Aug 2014 01:17:11 +0000
From: Dmitry Anipko <Dmitry.Anipko@microsoft.com>
To: GangChen <phdgang@gmail.com>
Thread-Topic: [mif] FW: I-D Action: draft-ietf-mif-mpvd-arch-03.txt
Thread-Index: AQHPstw95wCld6ApKUGrNO/9P6+LMpvJLDLTgABMt4CABETo0A==
Date: Wed, 13 Aug 2014 01:17:10 +0000
Message-ID: <9852a6da227545da995ecac31ae6b86f@SN2PR03MB077.namprd03.prod.outlook.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> <CAM+vMEQi4CN+sxOpycwYBg0URcOSWU0MAfpCgg9GbWNHm-x-ew@mail.gmail.com>
In-Reply-To: <CAM+vMEQi4CN+sxOpycwYBg0URcOSWU0MAfpCgg9GbWNHm-x-ew@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:ed31::3]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 0302D4F392
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199003)(51704005)(377454003)(377424004)(13464003)(76176999)(77096002)(1411001)(86612001)(86362001)(108616004)(95666004)(81342001)(21056001)(107046002)(105586002)(76576001)(99396002)(15975445006)(74662001)(85306004)(77982001)(54356999)(74316001)(33646002)(74502001)(2656002)(46102001)(20776003)(19580395003)(106116001)(81542001)(4396001)(50986999)(83072002)(106356001)(76482001)(99286002)(110136001)(79102001)(85852003)(101416001)(64706001)(83322001)(87936001)(80022001)(92566001)(15202345003)(93886004)(31966008)(19580405001)(24736002)(3826002); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB079; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/mif/LF6RjecgjsjuU4pZ1YbQmVuA1B4
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: Wed, 13 Aug 2014 01:17:18 -0000

Hi Gang,

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

Right, I was implying that the association with PvD is done in the ways defined in the respective documents, currently being worked on, such as the container option.

>> 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?

As I tried to describe in my previous mail, IMO the answer depends on the trust of the host to the individual PvD-IDs. See the arch draft section 7.2 for discussion of the trust to PvDs. If your concern specifically is about the case where both PvDs are trusted, and the question is which of the two PvDs in this case should be used for example.com destinations, we can add more text on that. IMO - perhaps the DHCP option should win since the admin has made explicit effort to provide RDNSS information, but probably either way may be fine given that the host trusts to both PvDs (and the choice can be based on other factors). 

>>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?

I don't think that the specific route should be a direct factor in PvD selection. Once a PvD is chosen due to other factors (cost/speed/connectivity tests/name based policies + trusted PvDs etc.), then within that PvD the specific route provides useful information. Across the PvDs, the specific routes are no different from default routes - there is no direct way to infer, which one is "better" or "makes more sense", since they are provisioned by different administrators, who may have completely different ideas of what is "better". 

-Dmitry

-----Original Message-----
From: GangChen [mailto:phdgang@gmail.com] 
Sent: Sunday, August 10, 2014 12:47 AM
To: Dmitry Anipko
Cc: MIF Mailing List
Subject: Re: [mif] FW: I-D Action: draft-ietf-mif-mpvd-arch-03.txt

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