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/ |