idnits 2.17.1 draft-ietf-bess-fat-pw-bgp-04.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 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 2, 2018) is 2244 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: 'RFC8126' is defined on line 316, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT K. Patel 3 Intended Status: Standard Track Arrcus 4 Updates: 4761 S. Boutros 5 VMware 6 J. Liste 7 Cisco 8 B. Wen 9 Comcast 10 J. Rabadan 11 Nokia 13 Expires: September 3, 2018 March 2, 2018 15 Extensions to BGP Signaled Pseudowires to support Flow-Aware Transport 16 Labels 17 draft-ietf-bess-fat-pw-bgp-04 19 Abstract 21 This draft defines protocol extensions required to synchronize flow 22 label states among Provider Edges PE(s) when using the BGP-based 23 signaling procedures. These protocol extensions are equally 24 applicable to point-to-point Layer2 Virtual Private Networks 25 (L2VPNs). This draft updates RFC 4761 by defining new flags in the 26 Control Flags field of the Layer2 Info Extended Community. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as 36 Internet-Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/1id-abstracts.html 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 Copyright and License Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1 Requirements Language . . . . . . . . . . . . . . . . . . . 4 68 2. Modifications to Layer2 Info Extended Community . . . . . . . . 5 69 3. Signaling the Presence of the Flow Label . . . . . . . . . . . 6 70 4 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1 Introduction 81 The mechanism described in [RFC6391] uses an additional label (Flow 82 Label) in the MPLS label stack to allow Label Switch Routers to 83 balance flows within Pseudowires at a finer granularity than the 84 individual Pseudowires across the Equal Cost Multiple Paths (ECMPs) 85 that exists within the Packet Switched Network (PSN). 87 Furthermore, [RFC6391] defines the LDP protocol extensions required 88 to synchronize the flow label states between the ingress and egress 89 PEs when using the signaling procedures defined in the [RFC8077]. 91 A pseudowire (PW) [RFC3985] is transported over one single network 92 path, even if Equal Cost Multiple Paths (ECMPs) exist between the 93 ingress and egress PW provider edge (PE) equipment. This is required 94 to preserve the characteristics of the emulated service. 96 This draft introduces an optional mode of operation allowing to 97 transport a PW over ECMPs, for example when the use of these is known 98 to be beneficial to the operation of the PW. This specification uses 99 the principles defined in [RFC6391], and augments the BGP-signaling 100 procedures of [RFC4761] and [RFC6624]. The use of a single path to 101 preserve the packet delivery order remains the default mode of 102 operation of a PW, and is described in [RFC4385] and [RFC4928]. 104 High bandwidth Ethernet-based services are a prime example that 105 benefits from the ability to load-balance flows in a PW over multiple 106 PSN paths. In general, load-balancing is applicable when the PW 107 attachment circuit bandwidth and PSN core link bandwidth are of same 108 order of magnitude. 110 To achieve the load-balancing goal, [RFC6391] introduces the notion 111 of an additional Label Stack Entry (LSE) (Flow label) located at the 112 bottom of the stack (right after PW LSE). Label Switching Routers 113 (LSRs) commonly generate a hash of the label stack in order to 114 discriminate and distribute flows over available ECMPs. The presence 115 of the Flow label (closely associated to a flow determined by the 116 ingress PE) will normally provide the greatest entropy. 118 Furthermore, following the procedures for Inter-AS scenarios 119 described in [RFC4761] section 3.4, the Flow label should never be 120 handled by the ASBRs, only the terminating PEs on each AS will be 121 responsible for popping or pushing this label. This is equally 122 applicable to Method B [RFC4761] section 3.4.2 where ASBRs are 123 responsible for swapping the PW label as traffic traverses from ASBR 124 to PE and ASBR to ASBR directions. Therefore, the Flow label will 125 remain untouched across AS boundaries. 127 1.1 Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 2. Modifications to Layer2 Info Extended Community 135 The Layer2 Info Extended Community is used to signal control 136 information about the pseudowires to be setup. The extended community 137 format is described in [RFC4761]. The format of this extended 138 community is described as: 140 +------------------------------------+ 141 | Extended community type (2 octets) | 142 +------------------------------------+ 143 | Encaps Type (1 octet) | 144 +------------------------------------+ 145 | Control Flags (1 octet) | 146 +------------------------------------+ 147 | Layer-2 MTU (2 octet) | 148 +------------------------------------+ 149 | Reserved (2 octets) | 150 +------------------------------------+ 152 Figure 1: Layer2 Info Extended Community 154 Control Flags: 156 This field contains bit flags relating to the control information 157 about pseudowires. This field is augmented with a definition of 2 new 158 flags field. 160 0 1 2 3 4 5 6 7 161 +-+-+-+-+-+-+-+-+ 162 |Z|Z|Z|Z|T|R|C|S| (Z = MUST Be Zero) 163 +-+-+-+-+-+-+-+-+ 165 Figure 2: Control Flags Bit Vector 167 With reference to the Control Flags Bit Vector, the following bits in 168 the Control Flags are defined; the remaining bits, designated Z, MUST 169 be set to zero when sending and MUST be ignored when receiving this 170 Extended Community. 172 T When the bit value is 1, the PE announce the ability 173 to send a Pseudowire packet that includes a flow label. 174 When the bit value is 0, the PE is indicating that it will 175 not send a Pseudowire packet containing a flow label. 177 R When the bit value is 1, the PE is able to receive a 178 Pseudowire packet with a flow label present. When the bit 179 value is 0, the PE is unable to receive a Pseudowire packet 180 with the flow label present. 182 C Defined in [RFC4761]. 184 S Defined in [RFC4761]. 186 3. Signaling the Presence of the Flow Label 188 As part of the Pseudowire signaling procedures described in 189 [RFC4761], a Layer2 Info Extended Community is advertised in the VPLS 190 BGP NLRI. 192 A PE that wishes to send a flow label in a Pseudowire packet MUST 193 include in its VPLS BGP NLRI a Layer2 Info Extended Community using 194 Control Flags field with T = 1. 196 A PE that is willing to receive a flow label in a Pseudowire packet 197 MUST include in its VPLS BGP NLRI a Layer2 Info Extended Community 198 using Control Flags field with R = 1. 200 A PE that receives a VPLS BGP NLRI containing a Layer2 Info Extended 201 Community with R = 0 MUST NOT include a flow label in the Pseudowire 202 packet. 204 Therefore, a PE sending a Control Flags field with T = 1 and 205 receiving a Control Flags field with R = 1 MUST include a flow label 206 in the Pseudowire packet. Under all other combinations, a PE MUST 207 NOT include a flow label in the Pseudowire packet. 209 A PE MAY support the configuration of the flow label (T and R bits) 210 on a per-service (e.g., VPLS VFI) basis. Furthermore, it is also 211 possible that on a given service, PEs may not share the same flow 212 label settings. The presence of a flow label is therefore determined 213 on a per-peer basis and according to the local and remote T and R bit 214 values. For example, a PE part of a VPLS and with a local T = 1, 215 must only transmit traffic with a flow label to those peers that 216 signaled R = 1. And if the same PE has local R = 1, it must only 217 expect to receive traffic with a flow label from peers with T = 1. 218 Any other traffic must not have a flow label. A PE expecting to 219 receive traffic from a remote peer with a flow label MAY drop traffic 220 that has no flow label. A PE expecting to receive traffic from a 221 remote peer with no flow label MAY drop traffic that has flow label. 223 Modification of flow label settings may impact traffic over a PW as 224 these could trigger changes in the PEs data-plane programming (i.e. 225 imposition / disposition of flow label). This is an implementation 226 specific behavior and outside the scope of this draft. 228 The signaling procedures in [RFC4761] state that the unspecified bits 229 in the Control Flags field (bits 0-5) MUST be set to zero when 230 sending and MUST be ignored when receiving. The signaling procedure 231 described here is therefore backwards compatible with existing 232 implementations. A PE not supporting the extensions described in 233 this draft will always advertise a value of ZERO in the position 234 assigned by this draft to the R bit and therefore a flow label will 235 never be included in a packet sent to it by one of its peers. 236 Similarly, it will always advertise a value of ZERO in the position 237 assigned by this draft to the T bit and therefore a peer will know 238 that a flow label will never be included in a packet sent by it. 240 Note that what is signaled is the desire to include the flow LSE in 241 the label stack. The value of the flow label is a local matter for 242 the ingress PE, and the label value itself is not signaled. 244 4 Acknowledgements 246 The authors would like to thank Bertrand Duvivier and John Drake for 247 their review and comments. 249 5 Contributors 251 In addition to the authors listed above, the following individuals 252 also contributed to this document: 254 Eric Lent 256 John Brzozowski 258 Steven Cotter 260 6. IANA Considerations 262 Although [RFC4761] defined a Control Flags Bit Vector as part of the 263 Layer2 Info Extended Community, it did not ask for the creation of a 264 registry. 266 This document requests that IANA creates a registry for this bit 267 vector and that it be called the "Layer2 Info Extended Community 268 Control Flags Bit Vector" registry. 270 This registry should be created here: 272 https://www.iana.org/assignments/bgp-extended-communities/bgp- 273 extended-communities.xhtml. 275 Considering [RFC4761] and this document, the initial registry is as 276 follows: 278 Value Name Reference 279 ----- -------------------------------- -------------- 280 S Sequenced delivery of frames RFC4761 281 C Presence of a Control Word RFC4761 282 T Request to send a flow label This document 283 R Ability to receive a flow label This document 285 As per [RFC4761] and this document, the remaining bits are 286 unassigned, and MUST be set to zero when sending and MUST be ignored 287 when receiving the Layer2 Info Extended Community. 289 7. Security Considerations 291 This extension to BGP does not change the underlying security issues 292 inherent in the existing [RFC4271] and [RFC4761]. 294 8. References 296 8.1. Normative References 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 300 1997, . 302 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 303 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, 304 January 2006, . 306 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 307 LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 308 4761, DOI 10.17487/RFC4761, January 2007, . 311 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 312 Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over 313 an MPLS Packet Switched Network", RFC 6391, DOI 10.17487/RFC6391, 314 November 2011, . 316 [RFC8126] M. Cotton, et al., "Guidelines for Writing an IANA 317 Considerations Section in RFCs", RFC 8126, DOI 10.17487/RFC6391, June 318 2017, . 320 8.2. Informative References 322 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 323 Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, 324 March 2005, . 326 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 327 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over 328 an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006, 329 . 331 [RFC8077] Martini, L., and G. Heron, "Pseudowire Setup and 332 Maintenance Using the Label Distribution Protocol (LDP)", RFC 8077, 333 DOI 10.17487/RFC8077, February 2017, . 336 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 337 Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, DOI 338 10.17487/RFC4928, June 2007, . 341 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 342 Virtual Private Networks Using BGP for Auto-Discovery and Signaling", 343 RFC 6624, DOI 10.17487/RFC6624, May 2012, . 346 Authors' Addresses 348 Keyur Patel 349 Arrcus 350 Email: keyur@arrcus.com 352 Sami Boutros 353 VMware 354 Email: sboutros@vmware.com 356 Jose Liste 357 Cisco 358 Email: jliste@cisco.com 360 Bin Wen 361 Comcast 362 Email: bin_wen@cable.comcast.com 364 Jorge Rabadan 365 Nokia 366 Email: jorge.rabadan@nokia.com