--- 1/draft-ietf-lsr-isis-area-proxy-01.txt 2020-07-25 19:13:29.374283974 -0700 +++ 2/draft-ietf-lsr-isis-area-proxy-02.txt 2020-07-25 19:13:29.418285098 -0700 @@ -1,21 +1,21 @@ Internet Engineering Task Force T. Li Internet-Draft S. Chen Intended status: Experimental V. Ilangovan -Expires: January 8, 2021 Arista Networks +Expires: January 26, 2021 Arista Networks G. Mishra Verizon Inc. - July 7, 2020 + July 25, 2020 Area Proxy for IS-IS - draft-ietf-lsr-isis-area-proxy-01 + draft-ietf-lsr-isis-area-proxy-02 Abstract Link state routing protocols have hierarchical abstraction already built into them. However, when lower levels are used for transit, they must expose their internal topologies to each other, leading to scale issues. To avoid this, this document discusses extensions to the IS-IS routing protocol that would allow level 1 areas to provide transit, @@ -31,21 +31,21 @@ 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 https://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 January 8, 2021. + This Internet-Draft will expire on January 26, 2021. Copyright Notice Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -62,48 +62,48 @@ 2. Area Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Segment Routing . . . . . . . . . . . . . . . . . . . . . 6 3. Inside Router Functions . . . . . . . . . . . . . . . . . . . 6 3.1. The Area Proxy TLV . . . . . . . . . . . . . . . . . . . 6 3.2. Level 2 SPF Computation . . . . . . . . . . . . . . . . . 7 4. Area Leader Functions . . . . . . . . . . . . . . . . . . . . 8 4.1. Area Leader Election . . . . . . . . . . . . . . . . . . 8 4.2. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Distributing Area Proxy Information . . . . . . . . . . . 8 4.3.1. The Area Proxy System Id Sub-TLV . . . . . . . . . . 8 - 4.3.2. The Area Segment SID Sub-TLV . . . . . . . . . . . . 9 + 4.3.2. The Area SID Sub-TLV . . . . . . . . . . . . . . . . 9 4.3.2.1. Flags . . . . . . . . . . . . . . . . . . . . . . 10 - 4.4. Area Proxy LSP Generation . . . . . . . . . . . . . . . . 10 + 4.4. Proxy LSP Generation . . . . . . . . . . . . . . . . . . 10 4.4.1. The Protocols Supported TLV . . . . . . . . . . . . . 10 4.4.2. The Area Address TLV . . . . . . . . . . . . . . . . 11 4.4.3. The Dynamic Hostname TLV . . . . . . . . . . . . . . 11 4.4.4. The IS Neighbors TLV . . . . . . . . . . . . . . . . 11 4.4.5. The Extended IS Neighbors TLV . . . . . . . . . . . . 11 4.4.6. The MT Intermediate Systems TLV . . . . . . . . . . . 12 4.4.7. Reachability TLVs . . . . . . . . . . . . . . . . . . 12 4.4.8. The Router Capability TLV . . . . . . . . . . . . . . 13 4.4.9. The Multi-Topology TLV . . . . . . . . . . . . . . . 13 4.4.10. The SID/Label Binding and The Multi-Topology SID/Label Binding SID TLV . . . . . . . . . . . . . . 13 4.4.11. The SRv6 Locator TLV . . . . . . . . . . . . . . . . 13 4.4.12. Traffic Engineering Information . . . . . . . . . . . 14 - 4.4.13. The Area Segment SID . . . . . . . . . . . . . . . . 14 - 5. Inside Edge Router Functions . . . . . . . . . . . . . . . . 14 - 5.1. Generating L2 IIHs to Outside Routers . . . . . . . . . . 14 + 4.4.13. The Area SID . . . . . . . . . . . . . . . . . . . . 14 + 5. Inside Edge Router Functions . . . . . . . . . . . . . . . . 15 + 5.1. Generating L2 IIHs to Outside Routers . . . . . . . . . . 15 5.2. Filtering LSP information . . . . . . . . . . . . . . . . 15 - 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 - 9.2. Informative References . . . . . . . . . . . . . . . . . 18 - 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 + 9.2. Informative References . . . . . . . . . . . . . . . . . 19 + 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction The IS-IS routing protocol IS-IS [ISO10589] currently supports a two- level hierarchy of abstraction. The fundamental unit of abstraction is the 'area', which is a (hopefully) connected set of systems running IS-IS at the same level. Level 1, the lowest level, is abstracted by routers that participate in both Level 1 and Level 2, and they inject area information into Level 2. Level 2 systems seeking to access Level 1, use this abstraction to compute the @@ -170,23 +170,23 @@ topology, Level 2's requirement for connectivity can be satisfied without the full overhead of the area's internal topology. It then becomes the responsibility of the Level 1 area to ensure the forwarding connectivity that's advertised. For this discussion, we'll consider a single Level 1 IS-IS area to be the Inside Area, and the remainder of the Level 2 area is the Outside Area. All routers within the Inside Area speak Level 1 and Level 2 IS-IS on all of the links within the topology. We propose to implement Area Proxy by having a Level 2 Proxy Link State Protocol - Data Unit (PDU, LSP) that represents the entire Inside Area. This is - the only LSP from the area that will be flooded into the overall - Level 2 LSDB. + Data Unit (PDU, LSP) that represents the entire Inside Area. We will + refer to this as the Proxy LSP. This is the only LSP from the area + that will be flooded into the overall Level 2 LSDB. There are four classes of routers that we need to be concerned with in this discussion: Inside Router A router within the Inside Area that runs Level 1 and Level 2 IS-IS. A router is recognized as an Inside Router by the existence of its LSP in the Level 1 LSDB. Area Leader The Area Leader is an Inside Router that is elected to represent the Level 1 area by injecting the Proxy LSP into the @@ -251,30 +251,30 @@ value of the SRGB advertised by all Inside Nodes MUST start at the same value. The range advertised for the area will be the minimum of all Inside Nodes. To support Segment Routing, the Area Leader will take the global SID information found in the L1 LSDB and convey that to L2 through the Proxy LSP. Prefixes with SID assignments will be copied to the Proxy LSP. Adjacency SIDs for Outside Edge Nodes will be copied to the Proxy LSP. - To further extend Segment Routing, it would be helpful to have a SID - that refers to the entire Inside Area. This allows a path to refer - to an area and have any node within that area accept and forward the - packet. In effect, this becomes an anycast SID that is accepted by - all Inside Edge Nodes. The information about this SID is distributed - in the Area Segment SID Sub-TLV, as part of the Area Leader's Area - Proxy TLV (Section 4.3.2). The Inside Edge Nodes MUST establish + To further extend Segment Routing, it would be helpful to have a + segment that refers to the entire Inside Area. This allows a path to + refer to an area and have any node within that area accept and + forward the packet. In effect, this becomes an anycast SID that is + accepted by all Inside Edge Nodes. The information about this SID is + distributed in the Area SID Sub-TLV, as part of the Area Leader's + Area Proxy TLV (Section 4.3.2). The Inside Edge Nodes MUST establish forwarding based on this SID. The Area Leader SHALL also include the - Area Segment SID in the Area Proxy LSP so that the remainder of L2 - can use it for path construction. (Section 4.4.13). + Area SID in the Proxy LSP so that the remainder of L2 can use it for + path construction. (Section 4.4.13). 3. Inside Router Functions All Inside Routers run Level 1-2 IS-IS and must be explicitly instructed to enable the Area Proxy functionality. To signal their readiness to participate in Area Proxy functionality, they will advertise the Area Proxy TLV. 3.1. The Area Proxy TLV @@ -282,42 +282,43 @@ The presence of the Area Proxy TLV in a node's LSP indicates that the node is enabled for Area Proxy. An LSP containing the Area Proxy TLV is also an Inside Node. All Inside Nodes, including pseudonodes, MUST advertise the Area Proxy TLV. It is a container for sub-TLVs with Area Proxy information. - A node advertises the Area Proxy TLV in its L2 LSP. The format of - the Area Proxy TLV is: + A node advertises the Area Proxy TLV in its L2 LSP. The Area Proxy + TLV is not used in the Proxy LSP. The format of the Area Proxy TLV + is: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | TLV Length | Sub-TLVs ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type: YYY TLV Length: length of the sub-TLVs 3.2. Level 2 SPF Computation When Outside Routers perform a Level 2 SPF computation, they will use - the Area Proxy LSP for computing a path transiting the Inside Area. + the Proxy LSP for computing a path transiting the Inside Area. Because the topology has been abstracted away, the cost for transiting the Inside Area will be zero. When Inside Routers perform a Level 2 SPF computation, they MUST - ignore the Area Proxy LSP. Further, because these systems do see the + ignore the Proxy LSP. Further, because these systems do see the Inside Area topology, the link metrics internal to the area are visible. This could lead to different and possibly inconsistent SPF results, potentially leading to forwarding loops. To prevent this, the Inside Routers MUST consider the metrics of links outside of the Inside Area (inter-area metrics) separately from the metrics of the Inside Area links (intra-area metrics). Intra- area metrics MUST be treated as less than any inter-area metric. Thus, if two paths have different total inter-area metrics, the path with the lower inter-area metric would be preferred, regardless of @@ -337,34 +338,34 @@ 4.1. Area Leader Election The Area Leader is selected using the election mechanisms and TLVs described in Dynamic Flooding for IS-IS [I-D.ietf-lsr-dynamic-flooding]. 4.2. Redundancy If the Area Leader fails, another candidate may become Area Leader - and MUST regenerate the Area Proxy LSP. The failure of the Area - Leader is not visible outside of the area and appears to simply be an - update of the Area Proxy LSP. + and MUST regenerate the Proxy LSP. The failure of the Area Leader is + not visible outside of the area and appears to simply be an update of + the Proxy LSP. For consistency, all Area Leader candidates SHOULD be configured with the same Proxy System Id, Proxy Hostname, and any other information that may be inserted into the Proxy LSP. 4.3. Distributing Area Proxy Information The Area Leader is responsible for distributing information about the area to all Inside Nodes. In particular, the Area Leader distributes - the Proxy System Id and the Area Segment SID. This is done using two - sub-TLVs of the Area Proxy TLV. + the Proxy System Id and the Area SID. This is done using two sub- + TLVs of the Area Proxy TLV. 4.3.1. The Area Proxy System Id Sub-TLV The Area Proxy System Id Sub-TLV MUST be used by the Area Leader to distribute the Area Proxy System Id. This is an additional system identifier that is used by Inside Nodes and an indication that Area Proxy is active. The format of this sub-TLV is: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 @@ -395,27 +396,26 @@ be logged. The Area Leader and other candidates for Area Leader MAY withdraw the Area Proxy System Identifier when one or more Inside Routers are not advertising the Area Proxy Router Capability. This will disable Area Proxy functionality. However, before withdrawing the Area Proxy System Identifier, an implementation SHOULD protect against unnecessary churn from transients by delaying the withdrawal. The amount of delay is implementation-dependent. -4.3.2. The Area Segment SID Sub-TLV +4.3.2. The Area SID Sub-TLV - The Area Segment SID Sub-TLV allows the Area Leader to advertise a - SID that represents the entirety of the Inside Area to the Outside - Area. This sub-TLV is learned by all of the Inside Edge Nodes who - should consume this SID at forwarding time. The Area Segment SID - Sub-TLV has the format: + The Area SID Sub-TLV allows the Area Leader to advertise a SID that + represents the entirety of the Inside Area to the Outside Area. This + sub-TLV is learned by all of the Inside Edge Nodes who should consume + this SID at forwarding time. The Area SID Sub-TLV has the format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Index/Label (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: @@ -444,72 +444,72 @@ proxy SID is used when forwarding IPv6-encapsulated traffic. V: Value Flag. If set, then the proxy SID carries a value. L: Local Flag. If set, then the value/index carried by the proxy SID has local significance. Other bits: MUST be zero when originated and ignored when received. -4.4. Area Proxy LSP Generation +4.4. Proxy LSP Generation Each Inside Router generates a Level 2 LSP, and the Level 2 LSPs for the Inside Edge Routers will include adjacencies to Outside Edge Routers. Unlike normal Level 2 operations, these LSPs are not advertised outside of the Inside Area and MUST be filtered by all Inside Edge Routers to not be flooded to Outside Routers. Only the - Area Proxy LSP is injected into the overall Level 2 LSDB. + Proxy LSP is injected into the overall Level 2 LSDB. The Area Leader uses the Level 2 LSPs generated by the Inside Edge - Routers to generate the Area Proxy LSP. This LSP is originated using - the Area Proxy System Identifier. The Area Leader MAY also insert - the following additional TLVs into the Area Proxy LSP for additional + Routers to generate the Proxy LSP. This LSP is originated using the + Area Proxy System Identifier. The Area Leader MAY also insert the + following additional TLVs into the Proxy LSP for additional information for the Outside Area. LSPs generated by unreachable nodes MUST NOT be considered. 4.4.1. The Protocols Supported TLV The Area Leader SHOULD insert a Protocols Supported TLV (129) - [RFC1195] into the Area Proxy LSP. The values included in the TLV - SHOULD be the protocols supported by the Inside Area. + [RFC1195] into the Proxy LSP. The values included in the TLV SHOULD + be the protocols supported by the Inside Area. 4.4.2. The Area Address TLV The Area Leader SHOULD insert an Area Addresses TLV (1) [ISO10589] - into the Area Proxy LSP. + into the Proxy LSP. 4.4.3. The Dynamic Hostname TLV It is RECOMMENDED that the Area Leader insert the Dynamic Hostname - TLV (137) [RFC5301] into the Area Proxy LSP. The contents of the - hostname may be specified by configuration. The presence of the - hostname helps to simplify debugging the network. + TLV (137) [RFC5301] into the Proxy LSP. The contents of the hostname + may be specified by configuration. The presence of the hostname + helps to simplify debugging the network. 4.4.4. The IS Neighbors TLV The Area Leader MAY insert the IS Neighbors TLV (2) [ISO10589] into - the Area Proxy LSP for Outside Edge Routers. The Area Leader learns - of the Outside Edge Routers by examining the LSPs generated by the + the Proxy LSP for Outside Edge Routers. The Area Leader learns of + the Outside Edge Routers by examining the LSPs generated by the Inside Edge Routers copying any IS Neighbors TLVs referring to Outside Edge Routers into the Proxy LSP. Since the Outside Edge Routers advertise an adjacency to the Area Proxy System Identifier, this will result in a bi-directional adjacency. An entry for a neighbor in both the IS Neighbors TLV and the Extended IS Neighbors would be functionally redundant, so the Area Leader SHOULD NOT do this. 4.4.5. The Extended IS Neighbors TLV The Area Leader MAY insert the Extended IS Reachability TLV (22) - [RFC5305] into the Area Proxy LSP. The Area Leader SHOULD copy each + [RFC5305] into the Proxy LSP. The Area Leader SHOULD copy each Extended IS Reachability TLV advertised by an Inside Edge Router about an Outside Edge Router into the Proxy LSP. If the Inside Area supports Segment Routing and Segment Routing selects a SID where the L-Flag is unset, then the Area Lead SHOULD include an Adjacency Segment Identifier sub-TLV (31) [RFC8667] using the selected SID. If the inside area supports SRv6, the Area Leader SHOULD copy the "SRv6 End.X SID" and "SRv6 LAN End.X SID" sub-TLVs of the extended IS @@ -542,41 +542,41 @@ Extended IP Reachability TLV (135) [RFC5305] IPv6 Reachability TLV (236) [RFC5308] Multi-Topology Reachable IPv4 Prefixes TLV (235) [RFC5120] Multi-Topology Reachable IPv6 Prefixes TLV (237) [RFC5120] For TLVs in the Level 1 LSDB, for a given TLV type and prefix, the Area Leader SHOULD select the TLV with the lowest metric and copy - that TLV into the Area Proxy LSP. + that TLV into the Proxy LSP. When examining the Level 2 LSDB for this function, the Area Leader SHOULD only consider TLVs advertised by Inside Routers. Further, for prefixes that represent Boundary links, the Area Leader SHOULD copy all TLVs that have unique sub-TLV contents. If the Inside Area supports Segment Routing and the selected TLV includes a Prefix Segment Identifier sub-TLV (3) [RFC8667], then the sub-TLV SHOULD be copied as well. The P-Flag SHOULD be set in the copy of the sub-TLV to indicate that penultimate hop popping SHOULD NOT be performed for this prefix. The E-Flag SHOULD be reset in the copy of the sub-TLV to indicate that an explicit NULL is not required. The R-Flag SHOULD simply be copied. 4.4.8. The Router Capability TLV The Area Leader MAY insert the Router Capability TLV (242) [RFC7981] - into the Area Proxy LSP. If Segment Routing is supported by the - inside area, as indicated by the presence of an SRGB being advertised - by all Inside Nodes, then the Area Leader SHOULD advertise an SR- + into the Proxy LSP. If Segment Routing is supported by the inside + area, as indicated by the presence of an SRGB being advertised by all + Inside Nodes, then the Area Leader SHOULD advertise an SR- Capabilities sub-TLV (2) [RFC8667] with an SRGB. The first value of the SRGB is the same value as the first value advertised by all Inside Nodes. The range advertised for the area will be the minimum of all ranges advertised by Inside Nodes. The Area Leader SHOULD use its own Router Id in the Router Capability TLV. If SRv6 Capability sub-TLV [RFC7981] is advertised by all Inside Routers, the Area Leader should insert an SRv6 Capability sub-TLV in the Router Capability TLV. Each flag in the SRv6 Capability sub-TLV should be set if the flag is set by all Inside Routers. @@ -595,53 +595,87 @@ topology, then the Area Leader MUST advertise the 'O' bit for that topology. If any Inside Node is advertising the 'A' (Attach) bit for a given topology, then the Area Leader MUST advertise the 'A' bit for that topology. 4.4.10. The SID/Label Binding and The Multi-Topology SID/Label Binding SID TLV If an Inside Node advertises the SID/Label Binding or Multi-Topology SID/Label Binding SID TLV [RFC8667], then the Area Leader MAY copy - the TLV to the Area Proxy LSP. + the TLV to the Proxy LSP. 4.4.11. The SRv6 Locator TLV If the inside area supports SRv6, the Area Leader SHOULD copy all SRv6 locator TLVs [I-D.ietf-lsr-isis-srv6-extensions] advertised by Inside Routers to the Proxy LSP. 4.4.12. Traffic Engineering Information If the inside area supports TE, the Area Leader SHOULD advertise a TE Router ID TLV (134) [RFC5305] in the Proxy LSP. It SHOULD copy the Shared Risk Link Group (SRLS) TLVs (138) [RFC5307] advertised by Inside Edge Routers about links to Outside Edge Routers. If the inside area supports IPv6 TE, the Area Leader SHOULD advertise an IPv6 TE Router ID TLV (140) [RFC6119] in the Proxy LSP. It SHOULD also copy the IPv6 SRLG TLVs (139) [RFC6119] advertised by Inside Edge Routers about links to Outside Edge Routers. -4.4.13. The Area Segment SID +4.4.13. The Area SID - If the Area Leader is advertising an Area Segment SID in the Area - Segment SID sub-TLV of the Area Proxy TLV, then the Area Leader - SHOULD advertise the Area Segment SID in the Proxy LSP. The - advertisement in the Proxy LSP informs the remainder of the network - that packets directed to the SID will be forwarded by one of the - Inside Edge Nodes and the Area Segment SID will be consumed. + When SR is enabled, it may be useful to advertise an Area SID which + will direct traffic to any of the Inside Edge Routers. The Binding/ + MT Binding TLVs described in RFC 8667 Section 2.4 are used to + advertise such a SID. - Area Segment SIDs are advertised using the SID/Label Binding TLV - [RFC8667], Section 2.4 or the Multi-Topology SID/Label Binding TLV, - section 2.5. The Area Segment SID Sub-TLV (Section 4.3.2) is used in - either TLV to convey the SID. + The following extensions to the Binding TLV are defined in order to + support Area SID: + + A new flag is defined: + + T-flag: The SID directs traffic to an area. (Bit 5) + + When T-flag is set: + + M and A flag MUST be clear + + Range and Prefix are ignored + + Section 2.4.4 of RFC 8667 is altered to say: + + "The Prefix-SID sub-TLV MUST be present in the SID/Label + Binding TLV when the M-Flag and T-flag are both clear. The + Prefix-SID sub-TLV MUST NOT be present when either the M-Flag + or T-flag are set." + + Regarding the SID/Label sub-TLV Section 2.4.5 of RFC 8667 is + altered to say: + + "It MUST be present in the SID/Label Binding TLV when either + the M-Flag or T-flag is set in the Flags field of the parent + TLV." + + When used in support of Area Proxy, the SID advertised MUST be + identical to the Area SID (Section 4.3.2). Other uses of the Area + SID are outside the scope of this document. Documents which define + other use cases for the Area SID MUST specify whether the SID value + should be the same or different from that used in support of Area + Proxy. + + If the Area Leader is advertising an Area SID in the Area SID sub-TLV + of the Area Proxy TLV, then the Area Leader SHOULD advertise the Area + SID in the Proxy LSP. The advertisement in the Proxy LSP informs the + remainder of the network that packets directed to the SID will be + forwarded by one of the Inside Edge Nodes and the Area SID will be + consumed. 5. Inside Edge Router Functions The Inside Edge Router has two additional and important functions. First, it MUST generate IIHs that appear to have come from the Area Proxy System Identifier. Second, it MUST filter the L2 LSPs, Partial Sequence Number PDUs (PSNPs), and Complete Sequence Number PDUs (CSNPs) that are being advertised to Outside Routers. 5.1. Generating L2 IIHs to Outside Routers @@ -717,26 +752,25 @@ Size, format, and syntax of registry entries: Value (0-255), Name, and Reference Initial assignments and reservations: IANA is requested to assign the following code points: +-------+------------------------------+---------------+ | Value | Name | Reference | +-------+------------------------------+---------------+ | AAA | Area Proxy System Identifier | This document | - | BBB | Area Segment SID | This document | + | BBB | Area SID | This document | +-------+------------------------------+---------------+ This memo also requests that IANA allocate a code point (ZZZ) for the - Area Segment SID subTLV in the registry for Sub-TLVs for TLVs 149 and - 150. + Area SID subTLV in the registry for Sub-TLVs for TLVs 149 and 150. 8. Security Considerations This document introduces no new security issues. Security of routing within a domain is already addressed as part of the routing protocols themselves. This document proposes no changes to those security architectures. 9. References