Subject: RE: [Mavs] Additional comments to the requirements draft

From: "David Page" <[email-masked]>
Date: Fri, 21 Oct 2005 10:22:33 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mavs

---

From: dimitri papadimitriou <[email-masked]>
Date: Sat, 22 Oct 2005 21:49:22 +0200

hi

> 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

> 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

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

thanks,
- dimitri.

> -Dave
> 
> 
> 
> ------------------------------------------------------------------------
>