Internet DRAFT - draft-marques-sndp-l3vpn-schema
draft-marques-sndp-l3vpn-schema
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]
