Network Working Group                                           L. Gong
Internet Draft                                             China Mobile
Intended status: Standards Track                                 C. Lin
Expires: April 28, 2025                            New H3C Technologies
                                                               Z. Zhang
                                                                    ZTE
                                                       October 21, 2024


     Link Discovery Protocol (LLDP) Extensions for Segment Routing over
                               IPv6 (SRv6)
                 draft-gong-spring-lldp-srv6-extensions-01


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).  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 April 28, 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
   (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 Revised BSD License text as described in



Gong, et al.           Expires April 28, 2025                 [Page 1]

Internet-Draft         LLDP Extensions for SRv6           October 2024


   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Revised BSD License.

Table of Contents


   1. Introduction...................................................2
      1.1. Requirements Language.....................................3
   2. Use Cases......................................................3
      2.1. Problem...................................................3
      2.2. Solution..................................................3
   3. LLDP Extension.................................................5
      3.1. SRv6 Locator TLV..........................................5
      3.2. SRv6 Capabilities TLV.....................................7
   4. Security Considerations........................................8
   5. IANA Considerations............................................8
   6. References.....................................................8
      6.1. Normative References......................................8
   Authors' Addresses................................................9

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.


Gong, et al.           Expires April 28, 2025                 [Page 2]

Internet-Draft         LLDP Extensions for SRv6           October 2024


   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.

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.


Gong, et al.           Expires April 28, 2025                 [Page 3]

Internet-Draft         LLDP Extensions for SRv6           October 2024


   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.

                +----------+      BGP-LS
                |Controller|<-----------------+
                +----------+                  |
                                              |
                                              |
                                              |
                                              |
                                              |
       +----+ 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 April 28, 2025                 [Page 4]

Internet-Draft         LLDP Extensions for SRv6           October 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 April 28, 2025                 [Page 5]

Internet-Draft         LLDP Extensions for SRv6           October 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 April 28, 2025                 [Page 6]

Internet-Draft         LLDP Extensions for SRv6           October 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 April 28, 2025                 [Page 7]

Internet-Draft         LLDP Extensions for SRv6           October 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 April 28, 2025                 [Page 8]

Internet-Draft         LLDP Extensions for SRv6           October 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, <https://www.rfc-editor.org/info/rfc8402>.

   [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,
             <https://www.rfc-editor.org/info/rfc8754>.

   [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, <https://www.rfc-
             editor.org/info/rfc8986>.

Authors' Addresses

   Liyan Gong
   China Mobile
   China

   Email: gongliyan@chinamobile.com

   Changwang Lin
   New H3C Technologies
   China
   Email: linchangwang.04414@h3c.com

   Zheng(Sandy) Zhang
   ZTE Corporation
   China
   Email: zzhang_ietf@hotmail.com
















Gong, et al.           Expires April 28, 2025                 [Page 9]