-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-ietf-i2rs-rib-info-model.xml
executable file
·1267 lines (1044 loc) · 58.3 KB
/
draft-ietf-i2rs-rib-info-model.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4271 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC4915 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4915.xml">
<!ENTITY RFC5065 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5065.xml">
<!ENTITY RFC5120 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5120.xml">
<!ENTITY RFC5246 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5511 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5511.xml">
<!ENTITY RFC6020 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC6241 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6242 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml">
<!ENTITY RFC8341 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml">
<!ENTITY RFC7920 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7920.xml">
<!ENTITY RFC8040 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY I2RS-RIB-DATA-MODEL SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-data-model.xml">
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="info" docName="draft-ietf-i2rs-rib-info-model-17"
ipr="trust200902">
<front>
<title>Routing Information Base Info Model</title>
<author fullname="Nitin Bahadur" initials="N.B." role="editor"
surname="Bahadur">
<organization>Uber</organization>
<address>
<postal>
<street>900 Arastradero Rd</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>
<email>nitin_bahadur@yahoo.com</email>
</address>
</author>
<author fullname="Sriganesh Kini" initials="S.K." role="editor"
surname="Kini">
<address>
<email>sriganeshkini@gmail.com</email>
</address>
</author>
<author fullname="Jan Medved" initials="J.M." surname="Medved">
<organization>Cisco</organization>
<address>
<email>jmedved@cisco.com</email>
</address>
</author>
<!---->
<date day="7" month="May" year="2018"/>
<area>Routing</area>
<workgroup>Network Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>RIB</keyword>
<keyword>info model</keyword>
<abstract>
<t>Routing and routing functions in enterprise and carrier networks are
typically performed by network devices (routers and switches) using a
routing information base (RIB). Protocols and configuration push data
into the RIB and the RIB manager installs state into the hardware for
packet forwarding. This draft specifies an information model for the RIB
to enable defining a standardized data model, and it was used by the
IETF’s I2RS WG to design the I2RS RIB data model. It is being
published to record the higher-level informational model decisions for
RIBs so that other developers of RIBs may benefit from the design
concepts.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction" toc="default">
<t>Routing and routing functions in enterprise and carrier networks are
traditionally performed in network devices. Traditionally routers run
routing protocols and the routing protocols (along with static
configuration information) populate the Routing Information Base (RIB)
of the router. The RIB is managed by the RIB manager and the RIB manager
provides a northbound interface to its clients, i.e., the routing
protocols, to insert routes into the RIB. The RIB manager consults the
RIB and decides how to program the Forwarding Information Base (FIB) of
the hardware by interfacing with the FIB manager. The relationship
between these entities is shown in <xref
target="rib-fib-interaction"/>.</t>
<figure align="center" anchor="rib-fib-interaction"
title="RIB manager, RIB clients, and FIB managers">
<artwork align="left"><![CDATA[
+-------------+ +-------------+
|RIB client 1 | ...... |RIB client N |
+-------------+ +-------------+
^ ^
| |
+----------------------+
|
V
+---------------------+
| RIB manager |
| |
| +--------+ |
| | RIB(s) | |
| +--------+ |
+---------------------+
^
|
+---------------------------------+
| |
V V
+----------------+ +----------------+
| FIB manager 1 | | FIB manager M |
| +--------+ | .......... | +--------+ |
| | FIB(s) | | | | FIB(s) | |
| +--------+ | | +--------+ |
+----------------+ +----------------+
]]></artwork>
</figure>
<t>Routing protocols are inherently distributed in nature and each
router makes an independent decision based on the routing data received
from its peers. With the advent of newer deployment paradigms and the
need for specialized applications, there is an emerging need to guide
the router's routing function <xref target="RFC7920"/>. Traditional
network-device protocol-based RIB population suffices for most use cases
where distributed network control is used. However there are use cases
that the network operators currently address by configuring static
routes, policies, and RIB import/export rules on the routers. There is
also a growing list of use cases in which a network operator might want
to program the RIB based on data unrelated to just routing (within that
network's domain). Programming the RIB could be based 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 simply be a
programmatic way of creating on-demand dynamic overlays (e.g., GRE
tunnels) between compute hosts (without requiring the hosts to run
traditional routing protocols). If there was a standardized
publicly-documented, programmatic interface to a RIB, it would enable
further networking applications that address a variety of use cases
<xref target="RFC7920"/>.</t>
<t>A programmatic interface to the RIB involves 2 types of operations -
reading from the RIB and writing (adding/modifying/deleting) to the
RIB.</t>
<t>In order to understand what is in a router's RIB, methods like
per-protocol SNMP MIBs and screen scraping are used. These methods are
not scalable, since they are client pull mechanisms and not proactive
push (from the router) mechanisms. Screen scraping is error prone (since
the output format can change) and is vendor dependent. Building a RIB
from per-protocol MIBs is error prone since the MIB data represent
protocol data and not the exact information that went into the RIB.
Thus, just getting read-only RIB information from a router is a hard
task.</t>
<t>Adding content to the RIB from a RIB client can be done today using
static configuration mechanisms provided by router vendors. However the
mix of what can be modified in the RIB varies from vendor to vendor and
the method of configuring it is also vendor dependent. This makes it
hard for a RIB client to program a multi-vendor network in a consistent
and vendor-independent way.</t>
<t>The purpose of this draft is to specify an information model for the
RIB. Using the information model, one can build a detailed data model
for the RIB. That data model could then be used by a RIB client to
program a network device. One data model that has been based on this
draft is the I2RS RIB data model <xref
target="I-D.ietf-i2rs-rib-data-model"></xref>.</t>
<t>The rest of this document is organized as follows. <xref
target="rib-data"> </xref> goes into the details of what constitutes and
can be programmed in a RIB. Guidelines for reading and writing the RIB
are provided in <xref target="rib-read"/> and <xref target="rib-write"/>
respectively. <xref target="events"/> provides a high-level view of the
events and notifications going from a network device to a RIB client, to
update the RIB client on asynchronous events. The RIB grammar is
specified in <xref target="rib-grammar"/>. Examples of using the RIB
grammar are shown in <xref target="rib-examples"/>. <xref
target="rib-scale"/> covers considerations for performing RIB operations
at scale.</t>
<section title="Conventions used in this document">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section>
</section>
<section anchor="rib-data" title="RIB data" toc="default">
<t>This section describes the details of a RIB. It makes forward
references to objects in the RIB grammar (<xref target="rib-grammar"/>).
A high-level description of the RIB contents is as shown in <xref
target="rib-model"/>. Please note that for ease of ASCII art
representation this drawing shows a single routing-instance, a single
RIB, and a single route. Sub-sections of this section describe the
logical data nodes that should be contained within a RIB. <xref
target="rib-read"/> and <xref target="rib-write"/> describe the
high-level read and write operations.</t>
<figure anchor="rib-model" title="RIB model">
<artwork name="RIB model"><![CDATA[
network-device
|
| 0..N
|
routing-instance(s)
| |
| |
0..N | | 0..N
| |
interface(s) RIB(s)
|
|
| 0..N
|
route(s)
]]></artwork>
</figure>
<section title="RIB definition">
<t>A RIB, in the context of the RIB information model, is an entity
that contains routes. It is identified by its name and is contained
within a routing instance (<xref target="routing-instance"/>). A
network device MAY contain routing instances and each routing instance
MAY contain RIBs. The name MUST be unique within a routing instance.
All routes in a given RIB MUST be of the same address family (e.g.,
IPv4). Each RIB MUST belong to a routing instance.</t>
<t>A routing instance may contain two or more RIBs of the same address
family (e.g., IPv6). A typical case where this can be used is for
multi-topology routing (<xref target="RFC4915"/>, <xref
target="RFC5120"/>).</t>
<t>Each RIB MAY be associated with an ENABLE_IP_RPF_CHECK attribute
that enables REVERSE PATH FORWARDING (RPF) checks on all IP routes in
that RIB. The RPF check is used to prevent spoofing and limit
malicious traffic. For IP packets, the IP source address is looked up
and the RPF interface(s) associated with the route for that IP source
address is found. If the incoming IP packet's interface matches one of
the RPF interface(s), then the IP packet is forwarded based on its IP
destination address; otherwise, the IP packet is discarded.</t>
</section>
<section anchor="routing-instance" title="Routing instance">
<t>A routing instance, in the context of the RIB information model, is
a collection of RIBs, interfaces, and routing parameters. A routing
instance creates a logical slice of the router. It allows different
logical slices across a set of routers to communicate with each other.
Layer 3 Virtual Private Networks (VPN), Layer 2 VPNs (L2VPN) and
Virtual Private Lan Service (VPLS) can be modeled as routing
instances. Note that modeling a Layer 2 VPN using a routing instance
only models the Layer-3 (RIB) aspect and does not model any layer-2
information (like ARP) that might be associated with the L2VPN.</t>
<t>The set of interfaces indicates which interfaces are associated
with this routing instance. The RIBs specify how incoming traffic is
to be forwarded, and the routing parameters control the information in
the RIBs. The intersection set of interfaces of 2 routing instances
MUST be the null set. In other words, an interface MUST NOT be present
in 2 routing instances. Thus a routing instance describes the routing
information and parameters across a set of interfaces.</t>
<t>A routing instance MUST contain the following mandatory
fields:<list style="symbols">
<t>INSTANCE_NAME: A routing instance is identified by its name,
INSTANCE_NAME. This MUST be unique across all routing instances in
a given network device.</t>
<t>rib-list: This is the list of RIBs associated with this routing
instance. Each routing instance can have multiple RIBs to
represent routes of different types. For example, one would put
IPv4 routes in one RIB and MPLS routes in another RIB. The list of
RIBs can be an empty list.</t>
</list></t>
<t>A routing instance MAY contain the following fields:<list
style="symbols">
<t>interface-list: This represents the list of interfaces
associated with this routing instance. The interface list helps
constrain the boundaries of packet forwarding. Packets coming in
on these interfaces are directly associated with the given routing
instance. The interface list contains a list of identifiers, with
each identifier uniquely identifying an interface.</t>
<t>ROUTER_ID: This field identifies the network device in control
plane interactions with other network devices. This field is to be
used if one wants to virtualize a physical router into multiple
virtual routers. Each virtual router MUST have a unique ROUTER_ID.
ROUTER_ID MUST be unique across all network devices in a given
domain.</t>
</list>A routing instance may be created purely for the purposes of
packet processing and may not have any interfaces associated with it.
For example, an incoming packet in routing instance A might have a
nexthop of routing instance B and after packet processing in B, the
nexthop might be routing instance C. Thus, routing instance B is not
associated with any interface. And given that this routing instance
does not do any control plane interaction with other network devices,
a ROUTER_ID is also not needed.</t>
</section>
<section title="Route">
<t>A route is essentially a match condition and an action following
the match. The match condition specifies the kind of route (IPv4,
MPLS, etc.) and the set of fields to match on. <xref
target="route-model"/> represents the overall contents of a route.
Please note that for ease of depiction in ASCII art only a single
instance of the route attribute, match flags, or nexthop is
depicted.</t>
<figure anchor="route-model" title="Route model">
<artwork name="Route model"><![CDATA[
route
| | |
+---------+ | +----------+
| | |
0..N | | |
route-attribute match nexthop
|
|
+-------+-------+-------+--------+
| | | | |
| | | | |
IPv4 IPv6 MPLS MAC Interface
]]></artwork>
</figure>
<t>This document specifies the following match types:<list
style="symbols">
<t>IPv4: Match on destination and/or source IP address in the IPv4
header</t>
<t>IPv6: Match on destination and/or source IP address in the IPv6
header</t>
<t>MPLS: Match on an MPLS label at the top of the MPLS label
stack</t>
<t>MAC: Match on MAC destination addresses in the Ethernet
header</t>
<t>Interface: Match on incoming interface of the packet</t>
</list></t>
<t>A route MAY be matched on one or more these match types by policy
as either an “AND” (to restrict the number of routes) or
an “OR” (to combine two filters).</t>
<t>Each route MUST have associated with it the following mandatory
route attributes:<list style="symbols">
<t>ROUTE_PREFERENCE: This is a numerical value that allows for
comparing routes from different protocols. Static configuration is
also considered a protocol for the purpose of this field. It is
also known as administrative-distance. The lower the value, the
higher the preference. For example there can be an OSPF route for
192.0.2.1/32 (or IPv6 2001:DB8::1/128) with a preference of 5. If
a controller programs a route for 192.0.2.1/32 (or IPv6
2001:DB8::1/128) with a preference of 2, then the controller's
route will be preferred by the RIB manager. Preference should be
used to dictate behavior. For more examples of preference, see
<xref target="route-preference"/>.</t>
</list></t>
<t>Each route can have associated with it one or more optional route
attributes.<list style="symbols">
<t>route-vendor-attributes: Vendors can specify vendor-specific
attributes using this. The details of this attribute is outside
the scope of this document.</t>
</list></t>
<t>Each route has associated with it a nexthop. Nexthop is described
in <xref target="nexthop"/>.</t>
<t>Additional features to match multicast packets were considered
(e.g., TTL of the packet to limit the range of a multicast group), but
these were not added to this information model. Future RIB information
models should investigate these multicast features.</t>
</section>
<section anchor="nexthop" title="Nexthop">
<t>A nexthop represents an object resulting from a route lookup. For
example, if a route lookup results in sending the packet out a given
interface, then the nexthop represents that interface.</t>
<t>Nexthops can be fully resolved nexthops or unresolved nexthop. A
resolved nexthop has adequate information to send the outgoing packet
to the destination by forwarding it on an interface to a directly
connected neighbor. For example, a nexthop to a point-to-point
interface or a nexthop to an IP address on an Ethernet interface has
the nexthop resolved. An unresolved nexthop is something that requires
the RIB manager to determine the final resolved nexthop. 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 reachable by regular IP
forwarding or by an MPLS tunnel or by both. If the RIB manager cannot
resolve the nexthop, then the nexthop remains in an unresolved state
and is NOT a candidate for installation in the FIB. Future RIB events
can cause an unresolved nexthop to get resolved (e.g., IP address
being advertised by an IGP neighbor). Conversely, resolved nexthops
can also become unresolved (e.g., in the case of a tunnel going down)
and hence would no longer be candidates to be installed in the
FIB.</t>
<t>When at least one of a route's nexthops is resolved, then the route
can be used to forward packets. Such a route is considered eligible to
be installed in the FIB and is henceforth referred to as a
FIB-eligible route. Conversely, when all the nexthops of a route are
unresolved that route can no longer be used to forward packets. Such a
route is considered ineligible to be installed in the FIB and is
henceforth referred to as a FIB-ineligible route. The RIB information
model allows a RIB client to program routes whose nexthops may be
unresolved initially. Whenever an unresolved nexthop gets resolved,
the RIB manager will send a notification of the same (see <xref
target="events"/> ).</t>
<t>The overall structure and usage of a nexthop is as shown in the
figure below. For ease of ASCII art depiction, only a single instance
of any component of the nexthop is shown in <xref
target="nexthop-model"/>.</t>
<figure anchor="nexthop-model" title="Nexthop model">
<artwork name="Nexthop model"><![CDATA[
route
|
| 0..N
|
nexthop <-------------------------------+
| |
+-------+----------------------------+-------------+ |
| | | | | |
| | | | | |
base load-balance protection replicate chain |
| | | | | |
| |2..N |2..N |2..N |1..N |
| | | | | |
| | V | | |
| +------------->+<------------+-------------+ |
| | |
| +-------------------------------------+
|
+-------------------+
|
|
|
|
+---------------+--------+--------+--------------+----------+
| | | | |
| | | | |
nexthop-id egress-interface ip-address logical-tunnel |
|
|
+--------------------------------------+
|
+--------------+----------+-------------+
| | | |
| | | |
tunnel-encap tunnel-decap rib-name special-nexthop
]]></artwork>
</figure>
<t>This document specifies a very generic, extensible, and recursive
grammar for nexthops. A nexthop can be a base nexthop or a derived
nexthop. <xref target="base-nexthop"/> details base nexthops and <xref
target="derived-nexthop"/> explains various kinds of derived nexthops.
There are certain special nexthops and those are described in <xref
target="special-nexthops"/>. Lastly, <xref
target="nexthop-indirection"/> delves into nexthop indirection and
it's use. Examples of when and how to use tunnel nexthops and derived
nexthops are shown in <xref target="nexthop-examples"/>.</t>
<section anchor="base-nexthop" title="Base nexthop">
<t>At the lowest level, a nexthop can be one of:<list
style="symbols">
<t>Identifier: This is an identifier returned by the network
device representing a nexthop. This can be used as a way of
re-using a nexthop when programming derived nexthops.</t>
<t>Interface nexthops - nexthops pointing to an interface.
Various attributes associated with these nexthops are: <list
style="symbols">
<t>EGRESS_INTERFACE: This represents a physical, logical, or
virtual interface on the network device. Address resolution
must not be required on this interface. This interface may
belong to any routing instance.</t>
<t>IP address: A route lookup on this IP address is done to
determine the egress interface. Address resolution may be
required depending on the interface. <list style="symbols">
<t>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 RIB name field to direct the packet
from one domain into another domain. By default the RIB
will be the same as the one that route belongs to.</t>
</list></t>
</list> These attributes can be used in combination as
follows: <list style="symbols">
<t>EGRESS_INTERFACE and IP address: This can be used in
cases, e.g., where the IP address is a link-local
address.</t>
<t>EGRESS_INTERFACE and MAC address: The egress interface
must be an Ethernet interface. Address resolution is not
required for this nexthop.</t>
</list></t>
<t>Tunnel nexthops - nexthops pointing to a tunnel. The types of
tunnel nexthops are: <list style="symbols">
<t>tunnel-encap: This can be an encapsulation representing
an IP tunnel or MPLS tunnel or others as defined in this
document. An optional egress interface can be chained to the
tunnel-encap to indicate which interface to send the packet
out on. The egress interface is useful when the network
device contains Ethernet interfaces and one needs to perform
address resolution for the IP packet.</t>
<t>tunnel-decap: This is to specify decapsulating a tunnel
header. After decapsulation, further lookup on the packet
can be done via chaining it with another nexthop. The packet
can also be sent out via an EGRESS_INTERFACE directly.</t>
<t>logical-tunnel: This can be an MPLS LSP or a GRE tunnel
(or others as defined in this document), that is represented
by a unique identifier (e.g., name).</t>
</list></t>
<t>RIB_NAME: A nexthop pointing to a RIB. This indicates that
the route lookup needs to continue in the specified RIB. This is
a way to perform chained lookups.</t>
</list></t>
<t>Tunnel nexthops allow a RIB client to program static tunnel
headers. There can be cases where the remote tunnel endpoint does
not support dynamic signaling (e.g., no LDP support on a host) and
in those cases the RIB client might want to program the tunnel
header on both ends of the tunnel. The tunnel nexthop is kept
generic with specifications provided for some commonly used tunnels.
It is expected that the data-model will model these tunnel types
with complete accuracy.</t>
<section anchor="special-nexthops" title="Special nexthops">
<t>Special nexthops are for performing specific well-defined
functions (e.g., discard). The purpose of each of them is
explained below:<list style="symbols">
<t>DISCARD: This indicates that the network device should drop
the packet and increment a drop counter.</t>
<t>DISCARD_WITH_ERROR: This indicates that the network device
should drop the packet, increment a drop counter and send back
an appropriate error message (like ICMP error).</t>
<t>RECEIVE: This indicates that that the traffic is destined
for the network device. For example, protocol packets or OAM
packets. All locally destined traffic SHOULD be throttled to
avoid a denial of service attack on the router's control
plane. An optional rate-limiter can be specified to indicate
how to throttle traffic destined for the control plane. The
description of the rate-limiter is outside the scope of this
document.</t>
</list></t>
</section>
</section>
<section anchor="derived-nexthop" title="Derived nexthops">
<t>Derived nexthops can be: <list style="symbols">
<t>Weighted lists - for load-balancing</t>
<t>Preference lists - for protection using primary and
backup</t>
<t>Replication lists - list of nexthops to which to replicate a
packet</t>
<t>Nexthop chains - for chaining multiple operations or
attaching multiple headers</t>
<t>Lists of lists - recursive application of the above</t>
</list></t>
<t>Nexthop chains (See <xref target="nexthop-chains"/> for usage)
are a way to perform multiple operations on a packet by logically
combining them. For example, one can chain together "decapsulate
MPLS header" and "send it out a specific EGRESS_INTERFACE". Chains
can be used to specify multiple headers over a packet before a
packet is forwarded. One simple example is that of MPLS over GRE,
wherein the packet has an inner MPLS header followed by a GRE header
followed by an IP header. The outermost IP header is decided by the
network device whereas the MPLS header or GRE header are specified
by the controller. Not every network device will be able to support
all kinds of nexthop chains and an arbitrary number of headers
chained together. The RIB data-model SHOULD provide a way to expose
nexthop chaining capability supported by a given network device.</t>
<t>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 to support all kinds of nexthops. RIB capability negotiation
becomes very important for this reason and a RIB data-model MUST
specify a way for a RIB client to learn about the network device's
capabilities.</t>
<section title="Nexthop list attributes">
<t>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 individual member of the list. Two attributes are
specified:<list style="symbols">
<t>NEXTHOP_PREFERENCE: This is used for protection schemes. It
is an integer value between 1 and 99. A lower value indicates
higher preference. To download a primary/standby pair to the
FIB, the nexthops that are resolved and have the two highest
preferences are selected. Each <NEXTHOP_PREFERENCE>
should have a unique value within a <nexthop-protection>
(<xref target="rib-grammar"/>).</t>
<t>NEXTHOP_LB_WEIGHT: This is used for load-balancing. Each
list member MUST be assigned a weight between 1 and 99. The
weight determines the proportion of traffic to be sent over a
nexthop used for forwarding as a ratio of the weight of this
nexthop divided by the weights of all the nexthops of this
route that are used for forwarding. To perform equal
load-balancing, one MAY specify a weight of "0" for all the
member nexthops. The value "0" is reserved for equal
load-balancing and if applied, MUST be applied to all member
nexthops. Note: A weight of 0 is special because of historical
reasons.</t>
</list></t>
</section>
</section>
<section anchor="nexthop-indirection" title="Nexthop indirection">
<t>Nexthops can be identified by an identifier to create a level of
indirection. The identifier is set by the RIB manager and returned
to the RIB client on request.</t>
<t>One example of usage of indirection is a nexthop that points to
another network device (Eg. BGP peer). The returned nexthop
identifier can then be used for programming routes to point to the
this nexthop. Given that the RIB manager has created an indirection
using the nexthop identifier, if the transport path to the network
device (BGP peer) changes, that change in path will be seamless to
the RIB client and all routes that point to that network device will
automatically start going over the new transport path. Nexthop
indirection using identifiers could be applied to not just unicast
nexthops, but even to nexthops that contain chains and nested
nexthops. See (<xref target="derived-nexthop"/>) for examples.</t>
</section>
</section>
</section>
<section anchor="rib-read" title="Reading from the RIB">
<t>A RIB data-model MUST allow a RIB client to read entries for RIBs
created by that entity. The network device administrator MAY allow
reading of other RIBs by a RIB client through access lists on the
network device. The details of access lists are outside the scope of
this document.</t>
<t>The data-model MUST support a full read of the RIB and subsequent
incremental reads of changes to the RIB. When sending data to a RIB
client, the RIB manager SHOULD try to send all dependencies of an object
prior to sending that object.</t>
</section>
<section anchor="rib-write" title="Writing to the RIB">
<t>A RIB data-model MUST allow a RIB client to write entries for RIBs
created by that entity. The network device administrator MAY allow
writes to other RIBs by a RIB client through access lists on the network
device. The details of access lists are outside the scope of this
document.</t>
<t>When writing an object to a RIB, the RIB client SHOULD try to write
all dependencies of the object prior to sending that object. The
data-model SHOULD support requesting identifiers for nexthops and
collecting the identifiers back in the response.</t>
<t>Route programming in the RIB MUST result in a return code that
contains the following attributes:<list style="symbols">
<t>Installed - Yes/No (Indicates whether the route got installed in
the FIB)</t>
<t>Active - Yes/No (Indicates whether a route is fully resolved and
is a candidate for selection)</t>
<t>Reason - e.g., Not authorized</t>
</list>The data-model MUST specify which objects can be modified. An
object that can be modified is one whose contents can be changed without
having to change objects that depend on it and without affecting any
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 use
a nexthop that is identified by a nexthop identifier should be
unaffected when the contents of that nexthop changes.</t>
</section>
<section anchor="events" title="Notifications">
<t>Asynchronous notifications are sent by the network device's RIB
manager to a RIB client when some event occurs on the network device. A
RIB data-model MUST support sending asynchronous notifications. A brief
list of suggested notifications is as below:<list style="symbols">
<t>Route change notification, with return code as specified in <xref
target="rib-write"/></t>
<t>Nexthop resolution status (resolved/unresolved) notification</t>
</list></t>
</section>
<section anchor="rib-grammar" title="RIB grammar">
<t>This section specifies the RIB information model in Routing
Backus-Naur Form <xref target="RFC5511"/>. This grammar is intended to
help the reader better understand <xref target="rib-data"/> in order to
derive a data model.</t>
<figure anchor="rib-grammar-details" title="RIB rBNF grammar">
<artwork><![CDATA[
<routing-instance> ::= <INSTANCE_NAME>
[<interface-list>] <rib-list>
[<ROUTER_ID>]
<interface-list> ::= (<INTERFACE_IDENTIFIER> ...)
<rib-list> ::= (<rib> ...)
<rib> ::= <RIB_NAME> <address-family>
[<route> ... ]
[ENABLE_IP_RPF_CHECK]
<address-family> ::= <IPV4_ADDRESS_FAMILY> | <IPV6_ADDRESS_FAMILY> |
<MPLS_ADDRESS_FAMILY> | <IEEE_MAC_ADDRESS_FAMILY>
<route> ::= <match> <nexthop>
[<route-attributes>]
[<route-vendor-attributes>]
<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>
<ipv4-route> ::= <ip-route-type>
(<destination-ipv4-address> | <source-ipv4-address> |
(<destination-ipv4-address> <source-ipv4-address>))
<destination-ipv4-address> ::= <ipv4-prefix>
<source-ipv4-address> ::= <ipv4-prefix>
<ipv4-prefix> ::= <IPV4_ADDRESS> <IPV4_PREFIX_LENGTH>
<ipv6-route> ::= <ip-route-type>
(<destination-ipv6-address> | <source-ipv6-address> |
(<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>
<route-attributes> ::= <ROUTE_PREFERENCE> [<LOCAL_ONLY>]
[<address-family-route-attributes>]
<address-family-route-attributes> ::= <ip-route-attributes> |
<mpls-route-attributes> |
<ethernet-route-attributes>
<ip-route-attributes> ::= <>
<mpls-route-attributes> ::= <>
<ethernet-route-attributes> ::= <>
<route-vendor-attributes> ::= <>
<nexthop> ::= <nexthop-base> |
(<NEXTHOP_LOAD_BALANCE> <nexthop-lb>) |
(<NEXTHOP_PROTECTION> <nexthop-protection>) |
(<NEXTHOP_REPLICATE> <nexthop-replicate>) |
<nexthop-chain>
<nexthop-base> ::= <NEXTHOP_ID> |
<nexthop-special> |
<EGRESS_INTERFACE> |
<ipv4-address> | <ipv6-address> |
(<EGRESS_INTERFACE>
(<ipv4-address> | <ipv6-address>)) |
(<EGRESS_INTERFACE> <IEEE_MAC_ADDRESS>) |
<tunnel-encap> | <tunnel-decap> |
<logical-tunnel> |
<RIB_NAME>)
<EGRESS_INTERFACE> ::= <INTERFACE_IDENTIFIER>
<nexthop-special> ::= <DISCARD> | <DISCARD_WITH_ERROR> |
(<RECEIVE> [<COS_VALUE>])
<nexthop-lb> ::= <NEXTHOP_LB_WEIGHT> <nexthop>
(<NEXTHOP_LB_WEIGHT> <nexthop) ...
<nexthop-protection> = <NEXTHOP_PREFERENCE> <nexthop>
(<NEXTHOP_PREFERENCE> <nexthop>)...
<nexthop-replicate> ::= <nexthop> <nexthop> ...
<nexthop-chain> ::= <nexthop> ...
<logical-tunnel> ::= <tunnel-type> <TUNNEL_NAME>
<tunnel-type> ::= <IPV4> | <IPV6> | <MPLS> | <GRE> | <VxLAN> | <NVGRE>
<tunnel-encap> ::= (<IPV4> <ipv4-header>) |
(<IPV6> <ipv6-header>) |
(<MPLS> <mpls-header>) |
(<GRE> <gre-header>) |
(<VXLAN> <vxlan-header>) |
(<NVGRE> <nvgre-header>)
<ipv4-header> ::= <SOURCE_IPv4_ADDRESS> <DESTINATION_IPv4_ADDRESS>
<PROTOCOL> [<TTL>] [<DSCP>]
<ipv6-header> ::= <SOURCE_IPV6_ADDRESS> <DESTINATION_IPV6_ADDRESS>
<NEXT_HEADER> [<TRAFFIC_CLASS>]
[<FLOW_LABEL>] [<HOP_LIMIT>]
<mpls-header> ::= (<mpls-label-operation> ...)
<mpls-label-operation> ::= (<MPLS_PUSH> <MPLS_LABEL> [<S_BIT>]
[<TOS_VALUE>] [<TTL_VALUE>]) |
(<MPLS_SWAP> <IN_LABEL> <OUT_LABEL>
[<TTL_ACTION>])
<gre-header> ::= <GRE_IP_DESTINATION> <GRE_PROTOCOL_TYPE> [<GRE_KEY>]
<vxlan-header> ::= (<ipv4-header> | <ipv6-header>)
[<VXLAN_IDENTIFIER>]
<nvgre-header> ::= (<ipv4-header> | <ipv6-header>)
<VIRTUAL_SUBNET_ID>
[<FLOW_ID>]
<tunnel-decap> ::= ((<IPV4> <IPV4_DECAP> [<TTL_ACTION>]) |
(<IPV6> <IPV6_DECAP> [<HOP_LIMIT_ACTION>]) |
(<MPLS> <MPLS_POP> [<TTL_ACTION>]))
]]></artwork>
</figure>
<section title="Nexthop grammar explained">
<t>A nexthop is used to specify the next network element to forward
the traffic to. It is also used to specify how the traffic should be
load-balanced, protected using preference, or multicast using
replication. This is explicitly specified in the grammar. The nexthop
has recursion built-in to address complex use cases like the one
defined in <xref target="lists-of-lists"/>.</t>
</section>
</section>
<section anchor="rib-examples" title="Using the RIB grammar">
<t>The RIB grammar is very generic and covers a variety of features.
This section provides examples on using objects in the RIB grammar and
examples to program certain use cases.</t>
<section anchor="route-preference" title="Using route preference">
<t>Using route preference a client can pre-install alternate paths in
the network. For example, if OSPF has a route preference of 10, then
another client can install a route with route preference of 20 to the
same destination. The OSPF route will get precedence and will get
installed in the FIB. When the OSPF route is withdrawn, the alternate
path will get installed in the FIB.</t>
<t>Route preference can also be used to prevent denial of service
attacks by installing routes with the best preference, which either
drops the offending traffic or routes it to some monitoring/analysis
station. Since the routes are installed with the best preference, they
will supersede any route installed by any other protocol.</t>
</section>
<section anchor="nexthop-examples"
title="Using different nexthops types">
<t>The RIB grammar allows one to create a variety of nexthops. This
section describes uses for certain types of nexthops.</t>
<section title="Tunnel nexthops">
<t>A tunnel nexthop points to a tunnel of some kind. Traffic that
goes over the tunnel gets encapsulated with the tunnel-encap. Tunnel
nexthops are useful for abstracting out details of the network, by
having the traffic seamlessly route between network edges. At the
end of a tunnel, the tunnel will get decapsulated. Thus the grammar
supports two kinds of operations, one for encapsulation and another
for decapsulation.</t>
</section>
<section anchor="replication-list" title="Replication lists">
<t>One can create a replication list for replicating traffic to
multiple destinations. The destinations, in turn, could be derived
nexthops in themselves - at a level supported by the network device.
Point to multipoint and broadcast are examples that involve
replication.</t>
<t>A replication list (at the simplest level) can be represented
as:</t>
<figure>
<artwork><![CDATA[
<nexthop> ::= <NEXTHOP_REPLICATE> <nexthop> [ <nexthop> ... ]
The above can be derived from the grammar as follows:
<nexthop> ::= <nexthop-replicate>
<nexthop> ::= <NEXTHOP_REPLICATE> <nexthop> <nexthop> ...
]]></artwork>
</figure>
</section>
<section title="Weighted lists">
<t>A weighted list is used to load-balance traffic among a set of
nexthops. From a modeling perspective, a weighted list is very
similar to a replication list, with the difference that each member
nexthop MUST have a NEXTHOP_LB_WEIGHT associated with it.</t>
<t>A weighted list (at the simplest level) can be represented
as:</t>
<figure>
<artwork><![CDATA[
<nexthop> ::= <NEXTHOP_LOAD_BALANCE> (<nexthop> <NEXTHOP_LB_WEIGHT>)
[(<nexthop> <NEXTHOP_LB_WEIGHT>)... ]
The above can be derived from the grammar as follows:
<nexthop> ::= <nexthop-lb>
<nexthop> ::= <NEXTHOP_LOAD_BALANCE>
<NEXTHOP_LB_WEIGHT> <nexthop>
(<NEXTHOP_LB_WEIGHT> <nexthop>) ...
<nexthop> ::= <NEXTHOP_LOAD_BALANCE> (<NEXTHOP_LB_WEIGHT> <nexthop>)
(<NEXTHOP_LB_WEIGHT> <nexthop>) ...
]]></artwork>
</figure>
</section>
<section title="Protection">
<t>A primary/backup protection can be represented as:</t>
<figure>
<artwork><![CDATA[
<nexthop> ::= <NEXTHOP_PROTECTION> <1> <interface-primary>
<2> <interface-backup>)
The above can be derived from the grammar as follows:
<nexthop> ::= <nexthop-protection>
<nexthop> ::= <NEXTHOP_PROTECTION> (<NEXTHOP_PREFERENCE> <nexthop>
(<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>))
]]></artwork>
</figure>
<t>Traffic can be load-balanced among multiple primary nexthops and
a single backup. In such a case, the nexthop will look like:</t>