idnits 2.17.1 draft-rosen-l2vpn-mesh-failure-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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 321. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([IPLS,VPLS], [PWE3-ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (September 2004) is 7156 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: 'L2VPN-Framework' is mentioned on line 229, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-l2vpn-ipls-00 ** Downref: Normative reference to an Historic draft: draft-ietf-l2vpn-ipls (ref. 'IPLS') ** Downref: Normative reference to an Informational draft: draft-ietf-l2vpn-l2-framework (ref. 'L2VPN-FRAMEWORK') ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-arch (ref. 'PWE3-ARCH') == Outdated reference: A later version (-09) exists of draft-ietf-l2vpn-vpls-ldp-05 Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Eric C. Rosen 2 Internet Draft Cisco Systems, Inc. 3 Expiration Date: March 2005 5 September 2004 7 Detecting and Reacting to Failures of the Full Mesh in IPLS and VPLS 9 draft-rosen-l2vpn-mesh-failure-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 Certain L2VPN architectures [IPLS, VPLS] rely on there being a full 36 mesh of pseudowires [PWE3-ARCH] among a set of entities. This mesh 37 is used to provide a "LAN-like" service among the entities. If one 38 or more of these pseudowires is absent, so that there is not really a 39 full mesh, various higher layers (from routing to bridge control 40 protocols) that expect a LAN-like service may fail to work as 41 expected. Therefore it is desirable to have procedures that enable 42 the pseudowire endpoints to determine automatically whether there is 43 really a full mesh or not. It is also desirable to have procedures 44 that cause the L2VPNs to adapt to pseudowire failures. This document 45 proposes a set of procedures to meet these goals. Detailed protocol 46 encodings are not present, but will be added in future versions. 48 Contents 50 1 Introduction ......................................... 2 51 2 Detection of Partially Connected EEs ................. 4 52 3 Actions Taken Upon Detection ......................... 5 53 4 Normative References ................................. 7 54 5 Informative References ............................... 7 55 6 Author's Information ................................. 7 56 7 Intellectual Property Statement ...................... 7 57 8 Full Copyright Statement ............................. 8 59 1. Introduction 61 IPLS [IPLS] interconnects a set of CEs. With respect to a particular 62 IPLS instance and a particular PE supporting that IPLS instance, the 63 set of CEs can be divided into the PE's "local CEs" and the PE's 64 "remote CEs". The local CEs are directly attached to the PE. 65 ("Directly attached" means attached via an "Attachment Circuit" in 66 the sense of [L2VPN-Framework].) The PE must ensure that each of its 67 local CEs is bound, by a Pseudowire (PW), to each of the remote CEs. 68 When this condition holds for all the PEs supporting a given IPLS 69 instance, we say that the IPLS instance is fully meshed. 71 VPLS [VPLS} interconnects a set of "VPLS Forwarders" [L2VPN- 72 FRAMEWORK], which are virtual entities inside PEs; for a given VPLS 73 instance, there is one VPLS Forwarder in a given PE. Some of these 74 are considered "spokes", and some are considered "hubs". In a given 75 VPLS instance, there must be a PW binding every hub VPLS Forwarder to 76 every other hub VPLS Forwarder; this means that every hub PE in the 77 VPLS instance must have a PW to every other hub PE in the VPLS 78 instance. When this condition holds, we say that the VPLS instance 79 is fully meshed. 81 We will use the term "LS" to mean "IPLS or VPLS". 83 In each LS instance, there is a set of "endpoint entities" (EEs). In 84 VPLS, the EEs are hub VPLS Forwarders inside the PEs, in IPLS the EEs 85 are CEs. In either case, we say say that the LS instance is "fully 86 meshed" if every pair of EEs which are not local to the same PE are 87 bound together by a PW. 89 (For present purposes, it does not matter whether two EEs are bound 90 by a single bidirectional point-to-point PW or by a pair of 91 unidirectional point-to-multipoint PWs.) 93 It is possible that a given LS instance may fail to be fully meshed. 94 This may happen for the following reasons: 96 - Configuration errors. 98 - Failure of the auto-discovery process. 100 - Failure of the control plane to properly establish all the 101 necessary PWs. This in turn may be due to bugs, or to resource 102 shortages at the PEs. 104 - Failure of the data plane to carry traffic correctly on all the 105 established PWs. This can occur if there are bugs in the 106 encapsulation/decapsulation procedures at the PEs, or bugs in the 107 forwarding procedures at intermediate nodes (especially in 108 technologies where the data and control planes are decoupled. 110 When an LS instance is not fully meshed, we will say that one or more 111 of its EEs are "partially connected". An EE is regarded as 112 "partially connected" at a particular time if one of the following 113 conditions holds: 115 - PW not established: at that time, some PW binding that EE to 116 another EE has not been properly established, as determined by 117 the PW control plane. 119 - PW not operational: at that time, although the control plane 120 indicates that all the PWs binding other EEs to the given EE are 121 properly established, one or more of those PW is incapable of 122 passing data to the given EE for some reason. Note that 123 "operational" status is a unidirectional attribute. 125 If an LS instance is not fully meshed, then it will not be able to 126 provide the "LAN-like" service on which its users are depending. For 127 instance, if a link state routing algorithm is using its LAN 128 procedures over an LS instance which is not fully meshed, the 129 selected set of routes may have "black holes". 131 It is desirable therefore to have procedures which will automatically 132 identify any partially connected EEs. This document proposes a set 133 of procedures to meet these goals. Detailed protocol encodings are 134 not present, but will be added in future versions if the WG has 135 interest in proceeding in this direction. 137 2. Detection of Partially Connected EEs 139 Each PE in a particular LS instance must have some sort of control 140 plane relationship with each of the other PEs in the same LS 141 instance. (For the time being we ignore the situation in which PWs 142 are spliced together; this concepts discussed here are readily 143 extended to that case.) 145 There must be a status message, which we call the "Mesh Status" 146 message, which a PE sends to each of the other PEs in the same LS 147 instance. The Mesh Status message identifies the LS instance (by its 148 globally unique VPN identifier, for example), and lists the set of EE 149 pairs for which the originating PE has operational PWs. This message 150 would need to be resent whenever the list changes. As long as the 151 control protocol can reliably transport control messages, this 152 message would not have to be sent unless there is a change; in fact, 153 only changes would need to be sent. (However, this would require two 154 variants of the Mesh Status message: an "Add" and a "Remove".) A 155 PE's Mesh Status messages should also indicate which of the EEs are 156 locally attached to that PE. 158 Thus every PE in an LS instance maintains the Mesh Status of every 159 other PE supporting that same LS instance. 161 When the control connection to a particular remote PE is lost, the 162 Mesh Status of the remote PE is flushed, and no longer considered for 163 the purposes of Partially Connected EE Detection. 165 By including a pair of EEs in its Mesh Status messages, a PE is 166 stating that there is an OPERATIONAL PW binding the two EEs together, 167 not merely an established PW. Each PE is responsible for determining 168 whether each of its local PWs is operational in the outgoing 169 direction. This may require the use of some sort of per-PW test of 170 the data plane. It is advisable to construct the test for operational 171 status so as to avoid the possibility of flapping, perhaps by not 172 allowing a non-operational PW to return to operational status in less 173 than a specified time period. The test for operational status should 174 also ensure that a PW is not declared non-operational due to ordinary 175 network conditions, such as occasional packet loss, and that a PW is 176 not declared non-operational due to routing transients. 178 It is understood that it is much easier to lay down such requirements 179 than it is to devise procedures to meet them. The specification of 180 such procedures however is outside the scope of the current document. 182 When a PE in a particular LS instance has received a Mesh Status 183 message from every other PE (that it knows about) in that instance, 184 it can compute the set {EE} of all the EEs in the LS instance. This 185 is the union of the set of EEs mentioned in all the Mesh Status 186 messages. 188 The IPLS or VPLS instance is fully meshed if and only if the 189 following condition holds: 191 For every PE p and every EE e, either e is one of p's local EEs, 192 or p reports an operational PW from each of its local EEs to e. 194 If this condition doesn't hold, there are one or more Partially 195 Connected PWs . The set of Partially Connected EEs is defined as 196 follows: 198 An EE e is "Partially Connected" if and only if there is some PE 199 p such that e is not locally attached to p, and p has a locally 200 attached EE e' such that there is either no operational PW from e 201 to e' or there is no operational PW from e' to e. 203 If the configuration and/or auto-discovery procedures identify a set 204 of EEs whose local PE just happens to be down (or otherwise 205 unreachable), no PEs will have operational PWs for any of those EEs, 206 and the above procedures will not result in the determination that 207 there are any Partially Connected EEs. However, misconfigurations or 208 auto-discovery problems which cause different PEs to learn about 209 different sets of EEs will result in the detection of Partially 210 Connected EEs. 212 3. Actions Taken Upon Detection 214 Upon identification of a Partially Connected EE, an alarm should be 215 raised so that the network operators are aware of the situation. 217 In general, the LS service will not function properly if there are 218 Partially Connected EEs. It can however be made to function properly 219 if the Partially Connected EEs are removed from service entirely, 220 until such time as they becomes fully connected. In effect, once the 221 problematic EEs are removed from the mesh entirely, the LS service is 222 once again fully meshed, though with fewer EEs. Any users who 223 connect via the removed EEs will of experience degraded service, if 224 not complete loss of service, but other users may continue to receive 225 service. 227 If a PE determines that one of its locally attached EEs is Partially 228 Connected, it should remove that EE from service. In the case of 229 VPLS, this means that an Emulated LAN interface [L2VPN-Framework] is 230 brought down. In the case of IPLS, this means that the Attachment 231 Circuit to a particular set of CEs is brought down. PWs which are 232 bound to the Emulated LAN interface or Attachment Circuit should NOT 233 be disestablished and the testing of the data plane of such PWs 234 should continue. 236 If a PE determines that a remote EE is Partially Connected, the PE 237 will cease to send or receive data to or from that EE. The 238 corresponding PWs should NOT be disestablished, and the testing of 239 the data plane of such PWs should continue. 241 There may be methods of returning the LS service to a full mesh which 242 do not require removing a Partially Connected EE from service 243 entirely. For example, in VPLS it may be possible to change a 244 Partially Connected EE from a hub to a spoke, thereby removing it 245 from the mesh without bringing it out of service. [HUB-TO-SPOKE] 247 If, at some later time, an EE ceases to be Partially Connected, 248 normal operations can resume. 250 It must be understood that when an EE first becomes known, there will 251 be a period of time during which PEs are trying to bring up PWs to 252 it. From the time the first PW to/from it becomes operational to the 253 time the last PW to/from it becomes operational, the EE will be 254 detected as Partially Connected. As this is a normal transient, there 255 should be a specified period of time during which a newly discovered 256 EE may be Partially Connected before any action is taken. 257 Determination that a previously known EE has become Partially 258 Connected should cause immediate actions, however. 260 If a PE detects that one of its PWs has ceased to be operational, the 261 remote EE does not necessarily get treated immediately as being 262 Partially Connected. Before declaring the EE to be Partially 263 Connected, the PE should wait a period of time to see if that EE 264 disappears from the Mesh Status messages generated by all the other 265 PEs. After all, a very likely cause for a PW to become non- 266 operational is for the remote PE to fail or to become unreachable. 267 As this will no result in a partial mesh, no special action needs to 268 be take. 270 4. Normative References 272 [IPLS] "IP-only LAN Service (IPLS)", H. Shah, K. Arvind, E. Rosen, F. 273 Le Faucheur, G. Heron, V. Radoaca, draft-ietf-l2vpn-ipls-00.txt, 274 November 2003 276 [L2VPN-FRAMEWORK] "L2VPN Framework", L. Andersson, E. Rosen, editors, 277 draft-ietf-l2vpn-l2-framework-05.txt, June 2004 279 [PWE3-ARCH] "PWE3 Architecture", S. Bryant, P.Pate, editors, draft- 280 ietf-pwe3-arch-07.txt, March 2004 282 [VPLS] "Virtual Private LAN Services over MPLS", M. Lasserre, V. 283 Kompella, et. al., draft-ietf-l2vpn-vpls-ldp-05.txt, September 2004 285 5. Informative References 287 [HUB-TO-SPOKE] as suggested by Vach Kompella on the L2VPN mailing 288 list 290 6. Author's Information 292 Eric C. Rosen 293 Cisco Systems, Inc. 294 1414 Massachusetts Avenue 295 Boxborough, MA, 01719 297 E-mail: erosen@cisco.com 299 7. Intellectual Property Statement 301 The IETF takes no position regarding the validity or scope of any 302 Intellectual Property Rights or other rights that might be claimed to 303 pertain to the implementation or use of the technology described in 304 this document or the extent to which any license under such rights 305 might or might not be available; nor does it represent that it has 306 made any independent effort to identify any such rights. Information 307 on the procedures with respect to rights in RFC documents can be 308 found in BCP 78 and BCP 79. 310 Copies of IPR disclosures made to the IETF Secretariat and any 311 assurances of licenses to be made available, or the result of an 312 attempt made to obtain a general license or permission for the use of 313 such proprietary rights by implementers or users of this 314 specification can be obtained from the IETF on-line IPR repository at 315 http://www.ietf.org/ipr. 317 The IETF invites any interested party to bring to its attention any 318 copyrights, patents or patent applications, or other proprietary 319 rights that may cover technology that may be required to implement 320 this standard. Please address the information to the IETF at ietf- 321 ipr@ietf.org. 323 8. Full Copyright Statement 325 Copyright (C) The Internet Society (2004). This document is subject 326 to the rights, licenses and restrictions contained in BCP 78 and 327 except as set forth therein, the authors retain all their rights. 329 This document and the information contained herein are provided on an 330 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 331 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 332 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 333 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 334 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 335 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.