idnits 2.17.1 draft-ietf-idr-bgp-ls-sbfd-extensions-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 date (May 30, 2019) is 1793 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) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 Summary: 1 error (**), 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: December 1, 2019 K. Talaulikar 6 Cisco Systems 7 S. Aldrin 8 Google, Inc 9 J. Tantsura 10 Apstra 11 G. Mirsky 12 ZTE Corp. 13 May 30, 2019 15 BGP Link-State Extensions for Seamless BFD 16 draft-ietf-idr-bgp-ls-sbfd-extensions-00 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 December 1, 2019. 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 . . . . . . . . . . . . . . . . . 7 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: TBD (see IANA Considerations Section 5) 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. The column "IS-IS TLV/Sub-TLV" defined 227 in the registry does not require any value and should be left empty. 229 +---------------+--------------------------+----------+ 230 | Code Point | Description | Length | 231 +---------------+--------------------------+----------+ 232 | TBD | S-BFD Discriminators TLV | variable | 233 +---------------+--------------------------+----------+ 235 6. Manageability Considerations 237 This section is structured as recommended in [RFC5706]. 239 The new protocol extensions introduced in this document augment the 240 existing IGP topology information that was distributed via [RFC7752]. 241 Procedures and protocol extensions defined in this document do not 242 affect the BGP protocol operations and management other than as 243 discussed in the Manageability Considerations section of [RFC7752]. 244 Specifically, the malformed NLRIs attribute tests in the Fault 245 Management section of [RFC7752] now encompass the new TLVs for the 246 BGP-LS NLRI in this document. 248 6.1. Operational Considerations 250 No additional operation considerations are defined in this document. 252 6.2. Management Considerations 254 No additional management considerations are defined in this document. 256 7. Security Considerations 258 The new protocol extensions introduced in this document augment the 259 existing IGP topology information that was distributed via [RFC7752]. 260 Procedures and protocol extensions defined in this document do not 261 affect the BGP security model other than as discussed in the Security 262 Considerations section of [RFC7752]. More specifically the aspects 263 related to limiting the nodes and consumers with which the topology 264 information is shared via BGP-LS to trusted entities within an 265 administrative domain. 267 Advertising the S-BFD Discriminators via BGP-LS makes it possible for 268 attackers to initiate S-BFD sessions using the advertised 269 information. The vulnerabilities this poses and how to mitigate them 270 are discussed in [RFC7752]. 272 8. Acknowledgements 274 The authors would like to thank Nan Wu for his contributions to this 275 work. 277 9. References 279 9.1. Normative References 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 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 287 S. Ray, "North-Bound Distribution of Link-State and 288 Traffic Engineering (TE) Information Using BGP", RFC 7752, 289 DOI 10.17487/RFC7752, March 2016, 290 . 292 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 293 Pallagatti, "Seamless Bidirectional Forwarding Detection 294 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 295 . 297 [RFC7883] Ginsberg, L., Akiya, N., and M. Chen, "Advertising 298 Seamless Bidirectional Forwarding Detection (S-BFD) 299 Discriminators in IS-IS", RFC 7883, DOI 10.17487/RFC7883, 300 July 2016, . 302 [RFC7884] Pignataro, C., Bhatia, M., Aldrin, S., and T. Ranganath, 303 "OSPF Extensions to Advertise Seamless Bidirectional 304 Forwarding Detection (S-BFD) Target Discriminators", 305 RFC 7884, DOI 10.17487/RFC7884, July 2016, 306 . 308 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 309 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 310 May 2017, . 312 9.2. Informative References 314 [I-D.ietf-mpls-seamless-mpls] 315 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 316 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 317 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 319 [I-D.ietf-spring-segment-routing-policy] 320 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 321 bogdanov@google.com, b., and P. Mattes, "Segment Routing 322 Policy Architecture", draft-ietf-spring-segment-routing- 323 policy-03 (work in progress), May 2019. 325 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 326 Management of New Protocols and Protocol Extensions", 327 RFC 5706, DOI 10.17487/RFC5706, November 2009, 328 . 330 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 331 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 332 . 334 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 335 Decraene, B., Litkowski, S., and R. Shakir, "Segment 336 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 337 July 2018, . 339 Authors' Addresses 341 Zhenbin Li 342 Huawei 343 Huawei Bld., No.156 Beiqing Rd. 344 Beijing 100095 345 China 347 Email: lizhenbin@huawei.com 349 Shunwan Zhuang 350 Huawei 351 Huawei Bld., No.156 Beiqing Rd. 352 Beijing 100095 353 China 355 Email: zhuangshunwan@huawei.com 356 Ketan Talaulikar 357 Cisco Systems 358 India 360 Email: ketant@cisco.com 362 Sam Aldrin 363 Google, Inc 365 Email: aldrin.ietf@gmail.com 367 Jeff Tantsura 368 Apstra 370 Email: jefftant.ietf@gmail.com 372 Greg Mirsky 373 ZTE Corp. 375 Email: gregimirsky@gmail.com