RE: [Mavs] Additional comments to the requirements draft

"David Page" <dpage@nexagent.com> Fri, 21 October 2005 09:23 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESt7A-0002I3-D5; Fri, 21 Oct 2005 05:23:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESt79-0002Hy-W0 for MAVS@megatron.ietf.org; Fri, 21 Oct 2005 05:23:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08484 for <mavs@ietf.org>; Fri, 21 Oct 2005 05:22:52 -0400 (EDT)
Received: from hostedexchange.hostedservice.com ([217.28.130.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EStJH-0000i1-5x for mavs@ietf.org; Fri, 21 Oct 2005 05:35:35 -0400
Received: from THHS2EXBE2X.hostedservice2.net ([192.168.33.21]) by hostedexchange.hostedservice.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 10:22:45 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Mavs] Additional comments to the requirements draft
Date: Fri, 21 Oct 2005 10:22:33 +0100
Message-ID: <B2B4D3618441D941B811329A672FD64E536CE3@THHS2EXBE2X.hostedservice2.net>
Thread-Topic: [Mavs] Additional comments to the requirements draft
Thread-Index: AcXVdIFR8OW+cx1lRPeHYLMcCNMz3AAolNwA
From: "David Page" <dpage@nexagent.com>
To: "Christian Jacquenet" <christian.jacquenet@gmail.com>, <mavs@ietf.org>
X-OriginalArrivalTime: 21 Oct 2005 09:22:45.0967 (UTC) FILETIME=[FF40EDF0:01C5D620]
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 93e7fb8fef2e780414389440f367c879
Cc:
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>
Content-Type: multipart/mixed; boundary="===============2064755134=="
Sender: mavs-bounces@ietf.org
Errors-To: mavs-bounces@ietf.org

Christian, some more thoughts...
 
1. I strongly encourage the co-authorship of this document by one or
more SP representatives.  Agreed.
 
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.
 
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.
 
-Dave
_______________________________________________
Mavs mailing list
Mavs@ietf.org
https://www1.ietf.org/mailman/listinfo/mavs