idnits 2.17.1 draft-ietf-bess-bgp-vpls-control-flags-07.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 (March 5, 2019) is 1850 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: September 6, 2019 March 5, 2019 9 Updated processing of Control Flags for BGP VPLS 10 draft-ietf-bess-bgp-vpls-control-flags-07 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 Treatment of C and S bits in multi-homing scenarios . . . . . . 5 66 5.1 Control word (C-bit) . . . . . . . . . . . . . . . . . . . . 5 67 5.2 Sequence flag (S-bit) . . . . . . . . . . . . . . . . . . . 6 68 6 Illustrative diagram . . . . . . . . . . . . . . . . . . . . . 6 69 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 70 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 71 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 9.1 Normative References . . . . . . . . . . . . . . . . . . . 7 73 9.2 Informative References . . . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 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 PE may 82 require other PEs in the same VPLS to include (or not) the control- 83 word and sequencing information in VPLS frames sent to this PE. 85 The use of the Control Word (CW) helps prevent mis-ordering of IPv4 86 or IPv6 Psuedo-Wire (PW) traffic over Equal Cost Multi-Path (ECMP) 87 paths or Link Aggregation Group (LAG) bundles. [RFC4385] describes 88 the format for CW that may be used over Point-to-Point PWs and over a 89 VPLS. Along with [RFC3985], the document also describes sequence 90 number usage for VPLS frames. 92 However, [RFC4761] does not specify the behavior of PEs in a mixed 93 environment where some PEs support Control Word/sequencing and others 94 do not. 96 1.1 Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in 101 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 102 capitals, as shown here. 104 2 Problem 106 [RFC4761] specifies the VPLS BGP NLRI by which a given PE advertises 107 the behavior expected by the multiple PEs participating in the same 108 VPLS. The NLRI indicates the VPLS label that the various PE routers, 109 which are referred to in the NLRI, should use when forwarding VPLS 110 traffic to this PE. Additionally, by using the Control Flags this PE 111 specifies whether the other PEs (in the same VPLS) should use Control 112 Word or sequenced-delivery for frames forwarded to this PE. These are 113 respectively indicated by the C and the S bits in the Control Flags 114 as specified in section 3.2.4 in [RFC4761]. 116 [RFC4761] requires that if the advertising PE sets the C and S bits, 117 the receiving PE MUST, respectively, insert control word (CW) and 118 include sequence numbers when forwarding VPLS traffic to the 119 advertising PE. 121 However, in a BGP VPLS deployment there would often be cases where a 122 PE receiving the VPLS BGP NLRI may not have the ability to insert a 123 CW or include sequencing information inside PW frames. Thus, the 124 behavior of processing CW and sequencing needs to be further 125 specified. 127 This document updates the meaning of the Control Flags in layer2 128 extended community in the BGP VPLS NLRI. It also specifies the 129 forwarding behavior for a mixed-mode environment where not every PE 130 in a VPLS has the ability or the configuration to honor the control 131 flags received from the PE advertising the BGP NLRI. 133 3 Updated meaning of Control Flags in the Layer2 Info Extended 134 Community 136 The current specification does not allow for the CW setting to be 137 negotiated. In a typical implementation, if a PE sets the C-bit, it 138 expects to receive VPLS frames with a control word, and will send 139 frames the same way. If the PEs at the two ends of a pseudowire do 140 not agree on the setting of the C-bit, the PW does not come up. The 141 behavior is similar for the S-bit. 143 This memo updates the meaning of the C-bit and the S-bit in the 144 control flags. 146 3.1 Control word (C-bit) 148 If a PE sets the C-bit in its NLRI, it means that the PE has ability 149 to send and receive frames with a control word. If the PEs at both 150 ends of a PW set the C-bit, control words MUST be used in both 151 directions of the PW. If both PEs send a C-bit of 0, Control Words 152 MUST NOT be used on the PW. These two cases behave as before. 154 However, if the PEs don't agree on the setting of the C-bit, control 155 words MUST NOT be used in either direction on that PW but the PW MUST 156 NOT be prevented from coming up due to this mismatch. So, the PW MUST 157 still come up but not use control word in either direction. This 158 behavior is changed from the behavior described in [RFC4761] where 159 the PW does not come up. 161 3.2 Sequence flag (S-bit) 163 Current BGP VPLS specification do not allow for S-bit setting to be 164 negotiated either. In typical implementations, if the PE sets the S- 165 bit, it expects to receive VPLS frames with seqence numbers, and will 166 send outgoing frames with sequence numbers as well. This memo 167 further specifies the expected behavior. If the PEs on the both ends 168 of the PW set the S-bit, then both PEs MUST include the PW sequence 169 numbers. If the PEs at both ends of the PW do not agree on the 170 setting of the S-bit, the PW SHOULD NOT come up. 172 4 Using Point-to-MultiPoint (P2MP) LSPs as transport for BGP VPLS 174 BGP VPLS can be used over point-2-point LSPs acting as transport 175 between the VPLS PEs. Alternately, BGP VPLS may also be used over 176 P2MP Label Switched Path (LSPs) with the source of the P2MP LSP 177 rooted at the PE advertising the VPLS BGP NLRI. 179 In a network that uses P2MP LSPs as transport for a VPLS,there may be 180 some PEs that support CW while others may not. Similarly, for the 181 sequencing of VPLS frames. 183 In such a setup, a source PE that supports CW should setup two 184 different P2MP LSPs such that: 185 - One P2MP LSP will transport CW-marked frames to those PEs 186 that advertised the C-bit as 1. 187 - The other P2MP LSP will transport frames without CW to those 188 PEs that advertised C-bit as 0. 190 Using two different P2MP LSPs to deliver frames with and without 191 the CW to different PEs ensures that a P2MP root PE honors the C- 192 bit advertised by the other P2MP PEs. 194 However, the set of leaves on the two P2MP LSPs (rooted at the 195 given PE) MUST NOT contain any PEs that advertised a value for the 196 S-bit different from what the root PE itself is advertising. PEs 197 that advertised their S-bit value differently (from what the P2MP 198 root PE advertised) will not be on either of the P2MP LSPs. This 199 ensures that the P2MP root PE is sending VPLS frames only to those 200 PEs that agree on the setting of S-bit. 202 The ingress router for the P2MP LSP should send separate NLRIs for 203 the cases of using control-word and for not using control-word. 205 5 Treatment of C and S bits in multi-homing scenarios 207 5.1 Control word (C-bit) 209 In multi-homed environment, different PEs may effectively represent 210 the same service destination end-point. It could be assumed that 211 the end-to-end PW establishment process should follow the same 212 rules when it comes to control word requirement, meaning setting 213 the C-bit would be enforced equally toward both primary and backup 214 designated forwarders. 216 However, in the multi-homing case each PW SHOULD be evaluated 217 independently. Assuming the below specified network topology, there 218 could be the case where PW between PE2 and PE1 could have CW 219 signaled via extended community and would be used in the VPLS 220 frame, while PE2 to PE4 PW would not insert the CW in the VPLS 221 frame due to C-bit mismatch. The rest of PEs multi-homing behavior 222 should simply follow the rules specified in [VPLS-MULTIHOMING]. 224 5.2 Sequence flag (S-bit) 226 In multi-homed environment, different PEs may effectively represent 227 the same service destination end-point. In this case, the rules for 228 end-to-end PW establishment SHOULD follow the same behavior as 229 listed in section 3.2 when it comes to sequence bit requirements. 230 Consider the case below with CE5 being multi-homed to PE4 and PE1. 231 The PW behavior is similar to the CW scenario so that the insertion 232 of S-bit evaluation SHOULD be independent per PW. However, because 233 S-bit mismatch between two end-point PEs results in no PW 234 establishment, in the case where PE4 doesn't support S-bit, only 235 one PW would be established, between PE1 and PE2. Thus, even 236 though CE5 is physically multi-homed, due to PE4's lack of support 237 for S-bit, and no PW between PE1 and PE4, CE5 would not be multi- 238 homed. 240 6 Illustrative diagram 242 ----- 243 / A1 \ 244 ---- ____CE1 | 245 / \ -------- -------- / | | 246 | A2 CE2- / \ / PE1 \ / 247 \ / \ / \___/ | \ ----- 248 ---- ---PE2 | \ 249 | | \ ----- 250 | Service Provider Network | \ / \ 251 | | CE5 A5 252 | ___ | / \ / 253 \ / \ PE4_/ ----- 254 PE3 / \ / 255 |------/ \------- ------- 256 ---- / | ---- 257 / \/ \ / \ CE = Customer Edge Device 258 | A3 CE3 --CE4 A4 | PE = Provider Edge Router 259 \ / \ / 260 ---- ---- A = Customer site n 262 Figure 1: Example of a VPLS 264 In the above topology, let there be a VPLS configured with the PEs as 265 displayed. Let PE1 be the PE under consideration that is CW enabled. 267 Let PE2 and PE3 also be CW enabled. Let PE4 not be CW enabled. PE1 268 will advertise a VPLS BGP NLRI, containing the C/S bits marked as 1. 269 PE2 and PE3 on learning of NLRI from PE1, will include the CW in VPLS 270 frames being forwarded to PE1. However, PE4 which does not have the 271 ability to include CW, will not. 273 As per [RFC4761], PE1 would have an expectation that all other PEs 274 forward traffic to it by including CW. That expectation cannot be met 275 by PE4 in this example. Thus, as per [RFC4761], the PW between PE1 276 and PE4 does not come up. 278 However, this document addresses how to support the mixed-CW 279 environment as above. PE1 will bring up the PW with PE4 despite the 280 CW mismatch. Additionally, it will setup its data-plane such that it 281 will strip the CW only for those VPLS frames that are received from 282 PEs that have indicated their desire to receive CW marked frames. So, 283 PE1 will setup its data plane to strip the CW only for VPLs frames 284 received from PE2 and PE3. PE1 will setup its data-plane to not strip 285 the CW from frames received from PE4. 287 7 Security Considerations 289 This document updates the behavior specified in [RFC4761]. The 290 security considerations listed in [RFC4761] apply. However, there are 291 no new security considerations due to the behavior changes in this 292 document. 294 8 IANA Considerations 296 This document does not make any requests from IANA. 298 9 References 300 9.1 Normative References 302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 303 Requirement Levels", BCP 14, RFC 2119, March 1997. 305 [RFC4761] Kompella, K., Y. Rekhter, Virtual Private LAN Service 306 (VPLS) Using BGP for Auto-Discovery and Signaling, 307 RFC 4761, January 2007. 309 [RFC4385] Bryant, S., Swallow G., Martini L., D. McPherson, 310 Pseudowire Emulation Edge-to-Edge (PWE3) Control Word, 311 RFC 4385, February 2006. 313 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 314 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 315 May 2017. 317 9.2 Informative References 319 [RFC3985] Bryant, S., P. Pate, Pseudo Wire Emulation 320 Edge-to-Edge (PWE3) Architecture, RFC3985, March 2005. 322 [VPLS-MULTIHOMING] Kothari, B., et al, BGP based Multi-homing in 323 Virtual Private LAN Service, 324 draft-ietf-bess-vpls-multihoming-02, September 2018. 326 Authors' Addresses 328 Ravi Singh 329 Juniper Networks 330 1133 Innovation Way 331 Sunnyvale, CA 94089 332 US 333 EMail: ravis@juniper.net 335 Kireeti Kompella 336 Juniper Networks 337 1133 Innovation Way 338 Sunnyvale, CA 94089 339 US 340 EMail: kireeti@juniper.net 342 Senad Palislamovic 343 Nokia 344 EMail: senad@nuagenetworks.net