Network Working Group                                         P. Marques
Internet-Draft                                             December 2011
Intended status: Standards Track
Expires: June 13, 2012

                       IF-MAP schema for IP VPNs.
                   draft-marques-sndp-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 June 13, 2012.

Copyright Notice

   Copyright (c) 2011 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

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2

Marques                           std                           [Page 1]

Internet-Draft                l3vpn schema                 December 2011

   2.  Data Model . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Identifiers  . . . . . . . . . . . . . . . . . . . . . . .  4
       2.1.1.  customer-attachement . . . . . . . . . . . . . . . . .  4
       2.1.2.  routing-table  . . . . . . . . . . . . . . . . . . . .  4
       2.1.3.  route-target . . . . . . . . . . . . . . . . . . . . .  4
       2.1.4.  provider-edge  . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Metadata . . . . . . . . . . . . . . . . . . . . . . . . .  5
       2.2.1.  attachement-state  . . . . . . . . . . . . . . . . . .  5
       2.2.2.  binding  . . . . . . . . . . . . . . . . . . . . . . .  5
       2.2.3.  Import and export targets  . . . . . . . . . . . . . .  6
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
   4.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  7

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 attachement 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 VPN
   identifier 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>
       <routing-table name="SimpleVPN">
       <metadata>
         <import-target>
           <route-target>1:0.0.0.1</route-target>
         </import-target>
         <export-target>
           <route-target>1:0.0.0.1</route-target>
         </export-target>
       </metadata>
     </update>
   </ifmap:publish>

   In the VPN definition above, the import and export route-target list
   is the same, creating a closed group VPN in which any customer
   attachement can only communicate with other members of the same VPN.
   This definition is published in the MAP server and available to all
   PE devices which may either subscribe to notification or poll the
   information on-demand.





Marques                           std                           [Page 2]

Internet-Draft                l3vpn schema                 December 2011

   The XML element "routing-table" above refers not to a particular
   instantiation of a VRF table on a PE device but a configuration
   template that is used to instantiate the specific routing tables.

   The schema allows for multiple import and export targets to be
   configured on a particular "routing-table" in order to allow for
   scenarios where there is direct traffic exchange between different
   VPNs.  For example, a common service such as storage may have a
   "storage-frontend" VPN which imports the route-targets of all its
   customer VPNs.  The customer VPNs would also import the route-target
   associated with the "storage-frontend" service.

   In order to associate a given "attachement circuit" to a routing-
   table 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:

   <?xml version="1.0"?>
   <ifmap:publish session-id="1"
       xmlns:ifmap="http://ietf.org/I-D.marques-l3vpn-schema">
     <update>
       <customer-attachement id="vm:00:00:00:01:02:03"/>
       <metadata>
         <binding>
            <table-name>SimpleVPN</table-name>
         </binding>
         <attachement-state>
        <provider-edge>192.168.0.1</provider-edge>
        <state>Up</state>
         </attachement-state>
       </metadata>
     </update>
   </ifmap:publish>

   The metadata information in this update message contains both the
   information of which routing table is the circuit bound to as well as
   its operational state.

   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

Marques                           std                           [Page 3]

Internet-Draft                l3vpn schema                 December 2011


   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.

   +-------------+
   |  customer   |                  +---------------+
   | attachement |-- [ binding ] -- | routing-table |
   +-------------+                  +---------------+
          |                               /    \
   [attachement-state]     [ import-target ]  [ export-target ]
          |                              |      |
   +---------------+                +--------------+
   | provider-edge |                | route-target |
   +---------------+                +--------------+

2.1.  Identifiers

   The following Identifiers are defined for this schema:

2.1.1.  customer-attachement

   The "customer attachement" identifier represents a circuit connecting
   to a customer edge device in the standard BGP IP VPN application.
   When the network in question is using an end-system [I-D.marques-
   l3vpn-end-system] based implementation, the "customer attachement"
   represents the XMPP client session between the end-system and
   signaling gateway.

   <xsd:complexType name="CustomerAttachementType">
     <xsd:attribute name="id" type="xsd:string" use="required">
   </xsd:complexType>

2.1.2.  routing-table

   The "routing table" element represents a configuration template used
   to provision a VRF table on a PE or a routing table on a BGP/XMPP
   signaling gateway.

   <xsd:complexType name="RoutingTableType">
     <xsd:attribute name="name" type="xsd:string" use="required">
   </xsd:complexType>

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.

   <xsd:complexType name="RouteTargetType">
     <xsd:attribute name="value" type="xsd:string" use="required">
   </xsd:complexType>

2.1.4.  provider-edge


Marques                           std                           [Page 4]

Internet-Draft                l3vpn schema                 December 2011


   A "provider-edge" element identifies a specific PE device.

   <xsd:complexType name="ProviderEdgeType">
     <xsd:attribute name="id" type="smi:IpAddress" use="required">
   </xsd:complexType>

   In the definition above the "smi" namespace is refers to the SNMP SMI
   XML schema [RFC5935].

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.  attachement-state

   The attachement-state metadata element is used to associate a
   "customer-attachement" with a PE device.  It can also convey its
   operational state.

   The contained "local-routes" element, when present, contains the
   number of routes that have been adverised by a given customer
   attachement to the local PE device.

   <xsd:element name="attachement-state">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element name="provider-edge" type="smi:IpAddress"
             minOccurs="1" maxOccurs="1">
         <xsd:element name="state" minOccurs="0" maxOccurs="1">
           <xsd:simpleType>
         <xsd:restriction base="xsd:string">
           <xsd:enumeration value="Up"/>
           <xsd:enumeration value="Down"/>
           <xsd:enumeration value="AdminDown"/>
         </xsd:restriction>
       </xsd:simpleType>
         </xsd:element>
         <xsd:element name="local-routes" type="xsd:integer" minOccurs="0"
             maxOccurs="1"/>
       </xsd:sequence>
       <xsd:attributeGroup ref="ifmap:singleValueMetadataAttributes"/>
     </xsd:complexType>
   </xsd:element>

2.2.2.  binding

   The binding metadata element associates a customer attachement with a
   specific VPN. It contains no operational state and maybe inserted by
   either a PE device or a provisioning system.




Marques                           std                           [Page 5]

Internet-Draft                l3vpn schema                 December 2011


   <xsd:element name="binding">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element name="table-name" type="xsd:string" minOccurs="1"
             maxOccurs="1">
       </xsd:sequence>
       <xsd:attributeGroup ref="ifmap:singleValueMetadataAttributes"/>
     </xsd:complexType>
   </xsd:element>

2.2.3.  Import and export targets

   The import and export target elements specific the list of route-
   targets that specify a routing-table import and export policies,
   respectively.  Import targets select routes which have been
   associated with any of these targets to be added to the specific
   routing table.  Export targets instruct the routing table to tag a
   route with that specific list of targets when advertising a route to
   other PE devices.  PE devices must also import/export routes between
   local VRFs which contain intersecting route target lists.

   <xsd:element name="import-target">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element name="route-target" type="xsd:string" minOccurs="1"
             maxOccurs="unbounded">
       </xsd:sequence>
       <xsd:attributeGroup ref="ifmap:multiValueMetadataAttributes"/>
     </xsd:complexType>
   </xsd:element>

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 and A Shukla, "End-system
              support for BGP-signaled IP/VPNs.", Internet-Draft draft-
              marques-l3vpn-end-system-02, October 2011.

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



Marques                           std                           [Page 6]

Internet-Draft                l3vpn schema                 December 2011


   [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.

Author's Address

   Pedro Marques
   
   Email: pedro.r.marques@gmail.com













































Marques                           std                           [Page 7]