Re: [Mavs] MAVS Requirements Draft posted

hi christian,

there is indeed lot's of progress achieved in terms of requirements for 
activating multi-AS/SP VPNs; imho, starting with topological, security 
and management should received most of the attention (as first step);

concerning "QoS" it would be appropriate to come with a sort of first 
layout because as far as my memory goes a discussion had been initiated 
in Yokohama on QoS for VPN that lead to a short section in RFC4364 and 
as the document also explains very few is available in terms of std's on 
which this multi-AS/SP QoS could rely on; so, from the QoS perspective 
the starting point is different than for inst. the topological aspects

the provided classification and the selected items should be completed 
by a detailed work plan with set of "actions" that would be part of a 
charter

relationship with the work carried out as part of other working groups 
(SIDR, DCP, etc.) could then be determined

i would be willing to help in this process

much thanks,
- dimitri.

JACQUENET Christian RD-TCH-REN wrote:

> Dear all,
> 
> FWIW, please find enclosed the aforementioned draft that has just been
> posted to the IETF web site. Your feedback on this document is more than
> welcome, especially because it may condition the organization of a BoF
> session on this subject during the upcoming IETF meeting of Dallas.
> 
> Cheers,
> 
> Jim, Martin, and Christian.
>  <<draft-Halstead-Guichard-MAVS-Requirements-01.txt>> 
> 
>      _________________    ________  ______  ______ 
>    /_____________   /__ /_    _ / /     / /     /   Christian Jacquenet
> - France Telecom R&D/TCH/NOR 
>       /_________/  /  /   /  /   /  /  / /  /__/    Tel: +33 2 99 12 49
> 40 Cell: +33 6 73 67 73 53 
>                /  /  /___/__/___/_____/_/__/____   "I got my mojo
> workin', 
>               /__/  /__________________________/_ But I'm pinned again."
> 
>                 /_______________________________/ - Pincushion.
>  
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> TBD                                                     M.Halstead, Ed 
> Internet Draft                                            Nexagent Ltd 
> Expires: July 2006                                                    
>                                                       Jim Guichard, Ed 
>                                                     Cisco Systems, Inc. 
>                                                                        
>                                                 Christian Jacquenet, Ed 
>                                                         France Telecom 
>  
>                                                       January 26, 2006 
>  
>                                                                        
> IETF Internet Draft 
>  
> Document: draft-Halstead-Guichard-MAVS-Requirements-01 
>                                       
>            Requirements for Multi Autonomous System VPN Services 
> 
> 
> Status of this Memo 
> 
>    This memo provides information for the Internet community. It does 
>    not specify an Internet standard of any kind. Distribution of this 
>    memo is unlimited. Internet-Drafts are working documents of the 
>    Internet Engineering Task Force (IETF), its areas, and its working 
>    groups.  Note that other groups may also distribute working documents 
>    as Internet-Drafts. Internet-Drafts are draft documents valid for a 
>    maximum of six months and may be updated, replaced, or obsoleted by 
>    other documents at any time. 
> 
> The list of current Internet-Drafts can be accessed at 
> 
> http://www.ietf.org/ietf/1id-abstracts.txt. 
> 
> The list of Internet-Draft Shadow Directories can be accessed at 
> http://www.ietf.org/shadow.html. 
> 
> Copyright Notice 
> 
>    Copyright (C) The Internet Society (2006).  All Rights Reserved. 
> 
> Abstract 
> 
>    This document complements [RFC4031] and defines requirements that are 
>    specific to the delivery of BGP/MPLS-based [RFC-2547bis] VPN services 
>    across multiple administrative domains. These requirements are 
>    independent of underlying technologies or the number of Autonomous 
>    Systems such VPNs may span. It lists the requirements of the 
>  
>  
>  
>                        Expires July 26, 2006                 [Page 1] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    different parties that are involved in the administration of these 
>    Autonomous Systems and may therefore be involved in the delivery of 
>    the VPN service offerings.  
> 
> Conventions used in this document  
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
>    document are to be interpreted as described in RFC-2119.  
> 
> Table of Contents 
> 
>     
>    1. Introduction................................................3 
>    2. Definitions.................................................5 
>       2.1. Multi Domain Environment (MDE)..........................5 
>       2.2. VPN Service Provider (VSP)..............................5 
>       2.3. VPN Peering Location (VPL)..............................6 
>       2.4. Agent..................................................6 
>    3. Problem Statement...........................................6 
>    4. Multi Domain Environment Reference Model.....................7 
>       4.1. Distributed Policy Enforcement Example..................8 
>       4.2. Centralized Policy Enforcement Example..................8 
>    5. Topological Requirements.....................................8 
>       5.1. Remote Service Interconnect Requirement.................8 
>       5.2. Optimal Interconnect Selection Requirement..............8 
>       5.3. Redundant Interconnect Requirement.....................10 
>       5.4. VPN Topology Requirement...............................10 
>       5.5. End-to-end Unicast and Multicast Routing Requirements...11 
>          5.5.1. Generic Routing Considerations....................11 
>          5.5.2. IGP Routing Considerations........................12 
>          5.5.3. BGP Routing Considerations........................12 
>             5.5.3.1. BGP AS_PATH Attribute Considerations..........12 
>             5.5.3.2. Route Distinguisher Allocation Considerations.13 
>             5.5.3.1. Route Target Allocation Considerations........13 
>             5.5.3.2. Traffic Load Balancing Considerations.........13 
>          5.5.4. Multicast Routing Considerations..................14 
>    6. QoS Requirements...........................................14 
>       6.1. Differentiated Services Policy Considerations..........15 
>          6.1.1. QoS Policy Transparency...........................16 
>       6.2. Consistent Metric Considerations.......................16 
>       6.3. Traffic Engineering/Routing Policy Considerations.......17 
>       6.4. Metrology Considerations...............................17 
>    7. Security Requirements.......................................18 
>       7.1. Encryption Requirements................................19 
>       7.2. Label Spoofing Protection..............................20 
>       7.3. Authentication Requirements............................20 
>  
>  
>                        Expires July 26, 2006                 [Page 2] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>          7.3.1. Authentication of Network Elements................20 
>          7.3.2. VPN Route Authentication and Filtering............20 
>    8. Management Requirements.....................................22 
>       8.1. Performance Metric Statistic Requirements..............22 
>       8.2. Capital Scaling Requirements...........................22 
>       8.3. Operational Scaling Requirements.......................22 
>          8.3.1. Service Independence Requirements.................23 
>          8.3.2. Minimize Network Integration Requirements..........23 
>          8.3.3. Third Party Interconnect Requirements.............24 
>       8.4. IPVPN Services Demarcation Requirements................24 
>          8.4.1. Fully Managed Service Demarcation.................24 
>          8.4.2. Mixed Management Service Demarcation..............25 
>       8.5. Remote CE Management Requirement.......................25 
>       8.6. End-to-End Combined Services Requirement...............26 
>          8.6.1. Combined VPN and Internet Access Requirement.......26 
>          8.6.2. Combined IP and non-IP Application Transport Requirement
>           ........................................................26 
>    9. Conclusions................................................27 
>    10. Acknowledgements..........................................27 
>    11. References................................................27 
>       11.1. Normative References..................................27 
>       11.2. Informative References................................28 
>    Editor's Addresses............................................29 
>    12. Intellectual Property Statement............................29 
>    Disclaimer of Validity........................................30 
>    Copyright Statement...........................................30 
>     
> 
> 1. Introduction 
> 
>    This document summarizes requirements that apply to all parties 
>    involved in the delivery of BGP/MPLS-based [RFC-2547bis] VPN services 
>    that span multiple Autonomous Systems (ASes). Such parties include, 
>    but are not limited to, Network Service Providers (NSP), Systems 
>    Integrators (SI), Network Integrators (NI), Cable Operators (CO), 
>    Mobile Operators (MO) and Virtual Network Operators (VNO).  
> 
>    BGP/MPLS-based [RFC-2547bis] services may be delivered between ASes 
>    of the same company (commonly referred to as "Inter-AS" services), or 
>    different companies (commonly referred to as "Inter-provider" 
>    services). This document aims to provide requirements for either type 
>    of service delivery. 
> 
>    BGP/MPLS-based [RFC-2547bis] VPN services are deployed and operated 
>    due to the combined activation of a set of elementary capabilities. 
>    This document is organized to take the requirements for activating 
> 
>  
>  
>                        Expires July 26, 2006                 [Page 3] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    these capabilities across multiple ASes into account using the 
>    following taxonomy: 
> 
>    - Topological considerations: These correspond to the information 
>       needed for the deployment of BGP/MPLS-based [RFC-2547bis] VPN 
>       topologies. This information includes, but is not limited to, 
>       identification of the endpoints that will be interconnected via 
>       the VPN, forwarding and routing policies to be enforced by the 
>       VPN network elements, and the topology of VPN membership. 
> 
>    - QoS considerations: These correspond to the information, with QoS 
>       parameters, that may characterize the level of quality provided 
>       with the VPN service offering. QoS parameters include, but are 
>       not limited to, VPN traffic classification and marking 
>       capabilities, traffic conditioning and scheduling capabilities, 
>       as well as VPN traffic engineering capabilities. 
> 
>    - Security considerations: Any BGP/MPLS-based [RFC-2547bis] VPN 
>       that is deployed and operated across multiple ASes may require 
>       the need for identification, authentication and potentially, VPN 
>       traffic encryption capabilities. This includes the possible 
>       identification and authentication of the resources that 
>       participate in the establishment and operation of a VPN, as well 
>       as the ability to check the integrity of VPN route announcements 
>       exchanged between ASes. 
> 
>    - Management considerations: It is assumed that the operation of 
>       QoS-based BGP/MPLS-based [RFC-2547bis] VPN services is part of 
>       the management tasks performed by service providers within their 
>       own ASes. Additional operational tasks are however needed in 
>       order to enable the management of VPN services across multiple 
>       ASes. 
> 
>    - Measurement and monitoring considerations: the ability to measure 
>       and monitor service delivery is of paramount importance, 
>       especially when such services span multiple ASes. 
> 
>    This document is therefore organized as follows:  
> 
>    - Section 2 defines terminology specific to the delivery of 
>       BGP/MPLS-based [RFC-2547bis] VPN services that span multiple 
>       ASes. This terminology aims at facilitating the overall 
>       understanding of the issues and requirements expressed in this 
>       document. 
> 
>    - Section 3 describes some of the drivers for the deployment of 
>       Multi-AS BGP/MPLS-based [RFC-2547bis] VPN services.  
>  
>  
>                        Expires July 26, 2006                 [Page 4] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    - Section 4 introduces a reference model that depicts the context 
>       for the deployment and the operation of BGP/MPLS-based [RFC-
>       2547bis] VPN service offerings that span multiple ASes. In 
>       addition, use cases illustrate examples of different business and 
>       operational process interaction between the various parties.  
> 
>    - Section 5 describes topological requirements that include traffic 
>       forwarding and routing considerations, VPN traffic load balancing 
>       capabilities, as well as VPL-specific interconnect design 
>       considerations. 
> 
>    - Section 6 describes VPN-specific Multi-AS QoS policy enforcement 
>       requirements which include forwarding, routing and measurement 
>       considerations. 
> 
>    - Section 7 describes VPN-specific Multi-AS security policy 
>       enforcement requirements which include identification, 
>       authentication and encryption considerations. 
> 
>    - Section 8 describes VPN-specific Multi-AS management policy 
>       enforcement requirements which include configuration, fault 
>       detection, performance and accounting management tasks. 
> 
> 2. Definitions 
> 
>    Some of the terminology used in this document is taken from [RFC-
>    4026] and [RFC-4031]. "VPN" in the context of this document refers 
>    specifically to BGP/MPLS-based [RFC-2547bis] VPN services. In order 
>    to clarify the requirements listed in this document, it is necessary 
>    to further define and introduce new terminology, specific to multi 
>    provider VPN services as follows:  
> 
> 2.1. Multi Domain Environment (MDE)  
> 
>    Two or more Autonomous Systems that may or may not be owned by 
>    separate administrative authorities, and which are used to 
>    interconnect service endpoints (sites) of one or more VPNs. 
> 
> 2.2. VPN Service Provider (VSP)  
> 
>    A VSP is an operator who participates in the delivery of a single 
>    domain, or multi-domain (MDE-wide) VPN service. In delivering the VPN 
>    service, the VSP may own a subset, or all of the participating 
>    network elements. Examples of VSPs include Network Service Providers 
>    (NSP), Systems Integrators (SI), Network Integrator (NI), Cable 
>    Operator (CO), Mobile Operator (MO) and Virtual Network Operators 
>    (VNO).  
>  
>  
>                        Expires July 26, 2006                 [Page 5] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
> 2.3. VPN Peering Location (VPL)  
> 
>    A VPL is a physical location where VPN services delivered by one or 
>    more VSPs are interconnected. Examples of VPLs include a network 
>    operator hotel, SP central offices, a collocation facility or any 
>    building common to one or more VSPs. A VPL could be operated by a 
>    single VSP, consortium of VSPs or a neutral 3rd-party.. 
> 
> 2.4. Agent  
> 
>    For the purposes of this document, an Agent is a VSP who is 
>    responsible for the management of multi-party business processes, 
>    negotiations and fulfillment that allow the multi-provider VPN to 
>    function. The Agent manages this responsibility by either 
>    operationally complying with or coordinating policies across all 
>    parties involved in delivering their customer's end-to-end service. 
>    Policy compliance or multi-party policy coordination is achieved 
>    either in a distributed or centralized manner.   
> 
>    For distributed policy enforcement, cooperating VSPs agree upon the 
>    enforcement of consistent policies for VPN service provisioning 
>    purposes. In this case, end-to-end policy enforcement is distributed 
>    across multiple VSPs, each of which is a stakeholder in the supply 
>    and enforcement of a fixed set of policies within the shared MDE. A 
>    VPN customer defines their VPN service requirements with an Agent who 
>    then maps these requirements to the set of pre-agreed policies.  
> 
>    For centralized policy enforcement, the Agent coordinates per 
>    customer, a set of policies related to the management of the 
>    customer's VPN service. In contrast to a shared MDE where policy 
>    enforcement is distributed across multiple VSPs, this Agent will 
>    coordinate policies and integrate VPN services per customer, thereby 
>    creating a MDE that is dedicated to the Agent's customers only. The 
>    Agent may independently agree and manage SLSs with each partner VSP 
>    and offer an aggregated end-to-end SLS to their customer's. 
> 
> 3. Problem Statement 
> 
>    No single network can deliver VPN services that provide optimal price 
>    and performance for all customers and all customer locations. For 
>    regulatory, commercial, resiliency and other reasons, customer 
>    requirements for VPN services may not be compatible with a single VSP 
>    owned network infrastructure. 
> 
>    Alternatively, some customers may have requirements for VPNs that are 
>    difficult and/or expensive for a single VSP to deliver. In this case 
> 
>  
>  
>                        Expires July 26, 2006                 [Page 6] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    the VSP has incentives to cooperate with other VSPs that may offer 
>    similar VPN services, along with broadly compatible SLSs. 
> 
>    For customers (whether they solicit an Agent or not), end-to-end VPN 
>    service delivery is paramount. Controllable, predictable and reliable 
>    VPN service must be delivered regardless of the characteristics of 
>    the MDE. The challenge however for the Agent in controlling 'global' 
>    service policy in an MDE is the lack of homogenous policies amongst 
>    VSPs and the difficulty VSPs have in adapting their VPN service 
>    domains to the customer's Agent-defined VPN service policy.   
> 
>     
> 
> 4. Multi Domain Environment Reference Model 
> 
>    Figure 1 shows a generic reference model for a Multi Domain 
>    Environment. It shows the relationships that exist between the 
>    various parties involved in the establishment of VPN services that 
>    span multiple VSP-administered networks.  
> 
>     
>    |<------------Multi Domain Environment----------->| 
>    |                                                 | 
>    |                     Customer                    | 
>    |                        |                        | 
>    |  +-----------------  Agent ------------------+  | 
>    |  |          |          |         |           |  | 
>    |  |         VSP1       VPL1     VSP2          |  | 
>    |  |          ^          ^         ^           |  | 
>    | 1..n       1..n      1..n       1..n       1..n | 
>    |  V          V          V         V           V  | 
>    |Site1 <---> AS1<---> (VPL1) <---> AS2 <---> Site2| 
>     
>                       Figure 1 - MDE Reference Model 
>     
>    The MDE consists of sites, interconnected via ASes. ASes are then 
>    interconnected via VPLs, within the context of delivering VPN service 
>    offerings. There is potentially a one-to-many relationship between 
>    VSPs and ASes, similarly there is potentially a one-to-many 
>    relationship between VPL operators and VPLs.    
> 
>    With reference to Figure 1, the following sections detail examples of 
>    the coordination of the various parties in the enforcement of a set 
>    of policies. These policies relate to the provisioning of an MDE-wide 
>    VPN service and include (but are not limited to) addressing, routing, 
>    QoS and security.   
> 
>  
>  
>                        Expires July 26, 2006                 [Page 7] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
> 4.1. Distributed Policy Enforcement Example 
> 
>    The customer's Agent is a single VSP (VSP1 in this example). VSP1 
>    manages the relationship with the customer, which includes the 
>    specification, instantiation, possible negotiation and invocation of 
>    the customer's SLS (Service Level Specification). Cooperating VSPs, 
>    VSP1 and VSP2 have pre-agreed an enforced set of policies, including 
>    the management of VPL1. The customer's requirements are mapped by 
>    VSP1 to the pre-agreed policies of VSP1 and VSP2.  
> 
> 4.2. Centralized Policy Enforcement Example 
> 
>    The customer's Agent is a Systems Integrator (SI). The SI does not 
>    own the network infrastructure (the VPN networking elements), but 
>    manages the VPLs, as well as the processes involved in connecting the 
>    VPLs with each relevant VSP owned AS. VSP1 and VSP2 independently 
>    provide customer-specific VPN services and associated SLS 
>    instantiated templates to the SI who is then responsible for 
>    integrating each VSP's VPN service components and 
>    negotiating/invoking an end-to-end SLS with/for their customer.  
> 
>       
> 
> 5. Topological Requirements 
> 
> 5.1. Remote Service Interconnect Requirement 
> 
>    In an MDE, Agent(s) will select VSPs according to the needs of their 
>    customer. VSP owned ASes may or may not be collocated at the same 
>    VPL. For those ASes that are collocated at the same VPL, 
>    interconnection of VPN services can take place locally. However, in 
>    the example of an end-to-end chain of three VSP owned ASes and two 
>    VPLs, local VPN interconnection will happen twice; once at the first 
>    VPL (first to second AS) and once at the second (second to third AS). 
>    However, in some situations, the Agent may choose not to use the VPN 
>    service of the second (middle) VSP. Instead, the Agent may wish to 
>    interconnect the VPN services of the first and third VSPs remotely. 
>    There is, therefore, an Agent-driven requirement to be able to 
>    remotely interconnect services of non-collocated VSP owned ASes in an 
>    MDE.  
> 
> 5.2. Optimal Interconnect Selection Requirement 
> 
>    VSP multi-homing is the scenario in which a VSP needs to interconnect 
>    their AS at two or more VPLs. By ensuring that traffic passes between 
>    ASes at pre-determined VPLs, the desired end-to-end VPN service 
> 
>  
>  
>                        Expires July 26, 2006                 [Page 8] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    delivery can be established and retained for any customer sites. VSP 
>    networks can therefore be utilized more efficiently.  
> 
>    As an example, consider a customer site in the middle of the USA. It 
>    is connected to a VSP's AS that is interconnected at VPLs in both New 
>    York and Los Angeles. In order to minimize latency, traffic must be 
>    sent to Tokyo via the LA VPL and not via New York. From a network 
>    utilization perspective, routing Tokyo-bound traffic via New York 
>    incurs an inefficient, resource-consuming round trip traversal of the 
>    USA. Similarly, the same site might also send traffic to London. The 
>    optimal route for this traffic will be via New York rather than LA.  
> 
>    Although this scenario may be taken care of by standard IP routing, 
>    the specifics of a VSPs BGP routing policy, or traffic engineering 
>    implementation, may force some traffic to be forwarded away from the 
>    best path. Therefore, for multi-homed ASes, there is a requirement 
>    for interconnects at multiple VPLs to be optimally selectable for 
>    each source-destination site pair within an MDE. Nevertheless, the 
>    notion of optimality should not necessarily be expressed in terms of 
>    hop count metrics. The selection of the optimal interconnecting 
>    points should rely upon a variety of criteria that include (but are 
>    not necessarily limited to): 
> 
>    - The minimum number of hops that need to be crossed to reach a 
>       given (set of) VPN destination(s),  
> 
>    - The minimum value of the one-way transit delay to reach a given 
>       (set of) VPN destination(s), 
> 
>    - The minimum value of the inter-packet delay variation to reach a 
>       given (set of) VPN destination(s), 
> 
>    - The minimum value of the packet loss rate to reach a given (set 
>       of) VPN destination(s), 
> 
>    - The preservation of the confidentiality of the traffic that may 
>       be exchanged between a given set of VPN locations, 
> 
>    - The maximum VPN prefix length that should be announced at VPL 
>       locations, 
> 
>    - The use of VPL locations that should not share network resources 
>       involved in the forwarding of Internet traffic, 
> 
>    - The required traffic symmetry to allow a given source-destination 
>       pair to be forwarded on the same path in both directions so as to 
>       avoid packet mis-ordering 
>  
>  
>                        Expires July 26, 2006                 [Page 9] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    - The available bandwidth capacity at the VPL (in the case where 
>       overbooking policies are in effect at the VPL) 
> 
>    - Any combination of the above criteria. 
> 
> 5.3. Redundant Interconnect Requirement 
> 
>    Part of the end-to-end VPN service offering provided by one or more 
>    Agents involves the provision of appropriate levels of redundancy for 
>    their MDE use case. In some VPLs, where business justifications 
>    exist, Agents or VSPs may choose to enhance interconnect reliability 
>    by implementing a redundant interconnect complex.  
> 
>    The resulting interconnects might exist in the same building or in 
>    different buildings within a city or in different buildings in 
>    different cities. This is in addition to the Optimal Interconnect 
>    Selection requirement in that a customer service will be designed to 
>    traverse each redundant interconnect, rather than a specific, optimal 
>    interconnect.  
> 
>    There is therefore a requirement to support customer services across 
>    redundant interconnects. 
> 
> 5.4. VPN Topology Requirement 
> 
>    Although VSP owned ASes 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 customer 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 and country-by country. Alternatively, segmentation might 
>    need to exist 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 VSPs. Consequently, VSPs use different 
>    methods for establishing the logical topology of a VPN and use 
>    different schemas to define VPN membership.  
> 
>    For instance, one VSP might use standard community values to 
>    establish layer-2 topologies whilst another might use extended 
>  
>  
>                        Expires July 26, 2006                [Page 10] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    community values. Yet another VSP may use a combination of both 
>    techniques. Alternatively, VSPs may segment VPNs using layer-3 
>    routing techniques. In fact, some VSPs might combine layer-2 and 
>    layer-3 segmentation techniques.  
> 
>    Additionally, each VSP will implement a schema for VPN membership 
>    that is proprietary, with membership values that are likely to 
>    overlap and conflict with other VSP assigned values. VPN membership 
>    allocation schemas tend to be difficult to modify due to the 'hard 
>    coding' of the schema in each network operator's OSS and BSS systems.  
> 
>    Conflicting VPN membership schemas and different methods for 
>    establishing logical topologies make it very difficult for the Agent 
>    to establish an end-to-end VPN service. Moreover, an inventory of the 
>    topology consisting of the network elements/interfaces and set of 
>    paths that traffic may take through the network could in addition be 
>    difficult for the VSP to be made available to the Agent.  
> 
>    These elements will most likely constitute a partial topological view 
>    of the network but may be sufficient and required for the purpose of 
>    QoS policy definition.  
> 
>    There is therefore, a requirement to be able to establish an end-to-
>    end VPN topology, including the publishing of network elements and 
>    interface inventories per VSP throughout an MDE. 
> 
> 5.5. End-to-end Unicast and Multicast Routing Requirements 
> 
>    5.5.1. Generic Routing Considerations 
> 
>    Routing and forwarding configuration information deals with the 
>    decision criteria that should be taken by a network element in order 
>    to forward VPN specific traffic according to a given VPN routing 
>    policy. From this perspective, VSP owned network elements should be 
>    provided as a minimum with the following information:  
> 
>    - Relevant metric information so that network elements can 
>       dynamically assign these metric values. Such metric values could 
>       be assigned on either long or (very) short-term basis. Examples 
>       of assigned 'long-term' metrics include packet loss and delay 
>       thresholds, usually expressed as percentiles of available 
>       resources. Short-term metrics may include available or reserved 
>       bandwidth, typically provided via real-time or near real-time 
>       SNMP MIB queries. 
> 
> 
> 
>  
>  
>                        Expires July 26, 2006                [Page 11] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    - The configuration information related to any static route that 
>       may identify a VPN endpoint (or VPL) as the next hop to reach a 
>       given VPN destination prefix. 
> 
>    5.5.2. IGP Routing Considerations 
> 
>    Today there are no standards for, or agreement of, how VPN routing 
>    policy based upon the policing of the admission and distribution of 
>    VPN routing information (classification and filtering of routing 
>    information) is implemented amongst VSPs.  
> 
>    Consequently, VSPs enforce VPN routing policies within a defined 
>    customer topology in different ways. For example, in an MDE, where 
>    the EF-inferred IGP policy [RFC2676] of AS1 relies upon the 
>    computation of routes with a maximum one-way transit delay of 120 ms 
>    in order to reach a set of destination prefixes, and AS2 defines the 
>    equivalent EF-inferred IGP policy with a different QoS parameter 
>    (e.g. maxLossRate=0%), then there is a risk of jeopardizing the 
>    overall quality of service of the multi-AS VPN. Conflicting routing 
>    policies amongst VSPs therefore make it difficult to establish an 
>    end-to-end unicast routing policy throughout an MDE.  
> 
>    There is, therefore, a requirement to be able to enforce a consistent 
>    IGP routing policy throughout an MDE. 
> 
>    5.5.3. BGP Routing Considerations 
> 
>    VSP owned network elements should be provided with relevant BGP-4 
>    [RFC-1771] reachability information, including the attributes taken 
>    into account by the network element's route selection process in 
>    order to decide whether or not traffic should be forwarded along a 
>    given VPN route. 
> 
>      5.5.3.1. BGP AS_PATH Attribute Considerations 
> 
>    Where BGP-4 is used as the PE-CE routing protocol, the use of a 
>    single private [RFC-1930] AS Number (ASN) across all customer sites 
>    hosted by multiple VSPs could raise issues for each VSP as they 
>    commonly use the 'as-override' command on PE-CE neighbors.  
> 
>    Where VPN-IPv4 routes are advertised across multiple ASes, VSP owned 
>    public Autonomous System Numbers (ASNs) could be pre-pended to 
>    private route updates. The 'as-override' feature will not then 
>    operate over PE-CE IPv4 links where public and private ASN numbers 
>    are advertised within the same VPN address prefix.  
> 
> 
>  
>  
>                        Expires July 26, 2006                [Page 12] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    Network elements located at a VPL should therefore be capable of 
>    removing or changing public or private ASNs from the BGP AS_PATH 
>    attribute on a per neighbor basis. This per neighbor AS path match 
>    and removal policy should be capable of being performed on ingress or 
>    egress across the entire AS path. 
> 
>      5.5.3.2. Route Distinguisher Allocation Considerations 
> 
>    VPN-IPv4 routes [RFC2547bis] are made unique across a domain by 
>    combining an IPv4 address with an 8 byte 'Route Distinguisher' (RD) 
>    value. The advertisement of RD values end-to-end between VSPs, 
>    combined with the customer's use of private [RFC1918] addressing 
>    could result in Route Reflectors (RR) making incorrect best path 
>    decisions for identical routes received from external as well as 
>    internal PE network elements. This will occur where RD and customer 
>    address space overlap across VSP ASes. Although the probability of 
>    this scenario is small, the consequences could be severe and 
>    difficult to isolate, therefore VSP owned RRs and PE's SHOULD NOT 
>    receive VPN-IPv4 routes that have RD values assigned by another VSP. 
>    In order to ensure that RD values that transit VPLs are unique, RD 
>    values MUST be pre-pended by a public registered AS number ([RFC-
>    2547bis], section (4.1). 
> 
>      5.5.3.1. Route Target Allocation Considerations 
> 
>    VSPs usually have difficulty in provisioning extended (Route Target) 
>    or standard BGP community values on their PE network elements that 
>    are assigned by external parties such as the end customers Agent or 
>    another VSP. This difficulty is due to the VSP having automated or 
>    manual OSS systems and operational procedures that typically apply to 
>    per VSP ASes only. These systems and processes are difficult to 
>    change due to schema conflicts brought about by attempting to 
>    incorporate externally assigned RT allocation schemas. In addition, 
>    not all VSPs allocate RT values that are pre-pended with a publicly 
>    registered ASN or IP address. RT values to be applied on VSP PEs 
>    therefore should be assigned by the operator of the PE. In order to 
>    ensure that BGP extended community values are unique between ASes, RT 
>    values that are advertised across the VPL MUST be pre-pended by a 
>    public registered ASN. This follows the specification detailed in the 
>    'Identifiers' section of [RFC-4031] and assists in the prevention of 
>    cross-connection for VPN services.  
> 
>      5.5.3.2. Traffic Load Balancing Considerations 
> 
>    VSPs use various traffic load-balancing techniques between customer 
>    sites to optimize traffic flows within their own ASes. As described 
>    in [RFC2547bis], this necessitates the use of different RD values 
>  
>  
>                        Expires July 26, 2006                [Page 13] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    provisioned across VRFs to which the customer is multi-homed. Similar 
>    mechanisms SHOULD be available when VSP owned ASes are multi-homed 
>    across multiple VPLs and where the VSP wishes to optimize customer 
>    traffic via load balancing. Such mechanisms may require that the 
>    signaling protocol support the advertisement of all available paths 
>    so that optimal path selection is available as well as backup paths 
>    in case of optimal path failure. 
> 
>    5.5.4. Multicast Routing Considerations 
> 
>    IP multicast transmission schemas may be used by some applications 
>    such as videoconferencing or TV broadcasting in order to optimize VPN 
>    network resources. 
> 
>    As a result, VSP owned network elements should support multicast 
>    routing capabilities for the dynamic establishment and maintenance of 
>    distribution trees within the VPN and should therefore be provisioned 
>    with the relevant yet consistent configuration information.  
> 
>    There are currently however no standards for, or agreement of, an 
>    enforcement of consistent multicast routing policies amongst VSPs. 
>    There is therefore a requirement to be able to enforce an end-to-end 
>    multicast routing policy for the sake of the establishment and 
>    maintenance of consistent distribution trees throughout an MDE.  
> 
> 6. QoS Requirements 
> 
>    Quality of service is a very generic term, which is sometimes 
>    misused, especially when applied to IP/MPLS environments. In this 
>    document, the design and the enforcement of a QoS policy within VPN-
>    specific MDE environments relies upon the following dimensions: 
> 
>    - A forwarding dimension, which consists of ensuring that a VSP 
>       owned network element behaves differently, depending on the kind 
>       of traffic it has to process and subsequently forward. This 
>       yields a need for VPN traffic identification, classification and 
>       possibly activation of traffic conditioning, policing, scheduling 
>       and optionally, discarding mechanisms. The forwarding dimension 
>       of a QoS policy is a notion that is local to a network element, 
>       independent from the expected behaviors of the other network 
>       elements within the MDE. The DiffServ (Differentiated Services) 
>       architecture, as described in [RFC-2475], is generally seen as 
>       the cornerstone of the forwarding dimension, introducing the 
>       notion of classes of service as well as Behavior Aggregates (BA). 
> 
> 
> 
>  
>  
>                        Expires July 26, 2006                [Page 14] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    - A metric definition dimension, which consists of defining 
>       consistent metrics such as delay, jitter and loss, so as to 
>       support QoS meaningfully across multiple VSPs. 
> 
>    - A routing dimension, which consists of enforcing a VPN-specific 
>       traffic engineering policy at the scale of a MDE. Traffic 
>       engineering is a set of capabilities that allow the (hopefully 
>       dynamic) computation and selection of paths that will be used to 
>       convey different kinds of VPN traffic. It may be necessary to 
>       route QoS-sensitive traffic to different VSPs or along different 
>       paths other than those selected by best effort traffic. Path 
>       selection is dependant on the (QoS) characteristics of such 
>       paths, which comply with the QoS requirements that have been 
>       expressed and negotiated by the Agent with their VPN customers.   
> 
>    - A monitoring dimension, which consists of qualifying how 
>       efficient a QoS policy is enforced within a MDE, based upon the 
>       use and measurement of well-defined indicators. Due to the 
>       multiple parties involved in the delivery of QoS, it is necessary 
>       to have well defined methods for measurement of QoS, ways to 
>       monitor the performance of different network elements, and ways 
>       to report performance consistently among VSPs. Such indicators 
>       include (but may not be limited to) one-way transit delay, one-
>       way inter-packet delay variation (sometimes called jitter), one-
>       way packet loss rate or any combination of such indicators.   
> 
>      
> 
> 6.1. Differentiated Services Policy Considerations 
> 
>    Currently, there are no standards for or agreement of service 
>    definitions as defined in the Diffserv architecture amongst VSPs. 
>    [RFC-3644] defines QoS policy within a single Diffserv domain as 
>    being dependent upon three types of information:  
> 
>    - The topology of the network elements under management;  
> 
>    - The particular type of QoS methodology used (e.g. Diffserv), and;  
> 
>    - The business rules and requirements for specifying service(s) 
>       delivered by the network.  
> 
>    These information types vary across VSP ASes. Consequently, VSPs 
>    deploy different numbers of classes of service (COS) and specify 
>    service definitions in proprietary ways. Fixed mappings of classes of 
>    service between any two VSPs may result in compromised service across 
>    the two. This is in part because fixed mappings cannot always utilize 
>  
>  
>                        Expires July 26, 2006                [Page 15] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    the full service envelope available from the interconnected VSPs (a 
>    VSP with three classes of service can only utilize 3/5ths of the 
>    service envelope of a VSP with five classes of service). Furthermore,  
>    fixed mappings may be adequate for some Agent's customers, but not 
>    for others. This is because QoS policy is often applied in different 
>    ways for each application used in each customer environment 
> 
>    When three or more VSP ASes are used to provide connectivity between 
>    customer sites, two or more VPLs are required and, therefore, a 
>    multiple, compounding service compromise exists.  
> 
>    In an MDE of many VSP ASes and VPLs, 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 VSP classes of service that may vary from one customer to 
>    another, and that can also utilize the full service envelope of all 
>    VSPs within an MDE.  
> 
>    6.1.1. QoS Policy Transparency 
> 
>    There is general agreement that customer packets should not be 
>    remarked (that is, have their DSCP values modified) as they transit 
>    the MDE. At the same time, it is often necessary for the VSP to 
>    impose a QoS treatment on customer packets that differs from that 
>    which might be indicated by the customer's DSCP (such as is the case 
>    for non-conforming traffic downgraded to best effort). However, even 
>    if the packets are treated as best effort by the VSP, the customer 
>    wishes to retain the original DSCP marking for their own use when the 
>    packets arrive at their remote site. This requirement is defined as 
>    "QoS transparency", where the transparency in question refers to the 
>    tunneling of the customer QoS policy, unmodified, from ingress to 
>    egress across an MDE. [RFC-4031] describes this requirement as a 
>    'Carrier's Carrier' model where one VSP is the customer of another 
>    VSP. Such a VSP should be able to resell VPN services to their 
>    customers independent of the DSCP mapping solution employed by the 
>    'Carrier's Carrier' VSP.  
> 
>    There is a requirement, therefore, for enterprise QoS policy 
>    transparency throughout an MDE. 
> 
> 6.2. Consistent Metric Considerations 
> 
>    Currently, there are no standards for, or agreement of metric 
>    definitions between VSPs. As an example, the Low Latency service 
>    class is generally characterized by three network performance 
>  
>  
>                        Expires July 26, 2006                [Page 16] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    metrics; latency, packet loss, and jitter. These metrics are 
>    generally reported as two-way or one-way derived from two-way 
>    measurements, but are generally defined differently between VSPs.  
> 
>    There is therefore a requirement to produce service classes with 
>    metrics that can be meaningfully concatenated, so as to provide 
>    reasonable commonality of metrics across VSPs. 
> 
> 6.3. Traffic Engineering/Routing Policy Considerations  
> 
>    In a true MDE environment there may be many alternate paths between 
>    customer sites. The preferred path among VSPs is typically determined 
>    by BGP policies. However, when multiple classes of service exist, it 
>    may be desirable to route some traffic preferentially via VSPs who 
>    support the enhanced QoS class(es) while best effort traffic takes 
>    the conventional route. That is to say, there may be cases in which 
>    the current route selection capabilities of BGP, which yield only a 
>    single best path for a given prefix, may not be sufficient. The 
>    deployment of traffic engineering capabilities in VPL owned network 
>    elements is of importance when considering the joint forwarding of 
>    "triple-play" services where data, video and voice traffic is 
>    forwarded within a given VPN.   
> 
>    Within a MDE, VSPs or Agents should provide configuration information 
>    parameters that will allow network elements to choose appropriate VPN 
>    paths to a given destination based on "Service Contexts". These paths 
>    are chosen according to application-specific constraints, available 
>    service characteristics and/or requirements.  
> 
>    These constraints and/or requirements may be expressed in terms of 
>    time duration (e.g. the use of a VPN route on a weekly basis), 
>    traffic characterization (e.g. all IP multicast traffic should be 
>    forwarded along a set of specific VPN routes), security concerns 
>    (e.g. use trusted network elements along the path towards specific 
>    destinations), and/or QoS considerations (e.g. marked VPN traffic 
>    with a specific DiffServ Code Point (DSCP) value should always use a 
>    configured set of traffic-engineered VPN routes, or available exit 
>    point that exhibits the desired "Service Context").  
> 
> 6.4. Metrology Considerations 
> 
>    Currently, there are no standards for, or agreement of, measurement 
>    methods amongst VSPs. VSPs define measurements differently and 
>    measure different service end points. In a MDE environment, 
>    measurement methodology differences, particularly differences in the 
>    statistical nature of the measurements, make it impossible to combine 
> 
>  
>  
>                        Expires July 26, 2006                [Page 17] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    VSP measurement reports so that the overall quality of the VPN 
>    service can be qualified.  
> 
>    As VSP reports can be so different, it is tedious and time consuming 
>    to analyze whether an individual VSP or VPL operator has met its 
>    performance targets. When end-to-end services fail, it may be very 
>    difficult to analyze VSP measurement data in order to detect and 
>    isolate faults amongst VSPs or VPL operators.  
> 
>    In an MDE, where the customer's Agent(s) are responsible for end-to-
>    end service, this may be untenable. In addition, whilst windows for 
>    scheduled and unscheduled maintenance will remain difficult for the 
>    Agent(s) to control or coordinate, any measurement methodology must 
>    take these windows into account in any performance assessments of the 
>    QoS policy that are made.  
> 
>    There is, therefore, a requirement for statistically homogenous 
>    measurement throughout an MDE as well as the ability to place 
>    measurement instrumentation/sources at VPL locations in order to aid 
>    fault detection and isolation. 
> 
> 7. Security Requirements 
> 
>    Security is a requirement of any business, but the requirement 
>    becomes more important where that business collaborates with others 
>    to provide a service [RFC-4111]. Potential threats might emanate from 
>    a number of sources, for instance, other VSPs, VPL operators and 
>    customers.  
> 
>    Clearly, the vulnerability of a customer service to threats from 
>    these sources is of paramount importance. Of equal importance is the 
>    vulnerability of a VSP AS to threats from these sources. An attack on 
>    a VSP AS could detrimentally affect numerous customers, including 
>    those attached to other VSP owned ASes.  
> 
>    Enforcement of a security policy at the scale of a MDE assumes the 
>    availability of the following capabilities as a minimum:  
> 
>    - The identification and the authentication of the users who may be 
>       entitled to access the VPN service,  
> 
>    - The identification and authentication of network elements that 
>       will not only participate in the deployment and the operation of 
>       the VPN, but also in VPN route information propagation, 
> 
>    - The preservation of the confidentiality of information within a 
>       VPN.  
>  
>  
>                        Expires July 26, 2006                [Page 18] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    VSPs should therefore be provided with configuration information 
>    related to the aforementioned security parameters. This does not mean 
>    that VSP owned network elements have to maintain a dynamically 
>    updated user database, rather, they should be provided with the 
>    following configuration information as a minimum:  
> 
>    - Identification information for IP networks that may exchange data 
>       through the VPN and/or the configuration information required for 
>       the activation of an identification/authentication mechanism such 
>       as RADIUS (Remote Authentication Dial-In User Service), [RFC-
>       2865],  
> 
>    - Identification information for VSP owned network elements that 
>       support endpoint(s) of the MP-BGP peer and possibly configuration 
>       information related to the activation of a mechanism for 
>       identifying and authenticating such peers (such a mechanism could 
>       be based upon the use of a SHA-1 (Secure Hash Algorithm) digital 
>       signature for example), 
> 
>    - Configuration information required for encryption purposes. This 
>       requirement is further expanded on in section 7.1.  
> 
>    There is a requirement, therefore, to secure VSP ASes and customer 
>    services in an MDE as well as securely forward VPN related security 
>    parameters between VSPs and Agents. 
> 
> 7.1. Encryption Requirements 
> 
>    VPN customers may require all or part of their encrypted traffic to 
>    be preserved, independent of the number of VSP owned ASes within the 
>    MDE supporting their VPN service. 
> 
>    There is therefore a need for the MDE to support any relevant 
>    encryption technique that preserves the confidentiality of the VPN 
>    traffic. This implies that: 
> 
>    - The VSP owned network elements that compose the MDE should 
>       support protocols of the IPsec suite [RFC-4301], 
> 
>    - The MDE should be capable of supporting an adequate means for 
>       identifying and authenticating any participating device involved 
>       in the forwarding of VPN traffic, 
> 
>    - The MDE should be capable of supporting an adequate means for 
>       identifying and authenticating any participating VSP owned 
>       network element involved in the enforcement of the VPN-specific 
>       routing policy. Such means should enable any VSP owned network 
>  
>  
>                        Expires July 26, 2006                [Page 19] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>       element to check the integrity of received VPN route 
>       announcements, 
> 
>    - The MDE should be capable of supporting and enforcing any dynamic 
>       key management scheme suitable for the dynamic establishment of 
>       Secure Associations (SA) between relevant VSP owned network 
>       elements, 
> 
>    - VSPs that are involved in the dynamic establishment of SA 
>       associations across their ASes should be provided with relevant 
>       configuration information (keys, passwords) in a timely manner, 
>       that is, the provisioning of such configuration information 
>       should not jeopardize the time to deliver the VPN service 
>       offering to the customer with the required level of security.  
> 
> 7.2. Label Spoofing Protection 
> 
>    Whenever labels are exchanged between two VSP peers it is possible 
>    that the spoofing of such labels may occur either toward the internal 
>    infrastructure of the said VSPs, or within the VPNs that are 
>    supported by such VSPs. There is therefore a requirement to provide 
>    mechanisms that prevent the spoofing of labels in the forwarding 
>    path. 
> 
> 7.3. Authentication Requirements 
> 
>    7.3.1. Authentication of Network Elements 
> 
>    Within a MDE, every VSP owned network element that participates in 
>    the deployment and the operation of a VPN service offering should be 
>    trusted. There is therefore a requirement to provide acceptable 
>    authentication processes in order for a network element to 
>    participate in the deployment and operation of a VPN service. This 
>    implies that every VSP owned network element must be identified and 
>    authenticated typically via processes owned by relevant Agents or 
>    VSPs. 
> 
>    7.3.2. VPN Route Authentication and Filtering 
> 
>    Within a MDE, every VSP owned network element is permitted to 
>    announce VPN routes to some or all of its pre-authenticated peers, 
>    assuming the requirements expressed in section 8.2.1. have been 
>    addressed. 
> 
>    VSPs have existing mechanisms and operational processes that prevent 
>    the cross connection of VPNs within their own ASes. These mechanisms 
>    include manual or automated systems for VPN membership allocations 
>  
>  
>                        Expires July 26, 2006                [Page 20] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    that include per customer RT values. Where the VSP extends VPN 
>    services via an MDE, incorrect or malicious configuration of VPN 
>    membership information could result in cross connection or incorrect 
>    announcement of VPN membership attributes across an MDE. These route 
>    announcements could in addition expose the VPN topology of the VSP.  
> 
>    The integrity of the contents of such VPN route announcements must be 
>    authenticated by any receiving peer and/or by some kind of VPN route 
>    server capability that could be embedded in the relevant Agent or VSP 
>    owned facility before the receiving peer accepts the announced route. 
>    Draft [VPN-VERIFICATION] could assist with this route authentication 
>    requirement.   
> 
>    It should be possible to enforce further VPN route-specific filtering 
>    policies at appropriate locations within an MDE. Additional route 
>    filtering criteria could be based upon (but not necessarily limited 
>    to): 
> 
>    - Intra-VPL communication restriction where, for example, RT value 
>       announcements are filtered such that they only include interested 
>       parties across VPL locations. This filtering policy is 
>       particularly relevant where the VSP owned network elements peer 
>       with more than one network element at a VPL. This function is 
>       described further in [RT-CONSTRAIN] 
> 
>    - Intra-VPN communication restrictions, where, for example, not all 
>       sites are permitted to communicate 
> 
>    - The contracted metrics with the VPN customer and between VSPs for 
>       routing table size, routing protocol type, and end-to-end routing 
>       policy. 
> 
>    - The required end-to-end convergence time to avoid the case where 
>       restoration policies, timer values, or fast convergence protocols 
>       (such as BFD), differ between VSPs. 
> 
>    - Inter-AS routing restrictions, where, for example, some VPN 
>       traffic shouldn't be transported across one or more ASes within 
>       an MDE 
> 
>    - Time based restrictions, where, for example, some destinations 
>       cannot be reached during working hours, 
> 
>    - QoS based restrictions, where, for example, traffic should not be 
>       bound for VPN route sources that experience more than a 100 ms 
>       one-way transit delay. Traffic route sources that experience 
> 
>  
>  
>                        Expires July 26, 2006                [Page 21] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>       delay over a certain threshold should not then be announced at 
>       selected VPLs.  
> 
> 8. Management Requirements 
> 
> 8.1. Performance Metric Statistic Requirements 
> 
>    Agents have stringent usage requirements for an MDE. From this 
>    perspective, VSPs should permit an Agent to have access to 
>    statistical information based upon, (but not necessarily limited to):  
> 
>    - The volume of traffic that has been conveyed by the entire VPN, a 
>       specific VPN route, forwarded by a specific network element or 
>       over a given period of time that may include a distinction 
>       between incoming and outgoing traffic,  
> 
>    - The volume of VPN traffic that has been dropped by network 
>       elements within a given period of time,   
> 
>    - IPPM (IP Performance Metrics) [RFC-2330] related information that 
>       is relevant to tunnel usage: such information includes one-way 
>       transit delay, inter-packet delay variation etc. 
> 
> 8.2. Capital Scaling Requirements 
> 
>    In an MDE, there might be one or more VPLs. At each VPL there may be 
>    one or more interconnected VSP ASes, or a single VSP that uses the 
>    VPL for connectivity between their own ASes.  
> 
>    Traditionally, the interconnection of two VSP ASes has resulted in 
>    the deployment of network element resources that are either dedicated 
>    to those two VSPs, or leased from the VPL operator.  
> 
>    Where there is a need for a VSP to interconnect with multiple other 
>    VSPs, scaling cost efficiency could result if interconnected network 
>    elements could be shared across all VSPs. This multilateral approach 
>    to VPL design will have increasing benefit as the number of 
>    interconnected VSPs at a VPL increases.  
> 
>    Interconnected network elements at VPLs must therefore be shared 
>    multilaterally.  
> 
> 8.3. Operational Scaling Requirements 
> 
>    Cost of operations is of great concern to a VSP, whether or not VPN 
>    services span their own ASes or those of their VSP partners. Compared 
>    to the capital cost of MDE interconnection at a VPL, operational cost 
>  
>  
>                        Expires July 26, 2006                [Page 22] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    easily dominates. In an MDE, some, and perhaps all VSPs, might play a 
>    part in delivering services to an individual customer's VPN.  
> 
>    Within a customer VPN, sites, physical and logical connectivity, 
>    VSPs, VPLs and VPN-specific policies might be variously moved, added, 
>    changed or deleted (MACD) at any time. In fact, different components 
>    of the VPN will, at times, undergo MACD concurrently.  
> 
>    Service MACD lifecycle is part of any customer VPN and will happen as 
>    needed throughout the VPN's service life. As an MDE evolves, with 
>    increasing numbers of VSPs, VPLs and customers, the amount of service 
>    MACD will increase and place a continual and increasing burden on VSP 
>    operators throughout an MDE unless a scalable approach is taken. 
>    Operational scaling criteria could be based upon (but are not 
>    necessarily limited to) the following sections. 
> 
>    8.3.1. Service Independence Requirements 
> 
>    In an MDE, it is inevitable that dependencies will exist between the 
>    services of individual VSPs. For example, a lack of forethought by 
>    the VPL operator by implementing a 'tightly-coupled' VPL interconnect 
>    environment would result in single VSP changes to topology, 
>    bandwidth, routing, QoS, etc., requiring all other VSPs to modify 
>    their definitions of existing services.  
> 
>    Service dependencies amongst VSPs in a MDE must therefore be 
>    minimized. 
> 
>    8.3.2. Minimize Network Integration Requirements 
> 
>    Currently there is no common agreement for how VSPs implement the 
>    interconnection of their VPN networks. This means that each inter-AS 
>    interconnect agreement at a VPL by VSP pairs will be a unique 
>    project, each of which potentially having different design goals and 
>    compromises.  
> 
>    Each unique inter-AS interconnect agreement will usually take 
>    considerable time and consume highly skilled resources in both 
>    organizations. As the number of VPLs increases, so the load on the 
>    organizations will increase. In an MDE, the required number of unique 
>    inter-AS interconnect agreements could rapidly become untenable. 
>    Unique network inter-AS interconnect agreements amongst VSP pairs 
>    must therefore be minimized.  
> 
> 
> 
> 
>  
>  
>                        Expires July 26, 2006                [Page 23] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    8.3.3. Third Party Interconnect Requirements 
> 
>    Agents or VSPs require the ability to provide end-to-end services 
>    within an MDE. These Agents or VSPs may however have no desire or be 
>    unable to administer the coordination of business and operational 
>    processes involved in establishing an MDE. In order for an MDE to be 
>    established, the Agent or VSP may therefore require a third party 
>    operator to provide these business and operational process services.  
> 
>    It may be that the third party is another VSP, 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 operator is 
>    able to control and coordinate global service business and 
>    operational process policy throughout the MDE.  
> 
>    There is, therefore, a requirement for the business and operational 
>    processes involved in establishing an MDE to be administered by a 
>    third party operator. 
> 
> 8.4. IPVPN Services Demarcation Requirements 
> 
>    8.4.1. Fully Managed Service Demarcation 
> 
>    [RFC-2547bis]-based VPN services may encompass a 'fully managed' 
>    Customer Edge (CE) to CE service with associated SLSs. In an MDE, 
>    this 'fully managed' service is interconnected to other VSP-owned 
>    services via VPLs. For SLS demarcation purposes, the VSP may express 
>    a preference to collocate a dedicated network element at each VPL. 
>    The VPL collocated network elements will, from an operational 
>    perspective function identically to a CE. In contrast to a standard 
>    CE however, each VPL collocated network element will usually support 
>    more than a single VPN across one or more customers and/or VSPs. From 
>    a scalability perspective, this is particularly advantageous for the 
>    VSP when interconnecting multiple VPN services at each VPL on behalf 
>    of one or more Agents. The SLS offered by the VSP to each Agent 
>    partner will in addition to CE-to-CE connectivity, include 
>    connectivity from each CE to one or more VPL collocated network 
>    elements.  
> 
>    For contractual and/or technical reasons, the VSP may decide for 
>    example to collocate a network element per Agent, per group of Agents 
>    or per VPN. In all cases, consistent, unambiguous service boundaries 
>    for the fully managed service offering are essential.  
> 
>    There is a requirement, therefore for consistent SLS demarcation 
>    points across 'fully managed' VPN service offerings within an MDE. 
> 
>  
>  
>                        Expires July 26, 2006                [Page 24] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    8.4.2. Mixed Management Service Demarcation 
> 
>    In addition to 'fully managed' services, VSPs also offer VPN services 
>    that allow for a third party such as the VSPs customers to manage 
>    their own CE network elements. IPVPN connectivity of the customers' 
>    CEs via the VSP-owned ASes is done via VSP-owned access facilities. 
>    This type of VPN network outsourcing is known as an 'unbundled' or 
>    'wires-only' service. SLSs are negotiated between the VSP and their 
>    customers that allow the customer managed CE's to intercommunicate. 
> 
>    In an MDE, when an 'unbundled' service is procured from a VSP by an 
>    Agent, the Agent may want to use the 'unbundled' service to extend 
>    the geographic reach of their VPN footprint by connecting this 
>    service to one or more VPLs. Again, for SLS demarcation purposes, the 
>    VSP may express a preference to collocate a network element at each 
>    VPL.  
> 
>    SLS demarcation points for the selling VSP may then include VPL 
>    collocated network elements that are shared across one or more Agents 
>    and/or VPNs, access facilities linking the Agent-owned CEs, and 
>    common [RFC-2547bis]-based VPN services that span the VSP-owned 
>    AS(es). The Agent must then offer SLSs to their customer that 
>    encompass the VSPs 'unbundled' service and associated SLS(s), as well 
>    as their managed CE offering.  
> 
>    There is a requirement, therefore, for consistent 'unbundled' service 
>    SLS demarcation points across an MDE.  
> 
> 8.5. Remote CE Management Requirement 
> 
>    For contractual and/or technical reasons, Agents or customers have a 
>    requirement to manage Customer Edge (CE) network elements that are 
>    interconnected as part of a [RFC-2547bis]-based VPN service. In an 
>    MDE, the ASes supporting these VPNs may or may not be operated by the 
>    Agent. The Agent will in addition to managing VPN services on behalf 
>    of their customers, usually operate a management network to which 
>    their end customers have restricted or no access. The management 
>    network is used to provide as a minimum IP-based connectivity between 
>    CEs and the Agent's operations staff, typically located in one or 
>    more operations centers. 
> 
>    In order for an Agent to directly manage CEs connected to ASes that 
>    they do not operate, the Agent will procure 'unbundled' VPN services 
>    from one or more VSP partners. In addition to SLSs that are 
>    negotiated between the Agent and the selling VSP for CE-to-CE 
>    communication, the Agent requires SLSs that encompass the connection 
>    of each CE to the Agent's management network. 
>  
>  
>                        Expires July 26, 2006                [Page 25] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    There is a requirement, therefore, for an Agent to remotely manage CE 
>    network elements that are directly interconnected through one or more 
>    ASes that are operated by the Agent's VSP partners. The VSP partner 
>    should therefore be capable of supporting one or more common 
>    management network connectivity methods selected by the Agent.  
> 
> 8.6. End-to-End Combined Services Requirement 
> 
>    8.6.1. Combined VPN and Internet Access Requirement 
> 
>    It is common for VSPs to offer combined Internet access and VPN 
>    services via a shared networking infrastructure, e.g. based upon 
>    [RFC-2547bis]. In an MDE, when an Agent offers this service, it is 
>    sometimes advantageous for the Agent if their VSP partners could 
>    support the local 'breakout' of traffic destined for the Internet 
>    within the VSPs own ASes. An alternative to this is for all customers 
>    Internet and VPN traffic to be transported by the Agent's VSP 
>    partners across VPLs to Internet 'breakout' location(s) in other 
>    ASes. These traffic paths are inevitably suboptimal, raising 
>    performance concerns with the Agent's customers. In addition, the 
>    service is potentially expensive to deliver for the Agent, as there 
>    is little or no differentiation between traffic paths carrying 
>    mission-critical VPN traffic and Internet destined best effort 
>    traffic as all traffic will be forwarded by the VSP partner across 
>    one or more VPLs. 
> 
>    There is a requirement, therefore, in an MDE for VSPs to provide 
>    consistent Internet 'breakout' services that are compatible with an 
>    Agents combined Internet access and VPN services. These compatibility 
>    requirements include (but are not limited to): 
> 
>    - Security, Authentication, Intrusion Detection, Virus protection 
>       services etc. 
> 
>    - Consistent QoS policies across VSPs for best effort or better 
>       than best effort Internet-destined traffic. 
> 
>    8.6.2. Combined IP and non-IP Application Transport Requirement 
> 
>    Some VSPs offer managed services that include the transporting of 
>    non-IP application traffic across a shared networking infrastructure 
>    based on [RFC-2547bis]. These 'legacy' applications use networking 
>    protocols (for example X.25, SNA and IPX) that typically do not 
>    support an IP network layer header and therefore cannot natively be 
>    transported across VSP operated ASes. The non-IP packets must 
>    therefore be 'tunneled' across VSP ASes by adding IP and MPLS headers 
>    to the packets. Either end of a 'legacy' application transport tunnel 
>  
>  
>                        Expires July 26, 2006                [Page 26] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    must support configurations that are based on non-IP application 
>    specific configuration parameters for mapping non-IP network layer 
>    application sources to destination tunnel network element IP 
>    addresses. In an MDE, the non-IP transport tunnel could span one or 
>    more VSP-owned ASes. Network elements that originate and terminate 
>    packets that are forwarded across these non-IP tunnels could 
>    therefore be operated by different VSPs. 
> 
>    There is a requirement, therefore, in an MDE for consistent non-IP 
>    application transport tunnels to be supported by participating VSPs 
>    in an MDE. Tunnel transport consistency per non-IP protocol must take 
>    into account amongst others, agreements on MTU sizing, SLS 
>    conformance, vendor proprietary and standardized encapsulation 
>    techniques etc.   
> 
> 9. Conclusions 
> 
> 10. Acknowledgements 
> 
>    This document is the combined effort of the co-editors and the 
>    following contributing authors: Dimitri Papadimitriou, James 
>    Humphris, Colin Simpson, Matthew Ford, William Copeland and David 
>    Page. 
> 
> 11. References  
> 
> 11.1. Normative References 
> 
>     [RFC-1771] Rekhter, Y., Li, T., et al., "A Border Gateway Protocol 4 
>                (BGP-4)", RFC 1771, March 1995. 
> 
>     [RFC-1930] Hawkinson, J., Bates, T., "Guidelines for creation, 
>                selection, and registration of an Autonomous System 
>                (AS)", RFC 1930, March 1996. 
> 
>     [RFC-2330] Paxson, V., et al., "Framework for IP Performance 
>                Metrics", RFC 2330, May 1998. 
> 
>     [RFC-2475] Blake, S., et al., "An Architecture for Differentiated 
>                Services", RFC 2475, December 1998. 
> 
>     [RFC-2676] Apostolopoulos, G., et al., "QoS Routing Mechanisms and 
>                OSPF Extensions", RFC 2676, August 1999. 
> 
>      
> 
> 
>  
>  
>                        Expires July 26, 2006                [Page 27] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>     [RFC-2865] Rigney, C., et al., "Remote Authentication Dial-In User 
>                Service (RADIUS)", RFC 2865, June 2000. 
> 
>     [RFC-3644] Snir, Y., et al., "Policy Quality of Service (QoS) 
>                Information Model", RFC 3644, November 2003. 
> 
>     [RFC-4026] Andersson, L., Madsen, T., "Provider-Provisioned Virtual 
>                Private Network (VPN) Terminology", RFC 4026, March 2005. 
> 
>     [RFC-4031] Carugi, M., et al., "Service Requirements for Layer 3 
>                Provider Provisioned Virtual Private Networks (PPVPNs)", 
>                RFC 4031, April 2005. 
> 
>     [RFC-4111] Fang, L., et al., "Security Framework for Provider-
>                Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, 
>                July 2005. 
> 
>     [RFC-4301] Kent, S., Seo, K., "Security Architecture for the 
>                Internet Protocol", RFC 4301, December 2005. 
> 
>     
> 
> 11.2. Informative References 
> 
>    [RFC-2547bis] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", draft-ietf-
>                l3vpn-rfc2547bis-03.txt, Work in Progress, October 2004. 
> 
>     [VPN-VERIFICATION] Behringer, M., et al., "Layer-3 VPN Import/Export 
>                Verification", draft- -ietf-l3vpn-vpn-verification-
>                00.txt, Work in Progress, March 2005. 
> 
>     
> 
>     
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
>  
>                        Expires July 26, 2006                [Page 28] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
> Editor's Addresses  
> 
>    Jim Guichard 
>    Cisco Systems, Inc 
>    300 Beaver Brook Rd 
>    Boxborough 
>    MA   
>    Email: jguichar@cisco.com 
>     
>    Martin Halstead 
>    Nexagent Ltd 
>    Thames Tower 
>    37-45 Station Road 
>    Reading 
>    Berkshire 
>    UK 
>    RG1 1LX 
>    Email: mhalstead@nexagent.com 
>     
>    Christian Jacquenet 
>    France Telecom 
>    4, rue du Clos Courtel 
>    BP 91226 
>    35512 Cesson-Sévigné Cedex 
>    France 
>    Email: christian.jacquenet@francetelecom.com    
>     
> 
> 12. Intellectual Property Statement 
> 
>    The IETF takes no position regarding the validity or scope of any 
>    Intellectual Property Rights or other rights that might be claimed to 
>    pertain to the implementation or use of the technology described in 
>    this document or the extent to which any license under such rights 
>    might or might not be available; nor does it represent that it has 
>    made any independent effort to identify any such rights.  Information 
>    on the procedures with respect to rights in RFC documents can be 
>    found in BCP 78 and BCP 79. 
> 
>    Copies of IPR disclosures made to the IETF Secretariat and any 
>    assurances of licenses to be made available, or the result of an 
>    attempt made to obtain a general license or permission for the use of 
>    such proprietary rights by implementers or users of this 
>    specification can be obtained from the IETF on-line IPR repository at 
>    http://www.ietf.org/ipr. 
> 
> 
>  
>  
>                        Expires July 26, 2006                [Page 29] 
> 
> 
> Internet-Draft draft-Halstead-Guichard-MAVS-Requirements-01 January 2006 
>     
> 
>    The IETF invites any interested party to bring to its attention any 
>    copyrights, patents or patent applications, or other proprietary 
>    rights that may cover technology that may be required to implement 
>    this standard.  Please address the information to the IETF at 
>    ietf-ipr@ietf.org. 
> 
> Disclaimer of Validity 
> 
>    This document and the information contained herein are provided on an 
>    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
>    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
>    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
>    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
>    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
>    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
> 
> Copyright Statement 
> 
>    Copyright (C) The Internet Society (2006). 
> 
>    This document is subject to the rights, licenses and restrictions 
>    contained in BCP 78, and except as set forth therein, the authors 
>    retain all their rights. 
> 
>      
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
>  
>                        Expires July 26, 2006                [Page 30] 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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