Re: [Mavs] Additional comments to the requirements draft

dimitri papadimitriou <> Sat, 22 October 2005 19:50 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1ETPNr-0003BM-FL; Sat, 22 Oct 2005 15:50:27 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1ETPNq-00038t-2O for; Sat, 22 Oct 2005 15:50:26 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id PAA26750 for <>; Sat, 22 Oct 2005 15:50:14 -0400 (EDT)
Received: from ([] ident=mailnull) by with esmtp (Exim 4.43) id 1ETPaF-0002gV-I9 for; Sat, 22 Oct 2005 16:03:15 -0400
Received: from localhost ([]) by with esmtp (Exim 4.52 (FreeBSD)) id 1ETPNc-0004Cr-T1; Sat, 22 Oct 2005 19:50:13 +0000
Message-ID: <>
Date: Sat, 22 Oct 2005 21:49:22 +0200
From: dimitri papadimitriou <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Page <>
Subject: Re: [Mavs] Additional comments to the requirements draft
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Content-Transfer-Encoding: 7bit
Cc:, Christian Jacquenet <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiprovider End-to-end VPN Services <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>


David Page wrote:
> Christian, some more thoughts...
> 1. I strongly encourage the co-authorship of this document by one or
> more SP representatives.  Agreed.

-> application of IETF rules should be the common rule here - authors 
independently of their affiliation and/or origins are susceptible to 
contribute to IETF document - this said contribution from operators are 
indeed more than welcome

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

i hope we will have the time to discuss these aspects during the next 
IETF meeting ...

- dimitri.

> -Dave
> ------------------------------------------------------------------------
> _______________________________________________
> Mavs mailing list

Mavs mailing list