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
|
<pre>Internet Engineering Task Force (IETF) P. Dutta
Request for Comments: 7392 M. Bocci
Category: Standards Track Alcatel-Lucent
ISSN: 2070-1721 L. Martini
Cisco Systems
December 2014
<span class="h1">Explicit Path Routing for Dynamic Multi-Segment Pseudowires</span>
Abstract
When set up through an explicit path, dynamic Multi-Segment
Pseudowires (MS-PWs) may be required to provide a simple solution for
1:1 protection with diverse primary and backup MS-PWs for a service,
or to enable controlled signaling (strict or loose) for special MS-
PWs. This document specifies the extensions and procedures required
to enable dynamic MS-PWs to be established along explicit paths.
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/rfc7392">http://www.rfc-editor.org/info/rfc7392</a>.
Copyright Notice
Copyright (c) 2014 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">Dutta, 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="./rfc7392">RFC 7392</a> MS-PW Explicit Routing December 2014</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Requirements Language and Terminology ...........................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Explicit Path in MS-PW Signaling ................................<a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. S-PE Addressing ............................................<a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. Explicit Route TLV (ER-TLV) ................................<a href="#page-3">3</a>
<a href="#section-3.3">3.3</a>. Explicit Route Hop TLV (ER-Hop TLV) ........................<a href="#page-4">4</a>
<a href="#section-3.4">3.4</a>. ER-Hop Semantics ...........................................<a href="#page-4">4</a>
<a href="#section-3.4.1">3.4.1</a>. ER-Hop Type: IPv4 Prefix ............................<a href="#page-4">4</a>
<a href="#section-3.4.2">3.4.2</a>. ER-Hop Type: IPv6 Prefix ............................<a href="#page-4">4</a>
<a href="#section-3.4.3">3.4.3</a>. ER-Hop Type: L2 PW Address ..........................<a href="#page-5">5</a>
<a href="#section-4">4</a>. Explicit Route TLV Processing ...................................<a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. Next-Hop Selection .........................................<a href="#page-6">6</a>
<a href="#section-4.2">4.2</a>. Adding ER Hops to the Explicit Route TLV ...................<a href="#page-8">8</a>
<a href="#section-5">5</a>. IANA Considerations .............................................<a href="#page-8">8</a>
<a href="#section-6">6</a>. Security Considerations .........................................<a href="#page-8">8</a>
<a href="#section-7">7</a>. Normative References ............................................<a href="#page-9">9</a>
Acknowledgements ...................................................<a href="#page-9">9</a>
Authors' Addresses ................................................<a href="#page-10">10</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Procedures for dynamically establishing Multi-Segment Pseudowires
(MS-PWs), where their paths are automatically determined using a
dynamic routing protocol, are defined in [<a href="./rfc7267" title=""Dynamic Placement of Multi-Segment Pseudowires"">RFC7267</a>]. For 1:1
protection of MS-PWs with primary and backup paths, MS-PWs need to be
established through a diverse set of Switching Provider Edges (S-PEs)
to avoid any single points of failure at the PW level. [<a href="./rfc7267" title=""Dynamic Placement of Multi-Segment Pseudowires"">RFC7267</a>]
allows this through BGP-based mechanisms. This document defines an
additional mechanism that allows Source Terminating Provider Edges
(ST-PEs) to explicitly choose the path that a PW would take through
the intervening S-PEs. Explicit path routing of dynamic MS-PWs may
also be required for controlled setup of dynamic MS-PWs and network
resource management.
Note that in many deployments the ST-PE will not have a view of the
topology of S-PEs and so the explicit route will need to be supplied
from a management application. How that management application
determines the explicit route is outside the scope of this document.
<span class="grey">Dutta, 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="./rfc7392">RFC 7392</a> MS-PW Explicit Routing December 2014</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Requirements Language and Terminology</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" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
This document uses the terminology defined in [<a href="./rfc7267" title=""Dynamic Placement of Multi-Segment Pseudowires"">RFC7267</a>], [<a href="./rfc4447" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>],
and [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>].
The following additional terminology is used:
Abstract Node: A group of nodes (S-PEs) representing an explicit hop
along the path of an MS-PW. An abstract node is identified by an
IPv4, IPv6, or S-PE address.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Explicit Path in MS-PW Signaling</span>
This section describes the Label Distribution Protocol (LDP)
extensions required for signaling explicit paths in dynamic MS-PW
setup messages. An explicitly routed MS-PW is set up using a Label
Mapping message that carries an ordered list of the S-PEs that the
MS-PW is expected to traverse. The ordered list is encoded as a
series of Explicit Route Hop TLVs (ER-Hop TLVs) encoded in an ER-TLV
that is carried in a Label Mapping message.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. S-PE Addressing</span>
An S-PE address is used to identify a given S-PE among the set of
S-PEs belonging to the Packet Switched Networks (PSNs) that may be
used by an MS-PW. Each S-PE MUST be assigned an address as specified
in <a href="./rfc7267#section-3.2">Section 3.2 of [RFC7267]</a>. An S-PE that is capable of dynamic
MS-PW signaling, but has not been assigned an S-PE address, and that
receives a Label Mapping message for a dynamic MS-PW MUST follow the
procedures in <a href="./rfc7267#section-3.2">Section 3.2 of [RFC7267]</a>.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Explicit Route TLV (ER-TLV)</span>
The ER-TLV specifies the path to be taken by the MS-PW being
established. Each hop along the path is represented by an abstract
node, which is a group of one or more S-PEs, identified by an IPv4,
IPv6, or S-PE address. The ER-TLV format is as per <a href="./rfc3212#section-4.1">Section 4.1 of
[RFC3212]</a>.
The ER-TLV contains one or more ER-Hop TLVs as defined in
<a href="#section-3.3">Section 3.3</a>.
<span class="grey">Dutta, 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="./rfc7392">RFC 7392</a> MS-PW Explicit Routing December 2014</span>
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Explicit Route Hop TLV (ER-Hop TLV)</span>
The contents of an ER-TLV are a series of variable-length ER-Hop
TLVs. Each hop contains the identification of an "abstract node"
that represents the hop to be traversed. The ER-Hop TLV format is as
specified in <a href="./rfc3212#section-4.2">Section 4.2 of [RFC3212]</a>.
[<a id="ref-RFC3212">RFC3212</a>] defines four ER-Hop TLV Types: IPv4 Prefix, IPv6 Prefix,
Autonomous System Number, and LSP-ID. This document specifies the
following new ER-Hop TLV Type:
Value Type
------ --------------------------------
0x0805 L2 PW Address of Switching Point
ER-Hop TLV
Details of the ER-Hop semantics are defined in <a href="#section-3.4">Section 3.4</a>.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. ER-Hop Semantics</span>
This section describes the various semantics associated with the
ER-Hop TLV.
<span class="h4"><a class="selflink" id="section-3.4.1" href="#section-3.4.1">3.4.1</a>. ER-Hop Type: IPv4 Prefix</span>
The semantics of the IPv4 ER-Hop TLV Type are specified in <a href="./rfc3212#section-4.7.1">[RFC3212],
Section 4.7.1</a>.
<span class="h4"><a class="selflink" id="section-3.4.2" href="#section-3.4.2">3.4.2</a>. ER-Hop Type: IPv6 Prefix</span>
The semantics of the IPv6 ER-Hop TLV Type are specified in <a href="./rfc3212#section-4.7.2">[RFC3212],
Section 4.7.2</a>.
<span class="grey">Dutta, 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="./rfc7392">RFC 7392</a> MS-PW Explicit Routing December 2014</span>
<span class="h4"><a class="selflink" id="section-3.4.3" href="#section-3.4.3">3.4.3</a>. ER-Hop Type: L2 PW Address</span>
The semantics of the L2 PW Address ER-Hop TLV Type, which contains
the L2 PW Address derived from the Generalized PWid Forwarding
Equivalence Class (FEC) AII Type 2 structure as defined in [<a href="./rfc5003" title=""Attachment Individual Identifier (AII) Types for Aggregation"">RFC5003</a>],
are 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| ER-Hop Type | Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type=02 | Length | Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global ID (contd.) | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (contd.) | AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U/F
These bits MUST be set to zero and the procedures of
[<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>] followed when the TLV is not known to the
receiving node.
Type
A fourteen-bit field carrying the value of the ER-Hop 3,
L2 PW Address, Value = 0x0805.
Length
Specifies the length of the value field in bytes = 18.
L Bit
Set to indicate a loose hop.
Cleared to indicate a strict hop.
Reserved
Zero on transmission. Ignored on receipt.
PreLen
Prefix Length 1-96 (including the length of the Global ID,
Prefix, and AC ID fields).
<span class="grey">Dutta, 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="./rfc7392">RFC 7392</a> MS-PW Explicit Routing December 2014</span>
All other fields (AII Type, Length, Global ID, Prefix, and AC ID)
define the L2 PW Address and are to be set and interpreted as
defined in <a href="./rfc5003#section-3.2">Section 3.2 of [RFC5003]</a>.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Explicit Route TLV Processing</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Next-Hop Selection</span>
A PW Label Mapping message containing an Explicit Route TLV specifies
the next hop for a given MS-PW path. Selection of this next hop by
the ST-PE or S-PE inserting the ER-Hop TLV may involve a selection
from a set of possible alternatives. The mechanism for making a
selection from this set is implementation specific and is outside the
scope of this document. The mechanism used to select a particular
path is also outside the scope of this document, but each node MUST
determine a loop-free path if it is to signal the MS-PW. <a href="./rfc6073#section-7.6">[RFC6073],
Section 7.6</a> provides a mechanism by which a node can check that the
path taken by an MS-PW does not include loops.
As noted in <a href="#section-1">Section 1</a>, in many deployments the ST-PE will not have a
view of the topology of S-PEs and so the path will need to be
supplied from a management application.
If a loop-free path cannot be found by an ST-PE or S-PE, then a node
MUST NOT attempt to signal the MS-PW. For an S-PE, if it cannot
determine a loop-free path, then the received Label Mapping message
MUST be released with a status code of "PW Loop Detected" as per
<a href="./rfc7267#section-4.2.3">Section 4.2.3 of [RFC7267]</a>.
To determine the next hop for the MS-PW path, a node performs the
following steps. Note that these procedures assume that a valid S-PE
address has been assigned to the node, as per <a href="#section-3.1">Section 3.1</a>, above.
1. The node receiving the Label Mapping message that contains an
ER-TLV MUST evaluate the first ER-Hop. If the L bit is not set
in the first ER-Hop and if the node is not part of the abstract
node described by the first ER-Hop (i.e., it does not lie within
the prefix as determined by the prefix length specified in the
ER-Hop TLV), it has received the message in error. Therefore,
the node MUST reply with a Label Release message with a "Bad
Initial ER-Hop Error" (0x04000004) status code. If the L bit is
set and the local node is not part of the abstract node described
by the first ER-Hop, the node selects a next hop that is along
the path to the abstract node described by the first ER-Hop. If
there is no ER-Hop TLV contained in the ER-TLV, the message is
also in error, and the node SHOULD return a "Bad Explicit Routing
TLV Error" (0x04000001) status code in a Label Release message
sent to the upstream node. Note that this statement does not
<span class="grey">Dutta, 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="./rfc7392">RFC 7392</a> MS-PW Explicit Routing December 2014</span>
preclude a Label Mapping message with no ER-TLV. If a Label
Mapping message with no ER-TLV is received, then it MUST be
processed as per [<a href="./rfc7267" title=""Dynamic Placement of Multi-Segment Pseudowires"">RFC7267</a>].
2. If there are no further ER-Hop TLVs following the first ER-Hop
TLV, this indicates the end of the explicit route. The Explicit
Route TLV MUST be removed from the Label Mapping message. This
node may or may not be the end of the PW. Processing continues
as per <a href="#section-4.2">Section 4.2</a>, where a new Explicit Route TLV MAY be added
to the Label Mapping message.
3. If a second ER-Hop TLV does exist, and the node is also a part of
the abstract node described by the second ER-Hop, then the node
deletes the first ER-Hop and continues processing with step 2,
above. Note that this makes the second ER-Hop into the first
ER-Hop for the iteration for the next PW segment.
4. The node determines if it is topologically adjacent to the
abstract node described by the second ER-Hop. That is, it is
directly connected to the next node by a PW control-plane
adjacency. If so, the node selects a particular next hop that is
a member of the abstract node. The node then deletes the first
ER-Hop and continues processing as per <a href="#section-4.2">Section 4.2</a>, below.
5. Next, the node selects a next hop within the abstract node of the
first ER-Hop that is along the path to the abstract node of the
second ER-Hop. If no such path exists, then there are two cases:
A. If the second ER-Hop is a strict ER Hop, then there is an
error, and the node MUST return a Label Release message to
the upstream node with a "Bad Strict Node Error" (0x04000002)
status code.
B. Otherwise, if the second ER-Hop is a loose ER Hop, then the
node selects any next hop that is along the path to the next
abstract node. If no path exists within the MPLS domain,
then there is an error, and the node MUST return a Label
Release message to the upstream node with a "Bad Loose Node
Error" (0x04000003) status code.
6. Finally, the node replaces the first ER-Hop with any ER Hop that
denotes an abstract node containing the next hop. This is
necessary so that when the explicit route is received by the next
hop, it will be accepted.
7. Progress the Label Mapping message to the next hop.
<span class="grey">Dutta, 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="./rfc7392">RFC 7392</a> MS-PW Explicit Routing December 2014</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Adding ER Hops to the Explicit Route TLV</span>
After selecting a next hop, the node MAY alter the explicit route in
the following ways.
If, as part of executing the algorithm in <a href="#section-4.1">Section 4.1</a>, the Explicit
Route TLV is removed, then the node MAY add a new Explicit Route TLV.
Otherwise, if the node is a member of the abstract node for the first
ER-Hop, then a series of ER Hops MAY be inserted before the First ER
Hop or the first ER-Hop MAY be replaced. Each ER Hop in this series
MUST denote an abstract node that is a subset of the current abstract
node.
Alternately, if the first ER-Hop is a loose ER Hop, an arbitrary
series of ER Hops MAY be inserted prior to the first ER-Hop.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
<a href="./rfc5036">RFC 5036</a> [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>] defines the LDP TLV name space, which is
maintained by IANA, in the LDP "TLV Type Name Space" registry. TLV
types for the Explicit Route TLV, the IPv4 Prefix ER-Hop TLV, and the
IPv6 Prefix ER-Hop TLV are already defined in this registry.
IANA has assigned a further code point from the IETF consensus
portion of this registry as follows:
TLV Type Value Reference
------------------------------------ ------ -------------
L2 PW Address of Switching Point 0x0805 This Document
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This document introduces no new security considerations beyond those
discussed in [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>], [<a href="./rfc4447" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>], and [<a href="./rfc7267" title=""Dynamic Placement of Multi-Segment Pseudowires"">RFC7267</a>]. The security
considerations detailed in those documents apply to the protocol
extensions described in this RFC.
As with [<a href="./rfc7267" title=""Dynamic Placement of Multi-Segment Pseudowires"">RFC7267</a>], it should be noted that the path selection
mechanisms specified in this document enable the network to
automatically select the S-PEs that are used to forward packets on
the MS-PW. Appropriate tools, such as the Virtual Circuit
Connectivity Verification (VCCV) trace mechanisms specified in
[<a href="./rfc6073" title=""Segmented Pseudowire"">RFC6073</a>], can be used by an operator of the network to verify the
path taken by the MS-PW and therefore be satisfied that the path does
not represent an additional security risk.
<span class="grey">Dutta, 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="./rfc7392">RFC 7392</a> MS-PW Explicit Routing December 2014</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</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>, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC3212">RFC3212</a>] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu,
L., Doolan, P., Worster, T., Feldman, N., Fredette, A.,
Girish, M., Gray, E., Heinanen, J., Kilty, T., and A.
Malis, "Constraint-Based LSP Setup using LDP", <a href="./rfc3212">RFC 3212</a>,
January 2002, <<a href="http://www.rfc-editor.org/info/rfc3212">http://www.rfc-editor.org/info/rfc3212</a>>.
[<a id="ref-RFC4447">RFC4447</a>] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", <a href="./rfc4447">RFC 4447</a>, April 2006,
<<a href="http://www.rfc-editor.org/info/rfc4447">http://www.rfc-editor.org/info/rfc4447</a>>.
[<a id="ref-RFC5003">RFC5003</a>] Metz, C., Martini, L., Balus, F., and J. Sugimoto,
"Attachment Individual Identifier (AII) Types for
Aggregation", <a href="./rfc5003">RFC 5003</a>, September 2007,
<<a href="http://www.rfc-editor.org/info/rfc5003">http://www.rfc-editor.org/info/rfc5003</a>>.
[<a id="ref-RFC5036">RFC5036</a>] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", <a href="./rfc5036">RFC 5036</a>, October 2007,
<<a href="http://www.rfc-editor.org/info/rfc5036">http://www.rfc-editor.org/info/rfc5036</a>>.
[<a id="ref-RFC6073">RFC6073</a>] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
Aissaoui, "Segmented Pseudowire", <a href="./rfc6073">RFC 6073</a>, January 2011,
<<a href="http://www.rfc-editor.org/info/rfc6073">http://www.rfc-editor.org/info/rfc6073</a>>.
[<a id="ref-RFC7267">RFC7267</a>] Martini, L., Bocci, M., and F. Balus, "Dynamic Placement
of Multi-Segment Pseudowires", <a href="./rfc7267">RFC 7267</a>, June 2014,
<<a href="http://www.rfc-editor.org/info/rfc7267">http://www.rfc-editor.org/info/rfc7267</a>>.
Acknowledgements
The authors gratefully acknowledge the contribution of the <a href="./rfc3212">RFC 3212</a>
[<a href="./rfc3212" title=""Constraint-Based LSP Setup using LDP"">RFC3212</a>] authors for the specification of the ER TLV and the ER-Hop
TLV, which are reused by this document. The authors also gratefully
acknowledge the input of Lizhong Jin.
<span class="grey">Dutta, 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="./rfc7392">RFC 7392</a> MS-PW Explicit Routing December 2014</span>
Authors' Addresses
Pranjal Kumar Dutta
Alcatel-Lucent
701 E. Middlefield Road
Mountain View, California 94043
United States
EMail: pranjal.dutta@alcatel-lucent.com
Matthew Bocci
Alcatel-Lucent
Voyager Place, Shoppenhangers Road
Maidenhead, Berks SL6 2PJ
United Kingdom
EMail: matthew.bocci@alcatel-lucent.com
Luca Martini
Cisco Systems
9155 East Nichols Avenue, Suite 400
Englewood, Colorado 80112
United States
EMail: lmartini@cisco.com
Dutta, et al. Standards Track [Page 10]
</pre>
|
