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
|
<pre>Internet Engineering Task Force (IETF) C. Hopps
Request for Comments: 6213 L. Ginsberg
Category: Standards Track Cisco Systems
ISSN: 2070-1721 April 2011
<span class="h1">IS-IS BFD-Enabled TLV</span>
Abstract
This document describes a type-length-value (TLV) for use in the IS-
IS routing protocol that allows for the proper use of the
Bidirectional Forwarding Detection (BFD) protocol. There exist
certain scenarios in which IS-IS will not react appropriately to a
BFD-detected forwarding plane failure without use of either this TLV
or some other method.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6213">http://www.rfc-editor.org/info/rfc6213</a>.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Hopps & Ginsberg Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6213">RFC 6213</a> IS-IS BFD-Enabled TLV April 2011</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Requirements Language ......................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. The Problem .....................................................<a href="#page-2">2</a>
<a href="#section-3">3</a>. The Solution ....................................................<a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. State Definitions ..........................................<a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. Adjacency Establishment and Maintenance ....................<a href="#page-4">4</a>
<a href="#section-3.3">3.3</a>. Advertisement of Topology-Specific IS Neighbors ............<a href="#page-4">4</a>
<a href="#section-4">4</a>. Transition ......................................................<a href="#page-4">4</a>
<a href="#section-5">5</a>. Graceful Restart ................................................<a href="#page-5">5</a>
<a href="#section-6">6</a>. The BFD-Enabled TLV .............................................<a href="#page-5">5</a>
<a href="#section-7">7</a>. Security Considerations .........................................<a href="#page-6">6</a>
<a href="#section-8">8</a>. IANA Considerations .............................................<a href="#page-6">6</a>
<a href="#section-9">9</a>. Acknowledgements ................................................<a href="#page-6">6</a>
<a href="#section-10">10</a>. Normative References ...........................................<a href="#page-7">7</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Bidirectional Forwarding Detection (BFD) protocol [<a href="./rfc5880" title=""Bidirectional Forwarding Detection (BFD)"">RFC5880</a>] is a
protocol that allows for detection of a forwarding plane failure
between two routers. A router can use [<a href="./rfc5880" title=""Bidirectional Forwarding Detection (BFD)"">RFC5880</a>] to validate that a
peer router's forwarding ability is functioning.
One specific application of BFD as described in [<a href="./rfc5882" title=""Generic Application of Bidirectional Forwarding Detection (BFD)"">RFC5882</a>] is to
verify the forwarding ability of an IS-IS [<a href="./rfc1195" title=""Use of OSI IS-IS for routing in TCP/IP and dual environments"">RFC1195</a>] router's
adjacencies; however, the method described in [<a href="./rfc5882" title=""Generic Application of Bidirectional Forwarding Detection (BFD)"">RFC5882</a>] does not
allow for certain failure scenarios. We will define a TLV that will
allow for proper response to the detection of all forwarding failures
where the use of BFD is employed with IS-IS.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements Language</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. The Problem</span>
We observe that, in order to allow for mixed use (i.e., some routers
running BFD and some not), [<a href="./rfc5882" title=""Generic Application of Bidirectional Forwarding Detection (BFD)"">RFC5882</a>] does not require a BFD session
be established prior to the establishment of an IS-IS adjacency.
Thus, if a router A has neighbors B and C, and B does not support
BFD, A would still form adjacencies with B and C, and it would only
establish a BFD session with C.
<span class="grey">Hopps & Ginsberg Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6213">RFC 6213</a> IS-IS BFD-Enabled TLV April 2011</span>
The problem with this solution is that it assumes that the
transmission and receipt of IS-IS Hellos (IIHs) shares fate with
forwarded data packets. This is not a fair assumption to make given
that the primary use of BFD is to protect IPv4 (and IPv6) forwarding,
and IS-IS does not utilize IPv4 or IPv6 for sending or receiving its
hellos.
Thus, if we consider our previous example, and if C is currently
experiencing an IPv4 forwarding failure that allows for IIHs to be
sent and received, when A first starts (or restarts), A will assume
that C simply does not support BFD, will form an adjacency with C,
and may incorrectly forward IPv4 traffic through C.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. The Solution</span>
A simple solution to this problem is for an IS-IS router to advertise
that it has BFD enabled on a given interface. It can do this through
the inclusion of a TLV in its IIHs as described in this document.
When sending an IIH on a BFD enabled interface, a router that
supports this extension MUST include the BFD-enabled TLV in its IIH.
The contents of the TLV MUST indicate what topologies/protocols
[<a href="./rfc5120" title=""M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)"">RFC5120</a>] have been enabled for BFD by including the appropriate
Multi-Topology Identifier (MTID)/ Network Layer Protocol Identifier
(NLPID) pairs.
When sending an IIH on an interface on which BFD is NOT enabled, a
router MUST NOT include the BFD-enabled TLV.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. State Definitions</span>
The following definitions apply to each IS-IS neighbor:
For each locally supported MTID/NLPID pair, an
"ISIS_TOPO_NLPID_BFD_REQUIRED" variable is assigned. If BFD is
supported by both the local system and the neighbor of the MTID/
NLPID, this variable is set to "TRUE". Otherwise, the variable is
set to "FALSE".
For each locally supported MTID, an "ISIS_TOPO_BFD_REQUIRED" variable
is set to the logical "OR" of all "ISIS_TOPO_NLPID_BFD_REQUIRED"
variables associated with that MTID.
An "ISIS_BFD_REQUIRED" variable is set to the logical "AND" of all
"ISIS_TOPO_BFD_REQUIRED" variables.
<span class="grey">Hopps & Ginsberg Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6213">RFC 6213</a> IS-IS BFD-Enabled TLV April 2011</span>
For each locally supported MTID/NLPID pair, an
"ISIS_TOPO_NLPID_STATE" variable is assigned. If
"ISIS_TOPO_NLPID_BFD_REQUIRED" is "TRUE", this variable follows the
BFD session state for that MTID/NLPID ("UP == TRUE"). Otherwise, the
variable is set to "TRUE".
For each locally supported topology (MTID), an "ISIS_TOPO_USEABLE"
variable is set to the logical "AND" of the set of
"ISIS_TOPO_NLPID_STATE" variables associated with that MTID.
An "ISIS_NEIGHBOR_USEABLE" variable is set to the logical "OR" of all
"ISIS_TOPO_USEABLE" variables.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Adjacency Establishment and Maintenance</span>
Whenever "ISIS_BFD_REQUIRED" is "TRUE", the following extensions to
the rules for adjacency establishment and maintenance MUST apply:
o "ISIS_NEIGHBOR_USEABLE" MUST be "TRUE" before the adjacency can
transition from "INIT" to "UP" state.
o When the IS-IS adjacency is "UP" and "ISIS_NEIGHBOR_USEABLE"
becomes "FALSE", the IS-IS adjacency MUST transition to "DOWN".
o On a Point-to-Point circuit whenever "ISIS_NEIGHBOR_USEABLE" is
"FALSE", the Three-Way adjacency state MUST be set to "DOWN" in
the Point-to-Point Three-Way Adjacency TLV [<a href="./rfc5303" title=""Three-Way Handshake for IS-IS Point-to-Point Adjacencies"">RFC5303</a>] in all
transmitted IIHs.
o On a LAN circuit whenever "ISIS_NEIGHBOR_USEABLE" is "FALSE", the
IS Neighbors TLV advertising the Media Access Control (MAC)
address of the neighbor MUST be omitted in all transmitted IIHs.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Advertisement of Topology-Specific IS Neighbors</span>
The advertisement of a topology-specific IS neighbor (as well as the
use of the neighbor in the topology-specific decision process) is
determined by the value of "ISIS_TOPO_USEABLE" for each topology. If
"ISIS_TOPO_USEABLE" is "TRUE", then the topology-specific neighbor is
advertised. If "ISIS_TOPO_USEABLE" is "FALSE", then the topology-
specific neighbor is not advertised.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Transition</span>
To allow for a non-disruptive transition to the use of BFD, some
amount of time should be allowed before bringing down an "UP"
adjacency on a BFD enabled interface when the value of
"ISIS_BFD_REQUIRED" becomes "TRUE" as a result of the introduction of
<span class="grey">Hopps & Ginsberg Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6213">RFC 6213</a> IS-IS BFD-Enabled TLV April 2011</span>
the BFD TLV or the modification (by adding a new supported MTID/
NLPID) of an existing BFD TLV in a neighbor's IIH. A simple way to
do this is to not update the adjacency hold time when receiving such
an IIH from a neighbor with whom we have an "UP" adjacency until
"ISIS_NEIGHBOR_USEABLE" becomes "TRUE".
If the value of "ISIS_BFD_REQUIRED" becomes "FALSE" as a result of
the removal the BFD TLV or the modification (by removing a supported
MTID/NLPID) of an existing BFD TLV in a neighbor's IIH, then BFD
session establishment is no longer required to maintain the adjacency
or transition the adjacency to the "UP" state.
If a BFD session is administratively shut down [<a href="./rfc5880" title=""Bidirectional Forwarding Detection (BFD)"">RFC5880</a>] and the BFD
session state change impacts the value of "ISIS_NEIGHBOR_USEABLE",
then IS-IS SHOULD allow time for the corresponding MTID/NLPID to be
removed from the neighbor's BFD TLV by not updating the adjacency
hold time until "ISIS_BFD_REQUIRED" becomes "FALSE". Note that while
this allows a non-disruptive transition, it still enforces
consistency between the administrative state of the BFD session and
the MTID/NLPID(s) advertised in the BFD TLV. This is necessary to
provide consistent behavior regardless of whether the BFD AdminDown
state is introduced before or after an IS-IS adjacency "UP" state has
been achieved.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Graceful Restart</span>
This section describes IS-IS implementation considerations when both
IS-IS graceful restart [<a href="./rfc5306" title=""Restart Signaling for IS-IS"">RFC5306</a>] and BFD are co-deployed.
In cases where BFD shares fate with the control plane, it can be
expected that BFD session failure may occur in conjunction with the
control-plane restart. In such cases, premature abort of IS-IS
graceful restart as a result of BFD session failure is undesirable.
Therefore, some mechanism to ignore the BFD session failure for a
limited period of time would be beneficial. The issue of the
interaction between graceful restart and BFD is described at length
in <a href="./rfc5882">RFC 5882</a>. The implementation of this interaction is outside the
scope of this document.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. The BFD-Enabled TLV</span>
The BFD-enabled TLV is formatted as shown below. The TLV SHALL only
be included in an IIH and only when BFD is enabled for one or more
supported MTID/protocols on the interface over which the IIH is being
sent. The NLPIDs encoded in the TLV are defined in [<a href="#ref-ISO9577" title=""Protocol identification in the network layer(ISO/IEC 9577)"">ISO9577</a>].
<span class="grey">Hopps & Ginsberg Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6213">RFC 6213</a> IS-IS BFD-Enabled TLV April 2011</span>
Type 148
Length # of octets in the value field (3 to 255)
Value 3 octets specifying the MTID/NLPID for each
topology/data protocol for which BFD support is enabled
No. of octets
+-----------------------+
|R|R|R|R| MTID | 2
+-----------------------+
| NLPID | 1
+-----------------------+
: :
: :
+-----------------------+
|R|R|R|R| MTID | 2
+-----------------------+
| NLPID | 1
+-----------------------+
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
The TLV defined within this document describes an addition to the
IS-IS Hello protocol. Inappropriate use of this TLV could prevent an
IS-IS adjacency from forming or lead to failure to detect
bidirectional forwarding failures -- each of which is a form of
denial of service. However, a party who can manipulate the contents
of this TLV is already in a position to create such a denial of
service by disrupting IS-IS routing in other ways.
Note that the introduction of this TLV has no impact on the use/
non-use of authentication either by IS-IS or by BFD.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
The following IS-IS TLV type is defined by this document.
Name Value IIH LSP SNP Purge
---------------------- ----- --- --- --- -----
BFD-Enabled TLV 148 y n n n
The IS-IS TLV Codepoint registry has been updated accordingly.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgements</span>
The authors wish to thank Jeffrey Haas, Matthew Jones, Dave Katz,
Jonathan Moon, Stefano Previdi, Mike Shand, Michael Shiplett, and
David Ward for various input on this document.
<span class="grey">Hopps & Ginsberg Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6213">RFC 6213</a> IS-IS BFD-Enabled TLV April 2011</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Normative References</span>
[<a id="ref-ISO9577">ISO9577</a>] International Organization for Standardization, "Protocol
identification in the network layer(ISO/IEC 9577)", ISO/
IEC 9577:1999, Fourth Edition, December 1999.
[<a id="ref-RFC1195">RFC1195</a>] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", <a href="./rfc1195">RFC 1195</a>, December 1990.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC5120">RFC5120</a>] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", <a href="./rfc5120">RFC 5120</a>, February 2008.
[<a id="ref-RFC5303">RFC5303</a>] Katz, D., Saluja, R., and D. Eastlake, "Three-Way
Handshake for IS-IS Point-to-Point Adjacencies", <a href="./rfc5303">RFC 5303</a>,
October 2008.
[<a id="ref-RFC5306">RFC5306</a>] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS",
<a href="./rfc5306">RFC 5306</a>, October 2008.
[<a id="ref-RFC5880">RFC5880</a>] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", <a href="./rfc5880">RFC 5880</a>, June 2010.
[<a id="ref-RFC5882">RFC5882</a>] Katz, D. and D. Ward, "Generic Application of
Bidirectional Forwarding Detection (BFD)", <a href="./rfc5882">RFC 5882</a>,
June 2010.
Authors' Addresses
Christian E. Hopps
Cisco Systems
170 W. Tasman Dr.
San Jose, California 95134
USA
EMail: chopps@cisco.com
Les Ginsberg
Cisco Systems
510 McCarthy Blvd.
Milpitas, California 95035
USA
EMail: ginsberg@cisco.com
Hopps & Ginsberg Standards Track [Page 7]
</pre>
|
