draft-nitinb-i2rs-rib-info-model-00.txt   draft-nitinb-i2rs-rib-info-model-01.txt 
Network Working Group N. Bahadur, Ed. Network Working Group N. Bahadur, Ed.
Internet-Draft R. Folkes, Ed. Internet-Draft R. Folkes, Ed.
Intended status: Informational Juniper Networks, Inc. Intended status: Informational Juniper Networks, Inc.
Expires: December 27, 2013 S. Kini Expires: January 16, 2014 S. Kini
Ericsson Ericsson
June 25, 2013 J. Medved
Cisco
July 15, 2013
Routing Information Base Info Model Routing Information Base Info Model
draft-nitinb-i2rs-rib-info-model-00 draft-nitinb-i2rs-rib-info-model-01
Abstract Abstract
Routing and routing functions in enterprise and carrier networks are Routing and routing functions in enterprise and carrier networks are
typically performed by network devices (routers and switches) using a typically performed by network devices (routers and switches) using a
routing information base (RIB). Protocols and configuration push routing information base (RIB). Protocols and configuration push
data into the RIB and the RIB manager install state into the data into the RIB and the RIB manager install state into the
hardware; for packet forwarding. This draft specifies an information hardware; for packet forwarding. This draft specifies an information
model for the RIB, to build a standardized RIB model, using which an model for the RIB to enable defining a standardized data model. Such
external entity (external to the network device) can read and write a data model can be used to define an interface to the RIB from an
information from/to the RIB. entity that may even be external to the network device. This
interface can be used to support new use-cases being defined by the
IETF I2RS WG.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 27, 2013. This Internet-Draft will expire on January 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions used in this document . . . . . . . . . . . . 5 1.1. Conventions used in this document . . . . . . . . . . . . 6
2. RIB data . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. RIB data . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. RIB definition . . . . . . . . . . . . . . . . . . . . . . 5 2.1. RIB definition . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Routing tables . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Routing tables . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1. Nexthop types . . . . . . . . . . . . . . . . . . . . 9 2.4.1. Nexthop types . . . . . . . . . . . . . . . . . . . . 10
2.4.2. Nexthop list attributes . . . . . . . . . . . . . . . 10 2.4.2. Nexthop list attributes . . . . . . . . . . . . . . . 11
2.4.3. Nexthop content . . . . . . . . . . . . . . . . . . . 10 2.4.3. Nexthop content . . . . . . . . . . . . . . . . . . . 11
2.4.4. Nexthop attributes . . . . . . . . . . . . . . . . . . 11 2.4.4. Nexthop attributes . . . . . . . . . . . . . . . . . . 12
2.4.5. Special nexthops . . . . . . . . . . . . . . . . . . . 11 2.4.5. Nexthop vendor attributes . . . . . . . . . . . . . . 13
3. Reading from the RIB . . . . . . . . . . . . . . . . . . . . . 11 2.4.6. Special nexthops . . . . . . . . . . . . . . . . . . . 13
4. Writing to the RIB . . . . . . . . . . . . . . . . . . . . . . 12 3. Reading from the RIB . . . . . . . . . . . . . . . . . . . . . 14
5. Events and Notifications . . . . . . . . . . . . . . . . . . . 12 4. Writing to the RIB . . . . . . . . . . . . . . . . . . . . . . 14
6. RIB grammar . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Events and Notifications . . . . . . . . . . . . . . . . . . . 14
7. Using the RIB grammar . . . . . . . . . . . . . . . . . . . . 15 6. RIB grammar . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Using route preference and metric . . . . . . . . . . . . 15 7. Using the RIB grammar . . . . . . . . . . . . . . . . . . . . 17
7.2. Using different nexthops types . . . . . . . . . . . . . . 16 7.1. Using route preference and metric . . . . . . . . . . . . 18
7.2.1. Tunnel nexthops . . . . . . . . . . . . . . . . . . . 16 7.2. Using different nexthops types . . . . . . . . . . . . . . 18
7.2.2. Replication lists . . . . . . . . . . . . . . . . . . 16 7.2.1. Tunnel nexthops . . . . . . . . . . . . . . . . . . . 18
7.2.3. Weighted lists . . . . . . . . . . . . . . . . . . . . 16 7.2.2. Replication lists . . . . . . . . . . . . . . . . . . 18
7.2.4. Protection lists . . . . . . . . . . . . . . . . . . . 17 7.2.3. Weighted lists . . . . . . . . . . . . . . . . . . . . 19
7.2.5. Nexthop chains . . . . . . . . . . . . . . . . . . . . 17 7.2.4. Protection lists . . . . . . . . . . . . . . . . . . . 19
7.2.6. Lists of lists . . . . . . . . . . . . . . . . . . . . 18 7.2.5. Nexthop chains . . . . . . . . . . . . . . . . . . . . 20
7.3. Solving optimized exit control . . . . . . . . . . . . . . 18 7.2.6. Lists of lists . . . . . . . . . . . . . . . . . . . . 20
8. RIB operations at scale . . . . . . . . . . . . . . . . . . . 19 7.3. Performing multicast . . . . . . . . . . . . . . . . . . . 20
8.1. RIB reads . . . . . . . . . . . . . . . . . . . . . . . . 19 7.4. Solving optimized exit control . . . . . . . . . . . . . . 21
8.2. RIB writes . . . . . . . . . . . . . . . . . . . . . . . . 19 8. RIB operations at scale . . . . . . . . . . . . . . . . . . . 21
8.3. RIB events and notifications . . . . . . . . . . . . . . . 19 8.1. RIB reads . . . . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8.2. RIB writes . . . . . . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8.3. RIB events and notifications . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Routing and routing functions in enterprise and carrier networks are Routing and routing functions in enterprise and carrier networks are
traditionally performed in network devices. Traditionally routers traditionally performed in network devices. Traditionally routers
run routing protocols and the routing protocols (along with static run routing protocols and the routing protocols (along with static
config) populates the Routing information base (RIB) of the router. config) populates the Routing information base (RIB) of the router.
The RIB is managed by the RIB manager and it provides a north-bound The RIB is managed by the RIB manager and it provides a north-bound
interface to its clients i.e. the routing protocols to insert routes 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 into the RIB. The RIB manager consults the RIB and decides how to
skipping to change at page 3, line 51 skipping to change at page 4, line 51
| | FIB | | | | FIB | | | | FIB | | | | FIB | |
| +-----+ | | +-----+ | | +-----+ | | +-----+ |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 1: RIB-Manager, RIB-Clients and FIB-Managers Figure 1: RIB-Manager, RIB-Clients and FIB-Managers
Routing protocols are inherently distributed in nature and each Routing protocols are inherently distributed in nature and each
router makes an independent decision based on the routing data router makes an independent decision based on the routing data
received from its peers. With the advent of newer deployment received from its peers. With the advent of newer deployment
paradigms and the need for specialized applications, there is an paradigms and the need for specialized applications, there is an
emerging need to guide the router's routing function ( emerging need to guide the router's routing function
[I-D.atlas-i2rs-problem-statement]). Traditional protocol-based RIB [I-D.atlas-i2rs-problem-statement]. Traditional network-device
population suffices for most use cases where distributed network protocol-based RIB population suffices for most use cases where
control works. However there are use cases in which the network distributed network control works. However there are use cases in
admins today configure static routes, policies and RIB import/export which the network admins today configure static routes, policies and
rules on the routers. There is also a growing list of use cases ( RIB import/export rules on the routers. There is also a growing list
[I-D.white-i2rs-use-case], [I-D.hares-i2rs-use-case-vn-vc] ) in which of use cases [I-D.white-i2rs-use-case],
a network admin might want to program the RIB based on data unrelated [I-D.hares-i2rs-use-case-vn-vc] in which a network admin might want
to just routing (within that network's domain). It could be based on to program the RIB based on data unrelated to just routing (within
routing data in adjacent domain or it could be based on load on that network's domain). It could be based on routing data in
storage and compute in the given domain. Or it could simply be a adjacent domain or it could be based on load on storage and compute
programmatic way of creating on-demand dynamic overlays between in the given domain. Or it could simply be a programmatic way of
compute hosts (without requiring the hosts to run traditional routing creating on-demand dynamic overlays between compute hosts (without
protocols). If there was a standardized programmatic interface to a requiring the hosts to run traditional routing protocols). If there
RIB, it would fuel further networking applications targeted towards was a standardized programmatic interface to a RIB, it would fuel
specific niches. further networking applications targeted towards specific niches.
Programming the RIB involves 2 parts - reading what's in the RIB and A programmatic interface to the RIB involves 2 types of operations -
adding/modifying/deleting contents of the RIB. reading what's in the RIB and adding/modifying/deleting contents of
[I-D.white-i2rs-use-case] lists various use-cases which require read the RIB. [I-D.white-i2rs-use-case] lists various use-cases which
and/or write manipulation of the RIB. require read and/or write manipulation of the RIB.
In order to understand what is in a router's RIB, methods like per- In order to understand what is in a router's RIB, methods like per-
protocol SNMP MIBs and show output screen scraping are being used. protocol SNMP MIBs and show output screen scraping are being used.
These methods are not scalable, since they are client pull mechanisms These methods are not scalable, since they are client pull mechanisms
and not proactive push (from the router) mechanisms. Screen scraping and not proactive push (from the router) mechanisms. Screen scraping
is error prone (since output can change) and vendor dependent. is error prone (since output can change) and vendor dependent.
Building a RIB from per-protocol MIBs is error prone since the MIB Building a RIB from per-protocol MIBs is error prone since the MIB
data represents protocol data and not the exact information that went data represents protocol data and not the exact information that went
into the RIB. Thus, just getting read-only RIB information from a into the RIB. Thus, just getting read-only RIB information from a
router is a hard task. router is a hard task.
skipping to change at page 4, line 48 skipping to change at page 5, line 48
This makes it hard for an external entity to program a multi-vendor This makes it hard for an external entity to program a multi-vendor
network in a consistent and vendor independent way. network in a consistent and vendor independent way.
The purpose of this draft is to specify an information model for the The purpose of this draft is to specify an information model for the
RIB. Using the information model, one can build a detailed data RIB. Using the information model, one can build a detailed data
model for the RIB. And that data model could then be used by an model for the RIB. And that data model could then be used by an
external entity to program a router. external entity to program a router.
The rest of this document is organized as follows. Section 2.1 goes The rest of this document is organized as follows. Section 2.1 goes
into the details of what constitutes and can be programmed in a RIB. into the details of what constitutes and can be programmed in a RIB.
The RIB grammar is specified in Section 6. Examples of using the RIB Section 5 provides a high-level view of the events and notifications
grammar are shown in Section 7. Section 5 provides a high-level view going from a network device to an external entity, to update the
of the events and notifications going from a network device to an external entity on asynchronous events. The RIB grammar is specified
external entity, to update the external entity on asynchronous in Section 6. Examples of using the RIB grammar are shown in
events. Section 7.
1.1. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. RIB data 2. RIB data
This section describes the details of a RIB. It makes forward This section describes the details of a RIB. It makes forward
references to objects in the RIB grammar (Section 6). references to objects in the RIB grammar (Section 6).
2.1. RIB definition 2.1. RIB definition
A RIB contains one or more routing instances. On a network device, a A RIB is a logical construct controlled by an external entity. A RIB
RIB is uniquely identified by its name. A routing instance can be in contains one or more routing instances. On a network device, a RIB
only 1 RIB. A routing instance is a collection of routing tables, is uniquely identified by its name. A routing instance can be in
interfaces, and routing parameters. A routing instance creates a only 1 RIB. A routing instance, in the context of the RIB
logical slice of the router and allows different logical slices; information model, is a collection of routing tables, interfaces, and
across a set of routers; to communicate with other each. Layer 3 routing parameters. A routing instance creates a logical slice of
VPNs, Layer 2 VPNs and VPLS are modeled as routing instances. The the router and allows different logical slices; across a set of
set of interfaces indicates which interfaces this RIB has control routers; to communicate with other each. Layer 3 Virtual Private
over. The routing tables specify how incoming traffic is to be Networks (VPN), Layer 2 VPNs (L2VPN) and Virtual Private Lan Service
forwarded. And the routing parameters control the information in the (VPLS) can be modeled as routing instances. Note that modeling a
routing tables. The intersection set of interfaces of 2 routing Layer 2 VPN using a routing instance only models the Layer-3 (RIB)
instances MUST be the null set. In other words, an interface should aspect and does not model any layer-2 information (like ARP) that
not be present in 2 routing instances. Thus a routing instance might be associated with the L2VPN.
describes the routing policy and parameters across a set of
interfaces. The set of interfaces indicates which interfaces this routing
instance has control over. The routing tables specify how incoming
traffic is to be forwarded. And the routing parameters control the
information in the routing tables. The intersection set of
interfaces of 2 routing instances MUST be the null set. In other
words, an interface should 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, o INSTANCE_NAME: A routing instance is identified by its name,
INSTANCE_NAME. INSTANCE_NAME.
o INSTANCE_DISTINGUISHER: Each routing instance must have a unique o INSTANCE_DISTINGUISHER: Each routing instance must have a unique
distinguisher associated with it. It enables one to distinguish distinguisher associated with it. It enables one to distinguish
routes across routing instances. The route distinguisher MUST be routes across routing instances. The route distinguisher SHOULD
unique across all routing instances in a given network device. be unique across all routing instances in a given network device.
How the INSTANCE_DISTINGUISHER is allocated and kept unique is How the INSTANCE_DISTINGUISHER is allocated and kept unique is
outside the scope of this document. The instance distinguisher outside the scope of this document. The instance distinguisher
maps well to BGP route-distinguisher for virtual private networks maps well to BGP route-distinguisher for virtual private networks
(VPNs). However, the same concept can be used for other use-cases (VPNs). However, the same concept can be used for other use-cases
as well. as well.
o routing-table-list: This is the list of routing tables associated o routing-table-list: This is the list of routing tables associated
with this routing instance. Each routing instance can have with this routing instance. Each routing instance can have
multiple tables to represent routes of different types. For multiple tables to represent routes of different types. For
example, one would put IPv4 routes in one table and MPLS routes in example, one would put IPv4 routes in one table and MPLS routes in
another table. another table.
skipping to change at page 6, line 39 skipping to change at page 7, line 46
IPv4). Each routing table MUST belong to some routing instance. IPv4). Each routing table MUST belong to some routing instance.
A routing table can be tagged with a MULTI_TOPOLOGY_ID. If a routing A routing table can be tagged with a MULTI_TOPOLOGY_ID. If a routing
instance is divided into multiple logical topologies, then the multi- instance is divided into multiple logical topologies, then the multi-
topology field is used to distinguish one topology from the other, so topology field is used to distinguish one topology from the other, so
as to keep routes from one topology independent of routes from as to keep routes from one topology independent of routes from
another topology. another topology.
If a routing instance contains multiple tables of the same type (e.g. If a routing instance contains multiple tables of the same type (e.g.
IPv4), then a MULTI_TOPOLOGY_ID MUST be associated with each such IPv4), then a MULTI_TOPOLOGY_ID MUST be associated with each such
table. In other words, multiple tables MUST be used only when there table. Multiple tables are useful when describing multiple topology
are multiple topologies. In a given routing instance, IGP (Interior Gateway Protocol) networks (see [RFC4915] and [RFC5120]
MULTI_TOPOLOGY_ID MUST be unique across routing tables of the same ). In a given routing instance, MULTI_TOPOLOGY_ID MUST be unique
type. across routing tables of the same type.
Each route table can be optionally associated with a Each route table can be optionally associated with a
ENABLE_IP_RPF_CHECK attribute that enables Reverse path forwarding ENABLE_IP_RPF_CHECK attribute that enables Reverse path forwarding
(RPF) checks on all IP routes in that table. Reverse path forwarding (RPF) checks on all IP routes in that table. Reverse path forwarding
(RPF) check is used to prevent spoofing and limit malicious traffic. (RPF) check is used to prevent spoofing and limit malicious traffic.
For IP packets, the IP source address is looked up and the rpf 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 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 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 interface(s), then the IP packet is forwarded based on its IP
destination address; otherwise, the IP packet is discarded. destination address; otherwise, the IP packet is discarded.
skipping to change at page 7, line 17 skipping to change at page 8, line 24
A route is essentially a match condition and an action following the A route is essentially a match condition and an action following the
match. The match condition specifies the kind of route (IPv4, MPLS, match. The match condition specifies the kind of route (IPv4, MPLS,
etc.) and the set of fields to match on. This document specifies the etc.) and the set of fields to match on. This document specifies the
following match types: following match types:
o IPv4: Match on destination IP in IPv4 header o IPv4: Match on destination IP in IPv4 header
o IPv6: Match on destination IP in IPv6 header o IPv6: Match on destination IP in IPv6 header
o MPLS: Match on a MPLS tag o MPLS: Match on a MPLS tag
o MAC: Match on ethernet destination addresses o MAC: Match on ethernet destination addresses
o Interface: Match on incoming interface of packet o Interface: Match on incoming interface of packet
o IP multicast: Match on (S, G) or (*, G), where S and G are IP
prefixes
Each route can have associated with it one or more optional route Each route can have associated with it one or more optional route
attributes. attributes.
o ROUTE_PREFERENCE: This is a numerical value that allows for o ROUTE_PREFERENCE: This is a numerical value that allows for
comparing routes from different protocols. It is also known as comparing routes from different protocols. It is also known as
administrative-distance. The lower the value, the higher the administrative-distance. The lower the value, the higher the
preference. For example there can be an OSPF route for preference. For example there can be an OSPF route for
192.0.2.1/32 with a preference of 5. If a controller programs a 192.0.2.1/32 with a preference of 5. If a controller programs a
route for 192.0.2.1/32 with a preference of 2, then the controller route for 192.0.2.1/32 with a preference of 2, then the controller
entered route will be preferred by the RIB manager. Preference entered route will be preferred by the RIB manager. Preference
skipping to change at page 9, line 19 skipping to change at page 10, line 28
2.4.1. Nexthop types 2.4.1. Nexthop types
This document specifies a very generic, extensible and recursive This document specifies a very generic, extensible and recursive
grammar for nexthops. Nexthops can be grammar for nexthops. Nexthops can be
o Unicast nexthops - pointing to an interface o Unicast nexthops - pointing to an interface
o Tunnel nexthops - pointing to a tunnel o Tunnel nexthops - pointing to a tunnel
o Replication lists - list of nexthops to which to replicate a o Replication lists - list of nexthops to which to replicate a
packet to packet to
o Weighted lists - for load-balancing o Weighted lists - for load-balancing
o Protection lists - for primary/backup paths o Protection lists - for primary/backup paths
o Nexthop chains - chaining headers, e.g. MPLS label over a GRE o Nexthop chains - for chaining headers, e.g. MPLS label over a GRE
header header
o Lists of lists - recursive application of the above o Lists of lists - recursive application of the above
o Indirect nexthops - pointing to a nexthop identifier o Indirect nexthops - pointing to a nexthop identifier
o Special nexthops - for performing specific well-defined functions
It is expected that all network devices will have a limit on It is expected that all network devices will have a limit on
recursion and not all hardware will be able to support all kinds of recursion and not all hardware will be able to support all kinds of
nexthops. RIB capability negotiation becomes very important for this nexthops. RIB capability negotiation becomes very important for this
reason and a RIB data-model MUST specify a way for an external entity 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 to learn about the network device's capabilities. Examples of when
and how to use various kinds of nexthops are shown in Section 7.2. and how to use various kinds of nexthops are shown in Section 7.2.
Tunnel nexthops allow an external entity to program static tunnel Tunnel nexthops allow an external entity to program static tunnel
headers. There can be cases where the remote tunnel end-point does 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 not support dynamic signaling (e.g. no LDP support on a host) and in
skipping to change at page 10, line 43 skipping to change at page 12, line 4
list members. To perform equal load-balancing, one MAY specify a list members. To perform equal load-balancing, one MAY specify a
weight of "0" for all the member nexthops. The value "0" is weight of "0" for all the member nexthops. The value "0" is
reserved for equal load-balancing and if applied, MUST be applied reserved for equal load-balancing and if applied, MUST be applied
to all member nexthops. to all member nexthops.
2.4.3. Nexthop content 2.4.3. Nexthop content
At the lowest level, a nexthop can point to a: At the lowest level, a nexthop can point to a:
o identifier: This is an identifier returned by the network device o identifier: This is an identifier returned by the network device
representing another nexthop or another nexthop chain. representing another nexthop or another nexthop chain.
o INTERFACE_IDENTIFIER: This represents a physical, logical or
virtual interface on the network device. o EGRESS_INTERFACE: This represents a physical, logical or virtual
interface on the network device.
o address: This can be an IP address or MAC address or ISO address. o address: This can be an IP address or MAC address or ISO address.
An optional table name can also be specified to indicate the table * An optional table name can also be specified to indicate the
in which the address is to be looked up further. By default the table in which the address is to be looked up further. One can
table will be the same in which the route lookup was performed. use the table name field to direct the packet from one domain
into another domain. For example, a MPLS packet coming in on
an interface would be looked up in a MPLS routing table and the
nexthop for that could indicate that we strip the MPLS label
and do a subsequent IPv4 lookup in an IPv4 table. By default
the table will be the same in which the route lookup was
performed.
* 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 an ARP lookup for the IP packet.
o tunnel encap: This can be an encap representing an IP tunnel or o tunnel encap: This can be an encap representing an IP tunnel or
MPLS tunnel or others as defined in this document 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 an ARP lookup for the IP packet.
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 ROUTING_TABLE_NAME: This is a routing table that exists in the o ROUTING_TABLE_NAME: This is a routing table that exists in the
RIB. A nexthop pointing to a table indicates that the route RIB. A nexthop pointing to a table indicates that the route
lookup needs to continue in the specified table. This is a way to lookup needs to continue in the specified table. This is a way to
perform chained lookups. perform chained lookups.
2.4.4. Nexthop attributes 2.4.4. Nexthop attributes
Certain information is encoded implicitly in the nexthop and does not Certain information is encoded implicitly in the nexthop and does not
need to be specified by the controller. For example, when a IP need to be specified by the controller. For example, when a IP
packet is forwarded out, the IP TTL is decremented by default. Same packet is forwarded out, the IP TTL is decremented by default. Same
skipping to change at page 11, line 27 skipping to change at page 13, line 5
by the network device and does not need to be programmed by an by the network device and does not need to be programmed by an
external device. external device.
A nexthop can have some attributes associated with it. The purpose A nexthop can have some attributes associated with it. The purpose
of the attributes is to either override implicit behavior (like that of the attributes is to either override implicit behavior (like that
related to TTL processing) or to guide the network device to perform related to TTL processing) or to guide the network device to perform
something specific. Vendor specific attributes can also be something specific. Vendor specific attributes can also be
specified. The details of vendor specific attributes is outside the specified. The details of vendor specific attributes is outside the
scope of this document. scope of this document.
2.4.5. Special nexthops 2.4.4.1. Nexthop flags
Nexthop flags in a nexthop is an optional attribute that is used to
denote specific connotation to hardware. Two common types of
operations are specified using nexthop flags.
o NO_DECREMENT_TTL: This indicates that the IPv4 time-to-live field
in an IPv4 packet MUST NOT be decremented before the packet is
forwarded. This may be applied one when an IPv4 packet is
encapsulated in a tunnel (E.g. MPLS) and one wants to hide the
fact that the packet is going through a tunnel.
o NO_PROPAGATE_TTL: This indicates that the IPv4 time-to-live field
in an IPv4 packet MUST NOT be propagated into an equivalent field,
when the IPv4 packet is tunneled. For example, if the IPv4 packet
is tunneled over MPLS, then the network device should use the
default time-to-live value for the outer MPLS header. This field
can also be used to indicate that when a tunnel terminates, one
does not propagate the outer header's time-to-live value into the
inner header. So, on MPLS tunnel termination, one does not
propagate the MPLS TTL value into the IPv4 header.
The TTL nexthop flags can be used to simulate a Pipe model for
tunnels. See [RFC3443] for a detailed understanding of Pipe model
and Uniform model.
2.4.5. Nexthop vendor attributes
This field has been defined for vendor specific extensions. The
contents of this field are beyond the scope of this document.
2.4.6. Special nexthops
This document specifies certain special nexthops. The purpose of This document specifies certain special nexthops. The purpose of
each of them is explained below: each of them is explained below:
o DISCARD: This indicates that the network device should drop the o DISCARD: This indicates that the network device should drop the
packet and increment a drop counter. packet and increment a drop counter.
o DISCARD_WITH_ERROR: This indicates that the network device should o DISCARD_WITH_ERROR: This indicates that the network device should
drop the packet, increment a drop counter and send back an drop the packet, increment a drop counter and send back an
appropriate error message (like ICMP error). appropriate error message (like ICMP error).
o RECEIVE: This indicates that that the traffic is destined for the o RECEIVE: This indicates that that the traffic is destined for the
network device. For example, protocol packets or OAM packets. network device. For example, protocol packets or OAM packets.
skipping to change at page 13, line 8 skipping to change at page 15, line 14
manager to an external entity when some event occurs on the network manager to an external entity when some event occurs on the network
device. A RIB data-model MUST support sending asynchronous device. A RIB data-model MUST support sending asynchronous
notifications. A brief list of suggested notifications is as below: notifications. A brief list of suggested notifications is as below:
o Route change notification, with return code as specified in o Route change notification, with return code as specified in
Section 4 Section 4
o Nexthop resolution status (resolved/unresolved) notification o Nexthop resolution status (resolved/unresolved) notification
6. RIB grammar 6. RIB grammar
This section specifies the RIB information model in Routing Backus- This section specifies the RIB information model in Routing Backus-
Naur Form ([RFC5511]). Naur Form [RFC5511].
<rib> ::= <RIB_NAME> <routing-instance> [<routing-instance> ...] <rib> ::= <RIB_NAME> <routing-instance> [<routing-instance> ...]
<routing-instance> ::= <INSTANCE_NAME> <INSTANCE_DISTINGUISHER> <routing-instance> ::= <INSTANCE_NAME> <INSTANCE_DISTINGUISHER>
[<interface-list>] <routing-table-list> [<interface-list>] <routing-table-list>
[<ROUTER_ID>] [<ISO_SYSTEM_ID>] [<ROUTER_ID>] [<ISO_SYSTEM_ID>]
[<as-data>] [<as-data>]
<as-data> ::= <AS_NUMBER> [<CONFEDERATION_AS>] <as-data> ::= <AS_NUMBER> [<CONFEDERATION_AS>]
<interface-list> ::= (<INTERFACE_IDENTIFIER> ...) <interface-list> ::= (<INTERFACE_IDENTIFIER> ...)
<routing-table-list> ::= (<routing-table> ...) <routing-table-list> ::= (<routing-table> ...)
<routing-table> ::= <routing-instance-name> <ROUTING_TABLE_NAME> <routing-table> ::= <ROUTING_TABLE_NAME> <table-family>
<table-family>
[<route> ... ] [<MULTI_TOPOLOGY_ID>] [<route> ... ] [<MULTI_TOPOLOGY_ID>]
[ENABLE_IP_RPF_CHECK] [ENABLE_IP_RPF_CHECK]
<table-family> ::= <IPV4_TABLE_FAMILY> | <IPV6_TABLE_FAMILY> | <table-family> ::= <IPV4_TABLE_FAMILY> | <IPV6_TABLE_FAMILY> |
<MPLS_TABLE_FAMILY> | <IEEE_MAC_TABLE_FAMILY> <MPLS_TABLE_FAMILY> | <IEEE_MAC_TABLE_FAMILY>
<route> ::= <ROUTING_TABLE_NAME> <match> <route> ::= <match> <nexthop-list>
<nexthop-list> [<route-attributes>] [<route-attributes>]
[<route-vendor-attributes>] [<route-vendor-attributes>]
<match> ::= <ipv4-route> | <ipv6-route> | <mpls-route> | <match> ::= <ipv4-route> | <ipv6-route> | <mpls-route> |
<mac-route> | <interface-route> <mac-route> | <interface-route>
<ipv4-route> ::= <IPV4_ADDRESS> <IPV4_PREFIX_LENGTH> <ipv4-route> ::= <IPV4_ADDRESS> <IPV4_PREFIX_LENGTH>
[<multicast-source-ipv4-address>]
<ipv6-route> ::= <IPV6_ADDRESS> <IPV6_PREFIX_LENGTH> <ipv6-route> ::= <IPV6_ADDRESS> <IPV6_PREFIX_LENGTH>
<mpls-route> ::= <MPLS> ( <MPLS_LABEL> ... ) [<multicast-source-ipv6-address>]
<mpls-route> ::= <MPLS> <MPLS_LABEL>
<mac-route> ::= <IEEE_MAC> ( <MAC_ADDRESS> ) <mac-route> ::= <IEEE_MAC> ( <MAC_ADDRESS> )
<interface-route> ::= <INTERFACE> <INTERFACE_IDENTIFIER> <interface-route> ::= <INTERFACE> <INTERFACE_IDENTIFIER>
<multicast-source-ipv4-address> ::= <IPV4_ADDRESS>
<IPV4_PREFIX_LENGTH>
<multicast-source-ipv6-address> ::= <IPV6_ADDRESS>
<IPV6_PREFIX_LENGTH>
<route-attributes> ::= [<ROUTE_PREFERENCE>] [<ROUTE_METRIC>] <route-attributes> ::= [<ROUTE_PREFERENCE>] [<ROUTE_METRIC>]
[<LOCAL_ONLY>] [<LOCAL_ONLY>]
[<address-family-route-attributes>] [<address-family-route-attributes>]
<address-family-route-attributes> ::= <ip-route-attributes> | <address-family-route-attributes> ::= <ip-route-attributes> |
<mpls-route-attributes> | <mpls-route-attributes> |
<ethernet-route-attributes> <ethernet-route-attributes>
<ip-route-attributes> ::= [<as-path>] [<rpf-check-interface>] <ip-route-attributes> ::= [<as-path>] [<rpf-check-interface>]
<as-path> ::= (<as-path-segment-type> <as-list>) [<as-path> ...] <as-path> ::= (<as-path-segment-type> <as-list>) [<as-path> ...]
<as-path-segment-type> ::= <AS_SET> | <AS_SEQUENCE> | <as-path-segment-type> ::= <AS_SET> | <AS_SEQUENCE> |
skipping to change at page 14, line 22 skipping to change at page 16, line 37
([<nexthop-list-member> ... ] <nexthop-list> )) ([<nexthop-list-member> ... ] <nexthop-list> ))
<nexthop-list-member> ::= (<nexthop-chain> | <nexthop-list-member> ::= (<nexthop-chain> |
<nexthop-chain-identifier> ) <nexthop-chain-identifier> )
[<nexthop-list-member-attributes>] [<nexthop-list-member-attributes>]
<nexthop-list-member-attributes> ::= [<PROTECTION_PREFERENCE>] <nexthop-list-member-attributes> ::= [<PROTECTION_PREFERENCE>]
[<LOAD_BALANCE_WEIGHT>] [<LOAD_BALANCE_WEIGHT>]
<nexthop-chain> ::= (<nexthop> ...) <nexthop-chain> ::= (<nexthop> ...)
<nexthop-chain-identifier> ::= <NEXTHOP_NAME> | <NEXTHOP_ID> <nexthop-chain-identifier> ::= <NEXTHOP_NAME> | <NEXTHOP_ID>
<nexthop> ::= (<nexthop-identifier> | <INTERFACE_IDENTIFIER> | <nexthop> ::= (<nexthop-identifier> | <EGRESS_IDENTIFIER> |
(<nexthop-address> [<ROUTING_TABLE_NAME>] (<nexthop-address>
[<EGRESS_INTERFACE>]) | ([<ROUTING_TABLE_NAME>] | [<EGRESS_INTERFACE>])) |
(<tunnel-encap> [<ROUTING_TABLE_NAME>] (<tunnel-encap> [<EGRESS_INTERFACE>]) |
[<EGRESS_INTERFACE>) | <logical-tunnel> |
<ROUTING_TABLE_NAME>) <ROUTING_TABLE_NAME>)
[<nexthop-attributes>] [<nexthop-attributes>]
[<nexthop-vendor-attributes>] [<nexthop-vendor-attributes>]
<nexthop-identifier> ::= <NEXTHOP_NAME> | <NEXTHOP_ID> <nexthop-identifier> ::= <NEXTHOP_NAME> | <NEXTHOP_ID>
<nexthop-address> ::= (<IPv4> <ipv4-address>) | <nexthop-address> ::= (<IPv4> <ipv4-address>) |
(<IPV6> <ipv6-address>) | (<IPV6> <ipv6-address>) |
(<IEEE_MAC> <IEEE_MAC_ADDRESS>) | (<IEEE_MAC> <IEEE_MAC_ADDRESS>) |
(<ISO> <ISO_ADDRESS>) (<ISO> <ISO_ADDRESS>)
<special-nexthop> ::= <DISCARD> | <DISCARD_WITH_ERROR> | <special-nexthop> ::= <DISCARD> | <DISCARD_WITH_ERROR> |
(<RECEIVE> [<COS_VALUE>] [<rate-limiter>]) (<RECEIVE> [<COS_VALUE>] [<rate-limiter>])
<rate-limiter> ::= <> <rate-limiter> ::= <>
<logical-tunnel> ::= <tunnel-type> <TUNNEL_NAME>
<tunnel-type> ::= <IP> | <MPLS> | <GRE> | <VxLAN> | <NVGRE>
<tunnel-encap> ::= (<IPV4> <ipv4-header>) | <tunnel-encap> ::= (<IPV4> <ipv4-header>) |
(<IPV6> <ipv6-header>) | (<IPV6> <ipv6-header>) |
(<MPLS> <mpls-header>) | (<MPLS> <mpls-header>) |
(<GRE> <gre-header>) | (<GRE> <gre-header>) |
(<VXLAN> <vxlan-header>) | (<VXLAN> <vxlan-header>) |
(<NVGRE> <nvgre-header>) (<NVGRE> <nvgre-header>)
<ipv4-header> ::= <SOURCE_IPv4_ADDRESS> <DESTINATION_IPv4_ADDRESS> <ipv4-header> ::= <SOURCE_IPv4_ADDRESS> <DESTINATION_IPv4_ADDRESS>
<PROTOCOL> [<TTL>] [<DSCP>] <PROTOCOL> [<TTL>] [<DSCP>]
skipping to change at page 18, line 26 skipping to change at page 20, line 43
7.2.6. Lists of lists 7.2.6. Lists of lists
Lists of lists is a complex construct. One example of usage of such Lists of lists is a complex construct. One example of usage of such
a construct is to replicate traffic to multiple destinations, with a construct is to replicate traffic to multiple destinations, with
high availability. In other words, for each destination you have a high availability. In other words, for each destination you have a
primary and backup nexthop (replication list) to ensure there is no primary and backup nexthop (replication list) to ensure there is no
traffic drop in case of a failure. So the outer list is a list of traffic drop in case of a failure. So the outer list is a list of
destinations and the inner lists are replication lists of primary/ destinations and the inner lists are replication lists of primary/
backup nexthops. backup nexthops.
7.3. Solving optimized exit control 7.3. Performing multicast
IP multicast involves matching a packet on (S, G) or (*, G), where
both S (source) and G (group) are IP prefixes. Following the match,
the packet is replicated to one or more recipients. How the
recipients subscribe to the multicast group is outside the scope of
this document.
In PIM-based multicast, the packets are IP forwarded on an IP
multicast tree. The downstream nodes on each point in the multicast
tree is one or more IP addresses. These can be represented as a
replication list ( Section 7.2.2 ).
In MPLS-based multicast, the packets are forwarded on a point to
multipoint (P2MP) label-switched path (LSP). The nexthop for a P2MP
LSP can be represented in the nexthop grammar as a <logical-tunnel>
(P2MP LSP identifier) or a replication list ( Section 7.2.2) of
<tunnel-encap>, with each tunnel encap representing a single mpls
downstream nexthop.
7.4. Solving optimized exit control
In case of optimized exit control, a controller wants to control the In case of optimized exit control, a controller wants to control the
edge device (and optionally control the outgoing interface on that edge device (and optionally control the outgoing interface on that
edge device) that is used by a server to send traffic out. This can edge device) that is used by a server to send traffic out. This can
be easily achieved by having the controller program the edge router be easily achieved by having the controller program the edge router
(Eg. 192.0.2.10) and the server along the following lines: (Eg. 192.0.2.10) and the server along the following lines:
Server: Server:
<route> ::= <routing-table-name> <match> (<edge-router> <route> ::= <routing-table-name> <match> (<edge-router>
<edge-router-interface>) <edge-router-interface>)
<route> ::= <routing-table-name> <198.51.100.1/16> <route> ::= <routing-table-name> <198.51.100.1/16>
(<GRE> <gre-header>)
(<MPLS> <mpls-header>) (<MPLS> <mpls-header>)
(<GRE> <gre-header>)
<route> ::- <routing-table-name> <198.51.100.1/16> <route> ::- <routing-table-name> <198.51.100.1/16>
(<GRE> <192.0.2.10> <GRE_PROTOCOL_MPLS>)
(<MPLS_PUSH> <100>) (<MPLS_PUSH> <100>)
(<GRE> <192.0.2.10> <GRE_PROTOCOL_MPLS>)
Edge Router: Edge Router:
<route> ::= <mpls-routing-table> <mpls-route> <nexthop> <route> ::= <mpls-routing-table> <mpls-route> <nexthop>
<route> ::= <mpls-routing-table> (<MPLS> <100>) <interface-10> <route> ::= <mpls-routing-table> (<MPLS> <100>) <interface-10>
In the above case, the label 100 identifies the egress interface In the above case, the label 100 identifies the egress interface
on the edge router. on the edge router.
8. RIB operations at scale 8. RIB operations at scale
skipping to change at page 20, line 26 skipping to change at page 23, line 20
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References 12.2. Informative References
[I-D.atlas-i2rs-problem-statement] [I-D.atlas-i2rs-problem-statement]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Problem Statement", Routing System Problem Statement",
draft-atlas-i2rs-problem-statement-00 (work in progress), draft-atlas-i2rs-problem-statement-01 (work in progress),
February 2013. July 2013.
[I-D.hares-i2rs-use-case-vn-vc] [I-D.hares-i2rs-use-case-vn-vc]
Hares, S., "Use Cases for Virtual Connections on Demand Hares, S., "Use Cases for Virtual Connections on Demand
(VCoD) and Virtual Network on Demand using Interface to (VCoD) and Virtual Network on Demand using Interface to
Routing System", draft-hares-i2rs-use-case-vn-vc-00 (work Routing System", draft-hares-i2rs-use-case-vn-vc-00 (work
in progress), February 2013. in progress), February 2013.
[I-D.white-i2rs-use-case] [I-D.white-i2rs-use-case]
White, R., Hares, S., and R. Fernando, "Use Cases for an White, R., Hares, S., and R. Fernando, "Use Cases for an
Interface to the Routing System", Interface to the Routing System",
draft-white-i2rs-use-case-00 (work in progress), draft-white-i2rs-use-case-00 (work in progress),
February 2013. February 2013.
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
in Multi-Protocol Label Switching (MPLS) Networks",
RFC 3443, January 2003.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, June 2007.
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065, August 2007. System Confederations for BGP", RFC 5065, August 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, February 2008.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009. Specifications", RFC 5511, April 2009.
Authors' Addresses Authors' Addresses
Nitin Bahadur (editor) Nitin Bahadur (editor)
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Avenue 1194 N. Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
skipping to change at line 962 skipping to change at page 24, line 36
US US
Phone: +1 408 745 2000 Phone: +1 408 745 2000
Email: ronf@juniper.net Email: ronf@juniper.net
URI: www.juniper.net URI: www.juniper.net
Sriganesh Kini Sriganesh Kini
Ericsson Ericsson
Email: sriganesh.kini@ericsson.com Email: sriganesh.kini@ericsson.com
Jan Medved
Cisco
Email: jmedved@cisco.com
 End of changes. 38 change blocks. 
115 lines changed or deleted 218 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/