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

Dmitry Anipko <Dmitry.Anipko@microsoft.com> Mon, 07 July 2014 22:34 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 3E6221B28BC for <mif@ietfa.amsl.com>; Mon, 7 Jul 2014 15:34:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 oHE6DXXZar-c for <mif@ietfa.amsl.com>; Mon, 7 Jul 2014 15:34:49 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142FC1A0AAD for <mif@ietf.org>; Mon, 7 Jul 2014 15:34:49 -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.974.11; Mon, 7 Jul 2014 22:34:47 +0000
Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.142]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.142]) with mapi id 15.00.0974.002; Mon, 7 Jul 2014 22:34:47 +0000
From: Dmitry Anipko <Dmitry.Anipko@microsoft.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Thread-Topic: [mif] FW: I-D Action: draft-ietf-mif-mpvd-arch-02.txt
Thread-Index: AQHPl1akiL51pqotJEiOWx+mtw+rSpuVJsqQ
Date: Mon, 7 Jul 2014 22:34:46 +0000
Message-ID: <3ea0c51c57224263a806916c9821f9d8@SN2PR03MB077.namprd03.prod.outlook.com>
References: <20140704005457.5925.30656.idtracker@ietfa.amsl.com> <1404435563313.15510@microsoft.com> <alpine.DEB.2.02.1407040833460.7929@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.02.1407040833460.7929@uplift.swm.pp.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e0:ee43::3]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 02652BD10A
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(252514010)(13464003)(377454003)(24454002)(199002)(189002)(99396002)(19580405001)(105586002)(85306003)(19580395003)(106356001)(110136001)(76176999)(107046002)(4396001)(99286002)(33646001)(74662001)(95666004)(50986999)(83322001)(31966008)(54356999)(106116001)(79102001)(86612001)(76576001)(92566001)(86362001)(74316001)(101416001)(87936001)(77096002)(74502001)(80022001)(2656002)(81342001)(76482001)(64706001)(21056001)(85852003)(46102001)(83072002)(81542001)(20776003)(108616002)(3826002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB079; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/mif/W_sWrHbPQq4JsvF-T8JoPTtMpkw
Cc: "mif@ietf.org" <mif@ietf.org>
Subject: Re: [mif] FW: I-D Action: draft-ietf-mif-mpvd-arch-02.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: Mon, 07 Jul 2014 22:34:52 -0000

Hello Mikael,

Thank you for reading the draft and providing feedback.

>>2.3. Does the current writing prohibit that multiple implicit PVDs are formed on a single interface, for instance if RAs are seen from two or more routers on the same link, each announcing non-overlapping address space and DNS resolvers? I would like to see a PVD being formed for each of these to also allow for source based routing to send packets / use each resolver depending on what source address based on these RAs are being used.

IIRC the WG discussed this question on a couple of occasions, and my understanding of consensus is: while there is no intent to prohibit multiple implicit PvDs on an interface, there is no clear way how to enable the implicit PvDs with finer granularity either. The text was supposed to reflect such position by saying "By default, implicit PVDs are limited... If additional information is available to the host through mechanisms out of scope of this document, the host may form implicit PVDs with different granularity".  Do you think this needs more elaboration in the text? (such as e.g. including your example into that section; this may open questions though such as e.g., how to make sure that IPv6 & IPv4 from the same router do not end up in different PvDs)

>>2.4. Nit: I would like to see some commas in the second sentence for easier understanding, for instance:
>>"For implicit PVDs, the node assigns a locally generated, with a high probability of being globally unique, ID to each implicit PVD."

Will do.

>>2.5 Nit grammar question (unsure):
>>"  For implicit PVDs, by default PVD-aware nodes shall including multiple IP families into single implicit PVD created for an interface."
>> Shouldn't that be "shall include"?

You're correct, will change.

>>3.3 Nit: Up to this, PVDs have been all caps, now there is a "PvD" (unless the font/rendering combination in my browser is fooling my eyes). This is also in 3.4 and others. The entire document needs to be checked for this?

Will change to PvD across the doc (since V doesn't map to a separate word).

>>5.2.2 If an application chooses an explicit source address first, I would like to see the traffic sourced from that IP go out through the logical/physical interface that IP is associcated with. Example:
>>You have a PVD that is associcated with your physical ethernet connection and a VPN tunnel that goes over your WiFi Internet connection. So the host has two PVDs, one "Internet", and one "Corporate", where the Corporate one has two interfaces, one >>physical and one logical. If packets are sourced using the VPN based IP address, I would like to see packets src/dst based routed to go out the VPN connection and not go directly to the Corporate physical connection. So this is *after* source address >>selection has been done. As far as I can tell, there is no text about this.

I'll add text, that if the application has explicitly specified a source address, then for the subsequent operations on the specified API object, a matching PvD should be used, provided that use of that PvD by that application is allowed by the host configuration.

>>5.2.3 Nit: "Internet" is a name, thus capital I. It's "Internet" in 5.3.
>>5.2.4. Nit: "Togetheer"

Will change.

>>5.4. I feel 5.4 needs more text, at minimum stating that even though it's a known non-perfect solution with connection managers, this problem is out of scope for this document. The current text seems to say there is a problem, and then... nothing.

My understanding is that the text starting with "Although connection managers solve some  connectivity problems, they rarely address the network selection problems.." was a reflection on that, with implication that the present draft shall improve the situation by providing to the hosts tools and guidance to make better network selection decisions. Will it address your comment if I add such sentence explicitly? 

>>10. Nit: there is a " , " (space before comma" in the middle of "tampering" section. Both of the last two sections seems to be lacking a ":" or a "." after the initial section identifier. "Rogue configuration source A compromised" for example.

Will add ":"s and fix the other thing.

-Dmitry

-----Original Message-----
From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] 
Sent: Friday, July 4, 2014 12:08 AM
To: Dmitry Anipko
Cc: mif@ietf.org
Subject: Re: [mif] FW: I-D Action: draft-ietf-mif-mpvd-arch-02.txt

On Fri, 4 Jul 2014, Dmitry Anipko wrote:

> The new revision addresses the comments made on the list, and has added examples in the section 4. Thanks Zhen Cao, Ian Farrer and Dapeng Liu for their contributions to the section 4.

Hi,

I'm re-reading the document in its entirety, writing comments as I go
along:

2.3. Does the current writing prohibit that multiple implicit PVDs are formed on a single interface, for instance if RAs are seen from two or more routers on the same link, each announcing non-overlapping address space and DNS resolvers? I would like to see a PVD being formed for each of these to also allow for source based routing to send packets / use each resolver depending on what source address based on these RAs are being used.

2.4. Nit: I would like to see some commas in the second sentence for easier understanding, for instance:

"For implicit PVDs, the node assigns a locally generated, with a high probability of being globally unique, ID to each implicit PVD."

2.5 Nit grammar question (unsure):

"  For implicit PVDs, by default PVD-aware nodes shall including multiple IP families into single implicit PVD created for an interface."

Shouldn't that be "shall include"?

3.3 Nit: Up to this, PVDs have been all caps, now there is a "PvD" (unless the font/rendering combination in my browser is fooling my eyes). This is also in 3.4 and others. The entire document needs to be checked for this?

5.2.2 If an application chooses an explicit source address first, I would like to see the traffic sourced from that IP go out through the logical/physical interface that IP is associcated with. Example:

You have a PVD that is associcated with your physical ethernet connection and a VPN tunnel that goes over your WiFi Internet connection. So the host has two PVDs, one "Internet", and one "Corporate", where the Corporate one has two interfaces, one physical and one logical. If packets are sourced using the VPN based IP address, I would like to see packets src/dst based routed to go out the VPN connection and not go directly to the Corporate physical connection. So this is *after* source address selection has been done. As far as I can tell, there is no text about this.

5.2.3 Nit: "Internet" is a name, thus capital I. It's "Internet" in 5.3.

5.2.4. Nit: "Togetheer"

5.4. I feel 5.4 needs more text, at minimum stating that even though it's a known non-perfect solution with connection managers, this problem is out of scope for this document. The current text seems to say there is a problem, and then... nothing.

10. Nit: there is a " , " (space before comma" in the middle of "tampering" section. Both of the last two sections seems to be lacking a ":" or a "." after the initial section identifier. "Rogue configuration source A compromised" for example.

Apart from this I feel the document is in good shape and I support its publication.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se