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
|
<pre>Internet Engineering Task Force (IETF) S. Sivabalan
Request for Comments: 8408 Cisco Systems, Inc.
Category: Standards Track J. Tantsura
ISSN: 2070-1721 Nuage Networks
I. Minei
Google, Inc.
R. Varga
Pantheon Technologies SRO
J. Hardwick
Metaswitch Networks
July 2018
<span class="h1">Conveying Path Setup Type</span>
<span class="h1">in PCE Communication Protocol (PCEP) Messages</span>
Abstract
A Path Computation Element (PCE) can compute Traffic Engineering (TE)
paths through a network; these paths are subject to various
constraints. Currently, TE paths are Label Switched Paths (LSPs)
that are set up using the RSVP-TE signaling protocol. However, other
TE path setup methods are possible within the PCE architecture. This
document proposes an extension to the PCE Communication Protocol
(PCEP) to allow support for different path setup methods over a given
PCEP session.
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="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8408">https://www.rfc-editor.org/info/rfc8408</a>.
<span class="grey">Sivabalan, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8408">RFC 8408</a> PCE Path Setup Type July 2018</span>
Copyright Notice
Copyright (c) 2018 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="https://trustee.ietf.org/license-info">https://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.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Requirements Language . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Path Setup Type Capability TLV . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6">6</a>. Manageability Considerations . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-7">7</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-8">8</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-8.1">8.1</a>. Additions to PCEP TLV Type Indicators Registry . . . . . <a href="#page-9">9</a>
<a href="#section-8.2">8.2</a>. New PCEP Path Setup Types Registry . . . . . . . . . . . <a href="#page-9">9</a>
8.3. Additions to PCEP-ERROR Object Error Types and Values
Registry . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-9">9</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-9.1">9.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-9.2">9.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<span class="grey">Sivabalan, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8408">RFC 8408</a> PCE Path Setup Type July 2018</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
[<a id="ref-RFC5440">RFC5440</a>] describes the PCE Communication Protocol (PCEP) for
communication between a Path Computation Client (PCC) and a Path
Computation Element (PCE) or between a PCE and a PCE. A PCC
requests, from a PCE, a path subject to various constraints and
optimization criteria. The PCE responds to the PCC with a hop-by-hop
path in an Explicit Route Object (ERO). The PCC uses the ERO to set
up the path in the network.
[<a id="ref-RFC8231">RFC8231</a>] specifies extensions to PCEP that allow a PCC to delegate
its LSPs to a PCE. The PCE can then update the state of LSPs
delegated to it. In particular, the PCE may modify the path of an
LSP by sending a new ERO. The PCC uses this ERO to reroute the LSP
in a make-before-break fashion. [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>] specifies a mechanism that
allows a PCE to dynamically instantiate an LSP on a PCC by sending
the ERO and the characteristics of the LSP. The PCC creates the LSP
using the ERO and other attributes sent by the PCE.
So far, PCEP and its extensions have assumed that the TE paths are
label switched and are established via the RSVP-TE signaling
protocol. However, other methods of LSP setup are possible in the
PCE architecture (see [<a href="./rfc4655" title=""A Path Computation Element (PCE)-Based Architecture"">RFC4655</a>] and [<a href="./rfc4657" title=""Path Computation Element (PCE) Communication Protocol Generic Requirements"">RFC4657</a>]). This document
generalizes PCEP to allow other LSP setup methods to be used. It
defines two new TLVs and specifies the base procedures to facilitate
this:
o The PATH-SETUP-TYPE-CAPABILITY TLV allows a PCEP speaker to
announce which LSP setup methods it supports when the PCEP session
is established.
o The PATH-SETUP-TYPE TLV allows a PCEP speaker to specify which
setup method should be used for a given LSP. When multiple path
setup types are deployed in a network, a given PCEP session may
have to simultaneously support more than one path setup type. A
PCEP speaker uses the PATH-SETUP-TYPE TLV to explicitly indicate
the intended path setup type in the appropriate PCEP messages,
unless the path setup type is RSVP-TE (which is assumed to be the
path setup type if no other setup type is indicated). This is so
that both the PCC and the PCE can take the necessary steps to set
up the path.
This document defines a path setup type code for RSVP-TE. When a new
path setup type (other than RSVP-TE) is introduced for setting up a
path, a path setup type code and, optionally, a sub-TLV pertaining to
the new path setup type will be defined by the document that
specifies the new path setup type.
<span class="grey">Sivabalan, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8408">RFC 8408</a> PCE Path Setup Type July 2018</span>
<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", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The following terminology is used in this document:
ERO: Explicit Route Object
PCC: Path Computation Client
PCE: Path Computation Element
PCEP: PCE Communication Protocol
PST: Path Setup Type
TLV: Type, Length, and Value
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Path Setup Type Capability TLV</span>
A PCEP speaker indicates which PSTs it supports during the PCEP
initialization phase using the following process. When the PCEP
session is created, it sends an Open message with an OPEN object
containing the PATH-SETUP-TYPE-CAPABILITY TLV. The format of this
TLV is as follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (34) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Num of PSTs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PST#1 | ... | PST#N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional sub-TLVs (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PATH-SETUP-TYPE-CAPABILITY TLV
<span class="grey">Sivabalan, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8408">RFC 8408</a> PCE Path Setup Type July 2018</span>
The TLV Type is 34. Its Reserved field MUST be set to zero by the
sender and MUST be ignored by the receiver. The other fields in the
TLV are as follows.
Length: The total length in bytes of the remainder of the TLV, that
is, excluding the Type and Length fields.
Num of PSTs: The number of PSTs in the following list, excluding
padding.
List of PSTs: A list of the PSTs that the PCEP speaker supports.
Each PST is a single byte in length. Duplicate entries in this
list MUST be ignored. The PCEP speaker MUST pad the list with
zeros so that it is a multiple of four bytes in length. This
document defines the following PST value:
* PST = 0: Path is set up using the RSVP-TE signaling protocol
Optional sub-TLVs: A list of sub-TLVs associated with the supported
PSTs. Each PST has zero or one sub-TLVs associated with it, and
each sub-TLV is associated with exactly one PST. Each sub-TLV
MUST obey the rules for TLV formatting defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]. That
is, each sub-TLV is padded to a four-byte alignment, and the
Length field of each sub-TLV does not include the padding bytes.
This document does not define any sub-TLVs; an example sub-TLV can
be found in [<a href="#ref-PCEP-EXTENSIONS">PCEP-EXTENSIONS</a>].
A PCEP speaker MUST check that this TLV is correctly formatted, as
follows.
o If there are no sub-TLVs, then the TLV Length field MUST be equal
to four bytes plus the size of the PST list, excluding any padding
bytes.
o If there are sub-TLVs, then the TLV Length field MUST be equal to
four bytes plus the size of the PST list (rounded up to the
nearest multiple of four) plus the size of the appended sub-TLVs,
excluding any padding bytes in the final sub-TLV.
o The Num of PSTs field MUST be greater than zero.
If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV that
violates these rules, then the PCEP speaker MUST send a PCErr message
with Error-Type = 10 (Reception of an invalid object) and Error-value
= 11 (Malformed object) and MUST close the PCEP session. The PCEP
speaker MAY include the malformed OPEN object in the PCErr message as
well.
<span class="grey">Sivabalan, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8408">RFC 8408</a> PCE Path Setup Type July 2018</span>
If a PCEP speaker receives an OPEN object with more than one PATH-
SETUP-TYPE-CAPABILITY TLV, then it MUST ignore all but the first
instance of this TLV.
The absence of the PATH-SETUP-TYPE-CAPABILITY TLV from the OPEN
object is equivalent to a PATH-SETUP-TYPE-CAPABILITY TLV containing a
single PST value of 0 (Path is set up using the RSVP-TE signaling
protocol) and no sub-TLVs. A PCEP speaker MAY omit the PATH-SETUP-
TYPE-CAPABILITY TLV if the only PST it supports is RSVP-TE. If a
PCEP speaker supports other PSTs besides RSVP-TE, then it SHOULD
include the PATH-SETUP-TYPE-CAPABILITY TLV in its OPEN object.
If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY
TLV, it will ignore the TLV in accordance with [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Path Setup Type TLV</span>
When a PCEP session is used to set up TE paths using different
methods, the corresponding PCE and PCC must be aware of the path
setup method used. This means that a PCE must be able to specify
paths in the correct format, and a PCC must be able to take control-
plane and forwarding-plane actions appropriate to the PST.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (28) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PST |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PATH-SETUP-TYPE TLV
The PATH-SETUP-TYPE TLV is an optional TLV associated with the
Request Parameters (RP) [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] and the Stateful PCE Request
Parameters (SRP) [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] objects. Its format is shown in Figure 2.
The TLV type is 28. Its Reserved field MUST be set to zero. The
one-byte PST field contains the PST as defined for the PATH-SETUP-
TYPE-CAPABILITY TLV.
The absence of the PATH-SETUP-TYPE TLV is equivalent to a PATH-SETUP-
TYPE TLV with a PST value of 0 (Path is set up using the RSVP-TE
signaling protocol). A PCEP speaker MAY omit the TLV if the PST is
RSVP-TE. If the RP or SRP object contains more than one PATH-SETUP-
TYPE TLV, only the first TLV MUST be processed, and the rest MUST be
ignored.
<span class="grey">Sivabalan, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8408">RFC 8408</a> PCE Path Setup Type July 2018</span>
If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it will
ignore the TLV in accordance with [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] and use RSVP-TE to set up
the path.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Operation</span>
During the PCEP initialization phase, if a PCEP speaker receives a
PATH-SETUP-TYPE-CAPABILITY TLV from its peer, it MUST assume that the
peer supports only the PSTs listed in the TLV. If the PCEP speaker
and its peer have no PSTs in common, then the PCEP speaker MUST send
a PCErr message with Error-Type = 21 (Invalid traffic engineering
path setup type) and Error-value = 2 (Mismatched path setup type) and
close the PCEP session.
If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP
speaker MUST infer that the peer supports path setup using at least
RSVP-TE. The PCEP speaker MAY also infer that the peer supports
other path setup types, but the means of inference are outside the
scope of this document.
When a PCC sends a PCReq message to a PCE [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>], it MUST include
the PATH-SETUP-TYPE TLV in the RP object, unless the intended PST is
RSVP-TE (in which case it MAY omit the PATH-SETUP-TYPE TLV). If the
PCE is capable of expressing the path in a format appropriate to the
intended PST, it MUST use the appropriate ERO format in the PCRep
message.
When a PCE sends a PCRep message to a PCC [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>], it MUST include
the PATH-SETUP-TYPE TLV in the RP object, unless the PST is RSVP-TE
(in which case it MAY omit the PATH-SETUP-TYPE TLV). If the PCE does
not support the intended PST, it MUST send a PCErr message with
Error-Type = 21 (Invalid traffic engineering path setup type) and
Error-value = 1 (Unsupported path setup type) and close the PCEP
session. If the PSTs corresponding to the PCReq and PCRep messages
do not match, the PCC MUST send a PCErr message with Error-Type = 21
(Invalid traffic engineering path setup type) and Error-value = 2
(Mismatched path setup type) and close the PCEP session.
When a stateful PCE sends a PCUpd message [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] or a PCInitiate
message [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>] to a PCC, it MUST include the PATH-SETUP-TYPE TLV
in the SRP object, unless the intended PST is RSVP-TE (in which case
it MAY omit the PATH-SETUP-TYPE TLV). If the PCC does not support
the PST associated with the PCUpd or PCInitiate message, it MUST send
a PCErr message with Error-Type = 21 (Invalid traffic engineering
path setup type) and Error-value = 1 (Unsupported path setup type)
and close the PCEP session.
<span class="grey">Sivabalan, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8408">RFC 8408</a> PCE Path Setup Type July 2018</span>
When a PCC sends a PCRpt message to a stateful PCE [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>], it MUST
include the PATH-SETUP-TYPE TLV in the SRP object, unless the PST is
RSVP-TE (in which case it MAY omit the PATH-SETUP-TYPE TLV). The PCC
MUST include the SRP object in the PCRpt message if the PST is not
RSVP-TE, even when the SRP-ID-number is the reserved value of
0x00000000. If the PCRpt message is triggered by a PCUpd or
PCInitiate message, then the PST that the PCC indicates in the PCRpt
message MUST match the PST that the stateful PCE intended in the
PCUpd or PCInitiate message. If it does not match, then the PCE MUST
send a PCErr message with Error-Type = 21 (Invalid traffic
engineering path setup type) and Error-value = 2 (Mismatched path
setup type) and close the PCEP session.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Manageability Considerations</span>
This document generalizes PCEP to allow path setup methods other than
RSVP-TE to be used by the network (but does not define any new path
setup types besides RSVP-TE). It is possible that, in a given
network, multiple path setup methods will be used. It is also
possible that not all devices will support the same set of path setup
methods. Managing networks that combine multiple path setup methods
may therefore raise some challenges from a configuration and
observability point of view.
Each document that defines a new path setup type in the "PCEP Path
Setup Types" registry (<a href="#section-8.2">Section 8.2</a>) must include a Manageability
Considerations section. The Manageability Considerations section
must explain how operators can manage PCEP with the new path setup
type. It must address the following questions, which are generally
applicable when working with multiple path setup types in PCEP.
o What are the criteria for when devices will use the new path setup
type in PCEP, and how can the operator control this?
o How can the network be migrated to the new path setup type, and
are there any backwards-compatibility issues that operators need
to be aware of?
o Are paths set up using the new path setup type intended to coexist
with other paths over the long term, and if so, how is this
situation managed with PCEP?
o How can operators verify the correct operation of PCEP in the
network with respect to the new path setup type? Which fault
conditions must be reported to the operators?
<span class="grey">Sivabalan, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8408">RFC 8408</a> PCE Path Setup Type July 2018</span>
o Are there any existing management interfaces (such as YANG models)
that must be extended to model the operation of PCEP in the
network with respect to the new path setup type?
See [<a href="./rfc5706" title=""Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions"">RFC5706</a>] for further guidance on how to write Manageability
Considerations sections in Standards Track documents.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
The security considerations described in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] and [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>] are
applicable to this specification. No additional security measure is
required.
Note that if the security mechanisms of [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] and [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>] are
not used, then the protocol described in this document could be
attacked in the following new way. An attacker, using a TCP man-in-
the-middle attack, could inject error messages into the PCEP session
when a particular PST is (or is not) used. Doing this could
potentially force the use of a specific PST, which may allow the
attacker to subsequently attack a weakness in that PST.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Additions to PCEP TLV Type Indicators Registry</span>
IANA has allocated the following code points in the "PCEP TLV Type
Indicators" registry.
Value Description Reference
----- -------------------------- ---------
28 PATH-SETUP-TYPE <a href="./rfc8408">RFC 8408</a>
34 PATH-SETUP-TYPE-CAPABILITY <a href="./rfc8408">RFC 8408</a>
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. New PCEP Path Setup Types Registry</span>
IANA has created a new sub-registry within the "Path Computation
Element Protocol (PCEP) Numbers" registry called "PCEP Path Setup
Types". The allocation policy for this new registry is IETF Review
[<a href="./rfc8126" title="">RFC8126</a>]. This new registry contains the following value:
Value Description Reference
----- -------------------------- ---------
0 Path is set up using the <a href="./rfc8408">RFC 8408</a>
RSVP-TE signaling protocol
<span class="grey">Sivabalan, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8408">RFC 8408</a> PCE Path Setup Type July 2018</span>
<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>. Additions to PCEP-ERROR Object Error Types and Values Registry</span>
IANA has allocated the following code points in the "PCEP-ERROR
Object Error Types and Values" registry.
Error-Type Meaning Reference
---------- ------------------------------------------- ---------
10 Reception of an invalid object <a href="./rfc5440">RFC 5440</a>
Error-value = 11: Malformed object <a href="./rfc8408">RFC 8408</a>
21 Invalid traffic engineering path setup type <a href="./rfc8408">RFC 8408</a>
Error-value = 0: Unassigned <a href="./rfc8408">RFC 8408</a>
Error-value = 1: Unsupported path setup type <a href="./rfc8408">RFC 8408</a>
Error-value = 2: Mismatched path setup type <a href="./rfc8408">RFC 8408</a>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<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>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC5440">RFC5440</a>] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", <a href="./rfc5440">RFC 5440</a>,
DOI 10.17487/RFC5440, March 2009,
<<a href="https://www.rfc-editor.org/info/rfc5440">https://www.rfc-editor.org/info/rfc5440</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
[<a id="ref-RFC8231">RFC8231</a>] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", <a href="./rfc8231">RFC 8231</a>,
DOI 10.17487/RFC8231, September 2017,
<<a href="https://www.rfc-editor.org/info/rfc8231">https://www.rfc-editor.org/info/rfc8231</a>>.
[<a id="ref-RFC8281">RFC8281</a>] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", <a href="./rfc8281">RFC 8281</a>, DOI 10.17487/RFC8281, December 2017,
<<a href="https://www.rfc-editor.org/info/rfc8281">https://www.rfc-editor.org/info/rfc8281</a>>.
<span class="grey">Sivabalan, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8408">RFC 8408</a> PCE Path Setup Type July 2018</span>
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-PCEP-EXTENSIONS">PCEP-EXTENSIONS</a>]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing",
Work in Progress, <a href="./draft-ietf-pce-segment-routing-12">draft-ietf-pce-segment-routing-12</a>, June
2018.
[<a id="ref-RFC4655">RFC4655</a>] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", <a href="./rfc4655">RFC 4655</a>,
DOI 10.17487/RFC4655, August 2006,
<<a href="https://www.rfc-editor.org/info/rfc4655">https://www.rfc-editor.org/info/rfc4655</a>>.
[<a id="ref-RFC4657">RFC4657</a>] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", <a href="./rfc4657">RFC 4657</a>, DOI 10.17487/RFC4657, September
2006, <<a href="https://www.rfc-editor.org/info/rfc4657">https://www.rfc-editor.org/info/rfc4657</a>>.
[<a id="ref-RFC5706">RFC5706</a>] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions",
<a href="./rfc5706">RFC 5706</a>, DOI 10.17487/RFC5706, November 2009,
<<a href="https://www.rfc-editor.org/info/rfc5706">https://www.rfc-editor.org/info/rfc5706</a>>.
[<a id="ref-RFC8126">RFC8126</a>] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>,
<a href="./rfc8126">RFC 8126</a>, DOI 10.17487/RFC8126, June 2017,
<<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>>.
Acknowledgements
We would like to thank Marek Zavodsky for valuable comments.
Contributors
The following people contributed to this document:
- Jan Medved
- Edward Crabbe
<span class="grey">Sivabalan, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8408">RFC 8408</a> PCE Path Setup Type July 2018</span>
Authors' Addresses
Siva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario K2K 3E8
Canada
Email: msiva@cisco.com
Jeff Tantsura
Nuage Networks
755 Ravendale Drive
Mountain View, CA 94043
United States of America
Email: jefftant.ietf@gmail.com
Ina Minei
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: inaminei@google.com
Robert Varga
Pantheon Technologies SRO
Mlynske Nivy 56
Bratislava, 821 05
Slovakia
Email: nite@hq.sk
Jon Hardwick
Metaswitch Networks
100 Church Street
Enfield, Middlesex
United Kingdom
Email: jonathan.hardwick@metaswitch.com
Sivabalan, et al. Standards Track [Page 12]
</pre>
|
