Internet DRAFT - draft-wijnands-mpls-mldp-multi-topology

draft-wijnands-mpls-mldp-multi-topology







MPLS Working Group                                          IJ. Wijnands
Internet-Draft                                                   K. Raza
Intended status: Standards Track                     Cisco Systems, Inc.
Expires: September 6, 2018                                      Z. Zhang
                                                        Juniper Networks
                                                                A. Gulko
                                                         Thomson Reuters
                                                           March 5, 2018


               mLDP Extensions for Multi-Topology Routing
             draft-wijnands-mpls-mldp-multi-topology-00.txt

Abstract

   Multi-Topology Routing (MTR) is a technology to enable service
   differentiation within an IP network.  Flexible Algorithm (FA) is
   another mechanism of creating a sub-topology within a topology using
   defined topology constraints and computation algorithm.  In order to
   deploy mLDP in a network that supports MTR and/or FA, mLDP is
   required to become topology and FA aware.  This document specifies
   extensions to mLDP to support MTR with FA such that when building a
   Multi-Point LSPs it can follow a particular topology and algorithm.

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 September 6, 2018.

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



Wijnands, et al.        Expires September 6, 2018               [Page 1]

Internet-Draft             Multi-Topology mLDP                March 2018


   (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.  Glossary  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Specification of Requirements . . . . . . . . . . . . . . . .   4
   4.  MT Scoped mLDP FECs . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  MP FEC Extensions for MT  . . . . . . . . . . . . . . . .   4
       4.1.1.  MP FEC Element  . . . . . . . . . . . . . . . . . . .   4
       4.1.2.  MT IP Address Families  . . . . . . . . . . . . . . .   5
       4.1.3.  MT MP FEC Element . . . . . . . . . . . . . . . . . .   6
     4.2.  Topology IDs  . . . . . . . . . . . . . . . . . . . . . .   7
   5.  MT Multipoint Capability  . . . . . . . . . . . . . . . . . .   7
   6.  MT Applicability on FEC-based features  . . . . . . . . . . .   8
     6.1.  Typed Wildcard MP FEC Elements  . . . . . . . . . . . . .   8
     6.2.  End-of-LIB  . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  Topology-Scoped Signaling and Forwarding  . . . . . . . . . .  10
     7.1.  Upstream LSR selection  . . . . . . . . . . . . . . . . .  10
     7.2.  Downstream forwarding interface selection . . . . . . . .  10
   8.  LSP Ping Extensions . . . . . . . . . . . . . . . . . . . . .  10
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     12.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Glossary

      MT - Multi-Topology

      MT-ID - Multi-Topology Identifier

      MTR - Multi-Topology Routing

      IGP - Interior Gateway Protocol

      MP - Multipoint (P2MP or MP2MP)

      LDP - Label Distribution Protocol



Wijnands, et al.        Expires September 6, 2018               [Page 2]

Internet-Draft             Multi-Topology mLDP                March 2018


      mLDP - Multipoint LDP

      P2MP - Point-to-Multipoint

      MP2MP - Multipoint-to-Multipoint

      FEC - Forwarding Equivalence Class

      LSP - Label Switched Path

      FA - Flexible Algorithm

      IPA - IGP Algorithm

2.  Introduction

   Multi-Topology Routing (MTR) is a technology to enable service
   differentiation within an IP network.  IGP protocols (OSPF and IS-IS)
   and LDP have already been extended to support MTR.  To support MTR,
   an IGP maintains independent IP topologies, termed as "Multi-
   Topologies" (MT), and computes/installs routes per topology.  OSPF
   extensions [RFC4915] and ISIS extensions [RFC5120] specify the MT
   extensions under respective IGPs.  To support IGP MT, similar LDP
   extensions [RFC7307] have been specified to make LDP MT-aware and be
   able to setup unicast Label Switched Paths (LSPs) along IGP MT
   routing paths.

   A more light weight mechanism to define constraint-based topologies
   is Flexible Algorithm (FA) [I-D.hegdeppsenak-isis-sr-flex-algo].  FA
   can be seen as creating a sub-topology within a topology using
   defined topology constraints and computation algorithm.  This can be
   done within a MTR topology or just the default Topology.  An instance
   of such a sub-topology is identified by a 1 octet value as documented
   in [I-D.hegdeppsenak-isis-sr-flex-algo]).  Flexible Algorithm is a
   mechanism to create a sub-topology, but in the future different
   algorithms might be defined on how to achieve that.  For that reason,
   in the remainder of this document we'll refer to this as the IGP
   Algorithm (IPA).

   Multipoint LDP (mLDP) refers to extensions in LDP to setup multi-
   point LSPs (point-to-multipoint (P2MP) or multipoint-to-multipoint
   (MP2MP)), by means of set of extensions and procedures defined in
   [RFC6388].  In order to deploy mLDP in a network that supports MTR
   and FA, mLDP is required to become topology and algorithm aware.
   This document specifies extensions to mLDP to support MTR/IPA such
   that when building a Multi-Point LSPs it can follow a particular
   topology and alogirthm.  This means that the identifier for the




Wijnands, et al.        Expires September 6, 2018               [Page 3]

Internet-Draft             Multi-Topology mLDP                March 2018


   particular Topology to be used by mLDP have to become a two tuple
   (MTR Topology Id, IGP Algorithm).

3.  Specification of Requirements

   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 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS.  Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

4.  MT Scoped mLDP FECs

   As defined in [RFC7307], MPLS Multi-Topology Identifier (MT-ID) is an
   identifier that is used to associate an LSP with a certain MTR
   topology.  In the context of MP LSPs, this identifier is part of the
   mLDP FEC encoding so that LDP peers are able to setup an MP LSP via
   their own defined MTR policy.  In order to avoid conflicting MTR
   policies for the same mLDP FEC, the MT-ID needs to be a part of the
   FEC, so that different MT-ID values will result in unique MP-LSP FEC
   elements.

   The same applies to the IPA.  The IPA needs to be encoded as part of
   the mLDP FEC to create unique MP-LSPs and at the same time is used to
   signal to mLDP (hop-by-hop) which Algorithm needs to be used to
   create the MP-LSP.

   Since the MT-ID and IPA are part of the FEC, they apply to all the
   LDP messages that potentially include an mLDP FEC element.

4.1.  MP FEC Extensions for MT

   Following subsections propose the extensions to bind an mLDP FEC to a
   topology.  The mLDP MT extensions reuse some of the extensions
   specified in [RFC7307].

4.1.1.  MP FEC Element

   Base mLDP specification [RFC6388] defines MP FEC Element as follows:










Wijnands, et al.        Expires September 6, 2018               [Page 4]

Internet-Draft             Multi-Topology mLDP                March 2018


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | MP FEC type   |       Address Family          |    AF Length  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Root Node Address                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Opaque Length              |       Opaque Value            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                 Figure 1: MP FEC Element Format [RFC6388]

   Where "Root Node Address" encoding is as defined for given "Address
   Family", and whose length (in octets) is specified by the "AF Length"
   field.

   To extend MP FEC elements for MT, the {MT-ID, IPA} is a tuple that is
   relevant in the context of the root address of the MP LSP.  The {MT-
   ID, IPA} tuple determines in which (sub)-topology the root address
   needs to be resolved.  Since the {MT-ID, IPA} tuple should be
   considered part of the mLDP FEC, the most natural place to encode
   this tuple is as part of the root address.  While encoding it, we
   also propose to use "MT IP" Address Families as described in
   following sub section.

4.1.2.  MT IP Address Families

   [RFC7307] has specified new address families, named "MT IP" and "MT
   IPv6", to allow specification of an IP prefix within a topology
   scope.  In addition to using this address family for mLDP, we also
   use 8 bits of the 16 bits Reserved field to encode the IGP Algorithm
   (IPA) Registry.  The resulting format of the data associated with
   these new Address Families is as follows:















Wijnands, et al.        Expires September 6, 2018               [Page 5]

Internet-Draft             Multi-Topology mLDP                March 2018


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     IPv4 Address                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved   |      IPA      |        MT-ID                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     IPv6 Address                              |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved   |      IPA      |        MT-ID                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


           Figure 2: Modified MT IP Address Families Data Format

   Where:

      IPv4/IPv6 Address: An IP address corresponding to "MT IP" and "MT
      IPv6" address families respectively.

      IPA: The IGP Algorithm, values are from the IGP Algorithm
      registry.

      Reserved: This 8-bit field MUST be zero.  If a message is received
      that includes a MT address family where the 8 bit Reserved value
      is not zero, the message must be discarded.

4.1.3.  MT MP FEC Element

   By using extended MT IP Address Family, the resultant MT MP FEC
   element is to be encoded as follows:












Wijnands, et al.        Expires September 6, 2018               [Page 6]

Internet-Draft             Multi-Topology mLDP                March 2018


      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | MP FEC type   |  AF (MT IP/ MT IPv6)          |    AF Length  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Root Node Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved   |      IPA      |        MT-ID                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Opaque Length              |       Opaque Value            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Figure 3: IP MT-Scoped MP FEC Element Format

   In the context of this document, the applicable LDP FECs for MT mLDP
   include:

   o  MP FEC Elements:

      *  P2MP (type 0x6)

      *  MP2MP-up (type 0x7)

      *  MP2MP-down (type 0x8)

   o  Typed Wildcard FEC Element (type 0x5)

   In case of "Typed Wildcard FEC Element", the sub FEC Element type
   MUST be one of the MP FECs listed above.

   This specification allows the use of Topology-scoped mLDP FECs in LDP
   label and notification messages, as applicable.

4.2.  Topology IDs

   This document assumes the same definitions and procedures associated
   with MPLS MT-ID as defined in [RFC7307] specification.

5.  MT Multipoint Capability

   "MT Multipoint Capability" is a new LDP capability, defined in
   accordance with LDP Capability definition guidelines [RFC5561], that
   is to be advertised to its peers by an mLDP speaker to announce its
   capability to support MTR and the procedures specified in this
   document.  This capability MAY be sent either in an Initialization



Wijnands, et al.        Expires September 6, 2018               [Page 7]

Internet-Draft             Multi-Topology mLDP                March 2018


   message at the session establishment time, or in a Capability message
   dynamically during the lifetime of a session (only if "Dynamic
   Announcement" capability [RFC5561] has been successfully negotiated
   with the peer).

   The format of this capability 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |U|F|  MT Multipoint Cap.(IANA) |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S| Reserved    |
      +-+-+-+-+-+-+-+-+

               Figure 4: MT Multipoint Capability TLV Format

   Where:

      U- and F-bits: MUST be 1 and 0, respectively, as per Section 3 of
      LDP Capabilities [RFC5561].

      MT Multipoint Capaility: TLV type (IANA assigned).

      Length: The length (in octets) of TLV.  The value of this field
      MUST be 1 as there is no Capability-specific data [RFC5561] that
      follows in the TLV.

      S-bit: Set to 1 to announce and 0 to withdraw the capability (as
      per [RFC5561].

   An mLDP speaker that has successfully advertised and negotiated "MT
   Multipoint" capability MUST support the following:

   1.  Topology-scoped mLDP FECs in LDP messages (Section 4.1)

   2.  Topology-scoped mLDP forwarding setup (Section 7)

6.  MT Applicability on FEC-based features

6.1.  Typed Wildcard MP FEC Elements

   [RFC5918] extends base LDP and defines Typed Wildcard FEC Element
   framework.  Typed Wildcard FEC element can be used in any LDP message
   to specify a wildcard operation for a given type of FEC.

   The MT extensions proposed in document do not require any extension
   in procedures for Typed Wildcard FEC Element support [RFC5918], and



Wijnands, et al.        Expires September 6, 2018               [Page 8]

Internet-Draft             Multi-Topology mLDP                March 2018


   these procedures apply as-is to Multipoint MT FEC wildcarding.  Like
   Typed Wildcard MT Prefix FEC Element, as defined in [RFC7307], the MT
   extensions allow use of "MT IP" or "MT IPv6" in the Address Family
   field of the Typed Wildcard MP FEC element in order to use wildcard
   operations for MP FECs in the context of a given (sub)-topology as
   identified by the MT-ID and IPA field.

   This document proposes following format and encoding for a Typed
   Wildcard MP FEC element:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Typed Wcard (5)| Type = MP FEC |   Len = 6     |  AF = MT IP ..|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |... or MT IPv6 |    Reserved   |      IPA      |     MT-ID     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |MT ID (contd.) |
      +-+-+-+-+-+-+-+-+

                Figure 5: Typed Wildcard MT MP FEC Element

   Where:

      Type: One of MP FEC Element type (P2MP, MP2MPup, MP2MP-down).

      MT ID: MPLS MT ID

      IPA: The IGP Algorithm, values are from the IGP Algorithm
      registry.

   The proposed format allows an LSR to perform wildcard MP FEC
   operations under the scope of a (sub-)topology.

6.2.  End-of-LIB

   [RFC5919] specifies extensions and procedures that allows an LDP
   speaker to signal its End-of-LIB (i.e. convergence) for a given FEC
   type towards a peer.  MT extensions for MP FEC do not require any
   change in these procedures and they apply as-is to MT MP FEC
   elements.  This means that an MT mLDP speaker MAY signal its
   convergence per (sub-)topology using MT Typed Wildcard MP FEC
   element.








Wijnands, et al.        Expires September 6, 2018               [Page 9]

Internet-Draft             Multi-Topology mLDP                March 2018


7.  Topology-Scoped Signaling and Forwarding

   Since the {MT-ID, IPA} tuple is part of an mLDP FEC, there is no need
   to support the concept of multiple (sub-)topology forwarding tables
   in mLDP.  Each MP LSP will be unique due to the tuple being part of
   the FEC.  There is also no need to have specific label forwarding
   tables per topology, and each MP LSP will have its own unique local
   label in the table.  However, In order to implement MTR in an mLDP
   network, the selection procedures for upstream LSR and downstream
   forwarding interface need be changed.

7.1.  Upstream LSR selection

   The procedures as described in RFC-6388 section-2.4.1.1 depend on the
   best path to reach the root.  When the {MT-ID, IPA} tuple is signaled
   as part of the FEC, this tuple is used to select the (sub-)topology
   that must be used to find the best path to the root address.  Using
   the next-hop from this best path, a LDP peer is selected following
   the procedures as defined in [RFC6388].

7.2.  Downstream forwarding interface selection

   The procedures as described in RFC-6388 section-2.4.1.2 describe how
   a downstream forwarding interface is selected.  In these procedures,
   any interface leading to the downstream LDP neighbor can be
   considered as candidate forwarding interface.  When the {MT-ID, IPA}
   tuple is part of the FEC, this is no longer true.  An interface must
   only be selected if it is part of the same (sub-)topology that was
   signaled in the mLDP FEC element.  Besides this restriction, the
   other procedures in [RFC6388] apply.

8.  LSP Ping Extensions

   [RFC6425] defines procedures to detect data plane failures in
   Multipoint MPLS LSPs.  Section 3.1.2 of [RFC6425] defines new Sub-
   Types and Sub-TLVs for Multipoint LDP FECs to be sent in "Target FEC
   Stack" TLV of an MPLS echo request message [RFC4379].

   To support LSP ping for MT Multipoint LSPs, this document uses
   existing sub-types "P2MP LDP FEC Stack" and "MP2MP LDP FEC Stack"
   defined in [RFC6425].  The proposed extension is to specify "MT IP"
   or "MT IPv6" in the "Address Family" field, set the "Address Length"
   field to 8 (for MT IP) or 20 (for MT IPv6), and encode the sub-TLV
   with additional {MT-ID, IPA} information as an extension to the "Root
   LSR Address" field.  The resultant format of sub-tlv is as follows:






Wijnands, et al.        Expires September 6, 2018              [Page 10]

Internet-Draft             Multi-Topology mLDP                March 2018


      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Address Family (MT IP/MT IPv6) | Address Length|               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
      ~                   Root LSR Address (Cont.)                    ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved   |      IPA      |        MT-ID                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Opaque Length          |         Opaque Value ...      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      ~                                                               ~
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 6: Multipoint LDP FEC Stack Sub-TLV Format for MT

   The rules and procedures of using this new sub-TLV in an MPLS echo
   request message are same as defined for P2MP/MP2MP LDP FEC Stack Sub-
   TLV in [RFC6425] with only difference being that Root LSR address is
   now (sub-)topology scoped.

9.  Security Considerations

   This extension to mLDP does not introduce any new security
   considerations beyond that already apply to the base LDP
   specification [RFC5036], base mLDP specification [RFC6388], and MPLS
   security framework [RFC5920].

10.  IANA Considerations

   This document defines a new LDP capability parameter TLV.  IANA is
   requested to assign the lowest available value after 0x0500 from "TLV
   Type Name Space" in the "Label Distribution Protocol (LDP)
   Parameters" registry within "Label Distribution Protocol (LDP) Name
   Spaces" as the new code point for the LDP TLV code point.













Wijnands, et al.        Expires September 6, 2018              [Page 11]

Internet-Draft             Multi-Topology mLDP                March 2018


    +-----+------------------+---------------+-------------------------+
    |Value| Description      | Reference     | Notes/Registration Date |
    +-----+------------------+---------------+-------------------------+
    | TBA | MT Multipoint    | This document |                         |
    |     | Capability       |               |                         |
    +-----+------------------+---------------+-------------------------+


                         Figure 7: IANA Code Point

11.  Acknowledgments

   The authors would like to acknowledge Eric Rosen for his input on
   this specification.

12.  References

12.1.  Normative References

   [I-D.hegdeppsenak-isis-sr-flex-algo]
              Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS
              Segment Routing Flexible Algorithm", draft-hegdeppsenak-
              isis-sr-flex-algo-02 (work in progress), February 2018.

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

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              DOI 10.17487/RFC4379, February 2006,
              <https://www.rfc-editor.org/info/rfc4379>.

   [RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
              Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
              RFC 4915, DOI 10.17487/RFC4915, June 2007,
              <https://www.rfc-editor.org/info/rfc4915>.

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120,
              DOI 10.17487/RFC5120, February 2008,
              <https://www.rfc-editor.org/info/rfc5120>.







Wijnands, et al.        Expires September 6, 2018              [Page 12]

Internet-Draft             Multi-Topology mLDP                March 2018


   [RFC6388]  Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
              Thomas, "Label Distribution Protocol Extensions for Point-
              to-Multipoint and Multipoint-to-Multipoint Label Switched
              Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
              <https://www.rfc-editor.org/info/rfc6388>.

   [RFC6425]  Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
              Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
              Failures in Point-to-Multipoint MPLS - Extensions to LSP
              Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,
              <https://www.rfc-editor.org/info/rfc6425>.

   [RFC7307]  Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D.
              King, "LDP Extensions for Multi-Topology", RFC 7307,
              DOI 10.17487/RFC7307, July 2014,
              <https://www.rfc-editor.org/info/rfc7307>.

12.2.  Informative References

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

   [RFC5561]  Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
              Le Roux, "LDP Capabilities", RFC 5561,
              DOI 10.17487/RFC5561, July 2009,
              <https://www.rfc-editor.org/info/rfc5561>.

   [RFC5918]  Asati, R., Minei, I., and B. Thomas, "Label Distribution
              Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
              (FEC)", RFC 5918, DOI 10.17487/RFC5918, August 2010,
              <https://www.rfc-editor.org/info/rfc5918>.

   [RFC5919]  Asati, R., Mohapatra, P., Chen, E., and B. Thomas,
              "Signaling LDP Label Advertisement Completion", RFC 5919,
              DOI 10.17487/RFC5919, August 2010,
              <https://www.rfc-editor.org/info/rfc5919>.

   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
              <https://www.rfc-editor.org/info/rfc5920>.

Authors' Addresses








Wijnands, et al.        Expires September 6, 2018              [Page 13]

Internet-Draft             Multi-Topology mLDP                March 2018


   IJsbrand Wijnands
   Cisco Systems, Inc.
   De kleetlaan 6a
   Diegem  1831
   Belgium

   Email: ice@cisco.com


   Kamran Raza
   Cisco Systems, Inc.
   2000 Innovation Drive
   Kanata, ON  K2K-3E8
   Canada

   Email: skraza@cisco.com


   Zhaohui Zhang
   Juniper Networks
   10 Technology Park Dr.
   Westford  MA  01886
   US

   Email: zzhang@juniper.net


   Arkadiy Gulko
   Thomson Reuters
   195 Broadway
   New York  NY 10007
   USA

   Email: arkadiy.gulko@thomsonreuters.com

















Wijnands, et al.        Expires September 6, 2018              [Page 14]