RE: [Mavs] Additional comments to the requirements draft

"David Page" <dpage@nexagent.com> Tue, 13 December 2005 18:31 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmEwM-000290-Sp; Tue, 13 Dec 2005 13:31:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmEwF-00028W-Hz for MAVS@megatron.ietf.org; Tue, 13 Dec 2005 13:31:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03531 for <mavs@ietf.org>; Tue, 13 Dec 2005 13:30:38 -0500 (EST)
Received: from hostedexchange.hostedservice.com ([217.28.130.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmEx3-000384-JM for mavs@ietf.org; Tue, 13 Dec 2005 13:32:42 -0500
Received: from THHS2EXBE2X.hostedservice2.net ([192.168.33.20]) by hostedexchange.hostedservice.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Dec 2005 18:31:06 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mavs] Additional comments to the requirements draft
Date: Tue, 13 Dec 2005 18:31:05 -0000
Message-ID: <B2B4D3618441D941B811329A672FD64E7ABF35@THHS2EXBE2X.hostedservice2.net>
Thread-Topic: [Mavs] Additional comments to the requirements draft
Thread-Index: AcXXQdZ8wN8U30OiScOmqDwKru24TAozBUWA
From: "David Page" <dpage@nexagent.com>
To: <dpapadimitriou@psg.com>, <dimitri.papadimitriou@alcatel.be>
X-OriginalArrivalTime: 13 Dec 2005 18:31:06.0963 (UTC) FILETIME=[61AB4230:01C60013]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Content-Transfer-Encoding: quoted-printable
Cc: mavs@ietf.org, Christian Jacquenet <christian.jacquenet@gmail.com>
X-BeenThere: mavs@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiprovider End-to-end VPN Services <mavs.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mavs>, <mailto:mavs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mavs>
List-Post: <mailto:mavs@ietf.org>
List-Help: <mailto:mavs-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mavs>, <mailto:mavs-request@ietf.org?subject=subscribe>
Sender: mavs-bounces@ietf.org
Errors-To: mavs-bounces@ietf.org

Dimitri,

Picking up on this thread with some clarification at the end...


>> 2. Some of the terminology is rather confusing: e.g. I think the 
>> notion of "MNE operator" is highly arguable, because I don't think 
>> there will be such a meta-organization. Rather, I would replace this 
>> notion by "a community of (VPN) service providers that use and
operate 
>> the (entwork) resources of a MNE facility to deploy and exploit a VPN

>> service offering".  The original white paper from which this draft
was 
>> derived, looked at a number of individual MNE use cases. Each use
case 
>> was described from the perspective of an individual service provider 
>> and the business requirement that they needed to meet, i.e. 
>> integration, wholesale, retail, etc. For each use case there was an 
>> MNE. Each MNE was the set of carriers and interconnects that the 
>> service provider used to fulfil their business need. Importantly,
each 
>> MNE was used solely for the purposes of the service providers
business 
>> use case. So in this context, the service provider became *the* MNE 
>> operator, because the MNE was used solely for its business purposes. 
>> This was a use case-based approach to understanding the requirements
of an 
>MNE.
>
>-> ok - but i don't think an IETF i-d needs to translate on a 1:1 basis
>individual's white papers (based on specific business case(s) but
instead the 
>IETF community needs as a whole; in particular, the user community in
the 
>present case; the delegation process introduced in the present document
implies >that the service delivered across the IP infrastructure managed
by the ISP would 
>simply be delegated to a specific "meta-" organization ... from an IETF

>viewpoint this is highly arguable because the IETF does not define such

>relationships but the tools ISPs can make use of in order to engineer
and 
>deploy their infrastructure and deliver IP-based services
>
>
>> Of course, that is one way of looking at things. Another way might be

>> for the MNE to be a superset of interconnected carriers and 
>> interconnects. The MNE, in this case, serves the business needs of 
>> many service providers; the MNE will serve many use cases; each use 
>> case would utilise a subset of the MNE to meet a particular business 
>> objective. This, I think, is more akin to your view of the MNE as 
>> community - so long as that community can include carriers as well as

>> non-carriers like VNOs, SIs, NIs, etc. In this scenario, there
clearly 
>> would not be *an* MNE operator, but I think it remains important to 
>> retain the concept that there are entities that are using their 
>> respective subsets of the MNE community for their individual use 
>> case/business needs. This way we have a concept - a handle - that
will 
>> enable us to properly understand the requirements of each use case 
>> within the MNE. We just need a name for the entity.
>
>-> i agree with christian here, there is a disconnect, the fact there
is
>super-structure providing for these VPN operations does not mean that
it has to >be managed by a "separate" or "meta-" organisation
>
>in brief, the document introduces the notion of VPN integrator (refer
to as MNE >operator) atop of ISPs ... this requires serious discussion !




DP. I'm not suggesting that the MNE *must* be managed/operated by some
meta organisation. That clearly does not make sense and does introduce
the notion of an organisation that does not exist today, and (very
probably) should not going forward.

However, a type of organisation that does clearly exist today is the
integrator. These companies do integrate VPN services from multiple
carriers, and they do build VPN integration platforms for multiple
customers to be served. They are the SIs, NIs and VNOs. When they do
this, they do effectively become a 'meta' organisation responsible to
their customers for the end-to-end services across multiple carriers. In
these use cases, the carriers are sub-contractors to the integrator who,
in turn, contracts with the end-customer. It is in these specific use
cases that the integrator effectively becomes a multi-network
environment (MNE) operator.

-Dave



_______________________________________________
Mavs mailing list
Mavs@ietf.org
https://www1.ietf.org/mailman/listinfo/mavs