Network Working Group                                         P. Marques
Internet-Draft                                          Contrail Systems
Intended status: Standards Track                               June 2012
Expires: December 01, 2012


                  IF-MAP schema for BGP/MPLS IP VPNs.
                     draft-marques-l3vpn-schema-00

Abstract

   This document defines the metadata schema used to define the route
   exchange policies of an IP VPN network.  Information elements
   conforming to this schema can be distributed using the IF-MAP [if-
   map] specification.  The schema is applicable both to the standard
   BGP IP VPN [RFC4364] deployments within service provider environments
   as well as end-system [I-D.marques-l3vpn-end-system] based
   deployments.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 01, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (http://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents


Marques                Expires December 01, 2012                [Page 1]

Internet-Draft                l3vpn schema                     June 2012

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Data Model . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Identifiers  . . . . . . . . . . . . . . . . . . . . . . .  5
       2.1.1.  customer-attachment  . . . . . . . . . . . . . . . . .  5
       2.1.2.  connectivity-group . . . . . . . . . . . . . . . . . .  5
       2.1.3.  route-target . . . . . . . . . . . . . . . . . . . . .  5
       2.1.4.  provider-attachment  . . . . . . . . . . . . . . . . .  5
     2.2.  Metadata . . . . . . . . . . . . . . . . . . . . . . . . .  5
       2.2.1.  attachment-info  . . . . . . . . . . . . . . . . . . .  5
       2.2.2.  attachment-state . . . . . . . . . . . . . . . . . . .  6
       2.2.3.  binding  . . . . . . . . . . . . . . . . . . . . . . .  6
       2.2.4.  group-target . . . . . . . . . . . . . . . . . . . . .  6
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
   4.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   Appendix A. Schema . . . . . . . . . . . . . . . . . . . . . . . .  7
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.  Introduction

   The schema defined in this document allows a management console or
   orchestration system to define IP VPNs and their access policies and
   distribute that information to all Provider Edge (PE) devices.  It
   also allows the PE devices to publish the information of which
   customer attachment points are locally associated with each VPN
   routing-table, providing a mechanism by which a management entity,
   potentially different from the one establishing access policies, can
   verify the operational state of the network.

   In order to define an IP VPN, a management system, must select a
   network name and associate it with a route-target value.  That
   operation is achieved by sending the following XML document to an IF-
   MAP server.

   <?xml version="1.0"?>
   <ifmap:publish session-id="1"
       xmlns:ifmap="http://ietf.org/I-D.marques-l3vpn-schema">
     <update>
       <connectivity-group name="SimpleVPN">
       <metadata>
         <group-target>
           <route-target value='1:0.0.0.1'/>
         </group-target>
       </metadata>
     </update>
   </ifmap:publish>

   A symetric VPN is implemented as a single "connectivity-group".  This
   is the scenario in which all the members of the VPN have the same
   connectivity.  However there are scenarios where the connectivity is
   assymetric.  One such example is a "hub and spoke" topology in which
   all the traffic from spoke sites must first traverse through the
   "hub" site.  In this situation a single logic VPN corresponds to two
   "connectivity-groups".




Marques                Expires December 01, 2012                [Page 2]

Internet-Draft                l3vpn schema                     June 2012


   PE devices that terminate circuits attached to a connectivity-group
   instatiate a corresponding VRF, where the VRF parameters are derived
   from the metadata associated to the given connectivity-group.

   In the example definition above, since no further metadata was
   defined, the import and export route-target list for the VRFs is the
   same and constitutes of the route-target specified in the 'group-
   target' metadata.

   Network connectivity information is published in the MAP server and
   available to all PE devices which may either subscribe to
   notification or poll the information on-demand.

   The schema defined in this document allows for connectivity-groups to
   be interconnected via a metadata element called 'connection'. When
   that element is present the local PE VRFs should be configured such
   that its vrf-import target lists include the 'group-target's
   associated with each of the groups to which the specified network is
   connected.

   <?xml version="1.0"?>
   <ifmap:publish session-id="1"
       xmlns:ifmap="http://ietf.org/I-D.marques-l3vpn-schema">
     <update>
       <connectivity-group name="SimpleVPN">
       <connectivity-group name="Storage frontend">
       <metadata>
         <connection/>
       </metadata>
     </update>
   </ifmap:publish>

   The XML document above esblishes a connection between two
   connectivity groups and would result in the respective VRFs importing
   both the route-target associated with "SimpleVPN" and "Storage
   frontend".

   In order to associate a given customer attachment-circuit to a
   virtual network a PE device may either consult the MAP server or rely
   on a information that is provided by the customer device via a PE-CE
   communication protocol.  In the second case it is important for the
   PE to be able to publish that mapping to the MAP server in order to
   provide the operational state of the network.

   Regardless of whether the association is centrally determined by a
   provisioning system or by the PE it can be added to the MAP server
   via the following message:







Marques                Expires December 01, 2012                [Page 3]

Internet-Draft                l3vpn schema                     June 2012


   <?xml version="1.0"?>
   <ifmap:publish session-id="1"
       xmlns:ifmap="http://ietf.org/I-D.marques-l3vpn-schema">
     <update>
       <customer-attachment uuid="urn:dev:mac:010203ffff040506"/>
       <connectivity-group name="SimpleVPN"/>
       <metadata>
         <binding/>
       </metadata>
     </update>
   </ifmap:publish>

   Additionally the information regarding the specific PE attachment
   circuit that the interface is bound to as well as its operational
   state can be published via an XML document such as:

   <?xml version="1.0"?>
   <ifmap:publish session-id="1"
       xmlns:ifmap="http://ietf.org/I-D.marques-l3vpn-schema">
     <update>
       <customer-attachment uuid="urn:dev:mac:010203ffff040506"/>
       <provider-attachment id='192.0.2.1' interface='ge-0/0/0.0'/>
       <metadata>
         <attachment-info/>
         <attachment-state>
           <state>up</state>
         </attachment-state>
       </metadata>
     </update>
   </ifmap:publish>

   By storing this information on a MAP server the provisioning and
   operational state of all IP VPNs in a domain can be known.  Note that
   the routing information corresponding to which IP prefixes are
   currently reachable and the selection of the preferred path for a
   given IP packet are still done using BGP IP VPN.

   Routing information is both very dynamic as well as potentially
   different at each specific VRF table, since the network location
   influences path selection.  Information stored in the MAP server is,
   typically, more global in nature.

2.  Data Model

   The figure bellow contains the data-model used to represent the
   provisioning information necessary to attach a given customer circuit
   to an IP VPN.  In it identifiers are represented by boxes while
   metadata is represented by elements in square brackets.






Marques                Expires December 01, 2012                [Page 4]

Internet-Draft                l3vpn schema                     June 2012


   +-------------+                  +---------------+
   |  customer   |                  | connectivity  |
   |  attachment |-- [ binding ] -- |    group      | == [ connection ]
   +-------------+                  +---------------+
          |                                 |
   [attachment-info]                 [ group-target ]
          |                                 |
   +-------------+                   +--------------+
   |   provider  |                   | route-target |
   |  attachment |                   +--------------+
   +-------------+

2.1.  Identifiers

   The following Identifiers are defined for this schema:

2.1.1.  customer-attachment

   The "customer attachment" identifier represents a circuit connecting
   to a customer edge device in the standard BGP IP VPN application.
   The "customer attachment" identifies the Customer Edge (CE) circuit.

   For instance, when the network in question is using an end-system
   [I-D.marques-l3vpn-end-system] based implementation, the "customer
   attachment" represents the virtual interface associated with a
   virtual machine.

2.1.2.  connectivity-group

   The "connectivity-group" element represents a configuration template
   used to provision a VRF table on a PE (or a routing table on a BGP/
   XMPP Signaling Gateway).

2.1.3.  route-target

   In BGP IP VPNs, route targets are associated with VPN routing
   information and used to express routing table import and export
   policies.

2.1.4.  provider-attachment

   A "provider-attachment" element identifies an interface in a PE
   device.

2.2.  Metadata

   In the IF-MAP specification [if-map] metadata determines the state of
   the MAP database.  Identifiers are immutable constants.  Metadata
   update and delete requests represent state and lead to updates being
   sent to subscribers.

2.2.1.  attachment-info


Marques                Expires December 01, 2012                [Page 5]

Internet-Draft                l3vpn schema                     June 2012


   The attachment-state metadata element is used to associate a
   "customer-attachment" with a PE interface.

2.2.2.  attachment-state

   The attachment-state metadata element conveys operational state for
   the interface between the customer and provider end-points.

2.2.3.  binding

   The binding metadata element associates a customer attachment with a
   connectivity-group.  It contains no operational state and maybe
   inserted by either a PE device or a provisioning system.

2.2.4.  group-target

   The group-target metadata associates a connectivity-group with its
   route-target.

3.  Security Considerations

   When using this approach, the MAP database, rather than the
   individual configurations on PE devices, becomes the "source of
   truth" about the VPN membership.  It is important to restrict the
   write access to the MAP database to systems that should be allowed to
   modified it.

   A MAP server implementation SHOULD support access controls on a per
   metadata element basis such that it is possible to restrict write
   access to a set of metadata elements to a specific list of
   certificates.

4.  References

   [I-D.marques-l3vpn-end-system]
              Marques, P., Fang, L., Pan, P., Shukla, A., Napierala, M.
              and N. Bitar, "BGP-signaled end-system IP/VPNs.",
              Internet-Draft draft-marques-l3vpn-end-system-05, March
              2012.

   [I-D.arkko-core-dev-urn]
              Arkko, J., Jennings, C. and Z. Shelby, "Uniform Resource
              Names for Device Identifiers", Internet-Draft draft-arkko-
              core-dev-urn-01, October 2011.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, February 2006.

   [RFC5935]  Ellison, M. and B. Natale, "Expressing SNMP SMI Datatypes
              in XML Schema Definition Language", RFC 5935, August 2010.

   [if-map]   "IF-MAP Binding for SOAP Specification Version 2.0", July
              2010.

Marques                Expires December 01, 2012                [Page 6]

Internet-Draft                l3vpn schema                     June 2012


Appendix A.  Schema





















































Marques                Expires December 01, 2012                [Page 7]

Internet-Draft                l3vpn schema                     June 2012


   <?xml version="1.0" encoding="UTF-8"?>
   <schema targetNamespace="http://www.ietf.org/I.D-l3vpn-schema" elementFormDefault="qualified"
       xmlns="http://www.w3.org/2001/XMLSchema" xmlns:vpn="http://www.ietf.org/I.D-l3vpn-schema"
       xmlns:ifmap="http://www.trustedcomputinggroup.org/2010/IFMAP/2" xsi:schemaLocation="http://www.trustedcomputinggroup.org/2010/IFMAP/2 /Users/roque/src/workspace/config/ifmap-base-2.0v17.xsd ">
   
       <!-- Identifiers -->
   
       <!-- Group of customer attachment points with the same connectivity policies -->
       <complexType name="ConnectivityGroupType">
           <element name="name" type="string"/>
       </complexType>
   
       <complexType name="RouteTargetType">
           <!-- Route Target extended community -->
           <element name="value" type="string"/>
       </complexType>
   
       <!-- VPN attachment interface on Customer Edge -->
       <complexType name="CustomerAttachementType">
           <!-- UUID -->
           <element name="uuid" type="string"/>
       </complexType>
   
       <!-- VPN attachment interface on Provider Edge -->
       <complexType name="ProviderAttachmentType">
           <!-- UUID -->
           <element name="uuid" type="string"/>
       </complexType>
   
       <!-- Types -->
       <complexType name="ProtocolBgpType">
           <sequence>
               <element name="autonomous-system" type="integer"/> <!-- customer autonomous-system -->
           </sequence>
       </complexType>
   
       <complexType name="ProtocolOspfType">
           <sequence>
               <element name="area" type="integer"/>
           </sequence>
       </complexType>
   
       <complexType name="ProtocolStaticType">
           <sequence>
               <element name="route" type="IPPrefixType" maxOccurs="unbounded"/>
           </sequence>
       </complexType>
   
       <!-- Metadata -->
       <!-- link metadata that associates two connectivity-group identifiers in order to establish inter-VPN connectivity -->
       <element name="connection">
           <complexType>
               <attributeGroup ref="ifmap:singleValueMetadataAttributes"></attributeGroup>

Marques                Expires December 01, 2012                [Page 8]

Internet-Draft                l3vpn schema                     June 2012

           </complexType>
       </element>
   
       <!-- link metadata that associates a connectivity-group identifier with a route-target identifier -->
       <element name="group-target">
           <complexType>
               <attributeGroup ref="ifmap:singleValueMetadataAttributes"></attributeGroup>
           </complexType>
       </element>
   
       <!-- Default PE-CE protocol used by attachment circuits to this routing table -->
       <element name="group-ce-protocol">
           <complexType>
               <choice>
                   <element name="bgp" type="ProtocolBgpType"/>
                   <element name="ospf" type="ProtocolOspfType"/>
               </choice>
               <attributeGroup ref="ifmap:singleValueMetadataAttributes"></attributeGroup>
           </complexType>
       </element>
   
       <!-- link metadata that associates a customer attachment with a connectivity-group
            parameters common to all customer attachments can be derived via this association
       -->
       <element name="binding">
           <complexType>
               <attributeGroup ref="ifmap:singleValueMetadataAttributes"></attributeGroup>
           </complexType>
       </element>
   
       <!-- link metadata that associates an attachment with an IP address -->
       <element name="attachment-address">
           <complexType>
               <attributeGroup ref="ifmap:singleValueMetadataAttributes"></attributeGroup>
           </complexType>
       </element>
   
       <!-- link metadata that associates a customer to a provider attachment
           may include parameters specific to a particular customer attachment
       -->
       <element name="attachment-info">
           <complexType>
               <sequence>
                   <choice>
                       <element name="static" type="ProtocolStaticType"/>
                       <element name="bgp" type="ProtocolBgpType"/>
                       <element name="ospf" type="ProtocolOspfType"/>
                   </choice>
               </sequence>
               <attributeGroup ref="ifmap:singleValueMetadataAttributes"></attributeGroup>
           </complexType>
       </element>
   
       <!-- link metadata that provides state information on the customer circuit -->

Marques                Expires December 01, 2012                [Page 9]

Internet-Draft                l3vpn schema                     June 2012

       <element name="attachment-state">
           <complexType>
               <sequence>
                   <element name="state">
                       <simpleType>
                           <restriction base="string">
                               <enumeration value="up"/>
                               <enumeration value="down"/>
                               <enumeration value="adminDown"/>
                           </restriction>
                       </simpleType>
                   </element>
               </sequence>
               <attributeGroup ref="ifmap:singleValueMetadataAttributes"></attributeGroup>
           </complexType>
       </element>
   </schema>

Author's Address

   Pedro Marques
   Contrail Systems
   440 N. Wolfe Rd.
   Sunnyvale, CA 94085
   
   Email: roque@contrailsystems.com




























Marques                Expires December 01, 2012               [Page 10]