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
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
|
<pre>Network Working Group L. Berger
Request for Comment: 5523 LabN Consulting, LLC
Category: Experimental April 2009
<span class="h1">OSPFv3-Based Layer 1 VPN Auto-Discovery</span>
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document defines an OSPFv3-based (Open Shortest Path First
version 3) Layer 1 Virtual Private Network (L1VPN) auto-discovery
mechanism. This document parallels the existing OSPF version 2 L1VPN
auto-discovery mechanism. The notable functional difference is the
support of IPv6.
<span class="grey">Berger Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5523">RFC 5523</a> OSPV3-Based Layer 1 VPN Auto-Discovery April 2009</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-2">2</a>
<a href="#section-1.2">1.2</a>. Conventions Used in This Document ..........................<a href="#page-3">3</a>
<a href="#section-1.3">1.3</a>. Overview ...................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. OSPFv3 L1VPN LSA and Its TLVs ...................................<a href="#page-5">5</a>
<a href="#section-2.1">2.1</a>. OSPFv3 L1VPN LSA ...........................................<a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. L1VPN IPv6 INFO TLV ........................................<a href="#page-7">7</a>
<a href="#section-3">3</a>. OSPFv3 L1VPN LSA Advertising and Processing .....................<a href="#page-8">8</a>
<a href="#section-4">4</a>. Backward Compatibility ..........................................<a href="#page-9">9</a>
<a href="#section-5">5</a>. Manageability Considerations ....................................<a href="#page-9">9</a>
<a href="#section-5.1">5.1</a>. Coexistence with and Migration from OSPFv2 .................<a href="#page-9">9</a>
<a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-10">10</a>
<a href="#section-7">7</a>. IANA Considerations ............................................<a href="#page-11">11</a>
<a href="#section-8">8</a>. Acknowledgment .................................................<a href="#page-11">11</a>
<a href="#section-9">9</a>. References .....................................................<a href="#page-11">11</a>
<a href="#section-9.1">9.1</a>. Normative References ......................................<a href="#page-11">11</a>
<a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-12">12</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document defines an OSPFv3-based (Open Shortest Path First
version 3) Layer 1 Virtual Private Network (L1VPN) auto-discovery
mechanism. This document parallels the existing OSPF version 2 L1VPN
auto-discovery mechanism. The notable functional difference is the
support of IPv6.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
The reader of this document should be familiar with the terms used in
[<a href="./rfc4847" title=""Framework and Requirements for Layer 1 Virtual Private Networks"">RFC4847</a>] and [<a href="./rfc5251" title=""Layer 1 VPN Basic Mode"">RFC5251</a>]. The reader of this document should also be
familiar with [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>], [<a href="./rfc5329" title=""Traffic Engineering Extensions to OSPF Version 3"">RFC5329</a>], and [<a href="./rfc5252" title=""OSPF-Based Layer 1 VPN Auto-Discovery"">RFC5252</a>]. In particular,
the following terms:
L1VPN Layer 1 Virtual Private Network
CE Customer (edge) network element directly connected to the
Provider network (terminates one or more links to one or
more PEs); it is also connected to one or more Cs and/or
other CEs.
C Customer network element that is not connected to the
Provider network but is connected to one or more other Cs
and/or CEs.
<span class="grey">Berger Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5523">RFC 5523</a> OSPV3-Based Layer 1 VPN Auto-Discovery April 2009</span>
PE Provider (edge) network element directly connected to one
or more Customer networks (terminates one or more links to
one or more CEs associated with the same or different
L1VPNs); it is also connected to one or more Ps and/or
other PEs.
P Provider (core) network element that is not directly
connected to any of Customer networks; P is connected to
one or more other Ps and/or PEs.
LSA OSPF Link State Advertisement.
LSDB Link State Database: a data structure supported by an IGP
speaker.
PIT Port Information Table.
CPI Customer Port Identifier.
PPI Provider Port Identifier.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Conventions Used in This Document</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>].
<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>. Overview</span>
The framework for Layer 1 VPNs is described in [<a href="./rfc4847" title=""Framework and Requirements for Layer 1 Virtual Private Networks"">RFC4847</a>]. Basic mode
operation is further defined in [<a href="./rfc5251" title=""Layer 1 VPN Basic Mode"">RFC5251</a>]. [<a href="./rfc5251" title=""Layer 1 VPN Basic Mode"">RFC5251</a>] identifies the
information that is necessary to map customer information (port
identifiers) to provider information (identifiers). It also states
that this mapping information may be provided via provisioning or via
an auto-discovery mechanism. [<a href="./rfc5252" title=""OSPF-Based Layer 1 VPN Auto-Discovery"">RFC5252</a>] provides such an auto-
discovery mechanism using Open Shortest Path First (OSPF) version 2.
This document provides the same functionality using OSPF version 3
and adds support for IPv6.
Figure 1 shows the L1VPN basic service being supported using OSPF-
based L1VPN auto-discovery. This figure shows two PE routers
interconnected over a GMPLS backbone. Each PE is attached to three
CE devices belonging to three different Layer 1 VPNs. In this
network, OSPF is used to provide the VPN membership, port mapping,
and related information required to support basic mode operation.
<span class="grey">Berger Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5523">RFC 5523</a> OSPV3-Based Layer 1 VPN Auto-Discovery April 2009</span>
PE PE
+---------+ +--------------+
+--------+ | +------+| | +----------+ | +--------+
| VPN-A | | |VPN-A || | | VPN-A | | | VPN-A |
| CE1 |--| |PIT || OSPF LSAs | | PIT | |-| CE2 |
+--------+ | | ||<----------->| | | | +--------+
| +------+| Distribution| +----------+ |
| | | |
+--------+ | +------+| | +----------+ | +--------+
| VPN-B | | |VPN-B || ------- | | VPN-B | | | VPN-B |
| CE1 |--| |PIT ||--( GMPLS )--| | PIT | |-| CE2 |
+--------+ | | || (Backbone) | | | | +--------+
| +------+| -------- | +----------+ |
| | | |
+--------+ | +-----+ | | +----------+ | +--------+
| VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C |
| CE1 |--| |PIT | | | | PIT | |-| CE2 |
+--------+ | | | | | | | | +--------+
| +-----+ | | +----------+ |
+---------+ +--------------+
Figure 1: OSPF Auto-Discovery for L1VPNs
The approach used in this document to provide OSPFv3-based L1VPN
auto-discovery uses a new type of Link State Advertisement (LSA),
which is referred to as an OSPFv3 L1VPN LSA. The OSPFv3 L1VPN LSA
carries information in TLV (type, length, value) structures. An
L1VPN-specific TLV is defined below to propagate VPN membership and
port information. This TLV is referred to as the L1VPN Info TLV.
The OSPFv3 L1VPN LSA may also carry Traffic Engineering (TE) TLVs;
see [<a href="./rfc3630" title=""Traffic Engineering (TE) Extensions to OSPF Version 2"">RFC3630</a>], [<a href="./rfc4203" title=""OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4203</a>], and [<a href="./rfc5329" title=""Traffic Engineering Extensions to OSPF Version 3"">RFC5329</a>].
<span class="grey">Berger Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5523">RFC 5523</a> OSPV3-Based Layer 1 VPN Auto-Discovery April 2009</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. OSPFv3 L1VPN LSA and Its TLVs</span>
This section defines the OSPFv3 L1VPN LSA and its TLVs.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. OSPFv3 L1VPN LSA</span>
The format of a OSPFv3 L1VPN LSA is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L1VPN Info TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Link TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LS age
As defined in [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>].
LS type
As defined in [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>]. The U-bit MUST be set to 1, and the S1
and S2 bits MUST be set to indicate either area or Autonomous
System (AS) scoping. The LSA Function Code portion of this field
MUST be set to 14, i.e., the OSPFv3 L1VPN LSA.
Advertising Router
As defined in [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>].
LS Sequence Number
As defined in [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>].
<span class="grey">Berger Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5523">RFC 5523</a> OSPV3-Based Layer 1 VPN Auto-Discovery April 2009</span>
LS checksum
As defined in [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>].
Length
As defined in [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>].
L1VPN Info TLV
A single L1VPN Info TLV, as defined in <a href="./rfc5252#section-2.2">Section 2.2 of [RFC5252]</a> or
<a href="#section-2.2">Section 2.2</a> of this document, MUST be present. If more than one
L1VPN Info TLV is present, only the first TLV is processed and the
others MUST be ignored on receipt. If no L1VPN Info TLV is
present, the LSA is processed (and flooded) as normal, but the
L1VPN PIT table MUST NOT be modified in any way.
TE Link TLV
A single TE Link TLV MAY be included in an OSPFv3 L1VPN LSA. When
an L1VPN IPv4 Info TLV is present, a single TE Link TLV as defined
in [<a href="./rfc3630" title=""Traffic Engineering (TE) Extensions to OSPF Version 2"">RFC3630</a>] and [<a href="./rfc4203" title=""OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4203</a>] MAY be included. When an L1VPN IPv6
Info TLV is present, a single TE Link TLV as defined in [<a href="./rfc5329" title=""Traffic Engineering Extensions to OSPF Version 3"">RFC5329</a>]
MAY be included.
<span class="grey">Berger Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5523">RFC 5523</a> OSPV3-Based Layer 1 VPN Auto-Discovery April 2009</span>
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. L1VPN IPv6 INFO TLV</span>
The following TLV is introduced:
Name: L1VPN IPv6 Info
Type: 32768
Length: Variable
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L1VPN TLV Type | L1VPN TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L1VPN Globally Unique Identifier |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE TE Address |
| ... |
| ... |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-Local Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| L1VPN Auto-Discovery Information |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .| Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L1VPN TLV Type
The type of the TLV (see above).
TLV Length
The length of the TLV in bytes, excluding the four (4) bytes of
the TLV header and, if present, the length of the Padding field.
L1VPN Globally Unique Identifier
As defined in [<a href="./rfc5251" title=""Layer 1 VPN Basic Mode"">RFC5251</a>].
PE TE Address
This field MUST carry an address that has been advertised by the
LSA originator per [<a href="./rfc5329" title=""Traffic Engineering Extensions to OSPF Version 3"">RFC5329</a>] and is either the Router IPv6 Address
TLV or Local Interface IPv6 Address link sub-TLV. It will
typically carry the TE Router Address.
<span class="grey">Berger Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5523">RFC 5523</a> OSPV3-Based Layer 1 VPN Auto-Discovery April 2009</span>
Link-Local Identifier
This field is used to support unnumbered links. When an
unnumbered PE TE link is represented, this field MUST contain a
value advertised by the LSA originator per [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>] in a Router
LSA. When a numbered link is represented, this field MUST be set
to zero (0).
L1VPN Auto-Discovery Information
As defined in [<a href="./rfc5251" title=""Layer 1 VPN Basic Mode"">RFC5251</a>].
Padding
A field of variable length and of sufficient size to ensure that
the TLV is aligned on a 4-byte boundary. This field is only
required when the L1VPN Auto-Discovery Information field is not
4-byte aligned. This field MUST be less than 4 bytes long, and
MUST NOT be present when the size of L1VPN Auto-Discovery
Information field is 4-byte aligned.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. OSPFv3 L1VPN LSA Advertising and Processing</span>
PEs advertise local <CPI, PPI> tuples in OSPFv3 L1VPN LSAs containing
L1VPN Info TLVs. Each PE MUST originate a separate OSPFv3 L1VPN LSA
with area or AS flooding scope, based on configuration, for each
local CE-PE link. The LSA MUST be originated each time a PE restarts
and every time there is a change in the PIT entry associated with a
local CE-PE link. The LSA MUST include a single L1VPN Info TLV and
MAY include a single TE Link TLV. The TE Link TLV carries TE
attributes of the associated CE-PE link. Note that because CEs are
outside of the provider TE domain, the attributes of CE-PE links are
not advertised via normal OSPF-TE procedures as described in
[<a href="./rfc5329" title=""Traffic Engineering Extensions to OSPF Version 3"">RFC5329</a>]. If more than one L1VPN Info TLVs and/or TE Link TLVs are
found in the LSA, the subsequent TLVs SHOULD be ignored by the
receiving PEs.
Every time a PE receives a new, removed, or modified OSPFv3 L1VPN
LSA, the PE MUST check whether it maintains a PIT associated with the
L1VPN specified in the L1VPN Globally Unique Identifier field. If
this is the case (the appropriate PIT will be found if one or more
local CE-PE links that belong to the L1VPN are configured), the PE
SHOULD add, remove, or modify the PIT entry associated with each of
the advertised CE-PE links accordingly. (An implementation MAY
choose to not remove or modify the PIT according to local policy or
management directives.) Thus, in the normal steady-state case, all
PEs associated with a particular L1VPN will have identical local PITs
for an L1VPN.
<span class="grey">Berger Experimental [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5523">RFC 5523</a> OSPV3-Based Layer 1 VPN Auto-Discovery April 2009</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Backward Compatibility</span>
Neither the TLV nor the LSA introduced in this document present any
interoperability issues. Per [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>], and due to the U-bit being
set, OSPFv3 speakers that do not support the OSPFv3 L1VPN LSA (Ps for
example) just participate in the LSA's flooding process but should
ignore the LSA's contents.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Manageability Considerations</span>
The principal concern in operating an auto-discovery mechanism for an
L1VPN is that the PE needs to be configured with information about
which VPNs it supports. This information can be discovered from the
CEs using some form of membership negotiation, but is more likely to
be directly configured by the operator as described in [<a href="./rfc4847" title=""Framework and Requirements for Layer 1 Virtual Private Networks"">RFC4847</a>],
[<a href="./rfc5251" title=""Layer 1 VPN Basic Mode"">RFC5251</a>], and [<a href="./rfc5253" title=""Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode"">RFC5253</a>]. No standardized mechanisms to configure
this information have been defined, and it is a matter for individual
implementations with input from operator policy how a PE is told
which L1VPNs it supports. It is probable that configuration of this
information is closely tied to the configuration of CE-facing ports
on the PE, which in turn causes PITs to be established in the PE.
Additionally, it may be of value to an operator to view the L1VPN
membership information that has been learned by a PE. An
implementation may supply this information through a proprietary
interface, or may allow it to be inspected through the OSPFv3 MIB
module [<a href="#ref-OSPFv3-MIB" title=""Management Information Base for OSPFv3"">OSPFv3-MIB</a>] or the Traffic Engineering Database MIB
[<a href="#ref-TED-MIB" title=""Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS"">TED-MIB</a>].
Note that the operation of the control plane has no impact on IP
network traffic because all of the user data is in Layer 1, while the
control plane is necessarily out of band in a Data Communications
Network (DCN).
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Coexistence with and Migration from OSPFv2</span>
It is expected that only a single routing protocol instance will be
used to operate auto-discovery within an L1VPN at any time. Thus,
coexistence issues only apply to the migration from OSPFv2 to OSPFv3
and can be expected to be transient.
Migration from OSPFv2 to OSPFv3 would be a once-only event for any
network and would probably depend on the migration of the routing
protocol used within the network for normal GMPLS procedures. The
migration process would not be any different from the process used to
migrate the normal GMPLS routing protocol. The steps to follow are
<span class="grey">Berger Experimental [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5523">RFC 5523</a> OSPV3-Based Layer 1 VPN Auto-Discovery April 2009</span>
clearly a matter for the operator of the network and are not a matter
for standardization, but the following sequence is provided to
illustrate the potential actions:
1. Assign IPv6 addresses to all control plane and data plane
resources.
2. Install and enable OSPFv3 on all controllers.
3. Use OSPFv3 to advertise IPv4 and IPv6 resource identifiers.
4. Manually verify the advertised membership and topology information
from the OSPFv2 and OSPFv3 databases.
5. Start a maintenance window where data continues to flow, but no
L1VPN connections can be changed.
6. Cut over to the OSPFv3 membership and topology information.
7. Close the maintenance window.
8. Turn off OSPFv2.
9. Remove/disable the IPv4 address for all control plane and data
plane resources.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
The approach presented in this document describes how PEs dynamically
learn L1VPN specific information. Mechanisms to deliver the VPN
membership information to CEs are explicitly out of scope of this
document. Therefore, the security issues raised in this document are
limited to within the OSPF domain.
This defined approach reuses mechanisms defined in [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>].
Therefore, the same security approaches and considerations apply to
this approach. OSPF provides several security mechanisms that can be
applied. Specifically, OSPF supports multiple types of
authentication, limits the frequency of LSA origination and
acceptance, and provides techniques to avoid and limit the impact of
database overflow. In cases were end-to-end authentication is
desired, OSPF's neighbor-to-neighbor authentication approach can be
augmented with an approach similar to the experimental extension to
OSPF, see [<a href="./rfc2154" title=""OSPF with Digital Signatures"">RFC2154</a>], which supports the signing and authentication of
LSAs.
<span class="grey">Berger Experimental [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5523">RFC 5523</a> OSPV3-Based Layer 1 VPN Auto-Discovery April 2009</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
IANA has assigned an OSPFv3 LSA Function Code as described in <a href="#section-2.1">Section</a>
<a href="#section-2.1">2.1</a> of this document. IANA has made an assignment in the form:
Value OSPFv3 LSA type function Type Reference
------- ----------------------------- ---------
14 OSPFv3 L1VPN LSA [<a href="./rfc5523">RFC5523</a>]
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgment</span>
This document was created at the request of Pasi Eronen. Adrian
Farrel and Acee Lindem provided valuable reviews of this document.
Adrian also provided the text for <a href="#section-5">Section 5</a>.
<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>, March 1997.
[<a id="ref-RFC5340">RFC5340</a>] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", <a href="./rfc5340">RFC 5340</a>, July 2008.
[<a id="ref-RFC3630">RFC3630</a>] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", <a href="./rfc3630">RFC</a>
<a href="./rfc3630">3630</a>, September 2003.
[<a id="ref-RFC4203">RFC4203</a>] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", <a href="./rfc4203">RFC 4203</a>, October 2005.
[<a id="ref-RFC5251">RFC5251</a>] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D.,
Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", <a href="./rfc5251">RFC</a>
<a href="./rfc5251">5251</a>, July 2008.
[<a id="ref-RFC5252">RFC5252</a>] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN
Auto-Discovery", <a href="./rfc5252">RFC 5252</a>, July 2008.
[<a id="ref-RFC5329">RFC5329</a>] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3", <a href="./rfc5329">RFC</a>
<a href="./rfc5329">5329</a>, September 2008.
<span class="grey">Berger Experimental [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5523">RFC 5523</a> OSPV3-Based Layer 1 VPN Auto-Discovery April 2009</span>
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-OSPFv3-MIB">OSPFv3-MIB</a>] Joyal, D., Ed. and V. Manral, Ed., "Management
Information Base for OSPFv3", Work in Progress, November
2008.
[<a id="ref-RFC2154">RFC2154</a>] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", <a href="./rfc2154">RFC 2154</a>, June 1997.
[<a id="ref-RFC4847">RFC4847</a>] Takeda, T., Ed., "Framework and Requirements for Layer 1
Virtual Private Networks", <a href="./rfc4847">RFC 4847</a>, April 2007.
[<a id="ref-RFC5253">RFC5253</a>] Takeda, T., Ed., "Applicability Statement for Layer 1
Virtual Private Network (L1VPN) Basic Mode", <a href="./rfc5253">RFC 5253</a>,
July 2008.
[<a id="ref-TED-MIB">TED-MIB</a>] Miyazawa, M., Otani, T., Nadeau, T., and K. Kumaki,
"Traffic Engineering Database Management Information
Base in support of MPLS-TE/GMPLS", Work in Progress,
January 2009.
Author's Address
Lou Berger
LabN Consulting, LLC
EMail: lberger@labn.net
Berger Experimental [Page 12]
</pre>
|
