MPLS LDP Identifier Name
draft-abd-mpls-ldp-identifier-name-00

Abstract

This document introduces a new optional LDP Identifier Name TLV that allows LDP routers to inform their LDP-Identifier-to-Name mapping in LDP Hello messages as part of the LDP Discovery Mechanism. This document describes a mechanism to provide a simple and dynamic mechanism for ldp routers to learn about symbolic LDP Identifier Names.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

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 March 25, 2019.

Copyright Notice

Copyright (c) 2018 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.

Table of Contents

• 1. Introduction
• 2. LDP Identifier Name TLV
• 2.1. Optional Parameter for Hello Message
• 2.2. LDP Identifier Name TLV Encoding
• 3. Security Considerations
• 4. IANA Considerations
• 5. Acknowledgements
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Authors' Addresses

1. Introduction

The Label Distribution Protocol (LDP) [RFC5036] sets up LDP sessions that run between LDP peers. The peers could either be directly connected at the link level or could be multiple hops away. An LDP Label Switching Router (LSR) could either be configured with the identity of its peers or could discover them using LDP Hello messages. These messages are sent encapsulated in UDP addressed to "all routers on this subnet" or to a specific IP address. Periodic Hello messages are also used to maintain the relationship between LDP peers necessary to keep the LDP session active.

[RFC5036] states that an LDP Identifier is a six octet quantity used to identify an LSR label space. The first four octets identify the LSR and must be a globally unique value, such as a 32-bit router Id assigned to the LSR. The last two octets identify a specific label space within the LSR. The last two octets of LDP Identifiers for platform-wide label spaces are always both zero.

An LSR that manages and advertises multiple label spaces uses a different LDP Identifier for each such label space.

[RFC5036] specifies using following representation for LDP Identifiers: <LSR Id> : <label space id> e.g., lsr171 : 0 lsr19 : 2

For management and operational reasons, network operators need to check the status of LDP adjacencies, entries in Label Information Base (LIB), and next hop address for the prefix to an LDP Identifier mapping table. When looking at diagnostic information, numerical representations of LDP Identifiers (e.g., dotted-decimal or hexadecimal representations) are less clear to humans than symbolic names.

LDP is increasingly used inside the data center. Due to the sheer scale of devices(ldp peers) involved, simplifying troubleshooting LDP would be very useful. One way to overcome this problem is to define a LDP-Identifier-to-Name mapping table on a router. This mapping can be used bidirectionally (e.g., to find symbolic names for LDP-Identifiers and to find LDP-Identifiers for symbolic names) or unidirectionally (e.g., to find symbolic names for LDP-Identifiers). Thus, every router has to maintain a table with mappings between names and LDP-Identifiers.

If these mapping tables are built by static definitions, it can currently become a manual and tedious process in operational networks; modifying these static mapping entries when additions, deletions, or changes occur becomes a non-scalable process very prone to error.

This document provides a way to populate tables by defining a new optional LDP Identifier Name TLV for LDP which will be exchanged in LDP Hello messages.

2. LDP Identifier Name TLV

2.1. Optional Parameter for Hello Message

There are various approaches to providing a LDP-Identifier-to-Name mapping service.

One way to build this table of mappings is by static definitions. The problem with static definitions is that the network administrator needs to keep updating the mapping entries manually as the network changes; this approach does not scale as the network grows, since there needs to be an entry in the mapping table for each LDP peer. Thus, this approach greatly suffers from maintainability and scalability considerations.

Another approach is having a centralized location where the name-to- LDP-Identifier mapping can be kept. The DNS could be used for this. A disadvantage with this centralized solution is that it is a single point of failure; and although enhanced availability of the central mapping service can be designed, it may not be able to resolve the LDP Identifier name in the event of reachability or network problems, which can be particularly problematic in times of problem resolution. Also, the response time can be an issue with the centralized solution, which can be equally problematic. If the DNS is used as the centralized mapping table, a network operator may desire a different name mapping than the existing mapping in the DNS, or new routers may not yet be in the DNS.

The third solution that we have defined in this document is to make use of the protocol itself to carry the LDP-Identifier-to-Name mapping in a TLV. Routers that understand this TLV can use it to create the symbolic LDP-Identifier-to-Name mapping, and routers that don't understand it can simply ignore it. This specification provides these semantics and mapping mechanisms for LDP, leveraging the LDP Optional TLVs exchanged in LDP Hellos. ([RFC5036]).

[RFC5036] defines the encoding for the Hello message. Each Hello message contains zero or more Optional Parameters, each encoded as a TLV. Three Optional Parameters are defined by [RFC5036].

[RFC7349] defines optional Cryptographic Authentication TLV.This document defines a new Optional Parameter: the LDP Identifier Name parameter.

Optional Parameter               Type
-------------------------------  --------
IPv4 Transport Address           0x0401 (RFC5036)
Configuration Sequence Number    0x0402 (RFC5036)
IPv6 Transport Address           0x0403 (RFC5036)
Cryptographic Authentication     0x0405 (RFC7349)
LDP Identifier Name              TBD1   (this document, TBD1 by IANA)

The LDP Identifier Name TLV Encoding is described in section 2.2.

2.2. LDP Identifier Name TLV Encoding

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|    LDP-ID Name (TBD1)     |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 LDP Identifier Name ...                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- Type: TBD1, LDP Identifier Name Type

- Length: Total length of the LDP Identifier Name (Value field) in octets, not including the optional padding.

- LDP Identifier Name: LDP Identifier Name, a string of 1 to 255 octets, padded with zeroes to 4-octet alignment, encoded in the US-ASCII charset.

Routers that do not recognize the LDP Identifier Name TLV Type ignore the TLV

The Value field identifies the symbolic LDP Identifier Name of the router originating the LSA. This symbolic name can be the Fully Qualified Domain Name (FQDN) for the LDP Identifier, it can be a subset of the FQDN, or it can be any string that operators want to use for the router. The use of FQDN or a subset of it is strongly recommended since it can be beneficial to correlate the LDP Identifier Name and the corresponding DNS entry. If there is no DNS LDP Identifier Name for the LDP Identifier, if the LDP Identifier does not map to an IPv4-addressed entity or if an alternate LDP Identifier Name naming convention is desired, any string with significance can be used. The string is not null-terminated. The LDP Identifier of this router is derived from the LDP header. The Value field is encoded in 7-bit ASCII. If a user-interface for configuring or displaying this field permits Unicode characters, that user-interface is responsible for applying the ToASCII and/or ToUnicode algorithm as described in [RFC3490] to achieve the correct format for transmission or display.

3. Security Considerations

Since the LDP-Identifier-to-Name mapping relies on information provided by the routers themselves, a misconfigured or compromised router can inject false mapping information, including a duplicate LDP-Identifier Name for different LDP-Identifiers. Thus, this information needs to be treated with suspicion when, for example, doing diagnostics about a suspected security incident.

There is potential confusion from name collisions if two routers use and advertise the same LDP-Identifier names. Name conflicts are not crucial, and therefore there is no generic conflict detection or resolution mechanism in the protocol. However, a router that detects that a received LDP-Identifier name is the same as the local one can issue a notification or a management alert.

This document raises no other new security issues for LDP.

4. IANA Considerations

The IANA is requested to as assign a new TLV from the "Label Distribution Protocol (LDP) Parameters" registry, "TLV Type Name Space".

Value   Meaning                            Reference
-----   --------------------------------   ------------------------
TBD1    LDP Identifier Name TLV            this document (sect 2.2)

Note to the RFC Editor and IANA (to be removed before publication):

The new value should be assigned from the range 0x400 - 0x4ff using the first free value.

5. Acknowledgements

we would also thank Hannes Gredler for his invaluable guidance.

6. References

6.1. Normative References

6.2. Informative References

Authors' Addresses