idnits 2.17.1 draft-yang-rtgwg-ipv6-associated-channel-01.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 (July 12, 2021) is 1019 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) -- Looks like a reference, but probably isn't: '0' on line 355 == Missing Reference: 'ITU-T G.8013' is mentioned on line 438, but not defined == Unused Reference: 'I-D.ietf-spring-srv6-path-segment' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'RFC8402' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'RFC8754' is defined on line 515, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-spring-srv6-path-segment-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG Working Group F. Yang 3 Internet-Draft M. Chen 4 Intended status: Standards Track T. Zhou 5 Expires: January 13, 2022 Huawei Technologies 6 July 12, 2021 8 Associated Channel over IPv6 9 draft-yang-rtgwg-ipv6-associated-channel-01 11 Abstract 13 This document introduces a control channel based on IPv6, called 14 Associated CHannel over IPv6 (ACH6), that may carry different types 15 of control and management messages. By using the associated channel, 16 messages can be transmitted between network nodes to provide 17 functions like path identification, OAM, automatic protection 18 switchover signaling, resource reservation, etc., targeting to 19 provide high quality SLA guarantees to IPv6 services. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 25 "OPTIONAL" in this document are to be interpreted as described in BCP 26 14 [RFC2119] [RFC8174] when, and only when, they appear in all 27 capitals, as shown here. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 13, 2022. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Architecture of Associated Channel over IPv6 . . . . . . . . 4 66 3.1. ACH6 Network Reference Model . . . . . . . . . . . . . . 4 67 3.2. ACH6 Processing . . . . . . . . . . . . . . . . . . . . . 5 68 4. Format of Associated Channel over IPv6 . . . . . . . . . . . 5 69 4.1. Identification of ACH6 . . . . . . . . . . . . . . . . . 5 70 4.2. Carried Message of ACH6 . . . . . . . . . . . . . . . . . 6 71 4.3. ACH6 TLV Format . . . . . . . . . . . . . . . . . . . . . 6 72 4.4. Encapsulation of ACH6 TLV in IPv6 . . . . . . . . . . . . 7 73 4.4.1. Encapsulated in IPv6 Destination Options Header . . . 7 74 4.4.2. Encapsulated in IPv6 Hop-by-Hop Options Header . . . 7 75 4.4.3. Encapsulated in IPv6 Segment Routing Header . . . . . 8 76 4.4.4. Encapsulated in Payload . . . . . . . . . . . . . . . 9 77 4.5. Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10 79 5.1. Path Identification . . . . . . . . . . . . . . . . . . . 10 80 5.2. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 5.3. Assist to Protection Switchover . . . . . . . . . . . . . 11 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 87 9.2. Informative References . . . . . . . . . . . . . . . . . 12 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 90 1. Introduction 92 IPv6 is becoming widely accepted to provide connectivity in many new 93 emerging scenarios, including Cloud Network convergence, Cloud-Cloud 94 interconnection, 5G vertical industries, and Internet of Things etc. 95 However, due to the best effort forwarding genes, native IP (for both 96 IPv4 and IPv6) cannot provide the forwarding capabilities such as 97 explicit path, control and management based on the forwarding path, 98 to meet the requirements of services accordingly. 100 Generic Associated Channel (G-ACh) [RFC5586] introduces an associated 101 control channel to MPLS to provide a set of maintenance functions, 102 including OAM, performance monitoring, automatic protection switching 103 and support of management to MPLS Sections, MPLS Label Switched Paths 104 (LSPs), and MPLS pseudowires (PWs). 106 Triggered by MPLS G-ACh, to enhance the control and management 107 capabilities to IPv6, this document introduces an associated channel 108 to a specific IPv6 path, called Associated Channel over IPv6 (ACH6). 109 Associated channel over IPv6 intends to create a control channel 110 associated with the IPv6 data forwarding path for control and 111 management purposes. By using the associated channel, messages can 112 be transmitted between the network nodes to provide functions like 113 path identification, OAM, automatic protection switchover signaling, 114 resource reservation, etc., targeting to provide high quality SLA 115 guarantees to services. To identify an IPv6 forwarding path, 116 associated channel ID is also introduced. 118 This document defines an ACH6 architecture, a TLV-based format of 119 ACH6, and discusses how ACH6 format can be encapsulated in IPv6 120 packet. It also discusses the applicability of ACH6 in IPv6 network. 122 2. Terminology 124 This document uses the terminology defined in [RFC8200] , and it also 125 introduces the following new terms: 127 OAM: Operations, Administration, and Maintenance 129 SLA: Service Level Agreement 131 G-ACh: Generic Associated Channel 133 ACH6: Associated CHannel over IPv6 135 3. Architecture of Associated Channel over IPv6 137 3.1. ACH6 Network Reference Model 139 Figure 1 gives a network reference model of associated channel over 140 IPv6. The key components in ACH6 network reference model include 141 ACH6 Ingress Node, ACH6 Mid-Point Node, and ACH6 Egress Node. These 142 nodes must be IPv6-capable node. 144 +----+ +-------+ +---------+ +------+ +----+ 145 ----| Nx |---| ACH6 |----| ACH6 |---| ACH6 |---| Ny |---- 146 | | |Ingress| |Mid-Point| |Egress| | | 147 +----+ +-------+ +---------+ +------+ +----+ 148 |<-----------IPv6 Path----------->| 149 |<--------------ACH6------------->| 150 |<-----------------------IPv6 Network---------------------->| 152 Figure 1 ACH6 Network Reference Model 154 In the network reference model, 156 Nx/Ny: IPv6 node, can be either a host or a router. 158 ACH6 Ingress Node: is the node indicates the entering of control and 159 management channel over an IPv6 path, where control and management 160 messages are generated and encapsulated. 162 ACH6 Mid-Point Node: is the node that has the capability to process 163 control and management messages over an IPv6 path. For a strict 164 explicit IPv6 path, all the IPv6 hop(s) forwarded from IPv6 source 165 address to IPv6 destination address are mid-point node(s). 167 ACH6 Egress Node: is the node indicates the exiting of control and 168 management channel over an IPv6 path, where control and management 169 messages are recovered and delivered to control or management plane 170 for further process. 172 IPv6 Path: a specific path from the source node to the destination 173 node in IPv6 forwarding plane. An IPv6 path can be explicitly or 174 implicitly represented by forwarding hops from IPv6 source node to 175 IPv6 destination node. 177 ACH6: Associated Channel over IPv6 179 3.2. ACH6 Processing 181 Regarding to an IPv6 path, an ACH6 control channel is established to 182 this specific IPv6 path for a required purpose. ACH6 ingress node 183 acts as the IPv6 source node, and ACH6 egress node is the IPv6 184 destination node. ACH6 ingress node encapsulates control or 185 management messages into IPv6 packets, identifies the specific 186 channel type which carried messages belong to, and sends the IPv6 187 ACH6 packets to the destination of IPv6 path. The control and 188 management messages can either piggyback with data packets, or 189 generated and transmitted separately. 191 When ACH6 Mid-Point Node receives ACH6 IPv6 packets, it firstly 192 recognizes ACH6 associated channel to interpret the control protocol, 193 and then processes the messages. The processing of messages can 194 include for example READ or/and WRITE, depending on the specification 195 of protocols used in the associated channel. ACH6 Mid-Point Node 196 needs to transmit the IPv6 packets carried with the original or 197 modified ACH6 messages to the destination of IPv6 packet. 199 ACH6 Egress Node receives ACH6 IPv6 packets and recognizes itself as 200 the destination. Based on the specific type of control protocol, the 201 message is delivered to control or management planes for further 202 process. 204 4. Format of Associated Channel over IPv6 206 An associated channel provides a control channel that carries at 207 least one or more types of control and management messages. The type 208 of message is not limited to any specific usage. The associated 209 channel is specified by two pieces of information, including the 210 identification of the associated channel and the carried message. 212 4.1. Identification of ACH6 214 The identification of associated channel, called Associated Channel 215 ID, indicates the path where the packets of the associated channel 216 are transmitted on. This identification also indicates the same path 217 of the service forwarding path with which the associated channel is 218 associated. When the Associated Channel ID is carried in the 219 associated channel, ACH6 edge nodes and intermediated nodes should 220 interpret it to identify the same IPv6 path. 222 The associated channel ID can be defined either globally unique or 223 site local, or even link local. The Associated Channel ID can be 224 self-generated, or designated from management plane, or advertised 225 and allocated via control protocol. 227 4.2. Carried Message of ACH6 229 At least one control or management protocol messages are transmitted 230 via associated channel over IPv6. When multiple protocols are 231 running over an IPv6 path, messages of different protocols can be 232 sent either in separate ACH6 TLVs in one ACH6 packet or in separate 233 ACH6 packets with only one type of ACH6 TLV. 235 4.3. ACH6 TLV Format 237 An Associated CHannel over IPv6 (ACH6) TLV is designed to carry the 238 identification and carried message of an associated channel. ACH6 239 TLV has the following format: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Type=TBD1 | length | Channel Type | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 // Associated Channel ID // 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | ~ 249 ~ Value ~ 250 ~ | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 2 ACH6 TLV Format 255 Type: 8 bits, indicates it is an associated channel ACH6 TLV, and 256 request a value assigned by IANA. The uniform type of TLV 257 generalizes the applicability of ACH6 TLV to support various types of 258 messages. 260 Length: 8 bits, defines the length of Value field in bytes. 262 Channel Type: is a 16-bit-length fixed portion of Value field. It 263 indicates the specific type of messages carried in associated 264 channel. Note that a new ACH6 TLV Channel Type Registry would be 265 requested to IANA. In later documents which specify application 266 protocols of associated channel, MUST also specify the applicable 267 Channel Type field value assigned by IANA. 269 Associated Channel ID: indicates the identification of associated 270 channel. The length is TBD. 272 Value: is a variable portion of Value field. It specifies the 273 messages indicated by Channel Type and carried in associated channel. 275 Note that the Value field of ACH6 TLV MAY contain sub-TLVs to provide 276 additional context information to ACH6 TLV. 278 4.4. Encapsulation of ACH6 TLV in IPv6 280 In the context of IPv6, ACH6 TLV can be encapsulated in different 281 types of IPv6 extension headers, or as an independent IPv6 payload. 282 Note that, no matter which way ACH6 TLV is applied, there is no 283 semantic change to IPv6 extension headers. 285 4.4.1. Encapsulated in IPv6 Destination Options Header 287 ACH6 TLV can be encapsulated in IPv6 Destination Options Header as 288 the TLV-encoded options. Figure 2 gives an example of an ACH6 TLV 289 encapsulated in IPv6 Destination Options Header. 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Next Header | Hdr Ext Len | Opt Type(ACH6)| Opt Data Len | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <-+ 296 | Channel Type | Associated Channel ID // | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 298 | ~ Option 299 ~ Value (depends on the specific protocol) ~ Data 300 ~ | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <-+ 303 Figure 3 ACH6 TLV in IPv6 Destination Options Header 305 According to the note 1 and note 3 described in section 4.1 306 of[RFC8200], ACH6 TLV encapsulated in IPv6 Destination Options Header 307 can provide two semantics of an associated channel. When only IPv6 308 Destination Options Header exists or IPv6 Destination Options Header 309 exists after the Routing Header, an end to end associated channel is 310 provided to transmit the messages between two endpoints. When both 311 IPv6 Destination Options Header and Routing Header exist, and IPv6 312 Destination Options Header exists before the Routing Header, an 313 associated channel is provided at network nodes of the first 314 destination that appears in the IPv6 Destination Address field plus 315 subsequent destinations listed in the Routing header. 317 4.4.2. Encapsulated in IPv6 Hop-by-Hop Options Header 319 ACH6 TLV can be encapsulated in IPv6 Hop-by-Hop Options Header as the 320 TLV-encoded options. Same option type numbering space is used for 321 both Hop-by-Hop Options header and Destination Options header. 323 Similarly, the ACH6 TLV in IPv6 Hop-by-Hop Options Header shares the 324 same encapsulation shown in Figure 3. 326 When it is encapsulated in IPv6 Hop-by-Hop Options Header, it 327 provides an associated channel at every node along the forwarding 328 path. ACH6 ingress node inserts the IPv6 HbH Option Header with ACH6 329 Option Type, every mid-point node examines, processes and transmits 330 the IPv6 packet to next forwarding hop. ACH6 egress node receives 331 the IPv6 packet as the destination node, ACH6 messages are processed 332 and delivered to control or management plane for further usage. 333 Processing is limited, can be READ and/or REWRITE. 335 Routers that are not configured to support Hop-by-Hop Options SHOULD 336 ignore this option and SHOULD forward the packet. 338 Routers that support Hop-by-Hop Options, but that are not configured 339 to support this option SHOULD ignore the option and SHOULD forward 340 the packet. 342 4.4.3. Encapsulated in IPv6 Segment Routing Header 344 ACH6 TLV can be encapsulated in IPv6 Segment Routing Header, as SRH 345 optional TLV. Figure 3 gives an example of an ACH6 TLV encapsulated 346 in IPv6 Segment Routing Header. 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Last Entry | Flags | Tag | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 ~ Segment List[0] (128 bits) ~ 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 ~ ... ~ 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 ~ Segment List[n] (128 bits) ~ 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Type=ACH6 | Length | Channel Type | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 // Associated Channel ID // 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | ~ 366 ~ Value (depends on the specific protocol) ~ 367 ~ | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | ~ 370 ~ Other Optional Type Length Value objects (variable) ~ 371 ~ | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Figure 4 ACH6 TLV in IPv6 Segment Routing Header 376 When ACH6 TLV is encapsulated in IPv6 Segment Routing Header, it 377 provides an associated channel at every SRv6 endpoints along the 378 path. 380 4.4.4. Encapsulated in Payload 382 ACH6 TLV can also be encapsulated in the payload of an IPv6 packet. 383 The term payload here means the octets after the IPv6 header and 384 extension headers. A synthetic packet is created with the payload of 385 messages. and transmitted in an associated channel. The synthetic 386 packet can use the same routing information with service data whose 387 associated channel it is associated. For example, synthetic packet 388 can encapsulate the same segment list as the one used in IPv6 SRH of 389 service data. If ACH6 TLV format is encapsulated in payload, TLV 390 Type and Length can be omitted, a new codepoint of IP Protocol 391 Numbers should be assigned. 393 4.5. Considerations 395 When ACH6 TLV is deployed in either IPv6 extension headers or payload 396 in IPv6 networks, there are serveral considerations needs to be taken 397 into account: 399 C1: MTU Increase 401 Given that ACH6 messages increases the packet size of IPv6 packet, it 402 may face the risk of exceeding the PMTU. This problem can be solved 403 by taking two things into considerations. Firstly, the mechanism of 404 each protocol should clearly specify the maximum size limit of 405 carried messages in one IPv6 packet. Secondly, operators or hosts 406 who makes use of ACH6 to carry control and management messages should 407 carefully design and ensure the addition of messages would not exceed 408 the agreed PMTU. 410 C2: Processing of IPv6 Extension Header 412 Though IPv6 Extension Headers especially IPv6 Hop-by-Hop Option 413 Header is not widely used in the Internet, there are some limited 414 environments like Data Centers and Interconnections between Data 415 Centers are experimentally using IPv6 Option Headers. It is worth to 416 keep the possibility of carrying ACH6 messages as Option in IPv6 417 Extension Headers. 419 5. Applicability 421 5.1. Path Identification 423 In a native IPv6 network, packets are transmitted hop by hop, there 424 is no way to identify an IPv6 forwarding path. The path needs to be 425 identified when OAM or protection switchover is applied to the path. 427 5.2. OAM 429 OAM includes a group of functions such as connectivity verification, 430 fault indication and detection, and performance measurement of loss 431 and delay etc. For example, BFD defines a generic control packet 432 format that can be encapsulated in different data planes to provide 433 low-overhead and short-duration failure detection function. The 434 format can also be encapsulated in ACH6 TLV as the option TLV of 435 Destination Options Header, to provide the same connectivity 436 verification and fault detect functions without introducing upper 437 layer protocols. Another example is to encapsulate PDU formats of 438 Ethernet OAM [ITU-T G.8013] in Value field of ACH6 TLV to provide a 439 set of OAM functions. By using ACH6 TLV to carry OAM messages in an 440 associated channel, different OAM functions can be easily integrated. 442 The OAM functions can be performed in either end-to-end or hop-by-hop 443 mode. For example, signal degradation that happens on the 444 intermediate node could be discovered and further indicated in 445 associated channel to monitor the path status. 447 5.3. Assist to Protection Switchover 449 Linear protection [RFC6378] provides a very flexible protection 450 mechanism in a mesh network because it can operate between any pair 451 of endpoints. ACH6 TLV can be used to transmit the protection state 452 control messages on an IPv6 forwarding path to provide the function 453 of bidirectional protection switchover. 455 6. IANA Considerations 457 o This document requests IANA to assign a codepoint of Destination 458 Options and Hop-by-Hop Options. 460 o This document requests IANA to assign a codepoint of Segment 461 Routing Header TLVs to indicate ACH6 TLV. 463 o This document request IANA to create a new registry of IPv6 ACH6 464 Channel Types to identify the usage of associated channel. 466 7. Security Considerations 468 TBD 470 8. Acknowledgements 472 TBD 474 9. References 476 9.1. Normative References 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, 480 DOI 10.17487/RFC2119, March 1997, 481 . 483 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 484 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 485 May 2017, . 487 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 488 (IPv6) Specification", STD 86, RFC 8200, 489 DOI 10.17487/RFC8200, July 2017, 490 . 492 9.2. Informative References 494 [I-D.ietf-spring-srv6-path-segment] 495 Li, C., Cheng, W., Chen, M., Dhody, D., and R. Gandhi, 496 "Path Segment for SRv6 (Segment Routing in IPv6)", draft- 497 ietf-spring-srv6-path-segment-00 (work in progress), 498 November 2020. 500 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 501 "MPLS Generic Associated Channel", RFC 5586, 502 DOI 10.17487/RFC5586, June 2009, 503 . 505 [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, 506 N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- 507 TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, 508 October 2011, . 510 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 511 Decraene, B., Litkowski, S., and R. Shakir, "Segment 512 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 513 July 2018, . 515 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 516 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 517 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 518 . 520 Authors' Addresses 522 Fan Yang 523 Huawei Technologies 524 Beijing 525 China 527 Email: shirley.yangfan@huawei.com 528 Mach(Guoyi) Chen 529 Huawei Technologies 530 Beijing 531 China 533 Email: mach.chen@huawei.com 535 Tianran Zhou 536 Huawei Technologies 537 Beijing 538 China 540 Email: zhoutianran@huawei.com