--- 1/draft-ietf-i2rs-rib-info-model-15.txt 2018-05-02 01:13:10.495440985 -0700 +++ 2/draft-ietf-i2rs-rib-info-model-16.txt 2018-05-02 01:13:10.555442418 -0700 @@ -1,21 +1,21 @@ Network Working Group N. Bahadur, Ed. Internet-Draft Uber Intended status: Informational S. Kini, Ed. -Expires: September 30, 2018 +Expires: November 3, 2018 J. Medved Cisco - March 29, 2018 + May 2, 2018 Routing Information Base Info Model - draft-ietf-i2rs-rib-info-model-15 + draft-ietf-i2rs-rib-info-model-16 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 September 30, 2018. + This Internet-Draft will expire on November 3, 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 @@ -229,39 +229,39 @@ | 0..N | route(s) Figure 2: RIB model 2.1. RIB definition A RIB, in the context of the RIB information model, is an entity that contains routes. It is identified by its name and is contained - within a routing instance (Section 2.2). There MAY be many routing - instances and each routing instance MAY contain RIBs. The name MUST - be unique within a routing instance. All routes in a given RIB MUST - be of the same rib family (e.g., IPv4). Each RIB MUST belong to a - routing instance. + within a routing instance (Section 2.2). A network device MAY + contain routing instances and each routing instance MAY contain RIBs. - A routing instance MAY even have two or more RIBs of the same rib + The name MUST be unique within a routing instance. All routes in a + given RIB MUST be of the same address family (e.g., IPv4). Each RIB + MUST belong to a routing instance. + + A routing instance may contain two or more RIBs of the same address family (e.g., IPv6). A typical case where this can be used is for multi-topology routing ([RFC4915], [RFC5120]). - Each RIB MAY be optionally associated with an ENABLE_IP_RPF_CHECK - attribute that enables REVERSE PATH FORWARDING (RPF) checks on all IP - routes in that RIB. The RPF check is used to prevent spoofing and - limit malicious traffic. For IP packets, the IP source address is - looked up and the RPF interface(s) associated with the route for that - IP source address is found. If the incoming IP packet's interface - matches one of the RPF interface(s), then the IP packet is forwarded - based on its IP destination address; otherwise, the IP packet is - discarded. + Each RIB MAY be associated with an ENABLE_IP_RPF_CHECK attribute that + enables REVERSE PATH FORWARDING (RPF) checks on all IP routes in that + RIB. The RPF check is used to prevent spoofing and limit malicious + traffic. For IP packets, the IP source address is looked up and the + RPF interface(s) associated with the route for that IP source address + is found. If the incoming IP packet's interface matches one of the + RPF interface(s), then the IP packet is forwarded based on its IP + destination address; otherwise, the IP packet is discarded. 2.2. Routing instance A routing instance, in the context of the RIB information model, is a collection of RIBs, interfaces, and routing parameters. A routing 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 @@ -278,23 +278,24 @@ 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. + 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 optional 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 @@ -357,24 +358,24 @@ combine two filters). Each route MUST have associated with it the following mandatory route 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/32) with a preference of 5. + 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/32) with a preference of 2, then the controller's route + DB8::1/128) with a preference of 2, then the controller's route will be preferred by the RIB manager. Preference should be used to dictate behavior. For more examples of preference, see Section 7.1. Each route can have associated with it one or more optional route attributes. o route-vendor-attributes: Vendors can specify vendor-specific attributes using this. The details of this attribute is outside the scope of this document. @@ -612,21 +613,22 @@ 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. + applied to all member nexthops. Note: A weight of 0 is special + because of historical reasons. 2.4.3. Nexthop indirection 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 RIB client on request. One example of usage of indirection is a nexthop that points to another network device (Eg. BGP peer). The returned nexthop identifier can then be used for programming routes to point to the @@ -701,25 +703,25 @@ This section specifies the RIB information model in Routing Backus- Naur Form [RFC5511]. This grammar is intended to help the reader better understand Section 2 in order to derive a data model. ::= [] [] ::= ( ...) ::= ( ...) - ::= + ::= [ ... ] [ENABLE_IP_RPF_CHECK] - ::= | | - | + ::= | | + | ::= [] [] ::= | | | | ::= | | | |