idnits 2.17.1 draft-ietf-isis-wg-mesh-group-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 114 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2000) is 8687 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Balay 3 INTERNET DRAFT Ericsson 5 D. Katz 6 Juniper Networks 8 J. Parker 9 Lucent Technology 11 July 7, 2000 13 IS-IS Mesh Groups 15 17 1. Status of this Memo 19 This document is an Internet-Draft and is in full conformance 20 with all provisions of Section 10 of RFC 2026. 22 Internet-Drafts are working documents of the Internet 23 Engineering Task Force (IETF), its areas, and its working 24 groups. Note that other groups may also distribute working 25 documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet- 30 Drafts as reference material or to cite them other than as 31 "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed 37 at http://www.ietf.org/shadow.html. 39 Copyright Notice 41 Copyright (C) The Internet Society (1997). All Rights 42 Reserved. 44 2. Abstract 46 This document describes a mechanism to reduce redundant packet 47 transmissions for the IS-IS Routing protocol, as described in 48 ISO 10589 [1]. The described mechanism can be used to reduce 49 the flooding of Link State PDUs (LSPs) in IS-IS topologies. 50 The net effect is to engineer a flooding topology for LSPs 51 which is a subset of the physical topology. This draft serves 52 to document the existing behavior in deployed implementations. 54 The draft describes behaviors that are backwards compatible 55 with implementations that do not support this feature. 57 This document is provided to the IETF working group on IS-IS. 59 Table of Contents 61 1. Status of this Memo.................................. 1 62 2. Abstract............................................. 2 63 3. Overview............................................. 2 64 4. Definitions of Mesh Groups........................... 4 65 5. Drawbacks of Mesh Groups............................. 6 66 6. Interoperation with Mesh Groups...................... 7 67 7. Acknowledgments...................................... 7 68 8. References........................................... 7 69 9. Security Considerations.............................. 8 70 10. Authors' Address..................................... 8 71 11. Full Copyright Statement............................. 9 73 3. Overview 75 In ATM or frame relay networks Intermediate Systems are 76 inter-connected using virtual circuits (VCs) which are logical 77 point-to-point links. Some organizations attach multiple 78 Intermediate Systems to form a full "mesh" topology, where 79 every pair of Intermediate Systems are connected by a point- 80 to-point link. In such topologies, IS-IS protocol operation 81 leads to redundant transmission of certain PDUs due to the 82 flooding operation which is illustrated below. 84 When an Intermediate System gets a new Link State Protocol 85 Data Unit (LSP), it stores it, and prepares to flood it out 86 every circuit except the source circuit. This is done by 87 setting SRM (Send Routing Message) bits held in the local copy 88 of the LSP: there is an SRM for each circuit. 90 +----------+ +----------+ 91 | | I12 I21 | | 92 | System 1 | --------------------------- | System 2 | 93 | | | | 94 +----------+ +----------+ 95 I13 | \ I14 I23 / | I24 96 | \ / | 97 | \ / | 98 | \ / | 99 | \ / | 100 | \ / | 101 | \ / | 102 | . | 103 | / \ | 104 | / \ | 105 | / \ | 106 | / \ | 107 | / \ | 108 | / \ | 109 I31 | / I32 I41 \ | I42 110 +----------+ +----------+ 111 | | | | 112 | System 3 | --------------------------- | System 4 | 113 | | I34 I43 | | 114 +----------+ +----------+ 116 Figure 1. A four node full mesh topology 118 When System1 regenerates an LSP, it will flood the LSP through 119 the network by marking the SRM bits for circuits I12, I14, and 120 I13. In due course, it will send out the LSP on each circuit. 122 When System2 receives System1's LSP, it propagates the PDU 123 according to section 7.2.14 of ISO 10589 [1]. It sets the SRM 124 bits on circuits I23 and I24, to flood the LSP to System3 and 125 System4. However, these Intermediate Systems will get the LSP 126 directly from System1. In a full mesh of N Intermediate 127 Systems, the standard protocol mechanism results in N-2 extra 128 transmissions of each LSP, a waste of bandwidth and processing 129 effort, with little gain in reliability. 131 Mesh groups provide a mechanism to reduce the flooding of 132 LSPs. 134 4. Definitions of Mesh Groups 136 A mesh group is defined as a set of point-to-point circuits 137 which provide full connectivity to a set of Intermediate 138 Systems. Each circuit has two new attributes: 139 meshGroupEnabled, which is in state {meshInactive, 140 meshBlocked, or meshSet} and an integer variable meshGroup, 141 which is valid only if the value of meshGroupEnabled attribute 142 is 'meshSet'. Circuits that are in state 'meshSet' and that 143 have the same value of meshGroup are said to be in the same 144 mesh group. 146 LSPs are not flooded over circuits in 'meshBlocked' state, and 147 an LSP received on a circuit C is not flooded out circuits 148 that belong to C's mesh group. 150 Section 7.3.15.1 clause e.1.ii) of ISO 10589 [1] is modified 151 as follows: 153 e.1.ii) 154 if the meshGroupEnabled attribute is 'meshSet' for the 155 circuit C, set the SRMflag for that LSP for all circuits 156 other than C whose meshGroupEnabled attribute is 157 'meshInactive'. Also set the SRMflag for all circuits in 158 state 'meshSet' whose meshGroup attribute is not the same 159 as C's. 161 if the meshGroupEnabled attribute is 'meshInactive' for 162 circuit C, set the SRMflag for that LSP for all circuits 163 other than C whose meshGroupEnabled attribute is not 164 'meshBlocked'. 166 For robust database synchronization when using mesh groups, 167 the Complete Sequence Number PDUs (CSNPs) are sent 168 periodically on point-to-point links with a mesh group 169 meshEnabled or meshBlocked. Section 7.3.15.3 clause b) of ISO 170 10589 [1] is modified as follows: 172 b) If C is a point-to-point circuit (including non-DA DED 173 circuits and virtual links), then 175 1) If the circuit's attribute is 'meshSet' or 'meshBlocked', 176 then for each valid level, the IS will send a complete 177 set of CSNPs as described for a Designated IS in section 178 7.3.15.3 clause a). 180 2) CSNPs are transmitted only at initialization on point- 181 to-point links whose state is 'meshInactive'. 183 Use of mesh groups at an Intermediate System also modifies the 184 behavior in transmission of generated LSPs. These LSPs are not 185 required to be transmitted over circuits in state 186 'meshBlocked' at system startup or when the LSP is 187 regenerated. The second sentence of Section 7.3.12 is 188 modified to read: 190 "For all the circuits whose meshGroupEnabled attribute is 191 not 'meshBlocked', the IS shall set the SRMflags for that 192 Link State PDU to propagate it on all these circuits. The 193 IS shall clear the SRMflags for circuits whose 194 meshGroupEnabled attribute is 'meshBlocked'." 196 Some of the transient transmission overhead can be reduced by 197 having an Intermediate System not transmit its copies of the 198 LSPs in database on a circuit start-up/restart if the circuit 199 is 'meshBlocked'. The clause a) in the last part of Section 200 7.3.17 of ISO 10589, which refers to the point-to-point 201 circuits, is modified as follows: 203 a) set SRMflag for that circuit on all LSPs if the 204 meshGroupEnabled attribute of the circuit is not 205 'meshBlocked', and 207 Numbering of mesh groups provides the ability to divide a 208 large full mesh topology into a smaller group of full mesh 209 sub-topologies (mesh groups). These mesh groups are connected 210 by "transit" circuits which are 'meshInactive', while the 211 remaining circuits between the mesh groups are configured as 212 'meshBlocked' to reduce flooding redundancy. Use of numbering 213 makes mesh groups more scalable. 215 5. Drawbacks of Mesh Groups 217 The mesh group feature described in this document is a simple 218 mechanism to reduce flooding of LSPs in some IS-IS topologies. 219 It relies on a correct user configuration. If a combination 220 of user configuration and link failures result in a 221 partitioned flooding topology, LSPs will not be sent in a 222 timely fashion, which may lead to routing loops or black 223 holes. 225 The concept of using numbered mesh groups also suffers from 226 the complexity and reliance on static configuration, making 227 the topologies brittle. Loosing a transit link can partition 228 LSP flooding in unpredictable ways, requiring the periodic 229 flooding of CSNPs to synchronize databases. In large networks, 230 CSNPs become large and also consume bandwidth. 232 The authors are not aware of any networks that have deployed 233 numbered mesh groups: instead, administrators set links to 234 state 'meshBlocked' to prune the flooding topology (also known 235 as "poor man's mesh groups"). 237 Some improvements to mesh groups which have been suggested 238 include: 240 a) To negotiate or check the mesh group attributes during 241 initialization of an adjacency to verify that the two 242 ends of every circuit hold identical values of the mesh 243 state and mesh number. 245 b) Dynamic election of active transit links so that a 246 topology could recover from failure of transit circuits. 248 c) Reduce the flooding of CSNPs by sending them periodically 249 on some meshGroup circuits rather than all circuits. 251 d) Reduce the size of PDUs required by flooding of CSNPs by 252 sending CSNP summaries: checksums or sequence numbers. 254 Any such improvements are outside the scope of this document, 255 and may be the basis for future work. 257 6. Interoperation with Mesh Groups 259 Since mesh groups do not alter the content of packets, an 260 Intermediate System that does not implement mesh groups will 261 not see any different packets or new TLVs. The only impact 262 will be that additional CSNPs will be seen on some point-to- 263 point links. A conformant implementation can be expected to 264 respond correctly to extra CSNPs. 266 7. Acknowledgments 268 The original idea for mesh groups is due to Dave Katz. Thanks 269 to Tony Li, Tony Przygienda, Peter Livesey, and Henk Smit for 270 helpful comments. 272 8. References 274 [1] ISO/IEC 10589, "Intermediate System to Intermediate 275 System Intra- Domain Routeing Exchange Protocol for use 276 in Conjunction with the Protocol for Providing the 277 Connectionless-mode Network Service (ISO 8473)", June 278 1992. 280 9. Security Considerations 282 This document raises no new security issues for IS-IS. 284 10. Authors' Address 286 Rajesh Balay 287 CoSine Communications 288 1200 Bridge Parkway 289 Redwood City, CA 94065 290 email: Rajesh.Balay@cosinecom.com 292 Dave Katz 293 Juniper Networks 294 385 Ravendale Drive 295 Mountain View, CA 94043 296 email: dkatz@juniper.net 298 Jeff Parker 299 Lucent Technologies, 300 200 Nickerson Road, 301 Marlborough, MA 01752 302 email: jparker@nexabit.com 304 11. Full Copyright Statement 306 Copyright (C) The Internet Society (1997). All Rights 307 Reserved. 309 This document and translations of it may be copied and 310 furnished to others, and derivative works that comment on or 311 otherwise explain it or assist in its implementation may be 312 prepared, copied, published and distributed, in whole or in 313 part, without restriction of any kind, provided that the above 314 copyright notice and this paragraph are included on all such 315 copies and derivative works. However, this document itself 316 may not be modified in any way, such as by removing the 317 copyright notice or references to the Internet Society or 318 other Internet organizations, except as needed for the purpose 319 of developing Internet standards in which case the procedures 320 for copyrights defined in the Internet Standards process must 321 be followed, or as required to translate it into languages 322 other than English. 324 The limited permissions granted above are perpetual and will 325 not be revoked by the Internet Society or its successors or 326 assigns. 328 This document and the information contained herein is provided 329 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 330 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 331 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 332 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 333 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 334 PARTICULAR PURPOSE."