Internet DRAFT - draft-abd-mpls-ldp-identifier-name


Network Working Group                                         Anil Kumar
Internet-Draft                                                  Deepak J
Intended status: Standards Track                              Basil Saji
Expires: March 25, 2019                                    RtBrick India
                                                      September 21, 2018

                        MPLS LDP Identifier Name


   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

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

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

   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.

Anil Kumar, et al.       Expires March 25, 2019                 [Page 1]
Internet-Draft             LDP Identifier Name            September 2018

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( 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
   2.  LDP Identifier Name TLV . . . . . . . . . . . . . . . . . . .   3
     2.1.  Optional Parameter for Hello Message  . . . . . . . . . .   3
     2.2.  LDP Identifier Name TLV Encoding  . . . . . . . . . . . .   4
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

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.

Anil Kumar, et al.       Expires March 25, 2019                 [Page 2]
Internet-Draft             LDP Identifier Name            September 2018

   [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

   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.

Anil Kumar, et al.       Expires March 25, 2019                 [Page 3]
Internet-Draft             LDP Identifier Name            September 2018

   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

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

Anil Kumar, et al.       Expires March 25, 2019                 [Page 4]
Internet-Draft             LDP Identifier Name            September 2018

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

Anil Kumar, et al.       Expires March 25, 2019                 [Page 5]
Internet-Draft             LDP Identifier Name            September 2018

4.  IANA Considerations

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

   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

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, DOI 10.17487/RFC3490, March 2003,

   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
              "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
              October 2007, <>.

6.2.  Informative References

   [RFC7349]  Zheng, L., Chen, M., and M. Bhatia, "LDP Hello
              Cryptographic Authentication", RFC 7349,
              DOI 10.17487/RFC7349, August 2014,

Anil Kumar, et al.       Expires March 25, 2019                 [Page 6]
Internet-Draft             LDP Identifier Name            September 2018

Authors' Addresses

   Anil Kumar S N
   RtBrick India
   HSR Layout
   Bengaluru, Karnataka  560102


   Deepak J Gowda
   RtBrick India
   HSR Layout
   Bengaluru, Karnataka  560102


   Basil Saji
   RtBrick India
   HSR Layout
   Bengaluru, Karnataka  560102


Anil Kumar, et al.       Expires March 25, 2019                 [Page 7]