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