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

[Alper Yegin <[e-mail]>]

Hi Dmitry,


On Jul 20, 2013, at 3:59 AM, Dmitry Anipko wrote:

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

Actually, I didn't mean or suggest that.

I was just trying to give what we are doing a name. It appears like some sort of "virtualization" to me.

Let me explain:

Long time ago, there was just one IP network. When a host attached to the network, it was on the IP network.
It didn't matter which interface or what parameters were used, the apps would get the same reachability/connectivity service.

But later, with the invention of VPN, captive portal, etc., the question of which "IP network" became important. 
That's why I see this as virtualization: We need to decide whether an app shall use the IP network that is served by a VPN to the enterprise, or the IP network gated by a captive portal. 
They may all be going over the same physical interface (that used to equate to the "IP network"), but virtually separated. 


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

My point is, in order to handle that VPN example, we need to be using advanced category. 

Alper



>  
> 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] <[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]
> https://www.ietf.org/mailman/listinfo/mif-arch-dt
>  
> _______________________________________________
> mif-arch-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif-arch-dt