idnits 2.17.1 draft-li-dynamic-flooding-isis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 18, 2018) is 2203 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Li 3 Internet-Draft Arista Networks 4 Intended status: Informational March 18, 2018 5 Expires: September 19, 2018 7 Dynamic Flooding for IS-IS 8 draft-li-dynamic-flooding-isis-01 10 Abstract 12 Routing with link state protocols in dense network topologies can 13 result in sub-optimal convergence times due to the overhead 14 associated with flooding. This can be addressed by decreasing the 15 flooding topology so that it is less dense. 17 This document discusses extensions to the IS-IS routing protocol to 18 support a solution to flooding in dense subgraphs. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 19, 2018. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Area Leader TLV . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Area System IDs TLV . . . . . . . . . . . . . . . . . . . . . 3 58 4. Flooding Path TLV . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 8.2. Informative References . . . . . . . . . . . . . . . . . 6 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 In recent years, there has been increased focused on how to address 70 the dynamic routing of networks that have a bipartite (a.k.a. spine- 71 leaf), Clos [Clos], or Fat Tree [Leiserson] topology. Conventional 72 Interior Gateway Protocols (IGPs, i.e. IS-IS [ISO10589], OSPF 73 [RFC5340]) under-perform, redundantly flooding information throughout 74 the dense topology, leading to overloaded control plane inputs and 75 thereby creating operational issues. For practical considerations, 76 network architects have resorted to applying unconventional 77 techniques to address the problem, applying BGP in the data center 78 [RFC7938], however it is very clear that using an Exterior Gateway 79 Protocol as an IGP is sub-optimal, if only due to the configuration 80 overhead. 82 This problem is discussed in more detail in [Architecture], along 83 with an architectural solution for the problem. The remainder of 84 this document is focused on describing extensions to the IS-IS 85 protocol to implement that architecture. Three additions appear to 86 be necessary. 88 1. A TLV that an IS may inject into its LSP to indicate its 89 preference for becoming Area Leader. 91 2. A TLV to carry the list of system IDs that compromise the 92 flooding topology for the area. 94 3. A TLV to carry the adjacency matrix for the flooding topology for 95 the area. 97 1.1. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 2. Area Leader TLV 105 The Area Leader TLV allows a system to indicate its eligibility and 106 priority for becoming Area Leader. Intermediate Systems (routers) 107 not advertising this TLV are not eligible to become Area Leader. 109 The Area Leader is the router with the numerically highest Area 110 Leader priority in the area. In the event of ties, the router with 111 the numerically highest system ID is the Area Leader. Due to 112 transients during database flooding, different routers may not agree 113 on the Area Leader. 115 The format of the Area Leader TLV is: 117 0 1 2 118 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | TLV Type | TLV Length | Priority | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 TLV Type: XXX 125 TLV Length: 1 127 Priority: 0-255, unsigned integer 129 3. Area System IDs TLV 131 The Area System IDs TLV is used by the Area Leader to enumerate the 132 system IDs that it has used in computing the flooding topology. 133 Conceptually, the Area Leader creates a list of system IDs for all 134 routers in the area, assigning indices to each system, starting with 135 index 0. 137 Because the space in a single TLV is small, it may require more than 138 one TLV to encode all of the system IDs in the area. This TLV may 139 recur in multiple LSP segments so that all system IDs can be 140 advertised. 142 The format of the Area System IDs TLV is: 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | TLV Type | TLV Length | Starting Index | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Ending Index |L| Reserved | System IDs ... 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 System IDs continued .... 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 TLV Type: YYY 156 TLV Length: 9 + (ID length * N) 158 Starting index: The index of the first system ID that appears in 159 this TLV. 161 Ending index: The index of the last system ID that appears in this 162 TLV. 164 L (Last): This bit is set if the ending index of this TLV is the 165 last index in the full list of system IDs for the area. 167 System IDs: A concatenated list of system IDs for the area. 169 4. Flooding Path TLV 171 The Flooding Path TLV is used to denote a path in the flooding 172 topology. The goal is an efficient encoding of the links of the 173 topology. A single link is a simple case of a path that only covers 174 two nodes. A connected path may be described as a sequence of 175 indices: (I1, I2, I3, ...), denoting a link from the system with 176 index 1 to the system with index 2, a link from the system with index 177 2 to the system with index 3, and so on. 179 If a path exceeds the size that can be stored in a single TLV, then 180 the path may be distributed across multiple TLVs by the replication 181 of a single system index. 183 Complex topologies that are not a single path can be described using 184 multiple TLVs. 186 The Flooding Path TLV contains a list of system indices relative to 187 the systems advertised through the Area System IDs TLV. At least 2 188 indices must be included in the TLV. Due to the lenth restriction of 189 TLVs, this TLV can contain at most 126 system indices. 191 The Flooding Path TLV has the format: 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | TLV Type | TLV Length | Starting Index | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Index 2 | Additional indices ... 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 TLV Type: ZZZ 203 TLV Length: 9 + Length of Matrix octet contents 205 Starting index: The index of the first system in the path. 207 Index 2: The index of the next system in the path. 209 Additional indices: A sequence of additional indices to systems 210 along the path. 212 Matrix: The concatenated rows of the upper right triangular 213 portion of the adjacency matrix for the flooding topology, padded 214 with 0 bits to an octet boundary. 216 5. Acknowledgements 218 The author would like to thank Adam Sweeney for his diligent review. 220 6. IANA Considerations 222 This memo requests that IANA allocate and assign three code points 223 from the IS-IS TLV Codepoints registry. One for each of the 224 following TLVs: 226 1. Area Leader TLV 228 2. Area System IDs TLV 230 3. Flooding Path TLV 232 7. Security Considerations 234 This document introduces no new security issues. Security of routing 235 within a domain is already addressed as part of the routing protocols 236 themselves. This document proposes no changes to those security 237 architectures. 239 8. References 241 8.1. Normative References 243 [ISO10589] 244 International Organization for Standardization, 245 "Intermediate System to Intermediate System Intra-Domain 246 Routing Exchange Protocol for use in Conjunction with the 247 Protocol for Providing the Connectionless-mode Network 248 Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002. 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, 252 DOI 10.17487/RFC2119, March 1997, 253 . 255 8.2. Informative References 257 [Architecture] 258 Li, T., "An Architecture for Dynamic Flooding on Dense 259 Graphs", Internet draft draft-li-dynamic-flooding, Jan. 260 2018. 262 [Clos] Clos, C., "A Study of Non-Blocking Switching Networks", 263 The Bell System Technical Journal Vol. 32(2), DOI 264 10.1002/j.1538-7305.1953.tb01433.x, March 1953, 265 . 267 [Leiserson] 268 Leiserson, C., "Fat-Trees: Universal Networks for 269 Hardware-Efficient Supercomputing", IEEE Transactions on 270 Computers 34(10):892-901, 1985. 272 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 273 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 274 . 276 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 277 BGP for Routing in Large-Scale Data Centers", RFC 7938, 278 DOI 10.17487/RFC7938, August 2016, 279 . 281 Author's Address 282 Tony Li 283 Arista Networks 284 5453 Great America Parkway 285 Santa Clara, California 95054 286 USA 288 Email: tony.li@tony.li