Subject: Re: [Mavs] MAVS Requirements Draft posted

From: dimitri papadimitriou <[email-masked]>
Date: Tue, 14 Feb 2006 02:12:17 +0100

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: [email-masked] 
>     
>    Martin Halstead 
>    Nexagent Ltd 
>    Thames Tower 
>    37-45 Station Road 
>    Reading 
>    Berkshire 
>    UK 
>    RG1 1LX 
>    Email: [email-masked] 
>     
>    Christian Jacquenet 
>    France Telecom 
>    4, rue du Clos Courtel 
>    BP 91226 
>    35512 Cesson-Sévigné Cedex 
>    France 
>    Email: [email-masked]    
>     
> 
> 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 
>    [email-masked]. 
> 
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mavs

_______________________________________________
Mavs mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mavs

---

From: "JACQUENET Christian RD-TCH-REN" <[email-masked]>
Date: Tue, 14 Feb 2006 17:17:26 +0100

Dimitri,

Many thanks for your comments...and for re-activating this list :-) More below. 

-----Message d'origine-----
De : dimitri papadimitriou [mailto:[email-masked]] 
Envoyé : mardi 14 février 2006 02:12
À : JACQUENET Christian RD-TCH-REN
Cc : [email-masked]; Jim Guichard (jguichar)
Objet : Re: [Mavs] MAVS Requirements Draft posted

hi christian,

CJ: thanks for your encouragement - I'm sure all the editors will appreciate :-)

CJ: I'm not sure I fully understand this comment. In the QoS section, we tried to insist on the current issues and requirements we'd like to deal with as far as the provisioning of inter-domain VPN services with the required level of quality (as expressed and potentially negotiated with the customer) is concerned. What we tried to suggest is, e.g., to encourage the ability of exhanging of QoS information between domains assuming common understanding of such information, hence hopefully yielding a *consistent* metrology to qualify how efficiently a VPN-specific QoS policy is enforced, based upon commonly understood QoS indicators, for example. So, the "layoout" you mention in your comment could consist in encouraging the standardization of a SLS template to (reliably) exchange (and negotiate) QoS information not only between a customer and a specific VSP, but also between VSPs.

CJ: agreed.

CJ: cool, let me suggest you send the editors the corresponding text of this presumably new section of the draft.

Cheers,

Christian.