






      
      
     Network Work Group                                          P. Bottorff
     Internet-Draft                                     HPE Aruba Networking
     Intended status: Standards Track                             P. Congdon
     Expires: January 23, 2026                       Congdon Consulting, LLC
                                                               July 22, 2025
      
      
         Using IEEE Std 802.1AB (LLDP) for IETF LSVR neighbor discovery and
                                    configuration  
                           draft-bottorff-lsvr-lldp-01.txt 


     Abstract 

        IEEE Std 802.1AB, known as the Link Layer Discovery Protocol (LLDP),
        can be applied to LSVR neighbor discovery and configuration. This can
        be achieved by using a "nearest router group address" as the LLDP 
        Scope MAC Address to target LSVR interfaces while advertising a set
        of LSVR-specific LLDP TLVs. These LSVR-specific TLVs are defined 
        using LLDP Organizationally Specific TLVs, as specified by LLDP for 
        use by individual organizations to allow them to define their own 
        Type-Length-Value (TLV) objects for exchange over the LLDP protocol. 
        The IETF Organizationally Specific TLVs for LSVR can be encoded using
        the IETF IANA OUI (RFC 9542). This document provides an overview of 
        applying LLDP to LSVR neighbor discovery and configuration and 
        specifies the IETF Organizationally Specific TLVs that support link 
        discovery for LSVR routers. In addition, a brief discussion of the 
        use of IEEE Connectivity Fault Management (CFM) as specified in IEEE
        Std 802.1Q-2022 cl 18-22 for link liveliness is included.  

     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 November 22, 2025. 
      
      
     Bottorff               Expires January 23, 2026                [Page 1]
      






     Internet-Draft            LSVR TLVs for LLDP                  July 2025
         

     Copyright Notice 

        Copyright (c) 2025 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 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...................................................3 
           1.1. Requirements Notation.....................................4 
              1.1.1. Requirements Language................................4 
        2. Terminology....................................................5 
        3. Abbreviations..................................................5 
        4. LLDP Operation.................................................6 
           4.1. Nearest Router Scope MAC Address for LLDP.................7 
           4.2. Logical Link Endpoint Identification......................8 
           4.3. Layer-2 Link Liveliness...................................8 
           4.4. LLDP Organizationally Specific TLVs.......................9 
              4.4.1. Type................................................10 
              4.4.2. Length..............................................10 
              4.4.3. Organizationally Unique Identifier..................10 
              4.4.4. Subtype.............................................10 
              4.4.5. Information.........................................10 
           4.5. LLDP IETF Organizationally Specific TLVs for LSVR........11 
           4.6. LSVR LLDP L3 data link application.......................12 
        5. Encapsulation TLVs for LSVR...................................12 
           5.1. Encaps Flags.............................................13 
              5.1.1. Announce............................................13 
              5.1.2. Primary.............................................13 
              5.1.3. Under/Over..........................................13 
              5.1.4. Loopback............................................13 
              5.1.5. Reserved............................................14 
           5.2. IPv4 Announcement TLV....................................14 
              5.2.1. Encaps Flags........................................14 
              5.2.2. IPv4 Address........................................14 
              5.2.3. Prefix Length.......................................14 
              5.2.4. IPv4 Announcement TLV usage rules...................15 
      
      
     Bottorff               Expires January 23, 2026                [Page 2]
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025
         

           5.3. IPv6 Announcement TLV....................................15 
              5.3.1. Encaps Flags........................................15 
              5.3.2. Prefix Length.......................................15 
              5.3.3. IPv6 Address........................................16 
              5.3.4. IPv6 Announcement TLV usage rules...................16 
           5.4. MPLS IPv4 Announcement TLV...............................16 
              5.4.1. MPLS Label List.....................................16 
                 5.4.1.1. Label Count....................................17 
                 5.4.1.2. Label..........................................17 
                 5.4.1.3. Exp............................................17 
                 5.4.1.4. S..............................................17 
              5.4.2. Encaps Flags........................................17 
              5.4.3. Prefix Length.......................................17 
              5.4.4. IPv4 Address........................................17 
              5.4.5. IPv4 Announcement TLV usage rules...................18 
           5.5. MPLS IPv6 Announcement TLV...............................18 
              5.5.1. MPLS Label List.....................................18 
              5.5.2. Encaps Flags........................................18 
              5.5.3. IPv6 Address........................................19 
              5.5.4. Prefix Length.......................................19 
              5.5.5. MPLS IPv6 Announcement TLV usage rules..............19 
        6. Upper-Layer Protocol Configuration TLVs.......................19 
              6.1.1. AttrTypes...........................................19 
              6.1.2. BGP ASN.............................................20 
              6.1.3. BGP IPv4 Peering Address............................20 
              6.1.4. BGP IPv6 Peering Address............................20 
              6.1.5. BGP Authentication Data.............................20 
              6.1.6. BGP Flags...........................................20 
              6.1.7. BGP Protocol Configuration TLVs usage rules.........21 
        7. Security Considerations.......................................21 
        8. IANA Considerations...........................................21 
        9. Conclusions...................................................21 
        10. References...................................................21 
           10.1. Normative References....................................21 
        11. Acknowledgments..............................................23 
         
     1. Introduction 

        The IEEE Std 802.1AB [802.1AB][802.1ABcu][802.1ABdh], commonly known
        as the Link Layer Discovery Protocol (LLDP), is an extremely simple 
        L2 protocol used to advertise the identity and capabilities of 
        router, switch, bridge, and end-station ports to network neighbors. 
        It is supported by many vendors and is widely deployed in data 
        centers and campus networks where it provides information used to 
        identify neighbors, capabilities, and current state. The LLDP 
        information is used in turn by management systems to map the network

      
      
     Bottorff               Expires January 23, 2026                [Page 3]
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025
         

        topology and capabilities and by LLDP applications to perform 
        protocol configuration.  

        The LLDP protocol operates over both point-to-point and multipoint 
        networks. It can be used to advertise neighbors and capabilities 
        both at the physical port level and at virtual interfaces within 
        systems. LLDP provides three standardized advertisement scopes which
        identify the type of port being advertised. These standard types are
        identified by a multicast Scope MAC Addresses which is used as an 
        LLDP destination address. The standard port types are nearest 
        bridge, nearest non-TPMR bridge, and nearest customer bridge. In 
        addition, the standard allows the use of an alternate group MAC 
        address or individual MAC address for the Scope MAC Address. For 
        LSVR an alternate Scope MAC Address can be used to identify router 
        ports which are internal to a switch or to identify router ports 
        that are behind a bridged network. 

        LLDP provides a means for individual organizations to define their 
        own Type-Length-Value (TLV) objects for exchange over the protocol. 
        TLVs that belong to an organization are identified by the inclusion 
        of the organization's OUI and an organizationally defined subtype in
        the initial octets of the information field.   

        The IETF is a standards development organization with an IANA OUI. 
        The usage and considerations for this OUI are discussed in 
        [RFC9542]. The IANA OUI can be used to identify IETF specific LLDP 
        Organizationally Specific TLVs. 

        The LSVR working group is specifying protocols that need to discover
        IP Layer 3 attributes of links, encapsulations and neighbors. This 
        document specifies a set of IETF LLDP Organizationally Specific TLVs 
        that carry the necessary discovery attributes for LSVR working group 
        protocols. 

     1.1. Requirements Notation 

     1.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. 

         


      
      
     Bottorff               Expires January 23, 2026                [Page 4] 
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025 
         

     2. Terminology 

        Extended Link Layer Discovery Protocol: Refer to [8021.ABdh] 

        Extension LLDP PDU: Refer to [8021.ABdh] 

        Extension Request LLDP PDU: Refer to [8021.ABdh] 

        Link or Logical Link: A logical connection between two logical ports 
        on two devices. E.g. two VLANs between the same two ports are two 
        links. 

        Logical Link Endpoint: One end of a logical link. 

        Logical Link Endpoint Identifier: The unique identifier for a 
        Logical Link Endpoint. 

        LLDP Protocol Data Unit: Refer to [802.1AB] 

        Manifest LLDP PDU: Refer to [8021.ABdh] 

        Normal LLDP PDU: Refer to [8021.ABdh] 

        Scope MAC Address: Refer to [8021.ABdh] 

     3. Abbreviations 

        LLDP - Link Layer Discovery Protocol 

        LLEI - Logical Link Identifier 

        TLV - Type-Length-Value 

        XLLDP - Extended Link Layer Discovery Protocol 

        XPDU - Extension LLDPDU 

        XREQ - Extension Request LLDPDU 









      
      
     Bottorff               Expires January 23, 2026                [Page 5] 
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025 
         

     4. LLDP Operation 

            Local Databases         Remote Databases 
        +----------------------+ +----------------------+ 
        | Organizationally     | | Organizationally     | 
        | defined local device | | defined remote device| +--+ 
        | LLDP YANG extensions | | LLDP YANG extensions | |  | +-----------+ 
        +----------------------+ +----------------------+ |  |-|   System  | 
                   |                         |            |  | | Management| 
          +------------------+     +-------------------+  |  | +-----------+ 
          |LLDP local system |     |LLDP remote systems|  |  | 
          |      YANG        |     |       YANG        |  |  | +-----------+ 
          +------------------+     +-------------------+  |  |-| Interface | 
                   |                         |            |  | | Management| 
            +---------------------------------------------+  | +-----------+ 
            |      LLDPDU Transmission and Reception         | 
            |                                                | +-----------+ 
            +---------------------------------------------+  |-| Router    | 
                             |     ^                      |  | | Management| 
                             | L F |                      +--+ +-----------+ 
                             | L r |                       
               Local device  | D a | Remote device 
               information   | P m | information 
                             |   e | 
                             |   s | 
                             |     | 
                           (Interface) 
         
                          Figure 1 LLDP Agent and databases 

        Figure 1 is a simplified illustration of figure 6-1 from [802.1AB]. 
        It illustrates an LLDP Agent and its relationship to the databases. 
        For a more detailed description refer to clause 6 of [802.1AB].  

        LLDP is a link layer protocol that allows an Ethernet device to 
        advertise the capabilities and status of a system interface. The 
        local database (see figure 1) is loaded with the information to be 
        advertised by the interface. The LLDP Agent at the interface 
        periodically encodes the local database into LLDP PDUs and transmits
        a Normal LLDP PDU destined to the Scope MAC Address. The interfaces 
        subscribed to the Scope MAC Address receive the incoming LLDP PDUs 
        and direct them to the LLDP Agent based on the LLDP PDU destination 
        address and the LLDP Ethertype 0x88CC. The information received in 
        LLDP PDUs is stored by the LLDP Agent in the remote database. The 
        local database contains the information advertised by LLDP for the 
        interface, while the remote database contains the information 
        received from each remote interface. 
      
      
     Bottorff               Expires January 23, 2026                [Page 6] 
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025 
         

        In the event the TLVs that encode the local database do not fit in a
        single LLDP PDU (which is a single frame), the LLDP Agent will 
        encode additional TLVs in extension LLDP PDUs (XPDUs) and will add a
        Manifest TLV to the Normal LLDP PDU. The Manifest TLV contains a 
        digest of each XPDU. The receiver of a Normal TLV containing a 
        Manifest TLV will decide if any of the XPDUs contains new 
        information by comparing the digest for the XPDUs in its remote 
        database with the digest contained in the Manifest. If new XPDUs are
        found the receiver will make explicit requests for the new XPDUs 
        using the Extension Request LLDP PDU (XREQ). The transmitting LLDP 
        Agent responds to XREQs by sending the requested XPDUs. The LLDP 
        extended request response performed using the XREQ and XPDU exchange
        is performed using unicast addressing. Since the receiver makes 
        explicit requests for XPDUs it can determine the pacing rate based 
        on its processing overhead and resources. The receiver is 
        responsible for timing out and retrying failed XREQs. 

     4.1. Nearest Router Scope MAC Address for LLDP 

        There are two choices for how to address LLDP PDUs for application 
        to LSVR discovery and configuration. These are to use the Nearest 
        Bridge Address (01-80-C2-00-00-0E) [802.1AB] for the LLDP Scope MAC
        Address or to select an application specific Nearest Router 
        Multicast Address for use as the LLDP Scope MAC Address.  

        If the IEEE standard Nearest Bridge Address is used, the LLDP Agent 
        will be at the physical switch port. In this case, routers attached 
        to subinterfaces or Switched Virtual Interfaces (SVIs) will need to 
        support information for multiple Logical Link Endpoints within the 
        local LLDP databases on each physical port. The LLDP local databases
        will require the Logical Link Endpoint Identifier (LLEI), VLAN IDs, 
        and MAC addresses associated with each Logical Link Endpoint. In 
        addition, if the nearest bridge address is used, router interfaces 
        with bridges between them will not be discoverable because the LLDP 
        PDUs will not travel through the bridges. 

        If an LSVR specific Nearest Router, Multicast Address which is not a 
        member of the reserved bridge addresses, is selected for the LLDP 
        Scope MAC Address, then the LLDP Agents can be associated directly 
        with the router interfaces regardless of whether they are physical, 
        subinterfaces, or Switched Virtual Interfaces (SVIs). In addition, 
        such an address will allow LLDP to operate when a bridge intervenes 
        between the router interfaces.  

        Within this document a Nearest Router Multicast will be assumed as 
        the only LLDP Scope MAC Address used for the LSVR discovery 
        application. We believe this approach is consistent with the current 
      
      
     Bottorff               Expires January 23, 2026                [Page 7] 
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025 
         

        intent of draft-ietf-lsvr-l3dl. The Nearest Router Multicast Address 
        for the LSVR LLDP Scope MAC Address should be reserved for router 
        interface discovery applications by IANA. IEEE may also reserve the 
        nearest router multicast selected by IANA, however since the nearest 
        router multicast would not have any special meaning to the IEEE 802 
        protocols reservation by IEEE is not required. 

     4.2. Logical Link Endpoint Identification 

        Every LLDP PDU begins with a ChassisID TLV and a PortID TLV 
        [802.1AB]. These two TLVs identify the sending LLDP location which 
        is the equivalent of the draft-ietf-lsvr-l2dl Logical Link Endpoint 
        Identifier. The ChassisID provides a unique identifier for the 
        system, in this case an LSVR router (i.e. a MAC address, any IANA 
        address family identifier, see [8021.AB] for further details). The 
        PortID provides a unique identifier for the interface within the 
        system (i.e. port number, IfIndex, see [8021.AB] for further 
        details). 

        Within this draft we assume the use of a Nearest Router Multicast 
        Scope MAC Address for LLDP which places LLDP Agents at the Logical 
        Link Endpoint. Provided the LLDP Agent is advertising information 
        from each router interface (physical or virtual) the ChassisID and 
        PortID can be used as the Logical Link Endpoint Identifier. This 
        draft assumes the LLDP ChassisID and PortID are used to identify 
        Logical Link Endpoints. 

     4.3. Layer-2 Link Liveliness 

        Two mechanisms are available to determine layer-2 link liveliness. 
        These are the periodic LLDP PDU transmissions along with the LLDP 
        time-to-live protocol and the IEEE Connectivity Fault Management 
        (CFM) protocol as specified in IEEE Ste 802.1Q cl 18-22 [802.1Q].  

        The LLDP mechanism is part of the basic LLDP protocol. Every Normal 
        LLDP PDU contains a Time-To-Live TLV which specifies how long the 
        information advertised for each Logical Link Endpoint is valid. LLDP 
        retransmits the Normal LLDP PDU periodically to maintain the 
        liveliness of the information in the remote LLDP databases. The 
        default retransmit time for LLDP is once every 30 seconds and is 
        settable in 1 second steps. The Time-To-Live is calculated based on 
        the Normal LLDP PDU retransmit window to allow multiple LLDP PDU 
        retransmits before expiring. The default is 4 transmission times. A 
        time-to-live timeout is indicated to the coupled application layer, 
        in this case the router, which can take action to disable the 
        associated Logical Link(s). 

      
      
     Bottorff               Expires January 23, 2026                [Page 8] 
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025 
         

        The l3dl protocol specifies a hello timer of 10 seconds with a 
        timeout of 3 transmission intervals. The LLDP transmissions and 
        timeout can be set to match these values if desired. 

        The Connectivity Fault Management (CFM) mechanism provides a multi-
        level Operations, Administration and Maintenance facility that can 
        be used to provide liveliness as well as L2 network diagnostics. For 
        application to LSVR link liveless CFM Continuity Check Messages 
        (CCMs) can be generated from each Logical Link Endpoint by 
        implementing a CFM Management End Point(MEP) at each Logical Link 
        Endpoint. These CCM messages travel over a Maintenance Domain (MD) 
        within a Maintenance Association (MA).  

        The Maintenance Domain specifies the boundaries of the L2 
        communication such as Customer/Service Provider/Operator. The MD 
        levels nest, however never intersect allowing support for network 
        layering. The MD level are 0-7 where 7 is the broadest reach. Each 
        MD level also is named. For the application of LLDP to LSVR LLE 
        discovery there could be lower level domains. For instance, if the 
        LSVR router interface was attached to a MEF E-LINE service, then 
        there could be both service provider and operator MDs as part of the 
        router link. In this case the LSVR interface MD should be in the 
        upper level. Another possibility is that the LSVR router provides an 
        L2 service interface to the data center (perhaps to the overlay). In 
        this case there could be MDs of greater extent than the used for 
        LSVR link discovery. To allow for these two cases the MD selected 
        for LSVR link discovery could be MD level 5 which is the lowest 
        customer level allowing 0-4 for provider networking and 6-7 for data 
        center L2 services. 

        A Maintenance Association (MA) within a MD is defined by a set of 
        Maintenance End Points (MEPs) at the edge of the MD to monitor 
        connectivity of a particular service. In this case every LSVR LLE 
        can be part of an MA. 

        The Connectivity Check Messages (CCMs) running over LSVR Management 
        Associations can provide link continuity checking down to the 10 
        msec range. 

        Further support for rapid L2 link liveliness may also use the IEEE 
        802.3ah OAM procedures. Refer to IEEE 802.3 cl 57. 

     4.4. LLDP Organizationally Specific TLVs 

        IEEE Std 802.1AB defines the format of the Organizationally Specific 
        TLVs.  The format is redrawn here for convenience. 

      
      
     Bottorff               Expires January 23, 2026                [Page 9] 
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025 
         

         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      |    Organizationally Unique    ~  
        |   7 bits    |     9 bits      |   Identifier (OUI) 3 octets   ~ 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        ~     OUI      |    Subtype     |         Information           ~ 
        ~  continued   |    1 octet     |     0 <= n <= 507 octets      ~ 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        ~                          Information...                       ~ 
        ~                                                               ~ 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         
                 Figure 2 LLDP Organizationally Specific TLV Format 

     4.4.1. Type 

        The Type field is 7 bits in length and is set to the value of 127 
        indicating the TLV type is an Organizationally Specific TLV.  

     4.4.2. Length 

        The Length field contains the length of the TLV specific 
        information, the OUI and subtype.  The Length is from 4 to 511 
        octets.  

     4.4.3. Organizationally Unique Identifier 

        The Organizationally Unique Identifier indicates the organization 
        specifying the TLV.  For IETF use, this field is the IANA OUI as 
        discussed in RFC 9542 and has the hex value of 00-00-5E.  

     4.4.4. Subtype 

        The Subtype field indicates the specific IETF Organizationally 
        Specific TLV.  The format of the information string is dependent 
        upon the Subtype field.   

         
     4.4.5. Information 

        The Information field contains the octets that are specific to the 
        Organizationally Specific TLV.  The field length is between 0 and 
        507 octets.  



      
      
     Bottorff               Expires January 23, 2026               [Page 10] 
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025 
         

     4.5. LLDP IETF Organizationally Specific TLVs for LSVR 

        The IETF draft [I-D.acee-idr-lldp-peer-discovery] describes the use 
        of LLDP by BGP for peer discovery. The IETF LLDP TLV format 
        specified for BGP is used here as the basis for LSVR router 
        discovery TLVs.  

        The format taken from draft-acee-idr-lldp-peer-discovery specifies 
        using the LLDP Organizationally Specific TLV subtype (4.4.4. ) to 
        identify the IETF working group followed by a working group specific 
        subtype. 

        The content of the TLVs specified here for the LSVR are modeled 
        after the TLVs specified for the L3DL protocol in draft [I-D.ietf-
        lsvr-l3dl]. 

        Each LLDP Organizationally Specific TLV starts with the same first 
        four fields as shown in (4.4. ). For LSVR the Type field SHALL be 
        127; the Length field SHALL be the length in octets of the LLDP TLV 
        information string which starts immediately after the Length field; 
        the OUI field SHALL be the IETF OUI 00-00-0E; the Subtype field 
        SHALL be xx assigned by IANA to designate the LSVR group.  

        Following the LLDP Organizationally Specific TLV Subtype a LSVR 
        specific one octet LsvrType SHALL be used to identify the TLV 
        content. The values of the LsvrType are shown in the following 
        table: 

                Subtype        Name 
                -------        ----- 
                   0           Reserved 
                   1           IPv4 Announcement 
                   2           IPv6 Announcement 
                   3           MPLS IPv4 Announcement 
                   4           MPLS IPv6 Announcement 
                   5           Upper-Layer Protocol Configuration    
                   6-255       Reserved 
         
        The specific TLV format for each LsvrType and remaining fields of 
        each Organizationally Specific TLV for LSVR are specified in the 
        following sections. 

        Since LLDP TLVs are limited in size the LLDP database may contain 
        multiple copies of a single LSVR TLV type. 



      
      
     Bottorff               Expires January 23, 2026               [Page 11] 
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025 
         

     4.6. LSVR LLDP L3 data link application 

        LSVR LLDP Agents are associated with router Logical Link Endpoint.
        Each agent advertises the local database associated with the Logical 
        Link Endpoint and updates its remote database to include the 
        information advertised by other router Logical Link Endpoints.  

        An L3 data link application accesses the LLDP databases to determine 
        the network configuration and operation. The application using the LLDP 
        databases signals to the LLDP Agent whenever it changes something in 
        the local database by using the LLDP SomethingChangedLocal() routine. 
        The LLDP Agent signals the application whenever a change is detected in 
        the remote database using the LLDP SomethingChangedRemote() routine.  

        The L3 data link application uses the information in the LLDP 
        databases to determine active logical links and the operating 
        configurations. The application informs the LSVR router of 
        operational links and parameters. The interface between the L3 data 
        link application and BGP-SPF can use the restricted profile of BGP-
        LS [RFC9552] API as specified in l3dl. 

     5. Encapsulation TLVs for LSVR 

        LLDP advertises the encapsulations available in the local database 
        associated with its interface. The interface is uniquely identified 
        by the ChassisID and PortID TLVs encoded as the first two TLVs 
        within each LLDP PDU. The ChassisID and PortID TLVs together encode 
        the Logical Link Endpoint Identifier for the router interface within 
        the sending system associated with the LLDP Agent. 

        The encapsulation types the peers can exchange are IPv4, IPv6, MPLS 
        IPv4, MPLS IPv6, and/or possibly others not defined here. 

        The sender of an encapsulation type MUST NOT assume the peer is   
        capable of the same encapsulation type. Only if an interface has the 
        encapsulation type in both the local and remote LLDP databases is it 
        safe for L3 protocols to assume they are compatible for that type. 

        The LLDP L3 data link application might recognize an addressing 
        conflict, such as both ends of the link trying to use the same 
        address.  Because alternative addresses or encapsulations may be 
        available, this error might be logged to allow the upper-layer 
        topology builder to determine a suitable option.  

        Furthermore, for an L3 data link of a given encapsulation type to be 
        formally established and passed to upper-layer protocols, its 
        addressing must be compatible(e.g., residing on the same IP subnet). 
      
      
     Bottorff               Expires January 23, 2026               [Page 12] 
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025 
         

     5.1. Encaps Flags 

        Each Encapsulation TLV specifies a set of flags for each address 
        listed for the encapsulation. These flags are specified here and 
        used in all the encapsulations. 

        The Encaps Flags specify attributes about the address being 
        announced and are compatible with the Encapsulation Flags defined in 
        [I-D.ietf-lsvr-l3dl].  The Encaps Flags have the following format: 

              0            1            2            3         4 ... 7 
        +------------+------------+------------+------------+-----------+ 
        |  Announce  |   Primary  | Under/Over |  Loopback  | Reserved  | 
        +------------+------------+------------+------------+-----------+ 
         
                            Figure 3 Encapsulation Flags 

     5.1.1. Announce 

        The Announce flag bit SHALL always be set to 1. [I-D.ietf-lsvr-l3dl] 
        defines this bit as an Announce/Withdraw bit to allow encapsulations 
        to be both announced and withdrawn by the L3DL protocol. Old 
        encapsulations are withdrawn in LLDP by simply excluding them in the 
        next transmission of an LLDP PDU.        

     5.1.2. Primary 

        The Primary flag bit indicates that the encapsulation interface is a 
        primary interface.  The value of 1 indicates the interface is 
        primary and the value of 0 indicates it is not. If the LLEI has 
        multiple addresses for an encapsulation type, one and only one 
        address SHOULD be marked as primary.   

     5.1.3. Under/Over 

        The Under/Over flag bit indicates if the interface address is for an 
        underlay interface or an overlay interface.  The value of 1 
        indicates the interface is an underlay and the value of 0 indicates 
        it is an overlay. 

     5.1.4. Loopback 

        The Loopback flag bit indicates if the interface address is a 
        loopback address.  Loopback addresses are generally not seen 
        directly on an external interface.  One or more loopback addresses 
        MAY be announced.  The value of 1 indicates that the interface 

      
      
     Bottorff               Expires January 23, 2026               [Page 13] 
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025 
         

        address is a loopback address and the value of 0 indicates it is 
        not. 

     5.1.5. Reserved 

        MUST be transmitted as 0 and ignored on receive.  

     5.2. IPv4 Announcement TLV 

        The IPv4 Announcement TLV describes a device's ability to exchange 
        IPv4 packets on one or more subnets.  It does so by announcing the 
        interface's addresses and the corresponding prefix lengths.  
        Multiple tuples of IPv4 address information can be announced in a 
        single TLV, each tuple with its own set of encapsulation flags, 
        address and prefix length.  The format of the IPv4 Announcement TLV 
        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      |        OUI = 00-00-5E         ~ 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        ~               |  TBD = xx     | LsvrType = 1  |  Encaps Flags |  
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        |                           IPv4 Address                        | 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        |Prefix Length |                             more               | 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         
                           Figure 4 IPv4 Announcement TLV 

     5.2.1. Encaps Flags 

        The Encaps Flags are the same flags specified in section 5.1.  

     5.2.2. IPv4 Address 

        The IPv4 Address field holds the IPv4 address to be announced. 

     5.2.3. Prefix Length 

        The Prefix Length field indicates the number of bits in the IPv4 
        Address that represent the IPv4 prefix for the subnet (network 
        portion of the address). 



      
      
     Bottorff               Expires January 23, 2026               [Page 14] 
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025 
         

     5.2.4. IPv4 Announcement TLV usage rules 

        An LLDP PDU MAY contain multiple IPv4 Announcement TLVs, however, 
        the encapsulation flags, IPv4 address and prefix length tuple for a 
        specific IPv4 address MUST only appear once in the LLDP PDU. 

     5.3. IPv6 Announcement TLV 

        The IPv6 Announcement TLV describes a device's ability to exchange 
        IPv6 packets on one or more subnets.  It does so by announcing the 
        interface's addresses and the corresponding prefix lengths.  
        Multiple tuples of IPv6 address information can be announced in a 
        single TLV, each tuple with its own set of encapsulation flags, 
        address and prefix length.  The format of the IPv6 Announcement TLV 
        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      |        OUI = 00-00-5E         ~ 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        ~               |  TBD = xx     | LsvrType = 2  |  Encaps Flags | 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        |                                                               | 
        +                                                               + 
        |                                                               | 
        +                       IPv6 Address                            + 
        |                                                               | 
        +                                                               + 
        |                                                               | 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        | Prefix Length |                           more                | 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         
                           Figure 5 IPv6 Announcement TLV 

     5.3.1. Encaps Flags 

        The Encaps Flags are the same flags specified in section 5.1.  

     5.3.2. Prefix Length 

        The Prefix Length field indicates the number of bits in the IPv6 
        Address that represent the IPv6 prefix for the subnet (network 
        portion of the address). 


      
      
     Bottorff               Expires January 23, 2026               [Page 15] 
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025 
         

     5.3.3. IPv6 Address 

        The IPv6 Address field holds the IPv6 address to be announced. 

     5.3.4. IPv6 Announcement TLV usage rules 

        An LLDP PDU MAY contain multiple IPv6 Announcement TLVs, however, 
        the encapsulation flags, IPv6 address and prefix length tuple for a 
        specific IPv6 address MUST only appear once in the LLDP PDU. 

     5.4. MPLS IPv4 Announcement TLV 

        The MPLS IPv4 Encapsulation describes a logical link's ability to   
        exchange labeled IPv4 packets on one or more subnets.  It does so by   
        stating the interface's addresses the corresponding prefix lengths, 
        and the corresponding labels which will be accepted for each 
        address.  The format of the MPLS IPv4 Announcement TLV 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      |        OUI = 00-00-5E         ~ 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        ~               |  TBD = xx     | LsvrType = 3  |MPLS Label List~  
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        ~                                               | Encaps Flags  |  
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        |                        IPv4 Address                           | 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        | Prefix Length |            more                               | 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         
                         Figure 6 MPLS IPv4 Announcement TLV 

     5.4.1. MPLS Label List 

        The MPLS Label List is a variable length field that contains the 
        label stack, see [RFC3032], that the sender will accept for the 
        prefix to which the list is attached.  The format of the MPLS Label 
        List is as follows: 






      
      
     Bottorff               Expires January 23, 2026               [Page 16] 
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025 
         

         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 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        |  Label Count  |                 Label                 | Exp |S| 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        |                 Label                 | Exp |S|    more ...   | 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                              Figure 7 MPLS Label List 

     5.4.1.1. Label Count 

        The number of label stack entries that are included in the list.  
        Each label stack entry has a label, experimental use bits and the 
        bottom of stack indicator.  The Label Count MUST NOT be 0. 

        <<Editor's note:  We really don't need this count because the S bit 
        indicates when the list ends>> 

     5.4.1.2. Label 

        The Label field is the 20-bit value of the label. 

     5.4.1.3. Exp 

        The Exp field is a 3-bit value reserved for experimental use. 

     5.4.1.4. S 

        The S field is a single bit that indicates the last entry in the 
        label stack.  The bit is set to 1 for the last entry and 0 for all 
        other entries in the list. 

     5.4.2. Encaps Flags 

        The Encaps Flags are the same flags specified in section 5.1.  

     5.4.3. Prefix Length 

        The Prefix Length field indicates the number of bits in the IPv4 
        Address that represent the IPv4 prefix for the subnet (network 
        portion of the address). 

     5.4.4. IPv4 Address 

        The IPv4 Address field holds the IPv4 address to be announced. 


      
      
     Bottorff               Expires January 23, 2026               [Page 17] 
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025 
         

     5.4.5. IPv4 Announcement TLV usage rules 

        An LLDP PDU MAY contain multiple MPLS IPv4 Announcement TLVs, 
        however, the encapsulation flags, label list, IPv4 address and 
        prefix length tuple for a specific IPv4 address MUST only appear 
        once in the LLDP PDU. 

     5.5. MPLS IPv6 Announcement TLV 

        The MPLS IPv6 Encapsulation describes a logical link's ability to   
        exchange labeled IPv6 packets on one or more subnets.  It does so by
        stating the interface's addresses the corresponding prefix lengths, 
        and the corresponding labels which will be accepted for each 
        address.  The format of the MPLS IPv6 Announcement TLV 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      |        OUI = 00-00-5E         ~ 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        ~               |  TBD = xx     | LsvrType = 4  |MPLS Label List~  
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        ~                                               | Encaps Flags  |  
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        |                                                               | 
        +                                                               + 
        |                                                               | 
        +                                                               + 
        |                       IPV6 Address                            | 
        +                                                               + 
        |                                                               | 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        | Prefix Length |                     more                      | 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         
                         Figure 8 MPLS IPv6 Announcement TLV 

     5.5.1. MPLS Label List 

        The MPLS Label List is the same as specified in section 5.4.1.  

     5.5.2. Encaps Flags 

        The Encaps Flags are the same flags specified in section 5.1.  


      
      
     Bottorff               Expires January 23, 2026               [Page 18] 
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025 
         

     5.5.3. IPv6 Address 

        The IPv6 Address field holds the IPv6 address to be announced. 

     5.5.4. Prefix Length 

        The Prefix Length field indicates the number of bits in the IPv6 
        Address that represent the IPv6 prefix for the subnet (network 
        portion of the address). 

     5.5.5. MPLS IPv6 Announcement TLV usage rules 

        An LLDP PDU MAY contain multiple MPLS IPv6 Announcement TLVs, 
        however, the encapsulation flags, label list, IPv6 address and 
        prefix length tuple for a specific IPv6 address MUST only appear 
        once in the LLDP PDU.  

     6. Upper-Layer Protocol Configuration TLVs 

        A router or switch supporting LSVR protocols MAY include the 
        following BGP Attribute TLV which is modeled after the l3dl ULPC 
        TLV. Alternatively, the TLVs from [I-D.acee-idr-lldp-peer-discovery] 
        could be used for BGP configuration. The format of the following TLV 
        is compatible with the TLVs in I-D.acee-idr-lldp-peer-discovery, 
        however don't use a length field in the sub-TLV.  

        The BGP Protocol Configuration TLV for LSVR is shown in Figure 2. 

         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      |        OUI = 00-00-5E         ~ 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        ~                  | TBD = xx    | LsvrType = 5 |   AttrType = a| 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        |                      Attribute                                | 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        |                         more                                  | 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         
                   Figure 9 BGP Protocol Configuration TLV Format 

     6.1.1. AttrTypes 

        The AttrType identifies the BGP attribute type. The types are: 

          AttrType = 1: BGP ASN 
      
      
     Bottorff               Expires January 23, 2026               [Page 19] 
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025 
         

          AttrType = 2: BGP IPv4 Peering Address 
          AttrType = 3: BGP IPv6 Peering Address 
          AttrType = 4: BGP Authentication Data 
          AttrType = 5: BGP Flags, Bit 0: GTSM, Bit 1: BFD,  
                       Bit 2-15 reserved = 0 

     6.1.2. BGP ASN 

        The four octet Autonomous System number MUST be specified. If the AS 
        Number is less than 32 bits, it is padded with high order zeros. 

     6.1.3. BGP IPv4 Peering Address 

        The five octet IPv4 Peering Address along with the Prefix Length. 

     6.1.4. BGP IPv6 Peering Address 

        The 17 octet IPv6 Peering Address along with the Prefix Length. 

     6.1.5. BGP Authentication Data 

        The BGP Authentication TLV provides any authentication data needed 
        to OPEN the BGP session. Depending on operator configuration of the 
        environment, it might be a simple MOS key (see [RFC2385]), the name 
        of a key chain in a KARP database (see [RFC7210)), or one of 
        multiple Authentication TLVs to support[RFC4808]. 

     6.1.6. BGP Flags 

        The BGP session OPEN has extensive, and a bit complex, capability 
        negotiation facilities. In case one or more extra attributes might 
        be needed, the two octet BGP Flags TLV may be used. No flags are 
        currently defined. 

        BGP Flags: 

          Bit O: GTSM 
          Bit 1: BFD 
          Bit 2-15: Must be zero 

        The GTSM flag, when 1, indicates that the sender wishes to enable 
        the [RFC5082] Generalized TTL Security Mechanism for the session. 

        The BFD flag, when 1, indicates that the sender wishes to enable the 
        [RFC5880] Bidirectional Forwarding Detection for the session. 


      
      
     Bottorff               Expires January 23, 2026               [Page 20] 
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025 
         

     6.1.7. BGP Protocol Configuration TLVs usage rules 

        An LLDP PDU MUST contain only a single BGP Protocol Configuration 
        TLV. 

     7. Security Considerations 

        <Add any security considerations> 

     8. IANA Considerations 

        The LSVR WG needs to use the IANA OUI to form the Organizationally 
        Specific TLVs used for LSVR discovery and configuration. 

        The LSVR WG needs a group address for the purpose of LLDP Nearest 
        Router discovery. This address should be recognized by IANA for this 
        application. 

     9. Conclusions 

        <Add any conclusions> 

     10. References 

     10.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, 
                  https://ieeexplore.ieee.org/document/7433915  

        [802.1ABcu] "IEEE Standards for Local and metropolitan area 
                  networks- Station and Media Access Control Connectivity 
                  Discovery Amendment 1: YANG Data Model" IEEE Std 
                  802.1ABcu-2021, December 2021, 
                  https://ieeexplore.ieee.org/document/9756407   

        [802.1ABdh] "IEEE Standards for Local and metropolitan area 
                  networks- Station and Media Access Control Connectivity 
                  Discovery Amendment 2: Support for Multiframe Protocol 
                  Data Units", IEEE Std 802.1ABdh-2021, December 2021, 
                  https://ieeexplore.ieee.org/document/9760302  

        [802.1Q] "IEEE Standards for Local and metropolitan area networks-
                  Bridges and Bridged Networks", IEEE Std 802.1A-2022, 
                  September 2022, 
                  https://ieeexplore.ieee.org/document/10004498 
      
      
     Bottorff               Expires January 23, 2026               [Page 21] 
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025 
         

        [802.1AE] "IEEE Standard for Local and metropolitan area networks-
                  Media Access Control (MAC) Security", IEEE Std 802.1AE-
                  2018, September 2018, 
                  https://ieeexplore.ieee.org/document/8585421                

        [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 
                  Requirement Levels", RFC 2119, March 1997, 
                  https://datatracker.ietf.org/doc/html/rfc2119 

        [RFC2385] Heffernan, A. "Protection of BGP Sessions via the TCP MD5 
                  Signature Option", RFC 2385, August 1998, 
                  https://datatracker.ietf.org/doc/html/rfc2385 

        [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 
                  Farinacci, D., Li, T. and Conta, A. "MPLS Label Stack 
                  Encoding", RFC 3032, January 2001, 
                  https://datatracker.ietf.org/doc/html/rfc3032  

        [RFC4808] Bellovin, S. "Key Change Strategies for TCP-MD5", RFC 
                  4808, March 2007, 
                  https://datatracker.ietf.org/doc/html/rfc4808 

        [RFC5082] Gill, V., Heasley, J. Meyer, D. Savola, P. and Pignataro, 
                  C., "The Generalized TTL Security Mechanism (GTSM)", RFC 
                  5082, October 2007, 
                  https://datatracker.ietf.org/doc/html/rfc5082 

        [RFC5880] Katz, D. and Ward, D. "Bidirectional Forwarding Detection 
                  (BFD)", RFC 5880, June 2010, 
                  https://datatracker.ietf.org/doc/html/rfc5880 

        [RFC5925] Touch, J., Mankin, A. and Bonica, R. "The TCP 
                  Authentication Option", RFC 5925, June 2010, 
                  https://datatracker.ietf.org/doc/html/rfc5925 

        [RFC8174] Leiba, B. "Ambiguity of Uppercase vs Lowercase in RFC 2119 
                  Key Words", RFC 8174, May 2017, 
                  https://datatracker.ietf.org/doc/html/rfc8174 

        [RFC9542] Eastlake, D. and Abley, J. "IANA Considerations and IETF 
                  Protocol and Documentation Usage for IEEE 802 Parameters", 
                  RFC 9542, April 2024, 
                  https://datatracker.ietf.org/doc/html/rfc9542 




      
      
     Bottorff               Expires January 23, 2026               [Page 22] 
         






     Internet-Draft            LSVR TLVs for LLDP                  July 2025 
         

        [RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and 
                  Traffic Engineering Information Using BGP", RFC 9552, DOI 
                  10.17487/RFC9552, December 2023,           
                  https://www.rfc-editor.org/info/rfc9552 

        [I-D.ietf-lsvr-l3dl] Bush, R., Austein, R. and Patel, K., "Layer 3 
                  Discovery and Liveness", draft-ietf-lsvr-l3dl-15.txt (work 
                  in progress), July 2019, 
                  https://datatracker.ietf.org/doc/draft-ietf-lsvr-l3dl/  

        [I-D.acee-idr-lldp-peer-discovery] A. Lindem, K. Patel, S.Zandi, 
                  J.Haas, X. Xu2, "BGP Logical Link Discovery Protocol 
                  (LLDP) Peer Discovery", draft-acee-idr-lldp-peer-
                  discovery-20.txt (work in progress), January 9, 2025, 
                  https://datatracker.ietf.org/doc/draft-acee-idr-lldp-peer-
                  discovery/   

     11. Acknowledgments 

        <Add any acknowledgements> 

        This document was prepared using 2-Word-v2.0.template.dot. 

     Authors' Addresses 

        Paul Congdon 
        Congdon Consulting, LLC 
        5582 Carlile Ct  
        Granite Bay, CA 95746 
         
        Email: paul.congdon@outlook.com 
         

        Paul Bottorff 
        HPE Aruba Networking 
        8000 Foothill Blvd 
        Roseville, CA  95747 
            
        Email: paul.bottorff@hpe.com 
         







      
      
     Bottorff               Expires January 23, 2026               [Page 23] 
         