Re: [mif-arch-dt] New Version Notification for draft-anipko-mif-mpvd-arch-00.txt

[Dmitry Anipko <[e-mail]>]

Hi Alper,

I think there are two parts to your question, as I understood it:


1.       Whether MPVD problem can be solved [possibly, you meant in the particular VPN scenario], by using the IP interface for grouping of configuration, instead of PVD.

2.       How could OS + app implement tying the connection to the specific set of parameters, and possible impact on APIs / application code.

Please let me know if I interpreted either or both questions incorrectly.

For the first question, RFC 6419 discusses that not all implementations keep interfaces in isolation from other interfaces. If the implementations consistently did that for configuration across layers (e.g. including DNS, HTTP etc), then I'd agree that a subset of MPVD problem, where 1 interface = 1 PVD would be solved. However even in that case, as RFC 6418 section 4.5 describes, there are cases where 1 interface may be attached to multiple PVD, and those (as well as the scenarios where PVD spans across interfaces) would not be solved by per-interface grouping.

For the second question, I don't think the question is specific to whether the grouping of configuration elements is done per interface or per PVD. In either case, something needs to ensure that the correct set of parameters, be it for a particular interface or for a particular PVD, is used for a particular connection and/or application. As I started outlining in the draft, section 5, there are different not exclusive (i.e. host could support all of them) approaches for how the API could look like. E.g. the "Basic" approach would imply that OS does all the work based on e.g. policies + on app identity, destination name / IP address etc. In "Intermediate" approach, the app could provide some PVD-aware input. I think the approach you described, falls into "Advanced" category, where the app does most of the work by itself.

If I've misunderstood what you meant with "virtualization", please clarify.

Thank you,
Dmitry

From: [e-mail] [mailto:[e-mail]] On Behalf Of Alper Yegin
Sent: Wednesday, July 17, 2013 8:09 AM
To: Dmitry Anipko
Cc: [e-mail]
Subject: Re: [mif-arch-dt] New Version Notification for draft-anipko-mif-mpvd-arch-00.txt

Hello,

Can we perceive this as some kind of a "virtualization" at the IP layer?

In order to handle "(3) is a use of employer-sponsored VPN connection for peer-to-peer connections, unrelated to employment activities.", PVD ID needs to be to exposed all the way to the application, and the application needs to explicitly request/bind to it. So, in a way, that virtualization needs to propagate all the way up to the apps.


Alper









On Jul 14, 2013, at 7:24 AM, Dmitry Anipko wrote:


Hi everyone.

I've just posted the first version of the MPD arch draft based on the teleconfs and list discussions we've had so far. If possible, please take a look before the Monday call and comment.

For some of the topics, which we touched but where I didn't feel like I had enough information, for now I created placeholder sections with little / no text.

Thank you,
Dmitry



________________________________________
From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, July 13, 2013 9:19 PM
To: Dmitry Anipko
Subject: New Version Notification for draft-anipko-mif-mpvd-arch-00.txt

A new version of I-D, draft-anipko-mif-mpvd-arch-00.txt
has been successfully submitted by Dmitry Anipko and posted to the
IETF repository.

Filename:        draft-anipko-mif-mpvd-arch
Revision:        00
Title:           Multiple Provisioning Domain Architecture
Creation date:   2013-07-13
Group:           Individual Submission
Number of pages: 9
URL:             http://www.ietf.org/internet-drafts/draft-anipko-mif-mpvd-arch-00.txt
Status:          http://datatracker.ietf.org/doc/draft-anipko-mif-mpvd-arch
Htmlized:        http://tools.ietf.org/html/draft-anipko-mif-mpvd-arch-00


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 Secretariat




_______________________________________________
mif-arch-dt mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mif-arch-dt