--- 1/draft-ietf-i2rs-rib-info-model-16.txt 2018-05-07 21:13:09.703054628 -0700 +++ 2/draft-ietf-i2rs-rib-info-model-17.txt 2018-05-07 21:13:09.759055972 -0700 @@ -1,21 +1,21 @@ Network Working Group N. Bahadur, Ed. Internet-Draft Uber Intended status: Informational S. Kini, Ed. -Expires: November 3, 2018 +Expires: November 8, 2018 J. Medved Cisco - May 2, 2018 + May 7, 2018 Routing Information Base Info Model - draft-ietf-i2rs-rib-info-model-16 + draft-ietf-i2rs-rib-info-model-17 Abstract Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using a routing information base (RIB). Protocols and configuration push data into the RIB and the RIB manager installs state into the hardware for packet forwarding. This draft specifies an information model for the RIB to enable defining a standardized data model, and it was used by the IETF's I2RS WG to design the I2RS RIB data model. @@ -31,21 +31,21 @@ 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 November 3, 2018. + This Internet-Draft will expire on November 8, 2018. Copyright Notice Copyright (c) 2018 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 @@ -53,21 +53,21 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 5 2. RIB data . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1. RIB definition . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. RIB definition . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Routing instance . . . . . . . . . . . . . . . . . . . . . 6 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.1. Base nexthop . . . . . . . . . . . . . . . . . . . . . 12 2.4.2. Derived nexthops . . . . . . . . . . . . . . . . . . . 13 2.4.3. Nexthop indirection . . . . . . . . . . . . . . . . . 15 3. Reading from the RIB . . . . . . . . . . . . . . . . . . . . . 15 4. Writing to the RIB . . . . . . . . . . . . . . . . . . . . . . 15 5. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 16 6. RIB grammar . . . . . . . . . . . . . . . . . . . . . . . . . 16 @@ -92,26 +92,26 @@ 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction Routing and routing functions in enterprise and carrier networks are traditionally performed in network devices. Traditionally routers run routing protocols and the routing protocols (along with static - configuration information) populate the Routing information base + configuration information) populate the Routing Information Base (RIB) of the router. The RIB is managed by the RIB manager and the RIB manager provides a northbound interface to its clients, i.e., the routing protocols, to insert routes into the RIB. The RIB manager - consults the RIB and decides how to program the forwarding - information base (FIB) of the hardware by interfacing with the FIB + consults the RIB and decides how to program the Forwarding + Information Base (FIB) of the hardware by interfacing with the FIB manager. The relationship between these entities is shown in Figure 1. +-------------+ +-------------+ |RIB client 1 | ...... |RIB client N | +-------------+ +-------------+ ^ ^ | | +----------------------+ | @@ -176,21 +176,23 @@ Adding content to the RIB from a RIB client can be done today using static configuration mechanisms provided by router vendors. However the mix of what can be modified in the RIB varies from vendor to vendor and the method of configuring it is also vendor dependent. This makes it hard for a RIB client to program a multi-vendor network in a consistent and vendor-independent way. The purpose of this draft is to specify an information model for the RIB. Using the information model, one can build a detailed data model for the RIB. That data model could then be used by a RIB - client to program a network device. + client to program a network device. One data model that has been + based on this draft is the I2RS RIB data model + [I-D.ietf-i2rs-rib-data-model]. The rest of this document is organized as follows. Section 2 goes into the details of what constitutes and can be programmed in a RIB. Guidelines for reading and writing the RIB are provided in Section 3 and Section 4 respectively. Section 5 provides a high-level view of the events and notifications going from a network device to a RIB client, to update the RIB client on asynchronous events. The RIB grammar is specified in Section 6. Examples of using the RIB grammar are shown in Section 7. Section 8 covers considerations for performing RIB operations at scale. @@ -263,39 +264,39 @@ instance creates a logical slice of the router. It allows different logical slices across a set of routers to communicate with each other. Layer 3 Virtual Private Networks (VPN), Layer 2 VPNs (L2VPN) and Virtual Private Lan Service (VPLS) can be modeled as routing instances. Note that modeling a Layer 2 VPN using a routing instance only models the Layer-3 (RIB) aspect and does not model any layer-2 information (like ARP) that might be associated with the L2VPN. The set of interfaces indicates which interfaces are associated with this routing instance. The RIBs specify how incoming traffic is to - be forwarded. And the routing parameters control the information in + be forwarded, and the routing parameters control the information in the RIBs. The intersection set of interfaces of 2 routing instances MUST be the null set. In other words, an interface MUST NOT be present in 2 routing instances. Thus a routing instance describes the routing information and parameters across a set of interfaces. - A routing instance MUST contain the following mandatory fields. + A routing instance MUST contain the following mandatory fields: o INSTANCE_NAME: A routing instance is identified by its name, INSTANCE_NAME. This MUST be unique across all routing instances in a given network device. o rib-list: This is the list of RIBs associated with this routing instance. Each routing instance can have multiple RIBs to represent routes of different types. For example, one would put IPv4 routes in one RIB and MPLS routes in another RIB. The list of RIBs can be an empty list. - A routing instance MAY contain the following fields. + A routing instance MAY contain the following fields: o interface-list: This represents the list of interfaces associated with this routing instance. The interface list helps constrain the boundaries of packet forwarding. Packets coming in on these interfaces are directly associated with the given routing instance. The interface list contains a list of identifiers, with each identifier uniquely identifying an interface. o ROUTER_ID: This field identifies the network device in control plane interactions with other network devices. This field is to @@ -351,21 +352,21 @@ o MAC: Match on MAC destination addresses in the Ethernet header o Interface: Match on incoming interface of the packet A route MAY be matched on one or more these match types by policy as either an "AND" (to restrict the number of routes) or an "OR" (to combine two filters). Each route MUST have associated with it the following mandatory route - attributes. + attributes: o ROUTE_PREFERENCE: This is a numerical value that allows for comparing routes from different protocols. Static configuration is also considered a protocol for the purpose of this field. It is also known as administrative-distance. The lower the value, the higher the preference. For example there can be an OSPF route for 192.0.2.1/32 (or IPv6 2001:DB8::1/128) with a preference of 5. If a controller programs a route for 192.0.2.1/32 (or IPv6 2001: DB8::1/128) with a preference of 2, then the controller's route @@ -400,24 +401,24 @@ connected neighbor. For example, a nexthop to a point-to-point interface or a nexthop to an IP address on an Ethernet interface has the nexthop resolved. An unresolved nexthop is something that requires the RIB manager to determine the final resolved nexthop. For example, a nexthop could be an IP address. The RIB manager would resolve how to reach that IP address, e.g., is the IP address reachable by regular IP forwarding or by an MPLS tunnel or by both. If the RIB manager cannot resolve the nexthop, then the nexthop remains in an unresolved state and is NOT a candidate for installation in the FIB. Future RIB events can cause an unresolved - nexthop to get resolved (like that IP address being advertised by an - IGP neighbor). Conversely, resolved nexthops can also become - unresolved (e.g., in the case of a tunnel going down) and hence would - no longer be candidates to be installed in the FIB. + nexthop to get resolved (e.g., IP address being advertised by an IGP + neighbor). Conversely, resolved nexthops can also become unresolved + (e.g., in the case of a tunnel going down) and hence would no longer + be candidates to be installed in the FIB. When at least one of a route's nexthops is resolved, then the route can be used to forward packets. Such a route is considered eligible to be installed in the FIB and is henceforth referred to as a FIB- eligible route. Conversely, when all the nexthops of a route are unresolved that route can no longer be used to forward packets. Such a route is considered ineligible to be installed in the FIB and is henceforth referred to as a FIB-ineligible route. The RIB information model allows a RIB client to program routes whose nexthops may be unresolved initially. Whenever an unresolved nexthop @@ -571,21 +572,21 @@ o Preference lists - for protection using primary and backup o Replication lists - list of nexthops to which to replicate a packet o Nexthop chains - for chaining multiple operations or attaching multiple headers o Lists of lists - recursive application of the above - Nexthop chains (See Section 7.2.5 for usage) is a way to perform + Nexthop chains (See Section 7.2.5 for usage) are a way to perform multiple operations on a packet by logically combining them. For example, one can chain together "decapsulate MPLS header" and "send it out a specific EGRESS_INTERFACE". Chains can be used to specify multiple headers over a packet before a packet is forwarded. One simple example is that of MPLS over GRE, wherein the packet has an inner MPLS header followed by a GRE header followed by an IP header. The outermost IP header is decided by the network device whereas the MPLS header or GRE header are specified by the controller. Not every network device will be able to support all kinds of nexthop chains and an arbitrary number of headers chained together. The RIB data- @@ -1126,20 +1127,26 @@ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 12.2. Informative References + [I-D.ietf-i2rs-rib-data-model] + Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, + S., and N. Bahadur, "A YANG Data Model for Routing + Information Base (RIB)", draft-ietf-i2rs-rib-data-model-14 + (work in progress), May 2018. + [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, . [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/ RFC5120, February 2008, .