RE: [Mavs] Comments on the requirements draft

"Martin Halstead" <mhalstead@nexagent.com> Mon, 07 November 2005 23:02 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 1EZG0x-0001uE-Kl; Mon, 07 Nov 2005 18:02:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZG0v-0001tN-QD for MAVS@megatron.ietf.org; Mon, 07 Nov 2005 18:02:57 -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 SAA15609 for <mavs@ietf.org>; Mon, 7 Nov 2005 18:02:31 -0500 (EST)
Received: from hostedexchange.hostedservice.com ([217.28.130.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZGGb-0003ob-EE for mavs@ietf.org; Mon, 07 Nov 2005 18:19:10 -0500
Received: from THHS2EXBE2X.hostedservice2.net ([192.168.33.20]) by hostedexchange.hostedservice.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 23:02:27 +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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mavs] Comments on the requirements draft
Date: Mon, 7 Nov 2005 23:02:27 -0000
Message-ID: <B2B4D3618441D941B811329A672FD64E475D1E@THHS2EXBE2X.hostedservice2.net>
Thread-Topic: Comments on the requirements draft
thread-index: AcXjjy55lfCE9Fj6TU2uft6PzDxerQAXgChg
From: "Martin Halstead" <mhalstead@nexagent.com>
To: <matthew.ford@bt.com>, <mavs@ietf.org>
X-OriginalArrivalTime: 07 Nov 2005 23:02:27.0787 (UTC) FILETIME=[52ECD9B0:01C5E3EF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2b428fb4265163ba7f2ac2af0ebfcf00
Content-Transfer-Encoding: quoted-printable
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>
Sender: mavs-bounces@ietf.org
Errors-To: mavs-bounces@ietf.org

Matthew

Thanks for the comments. Response in line with the first part of you list.

Martin


-----Original Message-----
From: mavs-bounces@ietf.org [mailto:mavs-bounces@ietf.org]On Behalf Of
matthew.ford@bt.com
Sent: 07 November 2005 11:34
To: mavs@ietf.org
Subject: [Mavs] Comments on the requirements draft

Hi folks,

Detailed comments below. High level observations are:

 - I'm not completely comfortable with the terminology used in this
draft, but that may mainly be because I don't feel I understand it very
well which is a problem with the exposition, rather than the terminology
per se.

 - The requirements as currently defined seem too general to be really
useful. I wonder if there isn't a need to be clearer about specific
requirements. This is likely to lead to more disagreements perhaps, but
hopefully these can be ironed out and useful progress will result.

MH - Could you be more specific about what you mean by 'need to be clearer':-) Do you mean 
that the draft could do with more technical content, more examples, more detailed explanations for 
each requirement or something else?

 - I'm not sure I agree with Dimitri that, "the document introduces the
notion of VPN integrator (refer to as MNE operator) atop of ISPs". I
think the document *allows* for that, but it also clearly alludes to the
idea that a single service provider is engaged with service provision to
a cusomter and acts as MNE operator for the purposes of delivering that
service. To improve the document, I think the roles of the various
entities and how they interact and are composed of/subsume each other
needs to be spelled out much more clearly. In addition, it might help to
specify what we consider the 'default' or 'typical' arrangement will be
to help readers trying to get to grips with the terminology for the
first time.

MH - Agreed, although this is a tricky thing to get right as it depends on which
side of the fence you sit on. The role of a SI, VNO, NI in relation to a customer via
their 'dedicated' MNE can be substantially different to the role of a NSP to a customer and a 'shared' MNE.
Not sure if it is possible to have a default as to me both roles are valid. Anyway, will try to 
update the text with something simpler.

Good luck with the mini-BoF this this afternoon - I'll try to join via
audiocast/jabber.

MH - Thanks. Rest of your comments to be incorporated...

Martin

Cheers,
Mat

OK, here goes, all my comments are prefixed with '==>', I've elided
portions of the document that I have no comments on.

	Requirements for Multi Autonomous System VPN services

==> I tend to think this should be Multi-Provider, not Multi-AS.
Multi-AS is a subset of Multi-Provider as I see it.

Abstract
This document complements [RFC4031] and defines requirements that are
specific to the provisioning of VPN services

==> insert 'across multiple service providers'

, potentially at the scale of the Internet. These requirements are
independent of underlying technologies or the number of Autonomous
Systems such VPNs may span. In addition, it lists the requirements of
the different entities that are involved in the administration of these
Autonomous Systems and may therefore be involved in the provisioning
processes of the VPN service offerings. 

==> OK, so who owns the requirements referred to in the first two
sentences? Maybe just delete 'In addition,'.

1. Introduction
This document summarizes a list of requirements

==> I don't think this reads well. Delete 'a list of'.

specified by all parties involved in the delivery of VPN services that
span multiple Autonomous Systems on behalf of their end customers. Such
parties include, but are not limited to, Enterprise IT departments,
Network Service Providers (NSP), Systems Integrators (SI), Network
Integrators (NI) and Virtual Network Operators (VNO). Section 3
specifies the roles of these parties, while section 4 details examples
of each operator type and how these operators interact to deliver VPN
services. Section 6 lists the requirements of the parties involved in
the delivery of multi-AS specific VPN services.

==> What about Section 5?

3. Definitions

Multi Network Environment (MNE): Two or more Autonomous Systems that
interconnect VPN service endpoints (sites) of a common subscriber

==> I'm not very comfortable with the MNE terminology - inter-provider
environment, or inter-domain environment seems less confusing to me. I
also think the 'common subscriber' is confusing and should be removed -
how about, 'Two or more Autonomous Systems that interconnect service
endpoints (sites) of one or more VPNs'

VPN Peering Location (VPL): A physical location where two or more NSP
VPN service domains are interconnected. An NSP or SP may operate the
VPL.

==> I think this sentence should be extended to acknowledge the
likelihood that a neutral 3rd-party or a consortium of SPs may operate
the VPL.

Customer: A customer is a single organization, corporation, or
enterprise that administratively controls a set of sites. The customer
for the purposes of this document has their VPN services delivered via a
MNE. Examples of customers include Multi National Corporations and Small
to Medium Enterprises.

==> I don't think these examples are helpful as they seem to include any
organisational entity. I'd delete the final sentence of this definition.

Service Provider (SP): A SP is an operator who delivers some aspect of a
VPN service to a customer.

==> If an SP is delivering 'some aspect of' a VPN service (i.e. not the
whole end-to-end service), then they shouldn't be delivering it to a
customer, rather they should be delivering it to another SP, so let's
delete 'to a customer'. Also a small nit, 'A SP' doesn't read very well
- better to write 'An SP' in my opinion.

Agent: An Agent is a set of SPs and/or NSPs

==> You can delete 'and/or NSPs' as NSPs are a subset of SPs.

 designated by a customer who have the authorization to manage a
customer's VPN service offering. The management relationship the Agent
has with the customer could be business (contractual) and/or
operational.

==> I don't buy the idea that customers want relationships with multiple
SPs in order to derive VPN service. I think if we're talking about
customer requirements for MAVS then 'single point-of-contact' is pretty
high up the list. I'd also argue that it actually isn't scalable for a
customer to have a contractual relationship with multiple SPs in order
to derive service.

 The contractual management relationship mandates that the Agent will be
responsible for fulfilling the customer's requirements for the
enforcement of a set of policies within a MNE. This Policy Agent

==> Are we defining 'Policy Agent' or 'Agent'? I think there is a need
for more clarity here about what is 'agent', 'policy agent', 'ops agent'
and how are they related to, or composed of, each other.

 function could, in addition include an operational management
capability that allows them to operationally agree or coordinate
policies across the parties involved in delivering the end-to-end
service via a MNE.

==> Indeed, I would expect this to be the default case.

 This additional operational (Ops) agent function may be distributed or
centralized. Where the Ops Agent is a NSP, the NSP Ops Agent may
communicate between all relevant NSP Ops Agents to agree upon the
enforcement of consistent policies for VPN service provisioning
purposes. In this case, the function of the Ops Agent is distributed
across multiple SPs. Alternatively, the customer or policy agent may
define their routing requirements and outsource their MNE service policy
to an Ops Agent, such as a NSP, SI, VNO, CO or MO, who will centrally
coordinate the enforcement of policies related to the provisioning of a
VPN service. In contrast to the distributed Ops Agent, the centralized
Ops Agent may not require end-to-end agreement of service policy across
all parties that supply services to his MNE.

==> How does the centralized agent deliver on an SLA in the absence of
end-to-end agreement?

 In addition, it is of importance to introduce the notion of Policy
Repository. The Policy Repository may be co-located with the Ops Agent
or exist as separate entities.

==> s/as separate entities/as a separate entity

Policy Agent (PA): The authority/authorities responsible for fulfilling
the customer's requirements for the enforcement of a set of policies
within a MNE. Typically a PA will exist per SP, and are assumed 

==> s/are/is

to communicate between all relevant PA parties to agree upon the
enforcement of consistent policies for VPN service provisioning
purposes. The customer may be responsible for specifying their MNE
service policy. Alternatively, the customer may define their routing
requirements and outsource their MNE service policy to a customer agent
such as a Service Provider, Systems Integrator, Cable Operator, Mobile
Operator or Virtual Network Operator who in this case would be one of
the possible PA involved in the enforcement of policies related to the
provisioning of a VPN service. Policy Agents are usually driven by
Policy Managers (here referred to as a policy orchestrator (PO)); in
addition to this it is of importance to introduce the notion of Policy
repository; they may be co-located with the PO or be separate entities.

==> There is some overlap and confusion between the Policy Agent
definition and the Agent definition - probably just a consequence of
unfinished editing. This needs to be tidied up. I think the Policy Agent
text is reasonably clear, but the 'Agent' text above needs work.

Policy Orchestrator (PO): The authority responsible for the physical and
logical integration of the MNE. In addition, the PO is responsible for
the operation and multi party business process definitions on behalf of
the PA.

==> In the PA definition above it is stated that PA is driven by PO, so
I don't think PO operating 'on behalf of' PA makes sense. Also, I think
'multi-party business process definition' is a bit unwieldy and unclear
- this should be reworded and perhaps expanded upon to make the concept
clearer. Perhaps, 'PO is responsible for the management of multi-party
business processes, negotiations and fulfillment to allow the PA, and by
implication the multi-provider VPN, to function.'

 The PA may directly fulfill the multi-provider VPN service by
performing the integration of the multi providers

==> s/multi providers/multi-provider

 VPN environment themselves - in this case the PA would also be the PO.
Alternatively, the PA may outsource the physical and logical fulfillment
as well as interconnect processes of the multi-provider VPN service to a
third party 'trading club'. The 'trading club' operator would then be
the PO on behalf of the PA.

4. Multi Network Environment Reference Model
Figure 1 shows a generic reference model for a Multi Network
Environment. It shows the relationships that exist between the various
parties involved in the establishment of VPN services that span multiple
provider networks. 

|<------------Multi Network Environment---------->|
|                                                 |
|                      Users                      |
|                        |                        |
|                     Customer                    |
|                        |                        |
|                      Agent                      |
|                      |   |                      |
|       Policy Agent   |   |                      |
|                          |                      |
|  +---------------Ops Agent(s) --------------+   |
|  |          |          |         |           |  |
|  |         NSP1       VPL1       NSP2        |  |
|  |          ^          ^         ^           |  |
| 1..n       1..n      1..n       1..n       1..n |
|  V          V          V         V           V  |
|Site1 <---> PSN1<--->(VPL1)<---> PSN2 <---> Site2|

Figure 1 - MNE Reference Model


==> The Policy Agent seems to be adrift in this diagram - need for
further clarification of relationships I think. I'd be happy to attempt
to redraw this, but I don't feel I have a clear enough understanding
from the text yet.

The following section details examples of the coordination of the
various parties in the enforcement of a set of policies including, but
not necessarily limited to addressing, routing, QoS and security for the
provisioning of an inter-domain VPN service that will comply with a
customers service requirements.

==> s/customers/customer's

4.1. Distributed Agent Multi Network Environment.
In this model, the MNE consists of a community of SPs and/or NSPs that
use and operate the network resources of a MNE facility to deploy and
exploit a VPN service offering.

==> Let's not start talking about 'a MNE facility' - better to just say
'... that use and operate network resources to deploy and exploit a VPN
service offering.'

 The Customer will define their routing requirements and let the SP
and/or NSP enforce the corresponding policy that addresses such
requirements. An Ops Agent will exist per SP and/or NSP, all of which
will agree upon the enforcement of consistent policies.

==> As I read this it is still very unclear to me what the role of the
Ops Agent is, and how it relates to the Policy Agent and how these
functions are expected to interact.

With reference to Figure 1, the Policy Agent is a single NSP (either
NSP1 or NSP2). Ops Agents then consist of SP1 and SP2, both of which
share the management of VPL1.

==> This is still unclear - SP1 and SP2 don't appear in Figure 1,
perhaps you mean NSP1 and NSP2. Figure 1 also implies Ops Agents exist
at Site1 and Site2. I'm happy to attempt re-working Figure 1, but I need
better understanding first.

4.2.1. Enterprise IT Department as the Centralized Agent
The Agent could be an Enterprise IT department who holds the Commercial
Agent

==> I think more rigorous use of terminology is necessary - what is
'Commercial' Agent?, 'Centralized' Agent? - using variable terminology
loosely is confusing

 relationship with the customer. In addition, the IT department is
responsible for the enforcement of the customer's network policy by
acting as the Ops Agent. The IT department manages the VPLs and
processes involved in interconnecting the VPL to the NSP VPN domains.
NSP1 and NSP2 independently provide VPN services via their PSNs to the
Ops Agent who is responsible for integrating each NSPs VPN service
offering.

4.2.2. Integration Service Provider as the Centralized Agent
In this model, the Commercial Agent

==> Again, what is 'Commercial Agent'?

 could be an Enterprise IT department. The IT department outsource their
customer's network policy to an Ops Agent who is a SP such as a SI, NI,
VNO or NSP. The Ops Agent will manage the VPL and associated VPN
services interconnects, as well as coordinate end-to-end VPN services
delivered by SP1 and SP2's PSN networks.

==> I don't really see how this is different to 4.1 except with
different actors given different names.

5. Problem Statement

No single network can deliver VPN services that provide optimal price
and performance for all customers or all customer locations, if such
locations are connected through domains administered by different
entities.

==> Not sure I follow this - it is precisely by connecting locations
through domains administered by different entities that the problem is
addressed. So maybe delete everything after 'customer locations'?

 For regulatory, resiliency and other reasons, customers may demand
that multiple NSP networks are used to deliver their VPN services.

==> I'm not sure about this. I don't think customers have any of these
requirements. Customers may have requirements for VPNs that are very
difficult and/or expensive for a single operator to deliver, hence the
need to make it simpler for multiple providers to interconnect in a
standardised fashion.

This document defines common requirements for implementing and operating
an MNE.

==> Common to whom?

6. Customer Agent MNE Requirements
6.1. Capital Scaling Requirement
In an MNE, there might be one or more VPLs. At each VPL there may be one
or more interconnected NSPs, or a single operator that uses the VPL for
connectivity between their own Autonomous Systems. Traditionally, the
interconnection of two NSPs, the so called bilateral interconnect, has
resulted in the deployment of network element resources that are either
dedicated to those two NSPs, or leased from the owner of the peering
point. Where there is a need for a SP to interconnect with multiple
other NSPs, a scaling cost-efficiency could result if interconnected
network elements could be shared across all SPs. This multilateral
approach to network interconnects would have increasing benefit as the
number of interconnected SPs at a VPL increased. Interconnected network
elements in a MNE must therefore be shared multilaterally.

==> Can you be more specific about what 'interconnected network
elements' you are referring to here? Is this something more than a
common L2 fabric?

6.2. Operational Scaling Requirement
Cost of operations is of great concern to a NSP, whether or not VPN
services span their own Autonomous Systems or those of partners.
Compared to the capital cost of MNE interconnection

==> I think you mean NSP interconnection?

, operational cost easily dominates. In an MNE, some, and perhaps all
SPs, might play a part in an individual customer solution. Within a
customer solution, sites, physical and logical connectivity, SPs,
interconnects and service policy might be variously moved, added,
changed or deleted (MACD) at any time.

==> I don't personally like the 'MACD' terminology. Can't we just talk
about service elements being altered, added, relocated or removed?
Collectively  we can refer to 'change management' or 'change control'?
  
6.3.1. VPN Topology Requirement
Although VPN networks offer the possibility for any customer site to
communicate with any other customer site, in certain situations this is
not desirable. There are many possible reasons why a customer might want
to restrict communication amongst sites so that their end-to-end service
becomes segmented. For instance, it may be that security is a concern or
it may be that company sites or divisions must only use connectivity
they have paid for. Furthermore, the traffic flows associated with
specific applications may require a partial topology specifically sized
to accommodate the aggregate traffic flows. 
The segmentation might need to exist on a geographical basis,
region-by-region, country-by country, or on a corporate basis,
division-by-division or site-by-site. Segmentation might even exist
within customer sites. However, today, there are no standards for or
agreement of how VPN topologies are constructed amongst network
operators .

==> Re Christian's comment, I think there might be a misunderstanding
here. There is certainly no need for standardisation of a set of
possible VPN topologies as they are design considerations for the VPN
service provider. However, I can see a requirement for having standard
VPN topology construction methods and VPN membership mechanisms to
address the issues identified. FWIW I think the sentence reads OK as it
is.

Consequently, network operators use different methods for establishing
the logical topology of a VPN and use different schemas to define VPN
membership. For instance, one network operator might use standard
community values to establish layer-2 topology whilst another might use
extended community values. Yet another network operator might use a
combination of both. Alternatively, network operators might segment VPNs
using layer-3 routing techniques. In fact, some network operators might
combine layer-2 and layer-3 segmentation techniques. Additionally, each
network operator will implement a schema for VPN membership that is
proprietary, with membership values that are likely to overlap and
conflict with other network operator values. VPN membership schemas tend
to be difficult to modify due to the 'hard coding' of the schema in each
network operator's OSS and BSS. Conflicting VPN membership schemas and
different methods for establishing logical topology make it very
difficult for the MNE operator to establish an end-to-end VPN topology.
Moreover, an inventory of this topology consisting of elements such as
the network elements/interfaces and the set of paths that traffic may
take through the network should be made available. These elements will
most likely constitute a partial topological view of the network but
would be sufficient for the purpose of QOS polcoy

==> s/polcoy/policy

 definition. There is therefore, a requirement to be able to establish
an end-to-end VPN topology, including network elements and interfaces
throughout an MNE.

==> I tend to think that this requirement and some of the others need to
be further refined and specified in more detail in order to be useful.
For example, the requirement as defined above actually includes
requirements for standardised VPN membership schemas, standardised VPN
topology construction mechanisms, etc.  I think it would be useful to
spell these out as distinct requirements. It would also aid the reader
if there was a table showing the heirarchy and organisation of all the
requirements e.g.:

	Service Provider VPN Policy Control
		VPN Topology
			VPN Membership Schema
			VPN Topology Definition Mechanism
		End-to-end QoS Policy
		etc.

6.3.2. End-to-end QoS Policy Requirement

==> This section introduces multiple requirements, so I think they
should be called out clearly in separate subsections.

Currently, there are no standards for or agreement of service
definitions amongst network SPs. [RFC3644] defines QoS policy as being
dependent upon three types of information; The topology of the network
devices under management (e.g. Diffserv), the particular type of QoS
methodology used and the business rules and requirements for specifying
service(s) delivered by the network. These information types vary across
SP/NSP and customer domains. Consequently, network operators deploy a
different number of classes of service (COS) and specify service
definitions in proprietary ways. Fixed mappings of classes of service
between any two network operators will result in compromised service
across the two. This is in part because fixed mappings cannot utilize
the full service envelope available from the interconnected network
operators (a network operator with three classes of service can only
utilize 3/5ths of the service envelope of a network operator with five
classes of service). In part, it is also because a fixed mapping may be
adequate for some customers, but not for others. This is because QoS
policy is often applied in different ways for each application in each
customer. Sometimes application of a QoS policy can vary within a single
customer. Indeed, as depicted in RFC3644, the definition of QoS policy
is dependent on three types of information: 1) the topology of the
network devices under management, 2) the particular type of QoS
methodology used and 3) the business rules and requirements for
specifying service(s) delivered by the network.

==> This sentence should be deleted as it is repetition of the second
sentence in the paragraph.

When three or more network operators are used to provide connectivity
between customer sites, two or more interconnects is

==> s/is/are

 required and, therefore, a multiple, compounding service compromise
exists.

==> I would say, '... and, therefore, the potential for compromised
service is compounded.'

 In an MNE of many network operators and many interconnects, it is clear
that numerous and compounding compromises in service will take place and
end-to-end QoS policy enforcement may be hard to achieve. There is a
requirement, therefore, for a relationship to exist between network
operator classes of service that may vary from one customer to another,
and that can also utilize the full service envelope of all network
operators within an MNE.

==> Isn't it sufficient to say that there is a requirement for a
default, standardised set of Classes of Service to be supported by all
members of an MNE?

In addition, for some customers who have implemented a QoS policy
amongst some or all of their business locations, it may be desirable for
the customer that an MNE does not modify that policy in any way.
Sometimes this need is characterized as QoS transparency, where the
transparency in question refers to the passing of the enterprise QoS
policy, unmodified, from ingress to egress of a telecommunications
service. [RFC4031] describes this requirement as a 'Carrier's Carrier'
model where one SP is the customer of another L3VPN SP. Such an SP
should be able to resell VPN service to their VPN customers
independently of the DSCP mapping solution employed by the 'Carrier's
Carrier' SP. There is a requirement, therefore, for enterprise QoS
policy transparency throughout an MNE.

6.7. Third Party Interconnect Requirement
Some operators, although they have a need to be able to provide end-to
end service in a solution involving multiple SPs, may be unable to
operate or have no desire to operate an MNE. In order that an MNE can be
established for it and its SP partners, the operator wants a third party
to provide interconnect services to the group. It may be that the third
party is another SP, a systems integrator, a network integrator or
another type of service provider. To achieve end-to-end service, it is
critical that the third party interconnect service provider is able to
control and coordinate global service policy throughout the MNE on
behalf the group.

==> s/behalf the/behalf of the

There is, therefore, a requirement for the interconnect equipment and
procedures to be controllable by a third party interconnect services
provider.



 END

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

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