-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-dhody-pce-stateful-pce-optional-00.txt
504 lines (355 loc) · 21.3 KB
/
draft-dhody-pce-stateful-pce-optional-00.txt
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
PCE Working Group D. Dhody, Ed.
Internet-Draft Huawei Technologies
Updates: 8231 (if approved) S. Litkowski
Intended status: Standards Track Orange
Expires: September 2, 2018 March 1, 2018
Extension for Stateful PCE to allow Optional Processing of PCEP Objects.
draft-dhody-pce-stateful-pce-optional-00
Abstract
This document introduces a mechanism to mark some Path Computation
Element (PCE) Communication Protocol (PCEP) objects as optional
during PCEP messages exchange for the Stateful PCE model to allow
relaxing some constraints.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 2, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) 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.
Dhody & Litkowski Expires September 2, 2018 [Page 1]
Internet-Draft STATEFUL-OPT March 2018
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Usage Example . . . . . . . . . . . . . . . . . . . . . . 3
3. PCEP Extension . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 4
3.2. Handling of P flag . . . . . . . . . . . . . . . . . . . 4
3.2.1. The PCRpt message . . . . . . . . . . . . . . . . . . 4
3.2.2. The PCUpd message and the PCInitiate message . . . . 5
3.3. Handling of I flag . . . . . . . . . . . . . . . . . . . 5
3.3.1. The PCUpd message . . . . . . . . . . . . . . . . . . 5
3.3.2. The PCRpt message . . . . . . . . . . . . . . . . . . 5
3.3.3. The PCInitiate message . . . . . . . . . . . . . . . 6
3.4. Unknown Object Handling . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 6
6. Manageability Considerations . . . . . . . . . . . . . . . . 7
6.1. Control of Function and Policy . . . . . . . . . . . . . 7
6.2. Information and Data Models . . . . . . . . . . . . . . . 7
6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 7
6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 7
6.5. Requirements On Other Protocols . . . . . . . . . . . . . 7
6.6. Impact On Network Operations . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
[RFC5440] describes the Path Computation Element communication
Protocol (PCEP) which enables the communication between a Path
Computation Client (PCC) and a Path Control Element (PCE), or between
two PCEs based on the PCE architecture [RFC4655].
PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of
extensions to PCEP to enable active control of Multiprotocol Label
Switching Traffic Engineering (MPLS-TE) and Generalzied MPLS (GMPLS)
tunnels. [RFC8281] describes the setup and teardown of PCE-initiated
LSPs under the active stateful PCE model, without the need for local
configuration on the PCC, thus allowing for a dynamic network.
[RFC5440] defined P flag (Processing-Rule) as part of Common Object
Header to allow a PCC to specify in a PCReq message sent to a PCE
whether the object must be taken into account by the PCE during path
Dhody & Litkowski Expires September 2, 2018 [Page 2]
Internet-Draft STATEFUL-OPT March 2018
computation or is just optional. The I flag (Ignore) is used by a
PCE in a PCRep message to indicate to a PCC whether or not an
optional object was processed. Stateful PCE [RFC8231] specified that
P and I flags of the PCEP objects defined in [RFC8231] is to be set
to 0 on transmission and ignored on receipt since they are
exclusively related to path computation requests. The behavior for P
and I flag in other objects defined in [RFC5440] and other extension
was not specified. This document clarifies how the P and I flag
could be used in the stateful PCE model to identify optional objects
in the Path Computation State Report (PCRpt), the Path Computation
Update Request (PCUpd) and the LSP Initiate Request (PCInitiate)
message.
This document updates [RFC8231] with respect to usage of P and I flag
as well as handling of unknown objects in stateful PCEP message
exchanges.
1.1. Requirements Language
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Overview
[RFC5440] describes the handling on unknown objects as per the
setting of the P flag for the PCReq message. Further [RFC8231]
defined the usage of LSP Error Code TLV in PCRpt message in response
to failed LSP Update Request via PCUpd message (for example, due to
an unsupported object or a TLV).
This document clarifies the procedure for marking some objects as
optional to be processed by the PCEP peer in the stateful PCEP
messages. Further this document updates the procedure for handling
unknown objects in the stateful PCEP messages based on the P flag.
2.1. Usage Example
The PCRpt message is used to report the current state of an LSP. As
part of the message both the <intended-attribute-list> and <actual-
attribute-list> is encoded. The <intended-attribute-list> could
include the METRIC object to indicate a limiting constraint (B flag
set) for the Path Delay Variation metric [RFC8233]. In some
scenarios it would be useful to state that this limiting constraint
can be relaxed by the PCE, in case it cannot find a path. Similarly
in case of an association groups [I-D.ietf-pce-association-group]
Dhody & Litkowski Expires September 2, 2018 [Page 3]
Internet-Draft STATEFUL-OPT March 2018
such as Disjoint Association [I-D.ietf-pce-association-diversity],
the PCE may need to completely relax the disjointness constraint in
order to provide a path to all the LSPs that are part of the
association. In these case it would be useful mark the objects as
optional and could be ignored by the PCEP peer. Also it would be
used for the PCEP speaker to learn if the PCEP peer has relaxed the
constraint and ignored the processing of the PCEP object.
Thus, this document simply clarifies how the already existing P and I
flag in PCEP common object header could be used during stateful PCEP
exchanges.
3. PCEP Extension
3.1. STATEFUL-PCE-CAPABILITY TLV
A PCEP speaker indicates its ability to support for handling P and I
flag during the stateful PCEP message exchanges during the PCEP
initialization phase, as follows. When the PCEP session is created,
it sends an Open message with an OPEN object that contains the
STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A new flag,
the R (RELAX) flag, is introduced to this TLV to indicate support for
relaxing the processing of some objects via the use of P and I flag
in PCEP common object header.
R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag
indicates that the PCEP Speaker is willing to send and receive PCEP
objects with handling of P and I flags in the PCEP common object
header. In case the bit is unset, it indicates that the PCEP Speaker
would not handle P and I flags in the PCEP common object header.
The R flag must be set by both a PCC and a PCE for handling of P and
I flag in the PCEP common object header to allow relaxing some
constraints by marking objects as optional to process. If the PCEP
speaker that did not set R flag but receives PCEP objects with P or I
bit set, would behave as per the processing rule in [RFC8231].
3.2. Handling of P flag
3.2.1. The PCRpt message
The P flag in the PCRpt message [RFC8231] allows a PCC to specify to
a PCE whether the object must be taken into account by the PCE
(during path computation or re-optimization) or is just optional.
When the P flag is set, the object MUST be taken into account by the
PCE. Conversely, when the P flag is cleared, the object is optional
and the PCE is free to ignore it. The P flag for the mandatory
objects LSP and ERO (intended path) MUST be set in the PCRpt message.
Dhody & Litkowski Expires September 2, 2018 [Page 4]
Internet-Draft STATEFUL-OPT March 2018
If the mandatory object is received with the P flag set incorrectly
according to the rules stated above, the receiving peer MUST send a
PCErr message with Error-Type=10 (Reception of an invalid object) and
Error-value=1 (reception of an object with P flag not set). By
default, the PCC SHOULD set the P flag, unless a local configuration
or local policy indicates that some constraints (corresponding PCEP
objects) can be marked as optional and could be ignored by the PCE.
3.2.2. The PCUpd message and the PCInitiate message
The P flag in the PCUpd message [RFC8231] and the PCInitiate message
[RFC8281] allows a PCE to specify to a PCC whether the object must be
taken into account by the PCC (during path setup) or is just
optional. When the P flag is set, the object MUST be taken into
account by the PCC. Conversely, when the P flag is cleared, the
object is optional and the PCC is free to ignore it. The P flag for
the mandatory objects SRP, LSP and ERO (intended path) MUST be set in
the PCUpd message. If the mandatory object is received with the P
flag set incorrectly according to the rules stated above, the
receiving peer MUST send a PCErr message with Error-Type=10
(Reception of an invalid object) and Error-value=1 (reception of an
object with P flag not set). By default, the PCE SHOULD set the P
flag, unless a local configuration or local policy indicates that
some constraints (corresponding PCEP objects) can be marked as
optional and could be ignored by the PCC.
3.3. Handling of I flag
3.3.1. The PCUpd message
The I flag in the PCUpd message [RFC8231] allows a PCE to indicate to
a PCC whether or not an optional object was processed. The PCE MAY
include the ignored optional object in its update request and set the
I flag to indicate that the optional object was ignored. When the I
flag is cleared, the PCE indicates that the optional object was
processed. Note that for the delegated LSPs, the PCE can update and
mark some object as ignored even when the PCC had set the P flag
during delegation.
3.3.2. The PCRpt message
The I flag in the PCRpt message [RFC8231] allows a PCC to indicate to
a PCE whether or not an optional object was processed in response to
an LSP Update Request. The PCC MAY include the ignored optional
object in its report and set the I flag to indicate that the optional
object was ignored at PCC. When the I flag is cleared, the PCC
indicates that the optional object was processed. The I flag has no
Dhody & Litkowski Expires September 2, 2018 [Page 5]
Internet-Draft STATEFUL-OPT March 2018
meaning if the PCRpt message is not in response to a PCUpd or
PCInitiate message.
3.3.3. The PCInitiate message
The I flag has no meaning in the PCinitiate message [RFC8281].
3.4. Unknown Object Handling
This document updates the handling of unknown objects in stateful
PCEP messages as per the setting of P flag in the common object
header in a similar way as [RFC5440], i.e. if a PCEP speaker does not
understand an object with the P flag set or understands the object
but decides to ignore the object, the entire stateful PCEP message
MUST be rejected and the PCE MUST send a PCErr message with Error-
Type="Unknown Object" or "Not supported Object" [RFC5440]. In case
the P flag is not set, the PCEP speaker is free to ignore the object
and continue with the message processing as defined.
[RFC8231] defined LSP Error Code TLV to be carried in PCRpt message
in the LSP object to convey error information. This document does
not change that impact that procedure.
4. Security Considerations
This documents clarifies how the already existing P and I flag in
PCEP common object header could be used during stateful PCEP
exchanges. It updates the unknown object error handling in stateful
PCEP message exchange. These changes on its own do not add any new
security concerns. The security considerations identified in
[RFC5440], [RFC8231], and [RFC8281].
As stated in [RFC6952], PCEP implementations SHOULD support the TCP-
AO [RFC5925] and not use TCP MD5 because of TCP MD5's known
vulnerabilities and weakness. PCEP also support Transport Layer
Security (TLS) [RFC8253] as per the recommendations and best current
practices in [RFC7525].
5. IANA Considerations
5.1. STATEFUL-PCE-CAPABILITY TLV
[RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV; per that RFC, IANA
created a registry to manage the value of the STATEFUL-PCE-CAPABILITY
TLV's Flag field. IANA has allocated a new bit in the STATEFUL-PCE-
CAPABILITY TLV Flag Field registry, as follows:
Dhody & Litkowski Expires September 2, 2018 [Page 6]
Internet-Draft STATEFUL-OPT March 2018
Bit Description Reference
-------------------------------------------------
TBD1 RELAX bit [This I.D.]
6. Manageability Considerations
6.1. Control of Function and Policy
An operator MUST be allowed to configure the capability to support
relaxation of constraints in the stateful PCEP message exchange.
They SHOULD also allow configuration of related LSP constraints (or
parameters) that are optional to process.
6.2. Information and Data Models
An implementation SHOULD allow the operator to view the capability
defined in this document. To serve this purpose, the PCEP YANG
module [I-D.ietf-pce-pcep-yang] could be extended.
6.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in [RFC5440].
6.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in
[RFC5440].
6.5. Requirements On Other Protocols
Mechanisms defined in this document do not imply any new requirements
on other protocols.
6.6. Impact On Network Operations
Mechanisms defined in this document do not have any impact on network
operations in addition to those already listed in [RFC5440].
7. References
7.1. Normative References
Dhody & Litkowski Expires September 2, 2018 [Page 7]
Internet-Draft STATEFUL-OPT March 2018
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
7.2. Informative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<https://www.rfc-editor.org/info/rfc6952>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki,
"Extensions to the Path Computation Element Communication
Protocol (PCEP) to Compute Service-Aware Label Switched
Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September
2017, <https://www.rfc-editor.org/info/rfc8233>.
Dhody & Litkowski Expires September 2, 2018 [Page 8]
Internet-Draft STATEFUL-OPT March 2018
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[RFC8281] 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", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", draft-ietf-pce-pcep-
yang-06 (work in progress), January 2018.
[I-D.ietf-pce-association-diversity]
Litkowski, S., Sivabalan, S., Barth, C., and D. Dhody,
"Path Computation Element communication Protocol extension
for signaling LSP diversity constraint", draft-ietf-pce-
association-diversity-03 (work in progress), February
2018.
[I-D.ietf-pce-association-group]
Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Dhody, D., and Y. Tanaka, "PCEP Extensions for
Establishing Relationships Between Sets of LSPs", draft-
ietf-pce-association-group-04 (work in progress), August
2017.
Authors' Addresses
Dhruv Dhody (editor)
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: dhruv.ietf@gmail.com
Stephane Litkowski
Orange
EMail: stephane.litkowski@orange.com
Dhody & Litkowski Expires September 2, 2018 [Page 9]