-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-dhody-pce-pcep-p2mp-per-destination-12.xml
452 lines (424 loc) · 23.3 KB
/
draft-dhody-pce-pcep-p2mp-per-destination-12.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
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?>
<rfc ipr="trust200902" category="exp" docName="draft-dhody-pce-pcep-p2mp-per-destination-12" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="EXPLICIT-INC-EXC-ABSTRACT-NODES">Supporting Explicit Inclusion or Exclusion
of Abstract Nodes for a Subset of P2MP Destinations in Path Computation Element Communication
Protocol (PCEP). </title>
<author initials="D" surname="Dhody" fullname="Dhruv Dhody">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560066</code>
<country>India</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</author>
<author initials="R" surname="Palleti" fullname="Ramanjaneya Reddy Palleti">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560066</code>
<country>India</country>
</postal>
<email>ramanjaneya.palleti@huawei.com</email>
</address>
</author>
<author initials="U" surname="Palle" fullname="Udayasree Palle">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560066</code>
<country>India</country>
</postal>
<email>udayasreereddy@gmail.com</email>
</address>
</author>
<author initials="V" surname="Kondreddy" fullname="Venugopal Reddy Kondreddy">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560066</code>
<country>India</country>
</postal>
<email>venugopalreddyk@huawei.com</email>
</address>
</author>
<date year="2017" />
<area>Routing</area>
<workgroup>PCE Working Group</workgroup>
<abstract>
<t>The ability to determine paths of point-to-multipoint (P2MP) Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label
Switched Paths (TE LSPs) is one the key requirements for Path Computation Element
(PCE). The PCEP has been extentded for intra and inter domain path computation via PCE(s)
for P2MP TE LSP. </t>
<t>This document describes the motivation and PCEP extension for explicitly
specifying abstract nodes for inclusion or exclusion for a subset of destinations
during P2MP path computation via PCE(s).</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>The PCE architecture is defined in <xref target="RFC4655"/>. <xref target="RFC5862"/>
lay out the requirements for PCEP to support P2MP path computation.
<xref target="I-D.ietf-pce-rfc6006bis"/> describe an extension to PCEP to compute optimal constrained
intra-domain (G)MPLS P2MP TE LSPs. <xref target="RFC7334"/> describes the
mechanism for inter-domain P2MP path computation. </t>
<t>Further <xref target="I-D.ietf-pce-rfc6006bis"/> describes mechanism to specify a list of nodes that can be
used as branch nodes or a list of nodes that cannot be used as branch nodes via Branch
Node Capability (BNC) object. The BNC object is used to specify which nodes have the
capability to act as a branch nodes or which nodes lack the capabilty. It supports IPv4
and IPv6 prefix sub-objects only. </t>
<t>This document explains the need to add
the capability to explicitly specify any abstract nodes (not just nodes with branch node
capabiltiy) for inclusion or exclusion for a subset of destinations.</t>
<t><xref target="RFC7334"/> describes the core-tree procedure to compute
inter-domain P2MP tree. It assumes that, due to deployment and commercial limitations,
the sequence of domains for a path (the path domain tree) will be known in advance.
For a group of destination which belong to a particular destination domain, the domain-sequence needs
to be encoded separately as described in <xref target="RFC7897"/>. The mechanism, as described in
this document, of explicitly specifying abstract nodes for inclusion or exclusion for
a subset of destinations can be used for this purpose, where abstract nodes are domains. </t>
<t>Stateful PCEs are shown to be helpful in many application scenarios,
in both MPLS and GMPLS networks, as illustrated in <xref target="RFC8051"/>. These
scenarios apply equally to P2P and P2MP TE LSPs.
<xref target="RFC8231"/> provides the fundamental extensions
needed for stateful PCE to support general functionality for P2P TE
LSP. <xref target="I-D.ietf-pce-pce-initiated-lsp"/> provides the an extensions
needed for stateful PCE-initiated P2P TE LSP. Complementarily, <xref target="I-D.ietf-pce-stateful-pce-p2mp"/>
focuses on the extensions that are necessary in order for
the deployment of stateful PCEs to support P2MP TE LSPs.</t>
<section title="Requirements Language" toc="default">
<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 title="Terminology" toc="default">
<t>The following terminology is used in this document.</t>
<t>
<list style="hanging">
<t hangText="IRO:">Include Route Object.</t>
<t hangText="PCC:">Path Computation Client: any client application requesting a
path computation to be performed by a Path Computation Element.</t>
<t hangText="PCE:">Path Computation Element. An entity (component, application,
or network node) that is capable of computing a network path or route based on
a network graph and applying computational constraints.</t>
<t hangText="PCEP:">Path Computation Element Protocol.</t>
<t hangText="P2MP:">Point-to-Multipoint</t>
<t hangText="P2P:">Point-to-Point</t>
<t hangText="RRO:">Record Route Object</t>
<t hangText="RSVP:">Resource Reservation Protocol</t>
<t hangText="TE LSP:">Traffic Engineering Label Switched Path.</t>
<t hangText="XRO:">Exclude Route Object.</t>
</list>
</t>
</section>
<section title="Motivation" toc="default">
<section title="Domain Sequence Tree in Inter Domain P2MP Path Computation" toc="default">
<t><xref target="RFC7334"/> describes the core-tree procedure for inter-domain
path computation. The procedure assumes that the sequence of domains for a path (the path domain tree)
will be known in advance due to deployment and commercial limitations (e.g., inter-AS peering agreements).</t>
<t>In the <xref target="fig1"/> below, D1 is the root domain; D4, D5 and D6 are the destination domains.
The ingress is Ro in domain D1; egresses are M, N in Domain D4; R, S in Domain D5; and U, V in Domain D6. </t>
<t>
<figure title="Domain Topology Example" anchor="fig1" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
+----------------+
| |Domain D1
| Ro |
| |
| A |
| |
+-B------------C-+
/ \
/ \
/ \
Domain D2 / \ Domain D3
+-------------D--+ +-----E----------+
| | | |
| F | | |
| G | | H |
| | | |
| | | |
+-I--------------+ +-J------------K-+
/\ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ Domain D4 \ Domain D5 / Domain D6 \
+-L-------------W+ +------P---------+ +-----------T----+
| | | | | |
| | | Q | | U |
| M O | | S | | |
| | | | | V |
| N | | R | | |
+----------------+ +----------------+ +----------------+
]]></artwork>
</figure>
</t>
<t>
The domain tree can be represented as a series of domain sequences:
<list>
<t>Domain D1, Domain D3, Domain D6</t>
<t>Domain D1, Domain D3, Domain D5</t>
<t>Domain D1, Domain D2, Domain D4</t>
</list>
</t>
<t>Since destinations in different destination domain will have different domain sequence
within the domain tree, it requires following encoding that binds destinations to a particular domain sequence.</t>
<t>
<list style="symbols">
<t>Destination M and N: D1-D2-D4</t>
<t>Destination R and S: D1-D3-D5</t>
<t>Destination U and V: D1-D3-D6</t>
</list>
</t>
<t>An extension in P2MP Path Computation request is needed to support this.
(Refer <xref target="SEC_REQ"/>)</t>
<t>The abstract nodes MAY include (but not limited to) domain subobjects - AS number
and IGP Area as described in <xref target="RFC7897"/>.</t>
<!--<section title="PCE-sequence" toc="default">
<t><xref target="RFC7334"/> also mentions PCE-sequence (i.e. list of PCE for
each domain in the path domain tree). <xref target="RFC5886"/> specify PCE-ID object
(used to specify a PCE's IP address)
and <pce-list> (list of PCE or PCE-sequence). Like domain-sequence as explained
above, PCE-sequence
will be different for different destinations and thus should be encoded per
subset of destinations.
</t>
</section>-->
</section>
<section title="Explicit inclusion or exclusion of abstract nodes" toc="default">
<t><xref target="I-D.ietf-pce-rfc6006bis"/> describes four possible types of leaves in a P2MP
request encoded in P2MP END-POINTS object.</t>
<t>
<list style="symbols">
<t>New leaves to add </t>
<t>Old leaves to remove </t>
<t>Old leaves whose path can be modified/reoptimized </t>
<t>Old leaves whose path must be left unchanged </t>
</list>
</t>
<t><xref target="I-D.ietf-pce-rfc6006bis"/> only allows to encode a list of nodes that have
(or have not) the branch node capability by using the Branch Node Capability (BNC)
Object. This object apply to all destinations (old and new) in the P2MP tree.</t>
<t>For an existing P2MP tree with an overloaded branch node, when adding a set of
new leaves, administrator may want to exclude that particular branch node to balance
the final P2MP tree. This cannot be achieved via the BNC object but by explicitly
excluding a particular node or including a different node, for the P2MP END-POINTS
object for new leaves only.</t>
<t>Administrator at the Ingress can exert stronger control by providing explicit
inclusion or exclusion of any abstract nodes (not limited to specifying nodes with
branch node capability) for a group (subset) of destinations and not all destinations.</t>
</section>
</section>
<section title="Detailed Description" toc="default">
<section title="Objective" toc="default">
<t><xref target="I-D.ietf-pce-rfc6006bis"/> and <xref target="I-D.ietf-pce-stateful-pce-p2mp"/> defines Request Message Format and Objects, along with
<end-point-rro-pair-list>. This section introduce the use of <IRO>
and <XRO> which are added to the <end-point-rro-pair-list>.</t>
<t>To allow abstract nodes to be explicitly included or excluded for a subset of
destinations (encoded in one <END-POINTS> object), changes are made as
shown below.</t>
<t>The abstract node (encoded as subobject in <IRO> and <XRO>) MAY be
an absolute hop, IP-Prefix, AS or IGP Area. The subobjects are described
in <xref target="RFC3209"/>, <xref target="RFC3477"/>, <xref target="RFC4874"/>
and <xref target="RFC7897"/>.</t>
<t>Note that one P2MP Path request can have multiple <END-POINTS> objects and each
P2MP <END-POINTS> object may have multiple destinations, the <pce-list>, <IRO> and <XRO>
is applied for all destinations in one such P2MP <END-POINTS> object.</t>
</section>
<section title="Request Message Format" toc="default" anchor="SEC_REQ">
<t>The format of PCReq message, with <xref target="I-D.ietf-pce-stateful-pce-p2mp"/> as base, is modified as follows:</t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
where:
<svec-list>::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<end-point-pce-iro-xro-rro-pair-list>
[<LSP>]
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>|<BNC>]
[<LOAD-BALANCING>]
<end-point-pce-iro-xro-rro-pair-list>::=
<END-POINTS>
[<IRO>]
[<XRO>]
[<RRO-List>][<BANDWIDTH>]
[<end-point-pce-iro-xro-rro-pair-list>]
<RRO-List>::=(<RRO>|<SRRO>)[<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>]
]]></artwork>
</figure>
</t>
<t>From <xref target="I-D.ietf-pce-rfc6006bis"/> and <xref target="I-D.ietf-pce-stateful-pce-p2mp"/>,
usage of <end-point-rro-pair-list> is changed
to <end-point-pce-iro-xro-rro-pair-list> in this document.</t>
<t><xref target="I-D.ietf-pce-rfc6006bis"/> describes Branch Node Capability (BNC) Object which is
different from the use of <IRO> and <XRO> to specify inclusion/exclusion of
abstract nodes for a subset of destinations as described here.</t>
</section>
<section title="Report Message Format">
<t><xref target="I-D.ietf-pce-stateful-pce-p2mp"/> defines a report message format and
objects. This document extends the message to allow explicit inclusion and exclusion
of abstract nodes for a group of destinations. </t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<state-report-list> ::= <state-report>
[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
<end-point-intended-path-pair-list>
[<actual_attribute_list>
<end-point-actual-path-pair-list>]
<intended-attribute-list>
Where:
<end-point-intended-path-pair-list>::=
[<END-POINTS>]
[<S2LS>]
[<IRO>]
[<XRO>]
<intended_path>
[<end-point-intended-path-pair-list>]
<end-point-actual-path-pair-list>::=
[<END-POINTS>]
[<S2LS>]
<actual_path>
[<end-point-actual-path-pair-list>]
<intended_path> ::= (<ERO>|<SERO>)
[<intended_path>]
<actual_path> ::= (<RRO>|<SRRO>)
[<actual_path>]
]]></artwork>
</figure>
</t>
<t><intended_path> is represented by the ERO, SERO object.
The <actual_attribute_list> consists of the actual computed and
signaled values of the <BANDWIDTH> and <metric-lists> objects
defined in <xref target="RFC5440"/>.
<actual_path> is represented by the RRO, SERO object.
The <end-point-intended-path-pair-list> is extended to add the IRO and XRO object for a group of destinations in the END-POINTS object.</t>
</section>
<section title="Backward Compatibility" toc="default">
<t>A legacy implementation that does not support explicit inclusion or exclusion of
abstract nodes for a subset of P2MP destinations will act according to the procedures
set out in <xref target="RFC5440"/>, that is it will find the P2MP Path Request message
out of order with respect to the format specified in <xref target="I-D.ietf-pce-rfc6006bis"/>
and <xref target="I-D.ietf-pce-stateful-pce-p2mp"/>.</t>
</section>
</section>
<section title="IANA Considerations" toc="default">
<t>There are no new IANA allocation in this document.</t>
</section>
<section title="Security Considerations" toc="default">
<t>PCEP security mechanisms as described in <xref target="RFC5440"/>, <xref target="I-D.ietf-pce-rfc6006bis"/>,
<xref target="RFC7334"/> and <xref target="I-D.ietf-pce-stateful-pce-p2mp"/> are applicable for this document.</t>
<t>The new explicit inclusion or exclusion of abstract nodes for a subset of P2MP destination
defined in this document allow finer and more specific control of the path computed by a PCE.
Such control increases the risk if a PCEP message is intercepted, modified, or spoofed because
it allows the attacker to exert control over the path that the PCE will compute or to make the
path computation impossible. Therefore, the security techniques described in <xref target="RFC5440"/>,
<xref target="I-D.ietf-pce-rfc6006bis"/>, <xref target="RFC7334"/> and <xref target="I-D.ietf-pce-stateful-pce-p2mp"/> are considered more important.</t>
<t>Note, however, that the route exclusion mechanisms also provide the operator with the ability to route
around vulnerable parts of the network and may be used to increase overall network security.</t>
</section>
<section title="Manageability Considerations" toc="default">
<section title="Control of Function and Policy" toc="default">
<t>Mechanisms defined in this document do not add any new control function/policy requirements
in addition to those already listed in <xref target="I-D.ietf-pce-rfc6006bis"/> and
<xref target="I-D.ietf-pce-stateful-pce-p2mp"/>.</t>
</section>
<section title="Information and Data Models" toc="default">
<t>Mechanisms defined in this document do not imply any new MIB requirements.</t>
</section>
<section title="Liveness Detection and Monitoring" toc="default">
<t>Mechanisms defined in this document do not imply any new liveness detection and monitoring
requirements in addition to those already listed in <xref target="I-D.ietf-pce-rfc6006bis"/> and
<xref target="I-D.ietf-pce-stateful-pce-p2mp"/>.</t>
</section>
<section title="Verify Correct Operations" toc="default">
<t>Mechanisms defined in this document do not imply any new operation verification requirements
in addition to those already listed in <xref target="I-D.ietf-pce-rfc6006bis"/> and
<xref target="I-D.ietf-pce-stateful-pce-p2mp"/>.</t>
</section>
<section title="Requirements On Other Protocols" toc="default">
<t>Mechanisms defined in this document do not imply any requirements on other protocols in addition
to those already listed in <xref target="I-D.ietf-pce-rfc6006bis"/> and
<xref target="I-D.ietf-pce-stateful-pce-p2mp"/>.</t>
</section>
<section title="Impact On Network Operations" toc="default">
<t>Mechanisms defined in this document do not have any impact on network operations in addition
to those already listed in <xref target="I-D.ietf-pce-rfc6006bis"/> and
<xref target="I-D.ietf-pce-stateful-pce-p2mp"/>.</t>
</section>
</section>
<section title="Acknowledgments" toc="default">
<t>We would like to thank Pradeep Shastry, Suresh babu, Quintin Zhao, Daniel King and Chen Huaimo
for their useful comments and suggestions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.RFC.8174.xml" ?>
<?rfc include="reference.RFC.8231.xml"?>
<?rfc include="reference.I-D.ietf-pce-rfc6006bis"?>
<?rfc include="reference.I-D.ietf-pce-pce-initiated-lsp"?>
<?rfc include="reference.I-D.ietf-pce-stateful-pce-p2mp"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3209.xml" ?>
<?rfc include="reference.RFC.3477.xml" ?>
<?rfc include="reference.RFC.4655.xml" ?>
<?rfc include="reference.RFC.4874.xml" ?>
<?rfc include="reference.RFC.5862.xml" ?>
<?rfc include="reference.RFC.7334.xml" ?>
<?rfc include="reference.RFC.7897.xml" ?>
<?rfc include="reference.RFC.8051.xml" ?>
</references>
</back>
</rfc>