Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters RegistriesOld Dog Consultingadrian@olddog.co.uk
Routing
IDRBGP-LSIANARFC 7752 defines the Border Gateway Protocol - Link State (BGP-LS). IANA created
a registry consistent with that document called "Border Gateway Protocol - Link
State (BGP-LS) Parameters" with a number of subregistries. The
allocation policy applied by IANA for those registries is "Specification Required",
as defined in RFC 8126.This document updates RFC 7752 by changing the allocation policy for all of
the registries to "Expert Review" and by updating the guidance to the designated
experts.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2021 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
() 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
. Introduction
. Requirements Language
. IANA Considerations
. Guidance for Designated Experts
. Security Considerations
. Normative References
Acknowledgements
Author's Address
Introduction"North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP" requested IANA to create
a registry called "Border Gateway Protocol - Link State (BGP-LS)
Parameters" with a number of subregistries. The allocation policy
applied by IANA for those registries is "Specification Required", as defined in
.The "Specification Required" policy requires evaluation of any assignment
request by a "designated expert", and guidelines for any such experts are
given in . In addition, this policy requires that "the
values and their meanings must be documented in a permanent and readily
available public specification, in sufficient detail so that
interoperability between independent implementations is possible" .
Further, the intention behind "permanent and readily available" is that "a
document can reasonably be expected to be findable and retrievable long after
IANA assignment of the requested value" .Another allocation policy called "Expert Review" is defined in .
This policy also requires Expert Review but has no requirement for a
formal document.All reviews by designated experts are guided by advice given in the
document that defined the registry and set the allocation policy.This document updates by changing the allocation policy for all of
the registries to "Expert Review" and updating the guidance to the
designated experts.Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
IANA ConsiderationsIANA maintains a registry called "Border Gateway Protocol - Link State (BGP-LS) Parameters".
This registry contains four subregistries:
BGP-LS NLRI-Types
BGP-LS Protocol-IDs
BGP-LS Well-Known Instance-IDs
BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs
IANA has changed the assignment policy for each of these registries to "Expert Review".IANA has also added this document as a reference for the registries mentioned above.Guidance for Designated Experts gives guidance to designated experts. This section replaces that guidance.In all cases of review by the designated expert described here,
the designated expert is expected to check the clarity of purpose and use of the
requested code points. The following points apply to the registries
discussed in this document:
Application for a code point allocation may be made to the
designated experts at any time and MUST be accompanied
by technical documentation explaining the use of the code
point. Such documentation SHOULD be presented in the
form of an Internet-Draft but MAY arrive in any form that
can be reviewed and exchanged amongst reviewers.
The designated experts SHOULD only consider requests that arise
from Internet-Drafts that have already been accepted as working group
documents or that are planned for progression as AD-Sponsored
documents in the absence of a suitably chartered working group.
In the case of working group documents, the designated experts
MUST check with the working group chairs that there is
consensus within the working group to make the allocation at this
time. In the case of AD-Sponsored documents, the designated
experts MUST check with the AD for approval to make the
allocation at this time.
If the document is not adopted by the IDR Working Group (or its
successor), the designated expert MUST notify the IDR mailing list
(or its successor) of the request and MUST provide access to the
document. The designated expert MUST allow two weeks for any response.
Any comments received MUST be considered by the designated expert
as part of the subsequent step.
The designated experts MUST then review the assignment requests
on their technical merit. The designated experts MAY raise
issues related to the allocation request with the
authors and on the IDR (or successor) mailing list
for further consideration before the assignments
are made.
The designated expert MUST ensure that any request for
a code point does not conflict with work that is active or already
published within the IETF.
Once the designated experts have granted approval, IANA will
update the registry by marking the allocated code points with a
reference to the associated document.
In the event that the document is a working group document or is
AD Sponsored, and that document fails to progress to publication
as an RFC, the working group chairs or AD SHOULD contact IANA
to coordinate about marking the code points as deprecated. A
deprecated code point is not marked as allocated for use and is not
available for allocation in a future document. The WG chairs may
inform IANA that a deprecated code point can be completely
deallocated (i.e., made available for new allocations) at any time
after it has been deprecated if there is a shortage of unallocated
code points in the registry.
Security ConsiderationsThe security considerations described in still apply.Note that the change to the Expert Review guidelines makes the registry and the designated experts slightly more
vulnerable to denial-of-service attacks through excessive and bogus requests for code points. It is expected that
the registry cannot be effectively attacked because the designated experts would, themselves, fall to any such
attack first. Designated experts are expected to report to the IDR Working Group chairs and responsible Area
Director if they believe an attack to be in progress and should immediately halt all requests for allocation.
This may temporarily block all legitimate requests until mitigations have been put in place.Normative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGPIn a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.AcknowledgementsThis work is based on the IANA Considerations described in . The author thanks the people who worked on that document.The author would like to thank for suggesting the need for this document.Thanks to , , , and for their review, comments, and discussion.Additional thanks to , , , , , ,
and for engaging in discussion on the details of this work.Author's AddressOld Dog Consultingadrian@olddog.co.uk