Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8299

 
 
 

YANG Data Model for L3VPN Service Delivery

Part 3 of 8, p. 32 to 47
Prev Section       Next Section

 


prevText      Top      ToC       Page 32 
6.3.  Site Overview

   A site represents a connection of a customer office to one or more
   VPN services.  Each site is associated with one or more locations.

                                                    +-------------+
                                                   /               \
     +------------------+                   +-----|      VPN1       |
     |                  |                   |      \               /
     |  New York Office |------ (site) -----+       +-------------+
     |                  |                   |       +-------------+
     +------------------+                   |      /               \
                                            +-----|      VPN2       |
                                                   \               /
                                                    +-------------+

   A site has several characteristics:

   o  Unique identifier (site-id): uniquely identifies the site within
      the overall network infrastructure.  The identifier is a string
      that allows any encoding for the local administration of the VPN
      service.

   o  Locations (locations): site location information that allows easy
      retrieval of information from the nearest available resources.  A
      site may be composed of multiple locations.  Alternatively, two or
      more sites can be associated with the same location, by
      referencing the same location ID.

   o  Devices (devices): allows the customer to request one or more
      customer premises equipment entities from the SP for a particular
      site.

   o  Management (management): defines the type of management for the
      site -- for example, co-managed, customer-managed, or provider-
      managed.  See Section 6.10.

   o  Site network accesses (site-network-accesses): defines the list of
      network accesses associated with the sites, and their properties
      -- especially bearer, connection, and service parameters.

   A site-network-access represents an IP logical connection of a site.
   A site may have multiple site-network-accesses.

Top      Up      ToC       Page 33 
         +------------------+             Site
         |                  |-----------------------------------
         |                  |****** (site-network-access#1) ******
         |  New York Office |
         |                  |****** (site-network-access#2) ******
         |                  |-----------------------------------
         +------------------+

   Multiple site-network-accesses are used, for instance, in the case of
   multihoming.  Some other meshing cases may also include multiple
   site-network-accesses.

   The site configuration is viewed as a global entity; we assume that
   it is mostly the management system's role to split the parameters
   between the different elements within the network.  For example, in
   the case of the site-network-access configuration, the management
   system needs to split the overall parameters between the PE
   configuration and the CE configuration.

6.3.1.  Devices and Locations

   A site may be composed of multiple locations.  All the locations will
   need to be configured as part of the "locations" container and list.
   A typical example of a multi-location site is a headquarters office
   in a city composed of multiple buildings.  Those buildings may be
   located in different parts of the city and may be linked by intra-
   city fibers (customer metropolitan area network).  In such a case,
   when connecting to a VPN service, the customer may ask for
   multihoming based on its distributed locations.

           New York Site

         +------------------+             Site
         | +--------------+ |-----------------------------------
         | | Manhattan    | |****** (site-network-access#1) ******
         | +--------------+ |
         | +--------------+ |
         | | Brooklyn     | |****** (site-network-access#2) ******
         | +--------------+ |
         |                  |-----------------------------------
         +------------------+

   A customer may also request some premises equipment entities (CEs)
   from the SP via the "devices" container.  Requesting a CE implies a
   provider-managed or co-managed model.  A particular device must be
   ordered to a particular already-configured location.  This would help

Top      Up      ToC       Page 34 
   the SP send the device to the appropriate postal address.  In a
   multi-location site, a customer may, for example, request a CE for
   each location on the site where multihoming must be implemented.  In
   the figure above, one device may be requested for the Manhattan
   location and one other for the Brooklyn location.

   By using devices and locations, the user can influence the
   multihoming scenario he wants to implement: single CE, dual CE, etc.

6.3.2.  Site Network Accesses

   As mentioned earlier, a site may be multihomed.  Each IP network
   access for a site is defined in the "site-network-accesses"
   container.  The site-network-access parameter defines how the site is
   connected on the network and is split into three main classes of
   parameters:

   o  bearer: defines requirements of the attachment (below Layer 3).

   o  connection: defines Layer 3 protocol parameters of the attachment.

   o  availability: defines the site's availability policy.  The
      availability parameters are defined in Section 6.7.

   The site-network-access has a specific type (site-network-access-
   type).  This document defines two types:

   o  point-to-point: describes a point-to-point connection between the
      SP and the customer.

   o  multipoint: describes a multipoint connection between the SP and
      the customer.

   The type of site-network-access may have an impact on the parameters
   offered to the customer, e.g., an SP may not offer encryption for
   multipoint accesses.  It is up to the provider to decide what
   parameter is supported for point-to-point and/or multipoint accesses;
   this topic is out of scope for this document.  Some containers
   proposed in the model may require extensions in order to work
   properly for multipoint accesses.

6.3.2.1.  Bearer

   The bearer container defines the requirements for the site attachment
   to the provider network that are below Layer 3.

   The bearer parameters will help determine the access media to be
   used.  This is further described in Section 6.6.3.

Top      Up      ToC       Page 35 
6.3.2.2.  Connection

   The "ip-connection" container defines the protocol parameters of the
   attachment (IPv4 and IPv6).  Depending on the management mode, it
   refers to PE-CE addressing or CE-to-customer-LAN addressing.  In any
   case, it describes the responsibility boundary between the provider
   and the customer.  For a customer-managed site, it refers to the
   PE-CE connection.  For a provider-managed site, it refers to the
   CE-to-LAN connection.

6.3.2.2.1.  IP Addressing

   An IP subnet can be configured for either IPv4 or IPv6 Layer 3
   protocols.  For a dual-stack connection, two subnets will be
   provided, one for each address family.

   The "address-allocation-type" determines how the address allocation
   needs to be done.  The current model defines five ways to perform IP
   address allocation:

   o  provider-dhcp: The provider will provide DHCP service for customer
      equipment; this is applicable to either the "IPv4" container or
      the "IPv6" container.

   o  provider-dhcp-relay: The provider will provide DHCP relay service
      for customer equipment; this is applicable to both IPv4 and IPv6
      addressing.  The customer needs to populate the DHCP server list
      to be used.

   o  static-address: Addresses will be assigned manually; this is
      applicable to both IPv4 and IPv6 addressing.

   o  slaac: This parameter enables stateless address autoconfiguration
      [RFC4862].  This is applicable to IPv6 only.

   o  provider-dhcp-slaac: The provider will provide DHCP service for
      customer equipment, as well as stateless address
      autoconfiguration.  This is applicable to IPv6 only.

   In the dynamic addressing mechanism, the SP is expected to provide at
   least the IP address, prefix length, and default gateway information.
   In the case of multiple site-network-access points belonging to the
   same VPN, address space allocated for one site-network-access should
   not conflict with one allocated for other site-network-accesses.

Top      Up      ToC       Page 36 
6.3.2.2.2.  OAM

   A customer may require a specific IP connectivity fault detection
   mechanism on the IP connection.  The model supports BFD as a fault
   detection mechanism.  This can be extended with other mechanisms via
   augmentation.  The provider can propose some profiles to the
   customer, depending on the service level the customer wants to
   achieve.  Profile names must be communicated to the customer.  This
   communication is out of scope for this document.  Some fixed values
   for the holdtime period may also be imposed by the customer if the
   provider allows the customer this function.

   The "oam" container can easily be augmented by other mechanisms; in
   particular, work done by the LIME Working Group
   (https://datatracker.ietf.org/wg/lime/charter/) may be reused in
   applicable scenarios.

6.3.2.3.  Inheritance of Parameters Defined at Site Level and Site
          Network Access Level

   Some parameters can be configured at both the site level and the
   site-network-access level, e.g., routing, services, security.
   Inheritance applies when parameters are defined at the site level.
   If a parameter is configured at both the site level and the access
   level, the access-level parameter MUST override the site-level
   parameter.  Those parameters will be described later in this
   document.

   In terms of provisioning impact, it will be up to the implementation
   to decide on the appropriate behavior when modifying existing
   configurations.  But the SP will need to communicate to the user
   about the impact of using inheritance.  For example, if we consider
   that a site has already provisioned three site-network-accesses, what
   will happen if a customer changes a service parameter at the site
   level?  An implementation of this model may update the service
   parameters of all already-provisioned site-network-accesses (with
   potential impact on live traffic), or it may take into account this
   new parameter only for the new sites.

6.4.  Site Role

   A VPN has a particular service topology, as described in
   Section 6.2.1.  As a consequence, each site belonging to a VPN is
   assigned with a particular role in this topology.  The site-role leaf
   defines the role of the site in a particular VPN topology.

   In the any-to-any VPN service topology, all sites MUST have the same
   role, which will be "any-to-any-role".

Top      Up      ToC       Page 37 
   In the Hub-and-Spoke VPN service topology or the Hub and Spoke
   disjoint VPN service topology, sites MUST have a Hub role or a Spoke
   role.

6.5.  Site Belonging to Multiple VPNs

6.5.1.  Site VPN Flavor

   A site may be part of one or multiple VPNs.  The "site-vpn-flavor"
   defines the way the VPN multiplexing is done.  The current version of
   the model supports four flavors:

   o  site-vpn-flavor-single: The site belongs to only one VPN.

   o  site-vpn-flavor-multi: The site belongs to multiple VPNs, and all
      the logical accesses of the sites belong to the same set of VPNs.

   o  site-vpn-flavor-sub: The site belongs to multiple VPNs with
      multiple logical accesses.  Each logical access may map to
      different VPNs (one or many).

   o  site-vpn-flavor-nni: The site represents an option A NNI.

6.5.1.1.  Single VPN Attachment: site-vpn-flavor-single

   The figure below describes a single VPN attachment.  The site
   connects to only one VPN.

                                                         +--------+
      +------------------+             Site             /          \
      |                  |-----------------------------|            |
      |                  |***(site-network-access#1)***|    VPN1    |
      |  New York Office |                             |            |
      |                  |***(site-network-access#2)***|            |
      |                  |-----------------------------|            |
      +------------------+                              \          /
                                                         +--------+

Top      Up      ToC       Page 38 
6.5.1.2.  MultiVPN Attachment: site-vpn-flavor-multi

   The figure below describes a site connected to multiple VPNs.

                                                           +---------+
                                                      +---/----+      \
   +------------------+             Site             /   |      \      |
   |                  |--------------------------------- |       |VPN B|
   |                  |***(site-network-access#1)******* |       |     |
   |  New York Office |                             |    |       |     |
   |                  |***(site-network-access#2)*******  \      |    /
   |                  |-----------------------------| VPN A+-----|---+
   +------------------+                              \          /
                                                      +--------+


   In the example above, the New York office is multihomed.  Both
   logical accesses are using the same VPN attachment rules, and both
   are connected to VPN A and VPN B.

   Reaching VPN A or VPN B from the New York office will be done via
   destination-based routing.  Having the same destination reachable
   from the two VPNs may cause routing troubles.  The customer
   administration's role in this case would be to ensure the appropriate
   mapping of its prefixes in each VPN.

6.5.1.3.  SubVPN Attachment: site-vpn-flavor-sub

   The figure below describes a subVPN attachment.  The site connects to
   multiple VPNs, but each logical access is attached to a particular
   set of VPNs.  A typical use case for a subVPN is a customer site used
   by multiple affiliates with private resources for each affiliate that
   cannot be shared (communication between the affiliates is prevented).
   It is similar to having separate sites, but in the case of a SubVPN,
   the customer can share some physical components at a single location,
   while maintaining strong communication isolation between the
   affiliates.  In this example, site-network-access#1 is attached to
   VPN B, while site-network-access#2 is attached to VPN A.

Top      Up      ToC       Page 39 
    +------------------+         Site                      +--------+
    |                  |----------------------------------/          \
    |                  |****(site-network-access#1)******|    VPN B   |
    |  New York Office |                                  \          /
    |                  |                                   +--------+
    |                  |                                   +--------+
    |                  |                                  /          \
    |                  |****(site-network-access#2)******|    VPN A   |
    |                  |                                  \          /
    |                  |                                   +--------+
    |                  |-----------------------------------
    +------------------+

   A multiVPN can be implemented in addition to a subVPN; as a
   consequence, each site-network-access can access multiple VPNs.  In
   the example below, site-network-access#1 is mapped to VPN B and VPN
   C, while site-network-access#2 is mapped to VPN A and VPN D.

   +-----------------+         Site                    +------+
   |                 |--------------------------------/       +-----+
   |                 |****(site-network-access#1)****| VPN B /       \
   | New York Office |                                \     |  VPN C  |
   |                 |                                 +-----\       /
   |                 |                                        +-----+
   |                 |
   |                 |                                 +-------+
   |                 |                                /        +-----+
   |                 |****(site-network-access#2)****| VPN A  /       \
   |                 |                                \      | VPN D   |
   |                 |                                 +------\       /
   |                 |---------------------------------        +-----+
   +-----------------+

   Multihoming is also possible with subVPNs; in this case, site-
   network-accesses are grouped, and a particular group will have access
   to the same set of VPNs.  In the example below, site-network-access#1
   and site-network-access#2 are part of the same group (multihomed
   together) and are mapped to VPN B and VPN C; in addition, site-
   network-access#3 and site-network-access#4 are part of the same group
   (multihomed together) and are mapped to VPN A and VPN D.

Top      Up      ToC       Page 40 
   +-----------------+         Site                     +------+
   |                 |---------------------------------/       +-----+
   |                 |****(site-network-access#1)*****| VPN B /       \
   | New York Office |****(site-network-access#2)***** \     |  VPN C  |
   |                 |                                  +-----\       /
   |                 |                                         +-----+
   |                 |
   |                 |                                  +------+
   |                 |                                 /       +-----+
   |                 |****(site-network-access#3)*****| VPN A /       \
   |                 |****(site-network-access#4)***** \     | VPN D   |
   |                 |                                  +-----\       /
   |                 |----------------------------------       +-----+
   +-----------------+

   In terms of service configuration, a subVPN can be achieved by
   requesting that the site-network-access use the same bearer (see
   Section 6.6.4 for more details).

6.5.1.4.  NNI: site-vpn-flavor-nni

   A Network-to-Network Interface (NNI) scenario may be modeled using
   the sites container (see Section 6.15.1).  Using the sites container
   to model an NNI is only one possible option for NNIs (see
   Section 6.15).  This option is called "option A" by reference to the
   option A NNI defined in [RFC4364].  It is helpful for the SP to
   indicate that the requested VPN connection is not a regular site but
   rather is an NNI, as specific default device configuration parameters
   may be applied in the case of NNIs (e.g., ACLs, routing policies).

Top      Up      ToC       Page 41 
           SP A                                             SP B
      -------------------                         -------------------
     /                   \                       /                   \
    |                     |                     |                     |
    |                 ++++++++ Inter-AS link ++++++++                 |
    |                 +      +_______________+      +                 |
    |                 +  (VRF1)---(VPN1)----(VRF1)  +                 |
    |                 + ASBR +               + ASBR +                 |
    |                 +  (VRF2)---(VPN2)----(VRF2)  +                 |
    |                 +      +_______________+      +                 |
    |                 ++++++++               ++++++++                 |
    |                     |                     |                     |
    |                     |                     |                     |
    |                     |                     |                     |
    |                 ++++++++ Inter-AS link ++++++++                 |
    |                 +      +_______________+      +                 |
    |                 +  (VRF1)---(VPN1)----(VRF1)  +                 |
    |                 + ASBR +               + ASBR +                 |
    |                 +  (VRF2)---(VPN2)----(VRF2)  +                 |
    |                 +      +_______________+      +                 |
    |                 ++++++++               ++++++++                 |
    |                     |                     |                     |
    |                     |                     |                     |
     \                   /                       \                   /
      -------------------                         -------------------

   The figure above describes an option A NNI scenario that can be
   modeled using the sites container.  In order to connect its customer
   VPNs (VPN1 and VPN2) in SP B, SP A may request the creation of some
   site-network-accesses to SP B.  The site-vpn-flavor-nni will be used
   to inform SP B that this is an NNI and not a regular customer site.
   The site-vpn-flavor-nni may be multihomed and multiVPN as well.

6.5.2.  Attaching a Site to a VPN

   Due to the multiple site-vpn flavors, the attachment of a site to an
   IP VPN is done at the site-network-access (logical access) level
   through the "vpn-attachment" container.  The vpn-attachment container
   is mandatory.  The model provides two ways to attach a site to a VPN:

   o  By referencing the target VPN directly.

   o  By referencing a VPN policy for attachments that are more complex.

   A choice is implemented to allow the user to choose the flavor that
   provides the best fit.

Top      Up      ToC       Page 42 
6.5.2.1.  Referencing a VPN

   Referencing a vpn-id provides an easy way to attach a particular
   logical access to a VPN.  This is the best way in the case of a
   single VPN attachment or subVPN with a single VPN attachment per
   logical access.  When referencing a vpn-id, the site-role setting
   must be added to express the role of the site in the target VPN
   service topology.

 <?xml version="1.0"?>
 <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
  <vpn-services>
   <vpn-service>
    <vpn-id>VPNA</vpn-id>
   </vpn-service>
   <vpn-service>
    <vpn-id>VPNB</vpn-id>
   </vpn-service>
  </vpn-services>
  <sites>
   <site>
    <site-id>SITE1</site-id>
    <locations>
     <location>
      <location-id>L1</location-id>
     </location>
    </locations>
    <management>
     <type>customer-managed</type>
    </management>
    <security>
     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>LA1</site-network-access-id>
      <ip-connection>
       <ipv4>
        <address-allocation-type>provider-dhcp</address-allocation-type>
       </ipv4>
       <ipv6>
        <address-allocation-type>provider-dhcp</address-allocation-type>
       </ipv6>
      </ip-connection>
      <service>
       <svc-mtu>1514</svc-mtu>

Top      Up      ToC       Page 43 
       <svc-input-bandwidth>10000000</svc-input-bandwidth>
       <svc-output-bandwidth>10000000</svc-output-bandwidth>
      </service>
      <security>
       <encryption>
        <layer>layer3</layer>
       </encryption>
      </security>
      <location-reference>L1</location-reference>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
     <site-network-access>
      <site-network-access-id>LA2</site-network-access-id>
      <ip-connection>
       <ipv4>
        <address-allocation-type>provider-dhcp</address-allocation-type>
       </ipv4>
       <ipv6>
        <address-allocation-type>provider-dhcp</address-allocation-type>
       </ipv6>
      </ip-connection>
      <service>
       <svc-mtu>1514</svc-mtu>
       <svc-input-bandwidth>10000000</svc-input-bandwidth>
       <svc-output-bandwidth>10000000</svc-output-bandwidth>
      </service>
      <security>
       <encryption>
        <layer>layer3</layer>
       </encryption>
      </security>
      <location-reference>L1</location-reference>
      <vpn-attachment>
       <vpn-id>VPNB</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
  </sites>
 </l3vpn-svc>

   The example of a corresponding XML snippet above describes a subVPN
   case where a site (SITE1) has two logical accesses (LA1 and LA2),
   with LA1 attached to VPNA and LA2 attached to VPNB.

Top      Up      ToC       Page 44 
6.5.2.2.  VPN Policy

   The "vpn-policy" list helps express a multiVPN scenario where a
   logical access belongs to multiple VPNs.  Multiple VPN policies can
   be created to handle the subVPN case where each logical access is
   part of a different set of VPNs.

   As a site can belong to multiple VPNs, the vpn-policy list may be
   composed of multiple entries.  A filter can be applied to specify
   that only some LANs of the site should be part of a particular VPN.
   Each time a site (or LAN) is attached to a VPN, the user must
   precisely describe its role (site-role) within the target VPN service
   topology.

     +--------------------------------------------------------------+
     |       Site1 ------ PE7                                       |
     +-------------------------+                 (VPN2)             |
                               |                                    |
     +-------------------------+                                    |
     |       Site2 ------ PE3               PE4 ------ Site3        |
     +----------------------------------+                           |
                                        |                           |
     +------------------------------------------------------------+ |
     |       Site4 ------ PE5           |   PE6 ------ Site5      | |
     |                                                            | |
     |                      (VPN3)                                | |
     +------------------------------------------------------------+ |
                                        |                           |
                                        +---------------------------+

   In the example above, Site5 is part of two VPNs: VPN3 and VPN2.  It
   will play a Hub role in VPN2 and an any-to-any role in VPN3.  We can
   express such a multiVPN scenario with the following XML snippet:

 <?xml version="1.0"?>
 <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
  <vpn-services>
   <vpn-service>
    <vpn-id>VPN2</vpn-id>
   </vpn-service>
   <vpn-service>
    <vpn-id>VPN3</vpn-id>
   </vpn-service>
  </vpn-services>
  <sites>
   <site>
    <site-id>Site5</site-id>
    <devices>

Top      Up      ToC       Page 45 
     <device>
      <device-id>D1</device-id>
     </device>
    </devices>
    <management>
     <type>provider-managed</type>
    </management>
    <security>
     <encryption>
      <layer>layer3</layer>
     </encryption>
    </security>
    <vpn-policies>
     <vpn-policy>
      <vpn-policy-id>POLICY1</vpn-policy-id>
      <entries>
       <id>ENTRY1</id>
       <vpn>
        <vpn-id>VPN2</vpn-id>
        <site-role>hub-role</site-role>
       </vpn>
      </entries>
      <entries>
       <id>ENTRY2</id>
       <vpn>
        <vpn-id>VPN3</vpn-id>
        <site-role>any-to-any-role</site-role>
       </vpn>
      </entries>
     </vpn-policy>
    </vpn-policies>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>LA1</site-network-access-id>
      <device-reference>D1</device-reference>
      <ip-connection>
       <ipv4>
        <address-allocation-type>provider-dhcp</address-allocation-type>
       </ipv4>
       <ipv6>
        <address-allocation-type>provider-dhcp</address-allocation-type>
       </ipv6>
      </ip-connection>
      <service>
       <svc-mtu>1514</svc-mtu>
       <svc-input-bandwidth>10000000</svc-input-bandwidth>
       <svc-output-bandwidth>10000000</svc-output-bandwidth>
      </service>

Top      Up      ToC       Page 46 
      <security>
       <encryption>
        <layer>layer3</layer>
       </encryption>
      </security>
      <vpn-attachment>
       <vpn-policy-id>POLICY1</vpn-policy-id>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
  </sites>
 </l3vpn-svc>

   Now, if a more-granular VPN attachment is necessary, filtering can be
   used.  For example, if only LAN1 from Site5 must be attached to VPN2
   as a Hub and only LAN2 must be attached to VPN3, the following XML
   snippet can be used:

      <?xml version="1.0"?>
      <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
        <vpn-services>
          <vpn-service>
            <vpn-id>VPN2</vpn-id>
          </vpn-service>
          <vpn-service>
            <vpn-id>VPN3</vpn-id>
          </vpn-service>
        </vpn-services>
        <sites>
          <site>
            <site-id>Site5</site-id>
            <vpn-policies>
              <vpn-policy>
                <vpn-policy-id>POLICY1</vpn-policy-id>
                <entries>
                  <id>ENTRY1</id>
                  <filters>
                    <filter>
                      <type>lan</type>
                      <lan-tag>LAN1</lan-tag>
                    </filter>
                  </filters>
                  <vpn>
                    <vpn-id>VPN2</vpn-id>
                    <site-role>hub-role</site-role>
                  </vpn>
                </entries>

Top      Up      ToC       Page 47 
                <entries>
                  <id>ENTRY2</id>
                  <filters>
                    <filter>
                      <type>lan</type>
                      <lan-tag>LAN2</lan-tag>
                    </filter>
                  </filters>
                  <vpn>
                    <vpn-id>VPN3</vpn-id>
                    <site-role>any-to-any-role</site-role>
                  </vpn>
                </entries>
              </vpn-policy>
            </vpn-policies>
            <site-network-accesses>
              <site-network-access>
                <site-network-access-id>LA1</site-network-access-id>
                <vpn-attachment>
                  <vpn-policy-id>POLICY1</vpn-policy-id>
                </vpn-attachment>
              </site-network-access>
            </site-network-accesses>
          </site>
        </sites>
      </l3vpn-svc>



(page 47 continued on part 4)

Next Section