draft-ietf-i2rs-rib-info-model-02.txt   draft-ietf-i2rs-rib-info-model-03.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: August 18, 2014 Juniper Networks, Inc. Expires: November 28, 2014 Juniper Networks, Inc.
S. Kini, Ed. S. Kini, Ed.
Ericsson Ericsson
J. Medved J. Medved
Cisco Cisco
February 14, 2014 May 27, 2014
Routing Information Base Info Model Routing Information Base Info Model
draft-ietf-i2rs-rib-info-model-02 draft-ietf-i2rs-rib-info-model-03
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
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 August 18, 2014. This Internet-Draft will expire on November 28, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 39 skipping to change at page 2, line 39
2.4.1. Nexthop types . . . . . . . . . . . . . . . . . . . . 11 2.4.1. Nexthop types . . . . . . . . . . . . . . . . . . . . 11
2.4.2. Nexthop list attributes . . . . . . . . . . . . . . . 12 2.4.2. Nexthop list attributes . . . . . . . . . . . . . . . 12
2.4.3. Nexthop content . . . . . . . . . . . . . . . . . . . 13 2.4.3. Nexthop content . . . . . . . . . . . . . . . . . . . 13
2.4.4. Special nexthops . . . . . . . . . . . . . . . . . . 14 2.4.4. Special nexthops . . . . . . . . . . . . . . . . . . 14
3. Reading from the RIB . . . . . . . . . . . . . . . . . . . . 14 3. Reading from the RIB . . . . . . . . . . . . . . . . . . . . 14
4. Writing to the RIB . . . . . . . . . . . . . . . . . . . . . 14 4. Writing to the RIB . . . . . . . . . . . . . . . . . . . . . 14
5. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 15
6. RIB grammar . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. RIB grammar . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Using the RIB grammar . . . . . . . . . . . . . . . . . . . . 18 7. Using the RIB grammar . . . . . . . . . . . . . . . . . . . . 18
7.1. Using route preference . . . . . . . . . . . . . . . . . 18 7.1. Using route preference . . . . . . . . . . . . . . . . . 18
7.2. Using different nexthops types . . . . . . . . . . . . . 19 7.2. Using different nexthops types . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . . 19 7.2.3. Weighted lists . . . . . . . . . . . . . . . . . . . 19
7.2.4. Protection lists . . . . . . . . . . . . . . . . . . 20 7.2.4. Protection lists . . . . . . . . . . . . . . . . . . 20
7.2.5. Nexthop chains . . . . . . . . . . . . . . . . . . . 20 7.2.5. Nexthop chains . . . . . . . . . . . . . . . . . . . 20
7.2.6. Lists of lists . . . . . . . . . . . . . . . . . . . 21 7.2.6. Lists of lists . . . . . . . . . . . . . . . . . . . 21
7.3. Performing multicast . . . . . . . . . . . . . . . . . . 21 7.3. Performing multicast . . . . . . . . . . . . . . . . . . 21
8. RIB operations at scale . . . . . . . . . . . . . . . . . . . 22 8. RIB operations at scale . . . . . . . . . . . . . . . . . . . 22
8.1. RIB reads . . . . . . . . . . . . . . . . . . . . . . . . 22 8.1. RIB reads . . . . . . . . . . . . . . . . . . . . . . . . 22
8.2. RIB writes . . . . . . . . . . . . . . . . . . . . . . . 22 8.2. RIB writes . . . . . . . . . . . . . . . . . . . . . . . 22
skipping to change at page 4, line 22 skipping to change at page 4, line 22
distributed network control is used. However there are use cases distributed network control is used. However there are use cases
which the network operators currently address by configuring static which the network operators currently address by configuring static
routes, policies and RIB import/export rules on the routers. There routes, policies and RIB import/export rules on the routers. There
is also a growing list of use cases [I-D.white-i2rs-use-case], is also a growing list of use cases [I-D.white-i2rs-use-case],
[I-D.hares-i2rs-use-case-vn-vc] in which a network operator might [I-D.hares-i2rs-use-case-vn-vc] in which a network operator might
want to program the RIB based on data unrelated to just routing want to program the RIB based on data unrelated to just routing
(within that network's domain). Programming the RIB could be based (within that network's domain). Programming the RIB could be based
on other information such as routing data in the adjacent domain or on other information such as routing data in the adjacent domain or
the load on storage and compute in the given domain. Or it could the load on storage and compute in the given domain. Or it could
simply be a programmatic way of creating on-demand dynamic overlays simply be a programmatic way of creating on-demand dynamic overlays
(e.g. GRE tunnels) between compute hosts (without requiring the hosts (e.g. GRE tunnels) between compute hosts (without requiring the
to run traditional routing protocols). If there was a standardized hosts to run traditional routing protocols). If there was a
publicly documented programmatic interface to a RIB, it would enable standardized publicly documented programmatic interface to a RIB, it
further networking applications that address a variety of use-cases would enable further networking applications that address a variety
[I-D.ietf-i2rs-problem-statement]. of use-cases [I-D.ietf-i2rs-problem-statement].
A programmatic interface to the RIB involves 2 types of operations - A programmatic interface to the RIB involves 2 types of operations -
reading from the RIB and writing (adding/modifying/deleting) to the reading from the RIB and writing (adding/modifying/deleting) to the
RIB. [I-D.white-i2rs-use-case] lists various use-cases which require RIB. [I-D.white-i2rs-use-case] lists various use-cases which require
read and/or write manipulation of the RIB. 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 used. These protocol SNMP MIBs and show output screen scraping are used. These
methods are not scalable, since they are client pull mechanisms and methods are not scalable, since they are client pull mechanisms and
not proactive push (from the router) mechanisms. Screen scraping is not proactive push (from the router) mechanisms. Screen scraping is
skipping to change at page 6, line 10 skipping to change at page 6, line 10
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 belong given RIB MUST be of the same type (e.g. IPv4). Each RIB MUST
to a routing instance. belong to a routing instance.
A routing instance can have multiple RIBs. A routing instance can A routing instance can have multiple RIBs. A routing instance can
even have two or more RIBs with the same type of routes (e.g. IPv6). even have two or more RIBs with the same type of routes (e.g. IPv6).
A typical case where this can be used is for multi-topology routing A typical case where this can be used is for multi-topology routing
([RFC4915], [RFC5120]). ([RFC4915], [RFC5120]).
Each RIB can be optionally associated with a ENABLE_IP_RPF_CHECK Each RIB can be optionally associated with a ENABLE_IP_RPF_CHECK
attribute that enables Reverse path forwarding (RPF) checks on all IP attribute that enables Reverse path forwarding (RPF) checks on all IP
routes in that RIB. Reverse path forwarding (RPF) check is used to routes in that RIB. Reverse path forwarding (RPF) check is used to
prevent spoofing and limit malicious traffic. For IP packets, the IP prevent spoofing and limit malicious traffic. For IP packets, the IP
source address is looked up and the rpf interface(s) associated with source address is looked up and the rpf interface(s) associated with
the route for that IP source address is found. If the incoming IP the route for that IP source address is found. If the incoming IP
packet's interface matches one of the rpf interface(s), then the IP packet's interface matches one of the rpf interface(s), then the IP
skipping to change at page 9, line 32 skipping to change at page 9, line 32
interface, then the nexthop represents that interface. interface, then the nexthop represents that interface.
Nexthops can be fully resolved nexthops or unresolved nexthop. A Nexthops can be fully resolved nexthops or unresolved nexthop. A
resolved nexthop has adequate information to send the outgoing packet resolved nexthop has adequate information to send the outgoing packet
to the destination by forwarding it on an interface to a directly to the destination by forwarding it on an interface to a directly
connected neighbor. For example, a nexthop to a point-to-point connected neighbor. For example, a nexthop to a point-to-point
interface or a nexthop to an IP address on an Ethernet interface has interface or a nexthop to an IP address on an Ethernet interface has
the nexthop resolved. An unresolved nexthop is something that the nexthop resolved. An unresolved nexthop is something that
requires the RIB manager to determine the final resolved nexthop. requires the RIB manager to determine the final resolved nexthop.
For example, a nexthop could be an IP address. The RIB manager would For example, a nexthop could be an IP address. The RIB manager would
resolve how to reach that IP address, e.g. is the IP address resolve how to reach that IP address, e.g. is the IP address
reachable by regular IP forwarding or by a MPLS tunnel or by both. reachable by regular IP forwarding or by a MPLS tunnel or by both.
If the RIB manager cannot resolve the nexthop, then the nexthop If the RIB manager cannot resolve the nexthop, then the nexthop
remains in an unresolved state and is NOT a candidate for remains in an unresolved state and is NOT a candidate for
installation in the FIB. Future RIB events can cause an unresolved installation in the FIB. Future RIB events can cause an unresolved
nexthop to get resolved (like that IP address being advertised by an nexthop to get resolved (like that IP address being advertised by an
IGP neighbor). Conversely resolved nexthops can also become IGP neighbor). Conversely resolved nexthops can also become
unresolved (e.g. in case of a tunnel going down) and hence would no unresolved (e.g. in case of a tunnel going down) and hence would no
longer be candidates to be installed in the FIB. longer be candidates to be installed in the FIB.
When at least one of a route's nexthops is resolved, then the route When at least one of a route's nexthops is resolved, then the route
skipping to change at page 11, line 33 skipping to change at page 11, line 33
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 Protection lists - for primary/backup paths
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
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
skipping to change at page 15, line 14 skipping to change at page 15, line 14
Route programming in the RIB MUST result in a return code that Route programming in the RIB MUST result in a return code that
contains the following attributes: contains the following attributes:
o Installed - Yes/No (Indicates whether the route got installed in o Installed - Yes/No (Indicates whether the route got installed in
the FIB) the FIB)
o Active - Yes/No (Indicates whether a route is fully resolved and o Active - Yes/No (Indicates whether a route is fully resolved and
is a candidate for selection) is a candidate for selection)
o Reason - E.g. Not authorized o Reason - E.g. Not authorized
The data-model MUST specify which objects are modify-able objects. A The data-model MUST specify which objects are modify-able objects. A
modify-able object is one whose contents can be changed without modify-able object is one whose contents can be changed without
having to change objects that depend on it and without affecting any having to change objects that depend on it and without affecting any
data forwarding. To change a non-modifiable object, one will need to data forwarding. To change a non-modifiable object, one will need to
create a new object and delete the old one. For example, routes that 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
skipping to change at page 15, line 41 skipping to change at page 15, line 41
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].
<routing-instance> ::= <INSTANCE_NAME> <routing-instance> ::= <INSTANCE_NAME>
[<interface-list>] <rib-list> [<interface-list>] <rib-list>
[<ROUTER_ID>] [<ROUTER_ID>]
<interface-list> ::= (<INTERFACE_IDENTIFIER> ...)
<rib-list> ::= (<rib> ...) <interface-list> ::= (<INTERFACE_IDENTIFIER> ...)
<rib> ::= <RIB_NAME> <rib-family>
[<route> ... ]
[ENABLE_IP_RPF_CHECK]
<rib-family> ::= <IPV4_RIB_FAMILY> | <IPV6_RIB_FAMILY> | <rib-list> ::= (<rib> ...)
<MPLS_RIB_FAMILY> | <IEEE_MAC_RIB_FAMILY> <rib> ::= <RIB_NAME> <rib-family>
[<route> ... ]
[ENABLE_IP_RPF_CHECK]
<route> ::= <match> <nexthop-list> <rib-family> ::= <IPV4_RIB_FAMILY> | <IPV6_RIB_FAMILY> |
[<route-attributes>] <MPLS_RIB_FAMILY> | <IEEE_MAC_RIB_FAMILY>
[<route-vendor-attributes>]
<match> ::= <ipv4-route> | <ipv6-route> | <mpls-route> | <route> ::= <match> <nexthop-list>
<mac-route> | <interface-route> [<route-attributes>]
[<route-vendor-attributes>]
<ipv4-route> ::= <destination-ipv4-address> | <source-ipv4-address> | <match> ::= <route-type> (<ipv4-route> | <ipv6-route> | <mpls-route> |
(<destination-ipv4-address> <source-ipv4-address>) <mac-route> | <interface-route>)
<destination-ipv4-address> ::= <ipv4-prefix> <route-type> ::= <IPV4> | <IPV6> | <MPLS> | <IEEE_MAC> | <INTERFACE>
<source-ipv4-address> ::= <ipv4-prefix>
<ipv4-prefix> ::= <IPV4_ADDRESS> <IPV4_PREFIX_LENGTH>
<ipv6-route> ::= <destination-ipv6-address> | <source-ipv6-address> | <ipv4-route> ::= <ip-route-type>
(<destination-ipv6-address> <source-ipv6-address>) (<destination-ipv4-address> | <source-ipv4-address> |
<destination-ipv6-address> ::= <ipv6-prefix> (<destination-ipv4-address> <source-ipv4-address>))
<source-ipv6-address> ::= <ipv6-prefix> <destination-ipv4-address> ::= <ipv4-prefix>
<ipv6-prefix> ::= <IPV6_ADDRESS> <IPV6_PREFIX_LENGTH> <source-ipv4-address> ::= <ipv4-prefix>
<ipv4-prefix> ::= <IPV4_ADDRESS> <IPV4_PREFIX_LENGTH>
<mpls-route> ::= <MPLS> <MPLS_LABEL> <ipv6-route> ::= <ip-route-type>
<mac-route> ::= <IEEE_MAC> ( <MAC_ADDRESS> ) (<destination-ipv6-address> | <source-ipv6-address> |
<interface-route> ::= <INTERFACE> <INTERFACE_IDENTIFIER> (<destination-ipv6-address> <source-ipv6-address>))
<destination-ipv6-address> ::= <ipv6-prefix>
<source-ipv6-address> ::= <ipv6-prefix>
<ipv6-prefix> ::= <IPV6_ADDRESS> <IPV6_PREFIX_LENGTH>
<ip-route-type> ::= <SRC> | <DEST> | <DEST_SRC>
<multicast-source-ipv4-address> ::= <IPV4_ADDRESS> <mpls-route> ::= <MPLS_LABEL>
<IPV4_PREFIX_LENGTH> <mac-route> ::= <MAC_ADDRESS>
<multicast-source-ipv6-address> ::= <IPV6_ADDRESS> <interface-route> ::= <INTERFACE_IDENTIFIER>
<IPV6_PREFIX_LENGTH>
<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> ::= <>
<nexthop-list> ::= <special-nexthop> | <nexthop-list> ::= <special-nexthop> |
((<nexthop-list-member>) | ((<nexthop-list-member>) |
([<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> | <EGRESS_INTERFACE> | <nexthop> ::= (<nexthop-identifier> | <EGRESS_INTERFACE> |
<ipv4-address> | <ipv6-address> | <ipv4-address> | <ipv6-address> |
(<EGRESS_INTERFACE> (<ipv4-address> | <ipv6-address>) (<EGRESS_INTERFACE> (<ipv4-address> | <ipv6-address>)
[RIB_NAME]) | [RIB_NAME]) |
(<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> <nexthop-identifier> ::= <NEXTHOP_NAME> | <NEXTHOP_ID>
<nexthop-address> ::= (<IPv4> <ipv4-address>) | <special-nexthop> ::= <DISCARD> | <DISCARD_WITH_ERROR> |
(<IPV6> <ipv6-address>) | (<RECEIVE> [<COS_VALUE>])
(<IEEE_MAC> <IEEE_MAC_ADDRESS>)
<special-nexthop> ::= <DISCARD> | <DISCARD_WITH_ERROR> |
(<RECEIVE> [<COS_VALUE>] [<rate-limiter>])
<rate-limiter> ::= <>
<logical-tunnel> ::= <tunnel-type> <TUNNEL_NAME> <logical-tunnel> ::= <tunnel-type> <TUNNEL_NAME>
<tunnel-type> ::= <IP> | <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>) |
(<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>]
<ipv6-header> ::= <SOURCE_IPV6_ADDRESS> <DESTINATION_IPV6_ADDRESS> <ipv6-header> ::= <SOURCE_IPV6_ADDRESS> <DESTINATION_IPV6_ADDRESS>
<NEXT_HEADER> [<TRAFFIC_CLASS>] <NEXT_HEADER> [<TRAFFIC_CLASS>]
[<FLOW_LABEL>] [<HOP_LIMIT>] [<FLOW_LABEL>] [<HOP_LIMIT>]
<mpls-header> ::= (<mpls-label-operation> ...) <mpls-header> ::= (<mpls-label-operation> ...)
<mpls-label-operation> ::= (<MPLS_PUSH> <MPLS_LABEL> [<S_BIT>] <mpls-label-operation> ::= (<MPLS_PUSH> <MPLS_LABEL> [<S_BIT>]
[<TOS_VALUE>] [<TTL_VALUE>]) | [<TOS_VALUE>] [<TTL_VALUE>]) |
(<MPLS_POP> [<TTL_ACTION>]) (<MPLS_POP> [<TTL_ACTION>])
<gre-header> ::= <GRE_IP_DESTINATION> <GRE_PROTOCOL_TYPE> [<GRE_KEY>] <gre-header> ::= <GRE_IP_DESTINATION> <GRE_PROTOCOL_TYPE> [<GRE_KEY>]
<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
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
skipping to change at page 23, line 15 skipping to change at page 23, line 15
10. IANA Considerations 10. IANA Considerations
This document does not generate any considerations for IANA. This document does not generate any considerations for IANA.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank the working group co-chairs and The authors would like to thank the working group co-chairs and
reviewers on their comments and suggestions on this draft. The reviewers on their comments and suggestions on this draft. The
following people contributed to the design of the RIB model as part following people contributed to the design of the RIB model as part
of the I2RS Interim meeting in April 2013 - Wes George, Chris of the I2RS Interim meeting in April 2013 - Wes George, Chris
Liljenstolpe, Jeff Tantsura, Sriganesh Kini, Susan Hares, Fabian Liljenstolpe, Jeff Tantsura, Susan Hares and Fabian Schneider.
Schneider and Nitin Bahadur.
12. References 12. References
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., "Use Cases for Virtual Connections on Demand Hares, S. and M. Chen, "Use Cases for Virtual Connections
(VCoD) and Virtual Network on Demand using Interface to on Demand (VCoD) and Virtual Network on Demand (VNoD)
Routing System", draft-hares-i2rs-use-case-vn-vc-00 (work using Interface to Routing System", draft-hares-i2rs-use-
in progress), February 2013. case-vn-vc-02 (work in progress), February 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", draft-ietf-i2rs- Routing System Problem Statement", draft-ietf-i2rs-
problem-statement-00 (work in progress), August 2013. problem-statement-01 (work in progress), May 2014.
[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", draft- Use Cases for an Interface to the Routing System", draft-
white-i2rs-use-case-01 (work in progress), August 2013. white-i2rs-use-case-02 (work in progress), February 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", RFC Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 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
skipping to change at page 24, line 37 skipping to change at page 24, line 33
URI: www.juniper.net URI: www.juniper.net
Sriganesh Kini (editor) Sriganesh Kini (editor)
Ericsson Ericsson
Email: sriganesh.kini@ericsson.com Email: sriganesh.kini@ericsson.com
Jan Medved Jan Medved
Cisco Cisco
Email: jmedved@cisco.com Email: jmedved@cisco.co
 End of changes. 37 change blocks. 
114 lines changed or deleted 108 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/