--- 1/draft-ietf-lsr-isis-area-proxy-02.txt 2020-08-05 14:13:13.998978334 -0700 +++ 2/draft-ietf-lsr-isis-area-proxy-03.txt 2020-08-05 14:13:14.046979588 -0700 @@ -1,21 +1,21 @@ Internet Engineering Task Force T. Li Internet-Draft S. Chen Intended status: Experimental V. Ilangovan -Expires: January 26, 2021 Arista Networks +Expires: February 6, 2021 Arista Networks G. Mishra Verizon Inc. - July 25, 2020 + August 5, 2020 Area Proxy for IS-IS - draft-ietf-lsr-isis-area-proxy-02 + draft-ietf-lsr-isis-area-proxy-03 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 26, 2021. + This Internet-Draft will expire on February 6, 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 @@ -63,47 +63,46 @@ 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 SID Sub-TLV . . . . . . . . . . . . . . . . 9 - 4.3.2.1. Flags . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Proxy LSP Generation . . . . . . . . . . . . . . . . . . 10 - 4.4.1. The Protocols Supported TLV . . . . . . . . . . . . . 10 + 4.4.1. The Protocols Supported TLV . . . . . . . . . . . . . 11 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 SID . . . . . . . . . . . . . . . . . . . . 14 - 5. Inside Edge Router Functions . . . . . . . . . . . . . . . . 15 - 5.1. Generating L2 IIHs to Outside Routers . . . . . . . . . . 15 + 5. Inside Edge Router Functions . . . . . . . . . . . . . . . . 14 + 5.1. Generating L2 IIHs to Outside Routers . . . . . . . . . . 14 5.2. Filtering LSP information . . . . . . . . . . . . . . . . 15 - 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 + 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 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 @@ -398,44 +397,48 @@ 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 SID Sub-TLV - 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: + The Area SID Sub-TLV allows the Area Leader to advertise a prefix and + 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Prefix Length | Prefix (variable) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: - Type: BBB in the Area Proxy TLV, ZZZ in TLV 149 or 150. + Type: BBB Length: variable (1 + SID length) - Flags: 1 octet. SID/Index/Label: as defined in [RFC8667] Section 2.1.1.1 -4.3.2.1. Flags + Prefix Length: 1 octet + + Prefix: 0-16 octets The Flags octet is defined as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|V|L| | +-+-+-+-+-+-+-+-+ where: @@ -618,64 +621,35 @@ 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 SID 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. - - 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." + will direct traffic to any of the Inside Edge Routers. The + information for the Area SID is distributed to all Inside Edge + Routers using the Area SID sub-TLV (Section 4.3.2) by the Area + Leader. - 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. + The Area Leader SHOULD advertise the Area SID information in the + Proxy LSP as a Node SID as defined in [RFC8667] Section 2.1. 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. - 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. + 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. 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 @@ -755,23 +729,20 @@ 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 SID | This document | +-------+------------------------------+---------------+ - This memo also requests that IANA allocate a code point (ZZZ) for the - 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 9.1. Normative References