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) R. Singh
Request for Comments: 8614 K. Kompella
Updates: <a href="./rfc4761">4761</a> Juniper Networks
Category: Standards Track S. Palislamovic
ISSN: 2070-1721 Nokia
June 2019
<span class="h1">Updated Processing of Control Flags for</span>
<span class="h1">BGP Virtual Private LAN Service (VPLS)</span>
Abstract
This document updates the meaning of the Control Flags field in the
"Layer2 Info Extended Community" used for BGP Virtual Private LAN
Service (VPLS) Network Layer Reachability Information (NLRI) as
defined in <a href="./rfc4761">RFC 4761</a>. This document updates <a href="./rfc4761">RFC 4761</a>.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8614">https://www.rfc-editor.org/info/rfc8614</a>.
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.
<span class="grey">Singh, 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="./rfc8614">RFC 8614</a> Control Flags for BGP VPLS June 2019</span>
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>. Problem Description .............................................<a href="#page-3">3</a>
3. Updated Meaning of Control Flags in the Layer2 Info Extended
Community .......................................................<a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. Control Word (C-Bit) .......................................<a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. Sequence Flag (S-Bit) ......................................<a href="#page-4">4</a>
4. Using Point-to-Multipoint (P2MP) LSPs as Transport for
BGP VPLS ........................................................<a href="#page-5">5</a>
<a href="#section-5">5</a>. Illustrative Diagram ............................................<a href="#page-6">6</a>
<a href="#section-6">6</a>. Treatment of C-Bits and S-Bits in Multihoming Scenarios .........<a href="#page-7">7</a>
<a href="#section-6.1">6.1</a>. Control Word (C-Bit) .......................................<a href="#page-7">7</a>
<a href="#section-6.2">6.2</a>. Sequence Flag (S-Bit) ......................................<a href="#page-7">7</a>
<a href="#section-7">7</a>. Security Considerations .........................................<a href="#page-8">8</a>
<a href="#section-8">8</a>. IANA Considerations .............................................<a href="#page-8">8</a>
<a href="#section-9">9</a>. References ......................................................<a href="#page-8">8</a>
<a href="#section-9.1">9.1</a>. Normative References .......................................<a href="#page-8">8</a>
<a href="#section-9.2">9.2</a>. Informative References .....................................<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>
"Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling" [<a href="./rfc4761" title=""Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling"">RFC4761</a>] describes the concepts and signaling for using
the Border Gateway Protocol (BGP) to set up a VPLS. It specifies the
BGP VPLS Network Layer Reachability Information (NLRI) by which a
Provider Edge (PE) router may require other PEs in the same VPLS to
include (or not) the Control Word (CW) and sequencing information in
VPLS frames sent to this PE.
The use of the CW helps prevent the misordering of IPv4 or IPv6
Pseudowire (PW) traffic over Equal-Cost Multipath (ECMP) paths or
Link Aggregation Group (LAG) bundles. [<a href="./rfc4385" title=""Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN"">RFC4385</a>] describes the format
for the CW that may be used over point-to-point PWs and over a VPLS.
Along with [<a href="./rfc3985" title=""Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture"">RFC3985</a>], [<a href="./rfc4385" title=""Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN"">RFC4385</a>] also describes sequence number usage
for VPLS frames.
However, [<a href="./rfc4761" title=""Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling"">RFC4761</a>] does not specify the behavior of PEs in a mixed
environment where some PEs support CW/sequencing and others do not.
<span class="grey">Singh, 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="./rfc8614">RFC 8614</a> Control Flags for BGP VPLS June 2019</span>
<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>. Problem Description</span>
[<a id="ref-RFC4761">RFC4761</a>] specifies the VPLS BGP NLRI by which a given PE advertises
the behavior expected by the multiple PEs participating in the same
VPLS. The NLRI indicates the VPLS label that the various PE routers,
which are referred to in the NLRI, should use when forwarding VPLS
traffic to this PE. Additionally, by using the Control Flags, this
PE specifies whether the other PEs (in the same VPLS) should use the
CW or sequenced delivery for frames forwarded to this PE. These are
indicated by the C-bits and the S-bits, respectively, in the Control
Flags, as specified in <a href="./rfc4761#section-3.2.4">Section 3.2.4 in [RFC4761]</a>.
[<a id="ref-RFC4761">RFC4761</a>] requires that if the advertising PE sets the C-bits and
S-bits, the receiving PE MUST, respectively, insert a CW and include
sequence numbers when forwarding VPLS traffic to the advertising PE.
However, in a BGP VPLS deployment, there would often be cases where a
PE receiving the VPLS BGP NLRI may not have the ability to insert a
CW or include sequencing information inside PW frames. Thus, the
behavior of CW processing and sequencing needs to be further
specified.
This document updates the meaning of the Control Flags in the Layer2
Info Extended Community in the BGP VPLS NLRI. It also specifies the
forwarding behavior for a mixed-mode environment where not every PE
in a VPLS has the ability or the configuration to honor the Control
Flags received from the PE advertising the BGP NLRI.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Updated Meaning of Control Flags in the Layer2 Info Extended</span>
<span class="h2"> Community</span>
[<a id="ref-RFC4761">RFC4761</a>] does not allow for the CW setting to be negotiated. In a
typical implementation, if a PE sets the C-bit, it expects to receive
VPLS frames with a CW and will send frames the same way. If the PEs
at the two ends of a PW do not agree on the setting of the C-bit, the
PW does not come up. The behavior is similar for the S-bit.
This memo updates the meaning of the C-bit and the S-bit in the
Control Flags.
<span class="grey">Singh, 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="./rfc8614">RFC 8614</a> Control Flags for BGP VPLS June 2019</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Control Word (C-Bit)</span>
If a PE sets the C-bit in its NLRI, it means that the PE has the
ability to send and receive frames with a CW.
- If the PEs at both ends of a PW set the C-bit, CWs MUST be used in
both directions of the PW.
- If both PEs send a C-bit of 0, CWs MUST NOT be used on the PW.
These two cases behave as before.
However, if the PEs at both ends of the PW do not agree on the
setting of the C-bit, CWs MUST NOT be used in either direction on
that PW, but the PW MUST NOT be prevented from coming up due to this
mismatch. So, the PW will still come up but will not use the CW in
either direction. This behavior is changed from the behavior
described in [<a href="./rfc4761" title=""Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling"">RFC4761</a>] where the PW does not come up.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Sequence Flag (S-Bit)</span>
If a PE sets the S-bit in its NLRI, it means that the PE has the
ability to set sequence numbers as described in <a href="./rfc4385#section-4.1">Section 4.1 in
[RFC4385]</a> and process sequence numbers as described in <a href="./rfc4385#section-4.2">Section 4.2 in
[RFC4385]</a>.
- If the PEs at both ends of a PW set the S-bit, non-zero sequence
numbers MUST be used in both directions of the PW.
- If both PEs send an S-bit of 0, sequence numbers MUST NOT be used
on the PW.
These two cases behave as before.
[<a id="ref-RFC4761">RFC4761</a>] does not allow for the S-bit setting to be negotiated
either. In a typical implementation, if the PE sets the S-bit in the
advertised NLRI, it expects to receive VPLS frames with non-zero
sequence numbers and will send outgoing frames over the PW with
non-zero sequence numbers.
This memo further specifies the expected behavior when the PEs at the
ends of the PW advertise differing S-bit values. If the PEs at both
ends of the PW do not agree on the setting of the S-bit, then the PW
SHOULD NOT come up. This is to avoid running into out-of-sequence
ordering scenarios when the multiple PEs that are enabling
multihoming for a site have differing S-bit advertisements as
described in <a href="./rfc4385#section-4.2">Section 4.2 in [RFC4385]</a>. However, if a deployment is
known to not utilize multihoming, a user-configurable way to override
<span class="grey">Singh, 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="./rfc8614">RFC 8614</a> Control Flags for BGP VPLS June 2019</span>
this recommendation MAY be provided by an implementation whereby the
PW is allowed to come up. In that case, the PE advertising the S-bit
as 0 should set sequence numbers in the frames as 0, and the PW
receiving the frames should not expect to receive non-zero sequence
numbers.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Using Point-to-Multipoint (P2MP) LSPs as Transport for BGP VPLS</span>
BGP VPLS can be used over point-to-point Label Switched Paths (LSPs)
acting as transport between the VPLS PEs. Alternately, BGP VPLS may
also be used over Point-to-Multipoint (P2MP) LSPs with the source of
the P2MP LSP rooted at the PE advertising the VPLS BGP NLRI.
In a network that uses P2MP LSPs as transport for a VPLS, there may
be some PEs that support the CW while others may not. The behavior
is similar for the sequencing of VPLS frames.
In such a setup, a source PE that supports CW should set up two
different P2MP LSPs such that:
- One P2MP LSP will transport CW-marked frames to those PEs that
advertised the C-bit as 1.
- The other P2MP LSP will transport frames without the CW to those
PEs that advertised the C-bit as 0.
Using two different P2MP LSPs to deliver frames with and without the
CW to different PEs ensures that a P2MP root PE honors the C-bit
advertised by the other P2MP PEs.
However, the set of leaves on the two P2MP LSPs (rooted at the given
PE) MUST NOT contain any PEs that advertised a value for the S-bit
different from what the root PE itself is advertising. PEs that
advertised their S-bit values differently (from what the P2MP root PE
advertised) will not be on either of the P2MP LSPs. This ensures
that the P2MP root PE is sending VPLS frames only to those PEs that
agree on the setting of the S-bit.
The ingress router for the P2MP LSP should send separate NLRIs for
the cases of using the CW and for not using the CW.
<span class="grey">Singh, 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="./rfc8614">RFC 8614</a> Control Flags for BGP VPLS June 2019</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Illustrative Diagram</span>
-----
/ A1 \
---- ____CE1 |
/ \ -------- -------- / | |
| A2 CE2- / \ / PE1 \ /
\ / \ / \___/ | \ -----
---- ---PE2 | \
| | \ -----
| Service Provider Network | \ / \
| | CE5 A5
| ___ | / \ /
\ / \ PE4_/ -----
PE3 / \ /
|------/ \------- -------
---- / | ----
/ \/ \ / \ CE = Customer Edge Device
| A3 CE3 --CE4 A4 | PE = Provider Edge Router
\ / \ /
---- ---- A<n> = Customer site n
Figure 1: Example of a VPLS
In the above topology, let there be a VPLS configured with the PEs as
displayed. Let PE1 be the PE under consideration that is CW enabled
and sequencing enabled. Let PE2 and PE3 also be CW enabled and
sequencing enabled. Let PE4 not be CW enabled or have the ability to
include sequence numbers. PE1 will advertise a VPLS BGP NLRI,
containing the C/S-bits marked as 1. PE2 and PE3, on learning of the
NLRI from PE1, will include the CW and non-zero sequence numbers in
the VPLS frames being forwarded to PE1 as described in <a href="./rfc4385#section-4">Section 4 in
[RFC4385]</a>. However, PE4, which does not have the ability to include
a CW or include non-zero sequence numbers, will not.
As per [<a href="./rfc4761" title=""Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling"">RFC4761</a>], PE1 would expect all other PEs to forward
CW-containing frames that have non-zero sequence numbers. That
expectation cannot be met by PE4 in this example. Thus, as per
[<a href="./rfc4761" title=""Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling"">RFC4761</a>], the PW between PE1 and PE4 does not come up.
However, this document addresses how an implementation should support
BGP VPLS in a network where a subset of the BGP VPLS PEs support the
CW and/or frame sequencing. PE1 will not bring up the PW with PE4
due to the S-bit mismatch, unless overridden by local configuration
on PE1 and PE4 as specified in <a href="#section-3.2">Section 3.2</a>. If PE4 instead was to
advertise a C-bit of 0 and an S-bit of 1, then the PW between PE1 and
PE4 would come up despite the CW mismatch. Additionally, PE1 would
set up its data plane such that it will strip the CW only for those
<span class="grey">Singh, 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="./rfc8614">RFC 8614</a> Control Flags for BGP VPLS June 2019</span>
VPLS frames that are received from PEs that have indicated their
desire to receive CW-marked frames. So, PE1 will set up its data
plane to strip the CW only for VPLS frames received from PE2 and PE3,
and it will expect to process PW frames containing non-zero sequence
numbers as described in <a href="./rfc4385#section-4.2">Section 4.2 in [RFC4385]</a>. PE1 will set up
its data plane to not strip the CW from frames received from PE4, and
it would expect PE4 to send frames with non-zero sequence numbers.
All frames sent by PE4 to PE1 over the PW would have a non-zero
sequence number.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Treatment of C-Bits and S-Bits in Multihoming Scenarios</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Control Word (C-Bit)</span>
In a multihomed environment, different PEs may effectively represent
the same service destination endpoint. It could be assumed that the
end-to-end PW establishment process should follow the same rules when
it comes to CW requirements, meaning that setting the C-bit would be
enforced equally toward both primary and backup designated
forwarders.
However, in the multihoming case, each PW SHOULD be evaluated
independently. Assuming the network topology specified in <a href="#section-5">Section 5</a>,
there could be the case where the PW between PE2 and PE1 could have
the CW signaled via the extended community and would be used in the
VPLS frame, while the PE2-to-PE4 PW would not insert the CW in the
VPLS frame due to a C-bit mismatch. The multihoming behavior of the
rest of the PEs should simply follow the rules specified in
[<a href="#ref-VPLS-MULTIHOMING">VPLS-MULTIHOMING</a>].
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Sequence Flag (S-Bit)</span>
In a multihomed environment, different PEs may effectively represent
the same service destination endpoint. In this case, the rules for
end-to-end PW establishment SHOULD follow the same behavior as that
described in <a href="#section-3.2">Section 3.2</a> when it comes to S-bit requirements.
Consider the case described in <a href="#section-5">Section 5</a> with CE5 having a connection
to multiple PEs (multihomed) to PE4 and PE1. The PW's behavior is
similar to that for the CW scenario such that the S-bit evaluation
SHOULD be independent per PW. So, in the case where PE4 does not set
the S-bit in its advertised NLRI, there is an S-bit mismatch between
PE1 and PE4. This mismatch prevents the PW establishment between PE1
and PE4. So, only one PW -- between PE1 and PE2 -- would be
established for the multihomed site shown. Thus, even though CE5 is
physically multihomed, due to PE4's lack of support for sending
frames with non-zero sequence numbers, there would be no PW between
PE2 and PE4. CE5 would effectively not be multihomed.
<span class="grey">Singh, 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="./rfc8614">RFC 8614</a> Control Flags for BGP VPLS June 2019</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
This document updates the behavior specified in [<a href="./rfc4761" title=""Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling"">RFC4761</a>]. The
security considerations discussed in [<a href="./rfc4761" title=""Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling"">RFC4761</a>] apply. This document
essentially addresses BGP VPLS behavior for PEs when the C-bit value,
the S-bit value, or both values advertised by a given PE are
different from what another PE in the VPLS is advertising. Any
bit-flipping media errors leading to causing this mismatch of
C/S-bits between PEs do not adversely affect the availability of the
PWs. Rather, they cause CWs to not be used or cause the
NLRI-advertising PE to not expect non-zero sequenced frames, for the
C-bit and the S-bit, respectively, being mismatched across PEs. This
is no worse than the previous behavior where any bit-flipping media
errors leading to a mismatch of the C/S-bits between PEs would cause
the PW to not come up.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
This document has no IANA actions.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC4761">RFC4761</a>] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", <a href="./rfc4761">RFC 4761</a>, DOI 10.17487/RFC4761, January 2007,
<<a href="https://www.rfc-editor.org/info/rfc4761">https://www.rfc-editor.org/info/rfc4761</a>>.
[<a id="ref-RFC4385">RFC4385</a>] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", <a href="./rfc4385">RFC 4385</a>, DOI 10.17487/RFC4385,
February 2006, <<a href="https://www.rfc-editor.org/info/rfc4385">https://www.rfc-editor.org/info/rfc4385</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>>.
<span class="grey">Singh, 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="./rfc8614">RFC 8614</a> Control Flags for BGP VPLS June 2019</span>
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-RFC3985">RFC3985</a>] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", <a href="./rfc3985">RFC 3985</a>,
DOI 10.17487/RFC3985, March 2005,
<<a href="https://www.rfc-editor.org/info/rfc3985">https://www.rfc-editor.org/info/rfc3985</a>>.
[<a id="ref-VPLS-MULTIHOMING">VPLS-MULTIHOMING</a>]
Kothari, B., Kompella, K., Henderickx, W., Balus, F.,
and J. Uttaro, "BGP based Multi-homing in Virtual
Private LAN Service", Work in Progress,
<a href="./draft-ietf-bess-vpls-multihoming-03">draft-ietf-bess-vpls-multihoming-03</a>, March 2019.
Authors' Addresses
Ravi Singh
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: ravis@juniper.net
Kireeti Kompella
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: kireeti@juniper.net
Senad Palislamovic
Nokia
600 Mountain Avenue
Murray Hill, NJ 07974-0636
United States of America
Email: Senad.palislamovic@nokia.com
Singh, et al. Standards Track [Page 9]
</pre>
|
