--- 1/draft-ietf-lsr-isis-area-proxy-00.txt 2020-07-07 09:13:54.888106429 -0700 +++ 2/draft-ietf-lsr-isis-area-proxy-01.txt 2020-07-07 09:13:54.932107547 -0700 @@ -1,21 +1,21 @@ Internet Engineering Task Force T. Li Internet-Draft S. Chen Intended status: Experimental V. Ilangovan -Expires: December 31, 2020 Arista Networks +Expires: January 8, 2021 Arista Networks G. Mishra Verizon Inc. - June 29, 2020 + July 7, 2020 Area Proxy for IS-IS - draft-ietf-lsr-isis-area-proxy-00 + draft-ietf-lsr-isis-area-proxy-01 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 December 31, 2020. + This Internet-Draft will expire on January 8, 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 @@ -53,58 +53,57 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Area Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Segment Routing . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. Segment Routing . . . . . . . . . . . . . . . . . . . . . 6 3. Inside Router Functions . . . . . . . . . . . . . . . . . . . 6 - 3.1. The Area Proxy Router Capability . . . . . . . . . . . . 6 - 3.2. Level 2 SPF Computation . . . . . . . . . . . . . . . . . 6 - 3.3. The Inside Node TLV . . . . . . . . . . . . . . . . . . . 7 - 4. Area Leader Functions . . . . . . . . . . . . . . . . . . . . 7 - 4.1. Area Leader Election . . . . . . . . . . . . . . . . . . 7 + 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. The Area Proxy TLV . . . . . . . . . . . . . . . . . . . 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.1. Flags . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Area Proxy LSP Generation . . . . . . . . . . . . . . . . 10 4.4.1. The Protocols Supported TLV . . . . . . . . . . . . . 10 - 4.4.2. The Area Address TLV . . . . . . . . . . . . . . . . 10 - 4.4.3. The Dynamic Hostname TLV . . . . . . . . . . . . . . 10 - 4.4.4. The IS Neighbors 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 . . . . . . . . . . . 11 - 4.4.7. Reachability TLVs . . . . . . . . . . . . . . . . . . 11 - 4.4.8. The Router Capability TLV . . . . . . . . . . . . . . 12 - 4.4.9. The Multi-Topology TLV . . . . . . . . . . . . . . . 12 + 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 Area Segment SID TLV . . . . . . . . . . . . . . 13 - 4.4.11.1. Flags . . . . . . . . . . . . . . . . . . . . . 14 - 4.4.12. The SRv6 Locator TLV . . . . . . . . . . . . . . . . 14 - 4.4.13. Traffic Engineering Information . . . . . . . . . . . 14 + 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 . . . . . . . . . . 15 + 5.1. Generating L2 IIHs to Outside Routers . . . . . . . . . . 14 5.2. Filtering LSP information . . . . . . . . . . . . . . . . 15 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 18 - 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 + 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 @@ -196,20 +195,40 @@ Inside Edge Router An Inside Edge Router is an Inside Area Router that has at least one Level 2 interface outside of the Inside Area. An interface on an Inside Edge Router that is connected to an Outside Edge Router is an Area Proxy Boundary. Outside Edge Router An Outside Edge Router is a Level 2 router that is outside of the Inside Area that has an adjacency with an Inside Edge Router. + Inside Area + + +--------+ +--------+ + | Inside |-----------------| Inside | + | Router | | Edge | + +--------+ +------------| Router | + | / +--------+ + | / | + +--------+ / =============|====== + | Area |/ || | + | Leader | || +---------+ + +--------+ || | Outside | + || | Edge | + || | Router | + || +---------+ + + Outside Area + + An example of router classes + All Inside Edge Routers learn the Area Proxy System Identifier from the Level 1 LSDB and use that as the system identifier in their Level 2 IS-IS Hello PDUs (IIHs) on all Outside interfaces. Outside Edge Routers should then advertise an adjacency to the Area Proxy System Identifier. This allows all Outside Routers to use the Proxy LSP in their SPF computations without seeing the full topology of the Inside Area. Area Proxy functionality assumes that all circuits on Inside Routers are either Level 1-2 circuits within the Inside Area, or Level 2 @@ -240,49 +259,55 @@ 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 forwarding based on this SID. The Area Leader SHALL also include the - Area Segment SID TLV in the Area Proxy LSP so that the remainder of - L2 can use it for path construction (Section 4.4.11). These two TLVs - are similar in structure, so care must be taken not to confuse them. + Area Segment SID in the Area 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 Router Capability as part of its Level 1 - Router Capability TLV. + advertise the Area Proxy TLV. -3.1. The Area Proxy Router Capability +3.1. The Area Proxy TLV - The Area Proxy Router Capability is a sub-TLV of the Router - Capability TLV [RFC7981] and has the following format: + The Area Proxy TLV serves multiple functions: - 0 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TLV Type | TLV Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + The presence of the Area Proxy TLV in a node's LSP indicates that + the node is enabled for Area Proxy. - TLV Type: LLL + An LSP containing the Area Proxy TLV is also an Inside Node. All + Inside Nodes, including pseudonodes, MUST advertise the Area Proxy + TLV. - TLV Length: 0 + It is a container for sub-TLVs with Area Proxy information. - A router advertising this TLV indicates that it is running Level 1-2 - and is prepared to perform Area Proxy functions. + A node advertises the Area Proxy TLV in its L2 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. 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 @@ -297,37 +322,20 @@ Thus, if two paths have different total inter-area metrics, the path with the lower inter-area metric would be preferred, regardless of any intra-area metrics involved. However, if two paths have equal inter-area metrics, then the intra-area metrics would be used to compare the paths. Point-to-Point links between two Inside Routers are considered to be Inside Area links. LAN links which have a pseudonode LSP in the Level 1 LSDB are considered to be Inside Area links. -3.3. The Inside Node TLV - - To simplify determining which nodes belong to the Inside Area, all - Inside Nodes MUST insert the Inside Node TLV into their LSP and into - any Inside Area pseudonode LSPs. The format of the Inside Node TLV - is: - - 0 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Type: ZZZ - - Length: Zero (0) - 4. Area Leader Functions The Area Leader has several responsibilities. First, it MUST inject the Area Proxy System Identifier into the Level 1 LSDB. Second, the Area Leader MUST generate the Proxy LSP for the Inside Area. 4.1. Area Leader Election The Area Leader is selected using the election mechanisms and TLVs described in Dynamic Flooding for IS-IS @@ -337,64 +345,53 @@ 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. 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. The Area Proxy TLV - - The Area Proxy TLV is a container for sub-TLVs with Area Proxy - Information. This TLV is injected into the Area Leader's Level 1 - 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 +4.3. Distributing Area Proxy Information - TLV Length: length of the sub-TLVs + 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. 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. The format of this sub-TLV - is: + 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Proxy System ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proxy System Identifier continued | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: AAA Length: length of a system ID (6) Proxy System Identifier: the Area Proxy System Identifier. - The Area Leader SHOULD advertise the Area Proxy System Identifier - Sub-TLV when it observes that all Inside Routers are advertising the - Area Proxy Router Capability. Their advertisements indicate that - they are individually ready to perform Area Proxy functionality. The - Area Leader then advertises the Area Proxy System Identifier TLV to - indicate that the Inside Area SHOULD enable Area Proxy functionality. + The Area Leader MUST advertise the Area Proxy System Identifier Sub- + TLV when it observes that all Inside Routers are advertising the Area + Proxy TLV. Their advertisements indicate that they are individually + ready to perform Area Proxy functionality. The Area Leader then + advertises the Area Proxy System Identifier TLV to indicate that the + Inside Area MUST enable Area Proxy functionality. Other candidates for Area Leader MAY also advertise the Area Proxy System Identifier when they observe that all Inside Routers are advertising the Area Proxy Router Capability. All candidates advertising the Area Proxy System Identifier TLV MUST be advertising the same system identifier. Multiple proxy system identifiers in a single area is a misconfiguration and each unique occurrence SHOULD be logged. The Area Leader and other candidates for Area Leader MAY withdraw the @@ -416,27 +413,51 @@ 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: - Type: BBB + Type: BBB in the Area Proxy TLV, ZZZ in TLV 149 or 150. Length: variable (1 + SID length) - Flags: 1 octet, see Section 4.4.11.1 + Flags: 1 octet. + SID/Index/Label: as defined in [RFC8667] Section 2.1.1.1 +4.3.2.1. Flags + + The Flags octet is defined as follows: + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |F|V|L| | + +-+-+-+-+-+-+-+-+ + + where: + + F: Address-Family Flag. If unset, then this proxy SID is used + when forwarding IPv4-encapsulated traffic. If set, then this + 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 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. The Area Leader uses the Level 2 LSPs generated by the Inside Edge @@ -575,92 +597,52 @@ 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. -4.4.11. The Area Segment SID TLV - - 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 TLV 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. - - This TLV is not specific to Area Proxy and MAY be used by Edge - Routers in conventional areas. The Area Segment SID 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: - - Type: XXX - - Length: variable (1 + SID length) - - Flags: 1 octet, see below - - SID/Index/Label: as defined in [RFC8667] Section 2.1.1.1 - -4.4.11.1. Flags - - The Flags octet is defined as follows: - - 0 1 2 3 4 5 6 7 - +-+-+-+-+-+-+-+-+ - |F|V|L| | - +-+-+-+-+-+-+-+-+ - - where: - - F: Address-Family Flag. If unset, then this proxy SID is used - when forwarding IPv4-encapsulated traffic. If set, then this - 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.12. The SRv6 Locator TLV +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.13. Traffic Engineering Information +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 + + 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. + + 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. + 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 @@ -673,62 +655,63 @@ the circuit using the Proxy System Id as the source of the IIH. Using the Proxy System Id causes the Outside Router to advertise an adjacency to the Proxy System Id, not to the Inside Edge Router, which supports the proxy function. The normal system id of the Inside Edge Router MUST NOT be used as it will cause unnecessary adjacencies to form and subsequently flap. 5.2. Filtering LSP information - For the proxy abstraction to be effective the L2 LSPs generated by - the Inside Routers MUST be restricted to the Inside Area. The Inside - Routers know which system ids are members of the Inside Area based on - the Level 1 LSDB. To prevent unwanted LSP information from escaping - the Inside Area, the Inside Edge Router MUST perform filtering of LSP - flooding, CSNPs, and PSNPs. Specifically: + For the area proxy abstraction to be effective the L2 LSPs generated + by the Inside Routers MUST be restricted to the Inside Area. The + Inside Routers know which system ids are members of the Inside Area + based on the advertisement of the Area Proxy TLV. To prevent + unwanted LSP information from escaping the Inside Area, the Inside + Edge Router MUST perform filtering of LSP flooding, CSNPs, and PSNPs. + Specifically: A Level 2 LSP with a source system identifier that is found in the - Level 1 LSDB MUST never be flooded to an Outside Router. + Level 1 LSDB MUST NOT be flooded to an Outside Router. + + A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded + to an Outside Router. A Level 2 CSNP sent to an Outside Router MUST NOT contain any information about an LSP with a system identifier found in the Level 1 LSDB. If an Inside Edge Router filters a CSNP and there is no remaining content, then the CSNP MUST NOT be sent. The source address of the CSNP MUST be the Area Proxy System Id. A Level 2 PSNP sent to an Outside Router MUST NOT contain any information about an LSP with a system identifier found in the Level 1 LSDB. If an Inside Edge Router filters a PSNP and there is no remaining content, then the PSNP MUST NOT be sent. The source address of the PSNP MUST be the Area Proxy System Id. 6. Acknowledgments - The authors would like to thank Bruno Decraene, Vivek Ilangovan, and - Gunter Van De Velde for their many helpful comments. The authors - would also like to thank a small group that wishes to remain - anonymous for their valuable contributions. + The authors would like to thank Bruno Decraene and Gunter Van De + Velde for their many helpful comments. The authors would also like + to thank a small group that wishes to remain anonymous for their + valuable contributions. 7. IANA Considerations This memo requests that IANA allocate and assign one code point from - the IS-IS TLV Codepoints registry for the Area Segment SID TLV (XXX), - one code point for the Area Proxy TLV (YYY), and one code point for - the Inside Node TLV (ZZZ). The registry fields for all three should - be: IIH:n, LSP:y, SNP:n, Purge:n. + the IS-IS TLV Codepoints registry for the Area Proxy TLV (YYY). The + registry fields should be: IIH:n, LSP:y, SNP:n, Purge:n. In association with this, this memo requests that IANA create a registry for code points for the sub-TLVs of the Area Proxy TLV. Name of the registry: Sub-TLVs for TLV YYY (Area Proxy TLV) - Required information for registrations: Temporary registrations may be made under the Early IANA Allocation of Standards Track Code Points policy. [RFC7120] Permanent registrations require the publication of an RFC describing the usage of the code point. Applicable registration policy: RFC Required and Expert Review. We propose the initial experts be Chris Hopps, Tony Li, and Sarah Chen. Size, format, and syntax of registry entries: Value (0-255), Name, @@ -737,23 +720,23 @@ 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 | +-------+------------------------------+---------------+ - IANA is also requested to allocate and assign one code point from the - IS-IS Router Capability TLV sub-TLV registry for the Area Proxy - Capability (LLL). + 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. 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