idnits 2.17.1 draft-ietf-pwe3-wildcard-pw-type-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 227. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 236. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 243. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 249. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 2006) is 6403 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 (ref. 'ARCH') ** Obsolete normative reference: RFC 4447 (ref. 'CONTROL') (Obsoleted by RFC 8077) -- Duplicate reference: RFC4447, mentioned in 'IANA', was also mentioned in 'CONTROL'. ** Obsolete normative reference: RFC 4447 (ref. 'IANA') (Obsoleted by RFC 8077) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini 3 Internet Draft Cisco Systems, Inc. 4 Category: Standards Track 5 Expiration Date: April 2007 6 George Swallow 7 Cisco Systems, Inc. 9 October 2006 11 Wildcard Pseudowire Type 13 draft-ietf-pwe3-wildcard-pw-type-02.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of 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 Internet- 25 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 Abstract 40 Pseudowire signaling requires that the Pseudowire Type (PW Type) be 41 identical in both directions. For certain applications the 42 configuration of the PW Type is most easily accomplished by 43 configuring this information at just one PW endpoint. In any form of 44 LDP-based signaling, each PW endpoint must initiate the creation of a 45 unidirectional LSP. In order to allow the initiation of these two 46 LSPs to remain independent, a means of allowing the PW endpoint 47 lacking a priori knowledge of the PW Type to initiate the creation of 48 an LSP is needed. This document defines a Wildcard PW Type to 49 satisfy this need. 51 Contents 53 1 Introduction .............................................. 3 54 1.1 Conventions and Terminology ............................... 3 55 2 Wildcard PW Type .......................................... 4 56 3 Procedures ................................................ 4 57 3.1 Procedures when sending the wildcard FEC .................. 4 58 3.2 Procedures when receiving the wildcard FEC ................ 4 59 4 Security Considerations ................................... 5 60 5 IANA Considerations ....................................... 5 61 6 References ................................................ 5 63 1. Introduction 65 Pseudowire signaling requires that the Pseudowire Type (PW Type) be 66 identical in both directions. For certain applications the configu- 67 ration of the PW Type is most easily accomplished by configuring this 68 information at just one PW endpoint. In any form of LDP-based sig- 69 naling, each PW endpoint must initiate the creation of a unidirec- 70 tional LSP. 72 By the procedures of [CONTROL] both label mapping messages must carry 73 the PW type and the two unidirectional mapping messages must be in 74 agreement. Thus within the current procedures the PW endpoint which 75 lacks configuration must wait to receive a Label Mapping message in 76 order to learn the PW Type, prior signaling the its unidirectional 77 LSP. 79 For certain applications this can become particularly onerous. For 80 example, suppose that an ingress PE is serving as part of a gateway 81 function between a layer two network and layer two attachment cir- 82 cuits on remote PEs. Suppose further that the initial setup needs to 83 be initiated from the layer 2 network, but the layer 2 signaling does 84 not contain sufficient information to determine the PW Type. This 85 information, however is known at the PE supporting the targeted 86 attachment circuit. 88 In this situation it is often desirable to allow the initiation of 89 the initiation of the two LSPs which compose a pseudowire to remain 90 independent. A means of allowing a PW endpoint lacking a piori 91 knowledge of the PW Type to initiate the creation of an LSP is 92 needed. This document defines a wildcard PW Type to satisfy this 93 need. 95 1.1. Conventions and Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 101 This document introduces no new terminology. However it assumes that 102 the reader is familiar with the terminology contained in [CONTROL] 103 and RFC 3985, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architec- 104 ture" [ARCH]. 106 2. Wildcard PW Type 108 In order to allow a PE to initiate the signaling exchange for a pseu- 109 dowire without knowing the pseudowire type, a new PW Type is defined. 110 The proposed codepoint is 0x7fff [to be assigned by IANA]. The 111 semantics are the following: 113 1. To the targeted PE, this value indicates that it is to determine 114 the PW Type (for both directions) and signal that in a label 115 mapping message back to the initiating PE. 117 2. For the procedures of [CONTROL] this PW Type is interpreted to 118 match any PW Type other than itself. That is the targeted PE may 119 respond with any valid PW Type other than the wildcard PW Type. 121 3. Procedures 123 3.1. Procedures when sending the wildcard FEC 125 When a PE which is not configured to use a specific PW Type for a 126 particular pseudowire, wishes to signaling an LSP for that pseu- 127 dowire, it sets the PW Type to "wildcard". This indicates that the 128 target PE should determine the PW Type for this pseudowire. 130 When a Label Mapping message is received for the pseudowire, the PE 131 checks the PW Type. 133 If the PW Type can be supported, the PE uses this as the PW Type for 134 both directions. 136 If the PW Type cannot be supported or is "wildcard" it MUST respond 137 to this message with a Label Release message with an LDP Status Code 138 of "Generic Misconfiguration Error". Further actions are beyond the 139 scope of this document but could include notifying the associated 140 application (if any) or notifying network management. 142 3.2. Procedures when receiving the wildcard FEC 144 When a targeted PE receives Label Mapping message indicating the 145 wildcard PW Type, it follows the normal procedures for checking the 146 AGI and TAII values. If the targeted PE is not configured to use a 147 specific, non-wildcard PW Type it MUST respond to this message with a 148 Label Release message with an LDP Status Code of "Generic Misconfigu- 149 ration Error". 151 Otherwise it treats the Label Mapping message as if it had indicated 152 the PW Type it is configured to use. 154 4. Security Considerations 156 This draft has little impact on the security aspects of [CONTROL]. 157 The message exchanges remain the same. However a malicious agent 158 attempting to connect to an access circuit would require one less 159 piece of information. To mitigate against this, a pseudowire control 160 entity receiving a request containing the wildcard FEC type SHOULD 161 only proceed with setup if explicitly configured to do so for the 162 particular AI in the TAI. Further, the reader should note the secu- 163 rity considerations of [CONTROL] in general and those pertaining to 164 the Generalized ID FEC Element in particular. 166 5. IANA Considerations 168 This document requests the following allocation be made from the IETF 169 consensus range of the "Pseudowire Type" registry as defined in 170 [IANA]. 172 PW Type Description 174 0x7FFF (TBA) Wildcard 176 6. References 178 Normative References 180 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 181 Requirement Levels", BCP 14, RFC 2119, March 1997. 183 [ARCH] Bryant, S. and P. Pate, "Pseudo Wire Emulation 184 Edge-to-Edge (PWE3) Architecture", RFC 3985, 185 March 2005. 187 [CONTROL] Martini, L., et al., "Pseudowire Setup and 188 Maintenance using the Label Distribution Protocol", 189 RFC 4447, April 2006. 191 [IANA] Martini, L., and Townsley, M., "IANA Allocations for 192 pseudo Wire Edge to Edge Emulation (PWE3)", 193 RFC 4447, April 2006. 195 Authors' Addresses 197 Luca Martini 198 Cisco Systems 199 9155 East Nichols Avenue, Suite 400 200 Englewood, CO, 80112 201 Email: lmartini@cisco.com 203 George Swallow 204 Cisco Systems 205 1414 Massachusetts Ave, 206 Boxborough, MA 01719 207 Email: swallow@cisco.com 209 Copyright Notice 211 Copyright (C) The Internet Society (2006). This document is subject 212 to the rights, licenses and restrictions contained in BCP 78, and 213 except as set forth therein, the authors retain all their rights. 215 Expiration Date 217 April 2007 219 Disclaimer of Validity 221 This document and the information contained herein are provided on an 222 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 223 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 224 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 225 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 226 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 227 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 229 The IETF takes no position regarding the validity or scope of any 230 Intellectual Property Rights or other rights that might be claimed to 231 pertain to the implementation or use of the technology described in 232 this document or the extent to which any license under such rights 233 might or might not be available; nor does it represent that it has 234 made any independent effort to identify any such rights. Information 235 on the procedures with respect to rights in RFC documents can be 236 found in BCP 78 and BCP 79. 238 Copies of IPR disclosures made to the IETF Secretariat and any 239 assurances of licenses to be made available, or the result of an 240 attempt made to obtain a general license or permission for the use of 241 such proprietary rights by implementers or users of this 242 specification can be obtained from the IETF on-line IPR repository at 243 http://www.ietf.org/ipr. 245 The IETF invites any interested party to bring to its attention any 246 copyrights, patents or patent applications, or other proprietary 247 rights that may cover technology that may be required to implement 248 this standard. Please address the information to the IETF at 249 ietf-ipr@ietf.org.