draft-ietf-i2rs-rib-info-model-05.txt   draft-ietf-i2rs-rib-info-model-06.txt 
Network Working Group N. Bahadur, Ed. Network Working Group N. Bahadur, Ed.
Internet-Draft Bracket Computing Internet-Draft Bracket Computing
Intended status: Informational R. Folkes, Ed. Intended status: Informational R. Folkes, Ed.
Expires: July 31, 2015 Juniper Networks, Inc. Expires: September 10, 2015 Juniper Networks, Inc.
S. Kini, Ed. S. Kini, Ed.
Ericsson Ericsson
J. Medved J. Medved
Cisco Cisco
January 27, 2015 March 09, 2015
Routing Information Base Info Model Routing Information Base Info Model
draft-ietf-i2rs-rib-info-model-05 draft-ietf-i2rs-rib-info-model-06
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 installs state into the data into the RIB and the RIB manager installs 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 enable defining a standardized data model. Such 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 a data model can be used to define an interface to the RIB from an
entity that may even be external to the network device. This entity that may even be external to the network device. This
interface can be used to support new use-cases being defined by the interface can be used to support new use-cases being defined by the
IETF I2RS WG. 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 July 31, 2015. This Internet-Draft will expire on September 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 6 1.1. Conventions used in this document . . . . . . . . . . . . 5
2. RIB data . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. RIB data . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. RIB definition . . . . . . . . . . . . . . . . . . . . . . 6 2.1. RIB definition . . . . . . . . . . . . . . . . . . . . . 5
2.2. Routing instance . . . . . . . . . . . . . . . . . . . . . 7 2.2. Routing instance . . . . . . . . . . . . . . . . . . . . 6
2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1. Nexthop types . . . . . . . . . . . . . . . . . . . . 12 2.4.1. Nexthop types . . . . . . . . . . . . . . . . . . . . 11
2.4.2. Nexthop list attributes . . . . . . . . . . . . . . . 13 2.4.2. Nexthop list attributes . . . . . . . . . . . . . . . 12
2.4.3. Nexthop content . . . . . . . . . . . . . . . . . . . 13 2.4.3. Nexthop content . . . . . . . . . . . . . . . . . . . 12
2.4.4. Special nexthops . . . . . . . . . . . . . . . . . . . 14 2.4.4. Special nexthops . . . . . . . . . . . . . . . . . . 13
3. Reading from the RIB . . . . . . . . . . . . . . . . . . . . . 14 3. Reading from the RIB . . . . . . . . . . . . . . . . . . . . 14
4. Writing to the RIB . . . . . . . . . . . . . . . . . . . . . . 15 4. Writing to the RIB . . . . . . . . . . . . . . . . . . . . . 14
5. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 15
6. RIB grammar . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. RIB grammar . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Nexthop grammar explained . . . . . . . . . . . . . . . . 18 6.1. Nexthop grammar explained . . . . . . . . . . . . . . . . 18
7. Using the RIB grammar . . . . . . . . . . . . . . . . . . . . 19 7. Using the RIB grammar . . . . . . . . . . . . . . . . . . . . 18
7.1. Using route preference . . . . . . . . . . . . . . . . . . 19 7.1. Using route preference . . . . . . . . . . . . . . . . . 18
7.2. Using different nexthops types . . . . . . . . . . . . . . 19 7.2. Using different nexthops types . . . . . . . . . . . . . 19
7.2.1. Tunnel nexthops . . . . . . . . . . . . . . . . . . . 19 7.2.1. Tunnel nexthops . . . . . . . . . . . . . . . . . . . 19
7.2.2. Replication lists . . . . . . . . . . . . . . . . . . 19 7.2.2. Replication lists . . . . . . . . . . . . . . . . . . 19
7.2.3. Weighted lists . . . . . . . . . . . . . . . . . . . . 20 7.2.3. Weighted lists . . . . . . . . . . . . . . . . . . . 19
7.2.4. Protection lists . . . . . . . . . . . . . . . . . . . 20 7.2.4. Protection . . . . . . . . . . . . . . . . . . . . . 20
7.2.5. Nexthop chains . . . . . . . . . . . . . . . . . . . . 21 7.2.5. Nexthop chains . . . . . . . . . . . . . . . . . . . 21
7.2.6. Lists of lists . . . . . . . . . . . . . . . . . . . . 21 7.2.6. Lists of lists . . . . . . . . . . . . . . . . . . . 21
7.3. Performing multicast . . . . . . . . . . . . . . . . . . . 23 7.3. Performing multicast . . . . . . . . . . . . . . . . . . 23
8. RIB operations at scale . . . . . . . . . . . . . . . . . . . 24 8. RIB operations at scale . . . . . . . . . . . . . . . . . . . 24
8.1. RIB reads . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. RIB reads . . . . . . . . . . . . . . . . . . . . . . . . 24
8.2. RIB writes . . . . . . . . . . . . . . . . . . . . . . . . 24 8.2. RIB writes . . . . . . . . . . . . . . . . . . . . . . . 24
8.3. RIB events and notifications . . . . . . . . . . . . . . . 24 8.3. RIB events and notifications . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . . 25 12.1. Normative References . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . . 25 12.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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) populate the Routing information base (RIB) of the router. config) populate the Routing information base (RIB) of the router.
The RIB is managed by the RIB manager and the RIB manager provides a The RIB is managed by the RIB manager and the RIB manager provides a
north-bound interface to its clients i.e. the routing protocols to north-bound interface to its clients i.e. the routing protocols to
insert routes into the RIB. The RIB manager consults the RIB and insert routes into the RIB. The RIB manager consults the RIB and
skipping to change at page 6, line 23 skipping to change at page 5, line 30
"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). A high-level references to objects in the RIB grammar (Section 6). A high-level
description of the RIB contents is as shown below. description of the RIB contents is as shown below.
routing-instance routing-instance
| | | |
| | | |
0..N | | 1..N 0..N | | 1..N
| | | |
interface(s) RIB(s) interface(s) RIB(s)
| |
| |
| 0..N | 0..N
|
route(s) route(s)
Figure 2: RIB model Figure 2: RIB model
2.1. RIB definition 2.1. RIB definition
A RIB is an entity that contains routes. A RIB is identified by its A RIB is an entity that contains routes. A RIB is identified by its
name and a RIB is contained within a routing instance (Section 2.2). name and a RIB is contained within a routing instance (Section 2.2).
The name MUST be unique within a routing instance. All routes in a The name MUST be unique within a routing instance. All routes in a
given RIB MUST be of the same type (e.g. IPv4). Each RIB MUST given RIB MUST be of the same type (e.g. IPv4). Each RIB MUST
skipping to change at page 8, line 22 skipping to change at page 7, line 27
a given domain. a given domain.
2.3. Route 2.3. Route
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. Figure 3 represents the etc.) and the set of fields to match on. Figure 3 represents the
overall contents of a route. overall contents of a route.
route route
| | | | | |
+---------+ | +----------+ +---------+ | +----------+
| | | | | |
0..N | | | 1..N 0..N | | |
route-attribute match nexthop-list
route-attribute match nexthop
| |
| |
+-------+-------+-------+--------+ +-------+-------+-------+--------+
| | | | | | | | | |
| | | | | | | | | |
IPv4 IPv6 MPLS MAC Interface IPv4 IPv6 MPLS MAC Interface
(Unicast/Multicast)
Figure 3: Route model Figure 3: Route model
This document specifies the following match types: This document specifies the following match types:
o IPv4: Match on destination IP address in the IPv4 header o IPv4: Match on destination IP address in the IPv4 header
o IPv6: Match on destination IP address in the IPv6 header o IPv6: Match on destination IP address in the IPv6 header
o MPLS: Match on a MPLS label at the top of the MPLS label stack o MPLS: Match on a MPLS label at the top of the MPLS label stack
o MAC: Match on MAC destination addresses in the ethernet header o MAC: Match on MAC destination addresses in the ethernet header
o Interface: Match on incoming interface of the packet o Interface: Match on incoming interface of the packet
o IP multicast: Match on (S, G) or (*, G), where S and G are IP o IP multicast: Match on (S, G) or (*, G), where S and G are IP
prefixes addresses
Each route MUST have associated with it the following mandatory route Each route MUST have associated with it the following mandatory 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. Static configuration comparing routes from different protocols. Static configuration
is also considered a protocol for the purpose of this field. It is also considered a protocol for the purpose of this field. It
is also known as administrative-distance. The lower the value, is also known as administrative-distance. The lower the value,
the higher the preference. For example there can be an OSPF route the higher the preference. For example there can be an OSPF route
for 192.0.2.1/32 with a preference of 5. If a controller programs for 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 a route for 192.0.2.1/32 with a preference of 2, then the
controller's route will be preferred by the RIB manager. controller's route will be preferred by the RIB manager.
Preference should be used to dictate behavior. For more examples Preference should be used to dictate behavior. For more examples
of preference, see Section 7.1. of preference, see Section 7.1.
skipping to change at page 11, line 6 skipping to change at page 10, line 6
henceforth referred to as a FIB-ineligible route. The RIB henceforth referred to as a FIB-ineligible route. The RIB
information model allows an external entity to program routes whose information model allows an external entity to program routes whose
nexthops may be unresolved initially. Whenever an unresolved nexthop nexthops may be unresolved initially. Whenever an unresolved nexthop
gets resolved, the RIB manager will send a notification of the same gets resolved, the RIB manager will send a notification of the same
(see Section 5 ). (see Section 5 ).
The overall structure and usage of a nexthop is as shown in the The overall structure and usage of a nexthop is as shown in the
figure below. figure below.
route route
| |
| 0..N | 0..N
nexthop-list
| |
+------------------+------------------+ nexthop <-----------------+
1..N | | | |
| | +-------+----------------------------+ |
| | | | |
nexthop-list-member special-nexthop | | | | |
base load-balance protection replicate |
| | | | | |
| | |2..N |2 |2..N |
| | V | |
nexthop-chain | +------------->+<------------+ |
| | |
| | +-----------------------+
1..N | |
+-------------------+
nexthop | |
| 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
Figure 4: Nexthop model Figure 4: Nexthop model
Nexthops can be identified by an identifier to create a level of Nexthops can be identified by an identifier to create a level of
indirection. The identifier is set by the RIB manager and returned indirection. The identifier is set by the RIB manager and returned
to the external entity on request. The RIB data-model SHOULD support to the external entity on request. The RIB data-model SHOULD support
a way to optionally receive a nexthop identifier for a given nexthop. 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 For example, one can create a nexthop that points to a BGP peer. The
returned nexthop identifier can then be used for programming routes returned nexthop identifier can then be used for programming routes
skipping to change at page 12, line 15 skipping to change at page 11, line 9
seamless to the external entity and all routes that point to that BGP seamless to the external entity and all routes that point to that BGP
peer will automatically start going over the new transport path. peer will automatically start going over the new transport path.
Nexthop indirection using identifiers could be applied to not just Nexthop indirection using identifiers could be applied to not just
unicast nexthops, but even to nexthops that contain chains and nested unicast nexthops, but even to nexthops that contain chains and nested
nexthops (Section 2.4.1). nexthops (Section 2.4.1).
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 Interface 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 packet
o Weighted lists - for load-balancing o Weighted lists - for load-balancing
o Protection lists - for primary/backup paths
o Preference lists - for protection using primary and backup
o Nexthop chains - for 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 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 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 levels of lookup can be performed and not all hardware will be able
to support all kinds of nexthops. RIB capability negotiation becomes to support all kinds of nexthops. RIB capability negotiation becomes
very important for this reason and a RIB data-model MUST specify a 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 way for an external entity to learn about the network device's
capabilities. Examples of when and how to use various kinds of capabilities. Examples of when and how to use various kinds of
nexthops are shown in Section 7.2. 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
skipping to change at page 13, line 10 skipping to change at page 12, line 14
are specified by the controller. Not every network device will be are specified by the controller. Not every network device will be
able to support all kinds of nexthop chains and an arbitrary number able to support all kinds of nexthop chains and an arbitrary number
of header chained together. The RIB data-model SHOULD provide a way of header chained together. The RIB data-model SHOULD provide a way
to expose nexthop chaining capability supported by a given network to expose nexthop chaining capability supported by a given network
device. device.
2.4.2. Nexthop list attributes 2.4.2. Nexthop list attributes
For nexthops that are of the form of a list(s), attributes can be 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 associated with each member of the list to indicate the role of an
individual member of the list. Two kinds of attributes are individual member of the list. Two attributes are specified:
specified:
o PROTECTION_PREFERENCE: This provides a primary/backup like o NEXTHOP_PREFERENCE: This is used for protection schemes. It is an
preference. The preference is an integer value that should be set integer value between 1 and 99. A lower value indicates higher
to 1 (primary) or 2 (backup). Only when all the primary nexthops preference. To download a primary/standby pair to the FIB, the
fail is the traffic re-routed through the backup nexthops. This nexthops that are resolved and have two highest preferences are
attribute must be specified for all the members of a list or none selected.
of them.
o LOAD_BALANCE_WEIGHT: This is used for load-balancing. Each list o NEXTHOP_LB_WEIGHT: This is used for load-balancing. Each list
member MUST be assigned a weight between 1 and 99. The weight member MUST be assigned a weight between 1 and 99. The weight
determines the proportion of traffic to be sent over a nexthop determines the proportion of traffic to be sent over a nexthop
used for forwarding as a ratio of the weight of this 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 divided by the weights of all the nexthops of this route that are
used for forwarding. To perform equal load-balancing, one MAY used for forwarding. To perform equal load-balancing, one MAY
specify a weight of "0" for all the member nexthops. The value specify a weight of "0" for all the member nexthops. The value
"0" is reserved for equal load-balancing and if applied, MUST be "0" is reserved for equal load-balancing and if applied, MUST be
applied to all member nexthops. applied to all member nexthops.
A nexthop list MAY contain elements that have both
PROTECTION_PREFERENCE and LOAD_BALANCE_WEIGHT set. When both are
set, it means under normal operation the network device should load
balance the traffic over all FIB-eligible nexthops of the current
protection preference.
2.4.3. Nexthop content 2.4.3. Nexthop content
At the lowest level, a nexthop can be one of: At the lowest level, a nexthop can be one of:
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 EGRESS_INTERFACE: This represents a physical, logical or virtual o EGRESS_INTERFACE: This represents a physical, logical or virtual
interface on the network device. Address resolution must not be interface on the network device. Address resolution must not be
required on this interface. This interface may belong to any required on this interface. This interface may belong to any
routing instance. routing instance.
o IP address: A route lookup on this IP address is done to determine o IP address: A route lookup on this IP address is done to determine
the egress interface. Address resolution may be required the egress interface. Address resolution may be required
depending on the interface. depending on the interface.
* An optional RIB name can also be specified to indicate the RIB * 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 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 RIB name field to direct the packet from one domain into
another domain. By default the RIB will be the same as the one another domain. By default the RIB will be the same as the one
that route belongs to. that route belongs to.
o EGRESS_INTERFACE and IP address: This can be used in cases e.g. o EGRESS_INTERFACE and IP address: This can be used in cases e.g.
where the IP address is a link-local address. where the IP address is a link-local address.
o EGRESS_INTERFACE and MAC address: The egress interface must be an o EGRESS_INTERFACE and MAC address: The egress interface must be an
ethernet interface. Address resolution is not required for this ethernet interface. Address resolution is not required for this
nexthop. nexthop.
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. An optional MPLS tunnel or others as defined in this document. An optional
egress interface can be specified to indicate which interface to egress interface can be specified to indicate which interface to
send the packet out on. The egress interface is useful when the send the packet out on. The egress interface is useful when the
network device contains Ethernet interfaces and one needs to network device contains Ethernet interfaces and one needs to
perform address resolution for the IP packet. perform address resolution for the IP packet.
o logical tunnel: This can be a MPLS LSP or a GRE tunnel (or others 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 as defined in this document), that is represented by a unique
identifier (E.g. name). identifier (E.g. name).
o RIB_NAME: A nexthop pointing to a RIB indicates that the route 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 lookup needs to continue in the specified RIB. This is a way to
perform chained lookups. perform chained lookups.
2.4.4. Special nexthops 2.4.4. 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.
All locally destined traffic SHOULD be throttled to avoid a denial All locally destined traffic SHOULD be throttled to avoid a denial
of service attack on the router's control plane. An optional of service attack on the router's control plane. An optional
rate-limiter can be specified to indicate how to throttle traffic rate-limiter can be specified to indicate how to throttle traffic
destined for the control plane. The description of the rate- destined for the control plane. The description of the rate-
limiter is outside the scope of this document. limiter is outside the scope of this document.
3. Reading from the RIB 3. Reading from the RIB
skipping to change at page 15, line 41 skipping to change at page 15, line 11
create a new object and delete the old one. For example, routes that 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. unaffected when the contents of that nexthop changes.
5. Notifications 5. Notifications
Asynchronous notifications are sent by the network device's RIB Asynchronous notifications are sent by the network device's RIB
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]. This grammar is intended to help the reader
better understand the english text description in order to derive a
data model. However it may not provide all the detail provided by
the english text. When there is a lack of clarity in the grammar the
english text will take precedence.
<routing-instance> ::= <INSTANCE_NAME> <routing-instance> ::= <INSTANCE_NAME>
[<interface-list>] <rib-list> [<interface-list>] <rib-list>
[<ROUTER_ID>] [<ROUTER_ID>]
<interface-list> ::= (<INTERFACE_IDENTIFIER> ...) <interface-list> ::= (<INTERFACE_IDENTIFIER> ...)
<rib-list> ::= (<rib> ...) <rib-list> ::= (<rib> ...)
<rib> ::= <RIB_NAME> <rib-family> <rib> ::= <RIB_NAME> <rib-family>
[<route> ... ] [<route> ... ]
[ENABLE_IP_RPF_CHECK] [ENABLE_IP_RPF_CHECK]
<rib-family> ::= <IPV4_RIB_FAMILY> | <IPV6_RIB_FAMILY> | <rib-family> ::= <IPV4_RIB_FAMILY> | <IPV6_RIB_FAMILY> |
<MPLS_RIB_FAMILY> | <IEEE_MAC_RIB_FAMILY> <MPLS_RIB_FAMILY> | <IEEE_MAC_RIB_FAMILY>
<route> ::= <match> <nexthop-list> <route> ::= <match> <nexthop>
[<route-attributes>] [<route-attributes>]
[<route-vendor-attributes>] [<route-vendor-attributes>]
<match> ::= <route-type> (<ipv4-route> | <ipv6-route> | <mpls-route> | <match> ::= <route-type> (<ipv4-route> | <ipv6-route> | <mpls-route> |
<mac-route> | <interface-route>) <mac-route> | <interface-route>)
<match> ::= <IPV4> <ipv4-route> | <IPV6> <ipv6-route> |
<MPLS> <MPLS_LABEL> | <IEEE_MAC> <MAC_ADDRESS> |
<INTERFACE> <INTERFACE_IDENTIFIER>
<route-type> ::= <IPV4> | <IPV6> | <MPLS> | <IEEE_MAC> | <INTERFACE> <route-type> ::= <IPV4> | <IPV6> | <MPLS> | <IEEE_MAC> | <INTERFACE>
<ipv4-route> ::= <ip-route-type> <ipv4-route> ::= <ip-route-type>
(<destination-ipv4-address> | <source-ipv4-address> | (<destination-ipv4-address> | <source-ipv4-address> |
(<destination-ipv4-address> <source-ipv4-address>)) (<destination-ipv4-address> <source-ipv4-address>))
<destination-ipv4-address> ::= <ipv4-prefix> <destination-ipv4-address> ::= <ipv4-prefix>
<source-ipv4-address> ::= <ipv4-prefix> <source-ipv4-address> ::= <ipv4-prefix>
<ipv4-prefix> ::= <IPV4_ADDRESS> <IPV4_PREFIX_LENGTH> <ipv4-prefix> ::= <IPV4_ADDRESS> <IPV4_PREFIX_LENGTH>
<ipv6-route> ::= <ip-route-type> <ipv6-route> ::= <ip-route-type>
(<destination-ipv6-address> | <source-ipv6-address> | (<destination-ipv6-address> | <source-ipv6-address> |
(<destination-ipv6-address> <source-ipv6-address>)) (<destination-ipv6-address> <source-ipv6-address>))
skipping to change at page 16, line 41 skipping to change at page 16, line 19
<ipv4-prefix> ::= <IPV4_ADDRESS> <IPV4_PREFIX_LENGTH> <ipv4-prefix> ::= <IPV4_ADDRESS> <IPV4_PREFIX_LENGTH>
<ipv6-route> ::= <ip-route-type> <ipv6-route> ::= <ip-route-type>
(<destination-ipv6-address> | <source-ipv6-address> | (<destination-ipv6-address> | <source-ipv6-address> |
(<destination-ipv6-address> <source-ipv6-address>)) (<destination-ipv6-address> <source-ipv6-address>))
<destination-ipv6-address> ::= <ipv6-prefix> <destination-ipv6-address> ::= <ipv6-prefix>
<source-ipv6-address> ::= <ipv6-prefix> <source-ipv6-address> ::= <ipv6-prefix>
<ipv6-prefix> ::= <IPV6_ADDRESS> <IPV6_PREFIX_LENGTH> <ipv6-prefix> ::= <IPV6_ADDRESS> <IPV6_PREFIX_LENGTH>
<ip-route-type> ::= <SRC> | <DEST> | <DEST_SRC> <ip-route-type> ::= <SRC> | <DEST> | <DEST_SRC>
<mpls-route> ::= <MPLS_LABEL>
<mac-route> ::= <MAC_ADDRESS>
<interface-route> ::= <INTERFACE_IDENTIFIER>
<route-attributes> ::= <ROUTE_PREFERENCE> [<LOCAL_ONLY>] <route-attributes> ::= <ROUTE_PREFERENCE> [<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> ::= <> <ip-route-attributes> ::= <>
<mpls-route-attributes> ::= <> <mpls-route-attributes> ::= <>
<ethernet-route-attributes> ::= <> <ethernet-route-attributes> ::= <>
<route-vendor-attributes> ::= <> <route-vendor-attributes> ::= <>
skipping to change at page 17, line 15 skipping to change at page 16, line 30
[<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> ::= <> <ip-route-attributes> ::= <>
<mpls-route-attributes> ::= <> <mpls-route-attributes> ::= <>
<ethernet-route-attributes> ::= <> <ethernet-route-attributes> ::= <>
<route-vendor-attributes> ::= <> <route-vendor-attributes> ::= <>
<nexthop-list> ::= <special-nexthop> | <nexthop> ::= <NEXTHOP_BASE> <nexthop-base> |
((<nexthop-list> <nexthop-list-attr>) ...) | <NEXTHOP_LOAD_BALANCE> <nexthop-lb> |
(<nexthop-list-member> ...) <NEXTHOP_PROTECTION> <nexthop-protection> |
<NEXTHOP_REPLICATE> <nexthop-replicate>
<nexthop-list-attributes> ::= [<PROTECTION_PREFERENCE>] <nexthop-lb> ::= <NEXTHOP_LB_WEIGHT> <nexthop-lb-member>
[<LOAD_BALANCE_WEIGHT>] (<NEXTHOP_LB_WEIGHT> <nexthop-lb-member>) ...
<NEXTHOP_LB_WEIGHT> is a number between 1 and 99.
<nexthop-lb-member> ::= <nexthop>
<nexthop-list-member> ::= (<nexthop-chain> | <nexthop-protection> = <NEXTHOP_PREFERENCE> <nexthop>
<nexthop-chain-identifier> ) (<NEXTHOP_PREFERENCE> <nexthop>)...
[<nexthop-list-member-attributes>] Each <NEXTHOP_PREFERENCE> should have a unique value within a
<nexthop-list-member-attributes> ::= [<PROTECTION_PREFERENCE>] <nexthop-protection>.
[<LOAD_BALANCE_WEIGHT>]
<nexthop-chain> ::= (<nexthop> ...) <nexthop-replicate> ::= <nexthop> <nexthop> ...
<nexthop-chain-identifier> ::= <NEXTHOP_NAME> | <NEXTHOP_ID>
<nexthop> ::= (<nexthop-identifier> | <EGRESS_INTERFACE> | <nexthop-base> ::= <nexthop-special> | <nexthop-chain>
<nexthop-chain> ::= <nexthop-chain-member> ...
<nexthop-chain-identifier> ::= <NEXTHOP_CHAIN_NAME> |
<NEXTHOP_CHAIN_ID>
<nexthop-chain-member> ::= <nexthop-chain-member-identifier> |
<EGRESS_INTERFACE> |
<ipv4-address> | <ipv6-address> | <ipv4-address> | <ipv6-address> |
(<EGRESS_INTERFACE> (<ipv4-address> | <ipv6-address>)) | (<EGRESS_INTERFACE> (<ipv4-address> | <ipv6-address>)) |
(<EGRESS_INTERFACE> <IEEE_MAC_ADDRESS>) | (<EGRESS_INTERFACE> <IEEE_MAC_ADDRESS>) |
(<tunnel-encap> [<EGRESS_INTERFACE>]) | (<tunnel-encap> [<EGRESS_INTERFACE>]) |
<logical-tunnel> | <logical-tunnel> |
<RIB_NAME>) <RIB_NAME>)
<nexthop-identifier> ::= <NEXTHOP_NAME> | <NEXTHOP_ID> <EGRESS_INTERFACE> ::= <INTERFACE_IDENTIFIER>
<special-nexthop> ::= <DISCARD> | <DISCARD_WITH_ERROR> |
<nexthop-chain-member-identifier> ::= <NEXTHOP_CHAIN_MEMBER_NAME> |
<NEXTHOP_CHAIN_MEMBER_ID>
<nexthop-special> ::= <DISCARD> | <DISCARD_WITH_ERROR> |
(<RECEIVE> [<COS_VALUE>]) (<RECEIVE> [<COS_VALUE>])
<logical-tunnel> ::= <tunnel-type> <TUNNEL_NAME> <logical-tunnel> ::= <tunnel-type> <TUNNEL_NAME>
<tunnel-type> ::= <IPV4> | <IPV6> | <MPLS> | <GRE> | <VxLAN> | <NVGRE> <tunnel-type> ::= <IPV4> | <IPV6> | <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>) |
skipping to change at page 18, line 32 skipping to change at page 18, line 21
<vxlan-header> ::= (<ipv4-header> | <ipv6-header>) <vxlan-header> ::= (<ipv4-header> | <ipv6-header>)
[<VXLAN_IDENTIFIER>] [<VXLAN_IDENTIFIER>]
<nvgre-header> ::= (<ipv4-header> | <ipv6-header>) <nvgre-header> ::= (<ipv4-header> | <ipv6-header>)
<VIRTUAL_SUBNET_ID> <VIRTUAL_SUBNET_ID>
[<FLOW_ID>] [<FLOW_ID>]
Figure 5: RIB rBNF grammar Figure 5: RIB rBNF grammar
6.1. Nexthop grammar explained 6.1. Nexthop grammar explained
A nexthop-list can be a special-nexthop like DISCARD or it can be A nexthop is used to specify the next network element to forward the
complex nexthop containing one or more lists. The nexthop-list has traffic to. It is also used to specify how the traffic should be
recursion built-in to address complex use-cases like the one defined load-balanced, protected using preference or multicasted using
in Section 7.2.6. When recursion is used, one can specify the replication. This is explicitly specified in the grammar. The
<nexthop-list-attributes> attributes if one desires load-balancing or nexthop has recursion built-in to address complex use-cases like the
primary/backup like feature. If neither attribute is specified, then one defined in Section 7.2.6.
it implies that multicast (send to all) is desired.
Protection preference and load balancing are also associated with the
nexthop-list-member. See Section 7.2.6 for an example.
Specifying the nexthop attributes (<nexthop-list-attribute> or
<nexthop-list-member-attribute>) at the beginning of the construct
helps clearly indicate whether one is defining a set of constructs
for doing protection or load balancing or multicast. Placing the
attribute at the inner level <nexthop> would cause issues since the
attribute would need to be consistent (and duplicated) across various
members of (for example) the load-balance list and only after parsing
the inner level <nexthop> one would realize that it was load-
balancing that the caller desired.
7. Using the RIB grammar 7. Using the RIB grammar
The RIB grammar is very generic and covers a variety of features. The RIB grammar is very generic and covers a variety of features.
This section provides examples on using objects in the RIB grammar This section provides examples on using objects in the RIB grammar
and examples to program certain use cases. and examples to program certain use cases.
7.1. Using route preference 7.1. Using route preference
Using route preference a client can pre-install alternate paths in Using route preference a client can pre-install alternate paths in
skipping to change at page 19, line 46 skipping to change at page 19, line 25
7.2.1. Tunnel nexthops 7.2.1. Tunnel nexthops
A tunnel nexthop points to a tunnel of some kind. Traffic that goes A tunnel nexthop points to a tunnel of some kind. Traffic that goes
over the tunnel gets encapsulated with the tunnel encap. Tunnel over the tunnel gets encapsulated with the tunnel encap. Tunnel
nexthops are useful for abstracting out details of the network, by 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.
7.2.2. Replication lists 7.2.2. Replication lists
One can create a replication list for replication traffic to multiple One can create a replication list for replicating traffic to multiple
destinations. The destinations, in turn, could be complex nexthops destinations. The destinations, in turn, could be complex nexthops
in themselves - at a level supported by the network device. Point to in themselves - at a level supported by the network device. Point to
multipoint and broadcast are examples that involve replication. multipoint and broadcast are examples that involve replication.
A replication list (at the simplest level) can be represented as: A replication list (at the simplest level) can be represented as:
<nexthop-list> ::= <nexthop> [ <nexthop> ... ] <nexthop> ::= <NEXTHOP_REPLICATE> <nexthop> [ <nexthop> ... ]
The above can be derived from the grammar as follows: The above can be derived from the grammar as follows:
<nexthop-list> ::= <nexthop-list-member> [<nexthop-list-member> ...] <nexthop> ::= <NEXTHOP_REPLICATE> <nexthop-replicate>
<nexthop-list> ::= <nexthop-chain> [<nexthop-chain> ...] <nexthop> ::= <NEXTHOP_REPLICATE> <nexthop> <nexthop> ...
<nexthop-list> ::= <nexthop> [ <nexthop> ... ]
7.2.3. Weighted lists 7.2.3. Weighted lists
A weighted list is used to load-balance traffic among a set of A weighted list is used to load-balance traffic among a set of
nexthops. From a modeling perspective, a weighted list is very nexthops. From a modeling perspective, a weighted list is very
similar to a replication list, with the difference that each member similar to a replication list, with the difference that each member
nexthop MUST have a LOAD_BALANCE_WEIGHT associated with it. nexthop MUST have a NEXTHOP_LB_WEIGHT associated with it.
A weighted list (at the simplest level) can be represented as: A weighted list (at the simplest level) can be represented as:
<nexthop-list> ::= (<nexthop> <LOAD_BALANCE_WEIGHT>) <nexthop> ::= <NEXTHOP_LOAD_BALANCE> (<nexthop> <NEXTHOP_LB_WEIGHT>)
[(<nexthop> <LOAD_BALANCE_WEIGHT>)... ] [(<nexthop> <NEXTHOP_LB_WEIGHT>)... ]
The above can be derived from the grammar as follows: The above can be derived from the grammar as follows:
<nexthop-list> ::= <nexthop-list-member> [<nexthop-list-member> ...] <nexthop> ::= <NEXTHOP_LOAD_BALANCE> <nexthop-lb>
<nexthop-list> ::= (<nexthop-chain> <nexthop-list-member-attributes>) <nexthop> ::= <NEXTHOP_LOAD_BALANCE>
[(<nexthop-chain> <NEXTHOP_LB_WEIGHT> <nexthop-lb-member>
<nexthop-list-member-attributes>) ...] (<NEXTHOP_LB_WEIGHT> <nexthop-lb-member>) ...
<nexthop-list> ::= (<nexthop-chain> <LOAD_BALANCE_WEIGHT>) <nexthop> ::= <NEXTHOP_LOAD_BALANCE> (<NEXTHOP_LB_WEIGHT> <nexthop>)
[(<nexthop-chain> <LOAD_BALANCE_WEIGHT>) ... ] (<NEXTHOP_LB_WEIGHT> <nexthop>) ...
<nexthop-list> ::= (<nexthop> <LOAD_BALANCE_WEIGHT>)
[(<nexthop> <LOAD_BALANCE_WEIGHT>)... ]
7.2.4. Protection lists 7.2.4. Protection
Protection lists are similar to weighted lists. A protection list A primary/backup protection can be represented as:
specifies a set of primary nexthops and a set of backup nexthops.
The <PROTECTION_PREFERENCE> attribute indicates which nexthop is
primary and which is backup.
A protection list can be represented as: <nexthop> ::= <1> <interface-primary> <2> <interface-backup>)
<nexthop-list> ::= (<nexthop> <PROTECTION_PREFERENCE>) The above can be derived from the grammar as follows:
[(<nexthop> <PROTECTION_PREFERENCE>)... ]
A protection list can also be a weighted list. In other words, <nexthop> ::= <NEXTHOP_PROTECTION> <nexthop-protection>
traffic can be load-balanced among the primary nexthops of a <nexthop> ::= <NEXTHOP_PROTECTION> (<NEXTHOP_PREFERENCE> <nexthop>
protection list. In such a case, the list will look like: (<NEXTHOP_PREFERENCE> <nexthop>)...)
<nexthop> ::= <NEXTHOP_PROTECTION> (<NEXTHOP_PREFERENCE> <nexthop>
(<NEXTHOP_PREFERENCE> <nexthop>))
<nexthop> ::= <NEXTHOP_PROTECTION> ((<NEXTHOP_PREFERENCE> <nexthop-base>
(<NEXTHOP_PREFERENCE> <nexthop-base>))
<nexthop> ::= <NEXTHOP_PROTECTION> (<1> <interface-primary>
(<2> <interface-backup>))
<nexthop-list> ::= (<nexthop> <PROTECTION_PREFERENCE> Traffic can be load-balanced among multiple primary nexthops and a
<LOAD_BALANCE_WEIGHT>) single backup. In such a case, the nexthop will look like:
[(<nexthop> <PROTECTION_PREFERENCE>
<LOAD_BALANCE_WEIGHT>)... ] <nexthop> ::= <NEXTHOP_PROTECTION> (<1>
(<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop-base>
(<NEXTHOP_LB_WEIGHT> <nexthop-base>) ...))
<2> <nexthop-base>)
A backup can also have another backup. In such a case, the list will
look like:
<nexthop> ::= <NEXTHOP_PROTECTION> (<1> <nexthop>
<2> <nexthop> <3> <nexthop>)
7.2.5. Nexthop chains 7.2.5. Nexthop chains
A nexthop chain is a nexthop that puts one or more headers on an A nexthop chain specifies how to put one or more headers on an
outgoing packet. One example is a Pseudowire - which is MPLS over outgoing packet. One example is a Pseudowire - which is MPLS over
some transport (MPLS or GRE for instance). Another example is VxLAN some transport (MPLS or GRE for instance). Another example is VxLAN
over IP. A nexthop chain allows an external entity to break up the over IP. A nexthop chain allows an external entity to break up the
programming of the nexthop into independent pieces - one per programming of the nexthop into independent pieces - one per
encapsulation. encapsulation.
Elements in a nexthop-chain are evaluated left to right. Elements in a nexthop-chain are evaluated left to right.
A simple example of MPLS over GRE can be represented as: A simple example of MPLS over GRE can be represented as:
<nexthop-list> ::= (<MPLS> <mpls-header>) (<GRE> <gre-header>) <nexthop-chain> ::= (<MPLS> <mpls-header>) (<GRE> <gre-header>
<interface-outgoing>)
The above can be derived from the grammar as follows: The above can be derived from the grammar as follows:
<nexthop-list> ::= <nexthop-list-member> [<nexthop-list-member> ...] <nexthop-chain> ::= <nexthop-chain-member> [<nexthop-chain-member> ...]
<nexthop-list> ::= <nexthop-chain> <nexthop-chain> ::= <tunnel-encap> (<tunnel-encap>
<nexthop-list> ::= <nexthop> [ <nexthop> ... ] <nexthop-chain-member>)
<nexthop-list> ::= <tunnel-encap> (<nexthop> [ <nexthop> ...]) <nexthop-chain> ::= <tunnel-encap> (<tunnel-encap> <EGRESS_INTERFACE>)
<nexthop-list> ::= <tunnel-encap> (<tunnel-encap>) <nexthop-chain> ::= (<MPLS> <mpls-header>) (<GRE> <gre-header>
<nexthop-list> ::= (<MPLS> <mpls-header>) (<GRE> <gre-header>) <interface-outgoing>)
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 load balancing. In other words, for each branch of the replication
primary and backup nexthop (replication list) to ensure there is no tree, there are multiple interfaces on which traffic needs to be
traffic drop in case of a failure. So the outer list is a multicast load-balanced on. So the outer list is a replication list for
list and the inner lists are protection lists of primary/backup multicast and the inner lists are weighted lists for load balancing.
nexthops. Lets take an example of a network element has to replicate traffic to
two other network elements. Traffic to the first network element
<nexthop-list> ::= (<outgoing-1> <outgoing-1-backup>) should be load balanced equally over two interfaces outgoing-1-1 and
(<outgoing-2> <outgoing-2-backup>) outgoing-1-2. Traffic to the second network element should be load
balanced over three interfaces outgoing-2-1, outgoing-2-2 and
The above can be derived from the grammar as follows: outgoing-2-3 in the ratio 20:20:60.
<nexthop-list> ::= (<nexthop-list>) (<nexthop-list>)
<nexthop-list> ::= (<nexthop-list-member> <nexthop-list-member>)
(<nexthop-list>)
<nexthop-list> ::= ((<nexthop-chain> <nexthop-list-member-attributes>)
<nexthop-chain> <nexthop-list-member-attributes>))
(<nexthop-list>)
<nexthop-list> ::= ((<nexthop-chain> <PROTECTION_PREFERENCE>)
(<nexthop-chain> <PROTECTION_PREFERENCE>))
(<nexthop-list>)
<nexthop-list> ::= ((<nexthop-chain> <1>) (<nexthop-chain> <2>))
(<nexthop-list>)
<nexthop-list> ::= ((<nexthop> <1>) (<nexthop> <2>))
(<nexthop-list>)
<nexthop-list> ::= ((<EGRESS_INTERFACE> <1>) (<EGRESS_INTERFACE> <2>))
(<nexthop-list>)
<nexthop-list> ::= ((<eth1> <1>) (<eth2> <2>)) (<nexthop-list>)
// Like above, the <nexthop-list> member on the right can be expanded
to give:
<nexthop-list> ::= ((<eth1> <1>) (<eth2> <2>))
((<eth3> <1>) (<eth4> <2>))
Above, eth1 and eth3 are primary multicast interfaces and eth2 and eth4
are their respective backup interfaces.
Another example of list of lists would be ECMP (load-balancing
traffic across 2 nexthops), wherein each nexthop itself is an
aggregated high-level interface (i.e. load-balance the traffic across
the components of the nexthop itself). See below for the derivation.
<nexthop-list> ::= (<eth1 <0.5>) ((<eth2> <0.5> <eth3> <0.5>) <0.5>)
The above asks for sending 50% traffic to eth1 interface,
25% (50% of 50%) to eth2 and 25% to eth3.
<nexthop-list> ::= (<nexthop-list> <nexthop-list-attributes)
(<nexthop-list> <nexthop-list-attributes)
<nexthop-list> ::= ((<nexthop-list> <LOAD_BALANCE_WEIGHT>)
(<nexthop-list> <LOAD_BALANCE_WEIGHT>)
<nexthop-list> ::= ((<nexthop-list> <0.5>) (<nexthop-list> <0.5>)
<nexthop-list> ::= ((<nexthop-list-member> <0.5>) (<nexthop-list> <0.5>)
<nexthop-list> ::= ((<nexthop-chain> <0.5>) (<nexthop-list> <0.5>)
<nexthop-list> ::= ((<nexthop> <0.5>) (<nexthop-list> <0.5>)
<nexthop-list> ::= ((<EGRESS_INTERFACE> <0.5>) (<nexthop-list> <0.5>)
<nexthop-list> ::= ((<eth1> <0.5>) (<nexthop-list> <0.5>)
<nexthop-list> ::= ((<eth1> <0.5>) This can be derived from the grammar as follows:
((<nexthop-list-member> <nexthop-list-member>) <0.5>)
<nexthop-list> ::= ((<eth1> <0.5>)
((<nexthop-chain> <0.5> <nexthop-chain> <0.5>) <0.5>)
<nexthop-list> ::= ((<eth1> <0.5>)
((<nexthop> <0.5> <nexthop> <0.5>) <0.5>)
<nexthop-list> ::= ((<eth1> <0.5>) ((<eth2> <0.5> <eth3> <0.5>) <0.5>)
One can make this example even more complicated by adding protection <nexthop> ::= <NEXTHOP_REPLICATE> <nexthop-replicate>
nexthops for one or more of the eth interfaces. <nexthop> ::= <NEXTHOP_REPLICATE> (<nexthop> <nexthop>...)
<nexthop> ::= <NEXTHOP_REPLICATE> (<nexthop> <nexthop>)
<nexthop> ::= <NEXTHOP_REPLICATE> ((<NEXTHOP_LOAD_BALANCE> <nexthop-lb>)
(<NEXTHOP_LOAD_BALANCE> <nexthop-lb>))
<nexthop> ::= <NEXTHOP_REPLICATE> ((<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop-lb-member>
(<NEXTHOP_LB_WEIGHT> <nexthop-lb-member>) ...))
((<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop-lb-member>
(<NEXTHOP_LB_WEIGHT> <nexthop-lb-member>) ...))
<nexthop> ::= <NEXTHOP_REPLICATE> ((<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop-lb-member>
(<NEXTHOP_LB_WEIGHT> <nexthop-lb-member>)))
((<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop-lb-member>
(<NEXTHOP_LB_WEIGHT> <nexthop-lb-member>)
(<NEXTHOP_LB_WEIGHT> <nexthop-lb-member>)))
<nexthop> ::= <NEXTHOP_REPLICATE> ((<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop-lb-member>)
(<NEXTHOP_LB_WEIGHT> <nexthop-lb-member>)))
((<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop-lb-member>)
(<NEXTHOP_LB_WEIGHT> <nexthop-lb-member>)
(<NEXTHOP_LB_WEIGHT> <nexthop-lb-member>)))
<nexthop> ::= <NEXTHOP_REPLICATE> ((<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop>)
(<NEXTHOP_LB_WEIGHT> <nexthop>)))
((<NEXTHOP_LOAD_BALANCE> (<NEXTHOP_LB_WEIGHT> <nexthop>)
(<NEXTHOP_LB_WEIGHT> <nexthop>)
(<NEXTHOP_LB_WEIGHT> <nexthop>)))
<nexthop> ::= <NEXTHOP_REPLICATE>
((<NEXTHOP_LOAD_BALANCE>
(50 <outgoing-1-1>)
(50 <outgoing-1-2>)))
((<NEXTHOP_LOAD_BALANCE>
(20 <outgoing-2-1>)
(20 <outgoing-2-2>)
(60 <outgoing-2-3>)))
7.3. Performing multicast 7.3. Performing multicast
IP multicast involves matching a packet on (S, G) or (*, G), where IP multicast involves matching a packet on (S, G) or (*, G), where
both S (source) and G (group) are IP prefixes. Following the match, both S (source) and G (group) are IP prefixes. Following the match,
the packet is replicated to one or more recipients. How the the packet is replicated to one or more recipients. How the
recipients subscribe to the multicast group is outside the scope of recipients subscribe to the multicast group is outside the scope of
this document. this document.
In PIM-based multicast, the packets are IP forwarded on an IP In PIM-based multicast, the packets are IP forwarded on an IP
skipping to change at page 25, line 29 skipping to change at page 25, line 43
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.hares-i2rs-use-case-vn-vc] [I-D.hares-i2rs-use-case-vn-vc]
Hares, S. and M. Chen, "Use Cases for Virtual Connections Hares, S. and M. Chen, "Use Cases for Virtual Connections
on Demand (VCoD) and Virtual Network on Demand (VNoD) on Demand (VCoD) and Virtual Network on Demand (VNoD)
using Interface to Routing System", using Interface to Routing System", draft-hares-i2rs-use-
draft-hares-i2rs-use-case-vn-vc-03 (work in progress), case-vn-vc-03 (work in progress), July 2014.
July 2014.
[I-D.ietf-i2rs-problem-statement] [I-D.ietf-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-ietf-i2rs-
draft-ietf-i2rs-problem-statement-06 (work in progress), problem-statement-06 (work in progress), January 2015.
January 2015.
[I-D.white-i2rs-use-case] [I-D.white-i2rs-use-case]
White, R., Hares, S., and A. Retana, "Protocol Independent White, R., Hares, S., and A. Retana, "Protocol Independent
Use Cases for an Interface to the Routing System", Use Cases for an Interface to the Routing System", draft-
draft-white-i2rs-use-case-06 (work in progress), white-i2rs-use-case-06 (work in progress), July 2014.
July 2014.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC
RFC 4915, June 2007. 4915, June 2007.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 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
 End of changes. 83 change blocks. 
254 lines changed or deleted 259 lines changed or added

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