Network Working Group L. Gong Internet Draft China Mobile Intended status: Standards Track C. Lin Expires: March 29, 2025 New H3C Technologies September 29, 2024 Link Discovery Protocol (LLDP) Extensions for Segment Routing over IPv6 (SRv6) draft-gong-spring-lldp-srv6-extensions-00 Abstract This document describes the method of carrying SRv6 Locator information through the LLDP protocol to simplify SRv6 deployment. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on March 29, 2025. Copyright Notice Copyright (c) 2024 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 (http://trustee.ietf.org/license-info) in effect on the date of Gong, et al. Expires March 29, 2025 [Page 1] Internet-Draft LLDP Extensions for SRv6 September 2024 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. Table of Contents 1. Introduction...................................................3 1.1. Requirements Language.....................................3 2. Use Cases......................................................4 2.1. Problem...................................................4 2.2. Solution..................................................4 3. LLDP Extension.................................................6 3.1. SRv6 Locator TLV..........................................6 3.2. SRv6 Capabilities TLV.....................................8 4. Security Considerations........................................9 5. IANA Considerations............................................9 6. References.....................................................9 6.1. Normative References......................................9 Authors' Addresses...............................................10 Gong, et al. Expires March 29, 2025 [Page 2] Internet-Draft LLDP Extensions for SRv6 September 2024 1. Introduction The Link Layer Discovery Protocol (LLDP) [802.1AB] is a standard link layer protocol that allows network devices to discover neighbors and exchange information. With Segment Routing (SR) [RFC8402], a node steers a packet through an ordered list of instructions, which are called segments.Segments are identified through Segment Identifiers (SIDs). SR can be directly instantiated on the IPv6 data plane through the use of the Segment Routing Header (SRH) defined in [RFC8754]. SRv6 refers to this SR instantiation on the IPv6 data plane. The network programming paradigm [RFC8986] is central to SRv6. It describes how any behavior can be bound to a SID and how any network program can be expressed as a combination of SIDs. For SRv6 networking, the SRv6 Locator information of each device within an autonomous system is usually carried by IGP protocols, while BGP is used for inter-domain advertising. Hosts typically do not support complex routing protocols, and thus cannot dynamically advertise their own Locator information. This presents challenges for deploying SRv6 networks. Therefore, a simplified SRv6 deployment method is needed to enable SRv6 Locator routing between access devices and hosts. This document describes a method for carrying SRv6 Locator information via the LLDP protocol to simplify SRv6 deployment. The SRv6 Locator sub-TLV announces SRv6 Locators -- a form of summary address for the set of topology-/algorithm-specific SIDs instantiated at the node. The SRv6 Capabilities sub-TLV announces the ability to support SRv6. This document specifies the IETF Organizationally Specific TLV for LLDP, which includes the SRv6 Locator sub-TLV and the SRv6 Capabilities sub-TLV. 1.1. Requirements Language 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. Gong, et al. Expires March 29, 2025 [Page 3] Internet-Draft LLDP Extensions for SRv6 September 2024 2. Use Cases 2.1. Problem As shown in Figure 1, the SRv6 network comprises Host, Access, Spin, and Core segments. Information is exchanged between the Host and Access via LLDP, between Access and Spin through IGP, and between Spin and Core using BGP. The SRv6 Locator information is transmitted between Access and Spin using the IGP protocol, and between Spin and Core using the BGP protocol. However, since Hosts generally do not support complex routing protocols, they cannot automatically transmit their SRv6 Locator information to the devices. This limitation complicates the deployment of SRv6 networks. +----+ LLDP+------+ IGP +------+BGP +------+ |Host+-----+Access+-----+ Spin +----+ Core + +----+ +------+ +------+ +------+ Figure 1 2.2. Solution By extending the LLDP protocol to carry SRv6 Locator information, Hosts and Access devices can exchange all SRv6 Locator information within an SRv6 network via LLDP, facilitating the deployment of SRv6. The SRv6 Locator are advertised in IGP, and collected by the controller using NETCONF or BGP-LS. The srv6 locator are advertised in LLDP between the host and access through LLDP, and are advertised via IGP within the domain. This information is collected by the controller using NETCONF or BGP-LS. Gong, et al. Expires March 29, 2025 [Page 4] Internet-Draft LLDP Extensions for SRv6 September 2024 +----------+ BGP-LS |Controller|<-----------------+ +----------+ | ^ ^ | NETCONF | | NETCONF | | +----------+ | | | | | | | +----+ LLDP+------+ IGP +------+BGP +------+ |Host+-----+Access+-----+ Spin +----+ Core + +----+ +------+ +------+ +------+ ^ ^ | | +--- LLDP --+ SRv6 Locator Figure 2 The specific process is as follows: 1) Enable LLDP on both Host and Access. 2) The Host advertises the SRv6 locator FC00:0:11::/48 and its SRv6 capability through LLDP. 3) The Access device learns the SRv6 locator FC00:0:11::/48 via LLDP. 4) Using IGP, the Access device re-advertises the SRv6 locator FC00:0:11::/48 obtained from LLDP to the Spine device. 5) The Spine device learns the SRv6 locator FC00:0:11::/48 route through IGP. 6) A BGP neighbor relationship is established between the Spine and Core devices, and the learned SRv6 locator FC00:0:11::/48 is sent to the Core using BGP-LS routes. 7) The Core device learns the SRv6 locator FC00:0:11::/48 via BGP-LS. 8) A BGP neighbor relationship is established between the Core device and the controller, and the SRv6 locator FC00:0:11::/48 is sent to the controller via BGP-LS routes. Gong, et al. Expires March 29, 2025 [Page 5] Internet-Draft LLDP Extensions for SRv6 September 2024 3. LLDP Extension 3.1. SRv6 Locator TLV LLDP TLVs that belong to an organization are identified by the inclusion of the organization's OUI (Organizationally Unique Identifier) and an organizationally defined subtype in the initial octets of the information field. This document defines a new IETF specific subtype, SRv6 Locator, under the IANA OUI. The LLDP IETF Organizationally Specific TLV of the new-defined subtype carries the local SRv6 Locator, which has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (127) |Length (variable)| OUI (3 Octets) 00-00-5E | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI Continued | Subtype (TBD) | SRv6 Locator TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRv6 Locator TLV Continued | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: o Type: IETF Organizationally Specific TLV type value, 127. o Length: Length of the remainder of the TLV, variable. o OUI: Organizationally Unique Identifier. For IETF use, this field is the IANA OUI (00-00-5E) as specified in RFC 7042. o Subtype: Subtype for SRv6 locator, TBD. o SRv6 Locator: SRv6 locator. The format of each SRv6 Locator TLV is as follows: Gong, et al. Expires March 29, 2025 [Page 6] Internet-Draft LLDP Extensions for SRv6 September 2024 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type | Length |R|R|R|R| MTID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LocSize | Locator (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |sub-tlv-len | Sub-Tlvs (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: o Sub-Type: 8 bits, The Sub-TLV Type value for locator shall be 1. o Length: 8 bits, variable. o MTID: 12 bits, Multi-Topology Identifier. o Metric: 32 bits, Cost. o Flags: 8 bits, Reserved. o Algorithm: 8 bits Algorithm: - 0: Shortest Path First (SPF). - 1: Strict Shortest Path First (Strict SPF). o Loc Size: 8 bits, Locator Length. o Locator (variable): Variable length, indicates the advertised SRv6 Locator. o sub-tlv-len: 8 bits, Sub-TLV Length. o Sub-TLVs (variable): Variable length, contains Sub-TLVs such as SRv6 End SID Sub-TLV. Gong, et al. Expires March 29, 2025 [Page 7] Internet-Draft LLDP Extensions for SRv6 September 2024 3.2. SRv6 Capabilities TLV To support the SRv6 functionality, the Host also needs to advertise SRv6-related capabilities through LLDP. The LLDP extension format for SRv6 capabilities is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (127) |Length (variable)| OUI (3 Octets) 00-00-5E | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI Continued | Subtype (TBD2)| SRv6 Capbility TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRv6 Capbility TLV Continued | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: IETF Organizationally Specific TLV type value, 127. o Length: Length of the remainder of the TLV, variable. o OUI: Organizationally Unique Identifier. For IETF use, this field is the IANA OUI (00-00-5E) as specified in RFC 7042. o Subtype: Subtype for SRv6 Capabilities, TBD2. o SRv6 Capbility TLV: SRv6 Capbility sub-TLV, format as follow: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | optional sub-sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: o Sub-Type: 8 bits, The Sub-TLV Type value for SRv6 capability shall be 1. o Length: 8 bits, variable. o Flags: 8 bits, Reserved. o optional sub-sub-TLVs, such as Node MSD sub-TLV. Gong, et al. Expires March 29, 2025 [Page 8] Internet-Draft LLDP Extensions for SRv6 September 2024 For optional MSD sub-sub-TLVs, the format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-sub-Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSD-Type | MSD-Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSD-Type | MSD-Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: o sub-sub-Type: 8 bits, The sub-sub-TLV Type value for MSD shall be 1. o Length: 8 bits, variable. o MSD-Type: 8 bits. o MSD-Value: 8 bits. 4. Security Considerations TBD. 5. IANA Considerations TBD. 6. References 6.1. Normative References [802.1AB] "IEEE Standard for Local and metropolitan area networks- Station and Media Access Control Connectivity Discovery", IEEE Std 802.1AB-2016, 29 January 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. Gong, et al. Expires March 29, 2025 [Page 9] Internet-Draft LLDP Extensions for SRv6 September 2024 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [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, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . Authors' Addresses Liyan Gong China Mobile China Email: gongliyan@chinamobile.com Changwang Lin New H3C Technologies China Email: linchangwang.04414@h3c.com Gong, et al. Expires March 29, 2025 [Page 10]