Internet DRAFT - draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry
draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry
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]
