[Mavs] Comments on the requirements draft
matthew.ford@bt.com Mon, 07 November 2005 11:34 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 1EZ5Gb-0007ap-0m; Mon, 07 Nov 2005 06:34:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ5GZ-0007a1-7t for MAVS@megatron.ietf.org; Mon, 07 Nov 2005 06:34:23 -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 GAA03903 for <mavs@ietf.org>; Mon, 7 Nov 2005 06:33:57 -0500 (EST)
From: matthew.ford@bt.com
Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ5W9-0000mA-9S for mavs@ietf.org; Mon, 07 Nov 2005 06:50:30 -0500
Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 11:34:07 +0000
Received: from I2KM11-UKBR.domain1.systemhost.net ([193.113.197.28]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Nov 2005 11:34:07 +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
Date: Mon, 07 Nov 2005 11:34:14 -0000
Message-ID: <4E28CEA517A795438B120F62D182A8C9020DE5B2@I2KM11-UKBR.domain1.systemhost.net>
Thread-Topic: Comments on the requirements draft
Thread-Index: AcXjjy55lfCE9Fj6TU2uft6PzDxerQ==
To: mavs@ietf.org
X-OriginalArrivalTime: 07 Nov 2005 11:34:07.0695 (UTC) FILETIME=[2A26EDF0:01C5E38F]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: b38aee91eedbacb27d28d558bc16c035
Content-Transfer-Encoding: quoted-printable
Subject: [Mavs] Comments on the requirements draft
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
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. - 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. Good luck with the mini-BoF this this afternoon - I'll try to join via audiocast/jabber. 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] Comments on the requirements draft matthew.ford
- RE: [Mavs] Comments on the requirements draft Martin Halstead
- RE: [Mavs] Comments on the requirements draft matthew.ford