Subject: [Idr] [IANA #814076] REVISED Last Call: <draft-ietf-idr-ls-distribution-10.txt> (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard

From: "Amanda Baber via RT" <[email-masked]>
Date: Tue, 07 Apr 2015 23:14:30 +0000

(BEGIN IANA LAST CALL COMMENTS)

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-idr-ls-distribution-10.  Please report any inaccuracies and respond to the questions below as soon as possible. IANA also requests two edits to the document's IANA Considerations section. 

IANA understands that, upon approval of this document, there are eight actions which IANA is required to complete.

First, IANA will update the reference for the following Address Family Number registration at https://www.iana.org/assignments/address-family-numbers:

16388	BGP-LS	[RFC-to-be]	2013-03-20 

REQUESTED EDIT: Section 5 says, "This document requests a code point from the registry of Address Family Numbers.  As per early allocation procedure this is AFI 16388." However, the term "early allocation" doesn't fit here. The "early allocation" procedure is a procedure defined by RFC 7120 that allows for a one-year temporary registration. 16388 was registered before this document was approved, but it's a permanent registration made in accordance with the registry's normal first-come, first-served procedure. 

Can you change this paragraph to "This document has registered Address Family Number 16388, BGP-LS" or "This document is the reference for Address Family Number 16388, BGP-LS," or something along those lines?

Second, IANA will update the reference for the following SAFI Value registration at https://www.iana.org/assignments/safi-namespace:

71	BGP-LS	[RFC-to-be]

REQUESTED EDIT: As above, this registration was not an early allocation, as defined by RFC 7120. (An example of an early allocation is BGP Path Attribute BGP-LS Attribute, which has an expiration date listed in the registry.) Please change "This document requests a code point from the registry of Subsequent Address Family Numbers named 'BGP-LS'.  As per early allocation procedure this is SAFI 71" to remove the reference to early allocation. 

Third, also in the Subsequent Address Family Identifiers (SAFI) Parameters registry at

https://www.iana.org/assignments/safi-namespace/

a new SAFI value will be registered as follows:

Value: [ RFC-to-be ]
Description: BGP-LS-VPN
Reference: [ RFC-to-be ]

QUESTION: The document notes that the value doesn't have to come from the 1-63 range, but doesn't specify which range to use. Does the registration belong in the 64-127 "First Come First Served" range, or in the 128-240 range marked "Some recognized assignments below, others Reserved"?

Fourth, the early allocation made by this document in the BGP Path Attributes registry at 

https://www.iana.org/assignments/bgp-parameters/

will be made permanent. Value 29 will have its reference changed to [ RFC-to-be ].

Fifth, a new registry called the BGP-LS NLRI-Types registry will be created in the Border Gateway Protocol - Link State (BGP-LS) Parameters top-level registry at

http://www.iana.org/assignments/bgp-ls-parameters/

The registry will be maintained via Specification Required as defined by RFC 5226. 

Initial registrations:

+------+---------------------------+---------------+
| Type | NLRI Type | Reference |
+------+---------------------------+---------------+
| 0 | Reserved | [ RFC-to-be ] |
| 1 | Node NLRI | [ RFC-to-be ] |
| 2 | Link NLRI | [ RFC-to-be ] |
| 3 | IPv4 Topology Prefix NLRI | [ RFC-to-be ] |
| 4 | IPv6 Topology Prefix NLRI | [ RFC-to-be ] |
| 5-65535 | Unassigned
+------+---------------------------+---------------+

Sixth, a new registry called the BGP-LS Protocol-IDs registry will be created under the Border Gateway Protocol - Link State (BGP-LS) Parameters heading at

http://www.iana.org/assignments/bgp-ls-parameters/

The registry will be maintained via Specification Required as defined by RFC 5226. 

Initial registrations:

+-------------+----------------------------------+---------------+
| Protocol-ID | NLRI information source protocol | Reference |
+-------------+----------------------------------+---------------+
| 0 | Reserved | [ RFC-to-be ] |
| 1 | IS-IS Level 1 | [ RFC-to-be ] |
| 2 | IS-IS Level 2 | [ RFC-to-be ] |
| 3 | OSPFv2 | [ RFC-to-be ] |
| 4 | Direct | [ RFC-to-be ] |
| 5 | Static configuration | [ RFC-to-be ] |
| 6 | OSPFv3 | [ RFC-to-be ] |
| 7-255 | Unassigned
+-------------+----------------------------------+---------------+

Seventh, a new registry called the BGP-LS Well-known Instance-IDs registry will be created under the Border Gateway Protocol - Link State (BGP-LS) Parameters top-level  heading at

http://www.iana.org/assignments/bgp-ls-parameters/

The registry will be maintained via Specification Required as defined by RFC 5226. 

Initial registrations:

+------------+----------------------------------+---------------+
| Identifier | Routing Universe | Reference: |
+------------+----------------------------------+---------------+
| 0 | Default Layer 3 Routing topology | [ RFC-to-be ] |
| 1-31 | Reserved | [ RFC-to-be ] |
+------------+----------------------------------+---------------+

Eighth, a new registry called the Node Anchor, Link Descriptor and Link Attribute TLVs registry will be created under the Border Gateway Protocol - Link State (BGP-LS) Parameters heading at

http://www.iana.org/assignments/bgp-ls-parameters/

The registry will be maintained via Specification Required as defined by RFC 5226. 

Initial registrations: 

+-----------+---------------------+---------------+-----------------+
| TLV Code Point | Description | IS-IS TLV/Sub-TLC | Reference |
+-----------+---------------------+---------------+-----------------+
| 0-255 | Reserved |[RFC-to-be ] 
| 256 | Local Node Descriptors | --- | Section 3.2.1.2 |
| 257 | Remote Node Descriptors | --- | Section 3.2.1.3 |
| 258 | Link Local/Remote Identifiers | 22/4 | [RFC5307]/1.1 |
| 259 | IPv4 interface address | 22/6 | [RFC5305]/3.2 |
| 260 | IPv4 neighbor address | 22/8 | [RFC5305]/3.3 |
| 261 | IPv6 interface address | 22/12 | [RFC6119]/4.2 |
| 262 | IPv6 neighbor address | 22/13 | [RFC6119]/4.3 |
| 263 | Multi-Topology ID | --- | Section 3.2.1.5 |
| 264 | OSPF Route Type | --- | Section 3.2.3 |
| 265 | IP Reachability Information | --- | Section 3.2.3 |
| 266-511 | Unassigned
| 512 | Autonomous System | --- | Section 3.2.1.4 |
| 513 | BGP-LS Identifier | --- | Section 3.2.1.4 |
| 514 | OSPF Area ID | --- | Section 3.2.1.4 |
| 515 | IGP Router-ID | --- | Section 3.2.1.4 |
| 516-1023 | Unassigned
| 1024 | Node Flag Bits | --- | Section 3.3.1.1 |
| 1025 | Opaque Node Properties | --- | Section 3.3.1.5 |
| 1026 | Node Name | variable | Section 3.3.1.3 |
| 1027 | IS-IS Area Identifier | variable | Section 3.3.1.2 |
| 1028 | IPv4 Router-ID of Local Node | 134/--- | [RFC5305]/4.3 |
| 1029 | IPv6 Router-ID of Local Node | 140/--- | [RFC6119]/4.1 |
| 1030 | IPv4 Router-ID of Remote Node | 134/--- | [RFC5305]/4.3 |
| 1031 | IPv6 Router-ID of Remote Node | 140/--- | [RFC6119]/4.1 |
| 1032-1087 | Unassigned
| 1088 | Administrative group (color) | 22/3 | [RFC5305]/3.1 |
| 1089 | Maximum link bandwidth | 22/9 | [RFC5305]/3.3 |
| 1090 | Max. reservable link bandwidth | 22/10 | [RFC5305]/3.5 |
| 1091 | Unreserved bandwidth | 22/11 | [RFC5305]/3.6 |
| 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 |
| 1093 | Link Protection Type | 22/20 | [RFC5307]/1.2 |
| 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 |
| 1095 | IGP Metric | --- | Section 3.3.2.4 |
| 1096 | Shared Risk Link Group | --- | Section 3.3.2.5 |
| 1097 | Opaque link attribute | --- | Section 3.3.2.6 |
| 1098 | Link Name attribute | --- | Section 3.3.2.7 |
| 1099-1151 | Unassigned
| 1152 | IGP Flags | --- | Section 3.3.3.1 |
| 1153 | Route Tag | --- | [RFC5130] |
| 1154 | Extended Tag | --- | [RFC5130] |
| 1155 | Prefix Metric | --- | [RFC5305] |
| 1156 | OSPF Forwarding Address | --- | [RFC2328] |
| 1157 | Opaque Prefix Attribute | --- | Section 3.3.3.6 |
| 1158-65535 | Unassigned
+-----------+---------------------+---------------+-----------------+

IANA understands that these eight actions are the only ones required upon completion. 

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.   

Thanks,

Amanda Baber
IANA Request Specialist
ICANN

(END IANA LAST CALL COMMENTS)

On Wed Mar 18 19:41:12 2015, [email-masked] wrote:
> 
> The IESG has received a request from the Inter-Domain Routing WG (idr) to
> consider the following document:
> - 'North-Bound Distribution of Link-State and TE Information using BGP'
>   <draft-ietf-idr-ls-distribution-10.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2015-04-08. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    In 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 information.  This is information typically
>    distributed by IGP routing protocols within the network.
> 
>    This document describes a mechanism by which links state and traffic
>    engineering 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).
> 
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ballot/
> 
> 
> The following IPR Declarations may be related to this I-D:
> 
>    http://datatracker.ietf.org/ipr/1864/
> 
> 
>

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Sat, 11 Apr 2015 07:26:22 +0000

Sue, Jie,

Is the shepherd included in the "[email-masked]" alias?

Before I send a note asking the authors to confirm the third and sixth actions, a quick note about this one: 

> On actions 1 and 2: First comment, this did go through the early
> allocation procedure, and then into the extension to permanent
> approval.   However, I have no objection to changing the language to
> fit the best text for IANA for the AFI/SAFI below.
 
The RFC 7120 use of the term "early allocation" refers only to temporary assignments made in ranges that don't allow for permanent assignment before approval. It's the RFC 7120 use that we're trying to reserve the term for. Because the authors requested assignment in the registries' First Come, First Served ranges rather than Standards Action ranges, the early allocation process turned out to be unnecessary in those two cases. 

thanks,
Amanda