[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                       L. Andersson
Internet-Draft                                                   M. Chen
Updates: 4379 (if approved)                                       Huawei
Intended status: Standards Track                                T. Petch
Expires: November 01, 2013                      Engineering Networks Ltd
                                                          April 30, 2013


               "MPLS LSP Ping TLVs and sub-TLVs registry"
       draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02.txt

Abstract

   This document addresses issues with the structure, allocation
   policies and clarity in the use of the "TLVs and sub-TLVs" of the
   "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
   Ping Parameters" in the "Multiprotocol Label Switching Architecture
   (MPLS)" name space.

   This document does not change any existing allocations and the new
   structure is backwards compatible with the existing registries.

   The policy for the allocation of TLVs is unchanged but future
   allocations of sub-TLVs will come from a single namespace, common to
   all TLVs of LSP Ping Parameters.

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 http://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 01, 2013.



Andersson, et al.      Expires November 01, 2013                [Page 1]


Internet-Draft  MPLS LSP Ping TLVs and sub-TLVs registry      April 2013


Copyright Notice

   Copyright (c) 2013 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
   (http://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.  Current situation . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Current situation - model . . . . . . . . . . . . . . . .   3
     2.2.  Allocation policies and Scope . . . . . . . . . . . . . .   4
     2.3.  A closer look at the model  . . . . . . . . . . . . . . .   5
   3.  New registry structure  . . . . . . . . . . . . . . . . . . .   6
     3.1.  If we'd done it from start  . . . . . . . . . . . . . . .   7
     3.2.  TLV Registry and allocation procedures  . . . . . . . . .   8
     3.3.  Sub-TLV registries and allocation policies  . . . . . . .   9
       3.3.1.  Sub-TLV registry for all TLVs . . . . . . . . . . . .  10
       3.3.2.  Sub TLV registry for TLV Type 9 . . . . . . . . . . .  12
       3.3.3.  Sub TLV registry for TLV Type 11  . . . . . . . . . .  13
       3.3.4.  Sub TLV registry for TLV Type 20  . . . . . . . . . .  14
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   5.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  15
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  16
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     7.2.  Informative references  . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   This document revises the allocation policies in the use of the TLVs
   and sub-TLVs of the MPLS LSP Ping Parameters, as defined in
   [RFC4379].

   This document does not change any existing allocations and the new
   structure is backwards compatible with the existing registries.





Andersson, et al.      Expires November 01, 2013                [Page 2]


Internet-Draft  MPLS LSP Ping TLVs and sub-TLVs registry      April 2013


   The policy for the allocation of TLVs is unchanged but future
   allocations of sub-TLVs will come from a single namespace, common to
   all TLVs of MPLS LSP Ping Parameters.

   The allocation of existing sub-TLVs is unaltered, so that the meaning
   of, e.g., sub-TLV sub-Type 1 is dependent on the TLV under which it
   appears.  No future allocations will be made with a sub-Type of less
   than 32.  Future allocations will be made from a single namespace
   starting at 32; a sub-TLV defined in this way may appear as part of
   any current or future TLV.  The document that specifies such an
   allocation should state which TLVs the sub-TLV may appear under and
   indicate any other future use which seems appropriate or
   inappropriate.

2.  Current situation

   Today all TLVs and sub-TLVs are found in a single table, and the
   allocation policies are the same for all TLVs and sub-TLVs.  The
   table below illustrates how the registry is set up.

   Initially this might have been a good idea, but over time, with an
   increasing number of TLVs, and with some sub-TLVs shared across TLVs,
   it has become increasingly difficult to understand how the allocation
   policies interact.

2.1.  Current situation - model

   The table below illustrates how the registry is set up and the
   allocation policies work currently.  We have chosen not to just copy
   the current registry here, but instead build a model that shows how
   the allocation policies work.

   --Note to RFC Editor; the various RFC aaaa to RFC zzzz are really
   meant to be like that in the finished document; we are not asking you
   to replace them with anything:-)


              Current TLV and sub-TLV registry (model)

       Type   Sub-type    Value field                Reference
     +------+----------+---------------------------+----------------+
         1  |          |  TLV # 1                  | RFC xxxx     (1)
         1  |     1    |  sub-TLV # 1              | RFC xxxx     (2)
         1  |     2    |  sub-TLV # 2              | RFC yyyy     (3)
         1  |     3    |  sub-TLV # 3              | RFC yyyy     (4)
         2  |          |  TLV # 2                  | RFC xxxx     (5)
         3  |          |  TLV # 3                  | RFC zzzz     (6)
         3  |     1    |  sub-TLV # 1              | RFC zzzz     (7)



Andersson, et al.      Expires November 01, 2013                [Page 3]


Internet-Draft  MPLS LSP Ping TLVs and sub-TLVs registry      April 2013


         3  |     2    |  sub-TLV # 2              | RFC zzzz     (8)
         3  |     3    |  sub-TLV # 3              | RFC aaaa     (9)
         4  |          |  TLV # 4                  | RFC bbbb    (10)
         4  | 1-16383  |  as specified for type 1  | RFC bbbb    (11)
         5  |          |  TLV # 5                  | RFC cccc    (12)
         5  | 1-65535  |  as specified for type 1  | RFC cccc    (13)



   Note: The row number column to the right is added here to discuss
   what is on the different rows.

2.2.  Allocation policies and Scope


             TLV and sub-TLV registration procedures

   Range        | Registration Procedures| Notes
   -------------+------------------------+------------------------------
   0-16383      | Standards Action       | This range is for mandatory
                |                        | TLVs or for optional TLVs
                |                        | that require an error message
                |                        | if not recognized.
   -------------+------------------------+------------------------------
   16384-31743  | Specification Required | Experimental RFC needed
   -------------+------------------------+------------------------------
   31744-32767  | Vendor Private Use     | MUST NOT be allocated
   -------------+------------------------+------------------------------
   32768-49161  | Standards Action       | This range is for optional
                |                        | TLVs that can be silently
                |                        | dropped if not recognized.
   -------------+------------------------+------------------------------
   49162-64511  | Specification Required | Experimental RFC needed
   -------------+------------------------+------------------------------
   64512-65535  | Vendor Private Use     | MUST NOT be allocated
   -------------+------------------------+------------------------------


   The IANA registry does not give enough information to correctly
   allocate TLVs and sub-TLVs, instead careful reading of [RFC4379] is
   necessary.

   [RFC4379] says:

   The valid range for TLVs and sub-TLVs is 0-65535.  Assignments in the
   range 0-16383 and 32768-49161 are made via Standards Action as
   defined in Section 5; assignments in the range 16384-31743 and
   49162-64511 are made via "Specification Required" as defined above;



Andersson, et al.      Expires November 01, 2013                [Page 4]


Internet-Draft  MPLS LSP Ping TLVs and sub-TLVs registry      April 2013


   values in the range 31744-32767 and 64512-65535 are for Vendor
   Private Use, and MUST NOT be allocated.

   [RFC4379] also says that the sub-TLVs are scoped by the TLVs, i.e.  a
   sub-TLV defined for one TLV is valid for that TLV only.  Later the
   practice to re-define (a block of) sub-TLVs defined for one TLV for
   another TLV was introduced.

2.3.  A closer look at the model

   The list below contains what we see as the results of the most common
   allocation requests for this registry.

   1.   Row 1 says that IANA has allocated a TLV as requested in
        RFCxxxx.  This TLV is type 1.

        RFCxxxx is the document that defines the registry and sets up
        the allocation policies.

   2.   Row 2 says that IANA has allocated a sub-TLV for TLV type 1,
        "sub-TLV #1", the source for this allocation is the same that
        defined the registry and allocated the TLV Type 1 (RFCxxxx).

   3.   Row 3 says that IANA has allocated a second sub-TLV (sub-TLV #2)
        for TLV type 1, the source for this allocation is RFCyyyy.

        -

   4.   Row 4 says that IANA has allocated a third sub-TLV (sub-TLV #3)
        for TLV type 1, the source for this allocation is RFCyyyy.

        -

   5.   Row 5 says that IANA has allocated a new TLV (TLV type 2), the
        source for this allocation is RFCxxxx, the same RFC that defined
        the registry.

        TLV type 2 has no sub-TLVs yet defined.

   6.   Row 6 says that IANA has allocated a new TLV (TLV type 3), the
        source for this allocation is RFCzzzz.

        -

   7.   Row 7 says that IANA has allocated a sub-TLV (sub-TLV # 1) for
        TLV type 3, the source for this allocation is RFCzzzz.





Andersson, et al.      Expires November 01, 2013                [Page 5]


Internet-Draft  MPLS LSP Ping TLVs and sub-TLVs registry      April 2013


        This means that we have one sub-TLV # 1 for TLV type 1, and
        another sub-TLV # 1 for TLV type 3.  In itself this is not a
        problem, the sub-TLVs are scoped by the TLVs.

   8.   Row 8 says that IANA has allocated a sub-TLV (sub-TLV # 2) for
        TLV type 3, the source for this allocation is RFCzzzz.

        -

   9.   Row 9 says that IANA has allocated a sub-TLV (sub-TLV # 2) for
        TLV type 3, the source for this allocation is RFCaaaa.

        -

   10.  Row 10 says that IANA has allocated a new TLV (TLV type 4), the
        source for this allocation is RFCbbbb.

        -

   11.  Row 11 says that IANA has been instructed not to allocate any
        sub-TLVs from the range 1-16383, but that the sub-TLVs for TLV
        type 4, shall use the same sub-TLVs that have been specified for
        TLV type 1 in this range.

        This implies that other ranges for TLV type 4 are open for
        allocation for "TLV type 4 specific sub-TLVs".  This is
        specified in RFCbbbb.

   12.  Row 12 says that IANA has allocated a new TLV (TLV type 5), the
        source for this allocation is RFCcccc.

        -

   13.  Row 13 says that IANA has been instructed not to allocate any
        sub-TLVs from the entire range (1-65535), but that the sub-TLVs
        for TLV type 5, shall use the same sub-TLVs that have been
        specified for TLV type 1.  This is specified in RFCcccc.

        Close reading of the allocation rules would likely show that
        disallowing the assignment of vendor-specific sub-TLVs is moot.

3.  New registry structure









Andersson, et al.      Expires November 01, 2013                [Page 6]


Internet-Draft  MPLS LSP Ping TLVs and sub-TLVs registry      April 2013


3.1.  If we'd done it from start

   The name space of sub-TLVs is very large, 65 535 potential TLVs times
   65 535 sub-TLVs per TLV, gives a maximum of 4 294 836 335 sub- TLVs.

   There seems no reason why that number of sub-TLVs should be needed;
   rather, 65 535 sub-TLVs shared among all TLVs would seem to have been
   more than sufficient.  If the IANA registries had been set up with
   one registry for TLVs and another for sub-TLVs, that would have
   resulted in registries and allocation policies much easier to
   understand and comprehend.

   In practice, the same sub-TLV number appears more than once under
   different TLVs with a different meaning on each occasion.  Thus sub-
   TLV 1 appears under TLV Type 1 as LDP IPv4 Prefix, under TLV Type 11
   as IPv4 Egress Address P2MP Responder and under TLV Type 20 as
   Multipath data.  At the same time, TLVs Types 16 and 21 reuse sub-TLV
   1 with the same meaning as for TLV Type 1.

   Thus it is now impossible to create a single registry for sub-TLVs
   which encompasses all existing sub-TLVs.  At the same time, such a
   registry would simplify future registration and use, allowing, for
   example, a sub-TLV to be defined for an IPv6 address that would then
   be used wherever such an address is required.  Hence, the future
   policy for the registration of sub-TLVs is to have a single registry
   regardless of which TLV the sub-TLV appears under.  This registry
   follows the same pattern as the existing registries, namely of


   0-16383      | Standards Action       | Mandatory (sub)TLVs
   -------------+------------------------+--------------------------
   16384-31743  | Specification Required | Mandatory Experimental
                |                        | RFC needed
   -------------+------------------------+--------------------------
   31744-32767  | Vendor Private Use     | MUST NOT be allocated
   -------------+------------------------+--------------------------
   32768-49161  | Standards Action       | Optional (sub)TLVs
   -------------+------------------------+--------------------------
   49162-64511  | Specification Required | Optional Experimental
                |                        | RFC needed
   -------------+------------------------+--------------------------
   64512-65535  | Vendor Private Use     | MUST NOT be allocated
   -------------+------------------------+--------------------------


   excepting that the range 0 to 31 is now reserved and MUST NOT be
   assigned lest there is an overlap with existing definitions.  The
   choice of 32 is somewhat greater than the greatest, existing, defined



Andersson, et al.      Expires November 01, 2013                [Page 7]


Internet-Draft  MPLS LSP Ping TLVs and sub-TLVs registry      April 2013


   sub-TLV, 25 for TLV Type 1, and is chosen to be a more user-friendly,
   easier to remember, number than, say, 26 or 29.

   The examples in TLV Registry and allocation procedures (Section 3.2)
   and Sub-TLV registries and allocation policies (Section 3.3) are the
   actual allocations in the IANA registry as they are found at the time
   of writing of this document (January 2013).

3.2.  TLV Registry and allocation procedures


             TLV registration procedures

   Range        | Registration Procedures| Notes
   -------------+------------------------+------------------------------
   0-16383      | Standards Action       | This range is for mandatory
                |                        | TLVs or for optional TLVs
                |                        | that require an error message
                |                        | if not recognized.
   -------------+------------------------+------------------------------
   16384-31743  | Specification Required | Experimental RFC needed
                |                        | This range is for mandatory
                |                        | TLVs or for optional TLVs
                |                        | that require an error message
                |                        | if not recognized.
   -------------+------------------------+------------------------------
   31744-32767  | Vendor Private Use     | MUST NOT be allocated
   -------------+------------------------+------------------------------
   32768-49161  | Standards Action       | This range is for optional
                |                        | TLVs that can be silently
                |                        | discarded if not recognized.
   -------------+------------------------+------------------------------
   49162-64511  | Specification Required | Experimental RFC needed
                |                        | This range is for optional
                |                        | TLVs that can be silently
                |                        | discarded if not recognized.
   -------------+------------------------+------------------------------
   64512-65535  | Vendor Private Use     | MUST NOT be allocated
   -------------+------------------------+------------------------------

   LSP Ping TLV Registry

   Type          | Value Field                  | Reference
   --------------+------------------------------+---------------------
   1             | Target FEC Stack             | [RFC4379]
   --------------+------------------------------+---------------------
   2             | Downstream Mapping           | [RFC4379]
                 | (DEPRECATED)                 | [RFC6424]



Andersson, et al.      Expires November 01, 2013                [Page 8]


Internet-Draft  MPLS LSP Ping TLVs and sub-TLVs registry      April 2013


   --------------+------------------------------+---------------------
   3             | Pad                          | [RFC4379]
   --------------+------------------------------+---------------------
   4             | Not Assigned                 | [RFC4379]
   --------------+------------------------------+---------------------
   5             | Vendor Enterprise Number     | [RFC4379]
   --------------+------------------------------+---------------------
   6             | Not Assigned                 | [RFC4379]
   --------------+------------------------------+---------------------
   7             | Interface and Label Stack    | [RFC4379]
   --------------+------------------------------+---------------------
   8             | Not Assigned                 | [RFC4379]
   --------------+------------------------------+---------------------
   9             | Errored TLVs                 | [RFC4379]
   --------------+------------------------------+---------------------
   10            | Reply TOS Byte               | [RFC4379]
   --------------+------------------------------+---------------------
   11            | P2MP Responder Identifier    | [RFC6425]
   --------------+------------------------------+---------------------
   12            | Echo Jitter                  | [RFC6425]
   --------------+------------------------------+---------------------
   13            | Source ID                    | [RFC6426]
   --------------+------------------------------+---------------------
   14            | Destination ID               | [RFC6426]
   --------------+------------------------------+---------------------
   15            | BFD Discriminator            | [RFC5884]
   --------------+------------------------------+---------------------
   16            | Reverse-path Target FEC Stack| [RFC6426]
   --------------+------------------------------+---------------------
   17-19         | Unassigned                   |
   --------------+------------------------------+---------------------
   20            | Downstream Detailed Mapping  | [RFC6424]
   --------------+------------------------------+---------------------
   22-31743      | Unassigned                   |
   --------------+------------------------------+---------------------
   31744-32767   | Reserved for Vendor          | [RFC4379]
                 | private use                  |
   --------------+------------------------------+---------------------
   32768-64511   | Unassigned                   |
   --------------+------------------------------+---------------------
   64512-65535   | Reserved for Vendor          | [RFC4379]
                 | private use                  |
   --------------+------------------------------+---------------------



3.3.  Sub-TLV registries and allocation policies




Andersson, et al.      Expires November 01, 2013                [Page 9]


Internet-Draft  MPLS LSP Ping TLVs and sub-TLVs registry      April 2013


3.3.1.  Sub-TLV registry for all TLVs


             Registration procedures for all sub-TLVs


   Range       | Registration Procedures| Notes
   ------------+------------------------+------------------------------
   0-31        | Reserved               | Existing allocations in this
               |                        | range are unaltered.
               |                        | No future allocations are
               |                        | to be made from this range.
   ------------+------------------------+------------------------------
   32-16383    | Standards Action       | This range is for mandatory
               |                        | sub-TLVs or for optional
               |                        | sub-TLVs that require an
               |                        | error message if not
               |                        | recognized.
   ------------+------------------------+------------------------------
   16384-31743 | Specification Required | Experimental RFC needed
               |                        | This range is for mandatory
               |                        | sub-TLVs or for optional
               |                        | sub-TLVs that require an
               |                        | error message if not
               |                        | recognized.
   ------------+------------------------+------------------------------
   31744-32767 | Vendor Private Use     | MUST NOT be allocated
   ------------+------------------------+------------------------------
   32768-49161 | Standards Action       | This range is for optional
               |                        | sub-TLVs that can be silently
               |                        | discarded if not recognized.
   ------------+------------------------+------------------------------
   49162-64511 | Specification Required | Experimental RFC needed
               |                        | This range is for optional
               |                        | sub-TLVs that can be silently
               |                        | discarded if not recognized.
   ------------+------------------------+------------------------------
   64512-65535 | Vendor Private Use     | MUST NOT be allocated
   ------------+------------------------+------------------------------

                       Type 1 TLV sub-TLVs

   Sub-TLVs for TLV Type 1

   Sub-TLV    | Value Field                   | Reference
   -----------+-------------------------------+--------------------
   0          | Reserved - do not assign      | This document
   -----------+-------------------------------+--------------------



Andersson, et al.      Expires November 01, 2013               [Page 10]


Internet-Draft  MPLS LSP Ping TLVs and sub-TLVs registry      April 2013


   1          | LDP IPv4 prefix               | [RFC4379]
   -----------+-------------------------------+--------------------
   2          | LDP IPv6 prefix               | [RFC4379]
   -----------+-------------------------------+--------------------
   3          | RSVP IPv4 LSP                 | [RFC4379]
   -----------+-------------------------------+--------------------
   4          | RSVP IPv6 LSP                 | [RFC4379]
   -----------+-------------------------------+--------------------
   5          | Not Assigned                  | [RFC4379]
   -----------+-------------------------------+--------------------
   6          | VPN IPv4 prefix               | [RFC4379]
   -----------+-------------------------------+--------------------
   7          | VPN IPv6 prefix               | [RFC4379]
   -----------+-------------------------------+--------------------
   8          | L2 VPN endpoint               | [RFC4379]
   -----------+-------------------------------+--------------------
   9          | "FEC 128" Pseudowire - IPv4   | [RFC4379]
              | (DEPRECATED)                  | [RFC6829]
   -----------+-------------------------------+--------------------
   10         | "FEC 128" Pseudowire - IPv4   | [RFC4379]
              |                               | [RFC6829]
   -----------+-------------------------------+--------------------
   11         | "FEC 129" Pseudowire - IPv4   | [RFC4379]
              |                               | [RFC6829]
   -----------+-------------------------------+--------------------
   12         | BGP labeled IPv4 prefix       | [RFC4379]
   -----------+-------------------------------+--------------------
   13         | BGP labeled IPv6 prefix       | [RFC4379]
   -----------+-------------------------------+--------------------
   14         | Generic IPv4 prefix           | [RFC4379]
   -----------+-------------------------------+--------------------
   15         | Generic IPv6 prefix           | [RFC4379]
   -----------+-------------------------------+--------------------
   16         | Nil FEC                       | [RFC4379]
   -----------+-------------------------------+--------------------
   17         | RSVP P2MP IPv4 Session        | [RFC6425]
   -----------+-------------------------------+--------------------
   18         | RSVP P2MP IPv6 Session        | [RFC6425]
   -----------+-------------------------------+--------------------
   19         | Multicast P2MP LDP FEC Stack  | [RFC6425]
   -----------+-------------------------------+--------------------
   20         | Multicast MP2MP LDP FEC Stack | [RFC6425]
   -----------+-------------------------------+--------------------
   21         | Unassigned                    |
   -----------+-------------------------------+--------------------
   22         | Static LSP                    | [RFC6426]
   -----------+-------------------------------+--------------------
   23         | Static Pseudowire             | [RFC6426]



Andersson, et al.      Expires November 01, 2013               [Page 11]


Internet-Draft  MPLS LSP Ping TLVs and sub-TLVs registry      April 2013


   -----------+-------------------------------+--------------------
   24         | "FEC 128" Pseudowire - IPv6   | [RFC6829]
   -----------+-------------------------------+--------------------
   25         | "FEC 129" Pseudowire - IPv6   | [RFC6829]
   -----------+-------------------------------+--------------------




3.3.2.  Sub TLV registry for TLV Type 9

   TLV Type 9 has a very different allocation policy to all other TLVs;
   any value carried in the Value field of the TLV is a copy of a TLV
   that has not been understood or recognized.  It is even doubtful that
   "All values" technically is a sub-TLV, but both the IANA registry and
   [RFC4379] says it is.  Equally, it is unclear whether or not TLV Type
   9 should be used to report a sub-TLV that has not been recognised and
   if it is, how that sub-TLV should appear in the Type 9 TLV.  More
   work on this is needed but that falls outside the scope of this
   document.


             Registration procedures TLV type 9 sub-TLVs

   Range      | Registration Procedures  | Notes
   -----------+--------------------------+----------------------------
   0-65635    | Reserved MUST NOT be     | Any value carried in the
              | assigned                 | value field of TLV type 9
              |                          | means that a TLV has not
              |                          | been understood.
   -----------+--------------------------+------------------------------



                       Type 9 TLV sub-TLVs


   Sub-TLVs for TLV Type 9

   Sub-TLV    | Value Field                   | Reference
   -----------+-------------------------------+--------------------
   All values | TLV that is not understood    | [RFC4379]
   -----------+-------------------------------+--------------------








Andersson, et al.      Expires November 01, 2013               [Page 12]


Internet-Draft  MPLS LSP Ping TLVs and sub-TLVs registry      April 2013


3.3.3.  Sub TLV registry for TLV Type 11


             Registration procedures TLV type 11 sub-TLVs
                     (as specified by RFC6425)

   Range        | Registration Procedures| Notes
   -------------+------------------------+------------------------------
   0-16383      | Standards Action       | This range is for mandatory
                |                        | TLVs or for optional TLVs
                |                        | that require an error message
                |                        | if not recognized.
   -------------+------------------------+------------------------------
   16384-31743  | Specification Required | Experimental RFC needed
   -------------+------------------------+------------------------------
   31744-32767  | Vendor Private Use     | MUST NOT be allocated
   -------------+------------------------+------------------------------
   32768-49161  | Standards Action       | This range is for optional
                |                        | TLVs that can be silently
                |                        | dropped if not recognized.
   -------------+------------------------+------------------------------
   49162-64511  | Specification Required | Experimental RFC needed
   -------------+------------------------+------------------------------
   64512-65535  | Vendor Private Use     | MUST NOT be allocated
   -------------+------------------------+------------------------------






                       Type 11 TLV sub-TLVs

   sub-TLV      Value Field                     Reference
   -----------+-------------------------------+-------------------
   0          | Reserved not to be assigned   | This document
   -----------+-------------------------------+-------------------
   1          | IPv4 Egress Address P2MP      | [RFC6425]
              | Responder                     |
   -----------+-------------------------------+-------------------
   2          | IPv6 Egress Address P2MP      | [RFC6425]
              | Responder                     |
   -----------+-------------------------------+-------------------
   3          | IPv4 Node Address P2MP        | [RFC6425]
              | Responder                     |
   -----------+-------------------------------+-------------------
   4          | IPv6 Node Address P2MP        | [RFC6425]
              | Responder                     |



Andersson, et al.      Expires November 01, 2013               [Page 13]


Internet-Draft  MPLS LSP Ping TLVs and sub-TLVs registry      April 2013


   -----------+-------------------------------+-------------------






3.3.4.  Sub TLV registry for TLV Type 20


             Registration procedures TLV type 20 sub-TLVs
                 (as specified by RFC6424)

   Range        | Registration Procedures| Notes
   -------------+------------------------+------------------------------
   0-16383      | Standards Action       | This range is for mandatory
                |                        | TLVs or for optional TLVs
                |                        | that require an error message
                |                        | if not recognized.
   -------------+------------------------+------------------------------
   16384-31743  | Specification Required | Experimental RFC needed
   -------------+------------------------+------------------------------
   31744-32767  | Vendor Private Use     | MUST NOT be allocated
   -------------+------------------------+------------------------------
   32768-49161  | Standards Action       | This range is for optional
                |                        | TLVs that can be silently
                |                        | dropped if not recognized.
   -------------+------------------------+------------------------------
   49162-64511  | Specification Required | Experimental RFC needed
   -------------+------------------------+------------------------------
   64512-65535  | Vendor Private Use     | MUST NOT be allocated
   -------------+------------------------+------------------------------


                       Type 20 TLV sub-TLVs

   sub-TLV      Value Field                     Reference
   -----------+-------------------------------+-------------------
   1          | Multipath data                | [RFC6424]
   -----------+-------------------------------+-------------------
   2          | Label stack                   | [RFC6424]
   -----------+-------------------------------+-------------------
   3          | FEC stack change              | [RFC6424]
   -----------+-------------------------------+-------------------







Andersson, et al.      Expires November 01, 2013               [Page 14]


Internet-Draft  MPLS LSP Ping TLVs and sub-TLVs registry      April 2013


4.  Security Considerations

   This document amends the policy for the registration of sub-TLVs of
   MPLS LSP Ping.  As such, it does not introduce any additional
   security considerations over and above those included with the
   specification of the sub-TLVs themselves.

5.  IANA considerations

   This document revises the allocation policies in the use of the TLVs
   and sub-TLVs of the MPLS LSP Ping Parameters, as previously defined
   in [RFC4379].

   The allocation policy for TLVs is unaltered from RFC4379 but the IANA
   registry should be updated to refer to this document, lest users of
   this information do not appreciate that the policies for sub-TLVs, as
   specified in [RFC4379], no longer apply; that is, users are directed
   here first, so that they have the current, overall procedures.

   The allocation policy for sub-TLVs is that all sub-TLVS now come from
   a common pool so that a sub-TLV sub-Type number is now unique within
   all of MPLS LSP Ping Parameters.

   The lowest value for allocation of any sub-TLV sub-Type is 32, so as
   to avoid overlap with any sub-TLV Type currently defined or under
   consideration.

   The registration procedure is as specified in Sub-TLV registry for
   all TLVs (Section 3.3.1), namely



   Range       | Registration Procedures| Notes
   ------------+------------------------+------------------------------
   0-31        | Reserved               | Existing allocations in this
               |                        | range are unaltered.
               |                        | No future allocations are
               |                        | to be made from this range.
   ------------+------------------------+------------------------------
   32-16383    | Standards Action       | This range is for mandatory
               |                        | sub-TLVs or for optional
               |                        | sub-TLVs that require an
               |                        | error message if not
               |                        | recognized.
   ------------+------------------------+------------------------------
   16384-31743 | Specification Required | Experimental RFC needed
               |                        | This range is for mandatory
               |                        | sub-TLVs or for optional



Andersson, et al.      Expires November 01, 2013               [Page 15]


Internet-Draft  MPLS LSP Ping TLVs and sub-TLVs registry      April 2013


               |                        | sub-TLVs that require an
               |                        | error message if not
               |                        | recognized.
   ------------+------------------------+------------------------------
   31744-32767 | Vendor Private Use     | MUST NOT be allocated
   ------------+------------------------+------------------------------
   32768-49161 | Standards Action       | This range is for optional
               |                        | sub-TLVs that can be silently
               |                        | discarded if not recognized.
   ------------+------------------------+------------------------------
   49162-64511 | Specification Required | Experimental RFC needed
               |                        | This range is for optional
               |                        | sub-TLVs that can be silently
               |                        | discarded if not recognized.
   ------------+------------------------+------------------------------
   64512-65535 | Vendor Private Use     | MUST NOT be allocated
   ------------+------------------------+------------------------------


6.  Acknowledgments

   TBD

7.  References

7.1.  Normative References

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

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              February 2006.

7.2.  Informative references

   [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
              "Bidirectional Forwarding Detection (BFD) for MPLS Label
              Switched Paths (LSPs)", RFC 5884, June 2010.

   [RFC6424]  Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
              Performing Label Switched Path Ping (LSP Ping) over MPLS
              Tunnels", RFC 6424, November 2011.

   [RFC6425]  Saxena, S., 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, November 2011.



Andersson, et al.      Expires November 01, 2013               [Page 16]


Internet-Draft  MPLS LSP Ping TLVs and sub-TLVs registry      April 2013


   [RFC6426]  Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
              On-Demand Connectivity Verification and Route Tracing",
              RFC 6426, November 2011.

   [RFC6829]  Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label
              Switched Path (LSP) Ping for Pseudowire Forwarding
              Equivalence Classes (FECs) Advertised over IPv6", RFC
              6829, January 2013.

Authors' Addresses

   Loa Andersson
   Huawei

   Email: loa@mail01.huawei.com


   Mach(Guoyi) Chen
   Huawei

   Email: mach.chen@huawei.com


   Tom Petch
   Engineering Networks Ltd

   Email: tomSecurity@network-engineer.co.uk























Andersson, et al.      Expires November 01, 2013               [Page 17]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/