draft-ietf-mpls-lsp-ping-registries-update-01.txt   draft-ietf-mpls-lsp-ping-registries-update-02.txt 
MPLS Working Group L. Andersson MPLS Working Group L. Andersson
Internet-Draft Bronze Dragon Consulting Internet-Draft Bronze Dragon Consulting
Updates: 8029, 8611 (if approved) M. Chen Updates: 8029, 8611 (if approved) M. Chen
Intended status: Standards Track Huawei Techologies Intended status: Standards Track Huawei Techologies
Expires: September 6, 2020 C. Pignataro Expires: October 18, 2020 C. Pignataro
Cisco Systems Cisco Systems
T. Saad T. Saad
Juniper Networks Juniper Networks
March 5, 2020 April 16, 2020
Updating the IANA MPLS LSP Ping Parameters Updating the IANA MPLS LSP Ping Parameters
draft-ietf-mpls-lsp-ping-registries-update-01 draft-ietf-mpls-lsp-ping-registries-update-02
Abstract Abstract
This document updates RFC 8029 and RFC 8611 that define IANA This document updates RFC 8029 and RFC 8611 that both define IANA
registries for MPLS LSP Ping. The updates are mostly for registries for MPLS LSP Ping. It also updates the language that is
clarification and to align this registry with recent developments.. used to define the procedures for responses are sent when an unkwon
or errored code point is found. The updates are for clarification
and to align this name space with recent developments.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2020. This Internet-Draft will expire on October 18, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 18
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3
2. Updating the Message Types, Reply Mode and Return Codes 2. Updating the Message Types, Reply Mode and Return Codes
Registries . . . . . . . . . . . . . . . . . . . . . . . . . 3 Registries . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Updating the TLV and sub-TLV registries . . . . . . . . . . . 4 3. Updating the TLV and sub-TLV registries . . . . . . . . . . . 4
3.1. General principles the LSP Ping TLV and sub-TLV 3.1. General principles the LSP Ping TLV and sub-TLV
registries . . . . . . . . . . . . . . . . . . . . . . . 5 registries . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Unrecognized Experimental and Private TLVs and sub- 3.1.1. Unrecognized Experimental and Private TLVs and sub-
TLVs . . . . . . . . . . . . . . . . . . . . . . . . 6 TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Changes to the LSP Ping registries . . . . . . . . . . . 6 3.2. Changes to the LSP Ping Registries . . . . . . . . . . . 5
3.2.1. Common changes to the TLV and sub-TLV registries . . 6 3.2.1. Common Changes to the TLV and sub-TLV Registries . . 5
4. Text chages/updates to related RFCs . . . . . . . . . . . . . 7 4. Text Chages/Updates to Related RFCs . . . . . . . . . . . . . 6
4.1. Text changes to RFC 8029 . . . . . . . . . . . . . . . . 7 4.1. Text Changes to RFC 8029 . . . . . . . . . . . . . . . . 6
4.1.1. Comments to this changes to RFC 8029 . . . . . . . . 8 4.2. Text Changes to RFC 8611 . . . . . . . . . . . . . . . . 7
4.2. Text changes to RFC 8611 . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4.2.1. Comments to this changes to RFC 8611 . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6.1. Updates of Message Type, Reply Mode and Return Codes
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 Registries . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. New Message Type, Reply Mode and Return Codes registries 9 6.2. Common Registration Procedures for TLVs and sub-TLVs . . 9
6.2. Common Registration Procedures for TLVs and sub-TLVs . . 10 6.3. IANA Assignments for TLVs and sub-TLVs . . . . . . . . . 9
6.3. IANA assignments for TLVs and sub-TLVs . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
When RFC 8029 [RFC8029] was published it contained among other things When RFC 8029 [RFC8029] was published it contained updates to the
updates to the "Multiprotocol Label Switching (MPLS) Label Switched "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
Paths (LSPs) Ping Parameters" IANA name space [IANA-LSP-PING]. Ping Parameters" IANA name space [IANA-LSP-PING].
RFC 8611 [RFC8611] updated the LSP Ping IANA registries to match RFC RFC 8611 [RFC8611] updated the LSP Ping IANA registries to match RFC
8029, but the registrations can be further clarified and their 8029. This document further clarifies the entries in those
definitions more precise. registries and makes the definitions more precise.
This document updates RFC 8029 [[RFC8029] and RFC 8611 [RFC8611] by This document updates RFC 8029 [[RFC8029] and RFC 8611 [RFC8611] by
updating two groups of registries. updating two groups of registries as follows:
First the registries for Message Types [IANA-MT], Reply Modes First the registries for Message Types [IANA-MT], Reply Modes
[IANA-RM] and Return Codes [IANA-RC]. The changes to these [IANA-RM] and Return Codes [IANA-RC] are updated. The changes to
registries are minor. these registries are minor.
Second, this document updates the TLV and sub-TLV registries. Second, this document updates the TLV and sub-TLV registries.
o TLVs [IANA-TLV-reg] o TLVs [IANA-TLV-reg]
o Sub-TLVs for TLVs 1, 16 and 21 [IANA-Sub-1-16-21] o Sub-TLVs for TLVs 1, 16 and 21 [IANA-Sub-1-16-21]
o Sub-TLVs for TLV 6 [IANA-Sub-6] o Sub-TLVs for TLV 6 [IANA-Sub-6]
o Sub-TLVs for TLV 11 [IANA-Sub-11] o Sub-TLVs for TLV 11 [IANA-Sub-11]
o Sub-TLVs for TLV 20 [IANA-Sub-20] o Sub-TLVs for TLV 20 [IANA-Sub-20]
o Sub-TLVs for TLV 23 [IANA-Sub-23] o Sub-TLVs for TLV 23 [IANA-Sub-23]
o Sub-TLVs for TLV 27 [IANA-Sub-27] o Sub-TLVs for TLV 27 [IANA-Sub-27]
The registry for sub-TLVs for TLV 9 [IANA-Sub-9] is not updated. The registry for sub-TLVs for TLV 9 [IANA-Sub-9] is not updated.
Third, some code points (TLVs and sub-TLVs) are "mandatory" and
"optional". Contrary to how other RFCs use these words, indicating
that it is mandatory or optional to include the code points in a
message, RFC 8029 use the words to indicate that an acction might or
might nt be nesesary. The words "mandatory and "optional" are
dropped and the text is changed to focus on what should be doen.
1.1. Requirement Language 1.1. Requirement Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Updating the Message Types, Reply Mode and Return Codes Registries 2. Updating the Message Types, Reply Mode and Return Codes Registries
The following changes are made to the Message Types, Reply Modes and The following changes are made to the Message Types, Reply Modes and
Return Codes [IANA-MT] registries. Return Codes [IANA-MT] registries.
o a small set of code points (4 code points) for experimental use is o In the listing of assignments the term "Vendor Private Use" is
added, actually they are take from the range for "Private Use". changed to "Private Use"
o a small set of code points (4 code points) for Experimental Use is
added by reducing the range for "Private Use".
o the registration procedure "Specification Required" is changed to o the registration procedure "Specification Required" is changed to
"RFC Required" and the note "Experimental RFC needed" is removed "RFC Required" and the note "Experimental RFC needed" is removed
o In the listing of assignments the term "Vendor Private Use" is
changed to "Private Use"
o the registration procedures "Private Use" and "Experimental Use" o the registration procedures "Private Use" and "Experimental Use"
are added to the table of registration procedures are added to the table of registration procedures
o A note "Not to be assigned" is added for the registration o A note "Not to be assigned" is added for the registration
procedures "Private Use" and "Experimental Use" procedures "Private Use" and "Experimental Use"
o In the list that capture the assignment status, the fields that o In the list that capture the assignment status, the fields that
are reserved, i.e. 0, Private Use and Experimental Use are are reserved, i.e. 0, Private Use and Experimental Use are
clearly marked. clearly marked.
* In the Return Codes [IANA-RC] registry the code point "0" * In the Return Codes [IANA-RC] registry the code point "0"
already been assigned. This assignment is not changed and this already been assigned. This assignment is not changed and this
registry will not have the "0" value "Reserved". registry will not have the "0" value "Reserved".
The new Registration Procedures layout and the new assignments for The new Registration Procedures layout and the new assignments for
these registries will be found in Section 6.1. these registries will be found in Section 6.1.
3. Updating the TLV and sub-TLV registries 3. Updating the TLV and sub-TLV registries
When a new LSP Ping sub-TLV registry were created by RFC 8611
[RFC8611] this registry "Sub-TLVs for TLV Type 6" [IANA-Sub-6] was
set up following the intentions of RFC 8029.
The registry for "Sub-TLVs for TLV Type 6" will serve as a model to
change/update the rest of the TLV and sub-TLV registries in this name
space.
The registration procedures in the current registry for "Sub-TLVs for
TLV Type 6" looks like this (2019-06-20). This will be used as a
base-line and some additions/changes will be made as captured in the
Appendixes:
+-------------+-------------------+---------------------------------+
| Range | Registration | Note |
| | Procedures | |
+-------------+-------------------+---------------------------------+
| 0-16383 | Standards Action | This range is for mandatory |
| | | TLVs or for optional TLVs that |
| | | require an error message if not |
| | | recognized. |
| 16384-31743 | RFC Required | This range is for mandatory |
| | | TLVs or for optional TLVs that |
| | | require an error message if not |
| | | recognized. |
| 31744-32767 | Private Use | Not to be assigned |
| 32768-49161 | Standards Action | This range is for optional TLVs |
| | | that can be silently dropped if |
| | | not recognized. |
| 49162-64511 | RFC Required | This range is for optional TLVs |
| | | that can be silently dropped if |
| | | not recognized. |
| 64512-65535 | Private Use | Not to be assigned |
+-------------+-------------------+---------------------------------+
Sub-TLVs for TLV Type 6 Registration Procedures
This document adds small ranges of code points for Experimental Use
to this registry and to registries listed in Section 6.2.
All registries will be changed to reflect the same model.
3.1. General principles the LSP Ping TLV and sub-TLV registries 3.1. General principles the LSP Ping TLV and sub-TLV registries
The following principles are valid for all the LSP Ping TLV and sub- The following principles are valid for all the LSP Ping TLV and sub-
TLV IANA registries TLV IANA registries
o all mandatory TLVs and sub-TLVs requires a response if the are not o all TLVs and sub-TLVs with a typ in the the range 0-32767 require
recognized a response if they are not recognized
o some optional TLVs and sub-TLVs requires a response if the are not
recognized
o some optional TLVs and sub-TLVs may be silently dropped if the are o all TLVs and sub-TLVs in the range 32768-65535 may be silently
not recognized dropped if the are not recognized
The range of each TLV and sub-TLV registry is divided into to blocks, The range of each TLV and sub-TLV registry is divided into wto
one with a range from 0 to 49161 for TLVs and sub-TLVs that require a blocks, one with a range from 0 to 32767 for TLVs and sub-TLVs that
response if not recognized. Another block in the range from 49161 to require a response if not recognized. Another block in the range
65535, this block is for TLVs and sub-TLVs that may be silently from 32768 to 65535, this block is for TLVs and sub-TLVs that may be
dropped if not recognized. silently dropped if not recognized.
Each of the blocks have code point spaces with the following Each of the blocks has code point spaces with the following
registration procedures: registration procedures:
o Standards Action o Standards Action
o RFC Required o RFC Required
o Experimental Use o Experimental Use
o Private Use o Private Use
The exact defintion of registration procedures for IANA registries The exact defintion of registration procedures for IANA registries
are found in [RFC8126] are found in [RFC8126]
3.1.1. Unrecognized Experimental and Private TLVs and sub-TLVs 3.1.1. Unrecognized Experimental and Private TLVs and sub-TLVs
Unrecognized TLVs and sub-TLVs for Expereimetal USe and Privagte Use Unrecognized TLVs and sub-TLVs for Expereimetal USe and Privagte Use
are handled as any other unrecognised TLV or sub-TLV. are handled as any other unrecognised TLV or sub-TLV.
skipping to change at page 6, line 40 skipping to change at page 5, line 30
range (64512-64515) or from the Private Use range (64515-65535) range (64512-64515) or from the Private Use range (64515-65535)
the TLVs SHOULD be silently ignored. the TLVs SHOULD be silently ignored.
IETF does not prescribe how recognized or unrecognized Experimental IETF does not prescribe how recognized or unrecognized Experimental
Use and Private Use TLVs and sub-TLVs are handled in experimental or Use and Private Use TLVs and sub-TLVs are handled in experimental or
private networks, that is up to the agency running the experiment or private networks, that is up to the agency running the experiment or
the private network. The statement above relates to how standard the private network. The statement above relates to how standard
compliant implementations will treat the unrecognized TLVs and sub- compliant implementations will treat the unrecognized TLVs and sub-
TLVs from these ranges. TLVs from these ranges.
3.2. Changes to the LSP Ping registries 3.2. Changes to the LSP Ping Registries
This section lists the changes to each MPLS LSP Ping Registry, in This section lists the changes to each MPLS LSP Ping Registry.
Section 6.1, Section 6.2 and Section 6.3 the changes are detailed and Section 6.1, Section 6.2 and Section 6.3 set out how the new versions
it is shown what the IANA registry version of the registration of the IANA registries should look, together with the registration
procedures and assignments would look like. procedures.
3.2.1. Common changes to the TLV and sub-TLV registries 3.2.1. Common Changes to the TLV and sub-TLV Registries
The following changes are made to the TLV and sub-TLV registries. The following changes are made to the TLV and sub-TLV registries.
o two small set of code points (2 times 4 code points) for o the registration procedures "Private Use" and "Experimental Use"
are added to the table of registration procedures
o two small sets of code points (2 times 4 code points) for
experimental use is added, actually they are take from the range experimental use is added, actually they are take from the range
for "Private Use". for "Private Use".
o the registration procedure "Specification Required" is changed to o the registration procedure "Specification Required" is changed to
"RFC Required" and the note "Experimental RFC needed" is removed "RFC Required" and the note "Experimental RFC needed" is removed
o In the listing of assignements the term "Vendor Private Use" is o In the listing of assignements the term "Vendor Private Use" is
changed to "Private Use" changed to "Private Use"
o In the listing of assignments the range for "Experimental Use" is o In the listing of assignments the range for "Experimental Use" is
added added
o the registration procedures "Private Use" and "Experimental Use"
are added to the table of registration procedures
o A note "Not to be assigned" is added for the registration o A note "Not to be assigned" is added for the registration
procedures "Experimental Use" and "Private Use" procedures "Experimental Use" and "Private Use"
o In the list that capture assignment status, the fields that are o In the list that capture assignment status, the fields that are
reserved, i.e. 0, Experimental Use and Private Use are clearly reserved, i.e. 0, Experimental Use and Private Use are clearly
marked. marked.
The new Registration Procedures description and the new assignments The new Registration Procedures description and the new assignments
for these registries will be found in Section 6.2 and Section 6.3. for these registries will be found in Section 6.2 and Section 6.3.
4. Text chages/updates to related RFCs 4. Text Chages/Updates to Related RFCs
Some referenced RFCs are using the concept "mandatory TLVs" and Some referenced RFCs are using the concept "mandatory TLVs" and
"mandatory sub-TLVs" to indicate that if a TLV or sub-TLV of the "mandatory sub-TLVs" to indicate that if a TLV or sub-TLV of the
range 0-16383 or 16384-31743 is present in a message but not range 0-16383 or 16384-31743 is present in a message but not
understood, error message need to be sent in response. understood, error message need to be sent in response.
Since other RFCs are using "mandatory TLVs" and "mandatory sub-TLVs" Since other RFCs are using "mandatory TLVs" and "mandatory sub-TLVs"
to indicate TLVs and sub-TLVs ths must be present in a message, we to indicate TLVs and sub-TLVs that must be present in a message, we
want to discontinue the use of "mandatory" to indicate TLVs and sub- want to discontinue the use of "mandatory" to indicate TLVs and sub-
TLVs that requires an error message in response if not understood. TLVs that requires an error message in response if not understood.
The changes to the RFCs below are intended to align with this The changes to the RFCs below are intended to align with this
practice. practice.
4.1. Text changes to RFC 8029 4.1. Text Changes to RFC 8029
In section 3 RFC 8029 says:
Types less than 32768 (i.e., with the high-order bit equal to 0)
are mandatory TLVs that MUST either be supported by an
implementation or result in the Return Code of 2 ("One or more of
the TLVs was not understood") being sent in the echo response.
Types greater than or equal to 32768 (i.e., with the high-order Mandatory and optional is used in this way on page 14 and 15 in
bit equal to 1) are optional TLVs that SHOULD be ignored if the Section 3 of RFC 8029.
implementation does not understand or support them.
This text is nows changed to: The text in those two paragraphs are now changed to:
TLV and sub-TLV Types less than 32768 (i.e., with the high-order TLV and sub-TLV Types less than 32768 (i.e., with the high-order
bit equal to 0) are TLVs and sub-TLVs that MUST either be bit equal to 0) are TLVs and sub-TLVs that MUST either be
supported by an implementation or result in the Return Code of 2 supported by an implementation or result in the Return Code of 2
("One or more of the TLVs was not understood") being sent in the ("One or more of the TLVs was not understood") being sent in the
echo response. echo response.
TLV and sub-TLV Types greater than or equal to 32768 (i.e., with An implementation that does not understand or support a received
the high-order bit equal to 1) are TLVs and sub-TLVs that SHOULD TLV or sub-TLV with Type greater than or equal to 32768 (i.e.,
be ignored if the implementation does not understand or support with the high-order bit equal to 1) SHOULD ignore and step over
them. the TLV or sub-TLV, however an implementation MAY send an echo
response with Return Code 2 ("One or more of the TLVs was not
4.1.1. Comments to this changes to RFC 8029 understood") as it would have doen if the high order bit had been
clear.
1. RFC 8029 is a Standard Tracks RFC. Ranges 0-16383 and
32768-49161 are assigned by Standards Action. Ranges 31744-32767
and 49162-64511 are assigned by RFC Required, as specified e.g.
in Section 6.2 in this doucument.
2. The text is change in two ways
First, the ambigous use of "mandatory" and "optional" is In Section 3.8 of RFC 8029 "mandatory" is used in the same way. The
removed, first two paragaraphs of this section ar now changed to read:
Second, it is clarified that both un-supported or not The following TLV is a TLV that MAY be included in an echo reply
recognized TLVs and sub-TLVs will generate an error message in to inform the sender of an echo request icluding TLVs or sub-TLVs
the Echo Reply message. Types greater than or equal to 32768 (i.e., with the high-order
bit equal to 1) are iether nor supported by the implementation or
parsed and found to be in error.
3. The name of the TLV used in the Echo Reply message is "TLV not The Value field contains the TLVs, including sub-TLVs, that were
understood", however it applies equally to sub-TLVs. If a sub- not understood, encoded as sub-TLVs.
TLV is not understood or supported, the entire TLV that includes
the sub-TLV is returned.
4.2. Text changes to RFC 8611 4.2. Text Changes to RFC 8611
RFC 8611 defines a sub-TLV registry - "Sub-TLVs for TLV Type 6". The The "Sub-TLVs for TLV Type 6" registry is now updated to align with
allocation policies for this registry is described in Section 3 of changes defined in this document.
this document. The "Sub-TLVs for TLV Type 6" registry is now updated
to align with changes defined in this document.
The registration procedurs for the "Sub-TLVs for TLV Type 6" registry The registration procedures for the "Sub-TLVs for TLV Type 6"
will now be like this: registry will now be like this:
+-------------+-------------------+---------------------------------+ +-------------+-------------------+---------------------------------+
| Range | Registration | Note | | Range | Registration | Note |
| | Procedures | | | | Procedures | |
+-------------+-------------------+---------------------------------+ +-------------+-------------------+---------------------------------+
| 0-16383 | Standards Action | This range is for sub-TLVs that | | 0-16383 | Standards Action | This range is for sub-TLVs that |
| | | require an error message if not | | | | require an error message if not |
| | | recognized. | | | | recognized. |
| 16384-31743 | RFC Required | This range is for sub-TLVs that | | 16384-31743 | RFC Required | This range is for sub-TLVs that |
| | | require an error message if not | | | | require an error message if not |
skipping to change at page 9, line 27 skipping to change at page 8, line 5
| | | can be silently dropped if not | | | | can be silently dropped if not |
| | | recognized. | | | | recognized. |
| 49162-64511 | RFC Required | This range is for sub-TLVs that | | 49162-64511 | RFC Required | This range is for sub-TLVs that |
| | | can be silently dropped if not | | | | can be silently dropped if not |
| | | recognized. | | | | recognized. |
| 64512-65535 | Private Use | Not to be assigned | | 64512-65535 | Private Use | Not to be assigned |
+-------------+-------------------+---------------------------------+ +-------------+-------------------+---------------------------------+
Sub-TLVs for TLV Type 6 Registration Procedures Sub-TLVs for TLV Type 6 Registration Procedures
4.2.1. Comments to this changes to RFC 8611
While it is true that the same rules apply to sub-TLVs and TLVs when
it comes tu return am error message if a TLV or sub-TLV is not
recognized. In the case if the registry for "Sub-TLVs for TLV Type 6
Registration Procedures" ir only includes sub-TLVs.
The changes described in this section aligns RFC 8611 with the
changes/updates described in the rest of this document.
5. Security Considerations 5. Security Considerations
This document only updates IANA registries, not how the code-points This document updates IANA registries, some terminology used to
in the registries are used. This should not create any new threats. define, and clarifies the terminology related to the code points in
the registries. The document does not change how the code-points in
the registries are used. This should not create any new threats.
However, the updated terminology and the clarifications improve
security because it makes it more likely that implementations will be
consistent and harder to attack.
6. IANA Considerations 6. IANA Considerations
IANA is requested to update the LSP Ping name space as described in IANA is requested to update the LSP Ping name space as described in
this document and documented in the Appendixies. this document.
6.1. New Message Type, Reply Mode and Return Codes registries 6.1. Updates of Message Type, Reply Mode and Return Codes Registries
This section details the updated registration procedures for Message This section details the updated registration procedures and
Type, Reply Mode and Return Codes registries. allocations for: Message Type, Reply Mode and Return Codes
registries.
+---------+--------------------+------------------------------------+ +---------+--------------------+------------------------------------+
| Range | Registration | Note | | Range | Registration | Note |
| | Procedures | | | | Procedures | |
+---------+--------------------+------------------------------------+ +---------+--------------------+------------------------------------+
| 0-191 | Standards Action | | | 0-191 | Standards Action | |
| 192-247 | RFC Required | | | 192-247 | RFC Required | |
| 248-251 | Experimental Use | Not to be assigned | | 248-251 | Experimental Use | Not to be assigned |
| 252-255 | Private Use | Not to be assigned | | 252-255 | Private Use | Not to be assigned |
+---------+--------------------+------------------------------------+ +---------+--------------------+------------------------------------+
skipping to change at page 11, line 29 skipping to change at page 9, line 46
| | | recognized. | | | | recognized. |
| 49162-64511 | RFC Required | This range is for TLVs that can | | 49162-64511 | RFC Required | This range is for TLVs that can |
| | | be silently dropped if not | | | | be silently dropped if not |
| | | recognized. | | | | recognized. |
| 64512-64515 | Experimental Use | Not to be assigned | | 64512-64515 | Experimental Use | Not to be assigned |
| 64515-65535 | Private Use | Not to be assigned | | 64515-65535 | Private Use | Not to be assigned |
+-------------+-------------------+---------------------------------+ +-------------+-------------------+---------------------------------+
TLV and sub-TLV Registration Procedures TLV and sub-TLV Registration Procedures
6.3. IANA assignments for TLVs and sub-TLVs 6.3. IANA Assignments for TLVs and sub-TLVs
The two tables in this section describes the updated IANA assignments The two tables in this section describes the updated IANA assignments
for the TLV and sub-TLV registries. The registry for sub-TLV 9 for the TLV and sub-TLV registries. The registry for sub-TLV 9
([IANA-Sub-9] is not changed. ([IANA-Sub-9] is not changed.
+-------------+-------------------+------------------+--------------+ +-------------+-------------------+------------------+--------------+
| Type | TLV name | Reference | sub-TLV | | Type | TLV name | Reference | sub-TLV |
| | | | registry | | | | | registry |
+-------------+-------------------+------------------+--------------+ +-------------+-------------------+------------------+--------------+
| 0 | Reserved | This document | | | 0 | Reserved | This document | |
 End of changes. 43 change blocks. 
165 lines changed or deleted 108 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/