idnits 2.17.1 draft-ietf-bess-bgp-vpls-control-flags-08.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 seems to lack 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? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC4761, updated by this document, for RFC5378 checks: 2003-07-22) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 18, 2019) is 1829 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 (-05) exists of draft-ietf-bess-vpls-multihoming-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group R. Singh 3 INTERNET-DRAFT K. Kompella 4 Intended Status: Proposed Standard Juniper Networks 5 Updates: 4761 (if approved) S. Palislamovic 6 Nokia 7 Expires: October 20, 2019 April 18, 2019 9 Updated processing of Control Flags for BGP VPLS 10 draft-ietf-bess-bgp-vpls-control-flags-08 12 Abstract 14 This document updates the meaning of the Control Flags field in the 15 Layer2 Info Extended Community used for BGP-VPLS NLRI as defined in 16 RFC4761. This document updates RFC4761. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright and License Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3 Updated meaning of Control Flags in the Layer2 Info Extended 60 Community . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1 Control word (C-bit) . . . . . . . . . . . . . . . . . . . . 4 62 3.2 Sequence flag (S-bit) . . . . . . . . . . . . . . . . . . . 4 63 4 Using Point-to-MultiPoint (P2MP) LSPs as transport for BGP 64 VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5 Illustrative diagram . . . . . . . . . . . . . . . . . . . . . 6 66 6 Treatment of C and S bits in multi-homing scenarios . . . . . . 7 67 6.1 Control word (C-bit) . . . . . . . . . . . . . . . . . . . . 7 68 6.2 Sequence flag (S-bit) . . . . . . . . . . . . . . . . . . . 7 69 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 70 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 71 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 9.1 Normative References . . . . . . . . . . . . . . . . . . . 8 73 9.2 Informative References . . . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 76 1 Introduction 78 "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and 79 Signaling" ([RFC4761]) describes the concepts and signaling for using 80 Border Gateway Protocol (BGP) to setup a VPLS. It specifies the BGP 81 VPLS Network Layer Reachability Information (NLRI) by which a 82 provider-edge router (PE) may require other PEs in the same VPLS to 83 include (or not) the control-word and sequencing information in VPLS 84 frames sent to this PE. 86 The use of the Control Word (CW) helps prevent mis-ordering of IPv4 87 or IPv6 Pseudo-Wire (PW) traffic over Equal Cost Multi-Path (ECMP) 88 paths or Link Aggregation Group (LAG) bundles. [RFC4385] describes 89 the format for CW that may be used over Point-to-Point PWs and over a 90 VPLS. Along with [RFC3985], the document also describes sequence 91 number usage for VPLS frames. 93 However, [RFC4761] does not specify the behavior of PEs in a mixed 94 environment where some PEs support Control Word/sequencing and others 95 do not. 97 1.1 Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in 102 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 2 Problem 107 [RFC4761] specifies the VPLS BGP NLRI by which a given PE advertises 108 the behavior expected by the multiple PEs participating in the same 109 VPLS. The NLRI indicates the VPLS label that the various PE routers, 110 which are referred to in the NLRI, should use when forwarding VPLS 111 traffic to this PE. Additionally, by using the Control Flags this PE 112 specifies whether the other PEs (in the same VPLS) should use Control 113 Word or sequenced-delivery for frames forwarded to this PE. These are 114 respectively indicated by the C and the S bits in the Control Flags 115 as specified in section 3.2.4 in [RFC4761]. 117 [RFC4761] requires that if the advertising PE sets the C and S bits, 118 the receiving PE MUST, respectively, insert control word (CW) and 119 include sequence numbers when forwarding VPLS traffic to the 120 advertising PE. 122 However, in a BGP VPLS deployment there would often be cases where a 123 PE receiving the VPLS BGP NLRI may not have the ability to insert a 124 CW or include sequencing information inside PW frames. Thus, the 125 behavior of processing CW and sequencing needs to be further 126 specified. 128 This document updates the meaning of the Control Flags in layer2 129 extended community in the BGP VPLS NLRI. It also specifies the 130 forwarding behavior for a mixed-mode environment where not every PE 131 in a VPLS has the ability or the configuration to honor the control 132 flags received from the PE advertising the BGP NLRI. 134 3 Updated meaning of Control Flags in the Layer2 Info Extended 135 Community 137 The current specification does not allow for the CW setting to be 138 negotiated. In a typical implementation, if a PE sets the C-bit, it 139 expects to receive VPLS frames with a control word, and will send 140 frames the same way. If the PEs at the two ends of a PW do not agree 141 on the setting of the C-bit, the PW does not come up. The behavior 142 is similar for the S-bit. 144 This memo updates the meaning of the C-bit and the S-bit in the 145 control flags. 147 3.1 Control word (C-bit) 149 If a PE sets the C-bit in its NLRI, it means that the PE has ability 150 to send and receive frames with a control word. If the PEs at both 151 ends of a PW set the C-bit, control words MUST be used in both 152 directions of the PW. If both PEs send a C-bit of 0, Control Words 153 MUST NOT be used on the PW. These two cases behave as before. 155 However, if the PEs at both ends of the PW do not agree on the 156 setting of the C-bit, control words MUST NOT be used in either 157 direction on that PW but the PW MUST NOT be prevented from coming up 158 due to this mismatch. So, the PW will still come up but not use 159 control word in either direction. This behavior is changed from the 160 behavior described in [RFC4761] where the PW does not come up. 162 3.2 Sequence flag (S-bit) 164 If a PE sets the S-bit in its NLRI, it means that the PE has ability 165 to set sequence numbers as listed in section 4.1 in [RFC4385] and 166 process sequence numbers as listed in section 4.2 in [RFC4385]. If 167 the PEs at both ends of a PW set the S-bit, non-zero sequence numbers 168 MUST be used in both directions of the PW. If both PEs send a S-bit 169 of 0, sequence numbers MUST NOT be used on the PW. These two cases 170 behave as before. 172 Current BGP VPLS specification does not allow for S-bit setting to be 173 negotiated either. In a typical implementation, if the PE sets the 174 S-bit in the advertised NLRI, it expects to receive VPLS frames with 175 non-zero sequence numbers, and will send outgoing frames over the PW 176 with non-zero sequence numbers. 178 This memo further specifies the expected behavior when the PEs at the 179 ends of the PW advertise differing S-bit values. If the PEs at both 180 ends of the PW do not agree on the setting of the S-bit, then the PW 181 SHOULD NOT come up. This is to avoid running into out-of-sequence 182 ordering scenarios when the multiple PEs that are enabling multi- 183 homing for a site have differing S-bit advertisements as listed in 184 section 4.2 in [RFC4385]. However, if a deployment is known to not 185 utilize multi-homing, a user-configurable way to override this 186 recommendation MAY BE provided by an implementation whereby the PW is 187 allowed to come up. In that case the PE advertising S-bit as 0 should 188 set sequence numbers in the frames as zero and the PW receiving the 189 frames should not have an expectation to receive non-zero sequence 190 numbers. 192 4 Using Point-to-MultiPoint (P2MP) LSPs as transport for BGP VPLS 194 BGP VPLS can be used over point-2-point LSPs acting as transport 195 between the VPLS PEs. Alternately, BGP VPLS may also be used over 196 P2MP Label Switched Path (LSPs) with the source of the P2MP LSP 197 rooted at the PE advertising the VPLS BGP NLRI. 199 In a network that uses P2MP LSPs as transport for a VPLS, there may 200 be some PEs that support CW while others may not. Similarly, for the 201 sequencing of VPLS frames. 203 In such a setup, a source PE that supports CW should setup two 204 different P2MP LSPs such that: 205 - One P2MP LSP will transport CW-marked frames to those PEs 206 that advertised the C-bit as 1. 207 - The other P2MP LSP will transport frames without CW to those 208 PEs that advertised C-bit as 0. 210 Using two different P2MP LSPs to deliver frames with and without 211 the CW to different PEs ensures that a P2MP root PE honors the C- 212 bit advertised by the other P2MP PEs. 214 However, the set of leaves on the two P2MP LSPs (rooted at the 215 given PE) MUST NOT contain any PEs that advertised a value for the 216 S-bit different from what the root PE itself is advertising. PEs 217 that advertised their S-bit value differently (from what the P2MP 218 root PE advertised) will not be on either of the P2MP LSPs. This 219 ensures that the P2MP root PE is sending VPLS frames only to those 220 PEs that agree on the setting of S-bit. 222 The ingress router for the P2MP LSP should send separate NLRIs for 223 the cases of using control-word and for not using control-word. 225 5 Illustrative diagram 227 ----- 228 / A1 \ 229 ---- ____CE1 | 230 / \ -------- -------- / | | 231 | A2 CE2- / \ / PE1 \ / 232 \ / \ / \___/ | \ ----- 233 ---- ---PE2 | \ 234 | | \ ----- 235 | Service Provider Network | \ / \ 236 | | CE5 A5 237 | ___ | / \ / 238 \ / \ PE4_/ ----- 239 PE3 / \ / 240 |------/ \------- ------- 241 ---- / | ---- 242 / \/ \ / \ CE = Customer Edge Device 243 | A3 CE3 --CE4 A4 | PE = Provider Edge Router 244 \ / \ / 245 ---- ---- A = Customer site n 247 Figure 1: Example of a VPLS 249 In the above topology, let there be a VPLS configured with the PEs as 250 displayed. Let PE1 be the PE under consideration that is CW enabled 251 and sequencing enabled. Let PE2 and PE3 also be CW enabled and 252 sequencing enabled. Let PE4 not be CW enabled or have the ability to 253 include sequence numbers. PE1 will advertise a VPLS BGP NLRI, 254 containing the C/S bits marked as 1. PE2 and PE3 on learning of NLRI 255 from PE1, will include the CW and non-zero sequence numbers in the 256 VPLS frames being forwarded to PE1 as listed in section 4 in 257 [RFC4385]. However, PE4 which does not have the ability to include CW 258 or include non-zero sequence numbers, will not. 260 As per [RFC4761], PE1 would have an expectation that all other PEs 261 forward CW-containing frames which have non-zero sequence numbers. 262 That expectation cannot be met by PE4 in this example. Thus, as per 263 [RFC4761], the PW between PE1 and PE4 does not come up. 265 However, this document addresses how to support the mixed-CW and 266 mixed sequencing-ability of PEs described above. PE1 will not bring 267 up the PW with PE4 due to the S-bit mismatch, unless overridden by 268 local configuration on PE1 and PE4 as specified in section 3.2. If 269 PE4 instead was to advertise a C-bit of 0 and an S-bit of 1, then 270 despite the CW mismatch the PW between PE1 and PE4 would come up. 271 Additionally PE1 would setup its data-plane such that it will strip 272 the CW only for those VPLS frames that are received from PEs that 273 have indicated their desire to receive CW marked frames. So, PE1 will 274 setup its data plane to strip the CW only for VPLs frames received 275 from PE2 and PE3 and it will expect to process PW frames containing 276 non-zero sequence numbers as listed in section 4.2 in [RFC4385]. PE1 277 will setup its data-plane to not strip the CW from frames received 278 from PE4 and it it would expect PE4 to send frames with non-zero 279 sequence numbers. All frames sent by PE4 to PE1 over the PW would 280 have a non-zero sequence number. 282 6 Treatment of C and S bits in multi-homing scenarios 284 6.1 Control word (C-bit) 286 In multi-homed environment, different PEs may effectively represent 287 the same service destination end-point. It could be assumed that the 288 end-to-end PW establishment process should follow the same rules when 289 it comes to control word requirement, meaning setting the C-bit would 290 be enforced equally toward both primary and backup designated 291 forwarders. 293 However, in the multi-homing case each PW SHOULD be evaluated 294 independently. Assuming the network topology specified in section 5, 295 there could be the case where PW between PE2 and PE1 could have CW 296 signaled via extended community and would be used in the VPLS frame, 297 while PE2 to PE4 PW would not insert the CW in the VPLS frame due to 298 C-bit mismatch. The rest of PEs multi-homing behavior should simply 299 follow the rules specified in [VPLS-MULTIHOMING]. 301 6.2 Sequence flag (S-bit) 303 In a multi-homed environment, different PEs may effectively represent 304 the same service destination end-point. In this case, the rules for 305 end-to-end PW establishment SHOULD follow the same behavior as listed 306 in section 3.2 when it comes to sequence bit requirements. Consider 307 the case described in section 5 with CE5 being multi-homed to PE4 and 308 PE1. The PW behavior is similar to the CW scenario so that the 309 insertion of S-bit evaluation SHOULD be independent per PW. However, 310 because S-bit mismatch between two end-point PEs results in no PW 311 establishment, in the case where PE4 doesn't support S-bit. So, only 312 one PW would be established, between PE1 and PE2. Thus, even though 313 CE5 is physically multi-homed, due to PE4's lack of support for 314 sending frames with non-zero sequence numbers there would be no PW 315 between PE2 and PE4. CE5 would effectively not be multi-homed. 317 7 Security Considerations 319 This document updates the behavior specified in [RFC4761]. The 320 security considerations listed in [RFC4761] apply. This document 321 essentially addresses BGP-VPLS behavior for PEs when the C-bit and/or 322 S-bit value advertised by a given PE are different from what another 323 PE in the VPLS is advertising. Any bit-flipping media errors leading 324 to causing this mismatch of C/S bits between PEs do not adversely 325 affect the availability of the PWs. Rather they cause control-words 326 to not be used or cause the NRLI-advertising PE to not expect non- 327 zero sequenced frames, for the C-bit and the S-bit respectively being 328 mismatched across PEs. This is no worse than the previous behavior 329 where any bit-flipping media errors leading to mismatch of C/S bit 330 between PEs would cause the PW to not come up. 332 8 IANA Considerations 334 This document does not make any requests from IANA. 336 9 References 338 9.1 Normative References 340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 341 Requirement Levels", BCP 14, RFC 2119, March 1997. 343 [RFC4761] Kompella, K., Y. Rekhter, Virtual Private LAN Service 344 (VPLS) Using BGP for Auto-Discovery and Signaling, 345 RFC 4761, January 2007. 347 [RFC4385] Bryant, S., Swallow G., Martini L., D. McPherson, 348 Pseudowire Emulation Edge-to-Edge (PWE3) Control Word, 349 RFC 4385, February 2006. 351 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 352 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 353 May 2017. 355 9.2 Informative References 357 [RFC3985] Bryant, S., P. Pate, Pseudo Wire Emulation 358 Edge-to-Edge (PWE3) Architecture, RFC3985, March 2005. 360 [VPLS-MULTIHOMING] Kothari, B., et al, BGP based Multi-homing in 361 Virtual Private LAN Service, 362 draft-ietf-bess-vpls-multihoming-02, September 2018. 364 Authors' Addresses 366 Ravi Singh 367 Juniper Networks 368 1133 Innovation Way 369 Sunnyvale, CA 94089 370 US 371 EMail: ravis@juniper.net 373 Kireeti Kompella 374 Juniper Networks 375 1133 Innovation Way 376 Sunnyvale, CA 94089 377 US 378 EMail: kireeti@juniper.net 380 Senad Palislamovic 381 Nokia 382 600 Mountain Avenue 383 Murray Hill, NJ 07974-0636 384 US 386 EMail: Senad.palislamovic@nokia.com