idnits 2.17.1 draft-cppy-grow-bmp-path-marking-tlv-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.lucente-bmp-tlv]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 has text resembling RFC 2119 boilerplate text. -- The document date (October 31, 2019) is 1640 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: Normative reference to a draft: ref. 'I-D.ietf-idr-best-external' == Outdated reference: A later version (-20) exists of draft-ietf-rtgwg-bgp-pic-10 ** Downref: Normative reference to an Informational draft: draft-ietf-rtgwg-bgp-pic (ref. 'I-D.ietf-rtgwg-bgp-pic') == Outdated reference: A later version (-12) exists of draft-lapukhov-bgp-ecmp-considerations-02 ** Downref: Normative reference to an Informational draft: draft-lapukhov-bgp-ecmp-considerations (ref. 'I-D.lapukhov-bgp-ecmp-considerations') Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Cardona 3 Internet-Draft P. Lucente 4 Intended status: Standards Track NTT 5 Expires: May 3, 2020 P. Francois 6 INSA 7 Y. Gu 8 Huawei 9 T. Graf 10 Swisscom 11 October 31, 2019 13 BMP Extension for Path Marking TLV 14 draft-cppy-grow-bmp-path-marking-tlv-01 16 Abstract 18 The BGP Monitoring Protocol (BMP) provides an interface for obtaining 19 BGP Path information. BGP Path Information is conveyed within BMP 20 Route Monitoring (RM) messages. This document proposes an extension 21 to BMP to convey the status of a BGP path after being processed by 22 the BGP best-path selection algorithm. This extension makes use of 23 the TLV mechanims described in draft-lucente-bmp-tlv 24 [I-D.lucente-bmp-tlv]. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 30 "OPTIONAL" in this document are to be interpreted as described in BCP 31 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 32 appear in all capitals, as shown here. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 3, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Path Marking TLV for the RM Message . . . . . . . . . . . . . 3 69 2.1. Path Type . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.2. Reason String . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 4.1. Path Marking TLV . . . . . . . . . . . . . . . . . . . . 6 74 4.2. Path Marking TLV Reason String . . . . . . . . . . . . . 6 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 76 6. Normative References . . . . . . . . . . . . . . . . . . . . 6 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 For a given prefix, multiple paths with different path status, e.g., 82 the "best-path", "back-up path" and so on, may co-exist in the BGP 83 RIB after being processed by the local policy and the BGP decision 84 process. The path status information is currently not carried in the 85 BGP Update Message RFC4271 [RFC4271] or in the BMP Update Message 86 RFC7854 [RFC7854]. 88 External systems can use the path status for various applications. 89 The path status is commonly checked by operators when performing 90 troubleshooting. Having such status stored in a centralized system 91 can enable the development of tools facilitating this process. 92 Optimisation systems can include the path status in their process, 93 and also use the status as a validation source (since it can compare 94 the calculated state to the actual outcome of the network, such as 95 primary and backup path). As a final example, path status 96 information can complement other centralized sources of data, for 97 example, flow collectors. 99 This document defines a so-called Path Marking TLV to convey the BGP 100 path status information to the BMP server. The BMP Path Marking is 101 defined to be prepended in the BMP Route Monitoring (RM) Message. 103 2. Path Marking TLV for the RM Message 105 As per RFC4271 [RFC4271], the BMP RM Message consists of the Common 106 Header, Per-Peer Header, and the BGP Update PDU. According to draft- 107 lucente-bmp-tlv [I-D.lucente-bmp-tlv] , optional trailing data in TLV 108 format is allowed in the BMP RM Message to convey characteristics of 109 transported NLRIs (i.e. to help stateless parsing) or vendor-specific 110 data. Such TLV types are to be defined for each application. 112 To include the path status along with each BGP path, we define the 113 Path Marking TLV, shown as follows. 115 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 116 +-------------------------------+-------------------------------+ 117 | Type (2 octets) | Length (2 octets) | 118 +-------------------------------+-------------------------------+ 119 | Path Type(4 octets) | 120 +---------------------------------------------------------------+ 121 | Reason String(Variable) | 122 +---------------------------------------------------------------+ 124 Figure 1: Path Marking TLV 126 o Type = TBD1 (2 Octets): Path Marking. 128 o Length (2 Octets): indicates the length of the value field of the 129 Path Marking TLV. The value field further consists of the Path- 130 Status field and Reason String field. 132 o Path-Status (4 Octets): indicates the path status of the BGP 133 Update PDU encapsulated in the RM Message. Currently 8 types of 134 path status are defined, as shown in Table 1. 136 o Reason String (Variable): indicates the reasons/explanations of 137 the path status indicated in the Path Type field. The detailed 138 Reason String format is defined in Figure 2. 140 2.1. Path Type 142 +--------+----------------------+ 143 | Value | Path type | 144 +-------------------------------+ 145 | 0x0000 | Unknown | 146 | 0x0001 | Best path | 147 | 0x0002 | Best external path | 148 | 0x0004 | Primary path | 149 | 0x0008 | Backup path | 150 | 0x0010 | Non-installed path | 151 | 0x0020 | Unreachable next-hop | 152 +--------+----------------------+ 154 Table 1: Path Type 156 The Path type field contains a bitfield where each bit encodes a 157 specific role of the path. Multiple bits may be set when a path is 158 used in multiple roles. 160 The best-path is defined in RFC4271 [RFC4271] and the best-external 161 path is defined in draft-ietf-idr-best-external 162 [I-D.ietf-idr-best-external]. 164 A primary path is a recursive or non-recursive path that can be used 165 all the time as long as a walk starting from this path can end to an 166 adjacency draft-ietf-rtgwg-bgp-pic [I-D.ietf-rtgwg-bgp-pic]. A 167 prefix can have more than one primary path if multipath is configured 168 draft-lapukhov-bgp-ecmp-considerations 169 [I-D.lapukhov-bgp-ecmp-considerations]. A best-path is also 170 considered as a primary path. 172 A backup path is also installed in the RIB, but it is not used until 173 some or all primary paths become unreachable. Backup paths are used 174 for fast convergence in the event of failures. 176 All other reachable paths are marked as 'Non-installed'. 178 Lastly, all paths that are considered unreachable are marked as 179 'Unreachable next-hop'. Unreachable paths may be sent only in some 180 specific cases. 182 2.2. Reason String 183 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 184 +-------------------------------+-------------------------------+ 185 | Sub Type 1 (2 octets) | Length (2 octets) | 186 +-------------------------------+-------------------------------+ 187 | Non-Best Reason String(Variable) | 188 +-------------------------------+-------------------------------+ 189 | Sub Type 2 (2 octets) | Length (2 octets) | 190 +-------------------------------+-------------------------------+ 191 | Uninstalled Reason String(Variable) | 192 +-------------------------------+-------------------------------+ 193 | Sub Type 3 (2 octets) | Length (2 octets) | 194 +-------------------------------+-------------------------------+ 195 | Unreachable Reason String(Variable) | 196 +---------------------------------------------------------------+ 198 Figure 2: Reason String field 200 The reason string fields include multiple TLVs containing freeform 201 ASCII encoded messsages containing the reason of a specific path 202 status. 204 o Sub Type 1 (2 Octets) = TBD2: Non-Best Reason String. 206 o Length (2 Octets): indicates the length of the value field of the 207 Non-Best Reason String. 209 o Non-Best Reason String (Variable): includes the reason why the 210 path has a non-best status. 212 o Sub Type 2 (2 Octets) = TBD3: Uninstalled Reason String. 214 o Length (2 Octets): indicates the length of the value field of the 215 Uninstalled Reason String. 217 o Uninstalled Reason String (Variable): includes the reason why the 218 path has an uninstalled status. 220 o Sub Type 3 (2 Octets) = TBD4: Unreachable Reason String. 222 o Length (2 Octets): indicates the length of the value field of the 223 Unreachable Reason String. 225 o Unreachable Reason String (Variable): includes the reason why the 226 path has an unreachable status. 228 3. Acknowledgements 230 TBD. 232 4. IANA Considerations 234 This document requests that IANA assign the following new parameters 235 to the BMP parameters name space. 237 4.1. Path Marking TLV 239 This document defines the Path Marking TLV with Type = TBD1: Path 240 Marking (Section 2). 242 4.2. Path Marking TLV Reason String 244 This document defines three new sub types of the Reason String in the 245 Path Marking TLV (Section 2.2). 247 Sub Type 1 = TBD2: Non-Best Reason String. 249 Sub Type 2 = TBD3: Uninstalled Reason String. 251 Sub Type 3 = TBD4: Unreachable Reason String. 253 5. Security Considerations 255 It is not believed that this document adds any additional security 256 considerations. 258 6. Normative References 260 [I-D.ietf-idr-best-external] 261 Marques, P., Fernando, R., Chen, E., Mohapatra, P., and H. 262 Gredler, "Advertisement of the best external route in 263 BGP", draft-ietf-idr-best-external-05 (work in progress), 264 January 2012. 266 [I-D.ietf-rtgwg-bgp-pic] 267 Bashandy, A., Filsfils, C., and P. Mohapatra, "BGP Prefix 268 Independent Convergence", draft-ietf-rtgwg-bgp-pic-10 269 (work in progress), October 2019. 271 [I-D.lapukhov-bgp-ecmp-considerations] 272 Lapukhov, P. and J. Tantsura, "Equal-Cost Multipath 273 Considerations for BGP", draft-lapukhov-bgp-ecmp- 274 considerations-02 (work in progress), July 2019. 276 [I-D.lucente-bmp-tlv] 277 Lucente, P., Gu, Y., and H. Smit, "TLV support for BMP 278 Route Monitoring and Peer Down Messages", draft-lucente- 279 bmp-tlv-00 (work in progress), July 2019. 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, 283 DOI 10.17487/RFC2119, March 1997, 284 . 286 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 287 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 288 DOI 10.17487/RFC4271, January 2006, 289 . 291 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 292 Monitoring Protocol (BMP)", RFC 7854, 293 DOI 10.17487/RFC7854, June 2016, 294 . 296 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 297 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 298 May 2017, . 300 Authors' Addresses 302 Camilo Cardona 303 NTT 304 164-168, Carrer de Numancia 305 Barcelona 08029 306 Spain 308 Email: camilo@ntt.net 310 Paolo Lucente 311 NTT 312 Siriusdreef 70-72 313 Hoofddorp, WT 2132 314 Netherlands 316 Email: paolo@ntt.net 317 Pierre Francois 318 INSA 319 Lyon 320 France 322 Email: Pierre.Francois@insa-lyon.fr 324 Yunan Gu 325 Huawei 326 Huawei Bld., No.156 Beiqing Rd. 327 Beijing 100095 328 China 330 Email: guyunan@huawei.com 332 Thomas Graf 333 Swisscom 334 Binzring 17 335 Zurich 8045 336 Switzerland 338 Email: thomas.graf@swisscom.com