idnits 2.17.1 draft-ietf-bess-bgp-vpls-control-flags-02.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If a PE sets the C-bit in its NLRI, it means that the PE has ability to send and receive frames with a control word. If the PEs at both ends of a PW set the C-bit, control words MUST be used in both directions of the PW. If both PEs send a C-bit of 0, control words MUST not be used on the PW. These two cases behave as before. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: However, if the PEs don't agree on the setting of the C-bit, control words MUST not be used on that PW but the PW MUST NOT be prevented from coming up due to this mismatch. So, the PW MUST still come up. This behavior is new; the old behavior was that the PW doesn't come up. -- The document date (January 9, 2017) is 2656 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) ** Downref: Normative reference to an Informational RFC: RFC 3985 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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 S. Palislamovic 6 Alcatel-Lucent 7 Expires: July 13, 2017 January 9, 2017 9 Updated processing of control flags for BGP VPLS 10 draft-ietf-bess-bgp-vpls-control-flags-02 12 Abstract 14 This document updates the meaning of the "control flags" fields 15 inside the "layer2 info extended community" used for BGP-VPLS NLRI. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright and License Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3 Updated meaning of control flags in the layer2 info extended 59 community . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1 Control word (C-bit) . . . . . . . . . . . . . . . . . . . . 4 61 3.2 Sequence flag (S-bit) . . . . . . . . . . . . . . . . . . . 4 62 4 Using p2mp LSP as transport for BGP VPLS . . . . . . . . . . . 5 63 5. Treatment of C and S bits in multi-homing scenarios . . . . . 5 64 5.1 Control word (C-bit) . . . . . . . . . . . . . . . . . . . . 5 65 5.2 Sequence flag (S-bit) . . . . . . . . . . . . . . . . . . . 6 66 6 Illustrative diagram . . . . . . . . . . . . . . . . . . . . . 6 67 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 68 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 69 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 9.1 Normative References . . . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1 Introduction 75 [RFC4761] describes the concepts and signaling for using BGP to setup 76 a VPLS. It specifies the BGP VPLS NLRI that a PE may require other 77 PEs in the same VPLS to include (or not) control-word and sequencing 78 information in VPLS frames sent to this PE. 80 The use of control word (CW) helps prevent mis-ordering of IPv4 or 81 IPv6 PW traffic over ECMP-paths/LAG-bundles. [RFC4385] describes the 82 format for control-word that may be used over point-2-point PWs and 83 over a VPLS. It along with [RFC3985] also describes sequencing of 84 frames. 86 However, [RFC4761] does not specify the behavior of PEs in a mixed 87 environment where some PEs support control-word/sequencing and others 88 do not. 90 1.1 Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 2 Problem 98 [RFC4761] specifies the use of a VPLS BGP NLRI by which a given PE 99 advertises the required behavior off multiple PEs participating in 100 the same VPLS. The behavior required off the multiple PEs identified 101 by the NLRI indicates the VPLS label they should use in the VPLS 102 traffic being forwarded to this PE. Additionally, by using the 103 "control flags" this PE specifies whether the other PEs (in the same 104 VPLS) should use control-word or sequenced-delivery for frames 105 forwarded to this PE. These are respectively indicated by the C and 106 the S bits in the "control flags" as specified in section 3.2.4 in 107 [RFC4761]. 109 [RFC4761] requires that if the advertising PE sets the C and S bits, 110 the receiving PE MUST honor the same by inserting control word (CW) 111 and by including sequence numbers respectively. 113 However, in a BGP VPLS deployment there would often be cases where a 114 PE receiving the VPLS BGP NLRI may not have the ability to insert a 115 CW or include sequencing information inside PW frames. Thus, the 116 behavior of BGP VPLS needs to be further specified. 118 This document updates the meaning of the control flags in layer2 119 extended community in the BGP VPLS NLRI and specifies the resulting 120 forwarding behavior for a mixed mode environment where not every PE 121 in a VPLS has the ability or the configuration to honor the control 122 flags received from the PE advertising the BGP NLRI. 124 3 Updated meaning of control flags in the layer2 info extended 125 community 127 Current specification does not allow for the CW setting to be 128 negotiated. Rather, if a PE sets the C-bit, it expects to receive 129 VPLS frames with a control word, and will send frames the same way. 130 If the PEs at both ends of a pseudowire do not agree on the setting 131 of the C-bit, the PW does not come up. The expected behavior is 132 similar for the S-bit. 134 This memo updates the meaning of the C-bit and the S-bit in the 135 control flags. 137 3.1 Control word (C-bit) 139 If a PE sets the C-bit in its NLRI, it means that the PE has ability 140 to send and receive frames with a control word. If the PEs at both 141 ends of a PW set the C-bit, control words MUST be used in both 142 directions of the PW. If both PEs send a C-bit of 0, control words 143 MUST not be used on the PW. These two cases behave as before. 145 However, if the PEs don't agree on the setting of the C-bit, control 146 words MUST not be used on that PW but the PW MUST NOT be prevented 147 from coming up due to this mismatch. So, the PW MUST still come up. 148 This behavior is new; the old behavior was that the PW doesn't come 149 up. 151 3.2 Sequence flag (S-bit) 153 Current BGP VPLS implementation do not allow for S-bit setting to be 154 negotiated either. If the PE sets the S-bit, it expects to receive 155 VPLS frames with sequence numbers, and will send the frames with the 156 sequence numbers as well. This memo further specifies the existing 157 behavior. If the PEs on the both ends of the PW set the S-bit, then 158 both PEs MUST include the PW sequence numbers. If the PEs at both 159 ends of the PW do not agree on the setting of the S-bit, the PW 160 SHOULD NOT come up at all. 162 4 Using p2mp LSP as transport for BGP VPLS 164 BGP VPLS can be used over point-2-point LSPs acting as transport 165 between the VPLS PEs. Alternately, BGP VPLS may also be used over 166 p2mp LSPs with the source of the p2mp LSP rooted at the PE 167 advertising the VPLS BGP NLRI. 169 In a network that uses p2mp LSPs as transport for BGP VPLS, in a 170 given VPLS there may be some PEs that support control-word while 171 others do not. Similarly, for sequencing of frames. 173 In such a setup, a source PE that supports control-word should setup 174 2 different p2mp LSPs such that: 175 - one p2mp LSP will carry CW-marked frames to those PEs that 176 advertised C-bit as 1, and 177 - the other p2mp LSP will carry frames without CW to those PEs 178 that advertised C-bit as 0. 180 However, the set of leaves on the 2 p2mp LSPs (rooted at the given 181 PE) MUST NOT contain any PEs that advertised a value for S-bit 182 different from what this PE itself is advertising. 184 Using 2 different p2mp LSPs to deliver frames with and without CW 185 to different PEs ensures that this PE honors the C-bit advertised 186 by the other PEs. 188 By not having PEs that advertised their S-bit value differently 189 (from what this PE advertised) on either of the p2mp LSPs, it is 190 ensured that this PE is sending VPLS frames only to those PEs that 191 agree on the setting of S-bit with this PE. 193 5. Treatment of C and S bits in multi-homing scenarios 195 5.1 Control word (C-bit) 197 In multi-homed environment, different PEs may effectively represent 198 the same service destination end point. It could be assumed that 199 the end-to-end PW establishment process should follow the same 200 rules when it comes to control word requirement, meaning setting 201 the C-bit would be enforced equally toward both primary and backup 202 designated forwarder together. 204 However, it is to be noted that in the multi-homing case, each PW 205 SHOULD be evaluated independently. Assuming the below specified 206 network topology, there could be the case where PW between PE2 and 207 PE1 could have control word signaled via extended community and 208 would be used in the VPLS frame, while PE2 to PE4 PW would not 209 insert the control word in the VPLS frame due to C-bit mismatch. 210 The rest of PEs multi-homing behavior should simply follow the 211 rules specified in draft-ietf-bess-vpls-multihoming-00. 213 5.2 Sequence flag (S-bit) 215 In multi-homed environment, different PEs may effectively represent 216 the same service destination end point. In this case, the rules 217 for end-to-end PW establishment SHOULD follow the same rules when 218 it comes to sequence bit requirements. Consider the case below 219 with CE5 being multi-homed to PE4 and PE1. The PW behavior is 220 similar to the C-word scenario so that the insertion of S-bit 221 evaluation SHOULD be independent per PW. However, because S-bit 222 mismatch between two end-point PEs yields in no PW establishment, 223 in the case where PE4 doesn't support S-bit, only one PW would be 224 established, between PE1 and PE2. Thus, even though CE5 is 225 physically multi-homed, due to PE4's lack of support for S-bit, and 226 no PW between PE1 and PE4, CE5 would not be multi-homed any more. 228 6 Illustrative diagram 230 ----- 231 / A1 \ 232 ---- ____CE1 | 233 / \ -------- -------- / | | 234 | A2 CE2- / \ / PE1 \ / 235 \ / \ / \___/ | \ ----- 236 ---- ---PE2 | \ 237 | | \ ----- 238 | Service Provider Network | \ / \ 239 | | CE5 A5 240 | ___ | / \ / 241 \ / \ PE4_/ ----- 242 PE3 / \ / 243 |------/ \------- ------- 244 ---- / | ---- 245 / \/ \ / \ CE = Customer Edge Device 246 | A3 CE3 --CE4 A4 | PE = Provider Edge Router 247 \ / \ / 248 ---- ---- A = Customer site n 250 Figure 1: Example of a VPLS 252 In the above topology, let there be a VPLS configured with the PEs as 253 displayed. Let PE1 be the PE under consideration that is CW enabled. 254 Let PE2 and PE3 also be CW enabled. Let PE4 not be CW enabled. PE1 255 will advertise a VPLS BGP NLRI, containing the C/S bits marked as 1. 256 PE2 and PE3 on learning of NLRI from PE1, shall include the control 257 word in VPLS frames being forwarded to PE1. However, PE4 which does 258 not have the ability to include control-word. 260 As per [RFC4761], PE1 would have an expectation that all other PEs 261 forward traffic to it by including CW. That expectation cannot be met 262 by PE4 in this example. Thus, as per [RFC4761] the PW between PE1 and 263 PE4 does not come up. 265 However, this document addresses how to support the mixed-CW 266 environment as above. PE1 will bring up the PW with PE4 despite the 267 CW mismatch. Additionally, it will setup its data-plane such that it 268 will strip the control-word only for those VPLS frames that are 269 received from PEs that are themselves indicating their desire to 270 receive CW marked frames. So, PE1 will setup its data plane to strip- 271 off the CW only for VPLs frames received from PEs PE2 and PE3. PE1 272 will setup its data plane to not strip CW from frames received from 273 PE4. 275 7 Security Considerations 277 No new security issues. 279 8 IANA Considerations 281 None. 283 9 References 285 9.1 Normative References 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, March 1997. 290 [RFC4761] Kompella, K., Y. Rekhter, Virtual Private LAN Service 291 (VPLS) Using BGP for Auto-Discovery and Signaling, 292 RFC 4761, January 2007. 294 [RFC4385] Bryant, S., Swallow G., Martini L., D. McPherson, 295 Pseudowire Emulation Edge-to-Edge (PWE3) Control Word, 296 RFC 4385, February 2006. 298 [RFC3985] Bryant, S., P. Pate, Pseudo Wire Emulation 299 Edge-to-Edge (PWE3) Architecture, RFC3985, March 2005. 301 Authors' Addresses 303 Ravi Singh 304 Juniper Networks 305 1194 N. Mathilda Ave. 306 Sunnyvale, CA 94089 307 US 308 EMail: ravis@juniper.net 310 Kireeti Kompella 311 Juniper Networks 312 1194 N. Mathilda Ave. 313 Sunnyvale, CA 94089 314 US 315 EMail: kireeti@juniper.net 317 Senad Palislamovic 318 Alcatel-Lucent 319 EMail: senad.palislamovic@alcatel-lucent.com