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