idnits 2.17.00 (12 Aug 2021) /tmp/idnits2889/draft-li-lsr-isis-link-ber-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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 119: '... this sub-TLV MUST be the packet bit...' RFC 2119 keyword, line 143: '...d for future use. It MUST be set to 0...' RFC 2119 keyword, line 144: '... when sent and MUST be ignored when ...' RFC 2119 keyword, line 154: '...he field maximum SHOULD be encoded as ...' RFC 2119 keyword, line 175: '... Implementations MUST make it possible...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2021) is 207 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 28, but not defined == Missing Reference: 'RFC8174' is mentioned on line 28, but not defined == Unused Reference: 'RFC5305' is defined on line 207, but no explicit reference was found in the text == Unused Reference: 'RFC8570' is defined on line 211, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Li 3 Internet-Draft G. Xu 4 Intended status: Informational Z. Hu 5 Expires: April 22, 2022 Z. Zhou 6 Huawei 7 October 19, 2021 9 IS-IS Extensions for Link Bit Error Ratio 10 draft-li-lsr-isis-link-ber-00 12 Abstract 14 In certain networks, network-performance criteria (e.g., latency) are 15 becoming as critical to data-path selection as other metrics. This 16 document describes extensions to IS-IS Traffic Engineering (TE) 17 Metric Extensions (RFC 8570). This draft provides the necessary IS- 18 IS extensions about the link bit error ratio (LBER) that need to be 19 used to describe network-performance. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in BCP 14 [RFC2119] 26 [RFC8174] when, and only when, they appear in all capitals, as shown 27 here. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 22, 2022. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. LBER Extensions to IS-IS . . . . . . . . . . . . . . . . . . 3 65 3. Sub-TLV Details . . . . . . . . . . . . . . . . . . . . . . . 3 66 3.1. Unidirectional Link BIT ERROR RATIO Sub-TLV . . . . . . . 3 67 4. Announcement Thresholds and Filters . . . . . . . . . . . . . 4 68 5. Announcement Suppression . . . . . . . . . . . . . . . . . . 4 69 6. Network Stability and Announcement Periodicity . . . . . . . 4 70 7. Enabling and Disabling Sub-TLVs . . . . . . . . . . . . . . . 4 71 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 4 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 74 11. Security Considerations . . . . . . . . . . . . . . . . . . . 5 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 78 1. Introduction 80 In certain networks, network-performance criteria (e.g., latency) are 81 becoming as critical to data-path selection as other metrics. This 82 document describes extensions to IS-IS Traffic Engineering (TE) 83 Metric Extensions (RFC 8570). This draft provides the necessary IS- 84 IS extensions about the link bit errror ratio (LBER) that need to be 85 used to describe network-performance.A new sub-TLV is introduced for 86 IS-IS. 88 As other IS-IS TE Metric Extensions (e.g., unidirectional link loss, 89 unidirectional link delay), Unidirectional link bit error ratio 90 described in this dicument is also meant to be used as part of the 91 operation of the routing protocol to enhance Constrained Shortest 92 Path First (CSPF), or for other uses such as supplementing the data 93 used by the controller to compute the policy path. 95 2. LBER Extensions to IS-IS 97 This document registers a new IS-IS TE sub-TLV in the "Sub-TLVs for 98 TLVs 22, 23, 141, 222, and 223" registry. This new sub-TLV provides 99 ways to distribute LBER. 101 This document registers a sub-TLV: 103 Type Description 104 ---------------------------------------------------- 105 TBD Unidirectional Link BIT ERROR RATIO 107 Figure 1 109 The new sub-TLV include a bit called the Anomalous (or "A") bit. 110 When the A bit is clear (or when the sub-TLV does not include an A 111 bit), the sub-TLV describes steady-state link performance. 113 3. Sub-TLV Details 115 3.1. Unidirectional Link BIT ERROR RATIO Sub-TLV 117 This sub-TLV advertises the bit error ratio between two directly 118 connected IS-IS neighbors. The link bit error ratio advertised by 119 this sub-TLV MUST be the packet bit error from the local neighbor to 120 the remote neighbor (i.e., the forward-path loss). The format of 121 this sub-TLV is shown in the following diagram: 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Type | Length | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+--+ 127 |A| RESERVED | Link Bit Error Ratio | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+--+ 130 Figure 2: Unidirectional Link BIT ERROR RATIO Sub-TLV for the IS-IS 131 extension 133 Type: TBD (suggested value 40) is to be assigned by IANA. 135 Length: 4. 137 A bit: This field represents the Anomalous (A) bit. The A bit is set 138 when the measured value of this parameter exceeds its configured 139 maximum threshold. The A bit is cleared when the measured value 140 falls below its configured reuse threshold. If the A bit is cleared, 141 the sub-TLV represents steady-state link performance. 143 RESERVED: This field is reserved for future use. It MUST be set to 0 144 when sent and MUST be ignored when received. 146 Link Bit Error Ratio: This 24-bit field carries Link Bit Error Ratio 147 as a percentage of the total traffic sent over a configurable 148 interval. The basic unit is 0.000003%, where (2^24 - 2) is 149 50.331642%. This value is the highest link bit error percentage that 150 can be expressed (the assumptions being that (1) precision is more 151 important on high-speed links than the ability to advertise link bit 152 error ratio greater than this and (2) high-speed links with over 50% 153 bit error are unusable). Therefore, measured values that are larger 154 than the field maximum SHOULD be encoded as the maximum value. 156 This sub-TLV is optional. 158 4. Announcement Thresholds and Filters 160 This document uses the same principle for announcement thresholds and 161 filters as described in RFC 8570. 163 5. Announcement Suppression 165 This document uses the same principle for announcement suppression as 166 described in RFC 8570. 168 6. Network Stability and Announcement Periodicity 170 This document uses the same principle for network stability and 171 announcement periodicity as described in RFC 8570. 173 7. Enabling and Disabling Sub-TLVs 175 Implementations MUST make it possible to enable or disable each sub- 176 TLV based on configuration. 178 8. Compatibility 180 Unrecognized sub-TLVs should be silently ignored. 182 9. Acknowledgements 184 TBD. 186 10. IANA Considerations 188 This document requests that IANA allocates new sub-TLV types as 189 defined in Section 2 from the "Sub-TLVs for TLVs 22, 23, 25, 141, 190 222, and 223 (Extended IS reachability, IS Neighbor Attribute, L2 191 Bundle Member Attributes, inter-AS reachability information, MT-ISN, 192 and MT IS Neighbor Attribute TLVs)" registry as specified. 194 Value Description Reference 195 --------------------------------------------------------------- 196 TBD Unidirectional LBER This document 198 Figure 3: Unidirectional LBER 200 11. Security Considerations 202 These extensions to IS-IS do not add any new security issues to the 203 existing IGP. 205 12. References 207 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 208 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 209 2008, . 211 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 212 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 213 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 214 2019, . 216 Authors' Addresses 218 Chenxi Li 219 Huawei 220 Huawei Bld., No.156 Beiqing Rd. 221 Beijing 100095 222 China 224 Email: lichenxi1@huawei.com 226 Guoqi Xu 227 Huawei 228 Huawei Bld., No. 156 Beiqing Rd. 229 Beijing 100095 230 China 232 Email: xuguoqi@huawei.com 233 Zhibo Hu 234 Huawei 235 Huawei Bld., No.156 Beiqing Rd. 236 Beijing 100095 237 China 239 Email: huzhibo@huawei.com 241 Tianran Zhou 242 Huawei 243 Huawei Bld., No. 156 Beiqing Rd. 244 Beijing 100095 245 China 247 Email: zhoutianran@huawei.com