idnits 2.17.1 draft-jc-pwe3-mpls-tp-static-checking-00.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-mpls-gach-adv]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 146: '...ncoming generic label MUST be included...' RFC 2119 keyword, line 151: '...tatic PW element SHOULD be sent only a...' RFC 2119 keyword, line 197: '...erational UP, PE SHOULD send its local...' RFC 2119 keyword, line 201: '... message SHOULD additionally include...' RFC 2119 keyword, line 205: '... it SHOULD save the PW parameters in...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2012) is 4435 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 (-08) exists of draft-ietf-mpls-gach-adv-00 -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Jin 3 Internet-Draft R. Chen 4 Intended status: Standards Track ZTE 5 Expires: September 5, 2012 March 4, 2012 7 Static pseudowire configuration checking using Generic Associated 8 Channel (G-ACh) Advertisement Protocol 9 draft-jc-pwe3-mpls-tp-static-checking-00.txt 11 Abstract 13 This draft introduces a way to do static pseudowire configuration 14 checking, so as to easy the trouble shooting of static PW in MPLS-TP. 15 The idea is to use Generic Associated Channel (G-ACh) Advertisement 16 Protocol (GAP) [I-D.ietf-mpls-gach-adv] in underlying PSN Tunnel to 17 transfer PW configuration parameters, to achieve static PW 18 configuration checking. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 5, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. GAP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Message Encoding . . . . . . . . . . . . . . . . . . . . . 3 58 3.2. PE Procedure . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2.1. PE message processing . . . . . . . . . . . . . . . . . 5 60 3.2.2. PW Configuration Check Process . . . . . . . . . . . . 6 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7.1. Normative references . . . . . . . . . . . . . . . . . . . 7 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 This draft introduces a way to do static pseudowire configuration 72 checking, so as to easy the trouble shooting of static PW in MPLS-TP. 73 The idea is to use Generic Associated Channel (G-ACh) Advertisement 74 Protocol (GAP) [I-D.ietf-mpls-gach-adv] in underlying PSN Tunnel to 75 transfer PW configuration parameters, to achieve static PW 76 configuration checking. A precondition of this functionality is that 77 the underlying PSN Tunnel is already operational, and with GAP 78 enabled. 80 2. Motivation 82 The manual configuration of static PW in MPLS-TP requires configuring 83 many parameters at two PE sides, and these parameters should be 84 aligned, so as to make PW be operational. If one of the parameters 85 on the two PE mis-matching, the PW would not operate correctly. For 86 the dynamic PW, the parameters would be negotiated by signaling 87 session, and easy to find out the configuration error if PW is not 88 operational UP. But for static PW, there is no such kind of 89 signaling session, it is difficult for operators to do trouble 90 shooting, to figure out which parameters mis-match at two PE sides. 92 In order to ease the trouble shooting of static PW, this draft relies 93 on GAP running on underlying PSN Tunnel to transfer PW configuration 94 parameters, so as to check PW configuration parameters automatically 95 on each PE to figure out parameter mis-matching. 97 3. GAP Extensions 99 3.1. Message Encoding 101 A new GAP application "static PW checking" is defined in this draft. 102 The default lifetime would be 120 seconds. Two new TLV objects 103 "local static PW element" and "remote static PW element" are defined 104 for this application, see the format below. 106 0 1 2 3 107 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 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | PW Element | Reserved | Length | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | | 112 + Generalized ID FEC + 113 | | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Interface Parameters | 116 | " | 117 | " | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 |0|0| Incoming Label (0x0200) | Length | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Label | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 |0|0| Outgoing Label (0x0200) | Length | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Label | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 Figure 1 130 Local static PW element type: to be assigned by IANA. 131 Remote static PW element type: to be assigned by IANA. 133 The value of "local&remote static PW element" TLV should carry local 134 static PW configuration and remote static PW configuration 135 separately. Multiple "local&remote static PW element" TLVs could be 136 included in "static PW configuration" application data block. 138 The value of "local&remote static PW element" TLV object would 139 include: 140 1. Generalized PWid FEC (type 129) [RFC4447] along with AII Type 2 141 [RFC5003]; 142 2. Interface parameters TLV for Generalized PWid FEC defined in 143 [RFC4447]; 144 3. Incoming and outgoing generic label as defined in [RFC5036]; 146 The Generalized PWid FEC and incoming generic label MUST be included 147 in static PW element. The Incoming and outgoing will use same 148 generic label type, and the first label should be the incoming label, 149 and second label should be outgoing label. 151 The remote static PW element SHOULD be sent only along with local 152 static PW element, where the two PW elements belong to the same PW 153 Path. That means remote static PW element should not be sent 154 independently. 156 The GAP Suppress message defined in [I-D.ietf-mpls-gach-adv] is only 157 applied for one application. We implement one particular static PW 158 element suppressing by defining a new TLV, called PW Suppress TLV, to 159 indicate suppressing special PW information transmission. Multiple 160 Generalized ID FEC elements could be included in this TLV. The 161 format would be as follows: 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 |PW Suppress TLV| Reserved | Length | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | | 169 + Generalized ID FEC + 170 | | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Multiple Generalized ID FEC! | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Figure 2 177 The type of PW suppress TLV is to be assigned by IANA. The format of 178 Generalized ID FEC is defined in [RFC4447]. The C-bit, PW type in 179 Generalized ID FEC should be zero. 181 A GAP message could contain both local&remote static PW element TLV 182 and PW Suppress TLV. 184 3.2. PE Procedure 186 3.2.1. PE message processing 188 The GAP message of static PW checking application should be sent at 189 least three times within lifetime. 191 For the static PW, the parameters of one pseudowire needed would 192 include: PW Path Identifier [RFC6370], PW type, Control Work, In&Out 193 PW Label, interface parameters and etc. When constructing "static PW 194 element" TLV, all the PW parameters should be carried. 196 When a PW is configured on the PE, and corresponding PSN Tunnel is 197 operational UP, PE SHOULD send its local PW configuration information 198 through GAP with local static PW element TLV. If PE has already 199 received remote PW configuration information belong to the same PW 200 Path through "local static PW element" TLV from remote PE, the GAP 201 message SHOULD additionally include exactly the same received TLV in 202 "remote static PW element" TLV. 204 When the remote PE receives GAP message with static PW element TLV, 205 it SHOULD save the PW parameters in "local static PW element" TLV as 206 remote PW information for a period of "lifetime" which is specified 207 in the GAP message. 209 If the receiving GAP message also has "remote static PW element" TLV, 210 PE should check local PW parameters with that in "remote static PW 211 element" TLV. If the same, PE should send GAP message with PW 212 suppress TLV contained the specified PW information to peer PE. If 213 not, PE send GAP message with local PW configuration information 214 carried in "local static PW element" TLV, and the received remote PW 215 configuration information carried in "remote static PW element" TLV. 217 Whenever PE receives the GAP message with PW suppress TLV, it SHOULD 218 stop sending GAP message with specified PW information. Whenever the 219 PE updates locally PW configuration information, PE could send GAP 220 message with static PW element to update information in remote PE. 222 3.2.2. PW Configuration Check Process 224 The PE would associate a PW with Generalized PWid FEC of: 225 AGI = AGI 226 SAII = A1-{Global_ID::Node_ID::AC_ID} 227 TAII = Z9-{Global_ID::Node_ID::AC_ID} 228 and a PW with Generalized PWid FEC of: 229 AGI = AGI 230 SAII = Z9-{Global_ID::Node_ID::AC_ID} 231 TAII = A1-{Global_ID::Node_ID::AC_ID} 232 as one PW Path. When the PE has both local and remote PW parameters 233 for one PW, it should do parameter checking as follows: 234 1. Check control word, if both sides have same capability. If not, 235 an error would report. 236 2. Check PW type, if both sides have the same. If not, an error 237 would report. 238 3. Check and negotiate interface parameters as defined in [RFC4447]. 239 4. Check In&Out PW label, if local in_label equals remote out_label, 240 and local out_label equals remote in_label. If not, an error would 241 report. 243 The mechanism described in this draft could also be used as label 244 advertisement, so as to avoid out_label negotiation manually between 245 two PE, and to avoid mis-configuration. Then the static PW is 246 allowed to configure only in_label instead of both in&out label. 247 Then if the remote PE does not send the out_label, PE will not check 248 local in_label and remote out_label. If PE does not have local 249 out_label, it should use remote in_label as local out_label. 251 4. Security Considerations 253 No new security threat is introduced by the mechanism in this draft. 255 5. IANA Considerations 257 IANA is requested to allocate a new Application ID in the "G-Ach 258 Advertisement Protocol Applications and Data Types" registry. 260 A new TLV Object "Local Static PW Element" type is requested to be 261 allocated, suggested value would be 1. 263 A new TLV Object "Remote Static PW Element" type is requested to be 264 allocated, suggested value would be 2. 266 A new TLV Object "PW Suppress TLV" type is requested to be allocated, 267 suggested value would be 3. 269 6. Acknowledgements 271 The authors would like to thank Stewart Bryant for the his review and 272 contributions. 274 7. References 276 7.1. Normative references 278 [I-D.ietf-mpls-gach-adv] 279 Frost, D., Bocci, M., and S. Bryant, "MPLS Generic 280 Associated Channel (G-ACh) Advertisement Protocol", 281 draft-ietf-mpls-gach-adv-00 (work in progress), 282 January 2012. 284 7.2. Informative References 286 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 287 Heron, "Pseudowire Setup and Maintenance Using the Label 288 Distribution Protocol (LDP)", RFC 4447, April 2006. 290 [RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, 291 "Attachment Individual Identifier (AII) Types for 292 Aggregation", RFC 5003, September 2007. 294 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 295 Specification", RFC 5036, October 2007. 297 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 298 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 300 Authors' Addresses 302 Lizhong Jin 303 ZTE Corporation 304 889, Bibo Road 305 Shanghai, 201203, China 307 Email: lizhong.jin@zte.com.cn 309 Ran Chen 310 ZTE Corporation 311 No.19 East Huayuan Road 312 Beijing, 100191, China 314 Email: chen.ran@zte.com.cn