idnits 2.17.1 draft-ietf-sfc-nsh-tlv-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 20, 2020) is 1437 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-NSH-MD2' ** Downref: Normative reference to an Informational RFC: RFC 7665 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC Y. Wei, Ed. 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track U. Elzur 5 Expires: November 21, 2020 Intel 6 S. Majee 7 Caber systems inc 8 May 20, 2020 10 Network Service Header Metadata Type 2 Variable-Length Context Headers 11 draft-ietf-sfc-nsh-tlv-03 13 Abstract 15 This draft describes Network Service Header (NSH) Metadata (MD) Type 16 2 variable-length context headers that can be used within a service 17 function path. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 21, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions used in this document . . . . . . . . . . . . . . 3 55 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 3. NSH MD Type 2 format . . . . . . . . . . . . . . . . . . . . 3 58 4. NSH MD Type 2 Context Headers . . . . . . . . . . . . . . . . 4 59 4.1. Forwarding Context . . . . . . . . . . . . . . . . . . . 4 60 4.2. Tenant Identifier . . . . . . . . . . . . . . . . . . . . 5 61 4.3. Content Type . . . . . . . . . . . . . . . . . . . . . . 5 62 4.4. Ingress Network Node Information . . . . . . . . . . . . 6 63 4.5. Ingress Network Source Interface . . . . . . . . . . . . 6 64 4.6. Flow ID . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.7. Source and/or Destination Groups . . . . . . . . . . . . 7 66 4.8. Universal Resource Identifier . . . . . . . . . . . . . . 7 67 4.9. Policy Identifier (POLICY_ID) . . . . . . . . . . . . . . 8 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 7.1. Forwarding Context Types . . . . . . . . . . . . . . . . 9 72 7.2. Tenant Identifier Types . . . . . . . . . . . . . . . . . 9 73 7.3. Group Types . . . . . . . . . . . . . . . . . . . . . . . 10 74 7.4. URI Types . . . . . . . . . . . . . . . . . . . . . . . . 10 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 8.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 Network Service Header (NSH) [RFC8300] is the Service Function 83 Chaining (SFC) encapsulation required to support the SFC 84 architecture. As such, NSH provides following key elements: 86 1. Service Function Path identification. 88 2. Indication of location within a Service Function Path. 90 3. Optional, per-packet metadata (fixed-length or variable). 92 [RFC8300] further defines two metadata formats (MD Types): 1 and 2. 93 MD Type 1 defines fixed length, 16 bytes-long metadata, whereas MD 94 Type 2 defines a variable-length context format for metadata. This 95 draft defines some common metadata contexts for use with NSH MD Type 96 2. 98 This draft does not address metadata usage, updating/chaining of 99 metadata or other SFP functions. Those topics are described in 100 [RFC8300]. 102 2. Conventions used in this document 104 2.1. Terminology 106 This document uses the terminology defined in the SFC Architecture 107 [RFC7665]and the Network Service Header [RFC8300] 109 2.2. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 3. NSH MD Type 2 format 119 A NSH is composed of a 4-byte Base Header, a 4-byte Service Path 120 Header and Context Headers. The Base Header identifies the MD-Type 121 in use: 123 0 1 2 3 124 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 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 Figure 1: NSH Base Header 131 Please refer to NSH [RFC8300] for a detailed header description. 133 When the base header specifies MD Type = 0x2, zero or more Variable 134 Length Context Headers MAY be added, immediately following the 135 Service Path Header. Therefore, Length = 0x2 indicates that only the 136 Base Header followed by the Service Path Header is present. The 137 number, indicated in the Length field, of optional Variable Length 138 Context Headers MUST be of an integer indicating length in 4-bytes 139 words Figure 2 below depicts the format of the Context Header as 140 defined in Section 2.5.1 of [RFC8300]. 142 0 1 2 3 143 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 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Metadata Class | Type |U| Length | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Variable-Length Metadata | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 Figure 2: NSH Variable-Length Context Headers 152 4. NSH MD Type 2 Context Headers 154 In [RFC8300] defined that Metadata Class 0x0000 as IETF Base NSH MD 155 Class. In this draft, metadata types are defined for the IETF Base 156 NSH MD Class. 158 4.1. Forwarding Context 160 This metadata context carries a network forwarding context, used for 161 segregation and forwarding scope. Forwarding context can take 162 several forms depending on the network environment. For example, 163 VXLAN/VXLAN-GPE VNID, VRF identification or VLAN. 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Metadata Class = 0x0000 | Type = TBA1 |U| Length = 8 | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | CT | Reserved | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Tenant ID | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Figure 3: Forwarding Context 177 where: 179 Context Type (CT) is four bits-long field that defines the length 180 and the interpretation of the Tenant ID field. Please see the 181 IANA Considerations in Section 7. This document defines these CT 182 values: 184 0x0 - 24 bits VXLAN/LISP virtual network identifier (VNI) 186 0x1 - 20 bits MPLS VPN label 188 0x2 - 12 bits VLAN identifier 190 4.2. Tenant Identifier 192 Tenant identification is often used for segregation within a multi- 193 tenant environment. Orchestration system-generated tenant IDs are an 194 example of such data. This context header carries both the format 195 and value of the Tenant identifier. 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Metadata Class = 0x0000 | Type = 0x02 |U| Length=12 | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | TT | Reserved | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Tenant ID | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Tenant ID | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 4: Tenant Identifier List 211 where: 213 Tenant Type (TT) is four bits-long field that specifies the length 214 of the Tenant ID field. This document defines the following 215 values for TT: 217 * 0x0 - 32 bits-long Tenant ID 219 * 0x1 - 64 bits-long Tenant ID 221 4.3. Content Type 223 Provides explicit information about the content being carried, for 224 example, type of video or content value for billing purposes. 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Metadata Class = 0x0000 | Type = TBA3 |U| Length = 4 | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Content Type | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Figure 5: Content Type 236 4.4. Ingress Network Node Information 238 This context carries Node ID of the ingress network node. 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Metadata Class = 0x0000 | Type = TBA4 |U| Length = 8 | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Node ID | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 6: Ingress Network Node ID 250 4.5. Ingress Network Source Interface 252 This context carries the ingress interface of the ingress network 253 node. 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Metadata Class = 0x0000 | Type = TBA5 |U| Length = 8 | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Source Interface/Port | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 7: Ingress Network Source Interface 265 4.6. Flow ID 267 Flow ID provides a representation of the flow. Akin, but not 268 identical to the usage described in [RFC6437]. 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Metadata Class = 0x0000 | Type = TBA6 |U| Length = 4 | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Flow ID | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Figure 8: Flow ID 280 4.7. Source and/or Destination Groups 282 Intent-based systems can use this data to express the logical 283 grouping of source and/or destination objects. [GROUPBASEDPOLICY] 284 and [GROUPPOLICY] provide examples of such a system. 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Metadata Class = 0x0000 | Type = TBA7 |U| Length=12 | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | GT | Reserved | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Source Group | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Dest Group | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Figure 9: End Point Group 300 where: 302 Group Type (GT) is four bits-long field that specifies the the 303 interpretation of Source Group and/or Destination Group fields. 304 This document defines the following values for GT: 306 * 0x1 - Group Based Policy (GBP) end point group (EPG) 308 4.8. Universal Resource Identifier 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Metadata Class = 0x0000 | Type = TBA8 |U| Length=var | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | UT | URI | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 ~ URI ~ 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Figure 10: Universal Resource Identifier 322 where 324 URI (Universal Resource Identifier) Type is four bits-long field 325 that specifies the format of the URI field. This document defines 326 the following values for the URI Type field: 328 * 0x1: URI in standard string format as defined in [RFC3986]. 330 * 0x2: URI represented in a compacted hash format. 332 4.9. Policy Identifier (POLICY_ID) 334 The policy is often referred by a system-generated identifier which 335 is then used by the devices to lookup the content of the policy 336 locally. For example, this identifier could be an index to an array, 337 a lookup key, a database Id. The identifier allows enforcement 338 agents or services to lookup up the content of their part of the 339 policy quite efficiently. 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Metadata Class = 0x0000 | Type = TBA9 |U| Length=var | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | POLICY_ID | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 ~ POLICY_ID ~ 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Figure 11: POLICY_ID 353 5. Security Considerations 355 [RFC8300] describes the requisite security considerations for 356 protecting NSH metadata. 358 6. Acknowledgments 360 The authors would like to thank Paul Quinn, Behcet Sarikaya, Dirk von 361 Hugo, Mohamed Boucadair, Carlos Pignataro and Gregory Mirsky for 362 providing invaluable concepts and content for this document. 364 7. IANA Considerations 366 This document requests IANA to assign the following types from the 367 "NSH IETF- Assigned Optional Variable-Length Metadata Types" (0x0000 368 IETF Base NSH MD Class) registry available at [IANA-NSH-MD2] 370 This document defines the following new values (Table 1)in the 371 Network Service Header (NSH) metadata context Type registry: 373 +-------+----------------------------------+---------------+ 374 | Value | Description | Reference | 375 +-------+----------------------------------+---------------+ 376 | TBA1 | Forwarding Context | This document | 377 | TBA2 | Tenant Identifier | This document | 378 | TBA3 | Content Type | This document | 379 | TBA4 | Ingress Network NodeID | This document | 380 | TBA5 | Ingress Network Interface | This document | 381 | TBA6 | Flow ID | This document | 382 | TBA7 | Source and/or Destination Groups | This document | 383 | TBA8 | Universal Resource Identifier | This document | 384 | TBA9 | Policy Identifier | This document | 385 +-------+----------------------------------+---------------+ 387 Table 1: Type Values 389 7.1. Forwarding Context Types 391 IANA is requested to create and maintain a new sub registry for 392 "Forwarding Context" context types at [IANA-NSH-MD2]. 394 +---------+-------------------------------------------+-------------+ 395 | Value | Context Types | Reference | 396 +---------+-------------------------------------------+-------------+ 397 | 0x0 | 24-bits VXLAN/LISP virtual network | This | 398 | | identifier (VNI) | document | 399 | 0x1 | 20-bits MPLS VPN label | This | 400 | | | document | 401 | 0x2 | 12-bit VLAN identifier | This | 402 | | | document | 403 | 0x3-0x9 | Unassigned | IETF Review | 404 | 0xA-0xE | Expert Review | IETF Review | 405 | 0xF | Reserved | This | 406 | | | document | 407 +---------+-------------------------------------------+-------------+ 409 Table 2: Fowarding Context Types 411 7.2. Tenant Identifier Types 413 IANA is requested to create and maintain a new sub registry for 414 "Tenant Identifier" context types at [IANA-NSH-MD2], with the 415 following initial allocation: 417 +-------+-------------------------+---------------+ 418 | Value | Tenant Identifier Types | Reference | 419 +-------+-------------------------+---------------+ 420 | 0x0 | 32 bits-long Tenant ID | This document | 421 | 0x1 | 64 bits-long Tenant ID | This document | 422 +-------+-------------------------+---------------+ 424 Table 3: Tenant Identifier Types 426 7.3. Group Types 428 IANA is requested to create and maintain a new sub registry for 429 "Group" context types at [IANA-NSH-MD2], with the following initial 430 allocation: 432 +---------+------------------------------------------+--------------+ 433 | Value | Group Types | Reference | 434 +---------+------------------------------------------+--------------+ 435 | 0x0 | Reserved | This | 436 | | | document | 437 | 0x1 | Group Based Policy (GBP) end point group | This | 438 | | (EPG) | document | 439 | 0x2-0xE | Unassigned | IETF Review | 440 | 0xF | Reserved | This | 441 | | | document | 442 +---------+------------------------------------------+--------------+ 444 Table 4: Group Types 446 7.4. URI Types 448 IANA is requested to create and maintain a new sub registry for 449 "Group" context types at [IANA-NSH-MD2], with the following initial 450 allocation: 452 +---------+-------------------------------------------+-------------+ 453 | Value | URI Types | Reference | 454 +---------+-------------------------------------------+-------------+ 455 | 0x0 | Reserved | This | 456 | | | document | 457 | 0x1 | URI in standard string format as defined | This | 458 | | in [RFC3986] | document | 459 | 0x2 | URI represented in a compacted hash | This | 460 | | format | document | 461 | 0x3-0xE | Unassigned | IETF Review | 462 | 0xF | Reserved | This | 463 | | | document | 464 +---------+-------------------------------------------+-------------+ 466 Table 5: URI Types 468 8. References 470 8.1. Normative References 472 [IANA-NSH-MD2] 473 IANA, "NSH IETF-Assigned Optional Variable-Length Metadata 474 Types", . 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, 479 DOI 10.17487/RFC2119, March 1997, 480 . 482 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 483 Resource Identifier (URI): Generic Syntax", STD 66, 484 RFC 3986, DOI 10.17487/RFC3986, January 2005, 485 . 487 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 488 Chaining (SFC) Architecture", RFC 7665, 489 DOI 10.17487/RFC7665, October 2015, 490 . 492 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 493 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 494 May 2017, . 496 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 497 "Network Service Header (NSH)", RFC 8300, 498 DOI 10.17487/RFC8300, January 2018, 499 . 501 8.2. Informative References 503 [GROUPBASEDPOLICY] 504 OpenStack, "Group Based Policy", 2014. 506 [GROUPPOLICY] 507 OpenDaylight, "Group Policy", 2014. 509 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 510 "IPv6 Flow Label Specification", RFC 6437, 511 DOI 10.17487/RFC6437, November 2011, 512 . 514 Authors' Addresses 516 Yuehua (Corona) Wei (editor) 517 ZTE Corporation 518 No.50, Software Avenue 519 Nanjing 210012 520 China 522 Email: wei.yuehua@zte.com.cn 524 Uri Elzur 525 Intel 527 Email: uri.elzur@intel.com 529 Sumandra Majee 530 Caber systems inc 532 Email: Sum.majee@gmail.com