[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

Network Working Group                                              Z. Li
Internet-Draft                                                 S. Zhuang
Intended status: Informational                                    G. Yan
Expires: September 9, 2015                           Huawei Technologies
                                                           March 8, 2015


                   Yang Data Model for Tunnel Policy
                  draft-li-rtgwg-tunnel-policy-yang-00

Abstract

   This document defines a YANG data model that can be used to configure
   and manage tunnel policy.

Requirements Language

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

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 September 9, 2015.

Copyright Notice

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



Li, et al.              Expires September 9, 2015               [Page 1]


Internet-Draft      Yang Data Model for Tunnel Policy         March 2015


   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
   2.  Definitions and Acronyms  . . . . . . . . . . . . . . . . . .   2
   3.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Tunnel Policy . . . . . . . . . . . . . . . . . . . . . .   3
       3.1.1.  Selection Sequence  . . . . . . . . . . . . . . . . .   3
       3.1.2.  Tunnel Binding  . . . . . . . . . . . . . . . . . . .   3
     3.2.  Tunnel Selector for Routes  . . . . . . . . . . . . . . .   4
     3.3.  Tunnel Selector for VPNs  . . . . . . . . . . . . . . . .   5
   4.  Design of Data Model  . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Tunnel Policy YANG Model  . . . . . . . . . . . . . . . .   5
     4.2.  Tunnel Selector YANG Model  . . . . . . . . . . . . . . .   5
   5.  Tunnel Policy Yang Module . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   YANG [RFC6020] is a data definition language that was introduced to
   define the contents of a conceptual data store that allows networked
   devices to be managed using NETCONF[RFC6241].  YANG is proving
   relevant beyond its initial confines, as bindings to other
   interfaces(e.g.  ReST) and encoding other than XML (e.g.  JSON) are
   being defined.  Furthermore, YANG data models can be used as the
   basis of implementation for other interface, such as CLI and
   programmatic APIs.

   This document defines a YANG data model that can be used to configure
   and manage tunnel policy.

2.  Definitions and Acronyms

   JSON: JavaScript Object Notation

   LSP: Label Switched Path

   NETCONF: Network Configuration Protocol

   RD: Route Distinguisher



Li, et al.              Expires September 9, 2015               [Page 2]


Internet-Draft      Yang Data Model for Tunnel Policy         March 2015


   TNLM: Tunnel Management

   VPN: Virtual Private Network

   YANG: A data definition language for NETCONF

3.  Introduction

3.1.  Tunnel Policy

   At present, multiple types of tunnels can be provided, such as LDP
   LSPs, static LSPs and CRLSP.  It is necessary to select different
   tunnels for the VPN services according to the specific tunnel policy.

   A tunnel policy determines which type of tunnels can be selected.
   Tunnel policies can be classified into two modes:

   o Selection Sequence: The system selects a tunnel for the service
   based on the tunnel type priorities defined in the tunnel policy.

   o Tunnel binding: The system selects only a specified tunnel for the
   service.

3.1.1.  Selection Sequence

   Selection sequence, as a tunnel policy mode, specifies the tunnel-
   selecting sequence and the number of tunnels in the load balancing
   mode.  Selection Sequence is applicable to the tunnels including the
   LSP, CR-LSP, etc.  In selection-sequence mode, tunnels are selected
   in sequence.  If a tunnel listed earlier is Up and not bound, it is
   selected regardless of whether other services have selected it; if a
   tunnel is listed later, it is not selected except that load balancing
   is required or the preceding tunnels are all in the Down state.

3.1.2.  Tunnel Binding

   Tunnel binding, as a tunnel policy mode, binds a tunnel with a
   destination IP address.  Tunnel binding is only applicable to TE
   tunnels.

   In tunnel binding mode, multiple TE tunnels can be specified to
   perform load balancing for the same destination IP address.
   Moreover, the down-switch attribute can be specified to ensure that
   other tunnels can be selected when all the designated tunnels are
   unavailable, which keeps the traffic uninterrupted to the maximum
   extent.





Li, et al.              Expires September 9, 2015               [Page 3]


Internet-Draft      Yang Data Model for Tunnel Policy         March 2015


   In terms of tunnel selection among TE tunnels, tunnels are selected
   according to the destination IP address and name of these TE tunnels.
   The principles of tunnel selection are as follows:

   1.  If the tunnel policy designates no TE tunnel for the destination
   IP address, the tunnels electing sequence is LSP, CR-LSP.

   2.  If the tunnel policy designates a TE tunnel for the destination
   IP address, and the designated TE tunnels is available, the TE tunnel
   is selected.

   3.  If the tunnel policy designates a TE tunnel for the destination
   IP address, but the designated TE tunnels is unavailable, the tunnel-
   selecting result is determined by the down-switch attribute.  If the
   down-switch attribute is configured, another available tunnel is
   selected based on the sequence of LSP, CR-LSP, and GRE tunnel; if the
   down-switch attribute is not configured, no tunnel is selected.

3.2.  Tunnel Selector for Routes

   A tunnel policy selector defines certain matching rules and
   associates the routes whose attributes matching the rules with
   specific tunnels.  This facilitates flexible tunneling and better
   satisfies user requirements.

   A tunnel policy selector consists of one more policy nodes and the
   relationship between these policy nodes is "OR".  The system checks
   the policy nodes based on index numbers.  If a route matches a policy
   node in the tunnel policy, the route does not continue to match the
   next policy node.  Each policy node comprises a set of if-match and
   apply clauses:

   1.  The if-match clauses define the matching rules that are used to
   match certain route attributes such as the next hop and RD.  The
   relationship between the if-match clauses of a node is "AND".  A
   route matches a node only when the route meets all the matching rules
   specified by the if-match clauses of the node.

   2.  The apply clause specifies actions.  When a route matches a node,
   the apply clause selects a tunnel policy for the route.  The matching
   modes of a node are as follows:

   a) Permit: If a route matches all the if-match clauses of a node, the
   route matches the node and the actions defined by the apply clause
   are performed on the route.  If a route does not match one if-match
   clause of a node, the route continues to match the next node.





Li, et al.              Expires September 9, 2015               [Page 4]


Internet-Draft      Yang Data Model for Tunnel Policy         March 2015


   b) Deny: In this mode, the actions defined by the apply clause are
   not performed.  If a route matches all the if-match clauses of a
   node, the route is denied and does not match the next node.

3.3.  Tunnel Selector for VPNs

   Selection of the tunnel for the VPN services includes the matching
   rules and the applied tunnel policy.  The data model is defined in
   the drafts of VPN Yang models which is out of the scope of the
   document.  They can refer to the Yang models defined in the document
   for the tunnel policy.

4.  Design of Data Model

4.1.  Tunnel Policy YANG Model

   A tunnel policy determines which type of tunnels can be selected by
   an application module.  The configuration of tunnel policy includes
   defining the tunnel selection sequence mode and the binding mode for
   the tunnel selection.

   +--rw tunnelPolicys
   |  +--rw tunnelPolicy* [tunnelPolicyName]
   |     +--rw tunnelPolicyName       string
   |     +--rw description?           string
   |     +--rw (tunnelPolicyMode)?
   |        +--:(SpecifyTunnelSelectionSequence)
   |        |  +--rw tunnelTypeSequences
   |        |     +--rw tunnelType*          enumeration
   |        |     +--rw loadBalanceNumber    uint32
   |        +--:(BindApplicationToTunnel)
   |           +--rw bindingPolicies
   |              +--rw bindingPolicy* [nextHopAddress]
   |                 +--rw nextHopAddress            inet:ip-address
   |                 +--rw tunnelInterface*          leafref
   |                 +--rw ignoreDestinationCheck?   boolean
   |                 +--rw downSwitch?               boolean

4.2.  Tunnel Selector YANG Model

   A tunnel policy selector defines certain matching rules and
   associates the routes whose attributes matching the rules with
   specific tunnels.  This facilitates flexible tunneling and satisfies
   user requirements better.

   Configuration of the tunnel selector and applying it to BGP VPNv4/
   VPNv6 address-family can make the VPN service to select the specific
   tunnel for VPN data transmission.



Li, et al.              Expires September 9, 2015               [Page 5]


Internet-Draft      Yang Data Model for Tunnel Policy         March 2015


   +--rw tunnelSelector* [name]
      +--rw name                   string
      +--rw description?           string
      +--rw tunnelSelectorNodes
         +--rw tunnelSelectorNode* [nodeSequence]
            +--rw nodeSequence      uint32
            +--rw matchMode?        enumeration
            +--rw matchCondition
            |  +--rw matchIPv4NextHop
            |  |  +--rw matchType       enumeration
            |  |  +--rw prefixName      string
            |  |  +--rw aclNameOrNum    string
            |  +--rw matchIPv6NextHop
            |  |  +--rw ipv6PrefixName    string
            |  +--rw matchRdFilter
            |     +--rw rdIndex    uint32
            +--rw applyAction
               +--rw tunnelPolicyName    string

   augment /bgp:bgp-router/bgp:vpnv4/bgp:unicast:
      +--rw tunnelSelectorName?   string
   augment /bgp:bgp-router/bgp:vpnv6/bgp:unicast:
      +--rw tunnelSelectorName?   string

5.  Tunnel Policy Yang Module

//Tunnel Management YANG MODEL
<CODE BEGINS> file "tunnel-management@2015-01-12.yang"
module tunnel-management {
  namespace "urn:huawei:params:xml:ns:yang:tunnel-management";
  // replace with IANA namespace when assigned
  prefix "tlnm";

  import bgp {
    prefix bgp;
    //draft-zhdankin-netmod-bgp-cfg
  }

  import ietf-interfaces {
    prefix if;
    //rfc7223-YANG Interface Management
  }

  import ietf-inet-types {
    prefix inet;
    //rfc6991-Common YANG Data Types
  }




Li, et al.              Expires September 9, 2015               [Page 6]


Internet-Draft      Yang Data Model for Tunnel Policy         March 2015


  description
    "This YANG module defines the tunnel management configuration
     data for tunnel management service.
     ";

  revision 2015-01-12 {
    description
      "Initial revision.";
  }

  grouping matchMode {
    leaf matchMode {
      config "true";
      type enumeration {
        enum "permit" {
          value "0";
          description "permit:
            Specifies the matching mode of the route-policy as permit.
            In permit mode, a route matches all the if-match clauses,
            the route matches the route-policy and the actions defined
            by the apply clause are performed on the route. Otherwise,
            the route continues to match the next entry.";
        }
        enum "deny" {
          value "1";
          description "deny:
            Specifies the matching mode of the route-policy as deny. In
            deny mode, if a route matches all the if-match clauses, the
            route fails to match the route-policy and cannot match the
            next node.";
        }
      }
    }
  }//End of grouping matchMode

  /*
   A tunnel policy determines which type of tunnels can be selected by
   an application module.

   Tunnel policies can be classified into two modes:
   Select-seq: The system selects a tunnel for an application program
   based on the tunnel type priorities defined in the tunnel policy.
   Tunnel binding: The system selects only a specified tunnel for an
   application program.

   The two modes are mutually exclusive.
  */
  container tunnelPolicys {



Li, et al.              Expires September 9, 2015               [Page 7]


Internet-Draft      Yang Data Model for Tunnel Policy         March 2015


    list tunnelPolicy {
      min-elements "0";
      max-elements "unbounded";
      key "tunnelPolicyName";

      leaf tunnelPolicyName {
        description
          "Specify tunnel policy name.";
        config "true";
        mandatory "true";
        type "string";
      }

      leaf description {
        description
          "Tunnel policy description(no more than 80 characters).";
        config "true";
        mandatory "false";
        type "string";
      }

      choice tunnelPolicyMode {
        case SpecifyTunnelSelectionSequence { //Tunnel selection sequence
          container tunnelTypeSequences {
            description
              "Specify Tunnel Selection Sequence.";

            leaf-list tunnelType {
              type enumeration {
                enum "gre" {
                  value "0";
                  description "gre:
                    Specifies the GRE tunnel.";
                }
                enum "lsp" {
                  value "1";
                  description "lsp:
                    Specifies the LDP LSP, BGP LSP or static LSP.";
                }
                enum "cr-lsp" {
                  value "2";
                  description "cr-lsp:
                    Specifies the CR-LSP tunnel.";
                }
                //TBD
              }
            }




Li, et al.              Expires September 9, 2015               [Page 8]


Internet-Draft      Yang Data Model for Tunnel Policy         March 2015


            leaf loadBalanceNumber {
              description
                "Specify tunnel load balance number.";
              config "true";
              mandatory "true";
              type uint32 {
                range "1..32";
              }
            }
          }
        }

        case BindApplicationToTunnel { //Bind application to tunnel
          container bindingPolicies {
            list bindingPolicy {
              key "nextHopAddress";
              min-elements "0";
              max-elements "unbounded";

              leaf nextHopAddress {
                description
                  "Specifies the destination address of the tunnel.";
                type inet:ip-address;
              }

              leaf-list tunnelInterface {
                description
                  "Specifies the interface number of the bound
                   tunnel interface.";
                config "true";
                type leafref {
                  path "/if:interfaces/if:interface/if:name";
                }
              }

              leaf ignoreDestinationCheck {
                description
                  "Specifies whether to ignore destination consistency
                   check. If this parameter is enabled, a tunnel
                   policy selects a TE tunnel for route iteration even
                   if the destination address of that TE tunnel is
                   different from the destination address specified in
                   the tunnel policy.";

                config "true";
                default "false";
                type "boolean";
              }



Li, et al.              Expires September 9, 2015               [Page 9]


Internet-Draft      Yang Data Model for Tunnel Policy         March 2015


              leaf downSwitch {
                description
                  "Indicates that the tunnel switchover is enabled.

                   After this parameter is configured, an available
                   tunnel, with the priority as LSP, CR-LSP, and then
                   GRE, is adopted when the bound TE tunnel fails.";

                config "true";
                default "false";
                type "boolean";
              }
            }

          }
        }

      }

    }

  }//End of container tunnelPolicys

  /*
  The tunnel selector is specific to BGP/MPLS IP VPN services (a
  type of VPN service), selecting a tunnel policy for VPNv4/VPNv6
  routes on the backbone network.

  A tunnel selector selects tunnel policies for routes after
  filtering routes based on some route attributes such as the
  route distinguisher (RD) and next hop. This makes tunnel
  selection more flexible.

  A tunnel selector is often used on the autonomous system boundary
  router (ASBR) in inter-AS VPN Option B or the superstratum
  provider edge (SPE) in hierarchy of VPN (HoVPN).
  */
  container tunnelSelectors {
    list tunnelSelector {
      key "name";
      min-elements "0";
      max-elements "unbounded";

      leaf name {
        description
          "Specifies the name of a tunnel selector.";

        config "true";



Li, et al.              Expires September 9, 2015              [Page 10]


Internet-Draft      Yang Data Model for Tunnel Policy         March 2015


        type "string";
      }

      leaf description {

        config "true";
        type "string";
      }

      container tunnelSelectorNodes {
        list tunnelSelectorNode {
          key "nodeSequence";
          min-elements "0";
          max-elements "unbounded";

          leaf nodeSequence {
            description
              "Specifies the index of a node of the tunnel selector.
               When a route-policy is used to filter a route, the
               route first matches the node with the smallest node
               value.";

            config "true";
            type uint32 {
              range "0..65535";
            }
          }

          uses matchMode;

          container matchCondition {
            container matchIPv4NextHop {
              leaf matchType {
                config "true";
                mandatory "true";
                type enumeration {
                  enum "matchNHopPF" {
                    value "0";
                    description "matchNHopPF:";
                  }
                  enum "matchNHopAcl" {
                    value "1";
                    description "matchNHopAcl:";
                  }
                }
              }
              leaf prefixName {
                description



Li, et al.              Expires September 9, 2015              [Page 11]


Internet-Draft      Yang Data Model for Tunnel Policy         March 2015


                  "Specifies the name of an IP address prefix list
                   that is used for route filtering.";

                config "true";
                mandatory "true";
                type "string";
              }
              leaf aclNameOrNum {
                description
                  "";

                config "true";
                mandatory "true";
                type "string";
              }
            }//End of container matchIPv4NextHop

            container matchIPv6NextHop {
              leaf ipv6PrefixName {
                description
                  "Specifies the name of an IPv6 address prefix
                   list.";

                config "true";
                mandatory "true";
                type "string";
              }
            }//End of container matchIPv6NextHops

            container matchRdFilter {
              leaf rdIndex {
                config "true";
                mandatory "true";
                type uint32 {
                  range "1..199";
                }
              }
            }//End of container matchRdFilters
          }//End of container matchCondition

          container applyAction {
             leaf tunnelPolicyName {
               config "true";
               mandatory "true";
               type "string";
             }
          }//End of container applyAction




Li, et al.              Expires September 9, 2015              [Page 12]


Internet-Draft      Yang Data Model for Tunnel Policy         March 2015


        }
      }//End of container tunnelSelectorNodes

    }
  }//End of container tunnelSelectors

  /*
   * augment some bgp vpn functions in bgp module.
   */
  augment "/bgp:bgp-router/bgp:vpnv4/bgp:unicast" {
    leaf tunnelSelectorName {
      description
        "Specifies the name of a tunnel selector.";

      config "true";
      type "string";
    }
  }

  augment "/bgp:bgp-router/bgp:vpnv6/bgp:unicast" {
    leaf tunnelSelectorName {
      description
        "Specifies the name of a tunnel selector.";

      config "true";
      type "string";
    }
  }

}
<CODE ENDS>



6.  IANA Considerations

   This document makes no request of IANA.

7.  Security Considerations

   This document does not introduce any new security risk.

8.  Acknowledgements

   The authors would like to thank Xianping Zhang, Linghai Kong for
   their contributions to this work.





Li, et al.              Expires September 9, 2015              [Page 13]


Internet-Draft      Yang Data Model for Tunnel Policy         March 2015


9.  References

   [I-D.zhdankin-idr-bgp-cfg]
              Alex, A., Patel, K., Clemm, A., Hares, S., Jethanandani,
              M., and X. Liu, "Yang Data Model for BGP Protocol", draft-
              zhdankin-idr-bgp-cfg-00 (work in progress), January 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)", RFC
              6241, June 2011.

Authors' Addresses

   Zhenbin Li
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: lizhenbin@huawei.com


   Shunwan Zhuang
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: zhuangshunwan@huawei.com


   Gang Yan
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: yangang@huawei.com






Li, et al.              Expires September 9, 2015              [Page 14]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/