idnits 2.17.00 (12 Aug 2021) /tmp/idnits5038/draft-ietf-idr-bgp-ls-sbfd-extensions-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 : ---------------------------------------------------------------------------- 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 (November 1, 2019) is 932 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) == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing Z. Li 3 Internet-Draft S. Zhuang 4 Intended status: Standards Track Huawei 5 Expires: May 4, 2020 K. Talaulikar 6 Cisco Systems 7 S. Aldrin 8 Google, Inc 9 J. Tantsura 10 Apstra 11 G. Mirsky 12 ZTE Corp. 13 November 1, 2019 15 BGP Link-State Extensions for Seamless BFD 16 draft-ietf-idr-bgp-ls-sbfd-extensions-01 18 Abstract 20 Seamless Bidirectional Forwarding Detection (S-BFD) defines a 21 simplified mechanism to use Bidirectional Forwarding Detection (BFD) 22 with large portions of negotiation aspects eliminated, thus providing 23 benefits such as quick provisioning as well as improved control and 24 flexibility to network nodes initiating the path monitoring. The 25 link-state routing protocols (IS-IS and OSPF) have been extended to 26 advertise the Seamless BFD (S-BFD) Discriminators. 28 This draft defines extensions to the BGP Link-state address-family to 29 carry the S-BFD Discriminators information via BGP. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 35 "OPTIONAL" in this document are to be interpreted as described in BCP 36 14 [RFC2119] [RFC8174] when, and only when, they appear in all 37 capitals, as shown here. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on May 4, 2020. 56 Copyright Notice 58 Copyright (c) 2019 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 3. Problem and Requirement . . . . . . . . . . . . . . . . . . . 3 76 4. BGP-LS Extensions for S-BFD Discriminator . . . . . . . . . . 4 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 78 6. Manageability Considerations . . . . . . . . . . . . . . . . 6 79 6.1. Operational Considerations . . . . . . . . . . . . . . . 6 80 6.2. Management Considerations . . . . . . . . . . . . . . . . 6 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 85 9.2. Informative References . . . . . . . . . . . . . . . . . 8 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 88 1. Introduction 90 Seamless Bidirectional Forwarding Detection (S-BFD) [RFC7880] defines 91 a simplified mechanism to use Bidirectional Forwarding Detection 92 (BFD) [RFC5880] with large portions of negotiation aspects 93 eliminated, thus providing benefits such as quick provisioning as 94 well as improved control and flexibility to network nodes initiating 95 the path monitoring. 97 For monitoring of a service path end-to-end via S-BFD, the headend/ 98 initiator node needs to know the S-BFD Discriminator of the 99 destination/tail-end node of that service. The link-state routing 100 protocols (IS-IS, OSPF and OSPFv3) have been extended to advertise 101 the S-BFD Discriminators. With this a initiator node can learn the 102 S-BFD discriminator for all nodes within its IGP area/level or 103 optionally within the domain. With networks being divided into 104 multiple IGP domains for scaling and operational considerations, the 105 service endpoints that require end to end S-BFD monitoring often span 106 across IGP domains. 108 BGP Link-State (BGP-LS) [RFC7752] enables the collection and 109 distribution of IGP link-state topology information via BGP sessions 110 across IGP areas/levels and domains. The S-BFD discriminator(s) of a 111 node can thus be distributed along with the topology information via 112 BGP-LS across IGP domains and even across multiple Autonomous Systems 113 (AS) within an administrative domain. 115 This draft defines extensions to BGP-LS for carrying the S-BFD 116 Discriminators information. 118 2. Terminology 120 This memo makes use of the terms defined in [RFC7880]. 122 3. Problem and Requirement 124 Seamless MPLS [I-D.ietf-mpls-seamless-mpls] extends the core domain 125 and integrates aggregation and access domains into a single MPLS 126 domain. In a large network, the core and aggregation networks can be 127 organized as different ASes. Although the core and aggregation 128 networks are segmented into different ASes, an E2E LSP can be created 129 using hierarchical BGP signaled LSPs based on iBGP labeled unicast 130 within each AS, and eBGP labeled unicast to extend the LSP across AS 131 boundaries. This provides a seamless MPLS transport connectivity for 132 any two service end-points across the entire domain. In order to 133 detect failures for such end to end services and trigger faster 134 protection and/or re-routing, S-BFD MAY be used for the Service Layer 135 (e.g. for MPLS VPNs, PW, etc. ) or the Transport Layer monitoring. 136 This brings up the need for setting up S-BFD session spanning across 137 AS domains. 139 In a similar Segment Routing (SR) [RFC8402] multi-domain network, an 140 end to end SR Policy [I-D.ietf-spring-segment-routing-policy] path 141 may be provisioned between service end-points across domains either 142 via local provisioning or by a controller or signalled from a Path 143 Computation Engine (PCE). Monitoring using S-BFD can similarly be 144 setup for such a SR Policy. 146 Extending the automatic discovery of S-BFD discriminators of nodes 147 from within the IGP domain to across the administrative domain using 148 BGP-LS enables setting up of S-BFD sessions on demand across IGP 149 domains. The S-BFD discriminators for service end point nodes MAY be 150 learnt by the PCE or a controller via the BGP-LS feed that it gets 151 from across IGP domains and it can signal or provision the remote 152 S-BFD discriminator on the initiator node on demand when S-BFD 153 monitoring is required. The mechanisms for the signaling of the 154 S-BFD discriminator from the PCE/controller to the initiator node and 155 setup of the S-BFD session is outside the scope of this document. 157 Additionally, the service end-points themselves MAY also learn the 158 S-BFD discriminator of the remote nodes themselves by receiving the 159 BGP-LS feed via a route reflector (RR) or a centralized BGP Speaker 160 that is consolidating the topology information across the domains. 161 The initiator node can then itself setup the S-BFD session to the 162 remote node without a controller/PCE assistance. 164 While this document takes examples of MPLS and SR paths, the S-BFD 165 discriminator advertisement mechanism is applicable for any S-BFD 166 use-case in general. 168 4. BGP-LS Extensions for S-BFD Discriminator 170 The BGP-LS [RFC7752] specifies the Node NLRI for advertisement of 171 nodes and their attributes using the BGP-LS Attribute. The S-BFD 172 discriminators of a node are considered as its node level attribute 173 and advertised as such. 175 This document defines a new BGP-LS Attribute TLV called the S-BFD 176 Discriminators TLV and its format is as follows: 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Type | Length | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Discriminator 1 | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Discriminator 2 (Optional) | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | ... | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Discriminator n (Optional) | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Figure 1: S-BFD Discriminators TLV 194 where: 196 o Type: 1032 198 o Length: variable. Minimum of 8 octets and increments of 4 octets 199 there on for each additional discriminator 201 o Discriminators : multiples of 4 octets, each carrying a S-BFD 202 local discriminator value of the node. At least one discriminator 203 MUST be included in the TLV. 205 The S-BFD Discriminators TLV can only be added to the BGP-LS 206 Attribute associated with the Node NLRI that originates the 207 corresponding underlying IGP TLV/sub-TLV as described below. This 208 information is derived from the protocol specific advertisements as 209 below.. 211 o IS-IS, as defined by the S-BFD Discriminators sub-TLV in 212 [RFC7883]. 214 o OSPFv2/OSPFv3, as defined by the S-BFD Discriminators TLV in 215 [RFC7884]. 217 When the node is not running any of the IGPs but running a protocol 218 like BGP, then the locally provisioned S-BFD discriminators of the 219 node MAY be originated as part of the BGP-LS attribute within the 220 Node NLRI corresponding to the local node. 222 5. IANA Considerations 224 This document requests assigning code-points from the registry "BGP- 225 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 226 TLVs" based on table below which reflects the values assigned via the 227 early allocation process. The column "IS-IS TLV/Sub-TLV" defined in 228 the registry does not require any value and should be left empty. 230 +---------------+--------------------------+----------+ 231 | Code Point | Description | Length | 232 +---------------+--------------------------+----------+ 233 | 1032 | S-BFD Discriminators TLV | variable | 234 +---------------+--------------------------+----------+ 236 6. Manageability Considerations 238 This section is structured as recommended in [RFC5706]. 240 The new protocol extensions introduced in this document augment the 241 existing IGP topology information that was distributed via [RFC7752]. 242 Procedures and protocol extensions defined in this document do not 243 affect the BGP protocol operations and management other than as 244 discussed in the Manageability Considerations section of [RFC7752]. 245 Specifically, the malformed NLRIs attribute tests in the Fault 246 Management section of [RFC7752] now encompass the new TLVs for the 247 BGP-LS NLRI in this document. 249 6.1. Operational Considerations 251 No additional operation considerations are defined in this document. 253 6.2. Management Considerations 255 No additional management considerations are defined in this document. 257 7. Security Considerations 259 The new protocol extensions introduced in this document augment the 260 existing IGP topology information that was distributed via [RFC7752]. 261 Procedures and protocol extensions defined in this document do not 262 affect the BGP security model other than as discussed in the Security 263 Considerations section of [RFC7752]. More specifically the aspects 264 related to limiting the nodes and consumers with which the topology 265 information is shared via BGP-LS to trusted entities within an 266 administrative domain. 268 Advertising the S-BFD Discriminators via BGP-LS makes it possible for 269 attackers to initiate S-BFD sessions using the advertised 270 information. The vulnerabilities this poses and how to mitigate them 271 are discussed in [RFC7752]. 273 8. Acknowledgements 275 The authors would like to thank Nan Wu for his contributions to this 276 work. 278 9. References 280 9.1. Normative References 282 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 283 Requirement Levels", BCP 14, RFC 2119, 284 DOI 10.17487/RFC2119, March 1997, 285 . 287 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 288 S. Ray, "North-Bound Distribution of Link-State and 289 Traffic Engineering (TE) Information Using BGP", RFC 7752, 290 DOI 10.17487/RFC7752, March 2016, 291 . 293 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 294 Pallagatti, "Seamless Bidirectional Forwarding Detection 295 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 296 . 298 [RFC7883] Ginsberg, L., Akiya, N., and M. Chen, "Advertising 299 Seamless Bidirectional Forwarding Detection (S-BFD) 300 Discriminators in IS-IS", RFC 7883, DOI 10.17487/RFC7883, 301 July 2016, . 303 [RFC7884] Pignataro, C., Bhatia, M., Aldrin, S., and T. Ranganath, 304 "OSPF Extensions to Advertise Seamless Bidirectional 305 Forwarding Detection (S-BFD) Target Discriminators", 306 RFC 7884, DOI 10.17487/RFC7884, July 2016, 307 . 309 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 310 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 311 May 2017, . 313 9.2. Informative References 315 [I-D.ietf-mpls-seamless-mpls] 316 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 317 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 318 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 320 [I-D.ietf-spring-segment-routing-policy] 321 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 322 P. Mattes, "Segment Routing Policy Architecture", draft- 323 ietf-spring-segment-routing-policy-03 (work in progress), 324 May 2019. 326 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 327 Management of New Protocols and Protocol Extensions", 328 RFC 5706, DOI 10.17487/RFC5706, November 2009, 329 . 331 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 332 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 333 . 335 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 336 Decraene, B., Litkowski, S., and R. Shakir, "Segment 337 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 338 July 2018, . 340 Authors' Addresses 342 Zhenbin Li 343 Huawei 344 Huawei Bld., No.156 Beiqing Rd. 345 Beijing 100095 346 China 348 Email: lizhenbin@huawei.com 350 Shunwan Zhuang 351 Huawei 352 Huawei Bld., No.156 Beiqing Rd. 353 Beijing 100095 354 China 356 Email: zhuangshunwan@huawei.com 357 Ketan Talaulikar 358 Cisco Systems 359 India 361 Email: ketant@cisco.com 363 Sam Aldrin 364 Google, Inc 366 Email: aldrin.ietf@gmail.com 368 Jeff Tantsura 369 Apstra 371 Email: jefftant.ietf@gmail.com 373 Greg Mirsky 374 ZTE Corp. 376 Email: gregimirsky@gmail.com