idnits 2.17.1 draft-zhuang-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-bfd-seamless-base]), 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 date (August 21, 2014) is 3536 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) == Unused Reference: 'I-D.ietf-idr-ls-distribution' is defined on line 312, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-bfd-seamless-base-02 == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-05 -- Obsolete informational reference (is this intentional?): RFC 4971 (Obsoleted by RFC 7981) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Zhuang 3 Internet-Draft Z. Li 4 Intended status: Standards Track Sam aldrin 5 Expires: February 22, 2015 Huawei Technologies 6 J. Tantsura 7 G. Mirsky 8 Ericsson 9 August 21, 2014 11 BGP Link-State Extensions for Seamless BFD 12 draft-zhuang-idr-bgp-ls-sbfd-extensions-00 14 Abstract 16 [I-D.ietf-bfd-seamless-base] defines a simplified mechanism to use 17 Bidirectional Forwarding Detection (BFD) with large portions of 18 negotiation aspects eliminated, thus providing benefits such as quick 19 provisioning as well as improved control and flexibility to network 20 nodes initiating the path monitoring. The link-state routing 21 protocols (IS-IS, OSPF and OSPFv3) have been extended to advertise 22 the Seamless BFD (S-BFD) Discriminators. 24 This draft defines extensions to the BGP Link-state address-family to 25 carry the S-BFD Discriminators information via BGP. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on February 22, 2015. 50 Copyright Notice 52 Copyright (c) 2014 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 (http://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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Problem and Requirement . . . . . . . . . . . . . . . . . . . 3 70 4. BGP-LS Extensions for S-BFD Discriminators Exchanging . . . . 3 71 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 77 9.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 [I-D.ietf-bfd-seamless-base] defines a simplified mechanism to use 83 Bidirectional Forwarding Detection (BFD) with large portions of 84 negotiation aspects eliminated, thus providing benefits such as quick 85 provisioning as well as improved control and flexibility to network 86 nodes initiating the path monitoring. 88 [I-D.ginsberg-isis-sbfd-discriminator] defines a mean of advertising 89 one or more S-BFD Discriminators using the IS-IS Router Capability 90 TLV. [I-D.bhatia-ospf-sbfd-discriminator] defines a new OSPF Router 91 Information (RI) TLV that allows OSPF routers to flood the S-BFD 92 discriminator values associated with a target network identifier. 93 This mechanism is applicable to both OSPFv2 and OSPFv3. 95 The link-state routing protocols (IS-IS, OSPF and OSPFv3) have been 96 extended to advertise the S-BFD Discriminators. But flooding based 97 propagation of the S-BFD Discriminators using IGPs is limited by the 98 perimeter of the IGP domain. For advertising the S-BFD 99 Discriminators which span across IGP domains (e.g. multiple ASes), 100 the Border Gateway Protocol (BGP) is better suited as its propagation 101 perimeter is not limited like the IGPs. 103 This draft defines extensions to the BGP Link-state address-family to 104 carry the S-BFD Discriminators information via BGP. 106 2. Terminology 108 This memo makes use of the terms defined in [I-D.ietf-bfd-seamless- 109 base]. 111 3. Problem and Requirement 113 Seamless MPLS [I-D.ietf-mpls-seamless-mpls] extends the core domain 114 and integrates aggregation and access domains into a single MPLS 115 domain. In a large network, the core and aggregation networks can be 116 organized as different autonomous systems. Although the core and 117 aggregation networks are segmented into different autonomous systems, 118 but an E2E LSP will be created using hierarchical-labeled BGP LSPs 119 based on iBGP-labeled unicast within each AS, and eBGP-labeled 120 unicast to extend the LSP across AS boundaries. Meanwhile, the 121 customer will see only two service-end points in the Seamless MPLS 122 network. In order to detect the possible failure quickly and protect 123 the network/trigger re-routing, BFD MAY be used for the Service Layer 124 (e.g. for MPLS VPNs, PW ) and the Transport Layer, so the need arises 125 that the BFD session has to span across AS domain. 127 The link-state routing protocols (IS-IS, OSPF and OSPFv3) have been 128 extended to advertise the S-BFD Discriminators. But flooding based 129 propagation of the S-BFD Discriminators using IGPs is limited by the 130 perimeter of the IGP domain. For advertising the S-BFD 131 Discriminators which span across IGP domains (e.g. multiple ASes), 132 the Border Gateway Protocol (BGP) is better suited as its propagation 133 perimeter is not limited like the IGPs. This draft defines 134 extensions requirement to the BGP Link-state address-family to carry 135 the S-BFD Discriminators information via BGP. 137 4. BGP-LS Extensions for S-BFD Discriminators Exchanging 139 The BGP-LS NLRI can be a node NLRI, a link NLRI or a prefix NLRI. 140 The corresponding BGP-LS attribute is a node attribute, a link 141 attribute or a prefix attribute. BGP-LS [I-D.ietf-idr-ls- 142 distribution] defines the TLVs that map link-state information to 143 BGP-LS NLRI and BGP-LS attribute. This document adds additional BGP- 144 LS attribute TLVs to encode the S-BFD Discriminators information. 146 [I-D.ginsberg-isis-sbfd-discriminator] defines the following TLVs to 147 encode the S-BFD Discriminators information. 149 The ISIS Router CAPABILITY TLV as defined in [RFC4971] will be used 150 to advertise S-BFD discriminators. A new Sub-TLV is defined as 151 described below. S-BFD Discriminators Sub-TLV is formatted as 152 specified in [RFC5305]. 154 No. of octets 155 +-----------------------------+ 156 | Type (to be assigned by | 1 157 | IANA - suggested value 19) | 158 +-----------------------------+ 159 | Length (multiple of 4) | 1 160 +-----------------------------+ 161 | Discriminator Value(s) | 4/Discriminator 162 : : 163 +-----------------------------+ 164 Figure 1: S-BFD Discriminators Sub-TLV 166 [I-D.bhatia-ospf-sbfd-discriminator] defines the following TLVs to 167 encode the S-BFD Discriminators information. The format of the S-BFD 168 Discriminator TLV is as follows: 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Type | Length | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Discriminator 1 | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Discriminator 2 (Optional) | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | ... | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Discriminator n (Optional) | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 Figure 2: S-BFD Discriminators Sub-TLV 185 Type - S-BFD Discriminator TLV Type 187 Length - Total length of the discriminator (Value field) in octets, 188 not including the optional padding. The Length is a multiple of 4 189 octets, and consequently specifies how many Discriminators are 190 included in the TLV. 192 Value - S-BFD network target discriminator value or values. 194 Routers that do not recognize the S-BFD Discriminator TLV Type MUST 195 ignore the TLV. S-BFD discriminator is associated with the BFD 196 Target Identifier type, which allows de-multiplexing to a specific 197 task or service. 199 These TLVs are mapped to BGP-LS attribute TLVs in the following way. 200 The new information in the Link-State NLRIs and attributes is encoded 201 in Type/Length/Value triplets. 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Type | Length | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 // Value (variable) // 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Figure 3: BGP-LS TLV format 212 The 2 octet Type field values are defined in Table 1. The next 2 213 octet Length field encodes length of the rest of the TLV. The Value 214 portion of the TLV is variable and is equal to the corresponding 215 Value portion of the TLV defined in [I-D.ginsberg-isis-sbfd- 216 discriminator] and [I-D.bhatia-ospf-sbfd-discriminator]. 218 The following 'Node Attribute' TLVs are defined: 220 +---------------+-------------------------+----------+----------------+ 221 | TLV Code | Description | Length | ISIS/OSPF | 222 | Point | | | TLV/Sub-TLV | 223 +---------------+-------------------------+----------+----------------+ 224 | TBD | S-BFD Discriminators | variable | TBD | 225 | ... | ... | ... | ... | 226 +---------------+-------------------------+----------+----------------+ 227 Table 1: Node Attribute TLVs 229 5. Operation 231 In an inter-as VPN network as follows, ASBR1 and ASBR2 establish a 232 BGP-LS session for exchanging S-BFD Discriminators information. 234 |-------------------| |-----------------| 235 | AS1 | | AS2 | 236 ----- | ------ | | | 237 |CE1|--- |PE1 |------| | | | 238 ----- | ------ | | | | 239 | | | S-BFD | | 240 | | | Discriminators | | 241 | | | Exchanging via | | 242 | | | BGP-LS | | 243 | -------- | <----------> | -------- ----- | ----- 244 | |----| ASBR1|--------------------| ASBR2|--|PE3|---|CE3| 245 | | -------- | | -------- ----- | ----- 246 ----- | ------ | | | 247 |CE2|--- |PE2 | | | | 248 ----- | ------ | | | 249 | | | | 250 |-------------------| |-----------------| 252 |<-----------S-BFD Connectivity Test----------->| 253 PE1/PE2 PE3 255 Step 1: ASBR1 learns all the S-BFD Discriminators information within 256 AS1 by the mean defines in [I-D.ginsberg-isis-sbfd-discriminator] or 257 [I-D.bhatia-ospf-sbfd-discriminator]. 259 Step 2: ASBR1 sends AS1's S-BFD Discriminators information to AS2's 260 ASBR2 via the BGP-LS session. 262 Step 3: ASBR2 injects the AS1's S-BFD Discriminators information 263 receiving from ASBR1 into IGP (IS-IS or OSPF or OSPFv3), then flood 264 them within the domain of the AS2 via IGP, So the nodes of AS2 can 265 learn all the S-BFD Discriminators information originating from AS1. 267 Likewise, the nodes of AS1 can learn all the S-BFD Discriminators 268 information originating from AS2. 270 At this point, we can use S-BFD Procedures defines in [I-D.ietf-bfd- 271 seamless-base] between the PEs which belong to different AS. 273 6. IANA Considerations 275 TBD. 277 7. Security Considerations 279 This document does not introduce any new security risk. 281 8. Acknowledgements 283 The authors would like to thank Nan Wu for his contributions to this 284 work. 286 9. References 288 9.1. Normative References 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, March 1997. 293 9.2. Informative References 295 [I-D.bhatia-ospf-sbfd-discriminator] 296 Bhatia, M., Ranganath, T., Pignataro, C., and S. Aldrin, 297 "OSPF extensions to advertise S-BFD Target Discriminator", 298 draft-bhatia-ospf-sbfd-discriminator-00 (work in 299 progress), May 2014. 301 [I-D.ginsberg-isis-sbfd-discriminator] 302 Ginsberg, L., Akiya, N., and M. Chen, "Advertising S-BFD 303 Discriminators in IS-IS", draft-ginsberg-isis-sbfd- 304 discriminator-00 (work in progress), May 2014. 306 [I-D.ietf-bfd-seamless-base] 307 Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J. 308 Networks, "Seamless Bidirectional Forwarding Detection 309 (S-BFD)", draft-ietf-bfd-seamless-base-02 (work in 310 progress), August 2014. 312 [I-D.ietf-idr-ls-distribution] 313 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 314 Ray, "North-Bound Distribution of Link-State and TE 315 Information using BGP", draft-ietf-idr-ls-distribution-05 316 (work in progress), May 2014. 318 [I-D.ietf-mpls-seamless-mpls] 319 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 320 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 321 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 323 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 324 System to Intermediate System (IS-IS) Extensions for 325 Advertising Router Information", RFC 4971, July 2007. 327 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 328 Engineering", RFC 5305, October 2008. 330 Authors' Addresses 332 Shunwan Zhuang 333 Huawei Technologies 334 Huawei Bld., No.156 Beiqing Rd. 335 Beijing 100095 336 China 338 Email: zhuangshunwan@huawei.com 340 Zhenbin Li 341 Huawei Technologies 342 Huawei Bld., No.156 Beiqing Rd. 343 Beijing 100095 344 China 346 Email: lizhenbin@huawei.com 348 Sam Aldrin 349 Huawei Technologies 350 2330 Central Expressway 351 Santa Clara CA 95051 353 Email: sam.aldrin@huawei.com 355 Jeff Tantsura 356 Ericsson 357 200 Holger Way 358 San Jose CA 95134 359 USA 361 Email: jeff.tantsura@ericsson.com 362 Greg Mirsky 363 Ericsson 364 300 Holger Way 365 San Jose CA 95134 366 USA 368 Email: gregory.mirsky@ericsson.com