idnits 2.17.1 draft-kompella-isis-ospf-rmr-00.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 (October 30, 2016) is 2707 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) == Missing Reference: 'RID' is mentioned on line 203, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-mpls-rmr-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IS-IS OSPF K. Kompella 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track October 30, 2016 5 Expires: May 3, 2017 7 IGP Extensions for Resilient MPLS Rings 8 draft-kompella-isis-ospf-rmr-00 10 Abstract 12 This document describes the use of IS-IS and OSPF for discovering 13 Resilient MPLS Rings (RMR). RMR relies on the IGP for discovery of 14 the ring elements and properties, as well as subsequent changes to 15 the ring topology. Details of auto-discovery and operation are given 16 in the RMR architecture document; this document simply describes the 17 formats of RMR-related constructs in IS-IS and OSPF. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 3, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Announcement . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 5.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 Rings are a very common topology in transport networks. A ring is 74 the simplest topology offering link and node resilience. Rings are 75 nearly ubiquitous in access and aggregation networks. As MPLS 76 increases its presence in such networks, and takes on a greater role 77 in transport, it is imperative that MPLS handles rings well; this is 78 not the case today. The RMR architecture document 79 [I-D.ietf-mpls-rmr] describes the motivations and operation of RMR. 81 RMR uses protocols such as IS-IS [RFC5305] and OSPF[RFC3630] for 82 auto-discovery, and RSVP-TE [RFC3209] and LDP [RFC5036] for signaling 83 LSPs. This document gives the specifics of Type-Length-Value (TLV) 84 formats for IS-IS and OSPF. 86 1.1. Definitions 88 For a more detailed description, see [I-D.ietf-mpls-rmr]. 90 A ring is a subgraph of a given graph G = (V, E), consisting of a 91 subset of n nodes {R_i, 0 <= i < n}. The directed edges {(R_i, 92 R_i+1) and (R_i+1, R_i), 0 <= i < n-1} must be a subset of E (note 93 that index arithmetic is done modulo n). We define the direction 94 from node R_i to R_i+1 as "clockwise" (CW) and the reverse direction 95 as "anticlockwise" (AC). As there may be several rings in a graph, 96 we number each ring with a distinct ring ID RID. 98 R0 . . . R1 99 . . 100 R7 R2 101 Anti- | . Ring . | 102 Clockwise | . . | Clockwise 103 v . RID = 17 . v 104 R6 R3 105 . . 106 R5 . . . R4 108 Figure 1: Ring with 8 nodes 110 The following terminology is used for ring LSPs: 112 Ring ID (RID): A non-zero number that identifies a ring; this is 113 unique in some scope of a Service Provider's network. A node may 114 belong to multiple rings. 116 Ring node: A member of a ring. Note that a device may belong to 117 several rings. 119 Node index: A logical numbering of nodes in a ring, from zero upto 120 one less than the ring size. Used purely for exposition in this 121 document. 123 Ring master: The ring master initiates the ring identification 124 process. Mastership is indicated in the IGP by a two-bit field. 126 Ring neighbors: Nodes whose indices differ by one (modulo ring 127 size). 129 Ring links: Links that connnect ring neighbors. 131 Express links: Links that connnect non-neighboring ring nodes. 133 Ring direction: A two-bit field in the IGP indicating the direction 134 of a link. The choices are: 136 UN: 00 undefined link 138 CW: 01 clockwise ring link 140 AC: 10 anticlockwise ring link 142 EX: 11 express link 144 Ring Identification: The process of discovering ring nodes, ring 145 links, link directions, and express links. 147 The following notation is used for ring LSPs: 149 R_k: A ring node with index k. R_k has AC neighbor R_(k-1) and CW 150 neighbor R_(k+1). 152 RL_k: A (unicast) Ring LSP anchored on node R_k. 154 CL_jk: A label allocated by R_j for RL_k in the CW direction. 156 AL_jk: A label allocated by R_j for RL_k in the AC direction. 158 P_jk (Q_jk): A Path (Resv) message sent by R_j for RL_k. 160 2. Theory of Operation 162 Say a ring has ring ID RID. The ring is provisioned by choosing one 163 or more ring masters for the ring and assigning them the RID. Other 164 nodes in the ring may also be assigned this RID, or may be configured 165 as "promiscuous". Ring discovery then kicks in. When each ring node 166 knows its CW and AC ring neighbors and its ring links, and all 167 express links have been identified, ring identification is complete. 169 Once ring identification is complete, each node signals one or more 170 ring LSPs RL_i. RL_i, anchored on node R_i, consists of two counter- 171 rotating unicast LSPs that start and end at R_i. A ring LSP is 172 "multipoint": any node R_j can use RL_i to send traffic to R_i; this 173 can be in either the CW or AC directions, or both (i.e., load 174 balanced). Both of these counter-rotating LSPs are "active"; the 175 choice of direction to send traffic to R_i is determined by policy at 176 the node where traffic is injected into the ring. The default is to 177 send traffic along the shortest path. Bidirectional connectivity 178 between nodes R_i and R_j is achieved by using two different ring 179 LSPs: R_i uses RL_j to reach R_j, and R_j uses RL_i to reach R_i. 181 2.1. Provisioning 183 For the purposes of RMR, a ring node R is configured with its 184 loopback address, the RID that it will participate in, and what link- 185 state IGP to use for auto-discovery. R is also configured with a 186 mastership value, which is used in master election. Finally, R may 187 be configured with the signaling protocols and OAM protocols it 188 supports, or these may be inferred. Note that R may participate in 189 multiple rings; each would have its own configuration. 191 To simplify ring provisioning even further, R may be made 192 "promiscuous" by being assigned an RID of 0. A promiscuous node 193 listens to RIDs in its IGP neighbors' link-state updates in order to 194 acquire an RID for its use. Details are in [I-D.ietf-mpls-rmr]. 196 2.2. Announcement 198 Once configured, R announces its configuration parameters in the IGP 199 via an RMR Node TLV. The RMR Node TLV may contain sub-TLVs; in 200 particular, the RMR Neighbor TLV. At a high level, these TLVs are as 201 follows. 203 [RMR Node Type][RMR Node Length][RID][Node Flags][sub-TLVs] 205 Ring Node TLV Structure 207 [RMR Nbr Type][RMR Nbr Length][Nbr Address][Nbr Flags] 209 Ring Neighbor Sub-TLV Structure 211 In IS-IS, the RMR Node TLV is a new top-level TLV. The specific 212 format is as follows: 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Type (TBD) | Length = 6+S | Ring ID (4 octets) ... | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | ... (RID continued) | Node Flags (2 octets) | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | sub-TLVs, if any ... 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 S is the total size of the sub-TLVs 225 Ring Node TLV Format 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Type (TBD) | Length = n*6 | Neighbor Loopback ... | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | ... (continued, 4 octets) | Neighbor Flags (2 octets) | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Neighbor Loopback (4 octets) | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Neighbor Flags (2 octets) | (etc.) 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 n = number of neighbors included in the sub-TLV 240 Ring Neighbor sub-TLV Format 242 In OSPF, the RMR Node TLV is a new top-level TLV of the Traffic 243 Engineering Opaque LSA. 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type (TBD) | Length = 8+S | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Ring ID (4 octets) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Node Flags (2 octets) | Pad (2 octets) | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | sub-TLVs ... 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Pad is set to zero when sending and ignored on receipt. 257 S = total length of sub-TLVs 259 OSPF Ring Node TLV Format 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Type (TBD) | Length = 6*N | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Neighbor Loopback (4 octets) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Neighbor Flags (2 octets) | Pad (2 octets) | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Neighbor Loopback (4 octets) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Neighbor Flags (2 octets) | Pad (2 octets) | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | ... etc. | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Pad is set to zero when sending and ignored on receipt. 278 OSPF Neighbor sub-TLV Format 280 0 1 281 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 |MV |SS | SO | MBZ |SU |M| 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 MV: Mastership Value 286 SS: Supported Signaling Protocols (10 = RSVP-TE; 01 = LDP) 287 SO: Supported OAM Protocols (100 = BFD; 010 = CFM; 001 = EFM) 288 SU: Signaling Protocol to Use (00 = none; 01 = LDP; 10 = RSVP-TE) 289 M : Elected Master (0 = no, 1 = yes) 291 Flags for a Ring Node TLV 293 0 1 294 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 |RD |OAM| MBZ | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 RD: Ring Direction 299 OAM: OAM Protocol to use (00 = none; 01 = BFD; 10 = CFM; 11 = EFM) 301 Flags for a Ring Neighbor TLV 303 3. Security Considerations 305 It is not anticipated that either the notion of MPLS rings or the 306 extensions to link-state IGPs to support them will cause new security 307 loopholes. As this document is updated, this section will also be 308 updated. 310 4. IANA Considerations 312 IANA is requested to assign a new top-level TLV for the RMR Node TLV 313 from the IS-IS TLV Codepoints Registry. IANA is also requested to 314 create a new registry for sub-TLVs of the RMR Node TLV. 316 IANA is also requested to assign a new top-level type for the RMR 317 Node TLV from the OSPF TE TLVs Registry. IANA is also requested to 318 create a new registry for sub-TLVs of the RMR Node TLV. 320 5. References 322 5.1. Normative References 324 [I-D.ietf-mpls-rmr] 325 Kompella, K. and L. Contreras, "Resilient MPLS Rings", 326 draft-ietf-mpls-rmr-03 (work in progress), October 2016. 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, 330 DOI 10.17487/RFC2119, March 1997, 331 . 333 5.2. Informative References 335 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 336 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 337 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 338 . 340 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 341 (TE) Extensions to OSPF Version 2", RFC 3630, 342 DOI 10.17487/RFC3630, September 2003, 343 . 345 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 346 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 347 October 2007, . 349 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 350 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 351 2008, . 353 Author's Address 355 Kireeti Kompella 356 Juniper Networks, Inc. 357 1133 Innovation Way 358 Sunnyvale, CA 94089 359 USA 361 Email: kireeti.kompella@gmail.com