Internet DRAFT - draft-abd-mpls-ldp-identifier-name
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
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 [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 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.
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
(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
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
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.
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
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, DOI 10.17487/RFC3490, March 2003,
<https://www.rfc-editor.org/info/rfc3490>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <https://www.rfc-editor.org/info/rfc5036>.
6.2. Informative References
[RFC7349] Zheng, L., Chen, M., and M. Bhatia, "LDP Hello
Cryptographic Authentication", RFC 7349,
DOI 10.17487/RFC7349, August 2014,
<https://www.rfc-editor.org/info/rfc7349>.
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
India
Email: anil.ietf@gmail.com
Deepak J Gowda
RtBrick India
HSR Layout
Bengaluru, Karnataka 560102
India
Email: deepakj4982@gmail.com
Basil Saji
RtBrick India
HSR Layout
Bengaluru, Karnataka 560102
India
Email: sajibasil@gmail.com
Anil Kumar, et al. Expires March 25, 2019 [Page 7]
