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
|
<pre>Internet Engineering Task Force (IETF) A. Malis
Request for Comments: 8596 S. Bryant
Category: Informational Futurewei
ISSN: 2070-1721 J. Halpern
Ericsson
W. Henderickx
Nokia
June 2019
<span class="h1">MPLS Transport Encapsulation for the Service Function Chaining (SFC)</span>
<span class="h1">Network Service Header (NSH)</span>
Abstract
This document describes how to use a Service Function Forwarder (SFF)
Label (similar to a pseudowire label or VPN label) to indicate the
presence of a Service Function Chaining (SFC) Network Service Header
(NSH) between an MPLS label stack and the NSH original packet/frame.
This allows SFC packets using the NSH to be forwarded between SFFs
over an MPLS network. The label is also used to select between
multiple SFFs in the destination MPLS node.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
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). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see <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/rfc8596">https://www.rfc-editor.org/info/rfc8596</a>.
<span class="grey">Malis, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8596">RFC 8596</a> MPLS for the SFC NSH June 2019</span>
Copyright Notice
Copyright (c) 2019 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-2">2</a>
<a href="#section-1.1">1.1</a>. Terminology ................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. MPLS Encapsulation Using an SFF Label ...........................<a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. MPLS Label Stack Construction at the Sending Node ..........<a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. SFF Label Processing at the Destination Node ...............<a href="#page-5">5</a>
<a href="#section-3">3</a>. Equal-Cost Multipath (ECMP) Considerations ......................<a href="#page-5">5</a>
4. Operations, Administration, and Maintenance (OAM)
Considerations ..................................................<a href="#page-6">6</a>
<a href="#section-5">5</a>. IANA Considerations .............................................<a href="#page-6">6</a>
<a href="#section-6">6</a>. Security Considerations .........................................<a href="#page-6">6</a>
<a href="#section-7">7</a>. References ......................................................<a href="#page-7">7</a>
<a href="#section-7.1">7.1</a>. Normative References .......................................<a href="#page-7">7</a>
<a href="#section-7.2">7.2</a>. Informative References .....................................<a href="#page-8">8</a>
Acknowledgements ...................................................<a href="#page-9">9</a>
Authors' Addresses .................................................<a href="#page-9">9</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
As discussed in [<a href="./rfc8300" title=""Network Service Header (NSH)"">RFC8300</a>], a number of transport encapsulations for
the Service Function Chaining (SFC) Network Service Header (NSH)
already exist, such as Ethernet, UDP, GRE, and others.
This document describes an MPLS transport encapsulation for the NSH
and how to use a Service Function Forwarder (SFF) [<a href="./rfc7665" title=""Service Function Chaining (SFC) Architecture"">RFC7665</a>] Label to
indicate the presence of the NSH in the MPLS packet payload. This
allows SFC packets using the NSH to be forwarded between SFFs in an
MPLS transport network, where MPLS is used to interconnect the
network nodes that contain one or more SFFs. The label is also used
to select between multiple SFFs in the destination MPLS node.
<span class="grey">Malis, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8596">RFC 8596</a> MPLS for the SFC NSH June 2019</span>
From an SFC perspective, this encapsulation is equivalent to other
transport encapsulations of packets using the NSH. This can be
illustrated by adding an additional line to the example of a next-hop
SPI / SI-to-network ("SPI" and "SI" stand for "Service Path
Identifier" and "Service Index") overlay network locator mapping in
Table 1 of [<a href="./rfc8300" title=""Network Service Header (NSH)"">RFC8300</a>]:
+------+------+---------------------+-------------------------+
| SPI | SI | Next Hop(s) | Transport Encapsulation |
+------+------+---------------------+-------------------------+
| 25 | 220 | Label 5467 | MPLS |
+------+------+---------------------+-------------------------+
Table 1: Extension to Table 1 in <a href="./rfc8300">RFC 8300</a>
SFF Labels are similar to other service labels at the bottom of an
MPLS label stack that denote the contents of the MPLS payload being
other than a normally routed IP packet, such as a Layer 2 pseudowire,
an IP packet that is routed in a VPN context with a private address,
or an Ethernet virtual private wire service.
This informational document follows well-established MPLS procedures
and does not require any actions by IANA or any new protocol
extensions.
Note that using the MPLS label stack as a replacement for the SFC
NSH, covering use cases that do not require per-packet metadata, is
described in [<a href="./rfc8595" title=""An MPLS-Based Forwarding Plane for Service Function Chaining"">RFC8595</a>].
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</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>. MPLS Encapsulation Using an SFF Label</span>
The encapsulation is a standard MPLS label stack [<a href="./rfc3032" title=""MPLS Label Stack Encoding"">RFC3032</a>] with an
SFF Label at the bottom of the stack, followed by an NSH as defined
by [<a href="./rfc8300" title=""Network Service Header (NSH)"">RFC8300</a>] and the NSH original packet/frame.
Much like a pseudowire label, an SFF Label MUST be allocated by the
downstream receiver of the NSH from its per-platform label space,
since the meaning of the label is identical, independent of which
incoming interface it is received from [<a href="./rfc3031" title=""Multiprotocol Label Switching Architecture"">RFC3031</a>].
<span class="grey">Malis, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8596">RFC 8596</a> MPLS for the SFC NSH June 2019</span>
If a receiving node supports more than one SFF (i.e., more than one
SFC forwarding instance), then the SFF Label can be used to select
the proper SFF, by having the receiving node advertise more than one
SFF Label to its upstream sending nodes as appropriate.
The method used by the downstream receiving node to advertise SFF
Labels to the upstream sending node is out of scope for this
document. That said, a number of methods are possible, such as via a
protocol exchange, or via a controller that manages both the sender
and the receiver using the Network Configuration Protocol
(NETCONF) / YANG, BGP, the Path Computation Element Communication
Protocol (PCEP), etc. One such BGP-based method has already been
defined and is documented in [<a href="#ref-BGP-NSH-SFC">BGP-NSH-SFC</a>]. This does not constrain
the further definition of other such advertisement methods in the
future.
While the SFF Label will usually be at the bottom of the label stack,
there may be cases where there are additional label stack entries
beneath it. For example, when an Associated Channel Header (ACH) is
carried that applies to the SFF, a Generic Associated Channel Label
(GAL) [<a href="./rfc5586" title=""MPLS Generic Associated Channel"">RFC5586</a>] will be in the label stack below the SFF. Similarly,
an Entropy Label Indicator / Entropy Label (ELI/EL) [<a href="./rfc6790" title=""The Use of Entropy Labels in MPLS Forwarding"">RFC6790</a>] may be
carried below the SFF in the label stack. This is identical to the
situation with VPN labels.
This document does not define the setting of the Traffic Class (TC)
field [<a href="./rfc5462" title=""Multiprotocol Label Switching (MPLS) Label Stack Entry: "">RFC5462</a>] (formerly known as the Experimental Use (EXP) bits
[<a href="./rfc3032" title=""MPLS Label Stack Encoding"">RFC3032</a>]) in the SFF Label.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. MPLS Label Stack Construction at the Sending Node</span>
When one SFF wishes to send an SFC packet with an NSH to another SFF
over an MPLS transport network, a label stack needs to be constructed
by the MPLS node that contains the sending SFF in order to transport
the packet to the destination MPLS node that contains the receiving
SFF. The label stack is constructed as follows:
1. Push zero or more labels that are interpreted by the destination
MPLS node on to the packet, such as the GAL [<a href="./rfc5586" title=""MPLS Generic Associated Channel"">RFC5586</a>] (see
<a href="#section-4">Section 4</a>). The TTL for these labels is set according to the
relevant standards that define these labels.
2. Push the SFF Label to identify the desired SFF in the receiving
MPLS node. The TTL for this MPLS label MUST be set to 1 to avoid
mis-forwarding.
<span class="grey">Malis, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8596">RFC 8596</a> MPLS for the SFC NSH June 2019</span>
3. Push zero or more additional labels such that (a) the resulting
label stack will cause the packet to be transported to the
destination MPLS node, and (b) when the packet arrives at the
destination node, either:
* the SFF Label will be at the top of the label stack (this is
typically the case when penultimate hop popping is used at the
penultimate node), or
* as a part of normal MPLS processing, the SFF Label becomes the
top label in the stack before the packet is forwarded to
another node and before the packet is dispatched to a higher
layer.
The TTL for these labels is set by configuration or set to the
defaults for normal MPLS operation in the network.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. SFF Label Processing at the Destination Node</span>
The destination MPLS node performs a lookup on the SFF Label to
retrieve the next-hop context between the SFF and SF, e.g., to
retrieve the destination Media Access Control (MAC) address in the
case where native Ethernet encapsulation is used between the SFF and
SF. How the next-hop context is populated is out of scope for this
document.
The receiving SFF SHOULD check that the received SFF Label has a TTL
of 1 upon receipt. Any other values indicate a likely error
condition and SHOULD result in discarding the packet.
The receiving MPLS node then pops the SFF Label (and any labels
beneath it) so that the destination SFF receives the SFC packet with
the NSH at the top of the packet.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Equal-Cost Multipath (ECMP) Considerations</span>
As discussed in [<a href="./rfc4928" title=""Avoiding Equal Cost Multipath Treatment in MPLS Networks"">RFC4928</a>] and [<a href="./rfc7325" title=""MPLS Forwarding Compliance and Performance Requirements"">RFC7325</a>], there are ECMP
considerations for payloads carried by MPLS.
Many existing routers use deep packet inspection to examine the
payload of an MPLS packet. If the first nibble of the payload is
equal to 0x4 or 0x6, these routers (sometimes incorrectly, as
discussed in [<a href="./rfc4928" title=""Avoiding Equal Cost Multipath Treatment in MPLS Networks"">RFC4928</a>]) assume that the payload is IPv4 or IPv6,
respectively and, as a result, perform ECMP load balancing based on
(presumed) information present in IP/TCP/UDP payload headers or in a
combination of MPLS label stack and (presumed) IP/TCP/UDP payload
headers in the packet.
<span class="grey">Malis, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8596">RFC 8596</a> MPLS for the SFC NSH June 2019</span>
For SFC, ECMP may or may not be desirable. To prevent ECMP when it
is not desired, the NSH Base Header was carefully constructed so that
the NSH could not look like IPv4 or IPv6 based on its first nibble.
See <a href="./rfc8300#section-2.2">Section 2.2 of [RFC8300]</a> for further details. Accordingly, the
default behavior for MPLS-encapsulated SFC is to not use ECMP other
than by using entropy derived from the MPLS label stack. This
results in all packets going to the same SF taking the same path
regardless of the use of ECMP in the network.
If ECMP is desired when SFC is used with an MPLS transport network,
there are two possible options: entropy labels [<a href="./rfc6790" title=""The Use of Entropy Labels in MPLS Forwarding"">RFC6790</a>] and
flow-aware transport [<a href="./rfc6391" title=""Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network"">RFC6391</a>] labels. A recommendation regarding
choosing between these options, and their proper placement in the
label stack, is left for future study.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Operations, Administration, and Maintenance (OAM) Considerations</span>
OAM at the SFC layer is handled by SFC-defined mechanisms [<a href="./rfc8300" title=""Network Service Header (NSH)"">RFC8300</a>].
However, OAM may be required at the MPLS transport layer. If so,
then standard MPLS-layer OAM mechanisms such as the GAL [<a href="./rfc5586" title=""MPLS Generic Associated Channel"">RFC5586</a>] may
be used at the transport label layer.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
This document has no IANA actions.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This document describes a method for transporting SFC packets using
the NSH over an MPLS transport network. It follows well-established
MPLS procedures in widespread operational use. It does not define
any new protocol elements or allocate any new code points, and it is
no more or less secure than carrying any other protocol over MPLS.
To the MPLS network, the NSH and its contents are simply an opaque
payload.
In addition, the security considerations in [<a href="./rfc8595" title=""An MPLS-Based Forwarding Plane for Service Function Chaining"">RFC8595</a>] also apply to
this document.
<span class="grey">Malis, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8596">RFC 8596</a> MPLS for the SFC NSH June 2019</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.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-RFC3031">RFC3031</a>] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", <a href="./rfc3031">RFC 3031</a>,
DOI 10.17487/RFC3031, January 2001,
<<a href="https://www.rfc-editor.org/info/rfc3031">https://www.rfc-editor.org/info/rfc3031</a>>.
[<a id="ref-RFC3032">RFC3032</a>] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", <a href="./rfc3032">RFC 3032</a>, DOI 10.17487/RFC3032, January 2001,
<<a href="https://www.rfc-editor.org/info/rfc3032">https://www.rfc-editor.org/info/rfc3032</a>>.
[<a id="ref-RFC5462">RFC5462</a>] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", <a href="./rfc5462">RFC 5462</a>, DOI 10.17487/RFC5462,
February 2009, <<a href="https://www.rfc-editor.org/info/rfc5462">https://www.rfc-editor.org/info/rfc5462</a>>.
[<a id="ref-RFC7665">RFC7665</a>] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", <a href="./rfc7665">RFC 7665</a>,
DOI 10.17487/RFC7665, October 2015,
<<a href="https://www.rfc-editor.org/info/rfc7665">https://www.rfc-editor.org/info/rfc7665</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
<a href="./rfc2119">RFC 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-RFC8300">RFC8300</a>] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", <a href="./rfc8300">RFC 8300</a>,
DOI 10.17487/RFC8300, January 2018,
<<a href="https://www.rfc-editor.org/info/rfc8300">https://www.rfc-editor.org/info/rfc8300</a>>.
[<a id="ref-RFC8595">RFC8595</a>] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based
Forwarding Plane for Service Function Chaining", <a href="./rfc8595">RFC 8595</a>,
DOI 10.17487/RFC8595, June 2019,
<<a href="https://www.rfc-editor.org/info/rfc8595">https://www.rfc-editor.org/info/rfc8595</a>>.
<span class="grey">Malis, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8596">RFC 8596</a> MPLS for the SFC NSH June 2019</span>
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-BGP-NSH-SFC">BGP-NSH-SFC</a>]
Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L.
Jalil, "BGP Control Plane for NSH SFC", Work in Progress,
<a href="./draft-ietf-bess-nsh-bgp-control-plane-11">draft-ietf-bess-nsh-bgp-control-plane-11</a>, May 2019.
[<a id="ref-RFC4928">RFC4928</a>] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
Cost Multipath Treatment in MPLS Networks", <a href="https://www.rfc-editor.org/bcp/bcp128">BCP 128</a>,
<a href="./rfc4928">RFC 4928</a>, DOI 10.17487/RFC4928, June 2007,
<<a href="https://www.rfc-editor.org/info/rfc4928">https://www.rfc-editor.org/info/rfc4928</a>>.
[<a id="ref-RFC5586">RFC5586</a>] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", <a href="./rfc5586">RFC 5586</a>,
DOI 10.17487/RFC5586, June 2009,
<<a href="https://www.rfc-editor.org/info/rfc5586">https://www.rfc-editor.org/info/rfc5586</a>>.
[<a id="ref-RFC6391">RFC6391</a>] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V.,
Regan, J., and S. Amante, "Flow-Aware Transport of
Pseudowires over an MPLS Packet Switched Network",
<a href="./rfc6391">RFC 6391</a>, DOI 10.17487/RFC6391, November 2011,
<<a href="https://www.rfc-editor.org/info/rfc6391">https://www.rfc-editor.org/info/rfc6391</a>>.
[<a id="ref-RFC6790">RFC6790</a>] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
<a href="./rfc6790">RFC 6790</a>, DOI 10.17487/RFC6790, November 2012,
<<a href="https://www.rfc-editor.org/info/rfc6790">https://www.rfc-editor.org/info/rfc6790</a>>.
[<a id="ref-RFC7325">RFC7325</a>] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A.,
and C. Pignataro, "MPLS Forwarding Compliance and
Performance Requirements", <a href="./rfc7325">RFC 7325</a>, DOI 10.17487/RFC7325,
August 2014, <<a href="https://www.rfc-editor.org/info/rfc7325">https://www.rfc-editor.org/info/rfc7325</a>>.
<span class="grey">Malis, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8596">RFC 8596</a> MPLS for the SFC NSH June 2019</span>
Acknowledgements
The authors would like to thank Jim Guichard, Eric Rosen, Med
Boucadair, Alexander (Sasha) Vainshtein, Jeff Tantsura, Anoop
Ghanwani, John Drake, Loa Andersson, Carlos Pignataro, Christian
Hopps, and Benjamin Kaduk for their reviews and comments.
Authors' Addresses
Andrew G. Malis
Futurewei
Email: agmalis@gmail.com
Stewart Bryant
Futurewei
Email: stewart.bryant@gmail.com
Joel M. Halpern
Ericsson
Email: joel.halpern@ericsson.com
Wim Henderickx
Nokia
Email: wim.henderickx@nokia.com
Malis, et al. Informational [Page 9]
</pre>
|
