--- 1/draft-ietf-i2rs-rib-info-model-07.txt 2015-10-19 12:15:09.321683615 -0700 +++ 2/draft-ietf-i2rs-rib-info-model-08.txt 2015-10-19 12:15:09.373684875 -0700 @@ -1,21 +1,21 @@ Network Working Group N. Bahadur, Ed. Internet-Draft Bracket Computing Intended status: Informational S. Kini, Ed. -Expires: April 2, 2016 Ericsson +Expires: April 21, 2016 Ericsson J. Medved Cisco - September 30, 2015 + October 19, 2015 Routing Information Base Info Model - draft-ietf-i2rs-rib-info-model-07 + draft-ietf-i2rs-rib-info-model-08 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. Such a data model can be used to define an interface to the RIB from an @@ -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 April 2, 2016. + This Internet-Draft will expire on April 21, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -62,39 +62,39 @@ 2. RIB data . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. RIB definition . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Routing instance . . . . . . . . . . . . . . . . . . . . . 7 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.1. Nexthop types . . . . . . . . . . . . . . . . . . . . 11 2.4.2. Nexthop list attributes . . . . . . . . . . . . . . . 12 2.4.3. Nexthop content . . . . . . . . . . . . . . . . . . . 12 2.4.4. Special nexthops . . . . . . . . . . . . . . . . . . . 13 3. Reading from the RIB . . . . . . . . . . . . . . . . . . . . . 13 - 4. Writing to the RIB . . . . . . . . . . . . . . . . . . . . . . 13 + 4. Writing to the RIB . . . . . . . . . . . . . . . . . . . . . . 14 5. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 14 - 6. RIB grammar . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 6. RIB grammar . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Nexthop grammar explained . . . . . . . . . . . . . . . . 17 7. Using the RIB grammar . . . . . . . . . . . . . . . . . . . . 18 7.1. Using route preference . . . . . . . . . . . . . . . . . . 18 7.2. Using different nexthops types . . . . . . . . . . . . . . 18 7.2.1. Tunnel nexthops . . . . . . . . . . . . . . . . . . . 18 7.2.2. Replication lists . . . . . . . . . . . . . . . . . . 18 7.2.3. Weighted lists . . . . . . . . . . . . . . . . . . . . 19 7.2.4. Protection . . . . . . . . . . . . . . . . . . . . . . 19 7.2.5. Nexthop chains . . . . . . . . . . . . . . . . . . . . 20 7.2.6. Lists of lists . . . . . . . . . . . . . . . . . . . . 21 7.3. Performing multicast . . . . . . . . . . . . . . . . . . . 22 8. RIB operations at scale . . . . . . . . . . . . . . . . . . . 23 8.1. RIB reads . . . . . . . . . . . . . . . . . . . . . . . . 23 8.2. RIB writes . . . . . . . . . . . . . . . . . . . . . . . . 23 8.3. RIB events and notifications . . . . . . . . . . . . . . . 23 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction @@ -378,46 +378,51 @@ gets resolved, the RIB manager will send a notification of the same (see Section 5 ). The overall structure and usage of a nexthop is as shown in the figure below. route | | 0..N | - nexthop <-----------------+ + nexthop <-------------------------------+ | | - +-------+----------------------------+ | - | | | | | - | | | | | - base load-balance protection replicate | - | | | | | - | |2..N |2 |2..N | - | | V | | - | +------------->+<------------+ | + +-------+----------------------------+-------------+ | + | | | | | | + | | | | | | + base load-balance protection replicate chain | + | | | | | | + | |2..N |2..N |2..N |1..N | + | | | | | | + | | V | | | + | +------------->+<------------+-------------+ | | | | - | +-----------------------+ + | +-------------------------------------+ | +-------------------+ - | | - | nexthop-chain - | | - special-nexthop | 1..N | - nexthop-chain-member | | - +---------------+--------+---------+------------------+ + | + +---------------+--------+--------+--------------+ | | | | | | | | - nexthop-id egress-interface logical-tunnel tunnel-encap + nexthop-id egress-interface logical-tunnel | + | + | + +---------------------------+ + | + +--------------+-----------+ + | | | + | | | + tunnel-encap tunnel-decap special-nexthop Figure 4: Nexthop model Nexthops can be identified by an identifier to create a level of indirection. The identifier is set by the RIB manager and returned to the external entity on request. The RIB data-model SHOULD support a way to optionally receive a nexthop identifier for a given nexthop. For example, one can create a nexthop that points to a BGP peer. The returned nexthop identifier can then be used for programming routes to point to the same nexthop. Given that the RIB manager has created @@ -432,22 +437,22 @@ 2.4.1. Nexthop types This document specifies a very generic, extensible and recursive grammar for nexthops. Nexthops can be o Interface nexthops - pointing to an interface o Tunnel nexthops - pointing to a tunnel o Replication lists - list of nexthops to which to replicate a packet o Weighted lists - for load-balancing o Preference lists - for protection using primary and backup - o Nexthop chains - for chaining headers, e.g. MPLS label over a GRE - header + o Nexthop chains - for chaining multiple operations or attaching + multiple headers o Lists of lists - recursive application of the above o Indirect nexthops - pointing to a nexthop identifier o Special nexthops - for performing specific well-defined functions (e.g. drop) It is expected that all network devices will have a limit on how many levels of lookup can be performed and not all hardware will be able to support all kinds of nexthops. RIB capability negotiation becomes very important for this reason and a RIB data-model MUST specify a way for an external entity to learn about the network device's capabilities. Examples of when and how to use various kinds of @@ -455,56 +460,63 @@ Tunnel nexthops allow an external entity to program static tunnel headers. There can be cases where the remote tunnel end-point does not support dynamic signaling (e.g. no LDP support on a host) and in those cases the external entity might want to program the tunnel header on both ends of the tunnel. The tunnel nexthop is kept generic with specifications provided for some commonly used tunnels. It is expected that the data-model will model these tunnel types with complete accuracy. - Nexthop 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 and 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 header chained together. The RIB data-model SHOULD provide a way - to expose nexthop chaining capability supported by a given network - device. + Nexthop chains Section 7.2.5, is 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 and + 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 header chained together. The RIB data-model SHOULD provide + a way to expose nexthop chaining capability supported by a given + network device. 2.4.2. Nexthop list attributes For nexthops that are of the form of a list(s), attributes can be associated with each member of the list to indicate the role of an individual member of the list. Two attributes are specified: o NEXTHOP_PREFERENCE: This is used for protection schemes. It is an integer value between 1 and 99. A lower value indicates higher preference. To download a primary/standby pair to the FIB, the nexthops that are resolved and have two highest preferences are - selected. + selected. Each should have a unique value + within a + * + (Section 6). o NEXTHOP_LB_WEIGHT: This is used for load-balancing. Each list member MUST be assigned a weight between 1 and 99. The weight determines the proportion of traffic to be sent over a nexthop used for forwarding as a ratio of the weight of this nexthop divided by the weights of all the nexthops of this route that are used for forwarding. To perform equal load-balancing, one MAY specify a weight of "0" for all the member nexthops. The value "0" is reserved for equal load-balancing and if applied, MUST be applied to all member nexthops. 2.4.3. Nexthop content At the lowest level, a nexthop can be one of: o identifier: This is an identifier returned by the network device - representing another nexthop or another nexthop chain. + representing a nexthop. This can be used as a way of re-using a + nexthop when programming complex nexthops. o EGRESS_INTERFACE: This represents a physical, logical or virtual interface on the network device. Address resolution must not be required on this interface. This interface may belong to any routing instance. o IP address: A route lookup on this IP address is done to determine the egress interface. Address resolution may be required depending on the interface. * An optional RIB name can also be specified to indicate the RIB in which the IP address is to be looked up. One can use the RIB name field to direct the packet from one domain into @@ -503,32 +515,36 @@ required on this interface. This interface may belong to any routing instance. o IP address: A route lookup on this IP address is done to determine the egress interface. Address resolution may be required depending on the interface. * An optional RIB name can also be specified to indicate the RIB in which the IP address is to be looked up. One can use the RIB name field to direct the packet from one domain into another domain. By default the RIB will be the same as the one that route belongs to. + o EGRESS_INTERFACE and IP address: This can be used in cases e.g. where the IP address is a link-local address. o EGRESS_INTERFACE and MAC address: The egress interface must be an ethernet interface. Address resolution is not required for this nexthop. o tunnel encap: This can be an encap representing an IP tunnel or MPLS tunnel or others as defined in this document. An optional - egress interface can be specified to indicate which interface to - send the packet out on. The egress interface is useful when the - network device contains Ethernet interfaces and one needs to - perform address resolution for the IP packet. - + egress interface can be chained to the tunnel encap to indicate + which interface to send the packet out on. The egress interface + is useful when the network device contains Ethernet interfaces and + one needs to perform address resolution for the IP packet. + o tunnel decap: This is to specify decapsulating a tunnel header. + After decap, further lookup on the packet can be done via chaining + it with another nexthop. The packet can also be sent out via a + EGRESS_INTERFACE directly. o logical tunnel: This can be a MPLS LSP or a GRE tunnel (or others as defined in this document), that is represented by a unique identifier (E.g. name). o RIB_NAME: A nexthop pointing to a RIB indicates that the route lookup needs to continue in the specified RIB. This is a way to perform chained lookups. 2.4.4. Special nexthops This document specifies certain special nexthops. The purpose of @@ -564,36 +580,36 @@ 4. Writing to the RIB A RIB data-model MUST allow an external entity to write entries, for RIBs created by that entity. The network device administrator MAY allow writes to other RIBs by an external entity through access lists on the network device. The details of access lists are outside the scope of this document. When writing an object to a RIB, the external entity SHOULD try to write all dependencies of the object prior to sending that object. - The data-model MUST support requesting identifiers for nexthops and + The data-model SHOULD support requesting identifiers for nexthops and collecting the identifiers back in the response. Route programming in the RIB MUST result in a return code that contains the following attributes: o Installed - Yes/No (Indicates whether the route got installed in the FIB) o Active - Yes/No (Indicates whether a route is fully resolved and is a candidate for selection) o Reason - E.g. Not authorized The data-model MUST specify which objects are modify-able objects. A modify-able object is one whose contents can be changed without having to change objects that depend on it and without affecting any data forwarding. To change a non-modifiable object, one will need to create a new object and delete the old one. For example, routes that - use a nexthop that is identified by a nexthop-identifier should be + use a nexthop that is identified by a nexthop identifier should be unaffected when the contents of that nexthop changes. 5. Notifications Asynchronous notifications are sent by the network device's RIB manager to an external entity when some event occurs on the network device. A RIB data-model MUST support sending asynchronous notifications. A brief list of suggested notifications is as below: o Route change notification, with return code as specified in Section 4 @@ -617,22 +634,20 @@ ::= [ ... ] [ENABLE_IP_RPF_CHECK] ::= | | | ::= [] [] - ::= ( | | | - | ) ::= | | | | ::= | | | | ::= ( | | ( )) ::= ::= @@ -649,58 +664,54 @@ ::= [] [] ::= | | ::= <> ::= <> ::= <> ::= <> - ::= | | - | - ::= - ( ) ... - is a number between 1 and 99. - ::= - - = - ( )... - Each should have a unique value within a - . - - ::= ... - - ::= | + ::= | | + | | + - ::= ... - ::= | - - ::= | + ::= | + | | | | - ( ( | )) | + ( + ( | )) | ( ) | - ( []) | + | | | ) ::= - ::= | - ::= | | ( []) + ::= + ( = + ( )... + + ::= ... + + ::= ... + ::= ::= | | | | | + ::= ( ) | ( ) | ( ) | ( ) | ( ) | ( ) ::= [] [] @@ -704,29 +715,34 @@ ::= [] [] ::= [] [] [] ::= ( ...) ::= ( [] [] []) | - ( []) + ( + []) ::= [] ::= ( | ) [] ::= ( | ) [] + ::= (( []) | + ( []) | + ( [])) + Figure 5: RIB rBNF grammar 6.1. Nexthop grammar explained A nexthop is used to specify the next network element to forward the traffic to. It is also used to specify how the traffic should be load-balanced, protected using preference or multicasted using replication. This is explicitly specified in the grammar. The nexthop has recursion built-in to address complex use-cases like the one defined in Section 7.2.6. @@ -755,21 +771,24 @@ 7.2. Using different nexthops types The RIB grammar allows one to create a variety of nexthops. This section describes uses for certain types of nexthops. 7.2.1. Tunnel nexthops A tunnel nexthop points to a tunnel of some kind. Traffic that goes over the tunnel gets encapsulated with the tunnel encap. Tunnel nexthops are useful for abstracting out details of the network, by - having the traffic seamlessly route between network edges. + having the traffic seamlessly route between network edges. At the + end of a tunnel, the tunnel will get decapsulated. Thus the grammar + supports two kinds of operations, one for encap and another for + decap. 7.2.2. Replication lists One can create a replication list for replicating traffic to multiple destinations. The destinations, in turn, could be complex nexthops in themselves - at a level supported by the network device. Point to multipoint and broadcast are examples that involve replication. A replication list (at the simplest level) can be represented as: @@ -789,22 +808,22 @@ A weighted list (at the simplest level) can be represented as: ::= ( ) [( )... ] The above can be derived from the grammar as follows: ::= ::= - - ( ) ... + + ( ) ... ::= ( ) ( ) ... 7.2.4. Protection A primary/backup protection can be represented as: ::= <1> <2> ) @@ -826,46 +845,59 @@ ::= (<1> ( ( ( ) ...)) <2> ) A backup can also have another backup. In such a case, the list will look like: ::= (<1> - <2> <3> ) + <2> (<1> <2> )) 7.2.5. Nexthop chains - A nexthop chain specifies how to put one or more headers on an + A nexthop chain is a way to perform multiple operations on a packet + by logically combining them. For example, when a VPN packet comes on + the WAN interface and has to be forwarded to the correct VPN + interface, one needs to POP the VPN label before sending the packet + out. Using a nexthop chain, one can chain together "pop MPLS header" + and "send it out a specific EGRESS_INTERFACE". + + The above example can be derived from the grammar as follows: + + ::= + ::= + ::= + ::= ( ) + + Elements in a nexthop-chain are evaluated left to right. + + A nexthop chain can also be used to put one or more headers on an outgoing packet. One example is a Pseudowire - which is MPLS over some transport (MPLS or GRE for instance). Another example is VxLAN - over IP. A nexthop chain allows an external entity to break up the - programming of the nexthop into independent pieces - one per + over IP. A nexthop chain thus allows an external entity to break up + the programming of the nexthop into independent pieces - one per encapsulation. - Elements in a nexthop-chain are evaluated left to right. - A simple example of MPLS over GRE can be represented as: - ::= ( ) ( - ) + ::= ( ) ( ) + The above can be derived from the grammar as follows: - ::= [ ...] - ::= ( - ) - ::= ( ) - ::= ( ) ( - ) + ::= + ::= + ::= + ::= ( ) ( ) + 7.2.6. Lists of lists Lists of lists is a complex construct. One example of usage of such a construct is to replicate traffic to multiple destinations, with load balancing. In other words, for each branch of the replication tree, there are multiple interfaces on which traffic needs to be load-balanced on. So the outer list is a replication list for multicast and the inner lists are weighted lists for load balancing. Lets take an example of a network element has to replicate traffic to @@ -876,43 +908,37 @@ outgoing-2-3 in the ratio 20:20:60. This can be derived from the grammar as follows: ::= ::= ( ...) ::= ( ) ::= (( ) ( )) ::= (( - ( - ( ) ...)) - (( - ( - ( ) ...)) - ::= (( - ( - ( ))) + ( + ( ) ...)) (( - ( - ( ) - ( ))) + ( + ( ) ...)) ::= (( - ( ) - ( ))) + ( + ( ))) (( - ( ) - ( ) - ( ))) + ( + ( ) + ( ))) ::= (( ( ) ( ))) - (( ( ) + (( + ( ) ( ) ( ))) ::= (( (50 ) (50 ))) (( (20 ) (20 ) (60 ))) @@ -981,25 +1007,26 @@ external agent MUST send requests to the RIB manager that comply with the supported data-model. The data-model MUST specify the behavior of the RIB manager on handling of unsupported data requests. 10. IANA Considerations This document does not generate any considerations for IANA. 11. Acknowledgements - The authors would like to thank Ron Folkes, the working group co- - chairs and reviewers on their comments and suggestions on this draft. - The following people contributed to the design of the RIB model as - part of the I2RS Interim meeting in April 2013 - Wes George, Chris - Liljenstolpe, Jeff Tantsura, Susan Hares and Fabian Schneider. + The authors would like to thank Ron Folkes, Jeffrey Zhang, the + working group co-chairs and reviewers on their comments and + suggestions on this draft. The following people contributed to the + design of the RIB model as part of the I2RS Interim meeting in April + 2013 - Wes George, Chris Liljenstolpe, Jeff Tantsura, Susan Hares and + Fabian Schneider. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . @@ -1037,24 +1064,25 @@ [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, . Authors' Addresses Nitin Bahadur (editor) Bracket Computing - 320 Soquel Way - Sunnyvale, CA 94085 + 150 West Evelyn Ave, Suite 200 + Mountain View, CA 94041 US Email: nitin_bahadur@yahoo.com Sriganesh Kini (editor) Ericsson Email: sriganesh.kini@ericsson.com + Jan Medved Cisco Email: jmedved@cisco.com