-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-szarecki-idr-bgp-lcu-traffic-steering-00.xml
658 lines (590 loc) · 51.5 KB
/
draft-szarecki-idr-bgp-lcu-traffic-steering-00.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
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
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3032 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3032.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC4760 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4760.xml">
<!ENTITY RFC2545 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2545.xml">
<!ENTITY RFC5549 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5549.xml">
<!ENTITY RFC8277 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8277.xml">
<!ENTITY RFC8402 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8402.xml">
<!ENTITY RFC2475 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2475.xml">
<!ENTITY RFC5575 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5575.xml">
<!ENTITY RFC7606 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7606.xml">
<!ENTITY RFC7811 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7811.xml">
<!ENTITY RFC7911 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7911.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY SR-POL SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.draft-ietf-spring-segment-routing-policy-03.xml">
<!ENTITY TUN-ENCAP SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.draft-ietf-idr-tunnel-encaps-12.xml">
<!ENTITY FlexAlgo SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.draft-ietf-lsr-flex-algo-03.xml">
<!ENTITY S-MPLS SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.draft-ietf-mpls-seamless-mpls-07.xml">
<!ENTITY P-SID SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.draft-ietf-idr-bgp-prefix-sid-27.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-szarecki-idr-bgp-lcu-traffic-steering-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Inter-Domain Traffic Steering with BGP-LCU">Inter-Domain Traffic Steering with BGP Labeled Colored Unicast (BGP-LCU)</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Louis Chan" initials="L.C."
surname="Chan">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>Cityplaza One, 1111 King's Road</street>
<!-- Reorder these if your country does things differently -->
<city>Taikoo Shing</city>
<region></region>
<code></code>
<country>Hong Kong</country>
</postal>
<phone>+8522587665</phone>
<email>[email protected]</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Rafal J. Szarecki" initials="R.S." role="editor"
surname="Szarecki">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1133 Innovation Way</street>
<!-- Reorder these if your country does things differently -->
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>United States of America</country>
</postal>
<phone>+14089365629</phone>
<email>[email protected]</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2019" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>IDR Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>BGP, BGP-LCU, labeled-colored-unicast, network slicing</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document describes technology that enables for Inter-Domain signaling of existence of E2E path that satisfy high-level traffic treatment behavior intent. The inter-domain path is built by the BGP protocol, as a concatenation of per TE-domain internal paths (segments), provisioned by one of existing intra-domain techniques. The traffic treatment behavior is encoded as an integer value called as "COLOR". The domain internal paths/tunnels are marked as satisfying given traffic treatment behavior. Then the tunnel destination and its COLOR are exchanged between TE-Domains using a new BGP LABELED-COLORED-UNICAST NLRI (BGP-LCU) defined in this document.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The networks of today grow to high 10,000's - 100,000's of nodes (routers) and beyond. This trend continues. To operate such a large topology, the common practice is to divide it into domains (see <xref target="fig_1"></xref>) and integrate through layered routing protocol infrastructure in order to secure end-to-end (E2E) connectivity. Please see <xref target="I-D.ietf-mpls-seamless-mpls"/>.</t>
<t>The nowadays critical and demanding applications rely on network infrastructure, and plain connectivity becomes an insufficient service level.</t>
<t>While the Differentiated Services architecture <xref target="RFC2475"/> allows for multiple service levels across same connectivity path, it does not address topological differentiation such as latency, non-fate-sharing, encryption or bandwidth. These challenges are addressed by existing Traffic Engineering (TE)techniques such RSVP, SR-TE or multi-topology IGPs (e.g. Maximally Redundant Tree <xref target="RFC7811"/>, Segment Routing IGP FlexAlgo <xref target="I-D.ietf-lsr-flex-algo"/>)in the scope of a limited size domain (TE-DOMAIN). </t>
<t>This document describes technology that enables signaling of existence of E2E path that satisfy high-level traffic treatment behavior intent. The inter-domain path is built by the BGP protocol, as a concatenation of per TE-domain internal paths (segments), provisioned by one of existing intra-domain techniques mentioned above. This way, inter-domain paths for a variety of traffic treatment intents are established without even need to expose the topology of any domain to any of the other domains. </t>
<figure align="center" anchor="fig_1">
<artwork align="left"><![CDATA[
BGP
<-----------><-----------><--><--------->
+-----------+ +----------+ +---------+
|domain 1 | | domain 2|----|domain 3 |
|(e.g. .-. (e.g.| /-| (e.g. |
|FlexAlgo) ( R ) RSVP)|-/ | SR-TE |
| `-' |----| w/ PCE) |
+-----------+ +----------+ +---------+
<---------> <---------> <--------->
TE-domain TE-domain TE-domain
<-------- cooperating domains ---------->
]]></artwork>
<postamble>Cooperating TE-domains</postamble>
</figure>
<t>The traffic treatment behavior (T-intent) is encoded as an integer value called as "COLOR". The TE-domain internal paths/tunnels are marked as satisfying given traffic treatment behavior as defined in Segment Routing Policy Architecture <xref target="I-D.ietf-spring-segment-routing-policy"/>. Then reachability of the tunnel destination and its COLOR are exchanged between TE-Domains using a new BGP LABELED-COLORED-UNICAST NLRI (BGP-LCU) defined in this document. The procedures of stitching/nesting intra domain tunnels advertised in BGP-LCU resulting in inter-domain E2E path is also specified in this document.</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Conventions used in this document">
<t>TE-DOMAIN - Continuous set of links and nodes that allow establishing tunnels that satisfy T-intent between each edge node without using BGP-LCU (defined in this document). Typically TE-domain is 1:1 mapped to IGP area (flooding domain),and intra-TE-domain tunnels are instantiated by RSVP (w/ or w/o assistance of PCE), SR/SRv6 w/ IGP FlexAlgo, static or PCE controlled SRTE/SRv6TE policies. A deployment when TE-domain comprises few connected IGP flooding domains is also possible.</t>
<t>COLOR - the integer value of 32bits representing given traffic treatment behavior intent (T-intent).</t>
<t>BGP-LCU - BGP Labeled Colored Unicast. Name given to SAFI(s) that carries traffic treatment intent toward destination system together with label(s)used to forward traffic across TE-DOMAINS. Defined in this document. </t>
<t><COLOR,DESTINATION> - colored BGP-LCU prefix, where COLOR is integer encoding traffic treatment intent and DESTINATION is IPv4 or IPv6 subnet address (not necessary host address).</t>
<t>[Label1,Label2,<COLOR,DESTINATION>] - notation used for the labeled colored unicast NLRI</t>
<t>SR-DOMAIN - continuous set of nodes and links that support SR and have at minimum single, shared prefix SID space. So, prefix SID (incl. Node SID and Anycast SID) values are unique in SR-DOMAIN.</t>
<t>BSID - Binding SID. The local label allocated for TE tunnel (RSVP-LSP, SR Policy, etc) </t>
</section>
<section title="Traffic treatment behavior intent (T-intent)">
<t>The service traffic, while traversing network(s) consumes resources from those networks. The path provided by network to service traffic could be optimized according to needs of the service. A simple example is a real-time communication application that would benefit from being placed on low-latency path. On the other hand, video streaming would best benefit from a low-loss path. Another example is sensitive data like personal health data, which would benefit from a taking path over encrypted links.</t>
<t>It is granted that ability of network to provide distinct path (tunnels) that satisfy treatment intended by application (or class of application) would provide best possible balance between application performance and network resource utilization.</t>
<t>The T-intent is high-level description of traffic treatment. Examples of T-intent are: "low-latency transport", "transport over encrypted infrastructure", "transport path that is topologically disjoined then other path", "transport path over encrypted links/segments", etc. It is up to the discretion of the network operator (or co-operating operators) to define a set of T-intents that have sense for them.</t>
<section title="COLOR">
<t>The T-intents defined by operator are encoded in control plane as 32-bit integer value called COLOR, in such way that color-to-T-intent mapping is of monotonic. Therefore, based on COLOR value the T-intent could be identified without ambiguity. The designation and mapping of COLOR value used for inter-domain operation to T-intent requires agreement of all operators of cooperating domains.</t>
<t> COLOR value of zero (0x00000000) is restricted and MUST NOT be used.</t>
</section>
<section title="COLOR name spaces">
<t>The concept of COLOR as defined above is not specific to inter-domain network slicing, and it actually was introduced in <xref target="I-D.ietf-spring-segment-routing-policy"/> and is used by SR-TE and SR IGP FlexAlgo (called there algorithm) in scope of single TE-domain.</t>
<t>Authors recognizes possibility that color-code values used inside given TE-domain may be not the same as agreed between TE-domains. Furthermore, it is possible that same color value is mapped to different T-intents inside TE-domain and for inter-TE-domain context.</t>
<t>It is recommended for network designers to adjust both color-code schemas to be identical in order to simplify operation. It is assumed in this specification, that color-code schema used for inter-TE-domain as well in each TE-domain is identical</t>
</section>
</section>
<section title="Scaling Consideration">
<t>The BGP-LCU path scale grow with product of number of COLORS supported by multi-domain network system and number of DESTINATIONS in this system. It become obvious that for some network there is a risk of exhausting available MPLS label space.</t>
<t>For large deployments, stacking of labels would be necessary to achieve desired scalability.</t>
</section>
<section title="BGP labeled-colored-unicast NLRI">
<t>This document defines new SAFI for labeled, colored, unicast (IPv4 and IPv6), and corresponding BGP NLRI that carries label(s) sequence binding to colored prefix - the <COLOR,DESTINATION> tuple. The SAFI value is [[TBD]].</t>
<t>For easy reading BGP instance/session supporting above new SAFI, we will reference it as "BGP-LCU" (Labeled-Colored-Unicast). </t>
<section title="BGP capability negotiation">
<t>In addition to AFI/SAFI negotiation on the opening of BGP session, in order to send NLRI with more than one label on stack the Multiple Labels Capability (MLC) MUST be successfully negotiated for the session in order to carry multiple label sequence in BGP-LCU NLRI. If MLC is not negotiated or negotiation failed, BGP-LCU NLRI MUST carry only one label.</t>
<t>The Multiple Labels Capability is defined in chapter 2.1 of BGP Labeled Unicast <xref target="RFC8277"/>. The BGP speaker supporting BGP-LCU MUST follow procedure defined there.</t>
<t>Implementation SHOULD send withdraw of <COLOR,DESTINATION> if length of labels sequence in (to be advertised) NLRI would exceed peers capability.</t>
</section>
<section title="BGP UPDATE message MP_REACH_NLRI">
<t>The procedure described in BGP Labeled Unicast<xref target="RFC8277"/> is used to encode the <COLOR,DESTINATION> tuple as prefix into NLRI with exception of NLRI length field. The Length field is encoded in one or two octets, in order to accommodate large sequence of labels. The Length field encoding follows BGP FlowSpec <xref target="RFC5575"/> encoding of length. </t>
<t>The <COLOR,DESTINATION> tuple form colored-IPv4 or colored-IPv6 prefix. The new sub-address family of SAFI [[TBD]] is allocated for labeled <COLOR,DESTINATION>. The AFI 1 and 2 are used for destination of IPv4 and IPv6 families respectively. The NLRI structure of SAFI [[TBD]] is shown below on <xref target="fig_2" /> for single label and <xref target="fig_3" /> for multiple labels (note: the color and destination elements of prefix are shown explicitly).</t>
<figure align="center" anchor="fig_2">
<artwork align="left"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Label |Rsrv |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| color |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble>NLRI with One Label.</postamble>
</figure>
<figure align="center" anchor="fig_3">
<artwork align="left"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length(1 or 2 octetx) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |Rsrv |S~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Label |Rsrv |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| color |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble>NLRI encoding with more then one label bind</postamble>
</figure>
<t><list style="symbols">
<t>Length: The Length field consists of a single or two octets. It specifies the length in bits of the remainder of the NLRI field. Note that for each label, the length is increased by 24 bits. The length of color is fixed and is always 32bits.
In an MP_REACH_NLRI attribute whose AFI/SAFI is 1/[[TBD]], the length of destination element of prefix will be 32 bits or less.
In an MP_REACH_NLRI attribute whose AFI/SAFI is 2/[[TBD]], the length of destination element of prefix will be 128 bits or less.
For NLRI shorter than 240 bits (30 octets) the Length is encoded is single octet. For NLRI of 240 bits or longer, two octets are used and the firs nibble is set to value 0xF. Therefore, maximum size of NLRI is 4095b.See <xref target="RFC5575"/>.
As specified in MP-BGP <xref target="RFC4760"/>, the actual length of the NLRI field will be the number of bits specified in the Length field rounded up to the nearest integral number of octets.</t>
<t>Label: The Label field is a 20-bit field containing an MPLS label value (see MPLS Label Encoding <xref target="RFC3032"/>). The null labels (values: 0, 2, 3) are allowed only as last label (or as only labels) in NLRI.</t>
<t>Rsrv: This 3-bit field SHOULD be set to zero on transmission and MUST be ignored on reception.</t>
<t>S: In all labels except the last (i.e., in all labels except the one immediately preceding the prefix), the S bit MUST be 0. In the last label, the S bit MUST be 1.
Note that failure to set the S bit in the last label will make it impossible to parse the NLRI correctly. See Section 3, paragraph j of Revised Error Handling for BGP UPDATE Messages <xref target="RFC7606"/> for a discussion of error handling when the NLRI cannot be parsed.</t>
</list>
</t>
<t>Note that the UPDATE message not only advertises the binding between the <COLOR,DESTINATION> and the label(s), it also advertises a path to the prefix via the node identified in the Next Hop field of the MP_REACH_NLRI attribute.</t>
<t>If the procedures of BGP ADD-PATHs <xref target="RFC7911"/> are being used, a four-octet "path identifier" (as defined in Section 3 of <xref target="RFC7911"/>) is part of the NLRI and precedes the Length field.</t>
</section>
<section title="BGP explicit WITHDRAWN message">
<t>The withdrawal methodology follows the one described in chapter 2.4 of <xref target="RFC8277"/>. For convenience short description is given below.</t>
<t>The label(s) binding to <COLOR,DESTINATION> could be explicitly withdrawn by sending BGP UPDATE message with MP_UNREACH_NLRI attribute. The NLRI field of MP_UNREACH_NLRI is encoded as follows:</t>
<figure align="center" anchor="fig_4">
<artwork align="left"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Compatibility |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| color |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble>NLRI for Withdrawal</postamble>
</figure>
<t>Where:</t>
<t><list style="symbols">
<t>Compatibility: Compatibility field SHOULD be set to 0x800000. Upon reception, the value of the Compatibility field MUST be ignored.</t>
</list></t>
<t>If the procedures of <xref target="RFC7911"/> are being used, a four-octet "path identifier" (as defined in Section 3 of <xref target="RFC7911"/>) is part of the NLRI and precedes the Length field.</t>
</section>
<section title="Some BGP attribute considerations">
<section title="BGP Next-Hop">
<t>The next-hop network address field in LABELED-COLORED-UNICAST SAFI updates may be either a IPv4 address or a IPv6 address(es) independent of the LABELED-COLORED-UNICAST AFI. This is in accordance to existing specfication in <xref target="RFC4760"/>, MP-BGP for IPv6<xref target="RFC2545"/> and IPv4 NLRI with IPv6 Next-Hop<xref target="RFC5549"/></t>
</section>
<section title="Prefix SID">
<t>In the deployment when multiple TE-domains forms single SR-domain, and therefore prefix SIDs (incl. Node SIDs and Anycast SIDs) are unique in entire multi-domain scope, BGP prefix SID attribute <xref target="I-D.ietf-idr-bgp-prefix-sid"/> may be attached to BGP-LCU NLRI, and SHOULD be honored.</t>
<t>Implementation SHOULD allow for disabling prefixSID processing by local configuration, and in such case tread this attribute as unsupported (therefore advertised without modification, since BGP prefix SID attribute is of transitive optional type). Implementation SHOULD allow, via local configuration, for removing BGP prefix SID attribute from BGP path.</t>
</section>
<section title="Color Extended Community">
<t>The Color Extended Community, defined in Tunnel Encapsulation Attribute<xref target="I-D.ietf-idr-tunnel-encaps"/>, MAY be attached to BGP-LCU NLRI.</t>
<t>The purpose of attaching this community is to provide a hint to BGP-LCU update receiver on how BGP Next-Hop attribute shall be resolved. Giving such hint could be useful e.g. for case when colors values used for given T-intent for inter-domain and intra-domain contexts are not equal (see chapter 3.2. ). Exact procedure to handle this case is out of scope of this specification.</t>
<t>In order to avoid ambiguity and simplify implementation, it is recommended to do not attach more than one Color Extended Community.</t>
</section>
<section title="Tunnel encapsulation ">
<t>The tunnel encapsulation attribute (23)<xref target="I-D.ietf-idr-tunnel-encaps"/> SHOULD NOT be attached to BGP-LCU NLRI.</t>
<t>If tunnel encapsulation attribute is attached, it MUST NOT conflict with intent of particular BGP path and its NLRI.</t>
<t>It is recommended for implementation to not process this attribute and pass it, if needed, as unsupported optional transitive attribute.</t>
</section>
</section>
</section>
<section title="BGP operation">
<section title="Injection of labeled colored unicast route to BGP">
<section title="Injecting from colored routes">
<t>The ingress border node (BN12)of given TE-domain (domain2 on <xref target="fig_5"/>)is provisioned by means out of scope of this document with multiple colored tunnels to endpoints in this domain. </t>
<figure align="center" anchor="fig_5">
<artwork align="left"><![CDATA[
+------------+ +----------------+ +---------+
| ++---+-+ domain 2 +-+---++ |
| | |----red---->| | |
| | BN12 |----blue--->| BN2n | |
| domain 1 | |--blue--+ | | |
| | |-red-+ | | | |
| ++---+-+ | | +-+---++ |
| | | v v | |domain N |
| | | +------+ | | |
+------------+ +-----+ PE2 +---+ +---------+
+------+
]]></artwork>
<postamble>Injection form colored routes</postamble>
</figure>
<t>The tunnel type is irrelevant for further discussion as long as MPLS frames can be encapsulated over it. Tunnels could be of MPLS, MPLS-SR, SRv6, MPLSoUDP, etc. Each of above tunnels has associated one or more intra-domain colors encoding traffic treatment provided by given tunnel, as per <xref target="I-D.ietf-spring-segment-routing-policy"/>. </t>
<t>The color-code schema used for Inter-domain is assumed to be the same as one used internally by TE-domain.</t>
<t>Let assume following color schema for domain 2, domain 1 and Inter-domain as shown in <xref target="table_1" />.</t>
<texttable anchor="table_1" title="COLOR code schema - intra- and inter-TE-domain">
<ttcol align="center"></ttcol>
<ttcol align="center">COLOR</ttcol>
<c>T-intent 1</c><c>red</c>
<c>T-intent 2</c><c>blue</c>
</texttable>
<t>The BGP speaker (BN12 in <xref target="fig_5"/> ) injects into BGP-LCU four routes with the NLRI fields and BGP attributes values as follow:</t>
<t><list style="symbols">
<t>NLRI DESTINATION := intra-domain tunnel destination IP prefix address (e.g. IP of loopback of BN2n and PE2 in <xref target="fig_5"/>).</t>
<t>NLRI COLOR := the color code value for T-intent the original tunnel satisfy inside given domain (e.g. red or blue).</t>
<t>Exactly one label of value derived according to procedure describe in chapter 6.6. In this case this label MUST be non-null label.</t>
<t>S:=1</t>
<t>Length := 56 + length of tunnel destination prefix</t>
<t>The BGP Next-Hop attribute is set to "self".</t>
</list></t>
<t>Other BGP attributes may also be added as needed by network configuration.</t>
<t>The BGP speaker may crates also MPLS forwarding entries for local label values advertised in NLRI of they do not exist previously.</t>
<t>Please note:</t>
<t><list style="symbols">
<t>This operation does not create any IP RIB entry nor <COLOR,DESTINATION> RIB entry.</t>
<t>This operation does not create any IP entry in FIB</t>
<t>This operation may create one or more MPLS entry in FIB if needed. The entry's key would be local label allocated as described in chapter 6.6. and advertised in NLRI. The associated action depends on tunnel type but could be generalized as popping label, pushing header(s) of tunnel given BGP route is originating form, forwarding trough egress interface of this tunnel.</t>
</list></t>
</section>
<section title="Injections from non-colored labeled routes">
<t>The injection of <COLOR,DESTINATION> into BGP from non-colored routes is similar to one from labeled colored routes, except there is no COLOR of original route to inherit. Therefore, local configuration MUST provide COLOR value that is used for NLRI construction. </t>
<t><list style="symbols">
<t>Implementation MUST support specification of one or more COLOR(s) that would be used for all DESTINATIONS when injected to BGP as LABELED-COLORED-UNICAST NLRI (of SAFI [[TBD]]). If multiple colors are specified, multiple NLRI is injected into BGP.</t>
<t>Implementation MAY support specification of COLOR in dependency on (original) route destination, attributes and/or session on which given <COLOR,DESTINATION> are injected to BGP as LABELED-COLORED-UNICAST NLRI (of SAFI [[TBD]].</t>
</list></t>
<t>Similarly, to case described in chapter 6.1.1. , label value MUST be non-null label.</t>
<t>Please note:</t>
<t><list style="symbols">
<t>This operation does not create any IP RIB entry nor <COLOR,DESTINATION> RIB entry.</t>
<t>This operation does not create any IP entry in FIB</t>
<t>This operation creates one or more MPLS entry in FIB. The entry's key would be local label allocated as described in chapter 6.6. and advertised in NLRI. The associated action depends on tunnel type but could be generalized as popping label, pushing header(s) of tunnel given BGP route is originating form, forwarding trough egress interface of this tunnel.</t>
</list></t>
</section>
<section title="Injections from non-colored non-labeled routes">
<t>The injection of <COLOR,DESTINATION> into BGP from non-labeled, non-colored routes is similar to one from labeled non-colored routes, except that explicit or implicit null label shall be used in advertisement.</t>
<t>Please note:</t>
<t><list style="symbols">
<t>This operation does not create any IP RIB entry nor <COLOR,DESTINATION> RIB entry.</t>
<t>This operation does not create any IP entry in FIB</t>
<t>This operation does not create any MPLS entry in FIB, since explicit null labels are already pre-programmed in FIB.</t>
</list></t>
</section>
</section>
<section title="Receiving BGP-LCU from eBGP (single hop)">
<t>The path for <COLOR,DESTINATION> received is experiencing normal BGP process - the sanity is checked first, then configured policies. Finally, path is installed in BGP Loc-RIB and path selection process kick in. Since BGP Next Hop attribute value is IP address of connected subnet, it is used w/o further processing (resolution).</t>
<t>Please note:</t>
<t><list style="symbols">
<t>This operation does create <COLOR,DESTINATION> entry in RIB.</t>
<t>This operation does not create any IP RIB entry.</t>
<t>This operation does not create any IP entry in FIB</t>
<t>This operation does not create any MPLS entry in FIB</t>
</list></t>
</section>
<section title="Receiving BGP-LCU from iBGP or multihop-eBGP">
<t>The path for <COLOR,DESTINATION> received is experiencing normal BGP process - the sanity is checked first, then configured policies. Finally, path is installed in BGP Loc-RIB and path selection process kick in. Since BGP Next Hop attribute value is not a IP address of connected subnet, it needs to be resolved. Since the intention is to provide continuous transport that satisfy T-intent encoded in COLOR, the intra-domain tunnel used for resolution need also satisfy this T-intent. Therefore:</t>
<t>
<list style="numbers">
<t>If BGP route for <COLOR,DESTINATION> is carrying Color Extended Community, The BGP NextHop attribute shall be resolved by tunnel of color carried in this community (which may be different then value of COLOR carried in NLRI. See chapter 3.2. above). Please see <xref target="I-D.ietf-spring-segment-routing-policy"/></t>
<t>ElseIf BGP route for <COLOR,DESTINATION> is NOT caring Color Extended Community, The BGP NextHop attribute shall be resolved over tunnel of color equal to COLOR carried in NLRI</t>
</list>
</t>
<t>The fallback to resolution over other tunnels - other color or non-colored - is subject of local configuration policy on the node and/or value of "CO" bits of Color Extended Community.</t>
<t>Please note:</t>
<t><list style="symbols">
<t>This operation does create <COLOR,DESTINATION> entry in RIB.</t>
<t>This operation does not create any IP RIB entry.</t>
<t>This operation does not create any IP entry in FIB</t>
<t>This operation does not create any MPLS entry in FIB</t>
</list></t>
</section>
<section title="Advertising BGP-LCU over eBGP session and iBGP session with BGP NH changed (NH-self)">
<t>Whenever BGP path to <COLOR,DESTINATION> is re-advertised and BGP Next Hop attribute is changed, the label(s) portion of NLRI is modified. On the Next-Hop-change the BGP speaker replaces all label(s) in NLRI by single local label. The local label identifies <COLOR, DESTINATION>. The value of local labels is derived as described in chapter 6.6. </t>
<t>Any BGP speaker supporting LABELED-COLORED-UNICAST (SAFI=[[TBD]]) MUST support above behavior on Next-hop-change.</t>
<t>Please note:</t>
<t><list style="symbols">
<t>This operation does not create <COLOR,DESTINATION> entry in RIB.</t>
<t>This operation does not create any IP RIB entry.</t>
<t>This operation does not create any IP entry in FIB</t>
<t>This operation may create or modify MPLS entry in RIB and FIB.
<list style="symbols">
<t>New RIB and FIB entries are created if no label was allocated to <COLOR,DESTINATION> previously.</t>
<t>The RIB and FIB entries are modified if given path is best and active. (or 2nd to best and BGP PIC EDGE is enabled)</t>
<t>The RIB entry is modified if given path is best.</t>
</list></t>
</list></t>
</section>
<section title="Advertising BGP-LCU over iBGP session when BGP NH remain unchanged.">
<t>Whenever BGP path to <COLOR,DESTINATION> is re-advertised but BGP Next-Hop attribute remains unchanged, the label(s) portion of NLRI MUST NOT be modified.</t>
</section>
<section title="Label value assignment procedure">
<t>The selection of local label value MUST follow below procedure.</t>
<t><list style="numbers">
<t>If BGP speaker is provided (e.g. by local configuration) with explicit label value binding for given <COLOR, DESTINATION>, it SHOULD be honored and used.</t>
<t>If BGP speaker is injecting <COLOR,DESTINATION> into BGP-LCU from other protocol or family, and Binding SID (BSID) as per Segment Routing Architecture <xref target="RFC8402"/> is assigned to original tunnel, then local label SHOULD be set to be equal to BSID value.</t>
<t>If BGP path carries BGP prefix-SID attribute, and given BGP speaker is enabled to process this attribute (e.g. by mean of local configuration), then this BGP speaker SHOULD allocate local label form it's SRGB <xref target="RFC8402"/>.</t>
<t>If, given BGP speaker has local label already allocated for given <COLOR, DESTINATION> as result of processing earlier routing events, this same value MUST be used.</t>
<t>Else, BGP speaker allocates label from free labels of it's dynamic label block.</t>
</list></t>
<t>Please note that above procedure could result with local label value shared among multiple <COLOR,DESTINATION> prefixes, or unique label value for each <COLOR,DESTINATION>. It depends on particular network scenario and both possibilities are valid and legitimate.</t>
</section>
</section>
<section title="Deployment and Operation Consideration">
<section title="Building label stack">
<section title="Purpose of multiple-label stack">
<t>Due to potential large scale of colored prefixes, the BGP-LCU speaker may run out of label space, if 1:1 relationship between <COLOR:DESTINATION> and local label would be established. </t>
<t>Sharing label among multiple <COLOR:DESTINATION> prefixes could be not always possible and reduction of needed labels is hard to predict and is changing together with intra-domain tunnels path changes.</t>
<t>To predictably address this scaling challenge, the topmost label of packet incoming on ASBR/ABR shall represents immediate downstream intra-domain tunnel in the connected TE-domain rather than entire end-to-end path. Consequently, ingress PE need to push appropriate label stack on outgoing data packets.</t>
<t>This chapter describes how BGP-LCU could be configured and used on various nodes of multi-domain network system to instruct ingress PE to build and push label stack onto outgoing packets.</t>
<t>If network scale, in terms of number of DESTINATIONS and COLORS, do not requires usage of label stack, it is perfectly valid design to simply swap label in NLRI on every domain border and use one label on ingress PE for inter-TE-domain tunnel.
</t>
</section>
<section title="Ingress recursive resolution">
<t>The Recursive resolution of BGP-LCU NH attributes on ingress PE provides ability to construct label stack and relief transit BGP speakers (ASBRs and ABRs)label space pressure. Recursive resolution is matter of network design and ingress PE capability and is inherently supported by BGP-LCU.</t>
<t>The below description is provided to the reader for convenience.</t>
<t>To provide ingress PE with sufficient information for building and pushing label stack onto packet, in addition to signal path for every <COLOR,EGRESS-PE> combination, would require signaling (in BGP-LCU) also path for <COLOR,ASBR/ABR> combination. Please note that typically number of ASBRs/ABRs is two or three orders of magnitude lower than PEs. Also, note that if given node is ASBR and PE, is should not be double-counted. Therefor impact on BGP-LCU path scale is expected to be < 1%. and therefore negligible.</t>
<t>Please note that when BGP-LCU path is re-advertised to another BGP-LCU session, BGP Next-Hop attribute is changed, or not, according to following rules. This rules do not represent default BGP behavior but could be implemented via local configuration of BGP speaker.</t>
<t><list style="numbers">
<t>If path is advertised to eBGP and has AS-PATH empty, then BGP Next-Hop attribute MUST be changed. This is default BGP behavior.</t>
<t>If path is learned from eBGP from AS that originated <COLOR,DESTINATION> prefix (is last on AS-PATH), then Next-Hop attribute should be changed. This is observed common practice to change BGP Next-Hop attribute to self in this scenario.</t>
<t>In every other case, including re-advertising to eBGP sessions, BGP-LCU Next-Hop attribute, and consequently label(s) sequence in NLRI, should stay unmodified.</t>
</list></t>
<t>Example below (<xref target="fig_6"/>) shows BGP-LCU update flow across domains. The BGP Next-Hop attribute manipulation and resolution are also shown in <xref target="table_2"/>. Finally, MPLS FIB entries are also displayed.</t>
<figure align="center" anchor="fig_6">
<artwork align="left"><![CDATA[
<-------AS 1--------> <---AS 2---> <---AS 3--->
+------+ +------+ +------+ +------+
|domain| |domain| |domain| |domain|
.+. 1 .-. 2 .-. .-. 3 .-. .-. 3 .+.
( I ) ( A ) ( B )--( C ) ( D )--( E ) ( Z )
'+' '-' '-' '-' '-' '-' '+'
+------+ +------+ +------+ +------+
]]></artwork>
<postamble>Label stack build on ingress - topology</postamble>
</figure>
<t>The <xref target="table_2"/> below, shows flow BGP-LCU Updates for DESTINATION "I"</t>
<texttable anchor="table_2" title="COLOR code schema - intra- and inter-TE-domain">
<ttcol align="center">From</ttcol>
<ttcol align="center">to</ttcol>
<ttcol align="center">NLRI</ttcol>
<ttcol align="center">BGP NH</ttcol>
<ttcol align="center">AS-path</ttcol>
<c>A</c> <c>B</c> <c>[L1 ,<red,I>]</c> <c>A</c> <c></c>
<c>B</c> <c>C</c> <c>[L1' ,<red,I>]</c> <c>B</c> <c>[AS1]</c>
<c>C</c> <c>D</c> <c>[L1",<red,I>]</c> <c>C</c> <c>[AS1]</c>
<c>D</c> <c>E</c> <c>[L1" ,<red,I>]</c> <c>C</c> <c>[AS1 AS2]</c>
<c></c> <c></c> <c>[L2 ,<red,C>]</c> <c>E</c> <c>[AS2]</c>
<c>E</c> <c>Z</c> <c>[L1",<red,I>]</c> <c>C</c> <c>[AS1 AS2]</c>
<c></c> <c></c> <c>[L2',<red,C>]</c> <c>E</c> <c>[AS2]</c>
</texttable>
<t>The <xref target="table_3"/> below shows RIB entry on node "Z" after recursive resolution</t>
<texttable anchor="table_3" title="Ingress label stack build - RIB entry">
<ttcol align="center">Prefix/key</ttcol>
<ttcol align="center">encap. operation</ttcol>
<ttcol align="center">egress interface</ttcol>
<c><red,I></c> <c>push: L1", L2', [red-tunnel-to-E]</c> <c> X</c>
</texttable>
<t>Please note that ASBRs "D" and "E" do not modify BGP Next-Hop attribute for prefix <red,I>, therefore no label is changed. Consequently there is no MPLS FIB entry created for this prefix.</t>
<t>The above described method allows to build label stack on ingress PE, thus address high scale of <COLOR,DESTINATION> prefix while reducing data-plane states on domains border nodes.</t>
</section>
</section>
<section title="Handling BGP-LCU ingress PEs with limited label imposition depth capabilities">
<t>The consequence of design in which inter-domain tunnel is represented as multiple labels stack, is that ingress PE would need to push even more labels onto the packet: </t>
<t><list style="numbers">
<t>service label, </t>
<t>perhaps ELI/EL or FAT label(s) </t>
<t>sequence of labels for inter-domain tunnel (learned form BGP-LCU and recursively resolved as per chapter 7.1. above)</t>
<t>and finally, sequence of one or more labels used by given ingress PE to reach egress ASBR/ABR while satisfying T-intent. The sequence of label could be significantly long if SRTE policy is used.</t>
</list></t>
<t>Authors of this document acknowledges that currently there is equipment in field and in development, that have limited capability in pushing deep label stack (Legacy-PE).</t>
<t>To support such devices in ingress role, egress ASBR/ABR (node "E" on <xref target="fig_6"/>) of ingress TE-DOMAIN comprising such PE (node "Z" on <xref target="fig_6"/>)have to "reduce" stack depth.</t>
<t>Provided that egress ASBR (node "E") learns all BGP-LCU <COLOR,DESTINATION> prefixes (e.g from Route Server), it advertises this BGP-LCU path to iBGP session toward (set of) ingress Legacy-PE, with BGP Next-Hop attribute change to self. As result, path would be re-advertised with only one label. This reduce required label push depth on legacy ingress PE.</t>
<t>In the very high scale environment, by doing above, egress ASBR/ABR would consume large number of labels. Therefore, network designer needs to take this into consideration and if needed take appropriate action, which could be for example:</t>
<t><list style="symbols">
<t>filter colored prefixes that are send to (all) legacy ingress PEs to smaller subset. This technique is specifically effective if ingress PEs are part of backhaul solution and provide transport to limited set of centralized service-aware nodes (vEPC, BNG, Video caches)</t>
<t>replace ingress PE hardware or software to enable deeper label push.</t>
</list></t>
</section>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?>
<!--<section anchor="Acknowledgements" title="Acknowledgements">
<t>This template was derived from an initial version written by Pekka
Savola and contributed by him to the xml2rfc project.</t>
</section>-->
<section anchor="Contributors" title="Contributors">
<t>The following people have contributed to this document:</t>
<t>Jeff Haas, Juniper Networks</t>
<t>Shraddha Hedge, Juniper Networks</t>
<t>Santosh Kolenchery, Juniper Networks</t>
<t>Shihari Sangli, Juniper Networks </t>
<t>Krzysztof Szarkowicz, Juniper Networks</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document defines a new SAFI in the registry "Subsequent Address Family Identifiers (SAFI) Parameters" that has been assigned by IANA:</t>
<texttable anchor="table_4" title="">
<ttcol align="center">Codepoint</ttcol>
<ttcol align="center">Description</ttcol>
<ttcol align="center">Reference</ttcol>
<c>[[TBD]]</c> <c>Labeled colored unicast SAFI</c> <c>This document</c>
</texttable>
</section>
<section anchor="Security" title="Security Considerations">
<t>The security considerations of BGP (as specified in BGP-4 <xref
target="RFC4271"/>) apply.</t>
<t>This document specifies that certain data packets be "tunneled" from one BGP speaker to another across single TE-domain. This requires that the packets be encapsulated while in flight. This document does not specify the encapsulation to be used, except it need to be able to carry MPLS packet as payload. However, if a particular encapsulation is used, the security considerations of that encapsulation are applicable.
</t>
<t>If a particular intra-TE-domain tunnel encapsulation does not provide integrity and authentication, it is possible that a data packet's label stack can be modified, through error or malfeasance, while the packet is in flight. This can result in misdelivery of the packet. It should be that the tunnel encapsulation (MPLS), expected to be most commonly used in deployments of this specification, does not provide integrity or authentication.
</t>
<t>There are various techniques one can use to constrain the distribution of BGP UPDATE messages. If a BGP UPDATE advertises the binding of a particular label or set of labels to a particular address <COLOR,DESTINATION>, such techniques can be used to control the set of BGP speakers that are intended to learn of that binding. However, if BGP sessions do not provide privacy, other routers may learn of that binding.
</t>
<t>When a BGP speaker processes a received MPLS data packet whose top label it advertised, there is no guarantee that the label in question was put on the packet by a router that was intended to know about that label binding. If a BGP speaker is using the procedures of this document, it may be useful for that speaker to distinguish its "internal" interfaces from its "external" interfaces and to "remember" label binding advertised over each "external" interfaces. Then, a data packet received on give "external" interface can be discarded if its top label was not advertised over this "external" interface. This reduces the likelihood of forwarding packets whose labels have been "spoofed" by untrusted sources.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC3032;
&RFC4271;
&RFC4760;
&RFC2545;
&RFC5549;
&RFC8277;
&RFC8402;
&SR-POL;
&TUN-ENCAP;
&P-SID;
<!--<reference anchor="min_ref">
the following is the minimum to make xml2rfc happy
<front>
<title>Minimal Reference</title>
<author initials="authInitials" surname="authSurName">
<organization></organization>
</author>
<date year="2006" />
</front>
</reference>-->
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC2475;
&RFC5575;
&RFC7606;
&RFC7811;
&RFC7911;
&FlexAlgo;
&S-MPLS;
</references>
<!-- A reference written by by an organization not a person. -->
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems).
v06 2010-04-01 TT Changed ipr attribute values to latest ones. Changed date to
year only, to be consistent with the comments. Updated the
IANA guidelines reference from the I-D to the finished RFC. -->
</back>
</rfc>