[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
I2RS working group                                              S. Hares
Internet-Draft                                                    Huawei
Intended status: Standards Track                        October 24, 2014
Expires: April 27, 2015


             An Information Model for Basic Network Policy
                  draft-hares-i2rs-bgp-compare-yang-00

Abstract

   This document contains a comparison of two BGP yang models: draft-
   zhdankin-netmod-bgp-cfg-01 and draft-wang-i2rs-bgp-dm.  The yang
   model in draft-zhdankin-netmod-bgp-cfg-01 is a model focused on
   configuration.  The yang model in draft-wang-i2rs-bgp-dm-00 is
   focused on the status and ephemeral state changes needed for the I2RS
   interface.  The conclusion of comparison is that there little overlap
   except the definitions of common bgp structures.  The draft-wang-
   i2rs-bgp-dm-00 is necessary to fulfil a majority of the requirement
   drawn from the BGP use cases in the I2RS use cases (draft-i2rs-hares-
   usecase-reqs-summary).

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 April 27, 2015.

Copyright Notice

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



Hares                    Expires April 27, 2015                 [Page 1]


Internet-Draft                IM for policy                 October 2014


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definitions and Acronyms  . . . . . . . . . . . . . . . . . .   3
   3.  BGP Yang Draft Comparison . . . . . . . . . . . . . . . . . .   4
   4.  Differences between the drafts  . . . . . . . . . . . . . . .   4
     4.1.  Overlap of configuration draft-zhdankin-netmod-bgp-01 . .   7
     4.2.  Unique configuration for draft-zhdankin-netmod-bgp-01 . .   7
     4.3.  Unique configuration for draft-wang-bgp-dm-00 . . . . . .   8
   5.  Comparison of State needed versus BGP requirements  . . . . .   9
     5.1.  BGP-REQ 01  . . . . . . . . . . . . . . . . . . . . . . .   9
     5.2.  BGP-REQ 02  . . . . . . . . . . . . . . . . . . . . . . .  10
     5.3.  BGP-REQ 03  . . . . . . . . . . . . . . . . . . . . . . .  13
     5.4.  BGP-REQ 04  . . . . . . . . . . . . . . . . . . . . . . .  14
     5.5.  BGP-REQ 05  . . . . . . . . . . . . . . . . . . . . . . .  15
     5.6.  BGP-REQ 06  . . . . . . . . . . . . . . . . . . . . . . .  16
     5.7.  BGP-REQ 07  . . . . . . . . . . . . . . . . . . . . . . .  17
     5.8.  BGP-REQ 08  . . . . . . . . . . . . . . . . . . . . . . .  18
     5.9.  BGP-REQ 09  . . . . . . . . . . . . . . . . . . . . . . .  19
     5.10. BGP-REQ 10  . . . . . . . . . . . . . . . . . . . . . . .  20
     5.11. BGP-REQ 11  . . . . . . . . . . . . . . . . . . . . . . .  22
     5.12. BGP-REQ 12  . . . . . . . . . . . . . . . . . . . . . . .  22
     5.13. BGP-REQ 13  . . . . . . . . . . . . . . . . . . . . . . .  25
     5.14. BGP-REQ 14  . . . . . . . . . . . . . . . . . . . . . . .  25
     5.15. BGP-REQ 15  . . . . . . . . . . . . . . . . . . . . . . .  27
     5.16. BGP-REQ 16  . . . . . . . . . . . . . . . . . . . . . . .  27
     5.17. BGP-REQ 17  . . . . . . . . . . . . . . . . . . . . . . .  28
     5.18. BGP-REQ 18  . . . . . . . . . . . . . . . . . . . . . . .  28
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  29
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  29
   8.  Informative References  . . . . . . . . . . . . . . . . . . .  29
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  30

1.  Introduction

   The Interface to the Routing System (I2RS) provides read and write
   access to the information and state within the routing process within
   routing elements.  The I2RS client interacts with one or more I2RS
   agents to collect information from network routing systems.  The
   processing of collecting information at the I2RS agent may require
   the I2RS Agent to filter certain information, group pieces of




Hares                    Expires April 27, 2015                 [Page 2]


Internet-Draft                IM for policy                 October 2014


   information, or perform actions on the I2rs collected information
   based on specific I2rs policies.

   This draft is a comparison of the following two BGP yang models:
   [I-D.zhdankin-netmod-bgp-cfg], and [I-D.wang-i2rs-bgp-dm].  The
   comparison provides an overview of the differences, overlaps, and
   unique features of each yang model.  The analysis also evaluates
   whether both models or a single model is necessary to satisfy the
   requirements for the BGP use cases found in the
   [I-D.hares-i2rs-usecase-reqs-summary].

   This draft concludes each of these two drafts focuses on the purpose
   each draft was created for (configuration, I2rs status and ephemeral
   state).  The drafts have little overlap outside common definitions
   for some of the BGP functions.  Both drafts reference bgp policy
   outside the basic structures (Prefix-lists, and policy-groups).  Both
   drafts have concepts of AFI level and BGP neighbor level features.
   The status and ephemeral state found in [I-D.wang-i2rs-bgp-dm] is
   necessary to fulfil the BGP use cases found in the
   [I-D.hares-i2rs-usecase-reqs-summary].  Configuration knobs in
   [I-D.zhdankin-netmod-bgp-cfg] were helpful to support these bgp use
   cases, but the lack of state would not allow support of these
   features.  The recommendation is that the two drafts harmonize the
   group structures and continue as two separate drafts for their
   original purpose (config and I2RS).

   One BGP requirement (BGP-REQ18) requires a re-computation of the
   local BGP tables after policies have been modified by the ephemeral
   interface.  The exact methodology of this re-computation could be
   part of ephemeral soft re-configuration.  However, the I2RS WG has
   not determine how ephemeral state acts.  Neither draft has created
   mechanism to do the ephemeral state re-configuration which is wise
   since both the I2RS WG and netmod WG should develop a joint ephemeral
   re-configuration process.

   The rest of this draft is the details so those who desire "sounds
   bytes" level reading may stop reading now.

2.  Definitions and Acronyms

      BGP - Border Gateway Protocol version 4

      CLI: Command Line Interface

      IGP: Interior Gateway Protocol

      I2RS: Interface to (2) Routing system.




Hares                    Expires April 27, 2015                 [Page 3]


Internet-Draft                IM for policy                 October 2014


      Information Model: An abstract model of a conceptual domain,
      independent of a specific implementations or data representation

      INSTANCE: Routing Code often has the ability to spin up multiple
      copies of itself into virtual machines.  Each Routing code
      instance or each protocol instance is denoted as Foo_INSTANCE in
      the text below.

      NETCONF: The Network Configuration Protocol

3.  BGP Yang Draft Comparison

   The authors of [I-D.zhdankin-netmod-bgp-cfg] focused on the
   configuration aspect of BGP (98%+ configuration, 2% status).  The
   [I-D.wang-i2rs-bgp-dm] is focused on the I2RS need for status with a
   small amount of specific I2RS configuration for I2RS needs (95%
   status, 2% config).  The two drafts can be combined together, but
   guidance is needed from the netmod group as the I2RS state is read-
   write ephemeral.

   Why is draft-wang-bgp-dm-00 mostly focused on routes, statistics, and
   state?

   The use cases specified in [I-D.hares-i2rs-usecase-reqs-summary]
   demonstrate a need for the status found in [I-D.wang-i2rs-bgp-dm]
   which includes: bgp-local-rib, bgp-rib-in, bgp-rib-out and all kinds
   of statistics and state, such as protocol-status , bgp-rt-state-info,
   peer-state-info, max-prefix-rcv-limit, etc.  The status is both a the
   AFI state and the BGP peer state (within the AFI).

   Two versions of [I-D.zhdankin-netmod-bgp-cfg] have been released - a
   -00.txt and a -01.txt he second version (-01 version) only updated
   references to netmod and states on the yang modules.  This draft will
   use the -01 version of [I-D.zhdankin-netmod-bgp-cfg],

   The [I-D.wang-i2rs-bgp-dm] was released mistakenly as
   [I-D.hares-i2rs-bgp-dm].  A few corrections to the status fields were
   included in the [I-D.wang-i2rs-bgp-dm].  This draft uses
   [I-D.wang-i2rs-bgp-dm] for the comparison.

4.  Differences between the drafts

   The [I-D.zhdankin-netmod-bgp-cfg] is composed by two parts: BGP
   Router Configuration and Prefix Lists.  BGP Router Configuration
   contains including 3 parts: af-configuration , bgp-neighbors, and
   rpki-config (as shown in figure 1).





Hares                    Expires April 27, 2015                 [Page 4]


Internet-Draft                IM for policy                 October 2014


               module: bgp
                  +--rw bgp-router
                  |  +--rw rpki-config
                  |  +--rw af-configuration
                  |  +--rw bgp-neighbors (98% config, 2% state)
                  +--rw Prefix Lists

            +--rw prefix-lists
            +--rw prefix-list [prefix-list-name]
               +--rw prefix-list-name    string
               +--rw prefixes
                  +--rw prefix [seq-nr]
                     +--rw seq-nr           uint16
                     +--rw prefix-filter
                        +--rw (ip-address-group)?
                        |  .....
                        +--rw action             actions-enum
                        +--rw statistics
                           .....

              Figure 1: draft-zhdankin-netmod-bgp-cfg structure

   The [I-D.wang-i2rs-bgp-dm] is written with a status structure focus
   where manipulation of every concrete route through controlling policy
   and BGP attributes in different BGP address families.  This does not
   contain the rpki-config.  These drafts have ~5% overlap in status/
   configuration.

            module: bgp
                  +--rw bgp-protocols
                  |  +--rw af-status
                  |  |  +--rw bgp-local-rib
                  |  |  +--rw bgp-neighbors (2% config, 98% state)
                  |  |  |  +--rw policy-in
                  |  |  |  +--rw policy-out
                  |  |  |  +--rw peer-state
                  |  |  |  +--rw bgp-rib-in
                  |  |  |  +--rw-bgp-rib-out

             module: ietf-pcim
                  +--rw Policy-sets
                     +--rw Policy-groups
                        +--rw Policy-Rules

           Figure 2 draft-i2rs-wang-bgp-dm-00






Hares                    Expires April 27, 2015                 [Page 5]


Internet-Draft                IM for policy                 October 2014


   o  The focus is status-based based on AFI, but includes local-rib and
      BGP neighbor's policy (in and out), peer state, rib-in, and rib-
      out.

   o  prefix list policy being covered inline
      ([I-D.zhdankin-netmod-bgp-cfg]) versus in the draft-hares-bnp-
      im-01 which uses the policy descriptions created by RFC3060,
      RFC3460, and other policy work.  This methodology is being
      utilized by the OpenDaylight Group policy as well.

   o  Redistribution being done inline ([I-D.zhdankin-netmod-bgp-cfg])
      as a configuration.  The draft-i2rs-wang-bgp-dm-00 did not
      configure af-configuration.

   o  [I-D.zhdankin-netmod-bgp-cfg] claims to list the aspath path was
      well as the prefix configuration, but this section is missing in
      the draft.  The example is the expression of as-path in draft-
      i2rs-wang-bgp-dm-00 is a actually string value of as-path which is
      one of attributes in BGP route rather not a Boolean value as used
      in [I-D.zhdankin-netmod-bgp-cfg].

   o  The order of specifying the protocol elements is different in some
      cases due to the status versus configuration focus.  For example,
      limiting maximum prefixes and maximum paths is done in a slightly
      different way.  A second example is that community and cluster
      strings.

   Below is an example of the AF-status structure found in draft-bgp-
   dm-00

           module: bgp-protocol
              +--rw bgp-protocol
                 +--rw bgp-ipv4-uni-instance
                 |  +--rw bgp-local-rib
                 |  +--rw bgp-peer-list
                 |     +--rw bgp-rib-in
                 |     +--rw bgp-rib-out
                 ......
               +--rw bgp-evpn-instance
                 |  +--rw bgp-local-rib
                 |  +--rw bgp-peer-list
                 |     +--rw bgp-rib-in
                 |     +--rw bgp-rib-out

                 figure bgp-3






Hares                    Expires April 27, 2015                 [Page 6]


Internet-Draft                IM for policy                 October 2014


4.1.  Overlap of configuration draft-zhdankin-netmod-bgp-01

   The draft-zhdankin-netmod-bgp-01 and draft-wang-i2rs-bgp-dm-00 both
   contain at the protocol level:

           module: bgp
             +--rw bgp router [bgp protocol]
                 +--rw local-as-number?    unit32
                 +--rw local-as-identifier inet:ip-address (zhdankin)
                  +--rw router-id              inet:ip-address (wang)
                  ...
             figure bgp-3

   The module contains at the peer level the association of a peer with
   an AS

   [draft-zhdank-netmod-bgp-01]

          +--rw bgp-neighbors* [AS-number]
             +--rw as-number
             +--rw (peer-address-type)?
               . . .
             +--rw prefix-list     prefix-list-ref
             +--default-action?     enumeration (permit/deny)

   [[I-D.wang-i2rs-bgp-dm]]

          +--rw bgp-peer-list* [bgp-peer-name]
             +--rw peer-session-address?
                . . .
             +--rw peer-name
             +--ro peer-type
             +--rw bgp-policy-in       policy-set-name
                +--rw bgp-policy-out   policy-set-name

          figure bgp-5

4.2.  Unique configuration for draft-zhdankin-netmod-bgp-01

   [I-D.zhdankin-netmod-bgp-cfg] contains the unique configuration for
   RPKI, AF-configuration and BGP peers.  A sample of the unique
   configuration for the AF-configuration is:

   o  cost-communities

   o  BGP-damping

   o  route-aggregation - this is policy so we could easily add,



Hares                    Expires April 27, 2015                 [Page 7]


Internet-Draft                IM for policy                 October 2014


   o  reflector clients

   o  best external advertisement

   o  aggregate timer (sending out aggregate times)

   o  flags to compare router-id as part of bgp bestpath selection

   o  MED-confederation

   o  administrative distance (cisco)

   o  packet forwarding over multiple paths

   o  allowances for slow peers

   o  BGP multi-path (ECMP peers)

   o  external fail-over for peer

   o  AS confederations

   o  deterministic MEDs

   o  Graceful-restart

   o  BGP AS listener only

   o  Logging of neighbor changes

   o  Transport options for BGP

   o  Removal of private AS

4.3.  Unique configuration for draft-wang-bgp-dm-00

   The following variables were included in [I-D.hares-i2rs-bgp-dm], but
   not in [I-D.zhdankin-netmod-bgp-cfg]:

   o  protocol-status (ro) - needed for I2RS information

   o  shutdown protocol - needed if I2RS is to shutdown bgp protocol,

   o  AFI based local-rib

   o  BGP-peer-status information - [I-D.zhdankin-netmod-bgp-cfg] has
      number of updates, but less status information in the draft.




Hares                    Expires April 27, 2015                 [Page 8]


Internet-Draft                IM for policy                 October 2014


   The following pieces are needed by I2RS:

   o  At instance level, bgp-instance-name, bgp-instance-create (to
      create bgp process), bgp-instance-type (to specify what type to
      create),

   o  At AFI level in local rib, bgp_route_create (to add bgp route for
      i2rs) and bgp_state_info for status updates.

   o  At peer level, there must be maximum prefixes per peer (received
      and transmit), high water/low water prefix counts, and average
      number of prefixes;

   o  Versions for instance publishing,

   o  Details on path attributes: ASpath strings, community and extend-
      community attribute, cluster lists, aggregation, atomic
      aggregator;

   o  Mechanisms for logging/publishing information

5.  Comparison of State needed versus BGP requirements

5.1.  BGP-REQ 01

   BGP-REQ01 requirement is: I2RS client/agent exchange SHOULD support
   the read, write and quick notification of status of the BGP peer
   operational state on each router within a given Autonomous System
   (AS).  This operational status includes the quick notification of
   protocol events that proceed a destructive tear-down of BGP session

   [I-D.zhdankin-netmod-bgp-cfg] contains the following status related
   to each peer's bgp operational state.

   module: bgp

      +--bgp-router
      + . . .
      +--rw bgp-neighbors
         +--rw peer-address
         |  . . .
         +--rw bgp-neighbor-state
            +--rw bgp-peer-admin-status  enumeration
            +--rw in-lastupdatetime
         Figure bgp-6

   Conclusion: [I-D.zhdankin-netmod-bgp-cfg] does not provide support
   required by I2RS.



Hares                    Expires April 27, 2015                 [Page 9]


Internet-Draft                IM for policy                 October 2014


   [I-D.wang-i2rs-bgp-dm] contains the following status related to each
   peer's BGP operational state:

   module: bgp

  +--bgp-protocol
   +  . . .
   +rw bgp-ipv4-uni-instance (af-instance)
        +--rw bgp-instance-name
        |   . . .
        +--rw bgp-local-rib
        | . . .
        +--rw bgp-peer-list [bgp-peer-name]
        |  . . .
        |   +--rw peer-state-info
        |   |  +--rw peer-current-state?   peer-state
        |   |  |--rw peer-last-state?       peer-state
        |   |  |--ro peer-down-reason
        |   |  |--ro error code?  enumeration
        |   |  |  +--ro (sub-error-code-type)?
        |   |  |  |  +--: (head-error-sub-code)
        |   |  |  |      +--ro head-error-sub-value? enumeration
        |   |  |  |  +--: (open-error-sub-code)
        |   |  |  |      +--ro open-error-sub-value? enumeration
        |   |  |  |  +--: (update-error-sub-code)
        |   |  |  |      +--ro-update-error-sub-value? enumeration
        |   |  |  |  +--: (route-refresh-error-sub-code)
        |   |  |  |      +--ro-route-refresh-error-sub-value? enumeration

      figure bgp-7

   Conclusion: [I-D.wang-i2rs-bgp-dm] provides for this requirement.

5.2.  BGP-REQ 02

   BGP-REQ02 requirement is: "I2RS client SHOULD be able to push BGP
   routes with custom cost communities to specific I2RS agents on BGP
   routers for insertion in specific BGP Peer(s) to aid Traffic
   engineering of data paths.  These routes SHOULD be tracked by the
   I2RS Agent as specific BGP routes with customer cost communities.
   These routes (will/will not) be installed via the RIB-Info."

   Status:

   [I-D.zhdankin-netmod-bgp-cfg] supports configuration related to
   address family control of these features, but it does not have a
   route level support.  The AFI family configuration is shown in
   context below:



Hares                    Expires April 27, 2015                [Page 10]


Internet-Draft                IM for policy                 October 2014


   module: bgp
      +--rw bgp-router
      |  +--rw local-as-number?       uint32
      |  +--rw local-as-identifier?   inet:ip-address
      |  +--rw rpki-config
      |  |  .....
      |  +--rw af-configuration
      |  |  +--rw ipv4
      |  |  |   +--rw mdt
      |  |  |    . . .
      |  |  |   +--rw multicast
      |  |  |   |   +--rw bgp
      |  |  |   |   |  +--rw bgp-af-config
      |  |  |   |   |  |  . . .
      |  |   |  |   |  |  +--rw bestpath
      |  |   |  |   |  |  |  +--case as-path:
      |  |   |  |   |  |  |      ignore-as-path boolean
      |  |   |  |   |  |  |  +--case compare-routerid
      |  |   |  |   |  |  |  |   ignore-routerid boolean
      |  |   |  |   |  |  |  + case cost-community
      |  |   |  |   |  |  |  |   ignore-cost-community Boolean
      |  |   |  |   . . .
      |  |   |  +--rw unicast
      |  |   |  |  +--rw bgp
      |  |   |  |      +--rw bgp-af-config
      |  |   |  |      |   . . .
      |  |   |  |      |  +--rw bestpath
      |  |   |  |      |  |   . . .
      |  |   |  |      |  |    +--case cost-community
      |  |   |  |   |  |  |  |   ignore-cost-community Boolean
      |  |   |  +--rw unicast
      |  |   |  |  +--rw bgp
      |  |   |  |      +--rw bgp-af-config
      |  |   |  |      |   . . .
      |  |   |  |      |  +--rw bestpath
      |  |   |  |      |  |   . . .
      |  |   |  |      |  |    +--case cost-community
      |  |   |  |   |  |  |  |   ignore-cost-community Boolean

   (replicated for appropriate AFIs)
    Figure bgp-8

   Conclusion: This [I-D.zhdankin-netmod-bgp-cfg]  does not adequately
   support the I2RS BGP REQ02. .

   [I-D.wang-i2rs-bgp-dm] does support per-route configuration tagging
   of route with customer community in local BGP rib, and per peer
   AdjRibIn and adjRibout



Hares                    Expires April 27, 2015                [Page 11]


Internet-Draft                IM for policy                 October 2014


     +--bgp-protocol
      +  . . .
      +rw bgp-ipv4-uni-instance (af-instance)
           +--rw bgp-instance-name
           | . . .
           +--rw afi
           +--rw safi
           +--rw bgp-local-rib
           |  +--rw bgp-route-list* [ipv4-route ipv4-prefix-length]
           |  |  +--rw ipvr-route inet:ipv4-prefix
           |  |  +--rw ipv4-prefix-length  uint8
           |  |  +--rw  route-type? enumeration
           |  |  +--rw bgp-attribute-list*
           |  |  |  +--rw bgp-origin?
           |  |  |   . . .
           |  |  |  +--rw bgp-extcommattr
           |  |  |  |  +--rw custom-community
           |  |  |  |  |  +--rw  valid boolean
           |  |  |  |  |  +--rw  insertion point uint8
           |  |  |  |  |  +--rw  community-id     uint8
           |  |  |  |  |  +--rw  cost-id           uint32
           |  |  |  |  +--rw useextcommsize uint16
           |  |  |  |  +--rw ulrefcount?     uint16
           |  |  |  |  +--rw excmmattr-value string
           |  +--rw bgp-peer-list* (bgp-peer-name)
           |  |   . . .
           |  |  +--rw  bgp-rib-in
           |  |  |  +--rw bgp-rib-in-list*  (ipv4 route
           |  |  |  |       ipvr-prefix-length route-distinguisher)
           |  |  |  |   +--rw ipv4-route  inet_ipv4-prefix
           |  |  |  |   |  +--rw bgp-attribute-list*
           |  |  |  |   |  |  . . .
           |  |  |  |   |  |  +--rw bgp-extcommattr
           |  |  |  |   |  |  |  +--rw custom-community
           |  |  |  |   |  |  |  +--rw  valid boolean
           |  |  |  |   |  |  |  +--rw  insertion point uint8
           |  |  |  |   |  |  |  +--rw  community-id     uint8
           |  |  |  |   |  |  |  +--rw  cost-id           uint32
           |  |  |  |   |  |  |  +--rw useextcommsize uint16
           |  |  |  |   |  |  |  +--rw ulrefcount?     uint16
           |  |  |  |   |  |  | +--rw excmmattr-value string
           |  |  |   . . .
           |  |  +--rw  bgp-rib-out
           |  |  |  +--rw bgp-rib-out-list*  (ipv4 route
           |  |  |  |       ipv4-prefix-length route-distinguisher)
           |  |  |  |   +--rw ipv4-route  inet_ipv4-prefix
           |  |  |  |   |  +--rw bgp-attribute-list*
           |  |  |  |   |  |  . . .



Hares                    Expires April 27, 2015                [Page 12]


Internet-Draft                IM for policy                 October 2014


           |  |  |  |   |  |  +--rw bgp-extcommattr
           |  |  |  |   |  |  |  +--rw custom-community
           |  |  |  |   |  |  |  +--rw  valid boolean
           |  |  |  |   |  |  |  +--rw  insertion point uint8
           |  |  |  |   |  |  |  +--rw  community-id     uint8
           |  |  |  |   |  |  |  +--rw  cost-id           uint32
           |  |  |  |   |  |  |  +--rw useextcommsize uint16
           |  |  |  |   |  |  |  +--rw ulrefcount?     uint16
           |  |  |  |   |  |  | +--rw excmmattr-value string

       Figure bgp-9

   Conclusion: [I-D.wang-i2rs-bgp-dm] needed as well as
   [I-D.zhdankin-netmod-bgp-cfg].

5.3.  BGP-REQ 03

   BGP-REQ03 requirement is: "I2RS client SHOULD be able to track via
   read or notifications all Traffic engineering changes applied via
   I2RS agents to BGP route processes in all routers in a network."

   Discussion on Requirement: Traffic engineering changes can include:
   ORFs (RFC5291, 5292), flows specifications (RFC5575, draft-ietf-), TE
   performance (draft-ietf-idr-te-pm-bgp-01), traffic-engineering state
   (draft-ietf-idr-te-lsp-distribution), and route target filtering.
   Additional input needs to be obtained from the i2rs WG on what
   constitutes traffic engineering.

   Status:

   [I-D.zhdankin-netmod-bgp-cfg] has the following potential
   configuration support:

   o  on most af configurations: af-bgp_config container supports
      allowing the following features: add-path, best-external,
      aggregation timer, damping, propagating dmz-link-bw, and
      redistributing iBGP routes into IGP.

   o  af rtfilters - AFI for rtfilters.

   These features do not provide any of the traffic engineering input.

   [I-D.wang-i2rs-bgp-dm]: has per route status tracking for the local-
   rib associated with each afi, and the virtual bgp AdjRibIn and BGP
   AdjRibOut for each peer.  Each route has a route type that include
   route types for all valid NLRIs which includes: ipv4, ipv6, labeled
   ipv4, labeled ipv6, flows, link-state (ls) data, evpn, mvpn, vpls,
   l2vpn-singaling-nlri, rt-constraint, pw-route.



Hares                    Expires April 27, 2015                [Page 13]


Internet-Draft                IM for policy                 October 2014


      +--bgp-protocol
      +  . . .
      +rw bgp-ipv4-uni-instance (af-instance)
           +--rw bgp-instance-name
           | . . .
           +--rw afi
           +--rw safi
           +--rw bgp-local-rib
           |  +--rw bgp-route-list* [ipv4-route ipv4-prefix-length]
           |  |  +--rw ipvr-route inet:ipv4-prefix
           |  |  +--rw ipv4-prefix-length  uint8
           |  |  +--rw  route-type? enumeration
           |  |  +--rw  route-admin-distance uint16
           |  |   ....
           |  |  +--rw bgp-attribute-list*
           |  |  |  +--rw bgp-origin?

       Figure bgp-10

   What needs to be added: Once the I2RS WG specifies what traffic
   engineering flags to watch on the BGP routes at AFI local-rib level
   or the BGP-peer routes (AdjRibIn, AdjRibOut), then the
   [I-D.wang-i2rs-bgp-dm] can be augmented.

   If the I2RS WG specifies configurations for traffic engineering at
   the AFI or BGP-peer level, these ephemeral status will either need to
   be added to draft-want-i2rs-bgp-dm-00 status or the peer.

5.4.  BGP-REQ 04

   BGP-REQ04 requirement is: "I2RS Agents SHOULD support identification
   of routers as BGP ASBRs, PE routers, and IBGP routers."

   [I-D.zhdankin-netmod-bgp-cfg]: No status provides a summation of the
   BGP roles a BGP routing instance.  The BGP-neighbor structure does
   not provide a role structure.

   [I-D.wang-i2rs-bgp-dm]:













Hares                    Expires April 27, 2015                [Page 14]


Internet-Draft                IM for policy                 October 2014


   module: bgp-protocol
      +--rw bgp-protocol
         +--rw router-id?   inet:ip-address
         +--rw as-number?    uint32
         + . . .
         +--ro bgp-role?     enumeration
         +--rw af instance
         |  +--rw bgp-local-rib
         |   . . .
         |  +--rw bgp-peer-list* [bgp-peer-name]
         |  |  +--rw bgp peer-session
         |  |  +--rw bgp-peer-name
         |  |  +--bgp-peer-type?  enumeration

          Figure bgp-11


   The enumeration for bgp-role is asbr, pe, ibgp,rr where the role is a
   bit mask indicating that one or more peer has this role on the
   protocol instance.

   The enumeration for bgp-peer-type is asbr, ibgp, rr, rr-client, pe,
   ce, bgp-vendor-types;

   Conclusion: [I-D.wang-i2rs-bgp-dm] supports BGP-REQ 04

5.5.  BGP-REQ 05

   BGP-REQ05 is: I2RS client-agent SHOULD support writing traffic flow
   specifications to I2RS Agents that will install them in associated
   BGP ASBRs and the PE routers.

   Status: BGP-REQ05 is the ability to read the roles within a bgp
   protocol instances at protocol level and at peer level, and to write
   routes with traffic flow specifications to AFI database and
   (optionally) bgp-peer AdjRibOut.

   BGP-REQ 4 showed that the [I-D.wang-i2rs-bgp-dm] supports the
   identification of BGP ASBR and PE routers at a peer level.  It also
   has a quick summary of the roles of BGP routers at the protocol
   level.  [I-D.wang-i2rs-bgp-dm] specifies a a route-type variable
   within each route in the AFI local-rib or the BGP Peers routes
   (AdjRibIn, AdjRibOut), and this route-type includes a enumeration
   variable for flows.

   [I-D.wang-i2rs-bgp-dm]





Hares                    Expires April 27, 2015                [Page 15]


Internet-Draft                IM for policy                 October 2014


   module: bgp protocol
      +--bgp-protocol
      +  . . .
      +rw bgp-ipv4-uni-instance (af-instance)
           +--rw bgp-instance-name
           | . . .
           +--rw afi
           +--rw safi
           +--rw bgp-local-rib
           |  +--rw bgp-route-list* [ipv4-route ipv4-prefix-length]
           |  |  +--rw ipv4-route inet:ipv4-prefix
           |  |  +--rw ipv4-prefix-length  uint8
           |  |  +--rw  route-type? enumeration

       Figure bgp-12

   Conclusion: [I-D.wang-i2rs-bgp-dm] supports BGP-REQ-05.

5.6.  BGP-REQ 06

   BGP-REQ06 requirement is: "I2RS Client SHOULD be able to track flow
   specifications installed within a IBGP Cloud within an AS via reads
   of BGP Flow Specification information in I2RS Agent, or via
   notifications from I2RS agent."

   Status: As section 3.5.5 on BGP-REQ04 shows [I-D.wang-i2rs-bgp-dm]
   supports the tracking of flow-specification routes associated with
   the local-rib for a AFI or a BGP Peer.

   [I-D.wang-i2rs-bgp-dm]:





















Hares                    Expires April 27, 2015                [Page 16]


Internet-Draft                IM for policy                 October 2014


 module: bgp protocol
    +--bgp-protocol
    +  . . .
    +rw bgp-ipv4-uni-instance (af-instance)
         +--rw bgp-instance-name
         |    . . .
         |  +--rw bgp-local-rib
         |  |  +--rw bgp-rib-in-list*  (ipv4 route ipv4-prefix-length
         |  |  |  +--rw ipv4-route inet:ipv4-prefix
         |  |  |  +--rw ipv4-prefix-length  uint8
         |  |  |  +--rw  route-type? enumeration
         |  |  . . .
         |  +--rw bgp-peer-list* (bgp-peer-name)
         |  |  +--rw bgp-peer-session addres
         |  |  +--rw bgp-peer-name
         |  |  +--rw bgp-peer-type
         |  |  +--rw  bgp-rib-in
         |  |  |  +--rw bgp-rib-in-list*  (ipv4 route ipv4-prefix-length
         |  |  |  |  +--rw ipv4-route inet:ipv4-prefix
         |  |  |  |  +--rw ipv4-prefix-length  uint8
         |  |  |  |  +--rw  route-type? enumeration

      Figure bgp-13

5.7.  BGP-REQ 07

   BGP-REQ07 requirement is: I2RS client-agent exchange SHOULD support
   the I2RS client being able to prioritize and control BGP's
   announcement of flow specifications after status information reading
   BGP ASBR and PE router's capacity.  BGP ASBRs and PE routers
   functions within a router MAY forward traffic flow specifications
   received from EBGP speakers to I2RS agents, so the I2RS Agent SHOULD
   be able to send these flow specifications from EBGP sources to a
   client in response to a read or notification.

   Discussion: The I2RS WG needs to provide additional input on what
   status information is key to track for the BGP ASBR and PE router's
   capacity.

   Status:

   [I-D.zhdankin-netmod-bgp-cfg] has prefix-lists which can allow or
   deny prefixes based on the NLRI family.  This feature allows the
   control of routes via the flow specification NLRI.  However peer
   status does not provide an easy way to detect BGP ASBR or PE status,
   or the number of routes.





Hares                    Expires April 27, 2015                [Page 17]


Internet-Draft                IM for policy                 October 2014


   [I-D.wang-i2rs-bgp-dm] has the ability to specify flexible policy via
   policy-sets for inbound and outbound policy that can filter based on
   prefix or any match sequence within the route and peer.  This draft
   also provides a data model that tracks track which peers are ASBR and
   PEs at the peer level via bgp-peer-type and at the protocol level via
   bgp-role (as described above).  This draft also specifies
   administrative distance on route structures in the per AFI bgp-local-
   rib or in the peers routes per AFI.

   module: bgp protocol
      +--bgp-protocol
      +  . . .
      +rw bgp-ipv4-uni-instance (af-instance)
           +--rw bgp-instance-name
           |    . . .
           |  +--rw bgp-local-rib
           |  |  +--rw bgp-rib-in-list*  (ipv4 route ipv4-prefix-length
           |  |  |  +--rw ipv4-route inet:ipv4-prefix
           |  |  |  +--rw ipv4-prefix-length  uint8
           |  |  |  +--rw  route-type? enumeration
           |  |  |  +--rw  route-admin-distance  uint32
           |  |  |  +--rw  route-rpki-origin-validity
           |  |  |  |  +--rw  rt-rpki-origin-valid Boolean
           |  |  |  |  +--rw  rt-rpki-ref  rpki-validity-ref


   figure bgp-14

5.8.  BGP-REQ 08

   BGP-REQ08 requirement is: "I2RS Client SHOULD be able to read BGP
   route filter information from I2RS Agents associated with legacy BGP
   routers, and write filter information via the I2RS agent to be
   installed in BGP RR.  The I2RS Agent SHOULD be able to install these
   routes in the BGP RR, and engage a BGP protocol action to push these
   routers to ASBR and PE routers."

   Discussion: The router filter information is determined to be the
   prefix-filters or policy-filters associated with BGP routes found in
   the AFI based bgp-local-rib or peer's structures (AdjRibIn,
   AdjRibout).

   Status:

   [I-D.zhdankin-netmod-bgp-cfg] has prefix-lists which can allow or
   deny prefixes based on the NLRI.  This yang model does not provide an
   easy way to detect peers as taking on the BGP RR, ABSR, and PE.  (See
   section 3.3 and yang model for the prefix-list descriptions).



Hares                    Expires April 27, 2015                [Page 18]


Internet-Draft                IM for policy                 October 2014


   [I-D.wang-i2rs-bgp-dm] has the ability to specify flexible policy via
   policy-groups or policy sets for inbound and outbound policy that can
   filter based on prefix or any match sequence within the route and
   peer.  This draft also provides a data model that tracks track which
   peers are ASBR, PEs, and RR at the peer level via bgp-peer-type and
   at the protocol level via bgp-role.  (Please see draft-ietf-i2rs-
   hares-bnp-info-model and draft-itef-hares-i2rs-bnp-dm for full
   description).

5.9.  BGP-REQ 09

   BGP-REQ09: I2RS client(s) SHOULD be able to request the I2RS agent to
   read BGP routes with all BGP parameters that influence BGP best path
   decision, and write appropriate changes to the BGP Routes to BGP and
   to the RIB-Info in order to manipulate BGP routes.

   Discussion: Best-path is considered when policy evaluation is the
   same.  The best path could be considered based on origin-as, as-path,
   router-id, cost-community. igp-metric, med-confed, missing-as-med,
   rpki-origin validity.  This requirement needs to be refined to
   specify an initial set of BGP parameters that influence BGP best path
   decisions.

   Status:

   [I-D.zhdankin-netmod-bgp-cfg] configures the parameters that
   influence BGP bestpath decisions.  However, this draft does not
   provide these parameters within each bgp-route.

   [I-D.wang-i2rs-bgp-dm] provides the per route status on origin-as,
   as-path, router-id, cost-community, igp-metric, MED, and rpki-origin
   validity.  This route status is on the AFI level local-rib and the
   per peer routes (AdjRibIn, AdjRibOut).


















Hares                    Expires April 27, 2015                [Page 19]


Internet-Draft                IM for policy                 October 2014


   module: bgp protocol
      +--bgp-protocol
      +  . . .
      +rw bgp-ipv4-uni-instance (af-instance)
           +--rw bgp-instance-name
           |    . . .
           |  +--rw bgp-local-rib
           |  |  +--rw bgp-rib-in-list*  (ipv4 route ipv4-prefix-length
           |  |  |  +--rw ipv4-route inet:ipv4-prefix
           |  |  |  +--rw ipv4-prefix-length  uint8
           |  |  |  +--rw  route-type? enumeration
           |  |  |  +--rw  route-admin-distance  uint32
           |  |  |  +--rw  route-rpki-origin-validity
           |  |  |  |  +--rw  rt-rpki-origin-valid Boolean
           |  |  |  |  +--rw  rt-rpki-ref  rpki-validity-ref

      figure bgp-15

5.10.  BGP-REQ 10

   BGP-REQ10 requirement is: I2RS client SHOULD be able instruct the
   I2RS agent(s) to notify the I2RS client when the BGP processes on an
   associated routing system observe a route change to a specific set of
   IP Prefixes and associated prefixes.  Route changes include: 1)
   prefixes being announced or withdrawn, 2) prefixes being suppressed
   due to flap damping, or 3) prefixes using an alternate best-path for
   a given IP Prefix.  The I2RS agent should be able to notify the
   client via publish or subscribe mechanism.

   Discussion: RFC5277 indicates that a netconf-filter looks for
   specific data value and data item.  Therefore, the I2RS client must
   specify the whether the data is in the AFI based local-rib or the BGP
   (AdjRibIn, AdjRibOut) and the specific values.  The specific values
   indicated by BGP-REQ-10 are prefixes with: announce flags, withdrawn
   flags, flap-dampened suppression flags, on-best-path-external or
   rejected due to best-path external.  This comparison assumes the
   RFC5277 paths can be made to work for the ephemeral storage.

   Sorting of these filters into critical or normal status requests is
   not considered in this comparison as adding this upon a non-existent
   definition of ephemeral services seems futile.

   [I-D.zhdankin-netmod-bgp-cfg] configures the parameters that
   influence BGP bestpath decisions or flap damping.  However, this
   draft does not provide these parameters within each bgp-route.

   [I-D.wang-i2rs-bgp-dm]:




Hares                    Expires April 27, 2015                [Page 20]


Internet-Draft                IM for policy                 October 2014


    +--rw ipv4-route            inet:ipv4-prefix
    +--rw ipv4-prefix-length    uint8
    +--rw bgp-route-type?       enumeration
    +--rw bgp-attribute-list
        ...
    +--ro bgp-rt-state-in
       +--ro rib-current-state?      rib-state-def
       +--ro rib-last-state?         rib-state-def
       +--ro rib-rejected-reason?    enumeration
       +--ro not-preferred-reason?   enumeration
    . . .

     typedef rib-state-def {
       type enumeration {
         enum "active";
         enum "in-active";
         enum "primary";
         enum "backup";
         enum "suppressed (flap dampened)"
         enum "suppressed non-flap dampen"
         enum "active on alternate best path"
   }

   Leaf not-preferred-reason {
       Type enumeration {
           enum "peer-address";
           enum "router-id";
           enum "cluster-list-length";
           enum "igp-metric";
           enum "peer-type";
           enum "origin";
           enum "weight-or-preferred-value";
           enum "local-preference";
           enum "route-type";
           enum "as-path-length";
           enum "med";
           enum "flap-dampened route";  [new]
           enum "not-this-path-prefix-uses-alternate-best-path"; [new]
           enum "overlapping-route-marked-to-remove"; [new]  (BGP-REQ17)
      }

   Figure bgp 16

   Conclusion: [I-D.wang-i2rs-bgp-dm] status is needed for this BGP-
   REQ10.






Hares                    Expires April 27, 2015                [Page 21]


Internet-Draft                IM for policy                 October 2014


5.11.  BGP-REQ 11

   BGP-REQ11 requirement is the "I2RS client SHOULD be able to read BGP
   route information from BGP routers on routes in received but rejected
   from ADJ-RIB-IN due to policy, on routes installed in ADJ-RIB-IN, but
   not selected as best path, and on route not sent to IBGP peers (due
   to non-selection)."

   Discussion: As discussed in BGP-REQ10, RFC5277 indicates that a
   netconf-filter looks for specific data value and data item.
   Therefore, the I2RS client must specify the whether the data is in
   the AFI based local-rib, or the BGP (AdjRibIn, AdjRibOut) and the
   specific values

   Status:

   [I-D.zhdankin-netmod-bgp-cfg] configures policy that indicates what
   routes are filtered, but it does not provide the status parameter on
   each BGP route.

   [I-D.wang-i2rs-bgp-dm]: Shows that the status can be tracked in the
   AFI based bgp local-rib and the per AFI per peer AdjRibIn and AdjRib
   out.

   Conclusion: [I-D.wang-i2rs-bgp-dm] status is needed for BGP-REQ10.

5.12.  BGP-REQ 12

   BGP-REQ12 requirement is: the "I2RS client SHOULD be able to request
   the I2RS agent to read installed BGP Policies."

   Discussion: BGP policies can be inbound filters, ACLs, or route maps.
   Three yang drafts take different approaches to the filters: draft-
   bogdanovic-netmod-acl-model-02, [I-D.zhdankin-netmod-bgp-cfg], and
   draft-hares-2rs-bnp-dm-01.

   The draft-bogdanovic-netmod-acl-model-02 takes the approach of
   extending the firewall ACLs, and suggests that proprietary methods be
   used to extend this to the ranges needed for BGP policy.  The index
   to the ACLS is the rule-name.  For a single prefix accept/deny the
   generic ACL policy may be sufficient.  Prefix ranges or the ability
   to set custom cost communities or other extended communities must use
   a proprietary vendor's model.

   The [I-D.zhdankin-netmod-bgp-cfg] (10/1/2014) suggests prefix-list
   matches that should provide prefix matches an index of route ID
   number (uint16).  The prefix matches can be either ip-address,
   prefix, host address, or prefix-range.  The only actions taken are



Hares                    Expires April 27, 2015                [Page 22]


Internet-Draft                IM for policy                 October 2014


   accept or deny the prefix.  The usage statistics contains only the
   "hit count" for the usage of the prefix mask.

   The [I-D.wang-i2rs-bgp-dm] (10/23/2014) provides a policy link to the
   Basic Network Policy (draft-hares-i2rs-bnp-info-model/draft-hares-
   i2rs-bnp-dm-01) which provides ordered list of policy rules that can
   provide sequences of match, actions (accept/deny, set variable, and
   modify).  A group of these policy rules is called a policy group
   which can be named.

   This model uses the policy definitions concept is also found in the
   Policy Core Information Model (PCIM) (RFC3060) and the Quality of
   Service QoS) Policy Information Model (QPIM)(RFC3644) and policy
   based routing.  ACL-based policy (draft-bogdanovic-netmod-acl-model-
   02), and prefix-list policy (accept/deny) can be one of the policy
   rule extensions.  The [I-D.zhdankin-netmod-bgp-cfg] can provide a
   second policy rule extension.

   The section below provides the specific modeling parameters for each
   draft.

   draft-bogdanovic-netmod-acl-model-02

   +--rw access-list-entry* [rule-name]
      +--rw rule-name        string
      +--rw matches
      |  +--rw (ace-type)?
      |  |  +--:(ace-ip)
      |  |  |  +--rw source-port-range
      |  |  |  |  +--rw lower-port    inet:port-number
      |  |  |  |  +--rw upper-port?   inet:port-number
      |  |  +--rw destination-port-range
      |  |  |  |  +--rw lower-port    inet:port-number
      |  |  |  |  +--rw upper-port?   inet:port-number
      |  |  |  +--rw dscp?             inet:dscp
      |  |  |  +--rw ip-protocol?     uint8
      |  |  |  +--rw (ace-ip-version)?
      |  |  |     +--:(ace-ipv4)
      |  |  |     |  +--rw destination-ipv4-address?
                        inet:ipv4-prefix
      |  |  |     |  +--rw source-ipv4-address?
                        inet:ipv4-prefix
      |  |  |     +--:(ace-ipv6)
      |  |  |        +--rw destination-ipv6-address?
                          inet:ipv6-prefix
      |  |  |        +--rw source-ipv6-address?
                         inet:ipv6-prefix
      |  |  |        +--rw flow-label?   inet:ipv6-flow-label



Hares                    Expires April 27, 2015                [Page 23]


Internet-Draft                IM for policy                 October 2014


      |  |  +--:(ace-eth)
      |  |     +--rw destination-mac-address?
                         yang:mac-address
      |  |     +--rw destination-mac-address-mask?
                         yang:mac-address
      |  |     +--rw source-mac-address?
                        yang:mac-address
      |  |     +--rw source-mac-address-mask?
                        yang:mac-address
      |  +--rw input-interface?                string
      |  +--rw absolute
      |     +--rw start?    yang:date-and-time
      |     +--rw end?      yang:date-and-time
      |     +--rw active?   boolean
      |     +--rw actions
      |  +--rw (packet-handling)?
      |     +--:(deny)
      |     |  +--rw deny?     empty
      |     +--:(permit)
      |        +--rw permit?   empty
      +--ro ace-oper-data
      +--ro match-counter?   ietf:counter64

   Figure bgp-17

   [I-D.zhdankin-netmod-bgp-cfg] (10/1/2014)

    +--rw prefix-lists
      +--rw prefix-list [prefix-list-name]
        +--rw prefix-list-name    string
          +--rw prefixes
            +--rw prefix [seq-nr]
              +--rw seq-nr uint16
                +--rw prefix-filter
                  +--rw (ip-address-group)?
                  |  (cases
                 +--rw action  actions-enum
                 +--rw statistics
                     ..
   Figure bgp-18

   [I-D.wang-i2rs-bgp-dm]









Hares                    Expires April 27, 2015                [Page 24]


Internet-Draft                IM for policy                 October 2014


   module: bgp_protocol
   +--rw bgp-protocol
      + af config
        +--rw bgp-policy-in   policy-group-ref
        +--rw bgp-policy-out  policy-group-ref

   Figure bgp-19

   draft-bnp-i2rs-bnp-dm-00

   (To be Completed after bnp drafts)

   Figure bgp-20

5.13.  BGP-REQ 13

   BGP-REQ13 requirement is: the "I2RS client SHOULD be able to instruct
   the I2RS Agent to write BGP Policies into the running BGP protocols
   and into the BGP configurations."

   Discussion: BGP-REQ 13 indicates that the policy changes supported by
   BGP-REQ 12 must be able to operate in the running configuration.  The
   I2RS and netmod groups are discussing the definition of ephemeral.
   Two definitions are being discussed - patch and pull-up configuration
   as described below:

   running = config + ephemeral patches [patch]

   running = config (copy) + ephemeral additions (pull-up)

   Either definition implies that the I2RS changes can alter the policy
   based on the bgp configuration and I2rs model.

   The writing of changes from I2RS to the configuration was
   specifically ignored.  Writing of specific configuration options from
   the ephemeral store to the running configuration can initially be
   done by the I2RS client writing via the configuration interface to
   the datastore.

   Data models needed: The Policy data models for filter or filter and
   action are the same as in BGP-REQ13.

5.14.  BGP-REQ 14

   BGP-REQ14 requirement is: the "I2RS client-agent SHOULD be able to
   read BGP statistics associated with Peer, and to receive
   notifications when certain statistics have exceeded limits.  An
   example of one of these protocol statistics is the max-prefix limit."



Hares                    Expires April 27, 2015                [Page 25]


Internet-Draft                IM for policy                 October 2014


   Discussion: BGP-REQ01 examines the peer connectivity state.  BGP-
   REQ14 examines BGP peer statistics.  [I-D.zhdankin-netmod-bgp-cfg]
   provides statistics on the number of updates received or sent, but it
   does not have statistics on the max-prefix exceeded.  It does provide
   a limit for maximum-prefix per peer.

   [I-D.wang-i2rs-bgp-dm] has statistics on the number of updates
   received or sent, number of routes received or sent plus maximum
   prefix high-water and low-water.  This draft also has the limits
   copied into the status fields for easy reading.

   [I-D.zhdankin-netmod-bgp-cfg] (10/1/2014)

      module: bgp
         + ....
         +--rw bgp-neighbors
         |  +--rw bgp-neighbor [as-number]
      |     +--rw as-number                  uint32
      |     +--rw (peer-address-type)?
      |     |  .....
      |     +--rw prefix-list?               prefix-list-ref
      |     +--rw default-action?            actions-enum
      |     +--rw af-specific-config
      |     +--ro bgp-neighbor-state
      |     |  +--ro bgp-peer-admin-status;
      |     +--ro bgp-neighbor-statistics
      |     |  +--ro nr-in-updates
      |     |  +--rw nr-out-updates

   [I-D.wang-i2rs-bgp-dm]





















Hares                    Expires April 27, 2015                [Page 26]


Internet-Draft                IM for policy                 October 2014


   |  +--rw bgp-peer-list* [bgp-peer-name]
   |     +--rw peer-session-address
   |     |  +--rw local-ipv4-address?    inet:ipv4-prefix
   |     |  +--rw remote-ipv4-address?   inet:ipv4-prefix
   |     +--rw bgp-peer-name           string
   |     +--ro bgp-peer-type?          enumeration
   |     +--ro bgp-peer-create?        enumeration
   |     +--rw bgp-policy-in            policy-group-ref
   |     +--rw bgp-policy-out           policy-group-ref
   |     +--rw peer-state-info
   |     |  +--ro peer-current-state?   peer-stat
   |     |  +--ro peer-last-state?      peer-state
   |     |  +--ro peer-down-reason
   |     |  |  +--ro error-code?       enumeration
   |     |  |  +--ro sub-error-code
   |     |  |  |  ...
   |     |  +--ro peer-transmit-update-cnt?   uint64
   |     |  +--ro peer-recived-update-cnt     uint64
   |     |  +--ro peer-received-route-cnt?    uint64
   |     |  +--ro peer-send-route-cnt?        uint64
   |     |  +--rw max-prefix-rcv-limit?       uint64
   |     |  +--rw max-prefix-xmt-limit?       uint64
   |     |  +--ro peer-prefix-high?           uint64
   |     |  +--ro peer-prefix-low?            uint64

   Conclusion: Full support of BGP-REQ 14 requires the
   [I-D.wang-i2rs-bgp-dm] draft.

5.15.  BGP-REQ 15

   BGP-REQ15 requirement is: the "I2RS client via the I2RS agent MUST
   have the ability to read the loc-RIB-In BGP table that gets all the
   routes that the CE has provided to a PE router."

   Discussion: The [I-D.zhdankin-netmod-bgp-cfg] provides no indication
   of a local-rib or a local-RIB-in associated with a BGP peer.  The
   [I-D.wang-i2rs-bgp-dm] provides a local-rib per AFI, and a local-RIB-
   IN (AdjRIBIn and AdjRIBOut) associated with each peer.  The route
   table format is presented in figure bgp-9.

   Conclusion: [I-D.wang-i2rs-bgp-dm] is necessary for this requirement.

5.16.  BGP-REQ 16

   BGP-REQ16 requirement is: the "I2RS client via the I2RS agent MUST
   have the ability to install destination based routes in the local RIB
   of the PE devices.  This must include the ability to supply the
   destination prefix (NLRI), a table identifier, a route preference, a



Hares                    Expires April 27, 2015                [Page 27]


Internet-Draft                IM for policy                 October 2014


   route metric, a next-hop tunnel through which traffic would be
   carried."

   Discussion: If this refers to the I2RS LOC-RIB, then both drafts have
   policy which could redistribute I2RS routes.

   If BGP-REQ 16 refers to a BGP local-rib per AFI and the bgp-peer
   based bgp-rib-in (AdjRibIn) and bgp-rib-out (AdjRibOut).  As this
   previous discussion indicates, the [I-D.zhdankin-netmod-bgp-cfg] does
   not have a local rib-in.

   The document [I-D.wang-i2rs-bgp-dm] describes a per AFI bgp local-rib
   and the per peer bgp-rib-in (AdjRIBIn) and bgp-rib-out (AdjRibOut).
   The routes in these RIBs fall under a table identifier structure and
   have a destination prefix (NLRI), route administrative preference,
   route local-reference, and a next-hop.  However,
   [I-D.wang-i2rs-bgp-dm] does not have a tunnel based definition for
   the next-hop.  This would need to be added.

   Conclusion: Additions to [I-D.wang-i2rs-bgp-dm] may need to be made
   to fulfill this requirement.

5.17.  BGP-REQ 17

   BGP-REQ17 requirement is: the "I2RS client via the I2RS agent SHOULD
   have the ability to read the loc-RIB-in BGP table to discover
   overlapping routes, and determine which may be safely marked for
   removal."

   Discussion: As discussed in BGP-REQ15 and BGP-REQ16, draft
   [I-D.zhdankin-netmod-bgp-cfg] does not have a local-RIB-In BGP table.
   [I-D.wang-i2rs-bgp-dm] has a BGP local-rib per AFI and a per BGP Peer
   bgp-rib-in.  As described in BGP REQ10, this each route may set a
   "remove overlapping route" status flag.

   Conclusion: [I-D.wang-i2rs-bgp-dm] supports BGP-REQ 17.

5.18.  BGP-REQ 18

   BGP-REQ18 requirement is the "I2RS client via the I2RS Agent SHOULD
   have the ability to modify filtering rules and initiate a re-
   computation of the local BGP table through those policies to cause
   specific routes to be marked for removal at the outbound eBGP edge."

   Discussion: This feature requires that I2RS should be able to do a
   re-computation of policies.  This re-computation of policies is part
   of a soft-reconfig which [I-D.zhdankin-netmod-bgp-cfg] allows by




Hares                    Expires April 27, 2015                [Page 28]


Internet-Draft                IM for policy                 October 2014


   configuration.  However, the I2RS client will need a parameter to be
   set to do a reconfigure.

   Neither [I-D.zhdankin-netmod-bgp-cfg] or [I-D.wang-i2rs-bgp-dm] have
   this feature.

   Conclusion: This feature needs to be added to final model

6.  IANA Considerations

   This draft includes no request to IANA.

7.  Security Considerations

   TBD

8.  Informative References

   [I-D.bogdanovic-netmod-acl-model]
              Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair,
              "Network Access Control List (ACL) YANG Data Model",
              draft-bogdanovic-netmod-acl-model-02 (work in progress),
              October 2014.

   [I-D.hares-i2rs-bgp-dm]
              Wang, L., Hares, S., and S. Zhuang, "An I2RS BGP Data
              Modell", draft-hares-i2rs-bgp-dm-00 (work in progress),
              October 2014.

   [I-D.hares-i2rs-info-model-service-topo]
              Hares, S., Wu, W., and X. Guan, "An Information model for
              service topology", draft-hares-i2rs-info-model-service-
              topo-01 (work in progress), July 2014.

   [I-D.hares-i2rs-usecase-reqs-summary]
              Hares, S., "Summary of I2RS Use Case Requirements", draft-
              hares-i2rs-usecase-reqs-summary-00 (work in progress),
              July 2014.

   [I-D.ietf-i2rs-architecture]
              Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
              Nadeau, "An Architecture for the Interface to the Routing
              System", draft-ietf-i2rs-architecture-05 (work in
              progress), July 2014.







Hares                    Expires April 27, 2015                [Page 29]


Internet-Draft                IM for policy                 October 2014


   [I-D.ietf-i2rs-rib-info-model]
              Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing
              Information Base Info Model", draft-ietf-i2rs-rib-info-
              model-03 (work in progress), May 2014.

   [I-D.wang-i2rs-bgp-dm]
              Wang, L., Hares, S., and S. Zhuang, "An I2RS BGP Data
              Modell", draft-wang-i2rs-bgp-dm-00 (work in progress),
              October 2014.

   [I-D.zhdankin-netmod-bgp-cfg]
              Alex, A., Patel, K., and A. Clemm, "Yang Data Model for
              BGP Protocol", draft-zhdankin-netmod-bgp-cfg-01 (work in
              progress), October 2014.

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

   [RFC3060]  Moore, B., Ellesson, E., Strassner, J., and A. Westerinen,
              "Policy Core Information Model -- Version 1
              Specification", RFC 3060, February 2001.

   [RFC3460]  Moore, B., "Policy Core Information Model (PCIM)
              Extensions", RFC 3460, January 2003.

   [RFC3644]  Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B.
              Moore, "Policy Quality of Service (QoS) Information
              Model", RFC 3644, November 2003.

   [RFC5511]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
              Used to Form Encoding Rules in Various Routing Protocol
              Specifications", RFC 5511, April 2009.

Author's Address

   Susan Hares
   Huawei
   7453 Hickory Hill
   Saline, MI  48176
   USA

   Email: shares@ndzh.com









Hares                    Expires April 27, 2015                [Page 30]