idnits 2.17.1 draft-ietf-bess-bgp-vpls-control-flags-05.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 ([RFC4761]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC4761, but the abstract doesn't seem to directly say this. It does mention RFC4761 though, so this could be OK. 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. (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 (July 2, 2018) is 2123 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: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: RFC 4761 (once approved) S. Palislamovic 6 Alcatel-Lucent 7 Expires: January 3, 2019 July 2, 2018 9 Updated processing of control flags for BGP VPLS 10 draft-ietf-bess-bgp-vpls-control-flags-05 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 as 16 defined in [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) 2013 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 p2mp LSP as transport for BGP VPLS . . . . . . . . . . . 5 64 5 Treatment of C and S bits in multi-homing scenarios . . . . . . 5 65 5.1 Control word (C-bit) . . . . . . . . . . . . . . . . . . . . 5 66 5.2 Sequence flag (S-bit) . . . . . . . . . . . . . . . . . . . 6 67 6 Illustrative diagram . . . . . . . . . . . . . . . . . . . . . 6 68 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 70 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 9.1 Normative References . . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1 Introduction 76 [RFC4761] describes the concepts and signaling for using BGP (Border 77 Gateway Protocol) to setup a VPLS (virtual private LAN service). It 78 specifies the BGP VPLS NLRI (network layer reachability information) 79 by which a PE may require other PEs in the same VPLS to include (or 80 not) control-word and sequencing information in VPLS frames sent to 81 this PE. 83 The use of control word (CW) helps prevent mis-ordering of IPv4 or 84 IPv6 PW traffic over ECMP (equal cost multi-path) paths or LAG (link 85 aggregation group) bundles. [RFC4385] describes the format for 86 control-word that may be used over point-2-point PWs (pseudowires) 87 and over a VPLS. It along with [RFC3985] also describes sequencing of 88 frames. 90 However, [RFC4761] does not specify the behavior of PEs in a mixed 91 environment where some PEs support control-word/sequencing and others 92 do not. 94 1.1 Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 2 Problem 102 [RFC4761] specifies the VPLS BGP NLRI by which a given PE advertises 103 the behavior expected from the multiple PEs participating in the same 104 VPLS. The NLRI indicates the VPLS label that the various PE routers, 105 which are referred to in the NLRI, should use when forwarding VPLS 106 traffic to this PE. Additionally, by using the "control flags" this 107 PE specifies whether the other PEs (in the same VPLS) should use 108 control-word or sequenced-delivery for frames forwarded to this PE. 109 These are respectively indicated by the C and the S bits in the 110 "control flags" as specified in section 3.2.4 in [RFC4761]. 112 [RFC4761] requires that if the advertising PE sets the C and S bits, 113 when forwarding VPLS traffic to the PE, the receiving PE MUST insert 114 control word (CW) and by including sequence numbers respectively. 116 However, in a BGP VPLS deployment there would often be cases where a 117 PE receiving the VPLS BGP NLRI may not have the ability to insert a 118 CW or include sequencing information inside PW frames. Thus, the 119 behavior of processing CW and sequencing needs to be further 120 specified. 122 This document updates the meaning of the control flags in layer2 123 extended community in the BGP VPLS NLRI. It also specifies the 124 forwarding behavior for a mixed-mode environment where not every PE 125 in a VPLS has the ability or the configuration to honor the control 126 flags received from the PE advertising the BGP NLRI. 128 3 Updated meaning of control flags in the layer2 info extended 129 community 131 Current specification does not allow for the CW setting to be 132 negotiated. Rather, if a PE sets the C-bit, it expects to receive 133 VPLS frames with a control word, and will send frames the same way. 134 If the PEs at both ends of a pseudowire do not agree on the setting 135 of the C-bit, the PW does not come up. The expected behavior is 136 similar for the S-bit. 138 This memo updates the meaning of the C-bit and the S-bit in the 139 control flags. 141 3.1 Control word (C-bit) 143 If a PE sets the C-bit in its NLRI, it means that the PE has ability 144 to send and receive frames with a control word. If the PEs at both 145 ends of a PW set the C-bit, control words MUST be used in both 146 directions of the PW. If both PEs send a C-bit of 0, control words 147 MUST not be used on the PW. These two cases behave as before. 149 However, if the PEs don't agree on the setting of the C-bit, control 150 words MUST not be used on that PW but the PW MUST NOT be prevented 151 from coming up due to this mismatch. So, the PW MUST still come up. 152 This behavior is new; the old behavior was that the PW doesn't come 153 up. 155 3.2 Sequence flag (S-bit) 157 Current BGP VPLS specification do not allow for S-bit setting to be 158 negotiated either. If the PE sets the S-bit, it expects to receive 159 VPLS frames with sequence numbers, and will send the frames with 160 sequence numbers as well. This memo further specifies the existing 161 behavior. If the PEs on the both ends of the PW set the S-bit, then 162 both PEs MUST include the PW sequence numbers. If the PEs at both 163 ends of the PW do not agree on the setting of the S-bit, the PW 164 SHOULD NOT come up at all. 166 4 Using p2mp LSP as transport for BGP VPLS 168 BGP VPLS can be used over point-2-point LSPs acting as transport 169 between the VPLS PEs. Alternately, BGP VPLS may also be used over 170 p2mp (point to multipoint) LSPs (label switched path) with the source 171 of the p2mp LSP rooted at the PE advertising the VPLS BGP NLRI. 173 In a network that uses p2mp LSPs as transport for BGP VPLS, in a 174 given VPLS there may be some PEs that support control-word while 175 others do not. Similarly, for sequencing of frames. 177 In such a setup, a source PE that supports control-word should setup 178 2 different p2mp LSPs such that: 179 - one p2mp LSP will carry CW-marked frames to those PEs that 180 advertised C-bit as 1, and 181 - the other p2mp LSP will carry frames without CW to those PEs 182 that advertised C-bit as 0. 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 However, the set of leaves on the 2 p2mp LSPs (rooted at the given 189 PE) MUST NOT contain any PEs that advertised a value for S-bit 190 different from what this PE itself is advertising. PEs that 191 advertised their S-bit value differently (from what this PE 192 advertised) will not be on either of the p2mp LSPs. It is ensured 193 that this PE is sending VPLS frames only to those PEs that agree 194 with this PE on the setting of S-bit. 196 5 Treatment of C and S bits in multi-homing scenarios 198 5.1 Control word (C-bit) 200 In multi-homed environment, different PEs may effectively represent 201 the same service destination end point. It could be assumed that 202 the end-to-end PW establishment process should follow the same 203 rules when it comes to control word requirement, meaning setting 204 the C-bit would be enforced equally toward both primary and backup 205 designated forwarder together. 207 However, in the multi-homing case each PW SHOULD be evaluated 208 independently. Assuming the below specified network topology, there 209 could be the case where PW between PE2 and PE1 could have control 210 word signaled via extended community and would be used in the VPLS 211 frame, while PE2 to PE4 PW would not insert the control word in the 212 VPLS frame due to C-bit mismatch. The rest of PEs multi-homing 213 behavior should simply follow the rules specified in draft-ietf- 214 bess-vpls-multihoming-00. 216 5.2 Sequence flag (S-bit) 218 In multi-homed environment, different PEs may effectively represent 219 the same service destination end point. In this case, the rules for 220 end-to-end PW establishment SHOULD follow the same rules when it 221 comes to sequence bit requirements. Consider the case below with 222 CE5 being multi-homed to PE4 and PE1. The PW behavior is similar 223 to the C-word scenario so that the insertion of S-bit evaluation 224 SHOULD be independent per PW. However, because S-bit mismatch 225 between two end-point PEs yields in no PW establishment, in the 226 case where PE4 doesn't support S-bit, only one PW would be 227 established, between PE1 and PE2. Thus, even though CE5 is 228 physically multi-homed, due to PE4's lack of support for S-bit, and 229 no PW between PE1 and PE4, CE5 would not be multi-homed any more. 231 6 Illustrative diagram 233 ----- 234 / A1 \ 235 ---- ____CE1 | 236 / \ -------- -------- / | | 237 | A2 CE2- / \ / PE1 \ / 238 \ / \ / \___/ | \ ----- 239 ---- ---PE2 | \ 240 | | \ ----- 241 | Service Provider Network | \ / \ 242 | | CE5 A5 243 | ___ | / \ / 244 \ / \ PE4_/ ----- 245 PE3 / \ / 246 |------/ \------- ------- 247 ---- / | ---- 248 / \/ \ / \ CE = Customer Edge Device 249 | A3 CE3 --CE4 A4 | PE = Provider Edge Router 250 \ / \ / 251 ---- ---- A = Customer site n 253 Figure 1: Example of a VPLS 255 In the above topology, let there be a VPLS configured with the PEs as 256 displayed. Let PE1 be the PE under consideration that is CW enabled. 257 Let PE2 and PE3 also be CW enabled. Let PE4 not be CW enabled. PE1 258 will advertise a VPLS BGP NLRI, containing the C/S bits marked as 1. 259 PE2 and PE3 on learning of NLRI from PE1, shall include the control 260 word in VPLS frames being forwarded to PE1. However, PE4 which does 261 not have the ability to include control-word. 263 As per [RFC4761], PE1 would have an expectation that all other PEs 264 forward traffic to it by including CW. That expectation cannot be met 265 by PE4 in this example. Thus, as per [RFC4761] the PW between PE1 and 266 PE4 does not come up. 268 However, this document addresses how to support the mixed-CW 269 environment as above. PE1 will bring up the PW with PE4 despite the 270 CW mismatch. Additionally, it will setup its data-plane such that it 271 will strip the control-word only for those VPLS frames that are 272 received from PEs that are themselves indicating their desire to 273 receive CW marked frames. So, PE1 will setup its data plane to strip- 274 off the CW only for VPLs frames received from PEs PE2 and PE3. PE1 275 will setup its data plane to not strip CW from frames received from 276 PE4. 278 7 Security Considerations 280 This document updates the behavior specified in [RFC4761]. The 281 security considerations listed in [RFC4761] apply. However, there are 282 no new security considerations due to the text of this document. 284 8 IANA Considerations 286 This document does not make any requests from IANA. 288 9 References 290 9.1 Normative References 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 [RFC4761] Kompella, K., Y. Rekhter, Virtual Private LAN Service 296 (VPLS) Using BGP for Auto-Discovery and Signaling, 297 RFC 4761, January 2007. 299 [RFC4385] Bryant, S., Swallow G., Martini L., D. McPherson, 300 Pseudowire Emulation Edge-to-Edge (PWE3) Control Word, 301 RFC 4385, February 2006. 303 [RFC3985] Bryant, S., P. Pate, Pseudo Wire Emulation 304 Edge-to-Edge (PWE3) Architecture, RFC3985, March 2005. 306 Authors' Addresses 308 Ravi Singh 309 Juniper Networks 310 1194 N. Mathilda Ave. 311 Sunnyvale, CA 94089 312 US 313 EMail: ravis@juniper.net 315 Kireeti Kompella 316 Juniper Networks 317 1194 N. Mathilda Ave. 318 Sunnyvale, CA 94089 319 US 320 EMail: kireeti@juniper.net 322 Senad Palislamovic 323 Alcatel-Lucent 324 EMail: senad.palislamovic@alcatel-lucent.com