I2RS Working Group S. Hares Internet-Draft L. Wang Intended status: Standards Track S. Zhuang Expires: January 2, 2015 Huawei July 1, 2014 An I2RS BGP Information Model draft-hares-i2rs-bgp-im-00.txt Abstract This document introduces an information model for i2RS BGP protocol and network policy that aligns with the I2RS BGP use cases. This draft utilizes the general Policy based routing structured found in the RIB Information Model (IM) and Policy Base Policy. 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 January 2, 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 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. Hares, et al. Expires January 2, 2015 [Page 1] Internet-Draft BGP IM July 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 3. BGP Data . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. BGP Protocol . . . . . . . . . . . . . . . . . . . . . . 3 3.1.1. Elements in I2RS Protocol Block . . . . . . . . . . . 4 3.1.2. RBNF the I2RS BGP IM Protocol Block . . . . . . . . . 5 3.2. BGP Instance List (BGP_INSTANCE_LIST) . . . . . . . . . . 6 3.2.1. Elements in BGP_INSTANCE Element . . . . . . . . . . 6 3.2.2. BGP_INSTANCE RBNF . . . . . . . . . . . . . . . . . . 9 3.3. BGP Peer . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. Reading/Writing Policy in I2RS IM model for BGP Peer 12 3.3.2. Elements in BGP Peer . . . . . . . . . . . . . . . . 12 3.3.3. RBNF for BGP Peer . . . . . . . . . . . . . . . . . . 15 3.4. BGP Route . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4.1. BGP Local RIB . . . . . . . . . . . . . . . . . . . . 18 4. BGP Policy . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1. BGP IM Policy RBNF . . . . . . . . . . . . . . . . . . . 24 4.2. RIB IM Policy RBNF . . . . . . . . . . . . . . . . . . . 26 4.3. BNP IM Grammar . . . . . . . . . . . . . . . . . . . . . 26 5. BGP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.1. UML grammar . . . . . . . . . . . . . . . . . . . . . . . 28 5.2. BGP-IM RNBF Grammar . . . . . . . . . . . . . . . . . . . 28 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 7. Security Considerations . . . . . . . . . . . . . . . . . . . 37 8. Informative References . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 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 via protocol message exchange between an I2RS Client and an I2RS Agent associated with the a routing system. The [I-D.ietf-i2rs-architecture] describes the basic interactions of this exchange. One of the important functions of this messages exchange is for the I2RS client to interact with one or more I2RS agents to collect information from network routing systems. One of the key information pieces that I2RS clients may collect from I2RS agents is the BGP information regarding BGP peers, BGP routes, and network topologies created within BGP. This document introduces a basic information model for BGP policies. This policy model can be linked with other information models such as the I2RS RIB informational model [I-D.ietf-i2rs-rib-info-model], and uses the generic policy found in the Policy Routing modules in [I-D.hares-i2rs-info-model-policy]. This basic BGP Information Model Hares, et al. Expires January 2, 2015 [Page 2] Internet-Draft BGP IM July 2014 is an extendable policy model is a product of the industry approach to I2RS. 2. Definitions and Acronyms BGP: Border Gateway Protocol Information Model: An abstract model of a conceptual domain, independent of a specific implementation or data representation NETCONF:The Network Configuration Protocol as defined in [RFC6536] RESTCONF: The REST-like protocol that provides a programmatic interface over HTTP for accesing data defined in YANG, using datastores defined in NETCONF Protocol [I-D.ietf-netconf-restconf] as defined in RBNF: Routing Backus-Naur Form [RFC5511]. 3. BGP Data BGP data includes information related to the BGP protocol instances, BGP Peer information, BGP Route information, and BGP policy. This section describes the information associated with the I2RS agent accessible via BGP. 3.1. BGP Protocol BGP protocol support within a router(or virtual routing device) may have multiple instances of the BGP protocol. This section describes the information regarding the BGP protocol available to the I2RS Agent. At end of this section there is a RBNF form summarizing this topology. Protocol The BGP protocol information stores a group of information associated with a BGP protocol implementation. This group of informational includes: * Router-ID (R/W) - Router-ID for BGP protocol, * AS(R/W)- Autonomous System Number, * protocol_status (R) - administrative status of the protocol, * shutdown_protocol (R/W) - Shutdown the BGP protocol, * ROLES (R) - a composite set of roles BGP peers play, Hares, et al. Expires January 2, 2015 [Page 3] Internet-Draft BGP IM July 2014 * bgp-instance-list (R/W) - BGP protocol instances, The section below describes these elements. 3.1.1. Elements in I2RS Protocol Block This section describes each element of the I2RS Protocol Block. Router-ID (R) This I2RS BGP IM element stores the ROUTER-ID which is configured in the BGP protocol as the default router-id. Instances of a protocol may configure unique router-IDs. The router-ID is a 32 bit unsigned value imported from the running BGP process. Router-ID (W) Upon a write from the I2RS Client to this I2RS BGP IM element, this I2RS Agent will temporarily change this default in the BGP protocol. I2RS Agent-routing system software must be able to handle both the original value (from node configuration systems), and the I2RS value as valid defaults. This change in the ROUTER_- ID default is passed to the BGP instances spawned from the BGP protocol. After the I2RS Client stops the relationship with the I2RS Agent, the Router-ID value reverts to the configured value. AS(R/W) This I2RS BGP IM element stores the default AS number configured in the BGP implementation. This value is 8 byte value represented as a decimal value. This value is a read-write value. The initial value of the AS is imported by the I2RS Agent from the BGP protocol in the BGP routing system. This the normal case. If this data element is written to, I2RS stores the default AS number value in the BGP protocol as the new default AS in the BGP protocol. This does not change the default AS number in existing BGP instances with the existing peers. New BGP instances spawned after the I2RS changes the default AS value, should have the I2RS specified default AS. Upon the completion of the I2RS client-I2RS Agent association, the default AS value should be returned to the configured value. protcol_status (R) This I2RS BGP IM element stores an administrative status for the protocol activity of "no-shutdown" (0x00) or "shutdown" (0x01). If the routing entity the I2RS protocol is attached has BGP Hares, et al. Expires January 2, 2015 [Page 4] Internet-Draft BGP IM July 2014 "shutdown", no data will be available from any BGP instances. This is a read-only variable. shutdown_protocol(R/W) A write of "TRUE" to the "shutdown_protocol" status in the I2RS Agent indicates the I2RS agent should request a shutdown of the BGP protocol from the routing function. The default value is "FALSE" for this I2RS variable. The read of the "shutdown_protocol" indicate the current status of the "shutdown_protocol" variable in the I2RS Agent. This is different than the "protocol_status" which indicates the status of the protocol: shutdown or not "shutdown" (running). BGP_ROLE (R) The BGP_ROLE provides a list of BGP Roles found within the BGP Instances associated with the BGP protocol function on the device associated with the I2RS agent. These can be ASBR (AS border router E-BGP), PE (Provider Edge E-BGP), IBGP peer, or RR (Route Reflector). bgp-instance-list (R-W) This element provides a list of BGP instances associated with the BGP routing process associated with the I2RS agent. Each BGP instance is identified by BGP_INSTANCE_NAME and BGP_INSTANCE_TYPE (AFI,SAFI tuple) Each instances contains: local-AS local-router- id, bgp_local_rib, bgp-peer-list described below. 3.1.2. RBNF the I2RS BGP IM Protocol Block ::= < ROUTER-ID > ::= [] [ ] [ ] [] ::= | ::= | ::= ( ...) Hares, et al. Expires January 2, 2015 [Page 5] Internet-Draft BGP IM July 2014 3.2. BGP Instance List (BGP_INSTANCE_LIST) This section describes the list of BGP instances (BGP_INSTANCE_LIST). Each BGP_INSTANCE has the following structure o BGP_INSTANCE_NAME (R/W) - Name for BGP instance o BGP_INSTANCE_CREATION_STATUS (R/W) o BGP_INSTANCE_TYPE (R/W) - Types of BGP Instance o BGP_VENDOR_TYPE (R/W) - Vendor types o AFI (R/W) - address family o SAFI (R/W) - sub-address family o BGP_MAX_PREFIX (R/W> o bgp_local_RIB (R/W) - o bgp-peer-list (R/W) 3.2.1. Elements in BGP_INSTANCE Element The definitions of the fields in BGP Instance are: BGP_INSTANCE_NAME (R/W) The BGP_INSTANCE_NAME provides a name to uniquely identify the BGP instance. BGP_INSTANCE_NAME identifies a instance with a particular AFI, SAFI, and BGP_VENDOR_TYPE field. A BGP instance capabilities may be summarized in the BGP_INSTANCE_TYPE. A write changes the BGP_INSTANCE_NAME, but BGP_INSTANCE_CREATION(R/W) is the flag to indicate whether the I2RS client is requesting the I2RS agent to have the BGP routing protocol create a new BGP instance for these I2RS parameters. The internal status includes: * Not I2RS created (NOT-I2RS), * I2RS client requests creation (I2RSCLIENT_CREATE_BGP_INSTANCE), * I2RS Agent rejects creation (I2RSAGENT_REJECTS_BGP_INSTANCE_CREATE), Hares, et al. Expires January 2, 2015 [Page 6] Internet-Draft BGP IM July 2014 * I2RS Agent attempting creation (I2RSAGENT_ATTEMPTS_BGP_INSTANCE_CREATE), and * I2RS Agent failed creation (I2RSAGENT_FAILS_BGP_INSTANCE_CREATE) * I2RS Agent created BGP instance (I2RSAGENT_CREATED_BGP_INSTANCE) BGP_INSTANCE_TYPE (R/W) contains flag field that summarizes common AFI-SAFIs within a flag word. * BGP_IPV4_UNI flag - is a flag for AFI of IPV4 and a SAFI of Unicast (1). * BGP_IPV4_MULTI flag - is a flag for AFI of IPV4 and a SAFI Multicast (2). * BGP_L3VPN I is a flag for AFI of IPv4 and a SAFI of MPLS labels (4). * BGP_IPv4_MVPN- is a flag for AFI of IPv4 and a SAFI of MCAST VPN (5). * BGP_VPLS - is a flag for an AFI of IPv4 and a SAFI VPLS (65). * BGP_IPV4_MDT - is a flag for AFI of IPv4 and a SAFI of BGP MDT (66). * BGP_EVPN - is a flag for APFI of IPv4 and SAFI of EVPNs (70) * BGP_LS - is a flag for an AFI of IPv4 and a SAFI of BGP link state (LS) (71). * BGP_IPV4_MPLS_VPN - is a flag for an AFI of IPv4 and a SAFI MPLS-labled Unicast VPNs (128). * BGP_IPv4_MPLS_MVPN - is a flag for an AFI of IPv4 and a SAFI MPLS-labeled Multicast VPNs (129). * BGP_IPv4_ROUTE_TARGET - is a flag for the AFI of IPv4 and a SAFI of Route Target Constraints (132) * BGP_IPv4_FLOW - is a flag for an AFI of IPv4 and a SAFI of IPv4 dissemination of flow specification rules (133). Hares, et al. Expires January 2, 2015 [Page 7] Internet-Draft BGP IM July 2014 * BGP_IPv4_VPN_FLOW - is a flag for an AFI of IPv4 and a SAFI of IPv4 VPN dissemination of flow specification rules(134). * BGP_L2AD - is a flag for an AFI of IPv4 and a SAFI L2 Auto- discovery (140) * BGP_IPv6_UNI - is a flag for AFI of IPv6 and SAFI of Unicast (1) * BGP_IPv6_MULTI - is a flag for API of IPv65 and a SAFI of Multicast (2) * BGP_IPV6_MPLS_VPN - is a flag for AFI of IPV4 and SAFI of Unicast MPLS VPNS. BGP_VENDOR_TYPE(R/W) contains a field to specify Vendor specific additions to identify instance. bgp_local_RIB_active (R/W) contains the contains a local RIB for BGP associated with this BGP instance. Every BGP instance has its own local RIB which contains the routes received by all Peers (Adj-RIB-IN per Peer), and selected by policy as the active route by the local BGP speaker's Decision Process. AFI (R/W) The AFI value from the standard values found in IANA's Address Family Numbers. SAFI (R/W) The AFI value from the standard values found in IANA's SAFI values. bgp_local_RIB (R/W) contains the bgp local RIB associated with this BGP instance. Every BGP instance has its own local RIB which contains the routes received by all Peers (Adj-RIB-IN per Peer), and selected by policy as the active route by the local BGP speaker's Decision Process. bgp-peer-list (R/W) Hares, et al. Expires January 2, 2015 [Page 8] Internet-Draft BGP IM July 2014 contains a list of BGP Peer information (BGP_PEER) associated with this BGP instance. A write to this BGP Peer list adds a BGP Peer to this BGP instance. 3.2.2. BGP_INSTANCE RBNF Hares, et al. Expires January 2, 2015 [Page 9] Internet-Draft BGP IM July 2014 ::= (< bgp-instance > ...) ::= ::= | | | | | | | | < BGP_INSTANCE_TYPE > ::= < BGP_IPV4_UNI > | < BGP_IPV4_MULTI > | < BGP_IPV4_L3VPN > | < BGP_IPV4_MVPN > | < BGP_VPLS > | < BGP_MDT > | < BGP_EVPN > | < BGP_LS > | < BGP_IPV4_MPLS_VPN > | < BGP_IPV4_MPLS_MVPN > | < BGP_ROUTE_TARGET > | < BGP_IPV4_FLOW > | < BGP_IPV4_VPN_FLOW > | < BGP_IPV4_VRF_LIST > | < BGP_IPV6_VRF_LIST > | < BGP_IPV6_UNI > | < BGP_IPV6_VPNV6 > ::= | < SAFI> ::= | | < L3VPN > | | | < RT_CONSTRAIN >| < IPV4_FLOW_SPEC > | < VPNV4_FLOW_SPEC >| < CLNS_VPN > | < NG_MVPN >| < MDT_SAFI > Hares, et al. Expires January 2, 2015 [Page 10] Internet-Draft BGP IM July 2014 3.3. BGP Peer The following are the elements in the BGP_Peer structure o BGP_PEER_NAME (R/W) o Session_address(R/W) o Peer_MAX_PREFIX (R/W) o BGP_Peer_Type o BGP_Peer_create - request to create BGP peer o bgp_rib_in (R) o bgp_rib_out (R/W) o Peer_policy_in (R/W) - Policy set name o Peer_policy_out (R/W) - Policy set name o Peer_policy_in_pset - Policy set (R) o Peer_policy_out_pset - Policy set (R) o Peer_state_info * Peer_current_state (R) * Peer_last_state (R) * Peer_down_reason (R) * Peer_Received_Route_Cnt (R) * Peer_Sent_Route_Cnt (R) * Peer_Prefix_high (R) * Peer_prefix_low (R) * Peer_prefix_ave (R) * Peer_prefix_time (R) * Peer_PREFIX_Max (R) Hares, et al. Expires January 2, 2015 [Page 11] Internet-Draft BGP IM July 2014 * publish_version (R) 3.3.1. Reading/Writing Policy in I2RS IM model for BGP Peer The I2RS Agent's peer inbound and outbound policies are logically considered to be stored in policy-sets as described in [I-D.hares-i2rs-info-model-policy]. Policy sets are uniquely identified by a Policy-set name/identity which the variables Peer_policy_in and Peer_policy_out refer to. The full policy set can be read from the variables Peer_policy_in_pset (inbound bgp peer policy), and Peer_policy_out_pset. A bit of explanation is in order to describe their use in the I2RS Client-I2RS Agent exchange. Some I2RS clients will have long-term connections to I2RS Agents associated with a BGP routing function, and may choose to transfer the BGP Policy set or a set of the BGP Policy Components to the client's local memory. In this case, the I2RS Client could request the I2RS Agent to simply transfer the BGP Policy Sets name used by for the BGP Peers to minimize travel along with an indication of the last time the policy was updated. The policy variables Peer_policy_in and Peer_policy_out allow both read and write of the Policy set IDs. The read of the Peer_policy_in and Peer_policy_out will provide simply the policy-set name. The write of the Peer_policy_in the I2RS agent will need to valid the the policy set name. After the policy set name is validated, the policy set link is placed in Peer_policy_in_pset and the BGP routing function updated with the policy set lists for the BGP Peer. Similarly, if a write occurs to I2RS Agent's Peer_policy_out, the I2RS agent validates the policy-set name , replaces Peer_policy_out_pset with the link to the policy-set identified by the Policy-set name. Reading either Peer_policy_in_pset will result in the I2RS Agent passing the policy linked to by the Peer_policy_in name (and linked to by Peer_policy_in_pset) to the I2RS Client in policy set form. Similarly, reading the Peer_policy_out_pset will retrieve the policy set pointed to by the Peer_policy_out name, and transfer the data in policy set form. 3.3.2. Elements in BGP Peer The definitions of the fields in BGP peer are: BGP_PEER_NAME (R/W) Hares, et al. Expires January 2, 2015 [Page 12] Internet-Draft BGP IM July 2014 This entry uniquely names a BGP Peer. If multiple TCP connections are utilized between two BGP Peers, then the BGP Peer uniquely identifies the Peering. An I2RS Write to a BGP_PEER_NAME changes the BGP_PEER_NAME For the duration of the I2RS client-agent association for the run-time BGP, but it does not change the configured BGP Peer name. Peer_Session_Address (R/W) provides local peer address information and remote peer address information. Please see the description below for the details of the BGP session address. A read of this information pulls this information from the BGP Peer data in the routing system. The write of this information MAY set-up an TCP session (either initial or a second in multiple TCP sessions support BGP_PEER_TYPE (R/W) contains the status on the type of BGP such as EBGP, IBGP, RR, RR- Client, PE, or CE. or Vendor specific types. PEER_MAX_PREFIX(R/W) contains the I2RS Agent's maximum prefixes allowed for this BGP Peer. A write of the PEER_MAX_PREFIX writes a new value into the I2RS Agent, and MAY upon configuration be read by the BGP routing function to set a new Peer_Max_Prefix_run. BGP_Peer_create(R/W) provides the I2RS creation status for this peer as: not-created by I2RS, requested by client but not processed, or an I2RS agent's response to the request: (agent reject peer creation, agent attempting peer creation, Agent failed peer creation, and Agent created BGP Peer). bgp_rib_in the BGP routes received by from this BGP peer in the form of a bgp-route-list. bgp_rib_out (R/W) provides a a list of the routes sent to the Peer in the form of a bgp-route-list. Peer_policy_in (R/W) Hares, et al. Expires January 2, 2015 [Page 13] Internet-Draft BGP IM July 2014 contains the policy set name for the inbound peer policy. The Information model for the policy set is defined in [I-D.hares-i2rs-info-model-policy]. The I2RS client reading a Policy_peer_in policy set name MAY match this against the policy- set names retrieved from the I2RS Agent. The I2RS Client writing to this Peer_policy_in writes a new policy name for the BGP peer policy in the I2RS agent, and signals the I2RS agent to have the bgp routing function to update the run time policy for this bgp peer for inbound traffic. This updated policy remains in the BGP Peer until either: a) I2RS Agents updates it, or b) the I2RS client-agent relationship ceases and the policy return to configured policy. Peer_policy_out (R/W) contains of a policy-set name for the outbound. The structure of a policy set is defined in [I-D.hares-i2rs-info-model-policy]. An I2RS client reading this policy set name should match the policy- set name to outbound policies retrieved from this I2RS Agent. A write of a new policy-set name to the I2RS agents signals the I2RS agent to validate the policy set name. After the Policy set name has been validated, the I2RS Agent SHOULD update I2rs BGP Peer_policy_out_pset, and signal the routing function to utilize the new policy identified by the policy-set to policy sets retrieved from the I2rs Agent. This updated policy remains in the BGP Peer until either: a) I2RS Agents updates it, or b) the I2RS client-agent relationship ceases and the BGP policy is restored to the configured policy. Peer_policy_in_pset (R) is the variable the I2RS client reads to receive the full policy- set used for this BGP Peers inbound policy. The I2RS Agent MUST to keep this policy variable in-sync with the I2RS Peer-Policy_in. Peer_policy_out_pset (R) is the variable the I2RS client reads to receive the full policy- set used for this BGP Peers inbound policy. The I2RS Agent MUST to keep this policy variable in-sync with the I2RS Peer- Policy_out. Peer_state_info provides the following readable state information copied from the BGP routing function: Hares, et al. Expires January 2, 2015 [Page 14] Internet-Draft BGP IM July 2014 * Peer_current_state (R) - the the current state of the BGP Peer in the BGP state machine. * Peer_last_state (R) - the the last state of the BGP peer according to the BGP state machine * Peer_down_reason (R) - the error code and sub-error code of the last peer down * Peer_received_update_cnt (R) - the count of the received update packets. * Peer_transmit_update_cnt (R) - the count of the transmit update packets. * Peer_Receive_Route_Cnt (R) - contains current total number of unique prefix routes received from peer * Peer_Sent_Route_Cnt (R) - contains current total number prefix routes sent to peer * MAX_PREFIX_RCV_Limit (R/W) - Maximum unique prefix routes accepted from peer * MAX_PREFIX_XMT_LIMIT (R/W) - Maximum unique prefix routes transmit to peer * Peer_prefix_high (R) - contains high water mark count of total unique routes by prefix received from peer. * Peer_prefix_low (R) - contains the low water mark count of total unique routes by prefix received from peer. * Peer_Prefix_ave (R) - contains the average number of prefix routes from peer (running). 3.3.3. RBNF for BGP Peer RBNF for the BGP Peer portion of BGP IM < bgp-peer-list > ::= (< BGP_peer > ...) ::= Hares, et al. Expires January 2, 2015 [Page 15] Internet-Draft BGP IM July 2014 [] ::= (alpha-numeric characters) ::= [] | [] | [] < v4-session-address> ::= ::= ::= ::= [][] [][] [][] [] ::= ... ::= INTEGER; ::= | | | | | /* details on the bgp_route_list are * contained in the bgp route section */ ::= /* Adj-RIB-IN */ ::= /* Adj-RIB-OUT */ /* details on the Policy_set_name and * Policy_set are imported from * draft-i2rs-hares-info-model-policy Hares, et al. Expires January 2, 2015 [Page 16] Internet-Draft BGP IM July 2014 */ ::= ; ::= ; ::= ; ::= ; ::= [] [] [] [] [] [] [] [] [] [] [] [] ::= < Established > | | < connect > | | < open_send > | ::= < Established > | | < connect > | | < open_send > | ::= [< ERROR SUB CODE>] ::= <1: Message_Header_Error> | <2: OPEN_Message_Error> | <3: UPDATE_Message_Error> | <4: Hold_Timer_Expired> | <5: Finite_State_Machine_Error > | <6: Cease > | <7: Route_Refresh_Error > ::= | | HEAD_ERROR_SUB_CODE> ::= <1 _ Connection_Not_Synchronized> | <2 _ Bad_Message_Length> | <3 _ Bad_Message_Type> ::= <1 _ Unsupported Version Number> | <2 _ Bad_Peer_AS> Hares, et al. Expires January 2, 2015 [Page 17] Internet-Draft BGP IM July 2014 | <3 _ Bad_BGP_Identifier> | <4 _ Unsupported_Optional_Parameter> | <5 _ Deprecated_see_Appendix_A> | <6 _ Unacceptable_Hold_Time> ::= <1_ Malformed Attribute List> | <2_Unrecognized Well_known Attribute> | <3 _ Missing_Well_known_Attribute> | <4 _ Attribute_Flags_Error> | <5 _ Attribute_Length_Error> | <6 _ Invalid_ORIGIN_Attribute> | <7 _ Deprecated_see_Appendix A> | <8 _ Invalid_NEXT_HOP_Attribute> | <9 _ Optional_Attribute_Error> | <10 _ Invalid_Network_Field> | <11 _ Malformed_AS_PATH> < Route_Refresh_ERROR_SUB_CODE> ::= <1_Invalid_Message_Length > ::= COUNTER-64; ::= COUNTER-64: ::= COUNTER-64; ::= COUNTER-64; ::= COUNTER-64; ::= COUNTER-64; ::= COUNTER-64; ::= COUNTER-64; 3.4. BGP Route The routes associated with each BGP instance are the BGP local RIB, the AdjRIBIn, and the AdjRIBOut. The BGP local RIB is described below. The AdjRIBIn is the bgp_rib_in described in the BGP_Peer section. The policy that sets preferences on the routes received by the peer is identified by the Peer_policy_in (an policy set name), and fully readable by the Peer_policy_in_pset (policy set pointer) entry. The AdjRIBOut is contained in bgp_rib_out (a route list) described in the BGP Peer Section. The Policy associated with the AdjRIBOut is identified by the Peer_policy_out (a policy set name) and fully readable by the Peer_policy_out_pset (policy set pointer). 3.4.1. BGP Local RIB The BGP Local RIB listed below may be created and stored as a prefix tree, but described below as a bgp_route-list for full transmission from the I2RS Client to the I2RS Agent. The bgp route list has a sequence of bgp_routes with the following elements: Hares, et al. Expires January 2, 2015 [Page 18] Internet-Draft BGP IM July 2014 o BGP_ROUTE_TYPE (R/W) o BGP_ROUTE_CREATE (R/W) o ROUTE_DISTINGUISHER (R/W) o ip-prefix (R/W) o FLOW_route (R/W) o EVPN_route (R/W) o MVPN_route (R/W) o bgp-attribute-list (R/W) o rt_rib_state_info which includes: * rt_rib_current_state * rt_rib_last_state * rt_rib_reject_reason * rt_not_preferred o BGP_ROUTE_CREATE (R/W) 3.4.1.1. BGP_LOCAL_RIB Entries The BGP Local RIB Entries are: BGP_ROUTE_TYPE(R/W) contains a ROUTE TYPE indicator. bgp-route-prefix (R/W) contains a prefix of the type specified in ROUTE_TYPE. bgp-attribute-list (R/W) contains a list of bgp attributes. bgp_route_creation (R/W) provides the status of the creation of a BGP route requested by a I2RS Client to I2RS agent to be created in the BGP instance's Hares, et al. Expires January 2, 2015 [Page 19] Internet-Draft BGP IM July 2014 local route. The status includes "not-i2rs" routes for routes created by the bgp protocol function and imported into the I2RS Agent for transmission to the I2RS Client. For routes created there is a series of status values that track the I2RS Client request for BGP route creation. bgp_status_info (R/W) contains a set of BGP status that inclues: * rt_rib_current_state * rt_rib_last_state * rt_rib_reject_reason * rt_not_preferred 3.4.1.2. BGP_LOCAL_RIB RBNF The following is the RBNF for the BGP_LOCAL_RIB: /* bgp local rib */ ::= ::= ( ...) ::= ::= | | | | | | | | | | | | | | ::= Hares, et al. Expires January 2, 2015 [Page 20] Internet-Draft BGP IM July 2014 | | | | | | | /* draft-ietf-l2vp-evpn */ | /* RFC6514 */ | /* RFC7117 */ | /* RFC6037 */ | /* draft-ietf-idr-ls-distribution */ | /* RFC4761 */ | /* RFC6064 */ | /* RFC4684 */ | /* RFC7267 */ ::=[] [] [] [] [ ] [] [] [] [] [] [] ::= <16-bit ASN: 32-bit-Number > | <32-bit IPv4_address:16-bit-Number > | <32-bit ASN:16-bit Number > ::= ::= ::= ::= ::= ::= ::= ::= ( ( | | | ) Hares, et al. Expires January 2, 2015 [Page 21] Internet-Draft BGP IM July 2014 ::= | | | ::= ( | ) :: | | | | | | | | | | < Ethernet_Segment route> :: = | *lt;Leaf_AD_route> /* MDT NLRI - IPv4 address that Identifies the PE * that originated this route. * The RD identifies the VRF in that PE. * The group address MUST be a IPv4 multicast * group address and it is used to build P-tunnel. * All PEs attached to given MVPN must specify * the same group address even if the group is * an SSM group. MDT-SAFIs do not carry RTs, and the group * address is used to associated a received * MDT-SAFI with a VRF. */ ::= ::= ( | | | ) ::= | | | /* VPLS_BGP_NLRI explanation * PE participating in the VPLS must have at least one VE ID. Hares, et al. Expires January 2, 2015 [Page 22] Internet-Draft BGP IM July 2014 * VE IDs are typi8cally assigned by the network administrator * with a scope local to VPLS. Therefore the VE ID should * only belong to one PE unless the CE is multi-homed. * * if the PE is the VE, then it typical has one VE ID. * if the PE is connected to several u-PEs, it has a distinct * VE ID for each u-PE. The PE may additionally have a VE ID for * itself, if asks acts as a VE for that VPLS. * A label block with demultiplexer labels is * used to reach the VE ID. * A VPLS BGP NLRI has a VE ID, a VE Block offset (VBO), a * block offset size (VBS), and a Label base (LB). * Labels for local VE are (LB+VBS-1) and for the remote * (VBO+VBS-1). */ ::= ::= ::= /* LENGTH of PW_route is prefix length of Route Distinguisher + * Global_ID + Prefix + AC ID in bits * default PW route = x length * other: length is between 96-160 bits */ ::= ::= | | | | | | | | ::= [] [] [] Hares, et al. Expires January 2, 2015 [Page 23] Internet-Draft BGP IM July 2014 ::= (< Active > | < InActive > ) | (< primary > | < backup >) [ < suppress > ] ::= (< Active > | < InActive > ) ( | < backup >) [ < suppress > ] ::= | | < Nexthop_Unreachable> | < Malformed_PEER_DOWN> | < Malformed_DISCARD> | < Malformed_IGNORE> ::= | | | | | | | | | | 4. BGP Policy The BGP policy uses policy sets to define the policy for bgp_policy_in, bgp_policy_out, bgp_policy_in_rpset, and bgp_policy_out_rpset. Policy sets are defined in [I-D.hares-i2rs-info-model-policy]. Policy sets contain informational model definitions for Policy groups, Policy Rules, PBR IM, local-config IM. The first section below contains the RBNF for the Policy sets, Policy Groups, and Policy Rules. The second section below contains the RBNF for the BGP Policy. The first section below contains the RBNF for these models that is utilized by the BGP Info-Model (IM). 4.1. BGP IM Policy RBNF The BGP IM policy has policy for: o BGP IM Tree Matches for Roles o Policy-Rule Extensions for Matching /* Role Tree Matches */ Hares, et al. Expires January 2, 2015 [Page 24] Internet-Draft BGP IM July 2014 ::= [ ::= [ ::= ::= ( ...) /* Policy Rule Extensions for BGP */ ::= ( ...) ::= ( ...) ::= ( ...) ::= [ ] [] [] [] [] [] [] [] [] [] [] [] ::= [] [] [comm_mod_args] ::= ::= (Peer_Session_Address ...); ::= ( ..) ::= ( ..) :: = [ | ] ::= [ | /* community list/ [ | ] ::= [] [] [] Hares, et al. Expires January 2, 2015 [Page 25] Internet-Draft BGP IM July 2014 [] [] [] [] [] 4.2. RIB IM Policy RBNF ::= [ ::= [ ::= ::= ( ...) ::= (....); [] [] ::= ( ...) [] ::= ::= [] ::= INTEGER (0..500); :;= INTEGER (0..500); ::= ( ...); ::= ( ...) [] [] ::= | ::= [] 5. BGP Grammar This section examines the grammar. Hares, et al. Expires January 2, 2015 [Page 27] Internet-Draft BGP IM July 2014 5.1. UML grammar This will include a UML version of the grammar. 5.2. BGP-IM RNBF Grammar ::= < Router ID > ::= [] [ ] [ < IBGP >] [< RR >] ::= | ::= | ::= (< BGP_INSTANCE > ...) /* BGP Instance */ ::= (< BGP_INSTANCE > ...) ::= ::= | | | | | | | | < BGP_INSTANCE_TYPE > ::= < BGP_IPV4_UNI > | < BGP_IPV4_MULTI > | < BGP_IPV4_L3VPN > | < BGP_IPV4_MVPN > | < BGP_VPLS > | < BGP_MDT > Hares, et al. Expires January 2, 2015 [Page 28] Internet-Draft BGP IM July 2014 | < BGP_EVPN > | < BGP_LS > | < BGP_IPV4_MPLS_VPN > | < BGP_IPV4_MPLS_MVPN > | < BGP_Route_Target > | < BGP_IPV4_FLOW > | < BGP_IPV4_VPN_FLOW > | < BGP_IPV4_VRF_LIST > | < BGP_IPV6_VRF_LIST > | < BGP_IPV6_UNI > | < BGP_IPV6_VPNV6 > ::= | < SAFI> ::= | | < L3VPN > | | | < RT_CONSTRAIN >| | < VPNV4_FLOW_SPEC >| | < NG_MVPN >| < MDT_SAFI > /* BGP Peer information */ ::= (< BGP_peer > ...) ::= [] ::= (alpha-numeric characters) ::= [] | [] | [] ::= ::= Hares, et al. Expires January 2, 2015 [Page 29] Internet-Draft BGP IM July 2014 ::= ::= [][] [][] [][] [] ::= ... ::= INTEGER; ::= | | | | | /* details on the bgp_route_list are * contained in the bgp route section */ ::= /* Adj-RIB-IN */ ::= /* Adj-RIB-OUT */ /* details on the Policy_set_name and * Policy_set are imported from * draft-i2rs-hares-info-model-policy */ ::= ; ::= ; ::= ; ::= ; ::= [] [] [] [] [] [] [] [] Hares, et al. Expires January 2, 2015 [Page 30] Internet-Draft BGP IM July 2014 [] [] [] [] ::= < Established > | | < connect > | | < open_send > | ::= < Established > | | < connect > | | < open_send > | ::= [< ERROR_SUB_CODE>] ::= <1: Message Header Error> | <2: OPEN Message Error> | <3: UPDATE Message Error> | <4: Hold Timer Expired> | <5: Finite State Machine Error > | <6: Cease > | <7: Route Refresh> ::= | | ::= < 1 _ Connection Not Synchronized> | <2 _ Bad Message Length> | <3 _ Bad Message Type> ::= <1 _ Unsupported Version Number> | <2 _ Bad Peer AS> | <3 _ Bad BGP Identifier> | <4 _ Unsupported Optional Parameter> | <5 _ [Deprecated _ see Appendix A] > | <6 _ Unacceptable Hold Time> ::= <1 _ Malformed Attribute List> | <2 _ Unrecognized Well_known Attribute> | <3 _ Missing Well_known Attribute> | <4 _ Attribute Flags Error> | <5 _ Attribute Length Error> | <6 _ Invalid ORIGIN Attribute> | <7 _ [Deprecated _ see Appendix A] > | <8 _ Invalid NEXT_HOP Attribute> | <9 _ Optional Attribute Error> | <10 _ Invalid Network Field> Hares, et al. Expires January 2, 2015 [Page 31] Internet-Draft BGP IM July 2014 | <11 _ Malformed AS_PATH> < Route_Refresh_ERROR_SUB_CODE> ::= <1_Invalid_Message_Length > ::= COUNTER-64; ::= COUNTER-64: ::= COUNTER-64; ::= COUNTER-64; ::= COUNTER-64; ::= COUNTER-64; ::= COUNTER-64; ::= COUNTER-64; /* bgp local rib */ ::= ::= ( ...) ::= ::= | | | | | | | | | | | | | | ::= | | | | | | | /* draft-ietf-l2vp-evpn */ | /* RFC6514 */ Hares, et al. Expires January 2, 2015 [Page 32] Internet-Draft BGP IM July 2014 | /* RFC7117 */ | /* RFC6037 */ | /* draft-ietf-idr-ls-distribution */ | /* RFC4761 */ | /* RFC6064 */ | /* RFC4684 */ | /* RFC7267 */ ::=[] [] [] [] [ ] [] [] [] [] [] [] ::= <16-bit ASN: 32-bit-Number > | <32-bit IPv4_address:16-bit-Number > | <32-bit ASN:16-bit Number > ::= ::= ::= ::= ::= ::= ::= ::= ( ( | | | ) ::= | | | ::= ( | ) Hares, et al. Expires January 2, 2015 [Page 33] Internet-Draft BGP IM July 2014 ::= | | | | | | :: = | /* MDT NLRI - IPv4 address that Identifies the PE * that originated this route. * The RD identifies the VRF in that PE. * The group address MUST be a IPv4 multicast * group address and it is used to build P-tunnel. * All PEs attached to given MVPN must specify * the same group address even if the group is * an SSM group. MDT-SAFIs do not carry RTs, and the group * address is used to associated a received * MDT-SAFI with a VRF. */ ::= ::= ( | | | ) ::= | | | /* VPLS_BGP_NLRI explanation * PE participating in the VPLS must have at least one VE ID. * VE IDs are typi8cally assigned by the network administrator * with a scope local to VPLS. Therefore the VE ID should * only belong to one PE unless the CE is multi-homed. * * if the PE is the VE, then it typical has one VE ID. * if the PE is connected to several u-PEs, it has a distinct * VE ID for each u-PE. The PE may additionally have a VE ID for * itself, if asks acts as a VE for that VPLS. * A label block with demultiplexer labels is * used to reach the VE ID. Hares, et al. Expires January 2, 2015 [Page 34] Internet-Draft BGP IM July 2014 * A VPLS BGP NLRI has a VE ID, a VE Block offset (VBO), a * block offset size (VBS), and a Label base (LB). * Labels for local VE are (LB+VBS-1) and for the remote * (VBO+VBS-1). */ ::= ::= /* LENGTH of PW_route is prefix length of Route Distinguisher + * Global_ID + Prefix + AC ID in bits * default PW route = x length * other: length is between 96-160 bits */ ::= ::= | | | | | | | | ::= [] [] [] ::= ( | ) | ( | ) [ ] ::= ( | ) ( | ) [ ] ::= | Hares, et al. Expires January 2, 2015 [Page 35] Internet-Draft BGP IM July 2014 | < Nexthop_Unreachable> | < Malformed_PEER_DOWN> | < Malformed_DISCARD> | < Malformed_IGNORE> ::= | | | | | | | < Local_Preference | < route_type > | | < MED > /* BGP Policy */ ::= [ ::= [ ::= ::= ( ...) /* Policy Rule Extensions for BGP */ ::= ( ...) ::= ( ...) ::= ( ...) ::= [ ] [] [] [] [] [] [] [] [] [] [] [] ::= [] [] [comm_mod_args] ::= ::= (Peer_Session_Address ...); Hares, et al. Expires January 2, 2015 [Page 36] Internet-Draft BGP IM July 2014 ::= ( ..) ::= ( ..) :: = [ | ] ::= [ | /* community list */ [| ] ::= [] [] [] [] [] [] [] [] 6. IANA Considerations This draft includes no request to IANA. 7. Security Considerations TBD. 8. Informative References [I-D.hares-i2rs-info-model-policy] Hares, S. and W. Wu, "An Information Model for Network policy", draft-hares-i2rs-info-model-policy-02 (work in progress), March 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-04 (work in progress), June 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. Hares, et al. Expires January 2, 2015 [Page 37] Internet-Draft BGP IM July 2014 [I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, "RESTCONF Protocol", draft-ietf-netconf-restconf-00 (work in progress), March 2014. [I-D.keyupate-i2rs-bgp-usecases] Patel, K., Fernando, R., Gredler, H., Amante, S., White, R., and S. Hares, "Use Cases for an Interface to BGP Protocol", draft-keyupate-i2rs-bgp-usecases-03 (work in progress), June 2014. [I-D.white-i2rs-use-case] White, R., Hares, S., and A. Retana, "Protocol Independent Use Cases for an Interface to the Routing System", draft- white-i2rs-use-case-05 (work in progress), June 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. [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. Moore, "Policy Quality of Service (QoS) Information Model", RFC 3644, November 2003. [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008. [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009. [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, March 2012. Authors' Addresses Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 USA Email: shares@ndzh.com Hares, et al. Expires January 2, 2015 [Page 38] Internet-Draft BGP IM July 2014 Lixing Wang Huawei Beijing PRC Email: wanglixing@huawei.com Shunwan Zhuang Huawei Beijing PRC Email: Zhuangshunwan@huawei.com Hares, et al. Expires January 2, 2015 [Page 39]