SPRING K. Fang Internet-Draft Cisco Systems, Inc. Intended status: Experimental Y. Li Expires: 31 December 2020 Google, Inc. F. Cai Cisco Systems, Inc. 29 June 2020 Segment Routing over UDP(SRoU) draft-zartbot-sr-udp-00 Abstract This document defines the Segment Routing Header[RFC8754] extension in UDP transport protocol with Network Address Translation Traversal. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 31 December 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Fang, et al. Expires 31 December 2020 [Page 1] Internet-Draft Segment Routing over UDP(SRoU) June 2020 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 2. SR over UDP(SRoU) Packet encapsulation . . . . . . . . . . . 3 2.1. SR over UDP(SRoU) Header . . . . . . . . . . . . . . . . 4 3. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Type:0x1, IPv4 Locator Mode . . . . . . . . . . . . . . . 7 3.2. Type:0x2, SRv6 format . . . . . . . . . . . . . . . . . . 10 3.3. Type:0x3, Compressed Segment List . . . . . . . . . . . . 10 3.3.1. Service Registration & Mapping . . . . . . . . . . . 10 3.4. Optional TLV . . . . . . . . . . . . . . . . . . . . . . 10 3.4.1. SR Integrity TLV . . . . . . . . . . . . . . . . . . 10 3.4.2. Micro-segmentation(uSeg) . . . . . . . . . . . . . . 10 3.4.3. End.PacketInfo . . . . . . . . . . . . . . . . . . . 11 4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Traffic engineering over Internet . . . . . . . . . . . . 11 4.2. Multipath forwarding . . . . . . . . . . . . . . . . . . 12 4.3. Micro Segmentation . . . . . . . . . . . . . . . . . . . 12 4.4. Container Network . . . . . . . . . . . . . . . . . . . . 12 4.5. MPLS-SR with SDWAN . . . . . . . . . . . . . . . . . . . 12 4.6. Cloud Native Network platform . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6.1. SRoU with QUIC . . . . . . . . . . . . . . . . . . . . . 14 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Normative References . . . . . . . . . . . . . . . . . . . . . 14 Informative References . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction Many UDP based transport protocol(eg, IPSec/DTLS/QUIC) could provide a secure transportation layer to handle overlay traffic. This document defines a new Segment Routing Header in UDP payload to enable segment routing over UDP(SRoU). Segment Routing over UDP(SRoU) interworking with QUIC could provide a generic programmable and secure transport layer for next generation applications. Discussion of this work is encouraged to happen on GitHub repository which contains the draft: https://github.com/zartbot/draft-quic-sr (https://github.com/zartbot/draft-quic-sr) Fang, et al. Expires 31 December 2020 [Page 2] Internet-Draft Segment Routing over UDP(SRoU) June 2020 1.1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Motivation Segment Routing provides source-based path enforcement and transportation level programmability but lacks of IPv4 support for transport over internet. MPLS-over-UDP[RFC7510] and MPLS Segment Routing over IP[RFC8663] defined SR-MPLS over IPv4 network, but it lacks of NAT traversal capabilities. Many SDWAN vendors defined their private protocols for routing control over multiple public cloud and internet, it's hard for interop with multi-vendors. Many applications may require intelligence traffic steering(CDN/LB case), SRoU with QUIC could be used in these cases. 2. SR over UDP(SRoU) Packet encapsulation The SRoU defined a generic segment routing enabled transport layer,the SR Header insert in UDP payload. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRoU Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: SRoU encapsulation Fang, et al. Expires 31 December 2020 [Page 3] Internet-Draft Segment Routing over UDP(SRoU) June 2020 2.1. SR over UDP(SRoU) Header SR over UDP must be present at the head of UDP payload. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Number | SRoU Length | Flow ID Length| Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Flow ID( Variable length) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Segment Type | SR Hdr Len | Last Entry | Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Segment List[0] (length based on segment type) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ... | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Segment List[0] (length based on segment type) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // // Optional Type Length Value objects (variable) // // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: SRoU Header Magic Number: 1 Byte field with ALL ZERO. SRoU Length: 1 Byte, The byte length of a SRoU header. Fang, et al. Expires 31 December 2020 [Page 4] Internet-Draft Segment Routing over UDP(SRoU) June 2020 FlowID Length: 1 Byte, The byte length of FlowID field. Protocol-ID: +------+------+------------------------------------+ | Type | Name | Section | +======+======+====================================+ | 0x0 | OAM | for Link state probe and other OAM | +------+------+------------------------------------+ | 0x1 | IPv4 | Indicate inner payload is IPv4 pkt | +------+------+------------------------------------+ | 0x2 | IPv6 | Indicate inner payload is IPv6 pkt | +------+------+------------------------------------+ Table 1: Protocol ID field Source Address: Protocol-ID = 1, this field is 4-Bytes IPv4 address Protocol-ID = 2, this field is 16-Bytes IPv6 address Source Port: Source UDP Port Number Segment Type: +------+-------------------------+------+-------------+ | Type | Name | Len | Section | +======+=========================+======+=============+ | 0x0 | Reserved | | | +------+-------------------------+------+-------------+ | 0x1 | IPv4 Address+ Port | 48b | Section 3.1 | +------+-------------------------+------+-------------+ | 0x2 | SRv6 | 128b | Section 3.2 | +------+-------------------------+------+-------------+ | 0x3 | Compressed Segment List | 128b | Section 3.3 | +------+-------------------------+------+-------------+ Table 2: Segment Types SR Hdr Len: SR Header length, include the SR Header flags Segment- List and Optional TLV. Last Entry: contains the index(zero based), in the Segment List, of the last element of the Segment List. Segments Left: 8-bit unsigned integer. Number of route segemnts remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination. Fang, et al. Expires 31 December 2020 [Page 5] Internet-Draft Segment Routing over UDP(SRoU) June 2020 Segment List[0..n]: 128-bit/48-bit/144-bit addresses to represent the SR Policy. Detailed forwarding behavior will be defined in Section 3 TLV: Opptional TLV used for future extension.currently only defined the following TLV. +------+----------------------+----------+---------------+ | Type | Value | Len | Section | +======+======================+==========+===============+ | 0x0 | SR Integrity | 32b | Section 3.4.1 | +------+----------------------+----------+---------------+ | 0x1 | Micro Segment Policy | variable | Section 3.4.2 | +------+----------------------+----------+---------------+ | 0x2 | End.PacketInfo | variable | Section 3.4.3 | +------+----------------------+----------+---------------+ Table 3: Optional TLV 3. Packet Processing This section describe the packet proccessing procedure. The following topology will be used in this section. H1---R1----------I1------R3----------+---R4---H2 | | |-----------R2------------------| | | I2 I1,I2: Interim Node that support SRoU R1~R4: Traditional Router H1,H2: Host Figure 3: Topology for packet proccesing Fang, et al. Expires 31 December 2020 [Page 6] Internet-Draft Segment Routing over UDP(SRoU) June 2020 +------+----------------------+-----------+----------------+ | Host | Address | SRoU Port | Post NAT | +======+======================+===========+================+ | H1 | 192.168.1.2 | 5111 | 10.1.1.1:23456 | +------+----------------------+-----------+----------------+ | R1 | 192.168.1.1/10.1.1.1 | | | +------+----------------------+-----------+----------------+ | R2 | 10.1.2.2 | | | +------+----------------------+-----------+----------------+ | R3 | 10.1.3.3 | | | +------+----------------------+-----------+----------------+ | R4 | 10.1.4.4 | | | +------+----------------------+-----------+----------------+ | H2 | 10.99.2.2 | 443 | 10.1.4.4:443 | +------+----------------------+-----------+----------------+ | I1 | 10.99.1.1 | 8811 | | +------+----------------------+-----------+----------------+ | I2 | 192.168.99.2 | 8822 | 10.1.2.2:12345 | +------+----------------------+-----------+----------------+ Table 4: IP address table 3.1. Type:0x1, IPv4 Locator Mode In this mode, the endpoint could directly insert the interim node IPv4 addresses and port into the segment-list. For example, H1 intend to send packet to H2 via R1->I2--->H2, In this case SRoU packet will be NATed twice to show the NAT traversal workflow. I2's public address could use STUN[RFC5389] protocol detected and sync to all SRoU enabled devices. H1 send packet with SRoU Header as below, H1 could use STUN detect it's source public address, but consider the simplicity, the 1st hop SRoU forwarder cloud update the source ip/port field in SRoU header. Fang, et al. Expires 31 December 2020 [Page 7] Internet-Draft Segment Routing over UDP(SRoU) June 2020 IP/UDP Header { Source IP: 192.168.1.2, Destination IP: 10.1.2.2(SegmentList[1],I2 Pre-NAT public address), Source Port: 5111, Destination Port: 12345(SegmentList[1],I2 Pre-NAT public port), } SRoU Header { Magic Num = 0x0 SRoU Length = 29 FlowID Length = 0x3 Protocol-ID = 0x1(IPv4), FlowID = 0x123, Source Address = 192.168.1.2, Source Port = 5111, Segment Left = 0x1, Last Entry = 0x1, SegmenetList[0] = 10.1.4.4:443(H2), SegmenetList[1] = 10.1.2.2:12345(I2), } Figure 4: Type:0x1 H1-->I2 Packet Header R1 is a NAT Device it will change the Source IP/Port to 10.1.1.1:23456. But this router may not have ALG function to modify SRoU Header.Then packet will send to 10.1.2.2:12345. It will be NAT again to I2. After twice NAT, I2 Recieved packet as below: IP/UDP Header { Source IP: 10.1.1.1(H1 post NAT addr), Destination IP: 192.168.99.2(I2 private addr), Source Port: 23456(H1 post NAT port), Destination Port: 8822(I2 private port), } SRoU Header { Magic Num = 0x0 SRoU Length = 29 FlowID Length = 0x3 Protocol-ID = 0x1(IPv4), FlowID = 0x123, Source Address = 192.168.1.2, Source Port = 5111, Segment Left = 0x1, Last Entry = 0x1, SegmenetList[0] = 10.1.4.4:443(H2), SegmenetList[1] = 10.1.2.2:12345(I2), } Fang, et al. Expires 31 December 2020 [Page 8] Internet-Draft Segment Routing over UDP(SRoU) June 2020 Figure 5: Type:0x1 H1-->I2, I2 Recieved Packet Header if the (LastEntry == Segment Left) indicate I2 is the 1st hop SRoU forwarder, It MUST apply ALG to update the Source Address/Port field by the IP/UDP header. Then it will execute Segment Left - 1, and copy SegmentList[0] to DA/Dport. Consider some interim router like R2 has URPF checking, the SA/Sport will also updated to I2 SRoU socket address. I2-->H2 packet: IP/UDP Header { Source IP: 192.168.00.2(I2 Private), Destination IP: 10.1.4.4(SegmentList[0]), Source Port: 8822(I2 Private), Destination Port: 443(SegmentList[0]), } SRoU Header { Magic Num = 0x0 SRoU Length = 29 FlowID Length = 0x3 Protocol-ID = 0x1(IPv4), FlowID = 0x123, Source Address = 10.1.1.1(update by I2 ALG), Source Port = 23456(update by I2 ALG), Segment Left = 0x0(SL--), Last Entry = 0x1, SegmenetList[0] = 10.1.4.4:443(H2), SegmenetList[1] = 10.1.2.2:12345(I2), } Figure 6: Type:0x1 I2-->H2 Packet Header H2 will recieve the packet, and if the segment left == 0, it MUST copy the Source Address and Port into IP/UDP Header and strip out the SRoU Header and send to udp socket. It may cache the reversed segmentlist for symmetric routing. H2 send to UDP socket IP/UDP Header { Source IP: 10.1.1.1(Copied from SRoU Src field), Destination IP: 10.99.2.2(Static NAT by R4), Source Port: 23456(Copied from SRoU Src field), Destination Port: 443(SegmentList[0]), } UDP Payload { } Fang, et al. Expires 31 December 2020 [Page 9] Internet-Draft Segment Routing over UDP(SRoU) June 2020 Figure 7: Type:0x1 H2 Send to UDP socket 3.2. Type:0x2, SRv6 format IPv6 does not need to consider the NAT traversal case, In this mode almost forwarding action is same as SRv6. This is only used for application driven traffic steering(like CDN/LB usecase.). It has some benefit interworking with QUIC, the pure userspace implementation could provide additional flexibility. For example some IOT sensor with legacy kernel stack does not support SRv6 could use SRoU insert SRH in UDP payload, the 1st hop SRoU forwarder could convert it to standard SRv6 packet. 3.3. Type:0x3, Compressed Segment List 3.3.1. Service Registration & Mapping I1,I2 use SRoU port as source port to inital STUN[RFC5389] session to SR mapping server, the mapping server could detect the Post NAT address and assign SID for each host, and distribute IP/port-SID mapping database to all the SRoU enabled host. +------+----------------+------+ | Host | Socket | SID | +======+================+======+ | I1 | 10.99.1.1:8811 | 1111 | +------+----------------+------+ | I2 | 10.1.2.2:12345 | 2222 | +------+----------------+------+ Table 5: sid mapping In this mode the socket information could combined with IPv4 and IPv6. 3.4. Optional TLV 3.4.1. SR Integrity TLV SR Integrity Tag to validate the SRH. All fields in the SRH except Segments Left fields need to be checked. 3.4.2. Micro-segmentation(uSeg) Option-TLV could defined Sub-TLV to support Micro-segmentation Security policy Fang, et al. Expires 31 December 2020 [Page 10] Internet-Draft Segment Routing over UDP(SRoU) June 2020 OptionTLV { 0x1, uSeg{ 0x0, SRC_GROUP_ID, 0x1, DST_GROUP_ID, 0x2, APP_GROUP_ID, 0x3, SRC_DEVICE_ID, 0x4, DST_DEVICE_ID, 0x5, APP_ID, } } Customer also could encode this microsegment policy header in flowID field. 3.4.3. End.PacketInfo This optional TLV defines extened packet info and Segment-end packet edit function. Sub-TLV defines as below: 3.4.3.1. Type:0x0, VPN-ID The SDWAN Router could use [I-D.ietf-quic-datagram] as VPN tunnel, This Sub-TLV defined the VPN-ID inside the tunnel. If SRoU header has this sub-TLV, the device MUST decrypt inner payload and use the VPN-ID for inner packet destination lookup. 3.4.3.2. Type:0x1, Orginal Destination Address/Port In SR Type 0x3, The original destination address/port cloud not encode in 128bit field, it could be store in option TLV. 4. Usage 4.1. Traffic engineering over Internet Client-------R1------------Internet--------------R2-----------Server | | | | R3----V1----PubliCloud--------V2-----| Figure 8: Traffic Engineering over internet Many video/conferencing application requires traffic engineering over IPv4 Internet, Webex/Zoom/Teams may setup V1,V2 in public cloud, The client and server could encode the V1/V2 information in SRoU header for traffic engineering Fang, et al. Expires 31 December 2020 [Page 11] Internet-Draft Segment Routing over UDP(SRoU) June 2020 4.2. Multipath forwarding Same as previously topoloy Figure 8, customer cloud ask server transmit packet over different path, two path have same Flow-ID, QUIC could be used in this case to provide multistream/multihoming support. 4.3. Micro Segmentation Same as previously topoloy Figure 8, the interim Router: R1/R2/R3, V1,V2 could insert uSeg Sub-TLV based on client and server uSeg identity, and other interim network equipment could based on this sub-TLV implement security policy or QoS policy. 4.4. Container Network C1----SideCar1-----L1-----S1------L2----SideCar2-------C2 | | |------S2-------| C1,C2: Container L1,L2: Leaf switch S1,S2: Spine switch Figure 9: Service-Mesh & Container Network SRoU with QUIC also could be used for container network interface, especially for service-mesh sidecar. The sidecar could aware the Datacenter underlay topology by BGP-LinkState, and use SRH select best path to avoid congestion. At the same time, all traffic are encrypted by [I-D.ietf-quic-tls]. 4.5. MPLS-SR with SDWAN S1---INET(ipv4)----PE1------MPLS------PE2----S2 S1,S2: SDWAN Router PE1,PE2: SR enabled MPLS PE Figure 10: MPLS-SR with SDWAN S1 will setup IPSec SA with S2 for end-to-end encryption, And it will use BSID between PE1-PE2 for traffic engineering. MPLS based BSID and IPv4 based locator could be encoded in uSID.A distributed mapping table could be used to translate uSID to packet action. Fang, et al. Expires 31 December 2020 [Page 12] Internet-Draft Segment Routing over UDP(SRoU) June 2020 IP/UDP Header { Source IP: H1, Destination IP: PE1, Source Port: srcport, Destination Port: IPSec, } SRoU Header { SegmentType = 0x1, SR_HDR_Len = 2, Last Entry = 0x0, Segment Left = 0, SegmenetList[0] = uSID: FC0:2222:3333:4444:: } Figure 11: Type:0x1 S1-->PE1 Packet Header 4.6. Cloud Native Network platform Each of the SRoU forwarder only rely on a UDP socket, it could be implement by a container. Customer could deploy such SRoU enable container in multiple cloud to provide a cloud-angonostic solution. All containers could be managed by K8S. A distributed K-V store could be used for SRoU forwarder service registration, routing(announce prefix), all the SRoU forwarder could measue peer's reachability/jitter/loss and update link-state to the K-V store. forwarding policy also could be sync by the K-V store. Detailed information will be provided in another I.D(ETCD based disaggregated SDN control plane). SRoU forwarder also could be implement by BPF for container communication. It will provide host level traffic engineering for massive scale datacenter to reduce the West-East traffic congestion. The best practice for SRoU is working with QUIC. SRoU with QUIC transport protocol provides the following benefit for SDWAN : * Stream multiplexing * Stream and connection-level flow control * Low-latency connection establishment * Connection migration and resilience to NAT rebinding * Authenticated and encrypted header and payload Fang, et al. Expires 31 December 2020 [Page 13] Internet-Draft Segment Routing over UDP(SRoU) June 2020 SRoU add traffic-engineering and VPN capabilites for SDWAN. Many existing SDWAN features could gain the benefits like: * TCP optimization * Packet duplication 5. Security Considerations The SRoU forwarder must validate the packet, FlowID could be used for source validation. It could be a token based solution, this token could be assigned by controller with a dedicated expire time. Source/Dest device ID and group cloud encode in flowid and signed by controller, just like JWT. A blacklist on controller k-v store could be implemented to block device when the token does not expire. 6. IANA Considerations 6.1. SRoU with QUIC The magic number in SRoU must be ZERO to distiguish with QUIC Long/ Short packet format. Acknowledgements The following people provided substantial contributions to this document: * Bin Shi, Cisco Systems, Inc. * Yijen Wang, Cisco Systems, Inc. * Pix Xu, Cisco Systems, Inc. * Xing James Jiang, Cisco Systems, Inc. References Normative References [I-D.ietf-quic-datagram] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", Work in Progress, Internet- Draft, draft-ietf-quic-datagram-00, 26 February 2020, . Fang, et al. Expires 31 December 2020 [Page 14] Internet-Draft Segment Routing over UDP(SRoU) June 2020 [I-D.ietf-quic-tls] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-tls-29, 9 June 2020, . [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, . [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 2015, . [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, DOI 10.17487/RFC8663, December 2019, . [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Authors' Addresses Kevin Fang Cisco Systems, Inc. Email: zartbot.ietf@gmail.com Yinghao Li Google, Inc. Fang, et al. Expires 31 December 2020 [Page 15] Internet-Draft Segment Routing over UDP(SRoU) June 2020 Email: liyinghao@gmail.com Feng Cai Cisco Systems, Inc. Email: fecai@cisco.com Fang, et al. Expires 31 December 2020 [Page 16]