idnits 2.17.1 draft-eastlake-trill-nick-label-prop-02.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 date (October 12, 2013) is 3848 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. 'ISO-10589' ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Donald Eastlake 2 INTERNET-DRAFT Weiguo Hao 3 Intended status: Proposed Standard Huawei 4 Expires: April 11, 2014 October 12, 2013 6 TRILL: Nickname and Label Properties 7 9 Abstract 11 There are a number of current and prospective requirements to 12 indicate properties of nicknames, labels, and blocks thereof, for use 13 with the TRILL (Transparent Interconnection of Lots of Links, RFC 14 6325) protocol. To meet that need, this document specifies IS-IS 15 (Intermediate System to Intermediate System) sub-TLVs and some of 16 their uses. 18 Status of This Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Distribution of this document is unlimited. Comments should be sent 24 to the TRILL working group mailing list. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 38 Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Table of Contents 43 1. Introduction............................................3 44 1.1 Conventions Used in This Document......................3 46 2. The Nickname Properties Sub-TLV.........................4 48 3. The Label Properties Sub-TLV............................7 50 4. IANA Considerations.....................................9 52 5. Security Considerations.................................9 54 6. Normative References...................................10 56 7. Informative References.................................10 58 Acknowledgements..........................................11 60 Authors' Addresses........................................12 62 1. Introduction 64 There are a number of current and prospective requirements to 65 indicate properties of Nicknames, data Labels, and blocks thereof, 66 for use with the TRILL (Transparent Interconnection of Lots of Links 67 [RFC6325]) protocol. To meet that need, this document specifies two 68 IS-IS (Intermediate System to Intermediate System [ISO-10589] 69 [RFC1195]) sub-TLVs and some of their uses. 71 These sub-TLVs are used to flag properties of Nicknames and data 72 Labels. Provision is made for flags associated with 74 o individual Nicknames, 75 o blocks of Nicknames, 76 o individual Labels, and 77 o blocks of Labels. 79 In addition, different sizes of Nicknames and data Labels can be 80 accommodated. 82 The sub-TLVs specified in this document are used as follows: 84 o They appear only in the IS-IS Router Capability and MT-Capability 85 TLVs, which are TLVs number 242 and 144 and are specified in 86 [RFC4971] and [RFC6329] respectively. 88 o They can appear multiple times in the same or different Capability 89 or MT-Capability TLVs. 91 1.1 Conventions Used in This Document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. The Nickname Properties Sub-TLV 99 The structure of the Nickname properties (NICK-PROP) sub-TLV is as 100 shown below. 102 +-+-+-+-+-+-+-+-+ 103 | Type = TBD | (1 byte) 104 +-+-+-+-+-+-+-+-+ 105 | Length | (1 byte) 106 +-+-+-+-+-+-+-+-+-+-+-+-+... 107 | NICK-PROP RECORD 1 (variable) 108 +-+-+-+-+-+-+-+-+-+-+-+... 109 | NICK-PROP RECORD 2 (variable) 110 +-+-+-+-+-+-+-+-+-+-+-+... 111 | ... 112 +-+-+-+-+-+-+-+-+-+-+-+... 113 | NICK-PROP RECORD K 114 +-+-+-+-+-+-+-+-+-+-+-+... 116 Figure 1. The Nickname Properties Sub-TLV 118 o Type: NICK-PROP Sub-TLV type, set to TBD. 120 o Length: Variable. 122 o NICK-PROP RECORD: Variable length record as described below. 124 Each NICK-PROP RECORD is structured as follows. 126 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 127 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 128 |NB| NKSZ |IN|OK| RESV | 129 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 130 | Nickname Information (variable) 131 +-+-+-+-+-+-+-+-+-+-+-+... 133 NB: If the NB (Nickname Block) flag is zero, the Nickname Information 134 is a single Nickname. If the NB flag is one, the Nickname 135 Information consists of an initial and final Nickname that are 136 treated as unsigned integers and specify a block of Nicknames 137 inclusively. 139 NKSZ: The NKSZ field specifies the size of each of the one or two 140 Nickname values (see NB bit) that occur in the Nickname 141 Information 143 The assigned value of NKSZ is as follows: 145 NKSZ 146 ---- 147 0 16-bit Nicknames 148 1-7 Available for assignment 150 IN: The IN flag is ignored unless the NB flag is zero and the 151 Nickname Information is a Nickname owned by the RBridge 152 advertising the enclosing NICK-PROP sub-TLV. When it is not being 153 ignored and is equal to one, the IN flag indicates that the 154 Nickname may be used by the advertising RBridge as the ingress 155 Nickname for TRILL Data frames it creates. 157 TRILL switches may have multiple Nicknames [RFC6325] but there is 158 no reason within the TRILL protocol for a TRILL switch to use 159 more than one Nickname as the ingress Nickname for TRILL Data 160 frames it creates. If a TRILL switch is not using all the 161 Nicknames it holds as ingress Nicknames, it SHOULD use the NICK- 162 PROP sub-TLV to indicate the Nickname (or Nicknames) it is using 163 as ingress. This reduces the amount of Reverse Path Forwarding 164 Check (RPFC) state in the campus. The amount of such state at 165 each TRILL switch port is roughly proportional to the product the 166 number of ingress Nicknames in use and the number of multi- 167 destination distribution trees in use. If a TRILL switch does not 168 avertise any ingress Nickname or Nicknames using the IN flag, it 169 may use any Nickname it hold as an ingress Nickname. 171 OK: The OK flag is only effective if the NB flag is one and the NICK- 172 PROP sub-TLV is advertised by the TRILL switch that is highest 173 priority to be a tree root. TRILL switches that understand the OK 174 flag and see one or more OK flags that are effective and are set 175 to one dynamically select their Nickname as specified in 176 [RFC6325] and [clearcorrect] except that they do so only from the 177 block or blocks of nicknames advertised by NICK-PROP sub-TLV 178 NICK-PROP RECORDS with an effective OK flag set to one. Such 179 blocks are called the OK Nicknames blocks and a Nickname that is 180 included in them is called an OK Nickname. If any Nickname value 181 in the range from 0xFFC0 through 0xFFFF or equal to 0x0000 is 182 advertised as part of an OK Nickname block they are ignored. For 183 example, if 0xE000 through 0xFFFF was advertised as an OK 184 Nickname block, it would be treated as if 0xE000 through 0xFFBF 185 was advertised. 187 If the OK Nickname blocks change such that any TRILL switch is 188 holding a Nickname that is no longer OK, that TRILL switch MUST 189 allocate a new OK Nickname. To maximize network stability, all 190 TRILL switches that might become highest priority tree root 191 SHOULD advertise the same OK Nickname blocks. 193 Intended uses of this flag are to restrict Nicknames within part 194 of a network so as to support some methods to implement 196 [multilevel] or [multidatacenter] TRILL. 198 RESV: The remaining 10 bits are reserved and MUST be set to zero and 199 ignored on receipt. 201 Nickname Information: If NB is zero, this information consists of 202 a single Nickname. If NB is one, this information consists of an 203 initial and final Nickname and represents a block of Nicknames. 204 The Nicknames are treated as unsigned integers in network byte 205 order. If the final Nickname of a block is less than the initial 206 Nickname, the NICK-PROP RECORD is ignored. If the initial and 207 final Nicknames are equal, then a block of size one is indicated. 208 Otherwise a block of Nickname values with a size greater than one 209 is indicated, starting with initial Nickname through and 210 including the final Nickname. If the size of each Nickname value 211 is not a multiple of 8 bits, the Nickname values are padded with 212 initial reserved bits up to the next multiple of 8. These 213 reserved bits MUST be sent as zero and ignored on receipt. 215 Each NICK-PROP RECORD must fit within the Length of the NICK-PROP 216 sub-TLV. If there is a truncated NICK-PROP RECORD at the end of hte 217 sub-TLV, that RECORD is ignored. 219 For IANA Considerations in assigning values of NKSZ and bits in the 220 RESV field, see Section 4. 222 3. The Label Properties Sub-TLV 224 The structure of the Label properties (LABEL-PROP) sub-TLV is as 225 shown below. 227 +-+-+-+-+-+-+-+-+ 228 | Type = TBD | (1 byte) 229 +-+-+-+-+-+-+-+-+ 230 | Length | (1 byte) 231 +-+-+-+-+-+-+-+-+-+-+-+-+... 232 | LABEL-PROP RECORD 1 (variable) 233 +-+-+-+-+-+-+-+-+-+-+-+... 234 | LABEL-PROP RECORD 2 (variable) 235 +-+-+-+-+-+-+-+-+-+-+-+... 236 | ... 237 +-+-+-+-+-+-+-+-+-+-+-+... 238 | LABEL-PROP RECORD K 239 +-+-+-+-+-+-+-+-+-+-+-+... 241 Figure 2. The Label Properties Sub-TLV 243 o Type: LABEL-PROP Sub-TLV type, set to TBD. 245 o Length: Variable. 247 o LABEL-PROP RECORD: Variable length record as described below. 249 Each LABEL-PROP RECORD is structured as follows. 251 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 252 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 253 |LB| LBSZ | SCP |MG| RESV | 254 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 255 | Label Information (variable) 256 +-+-+-+-+-+-+-+-+-+-+-+... 258 LB: If the LB (Label Block) flag is zero, the Label Information is a 259 single Label. If the LB flag is one, the Label Information 260 consists of an initial and final Label that are treated as 261 unsigned integers and specify a block of Labels inclusively. 263 LBSZ: The LBSZ field specifies the size and type of each of the one 264 or two Label values (see LB bit) that occur in the Nickname 265 Information 267 The assigned values of LBSZ are as follows: 269 LBSZ 270 ---- 271 0 12-bit VLAN ID 272 1 24-bit FGL Label [FGL] 273 2-7 275 SCP: The SCP or Scope field only has an effect if it is non-zero and 276 the LABEL-PROP sub-TLV is advertised by the TRILL switch that is 277 highest priority to be a tree root. If indicates the scope of 278 propagation of TRILL Data frames having the data label or any of 279 the data labels in the block indicated by the PROPERTY RECORD. 280 The following values for SCP are currently specified: 282 SCP Meaning 283 --- ------- 284 0 No scope specified 285 1 Available for assignment 286 2 Throughout a campus 287 3 Local, within part of a campus [TreeDistr] 289 MG: The MG bit is used to indicate the management Label. It is only 290 effective if the LB flag is zero and the LABEL-PROP sub-TLV is 291 advertised by the TRILL switch that is highest priority to be a 292 tree root. All TRILL switches that understand this bit MUST 293 indicate interest in the listed Label unless this bit is set for 294 more than one Label, in which case only the lowest valued such 295 Label will be considered the management Label. The failure of a 296 TRILL switch to indicate interest in this label will be ignored 297 and tree distribution of TRILL data frames with this label will 298 not be pruned. 300 RESV: The remaining 9 bits are reserved. See Section 4 for IANA 301 Considerations. 303 Label Information: If LB is zero, this information consists of a 304 single Label. If LB is one, this information consists of an 305 initial and final Label and represents a block of Labels. The 306 Labels are treated as unsigned integers in network byte order. If 307 the final Label for a block is less than the initial Label, the 308 LABEL-PROP RECORD is ignored. If the initial and final Labels are 309 equal, then a block of size one is indicated. Otherwise a block 310 of Label values with a size greater than one is indicated, 311 starting with initial Label through and including the final 312 Label. If the size of each Label value is not a multiple of 8 313 bits, each Label value is padded with initial reserved bits up to 314 the next multiple of 8. These reserved bits MUST be sent as zero 315 and ignored on receipt. For example, 12-bit Labels are padded 316 with four initial zeros. 318 4. IANA Considerations 320 TBD 322 5. Security Considerations 324 TBD 326 For general TRILL security considerations, see [RFC6325]. 328 6. Normative References 330 [ISO-10589] - ISO/IEC 10589:2002, Second Edition, "Intermediate 331 System to Intermediate System Intra-Domain Routing Exchange 332 Protocol for use in Conjunction with the Protocol for Providing 333 the Connectionless-mode Network Service (ISO 8473)", 2002. 335 [RFC1195] - Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 336 Dual Environments", 1990. 338 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 [RFC4971] - Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 342 "Intermediate System to Intermediate System (IS-IS) Extensions 343 for Advertising Router Information", RFC 4971, July 2007 345 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 346 Ghanwani, "Routing Bridges (RBridges): Base Protocol 347 Specification", RFC 6325, July 2011. 349 [RFC6329] - Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg, 350 A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq 351 Shortest Path Bridging", RFC 6329, April 2012. 353 [clearcorrect] - D. Eastlake, M. Zhang, A. Ghanwani, A. Banerjee, V. 354 Manral, draft-ietf-trill-clear-correct-06.txt, in RFC Editor's 355 queue. 357 [FGL] - D. Eastlake, M. Zhang, P. Agarwal, R. Perlman, D. Dutt, 358 "TRILL (Transparent Interconnection of Lots of Links): Fine- 359 Grained Labeling", draft-ietf-trill-fine-labeling, in RFC 360 Editor queue. 362 [multilevel] - Perlman, R., D. Eastlake, A. Ghanwani, H. Zhai, 363 "Multilevel TRILL (Transparent Interconnection of Lots of 364 Links)", draft-perlman-trill-rbridge-multilevel, work in 365 progress. 367 7. Informative References 369 [TreeDistr] - draft-wu-trill-lsp-ext-tree-distr-opt, work in 370 progress. 372 Acknowledgements 374 The authors gratefully acknowledge the contributions and review by 375 the following: 377 tbd 379 This document was produced with raw nroff. All macros used were 380 defined in the source files. 382 Authors' Addresses 384 Donald Eastlake 385 Huawei R&D USA 386 155 Beaver Street 387 Milford, MA 01757 USA 389 Phone: +1-508-333-2270 390 Email: d3e3e3@gmail.com 392 Weiguo Hao 393 Huawei Technologies 394 101 Software Avenue, 395 Nanjing 210012, China 397 Phone: +86-25-56623144 398 Email: haoweiguo@huawei.com 400 Copyright, Disclaimer, and Additional IPR Provisions 402 Copyright (c) 2013 IETF Trust and the persons identified as the 403 document authors. All rights reserved. 405 This document is subject to BCP 78 and the IETF Trust's Legal 406 Provisions Relating to IETF Documents 407 (http://trustee.ietf.org/license-info) in effect on the date of 408 publication of this document. Please review these documents 409 carefully, as they describe your rights and restrictions with respect 410 to this document. Code Components extracted from this document must 411 include Simplified BSD License text as described in Section 4.e of 412 the Trust Legal Provisions and are provided without warranty as 413 described in the Simplified BSD License. The definitive version of 414 an IETF Document is that published by, or under the auspices of, the 415 IETF. Versions of IETF Documents that are published by third parties, 416 including those that are translated into other languages, should not 417 be considered to be definitive versions of IETF Documents. The 418 definitive version of these Legal Provisions is that published by, or 419 under the auspices of, the IETF. Versions of these Legal Provisions 420 that are published by third parties, including those that are 421 translated into other languages, should not be considered to be 422 definitive versions of these Legal Provisions. For the avoidance of 423 doubt, each Contributor to the IETF Standards Process licenses each 424 Contribution that he or she makes as part of the IETF Standards 425 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 426 language to the contrary, or terms, conditions or rights that differ 427 from or are inconsistent with the rights and licenses granted under 428 RFC 5378, shall have any effect and shall be null and void, whether 429 published or posted by such Contributor, or included with or in such 430 Contribution.