idnits 2.17.1 draft-pkwok-pwe3-pw-communities-03.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 ([I-D.ietf-pwe3-dynamic-ms-pw], [RFC4447]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 20, 2012) is 4358 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) == Missing Reference: 'RFC3209' is mentioned on line 300, but not defined == Missing Reference: 'RFC3107' is mentioned on line 297, but not defined ** Obsolete undefined reference: RFC 3107 (Obsoleted by RFC 8277) == Outdated reference: A later version (-22) exists of draft-ietf-pwe3-dynamic-ms-pw-14 ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Kwok 3 Internet-Draft P. Dutta 4 Intended status: Standards Track Alcatel-Lucent 5 Expires: November 21, 2012 F. Jounay 6 France Telecom 7 May 20, 2012 9 Pseudowire Communities 10 draft-pkwok-pwe3-pw-communities-03 12 Abstract 14 [RFC4447]describes a set of procedures for Pseudowire set-up and 15 maintenance using LDP as signaling protocol. 16 [I-D.ietf-pwe3-dynamic-ms-pw] extends the mechanisms described in 17 [RFC4447] for dynamic placement of multi- segment pseudowires. 19 This document describes an extension to [RFC4447]procedures which may 20 be used to pass additional information to S-PE/T-PEs when SS-PWs or 21 MS-PWs are set-up. 23 The intention of the proposed technique is to aid in policy 24 administration, specifically during MS-PW set-up across various 25 S-PEs. The proposed method is very generic so that it can support 26 the management of various parameters or rules while setting up 27 pseudowires with minimal overhead. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in [RFC2119]. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on November 21, 2012. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. PW Communities . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Defined PW Community Types . . . . . . . . . . . . . . . . . . 6 71 3.1. PW Template Community . . . . . . . . . . . . . . . . . . . 6 72 3.1.1. PW Generic Template Community . . . . . . . . . . . . . 7 73 3.2. PW Color Community . . . . . . . . . . . . . . . . . . . . 7 74 3.2.1. PW Generic Color Community . . . . . . . . . . . . . . 7 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 80 7.2. References . . . . . . . . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 83 1. Introduction 85 A Multi-Segment PW (MS-PW) is defined as a set of two or more 86 contiguous segments that behave and function as a single point-to- 87 point PW. An MS-PW enables service providers to extend the reach of 88 PWs across multiple PSN domains. 90 To facilitate and simplify the control of dynamic MS-PW set-up across 91 S-PEs, this document proposes a grouping or "community" of PWs so 92 that PW set-up decision can also be based on the identity of the 93 group. Such a scheme is expected to significantly simplify dynamic 94 MS-PW signaling [I-D.ietf-pwe3-dynamic-ms-pw] that controls the MS-PW 95 set-up across the Switching Provider Edge (S-PE) devices. 97 MS-PW spans across multiple autonomous systems or administrative 98 domains. For security reasons, strict access control is required at 99 S-PEs through which a PW enters another administrative domain. One 100 way is for operators to define a policy at the S-PE that would match 101 the PW set-up requests based on Target Attachment Individual 102 Identifier (TAII) or Source Attachment Individual Identifier (SAII) 103 or Attachment Group Identifier (AGI) etc. Such policies can be 104 complex or very large, leading to administrative overheads or 105 configuration mistakes. Rather, operators could define several tags/ 106 colors which can be associated with individual PWs when they are 107 signaled. S-PEs can then apply PW policies based on the received 108 tags, accordingly. This example application eliminates the primary 109 motivation for a complex policy database that may result in the 110 generation of very large PW prefix-based filter rules. A smaller 111 policy database such as this also requires less maintenance, so 112 shortening or eliminating out-of-band maintenance delays. 114 Another application of PW policies is in underlying transport 115 applications. Each S-PE independently chooses a unidirectional PSN 116 tunnel to map a set of PW segments to their next S-PE or T-PE. Such 117 PSN Tunnels could be Label Distribution Protocol (LDP) [RFC5036] or 118 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) [RFC3209] 119 or Labeled BGP [RFC3107] based LSPs. There is currently no signaling 120 support in [I-D.ietf-pwe3-dynamic-ms-pw] to signal a preference for 121 the type of PSN tunnel to bind a PW to at the S-PEs when multiple 122 tunnel types are available. For example, LDP can be preferred over 123 BGP tunnels when both forms of tunnels are available at an S-PE. 124 Secondly, it is also possible that only a specific RSVP tunnel or 125 class of RSVP tunnels based in Admin Groups is preferable to provide 126 a traffic class or QoS treatment, or protection capability, and some 127 form of control is required that LSPs are correctly used by S-PEs. 128 One possible way is to manually configure filter rules by PW ID or 129 AGI/SAII/TAII, but such rules can create significant maintenance 130 overhead and be prone to configuration errors. Further, signaling 131 each of the various types of PSN tunnel selection criteria/ 132 preferences in PW set-up messages adds significant burden to LDP 133 label mapping procedures. 135 In Dynamic MS-PW, a T-PE or S-PE may need to choose one next-hop from 136 several Equal Cost Multi-Path (ECMP) next-hops provided by best 137 matching PW Route. One way to do ECMP selection is to apply some 138 form of hash function on AGI/SAII/TAII of the PW but that strictly 139 limits the MS-PW addressing schemes in order to get proper load 140 distribution of MS-PWs across all next-hops. Operators need a 141 predictable way for load balancing MS-PW across ECMP next-hops which 142 is independent of MS-PW addressing schemes. 144 To address such policy management issues, this draft proposes a very 145 simple solution that allows minimal manual intervention and 146 configuration with no overhead in PW signaling. It introduces a 147 concept of "PW Communities" that can be thought of as templates 148 provisioned at a S-PE/T-PE, based on which of a certain set of rules 149 are applied to all PWs that are tagged as belonging to same 150 community. 152 Note that PW Community is different from PW Grouping (as defined 153 using PW Group ID) defined in [RFC4447]]. PW Grouping is associated 154 with binding of a set of PWs to a common event group for reduced 155 signaling of various intensive events such as Label withdraw or PW 156 Status Notification etc. However, PW Communities can be thought of a 157 grouping of PWs from policy management perspective. It is not 158 necessary that PW Grouping and PW Communities associated with a PW be 159 correlated. 161 2. PW Communities 163 The PW Communities is an OPTIONAL TLV defined as follows which is in 164 the format of LDP TLV [RFC5036]. 166 0 1 2 3 167 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 |1|1| PW Communities (0x407) | Length | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | PW Community 1 | 172 +---------------------------------------------------------------+ 173 | PW Community 2 | 174 +///////////////////////////////////////////////////////////////+ 175 | PW Community N | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 U/F bits MUST be set to 1. Length is variable. Value field of the 178 TLV contains a set of "PW Communities". 180 A PW Community is defined as follows: 182 0 1 2 3 183 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Type | Sub-type | Length | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Value | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Type field indicates the specific PW Community Type. The types are 191 introduced to provide a broad classification of various PW 192 communities based on the scope of applicability. Each community type 193 further provides the flexibility to define sub-types within it. 194 Length of a PW community is variable and to be defined by Type and 195 Sub-Type associated with a PW community. 197 3. Defined PW Community Types 199 This section introduces a few PW community types and defines the 200 format of the PW Community for those types. 202 3.1. PW Template Community 204 A PW Template community (PW Community Type 0x01) can be considered as 205 a template that has a set of rules defined locally by a T-PE or S-PE. 206 Each T-PE or S-PE can define its own set of rules and its upto the 207 administrative domain to maintain congruities among PW community 208 rules through which PW set-up process would follow. A LDP peer may 209 use this community to control information it accepts, prefers or 210 distributes to other peers. 212 A LDP peer receiving a PW set-up request (label mapping message) that 213 does not carry the PW Template Community MAY append a PW Template 214 Community TLV when propagating the label mapping message to next 215 S-PE/T-PE. 217 A LDP peer receiving a PW set-up request with PW Template Community 218 MAY modify the PW community according to local policy while 219 propagating the request to the next-hop. Following sub-types of PW 220 Template Community are defined in this document. 222 3.1.1. PW Generic Template Community 224 PW Generic Template Community is defined as sub-type 0x1 of the PW 225 Template Community. The length field is 4 octets and contains a 32 226 bit generic identifier. 228 0 1 2 3 229 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | 0x01 | 0x01 | Length | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Generic PW Template ID | 234 +---------------------------------------------------------------+ 236 3.2. PW Color Community 238 A PW Color community (PW Community type 0x2) can be considered as a 239 "coloring" of the PW that may be used by T-PE and S-PE in performing 240 various hash functions required during PW set-up. One such 241 application is in selection of PW signaling next-hop from multiple 242 ECMP next-hops provided by the matching PW Route. 244 3.2.1. PW Generic Color Community 246 PW Generic Color Community is defined as sub-type 0x1 of the PW Color 247 Community. The length field is 4 octets and contains a 32 bit 248 generic identifier. 250 0 1 2 3 251 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | 0x02 | 0x01 | Length | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Generic PW Color ID | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 4. IANA Considerations 260 This document proposes an OPTIONAL LDP PW Communities TLV, with a 261 proposed type of 0x407, to be allocated from the LDP TLV type 262 registry. 264 5. Security Considerations 266 This document does not impose additional security considerations to 267 what is defined in [RFC5036],[RFC4447] and 268 [I-D.ietf-pwe3-dynamic-ms-pw] 270 6. Acknowledgements 272 The authors would like to acknowledge the valuable comments and 273 suggestions from Mathew Bocci, Mustapha Aissaoui and Wim Henderickx. 275 7. References 277 7.1. Normative References 279 [I-D.ietf-pwe3-dynamic-ms-pw] 280 Martini, L., Bocci, M., and F. Balus, "Dynamic Placement 281 of Multi Segment Pseudowires", 282 draft-ietf-pwe3-dynamic-ms-pw-14 (work in progress), 283 July 2011. 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, March 1997. 288 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 289 Heron, "Pseudowire Setup and Maintenance Using the Label 290 Distribution Protocol (LDP)", RFC 4447, April 2006. 292 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 293 Specification", RFC 5036, October 2007. 295 7.2. References 297 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 298 BGP-4", RFC 3107, May 2001. 300 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 301 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 302 Tunnels", RFC 3209, December 2001. 304 Authors' Addresses 306 Paul Kwok 307 Alcatel-Lucent 308 701 E Middlefield Road 309 Mountain View, CA 94043 310 USA 312 Email: paul.kwok@alcatel-lucent.com 314 Pranjal Kumar Dutta 315 Alcatel-Lucent 316 701 E Middlefield Road 317 Mountain View, CA 94043 318 USA 320 Email: pranjal.dutta@alcatel-lucent.com 322 Frederic Jounay 323 France Telecom 324 2, avenue Pierre-Marzin 325 22307 Lannion Cidex, 326 France 328 Email: frederic.jounay@orange-ftgroup.com