BGP-Signaled End-System IP/VPNs
draft-ietf-l3vpn-end-system-06

Abstract

This document describes a solution in which the control plane protocol specified in BGP/MPLS IP VPNs is used and extended via the XMPP protocol to provide a Virtual Network service to end-systems (hosts). These end-systems may be used to provide network services or may host end-user applications.

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 18, 2017.

Copyright Notice

Copyright (c) 2016 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
• 1.1. Terminology
• 2. Requirements
• 3. Applicability of BGP IP VPNs
• 4. Virtual Network End-Points
• 5. VPN Forwarder
• 6. XMPP signaling protocol
• 7. End-System Route Server behavior
• 8. Operational Model
• 9. IANA Considerations
• 10. Security Considerations
• 11. XML schema
• 12. Acknowledgements
• 13. References
• 13.1. Normative References
• 13.2. Informational References
• Authors' Addresses

1. Introduction

This document describes the requirements for a network virtualization solution that provides an IP service to end-system virtual interfaces. It then discusses how the control plane for BGP IP VPNs [RFC4364] can be used and extended via the XMPP protocol to provide a solution that meets these requirements. Subsequent sections provide a detailed discussion of the control and forwarding plane components.

In BGP IP VPNs, Customer Edge (CE) interfaces connect to a Provider Edge (PE) device which provides both the control plane and VPN encapsulation functions required to implement a Virtual Network service. This document describes how the control plane and forwarding functionality of a PE device can be decoupled in order to enable the forwarding functionality to be implemented in multiple devices. For instance, the forwarding function can be implemented directly on the operating system of application servers or network appliances.

1.1. Terminology

This document makes use of the following terms:

End-System:

A compute node whose primary function is to run applications. It is assumed that end-systems support multiple application instances (e.g., virtual machines), each with its independent network configuration.

End-System Route Server:

A software application that implements the control plane functionality of a BGP IP VPN PE device and an XMPP server that interacts with VPN Forwarders.

Virtual Interface:

An interface in an end-system that is used by a virtual machine or by applications. It performs the role of a CE interface in a BGP IP VPN network. This is similar to the concept of Virtual Access Point (VAP) in RFC 7365 [RFC7365].

VPN Forwarder:

The forwarding component of a BGP IP VPN PE device. This functionality may be co-located with the virtual interface or implemented by an external device.

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

2. Requirements

Network virtualization is used in both service provider as well as enterprise networks to support multi-tenancy and network-based access control. It may also be used to facilitate application instance mobility.

Multi-tenancy allows a physical network to provide services to multiple "customers" or "tenants", whether these are external entities in the case of a Service Provider providing managed VPN services, or internal departments of an enterprise sharing an IT facility. Multi-tenancy requires isolation of traffic and routing information between tenants.

Within a tenant, it is often required to create multiple distinct virtual networks, in order to be able to provide network-based access control. In this service model, each virtual network behaves as a "Closed User Group" (CUG) of virtual interfaces that are allowed to exchange traffic freely, while traffic between virtual networks is subject to access controls. This scenario can be found in enterprise campus networks, branch offices and data centers.

It is often the case when network access control is used, that the traffic patterns are such that there is significantly more traffic crossing a CUG boundary than staying within such boundary. As an example, in campus networks it is common to segregate users into CUGs based on some classification such as the user's department. Campus networks often see traffic patterns in which almost all the traffic flows northbound to the data center or internet boundaries. Similar traffic patterns can be found in multi-tier applications in IT data centers.

Virtual interfaces are often configured to expect the concept of IP subnet to match its closed user group. A network virtualization solution should be able to provide this concept of IP subnet regardless of whether the underlying implementation uses a multi-access network or not.

Virtual interfaces should be able to directly access multiple closed user groups without needing to traverse a gateway. Network access policy should allow this access whether the source and destination CUGs for a particular traffic flow belong to the same tenant or different tenants. It is often the case that infrastructure services are provided to multiple tenants. One such example is voice-over-IP gateway services for branch offices.

Independently, but often associated with the previous two functions, IP mobility is another network function that can be implemented using network virtualization. By abstracting the externally visible network address from the underlying infrastructure address, mobility can be implemented without having to rely upon home agents or large L2 broadcast domains.

IP Mobility requires the ability to "move" a virtual interface without disrupting its TCP (or UDP) transport sessions. This requires a mechanism that can efficiently communicate the mappings between logical and physical addressing.

IP Mobility can be a result of devices physically moving (e.g., a WiFi enabled laptop) or workload being diverted between physical systems such as network appliances or application servers.

3. Applicability of BGP IP VPNs

BGP IP VPNs [RFC4364] is the industry de-facto standard for providing "closed user group" functionality in WAN environments. It is used by service providers in environments where several millions of routes are present. It supports both isolated VPNs as well as overlapping VPNs (often referred to as "extranets").

The BGP IP VPN control plane has been designed to be able to distribute the mapping between virtual address and location (next-hop) to the subset of network nodes for which this information is relevant, whenever that mapping changes. This provides an efficient mechanism to address IP mobility requirements as compared to methods that depend on a (cached) mapping request from the end-systems.

In its traditional usage in Service Provider networks, BGP IP VPN functionality is implemented in a Provider Edge (PE) device that combines both BGP signaling as well as VRF-based forwarding functions. In practice, most PE devices in current use are multi-component systems with the signaling and forwarding functionality actually implemented in different processors attached to an internal network.

This document assumes a similar separation of functionality in which software appliances, the End-System Route Servers, implement the control plane functionality of a PE device and a VPN Forwarder implements the forwarding function usually found in a PE device "line-card". The VPN Forwarder functionality may be co-located with the end-system (e.g., implemented in the hypervisor switch or host OS network drivers) or it may be external. For instance, residing in a data center switch or specialized appliance.

Operationally, BGP IP VPN technology has several important characteristics:

• It has a high-level of aggregation between customer interfaces and managed entities (Provider Edge devices).
• It defines VPNs as policies, allowing an interface to directly exchange traffic with multiple VPNs and allowing for the topology of the virtual network to be modified by modifying the policy configuration.
• It scales horizontally in terms of event propagation. By increasing the number of signaling devices implementing the PE control plane, it is possible to decrease the load on each signaling device for events that originate in a specific location and which must be propagated across the network.

The last point is particularly relevant to the convergence characteristics required for large scale deployments. BGP's hierarchical route distribution capabilities allow a deployment to divide the workload by increasing the number of End-System Route Servers.

As an example consider a topology in which 100 End-System Route Servers are deployed in a network each serving a subset of the VPN forwarding elements. The Route Servers inter-connect to two top-level BGP Route Reflectors [RFC4456].

If an event (i.e., a VPN route change) needs to be propagated from a specific end-system to 10,000 clients randomly distributed across the network, each of the End-System Route Servers must generate 100 updates to its respective downstream clients.

By modifying this topology such that another 100 End-System Route Servers are added, each Route Server is now responsible for generating 50 client updates. This example illustrates the linear scaling properties of BGP: doubling the number of Route Servers (i.e., the processing capacity) reduces by half the number of updates generated by each one (i.e. the load at each processing node is halved).

The same horizontal scaling techniques can be applied to the Route Reflector layer in the example above by dividing the VPN Route space according to some pre-defined criteria (for instance VPN route target) and using a pair of Route Reflectors per subset.

In the previous example we assumed a dense membership in which all Route Servers have local clients that are interested in a particular event. BGP also optimizes the route distribution for sparse events. The Route Target Constraint [RFC4684] extension, builds an optimal distribution tree for XMPP stanza and message propagation based on VPN membership. It ensures that only the PEs with local receivers for a particular event do receive it also decreasing the total load on the upstream BGP speaker.

In the WAN environment, BGP IP VPN control plane scaling is not primarily focused on route convergence times, but on the memory footprint of embedded devices. While memory footprint does not have a similar linear scaling behavior as load, memory technology available to software appliances is often at 10x the scale of what is commonly found in WAN environments, and so is not so much of a concern.

The functionality present in the BGP IP VPN control plane addresses the requirements specified in the previous section. Specifically, it supports multiple potentially overlapping "groups", regular or "hub and spoke" topologies and the scaling characteristics necessary.

The BGP IP VPN control plane supports not only the definition of "closed user-groups" (VPNs in its terminology) but also the propagation of inter-VPN traffic policies [RFC5575].

Note that the signaling protocol itself is rather agnostic of the encapsulation used on the wire as long as this encapsulation has the ability to carry a label of sufficient length to enumerate all the VPNs in an administrative domain (e.g. an MPLS label, which has 20 bits).

Several network environments use a network infrastructure that is only capable of providing an IP unicast service. In order to support them, implementations of this document should support the MPLS in GRE [RFC4023] encapsulation. Other encapsulations are possible, including UDP-based encapsulations RFC 7510 [RFC7510] and VXLAN [RFC7348].

4. Virtual Network End-Points

This document assumes that end-systems support one or more virtual network interfaces in addition to a physical interface that is associated with the underlying network infrastructure. A virtual network interfaces can be associated with a specific application via a OS-dependent mechanisms like a Virtual Machine (VM), or they can be used to provide network connectivity to all user applications in the same way that a "VPN tunnel" interface is used to provide access between an end-system (e.g., a laptop) and a remote corporate network.

Each virtual network interface is assigned an IP addresses from a subnet associated with a "closed user group" or VPN, while the physical interface of the machine is addressed in the network infrastructure topology.

A virtual network interface is connected to a VPN Forwarder. This VPN Forwarder MAY be co-located in the end-system or external. In cases where the VPN Forwarder is external to the end-system, they can either be directly connected or interconnected with a dedicated 802.1Q VLAN on a per virtual interface basis.

Both static and dynamic IP address allocation can be supported. The latter assumes that the VPN Forwarder implements DHCP relay or DHCP proxy functionality.

Traffic that ingresses or egresses through a virtual network interface is routed at the VPN Forwarder, which acts as the first-hop router (in the virtual topology). The IP configuration on the client side of this virtual network interface (e.g., in the guest OS) can follow one of two models:

• Point-to-point interface model
• Multipoint interface model

In a point-to-point interface model, the VPN client routing table (e.g., on the guest OS) contains the following routing entries: a host route to the local IP address, a host route to the first-hop router via the virtual interface and a default route to the first-hop router. This is the model typically used in "VPN tunnel" configurations or other access technologies such as cable deployments or DSL. When this model is used, the first-hop router IP address is either an address from the tenant's IP address space or a link-local address. This address SHOULD be the same on all first-hop routers across a specific deployment so that it does not change when a virtual interface moves between end systems.

In a multi-point interface model, the VPN client routing table (e.g., on the guest OS) contains the following routing entries: a host route to the local IP address, a subnet route to the local interface and optionally a default route to a specific router address within that subnet. In this model, the VPN client IP stack will issue address resolution requests for any IP addresses it considers to be directly attached to the subnet. The VPN Forwarder SHALL answer all address resolution requests via Proxy ARP [RFC1027].The same technique is applicable when Neighbor Discovery is used to resolve IPv6 addresses. Address resolution request SHOULD be answered using a virtual MAC address which SHOULD be the same across all VPN Forwarders in a specific deployment. This virtual MAC address SHALL default to the VRRP [RFC5798] virtual router MAC address for Virtual Router Identifier (VRID) 1.

When the virtual topology first-hop router resides on the same physical machine, the host OS is responsible for mapping the virtual interface with a VPN-specific routing table (without taking L2 addresses into consideration). In this case the MAC addresses known to the guest OS are not used on the wire.

When the virtual topology first-hop router resides in an external system (e.g., the first hop-switch) the virtual interface shall be identified by the physical interface of the end-system and a 802.1Q VLAN tag. The first-hop switch should use a virtual router MAC address to answer any address resolution queries.

Whenever external VPN forwarding is used, and resiliency is desired, multiple external VPN Forwarder may be employed in a redundant configuration. It is desirable to use VRRP as a mechanism to control the flow of traffic between the end-system and the external VPN Forwarder. VRRP already defines the necessary procedures to elect a single forwarder for a LAN.

This specification uses the VRRP virtual router MAC address as the default L2 address for the VPN Forwarder, in order to support a client virtual interface moving between locations.

While the VRRP Virtual Router MAC will be used to answer any address resolution request made by the virtual interface client (e.g., the guest VM) this does not imply that a single default router is elected per virtual IP subnet. The ingress VPN Forwarder will perform an IP forwarding decision based on the destination IP address of the (payload) traffic.

VRRP router election is only relevant in selecting the VPN Forwarder associated with a specific machine, when external forwarders are in use.

5. VPN Forwarder

In this solution, the Host OS/Hypervisor in the end-system must participate in the virtual network service. Given an end-system with multiple virtual interfaces, these virtual interfaces must be mapped onto the network by the end system OS such that applications on one virtual interface cannot send traffic to networks they are not authorized to communicate with or using source addresses not assigned to the virtual interface.

When VPN forwarder functionality is implemented by the Host OS/Hypervisor, intermediate systems in the network do not require any knowledge of the virtual network topology. This can simplify the design and operation of the physical network.

When it is not possible or desirable to add the VPN forwarding functionality to the end-system, it may be implemented by an external system, typically located as close as possible to the end-system itself.

Both models, co-located and external VPN Forwarder can co-exist in a deployment.

In order to implement the BGP IP VPN Forwarder functionality a device MUST implement the following functionality:

• Support for multiple "Virtual Routing and Forwarding" (VRF) tables;
  • VRF route entries map prefixes in the virtual network topology to a next-hop containing a infrastructure IP address and a label allocated by the destination Forwarder. The VRF table lookup follows the standard IP lookup (best-match) algorithm.
• Associate an end-system virtual interface with a specific VRF table;
  • When the Forwarder is co-located with the end-system, this association is implemented by an internal mechanism. When the Forwarder is external the association is performed using the MAC address of the end-system and an IEEE 802.1Q tag that identifies the virtual interface within the end-system.
• Encapsulate outgoing traffic (end-system to network) according to the result of the VRF lookup;
• Associate incoming packets (network to end-system) to a virtual interface for direct forwarding, or to a VRF for lookup, according to the label contained in the packet;

The VPN Forwarder MAY support the ability to associate multiple virtual interfaces with the same VRF. When that is the case, locally originated routes, that is IP routes to the local virtual interfaces SHALL NOT be used to forward outbound traffic (from the virtual interfaces to the outside) unless a route advertisement has been received that matches that specific IP prefix and next-hop information. This is intended to ensure that the forwarding behavior is the same whether the VRF is shared or between multiple interfaces of the same virtual-network or not.

As an example, if a given VRF contains two virtual interfaces, "veth0" and "veth1", with the addresses 203.0.113.1/32 and 203.0.113.2/32 respectively, the initial forwarding state must be initialized such that traffic from either of these interfaces does not match the other's routing table entry. It may, for instance, match a default route advertised by a remote system. Traffic received from other VPN Forwarders, however, must be delivered to the correct local interface. If at a subsequent stage a route is received from the Route Server such that 203.0.113.2/32 has a next-hop with the IP address of the local host and the correct label, the system may subsequently install a local routing table entry that delivers traffic directly to the "veth1" interface. This means that forwarding table entries apply to downstream traffic only, by default. This capability can be used to implement a hub-and-spoke topology, if required.

The label which is associated with a virtual interface is of local significance only and SHOULD be allocated by the VPN Forwarder.

When an external VPN Forwarder is used the end-system MUST associate each virtual interface with a VLAN [IEEE.802-1Q] that is unique on the end-system. The switching infrastructure SHOULD be configured such that multi-destination frames sourced from an end-system are only delivered to VPN Forwarders used by this end-system and not to other end-systems.

6. XMPP signaling protocol

End-System Route Servers must be aware of VPN membership on each Forwarder as well as what IP addresses are currently associated with each virtual interface.

VPN Forwarders receive VPN route information from which to populate their forwarding tables. External VPN Forwarders also need to receive the virtual interface and IP address allocation events for the end-system for which they are VPN forwarders. In this case, the end-system assigns an 802.1Q VLAN tag to each virtual interface and communicates that information to the Forwarder directly, or via the Route Server.

In order to exchange this information this specification uses the XMPP [RFC6120] protocol along with the Publish-Subscribe [pubsub] extension.

VPN forwarders (both co-located and external) establish XMPP sessions with End-System Route Servers, acting as XMPP clients. When an external VPN Forwarder is used, end-systems MAY establish XMPP sessions with VPN Forwarders. In such cases, external VPN Forwarders act as XMPP servers for end-systems which are associated with them.

A VPN Forwarder MAY connect to multiple End-System Route Servers for reliability. In this case it SHOULD publish its information to each of the Route Servers. It MAY choose to subscribe to VPN routing information from only one of the available Route Servers. In this case, the Forwarder is responsible for switching subscriptions over to an alternate Route Server in the case of Route Server failure. Alternatively, it MAY choose to subscribe to VPN routing information from more than one End-System Route Server. In this case, the Forwarder is responsible for selecting which Route Server is authoritative for each forwarding entry. The Route Servers SHOULD produce the same forwarding information for each destination. The VPN Forwarder is expected to select the entry that it deems as more recent for positive updates. It SHOULD NOT consider a forwarding entry to be withdrawn unless it is withdrawn by both Route Servers.

Each End-System Route Server MUST monitor the XMPP connection status of each VPN Forwarder that is connected to it. The information advertised by an XMPP client SHOULD be deleted after a configurable timeout, after XMPP session closes. This timeout SHOULD default to 60 seconds.

An End-System Route Server MAY monitor the status of each VPN Forwarder that is connected to it, using, for example, the BFD [RFC5880] protocol and to delete advertised information after a timeout when a failure is detected. The Route Server MAY choose to immediately reduce the preference of routing information received from an XMPP client for which a failure has been detected, either through an XMPP session close event, or a failure detection mechanism such as BFD.

                        +---------+        +--------+
                        |    RS   |--------|  BGP   |
                        +---------+        +--------+
                        /         \        /
                      XMPP         \      /
                      /             \    /
   +--------------------+            \  /
   |  End   |   VPN     |             \/
   | System | Forwarder |             /\
   +--------------------+            /  \
                      \             /    \
                      XMPP         /      \
                        \         /        \
                        +---------+        +--------+
                        |    RS   |--------|  BGP   |
                        +---------+        +--------+
                        
              VPN Forwarder Connected to Two Routing Systems

<iq type='set'
    from='forwarder@domain.org'
    to='route-server@ietf.org'
    id='sub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <subscribe node='vpn-customer-name' jid='fowarder@domain.org'/>
    <options>
      <instance-id>1</instance-id>
    </options>
  </pubsub>
</iq>

<iq type='set'
    from='end-system@domain.org'
    to='forwarder@domain.org'
    id='sub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <subscribe node='vpn-customer-name' jid='forwarder@domain.org'/>
    <options>
      <x xmlns='jabber:x:data' type='submit'>
        <field var='vpn#vlan_id'><value>100</value></field>
      </x>
    </options>
  </pubsub>
</iq>

<iq type='set'
    from='forwarder@domain.org'
    to='route-server@ietf.org'
    id='unsub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <unsubscribe 
      node='vpn-identifier'
      jid='forwarder@domain.org'/>
  </pubsub>
</iq>

<iq type='set'
    from='forwarder@domain.org'
    to='route-server@ietf.org'
    id='request1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='vpn-customer-name'>
      <item id='192.0.2.1:1:203.0.113.42/32'>
        <entry xmlns='urn:ietf:params:xml:ns:bgp:l3vpn:unicast'>
          <nlri>
            <af>1</af>
            <address>203.0.113.42</address>
          </nlri>
          <next-hops>
            <next-hop>
              <af>1</af>
              <address>192.0.2.1</address>
              <label>10000</label>
              <tunnel-encapsulation-list>
                <tunnel-encapsulation>gre</tunnel-encapsulation>
                <tunnel-encapsulation>udp</tunnel-encapsulation>
              </tunnel-encapsulation-list>
            </next-hop>
          </next-hops>
          <sequence-number>1</sequence-number>
        </entry>
      </item>
    </publish>
  </pubsub>
</iq>

<iq type='set'
    from='forwarder@domain.org'
    to='route-server@ietf.org'
    id='retract1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <retract node='vpn-customer-name'>
      <item id='192.0.2.1:1:203.0.113.42/32'/>
    </retract>
  </pubsub>
</iq>

<message to='forwarder@domain.org' from='route-server@ietf.org'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='vpn-customer-name'>
      <item id='192.0.2.1:1:203.0.113.42/32'>
        <entry xmlns='urn:ietf:params:xml:ns:bgp:l3vpn:unicast'>
          <nlri>
            <af>1</af>
            <address>203.0.113.42/32</address>
          </nlri>
          <next-hops>
            <next-hop>
              <af>1</af>
              <address>192.0.2.1</address>
              <label>10000</label>
              <tunnel-encapsulation-list>
                <tunnel-encapsulation>gre</tunnel-encapsulation>
                <tunnel-encapsulation>udp</tunnel-encapsulation>
              </tunnel-encapsulation-list>
            </next-hop>
          </next-hops>
          <sequence-number>1</sequence-number>
        </entry>
      </item>
      <item >
        ...
      </item>
    </items>
  </event>
</message>

                             .------.
+----+       +-----+        /        \        +-----+       +----+
| H1 | <===> | RS1 | <===> ( BGP mesh ) <===> | RS2 | <===> | H2 |
+----+       +-----+        \        /        +-----+       +----+
                             `------'
                             
       Example Network with Two Hosts and Two Route Servers

               +--------+                 +--------+
app -- veth0 --|   H1   |=== [network] ===|   H2   |-- veth0 -- app
               +--------+                 +--------+

IP pkt ===> encap (GRE + label) ===> [IP net] ===> decap ===> IP pkt
            [192.51.100.10, 20]                 map 20 to veth0

        Packet Flow from Application in H1 to Application in H2

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    targetNamespace=
        "urn:ietf:params:xml:ns:bgp:l3vpn:unicast">

<xsd:simpleType name="TunnelEncapsulationType">
    <xsd:restriction base="xsd:string">
        <xsd:enumeration value="gre"/>
            <!-- RFC 4023 -->
        <xsd:enumeration value="udp"/>
            <!-- RFC 7510 -->
        <xsd:enumeration value="vxlan"/>
            <!-- RFC 7348 -->
    </xsd:restriction>
</xsd:simpleType>

<xsd:complexType name="TunnelEncapsulationListType">
  <xsd:sequence>
    <xsd:element name="tunnel-encapsulation"
        type="TunnelEncapsulationType"
        maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType> 

<xsd:complexType name="NextHopType">
  <xsd:sequence>
    <xsd:element name="af" type="xsd:integer"/>
    <xsd:element name="address" type="xsd:string"/>
    <xsd:element name="label" type="xsd:integer"/>
    <xsd:element name="tunnel-encapsulation-list"
        type="TunnelEncapsulationListType"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="NextHopListType">
  <xsd:sequence>
    <xsd:element name="next-hop" type="NextHopType"
        maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="IPAddressType">
  <xsd:sequence>
    <xsd:element name="af" type="xsd:integer"/>
    <xsd:element name="safi" type="xsd:integer"/>
    <xsd:element name="address" type="xsd:string"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="EntryType">
    <xsd:all>
        <xsd:element name="nlri" type="IPAddressType"/>
        <xsd:element name="next-hops" type="NextHopListType"/>
        <xsd:element name="sequence-number" type="xsd:integer"/>
        <xsd:element name="local-preference" type="xsd:integer"/>
    </xsd:all>
</xsd:complexType>

<xsd:complexType name="ItemType">
  <xsd:sequence>
    <xsd:element name="entry" type="EntryType"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="ItemsType">
    <xsd:sequence>
        <xsd:element name="item" type="ItemType"
            maxOccurs="unbounded"/>
    </xsd:sequence>
</xsd:complexType>

<xsd:element name="items" type="ItemsType"/>

</xsd:schema>