idnits 2.17.1 draft-ietf-l2vpn-vpws-iw-oam-04.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 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 12, 2014) is 3697 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: 'RFC 4618' is mentioned on line 483, but not defined == Missing Reference: 'RFC4447' is mentioned on line 502, but not defined ** Obsolete undefined reference: RFC 4447 (Obsoleted by RFC 8077) == Unused Reference: 'RFC4618' is defined on line 545, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Mustapha Aissaoui 2 Internet Draft Peter Busschbach 3 Expires: September 12, 2014 Alcatel-Lucent 5 Dave Allan 6 Ericsson 8 Monique Morrow 9 Cisco Systems Inc. 11 Thomas Nadeau 12 Juniper Networks 14 Editors 16 March 12, 2014 18 OAM Procedures for VPWS Interworking 19 draft-ietf-l2vpn-vpws-iw-oam-04.txt 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with 24 the provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 12, 2014. 44 Copyright and License Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described in 56 Section 4.e of the Trust Legal Provisions and are provided without 57 warranty as described in the Simplified BSD License. 59 Abstract 61 This draft proposes OAM procedures for the Ethernet interworking, IP 62 interworking and FR-ATM interworking Virtual Private 63 Wire Service (VPWS). 65 Conventions used in this document 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC-2119. 71 Table of Contents 73 1. Contributors...................................................3 74 2. Introduction...................................................3 75 3. Conventions....................................................4 76 4. Reference Model and Defect Locations...........................5 77 5. Abstract Defect States.........................................6 78 6. VPWS OAM Modes.................................................8 79 7. PW Defect State Entry/Exit....................................10 80 8. ATM AC Defect State Entry/Exit................................10 81 9. FR AC Defect State Entry/Exit.................................11 82 10. Ethernet AC Defect State Entry/Exit..........................11 83 11. PPP AC Defect State Entry/Exit...............................11 84 12. Security Considerations......................................11 85 13. IANA Considerations..........................................12 86 14. References...................................................12 87 14.1. Normative References....................................12 88 14.2. Informative References..................................12 89 15. Editor's Addresses...........................................13 91 1. Contributors 93 The following individuals contributed significant ideas or text: 95 Matthew Bocci, matthew.bocci@alcatel-lucent.com 96 Simon Delord, simon.delord@gmail.com 97 Paul Doolan, paul.doolan@coriant.com 98 Mike Loomis, mike.loomis@alcatel-lucent.com 99 Hamid Ould-Brahim, ouldh@yahoo.com 100 Vasile Radoaca, vasile.radoaca@alcatel-lucent.com 101 Himanshu Shah, hshah@ciena.com 102 David Watkinson, david.watkinson@alcatel-lucent.com 103 John Z. Yu. 105 2. Introduction 107 This draft augments OAM message mapping [RFC6310] with OAM 108 procedures for scenarios when the attachment circuit does not 109 correspond to the pseudo wire. When combined with procedures defined 110 in [RFC6310] and [RFC7023], comprehensive OAM interworking can be 111 defined for VPWS services. VPWS services are defined in the L2 VPN 112 framework [RFC4664]. 114 The following VPWS are covered in this document: 116 1. VPWS with heterogeneous ACs of ATM and FR types, and in which the 117 PW type is ATM or FR. In this case, FR-ATM service interworking 118 [FRF8.2] is performed at one end of the VPWS and a FR (or ATM) PW 119 is extended to the remote PE. This VPWS will be referred to as 120 FR-ATM Interworking VPWS. 122 2. VPWS with heterogeneous ACs of ATM, FR, Ethernet, and PPP/BCP 123 types, and in which the PW type is Ethernet. This VPWS will be 124 referred to as Ethernet Interworking VPWS. 126 3. VPWS with heterogeneous ACs of ATM, FR, Ethernet, and PPP/IPCP 127 types, and in which the PW type is IP [RFC6575]. This VPWS will 128 be referred to as IP Interworking VPWS. 130 OAM procedures for homogeneous VPWS circuits of ATM and FR types are 131 described in [RFC6310]. OAM procedures for homogeneous VPWS circuits 132 of Ethernet type are defined in [RFC7023]. 134 The PPP PW encapsulation [RFC 4618] describes in Section 5.3 the 135 need to generate a PW status notification to the far-end PE if a 136 change to the status of the PPP AC or PW is detected. However, the 137 PPP protocol does not have a standardized OAM mechanism to propagate 138 to the PPP AC defects detected on the PW. 140 3. Conventions 142 The words "defect" and "fault" are used interchangeably to mean any 143 condition that obstructs forwarding of user traffic between the CE 144 endpoints of the VPWS. 146 The words "defect notification" and "defect indication" are used 147 interchangeably to mean any OAM message generated by a PE and sent 148 to other nodes in the network to convey the defect state local to 149 this PE. 151 An end-to-end virtual circuit in a VPWS consists of a 3 segment set: 152 [RFC4664]. Note that the AC does not need to connect a 153 CE directly to a PE. An intermediate L2 network may exist. 155 A VPWS is homogeneous if AC and PW types are the same. E.g., ATM 156 VPWS: . 158 A VPWS is heterogeneous if any two segments of the circuit are of 159 different types. E.g., IP interworking circuit: , or . 162 The PW of a VPWS can be carried over three types of Packet Switched 163 Networks (PSNs). An "MPLS PSN" makes use of MPLS Label Switched 164 Paths [RFC3031] as the tunneling technology to forward the PW 165 packets. An "MPLS/IP PSN" makes use of MPLS-in-IP tunneling 166 [RFC4023], with an MPLS shim header used as PW demultiplexer. An 167 "L2TPv3/IP PSN" makes use of L2TPv3/IP [RFC3931] as the tunneling 168 technology with the L2TPv3/IP Session ID as the PW demultiplexer. 170 If LSP-Ping [RFC4379] is run over a PW as described in [RFC5085], it 171 will be referred to as "VCCV-Ping". If BFD is run over a PW as 172 described in [RFC5885], it will be referred to as "VCCV-BFD". 174 While PWs are inherently bidirectional entities, defects and OAM 175 messaging are related to a specific traffic direction. We use the 176 terms "upstream" and "downstream" to identify PEs in relation to the 177 traffic direction. A PE is upstream for the traffic it is forwarding 178 and is downstream for the traffic it is receiving. 180 We use the terms "local" and "remote" to identify native service 181 networks and ACs in relation to a specific PE. The local AC is 182 attached to the PE in question, while the remote AC is attached to 183 the PE at the other end of the PW. 185 A "transmit defect" is any defect that uniquely impacts traffic sent 186 or relayed by the observing PE. A "receive defect" is any defect 187 that impacts information transfer to the observing PE. Note that a 188 receive defect also impacts traffic relayed, and thus can be 189 considered to incorporate two defect states. Thus, when a PE 190 enters both receive and transmit defect states of a VPWS, the 191 receive defect takes precedence over the transmit defect in terms of 192 the consequent actions. 194 A "forward defect indication" (FDI) is sent in the same direction as 195 the user traffic impacted by the defect. A "reverse defect 196 indication" (RDI) is sent in the direction opposite to that of the 197 impacted traffic. 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 201 document are to be interpreted as described in [RFC2119]. 203 4. Reference Model and Defect Locations 205 Figure 1 illustrates the VPWS network reference model with an 206 indication of the possible defect locations. This model is 207 introduced in [RFC6310] for homogeneous VPWS and is also valid for 208 heterogeneous VPWS. 210 ACs PSN tunnel ACs 211 +----+ +----+ 212 +----+ | PE1|==================| PE2| +----+ 213 | |---(a)---(b)..(c)......PW1..(d)..(e)..(f)---(g)---| | 214 | CE1| (N1) | | | | (N2) |CE2 | 215 | |----------|............PW2.............|----------| | 216 +----+ | |==================| | +----+ 217 ^ +----+ +----+ ^ 218 | Provider Edge 1 Provider Edge 2 | 219 | | 220 |<-------------- Emulated Service ---------------->| 221 Customer Customer 222 Edge 1 Edge 2 223 Figure 1: PWE3 Network Defect Locations 225 The procedures will be described in this document from the viewpoint 226 of PE1, so that N1 is the local Native Service (NS) network and N2 227 is the remote NS network. It is assumed that the AC and PW are of 228 different types at PE1. PE2 will typically implement the same 229 procedures. Note that PE1 is the upstream PE for traffic originating 230 in the local NS network N1, while it is the downstream PE for 231 traffic originating in the remote NS network N2. 233 The following is a brief description of the defect locations: 235 a. Defect in NS network N1. This covers any defect in network N1 236 (including any CE1 defect) that impacts all or some ACs 237 attached to PE1, and is thus a local AC defect. The defect is 238 conveyed to PE1 and to NS network N2 using NS specific OAM 239 defect indications. 241 b. Defect on a PE1 AC interface (another local AC defect). 243 c. Defect on a PE1 PSN interface. 245 d. Defect in the PSN network. This covers any defect in the PSN 246 that impacts all or some PWs between PE1 and PE2. The defect is 247 conveyed to the PE using a PSN and/or a PW specific OAM defect 248 indication. Note that both data plane defects and control plane 249 defects must be taken into consideration. Although control 250 plane packets may follow a different path than PW data plane 251 packets, a control plane defect may affect the PW status. 253 e. Defect on a PE2 PSN interface. 255 f. Defect on a PE2 AC interface (a remote AC defect). 257 g. Defect in NS network N2 (another remote AC defect). This covers 258 any defect in N2 (including any CE2 defect) which impacts all 259 or a subset of ACs attached to PE2. The defect is conveyed to 260 PE2 and to NS network N1 using the NS OAM defect indication. 262 5. Abstract Defect States 264 PE1 must track four defect states that reflect the observed states 265 of both directions of the VPWS on both the AC and the PW sides. 267 Defects may impact one or both directions of the VPWS. The observed 268 state is a combination of defects directly detected by PE1 and 269 defects of which it has been made aware via notifications. 271 +-----+ 272 ----AC receive---->| |-----PW transmit----> 273 CE1 | PE1 | PE2/CE2 274 <---AC transmit----| |<----PW receive----- 275 +-----+ 277 (arrows indicate direction of user traffic impacted by a defect) 278 Figure 2: Receive and Transmit Defect States 280 PE1 will directly detect or be notified of AC receive or PW receive 281 defects as they occur upstream of PE1 and impact traffic being sent 282 to PE1. As a result, PE1 enters the AC or PW receive defect state. 284 In Figure 2, PE1 may be notified of a receive defect in the AC by 285 receiving a Forward Defect indication, e.g., ATM AIS, from CE1 or an 286 intervening network. This defect notification indicates that user 287 traffic sent by CE1 may not be received by PE1 due to a defect. PE1 288 can also directly detect an AC receive defect if it resulted from a 289 failure of the receive side in the local port or link over which the 290 AC is configured. 292 Similarly, PE1 may detect or be notified of a receive defect in the 293 PW by receiving a Forward Defect indication from PE2. If PW status 294 is used for fault notification, this message will indicate a Local 295 PSN-facing PW (egress) Transmit Fault or a Local AC (ingress) 296 Receive Fault at PE2 [RFC4446]. This defect notification indicates 297 that user traffic sent by CE2 may not be received by PE1 due to a 298 defect. As a result, PE1 enters the PW receive defect state. 300 Note that a Forward Defect Indication is sent in the same direction 301 as the user traffic impacted by the defect. 303 Generally, a PE cannot detect transmit defects by itself and will 304 therefore need to be notified of AC transmit or PW transmit defects 305 by other devices. 307 In Figure 2, PE1 may be notified of a transmit defect in the AC by 308 receiving a Reverse Defect indication, e.g., ATM RDI, from CE1. This 309 defect relates to the traffic sent by PE1 to CE1 on the AC. 311 Similarly, PE1 may be notified of a transmit defect in the PW by 312 receiving a Reverse Defect indication from PE2. If PW status is used 313 for fault notification, this message will indicate a Local PSN 314 facing PW (ingress) Receive Fault or a Local Attachment Circuit 315 (egress) Transmit Fault at PE2 [RFC4446]. This defect impacts the 316 traffic sent by PE1 to CE2. As a result, PE1 enters the PW transmit 317 defect state. 319 Note that a Reverse Defect indication is sent in the reverse 320 direction to the user traffic impacted by the defect. 322 The procedures outlined in this document define the entry and exit 323 criteria for each of the four states with respect to the set of 324 heterogeneous VPWS within the document scope and the consequent 325 actions that PE1 must perform. 327 When a PE enters both receive and transmit defect states related to 328 the same VPWS, then the receive defect takes precedence over 329 transmit defect in terms of the consequent actions. 331 6. VPWS OAM Modes 333 A heterogeneous VPWS forwards packets between an AC and a PW of 334 different types. It thus implements both NS OAM and PW OAM 335 mechanisms. 337 PW OAM defect notification messages and NS OAM messages are 338 described in [RFC6310]. Ethernet NS OAM messages are described in 339 [RFC7023]. 341 [RFC6310] defined two different OAM modes, the distinction being the 342 method of mapping between the NS and PW OAM defect notification 343 messages. 345 The first mode, illustrated in Figure 3, is called the "single 346 emulated OAM loop" mode. Here a single end-to-end NS OAM loop is 347 emulated by transparently passing NS OAM messages over the PW. Note 348 that the PW OAM is shown outside the PW in Figure 3, as it is 349 transported in LDP messages or in the associated channel, not inside 350 the PW itself. 352 +-----+ +-----+ 353 +-----+ | |=================| | +-----+ 354 | CE1 |-=NS-OAM=>| PE1 |----=NS-OAM=>----| PE2 |-=NS-OAM=>| CE2 | 355 +-----+ | |=================| | +-----+ 356 +-----+ +-----+ 357 \ / 358 -------=PW-OAM=>------- 359 Figure 3: Single Emulated OAM Loop Mode 361 The single emulated OAM loop mode implements the following behavior: 363 a. The upstream PE (PE1) MUST transparently relay NS OAM messages 364 over the PW. 366 b. The upstream PE MUST signal local defects affecting the AC 367 using a NS defect notification message sent over the PW. In 368 the case that it is not possible to generate NS OAM messages 369 (e.g., because the defect interferes with NS OAM message 370 generation), the PE MUST signal local defects affecting the AC 371 using a PW defect notification message. 373 c. The upstream PE MUST signal local defects affecting the PW 374 using a PW defect notification message. 376 d. The downstream PE (PE2) MUST insert NS defect notification 377 messages into its local AC when it detects or is notified of a 378 defect in the PW or remote AC. This includes translating 379 received PW defect notification messages into NS defect 380 notification messages for defects signaled by the upstream PE. 382 The second OAM mode operates three OAM loops joined at the AC/PW 383 boundaries of the PEs. This is referred to as the "coupled OAM 384 loops" mode and is illustrated in Figure 4. Note that in contrast to 385 Figure 3, NS OAM messages are never carried over the PW. 387 +-----+ +-----+ 388 +-----+ | |=================| | +-----+ 389 | CE1 |-=NS-OAM=>| PE1 | | PE2 |-=NS-OAM=>| CE2 | 390 +-----+ | |=================| | +-----+ 391 +-----+ +-----+ 392 \ / 393 -------=PW-OAM=>------- 394 Figure 4: Coupled OAM Loops Mode 396 The coupled OAM loops mode implements the following behavior: 398 a. The upstream PE (PE1) MUST terminate and translate a received 399 NS defect notification message into a PW defect notification 400 message. 402 b. The upstream PE MUST signal local failures affecting its local 403 AC using PW defect notification messages to the downstream PE. 405 c. The upstream PE MUST signal local failures affecting the PW 406 using PW defect notification messages. 408 d. The downstream PE (PE2) MUST insert NS defect notification 409 messages into the AC (unless the AC is PPP) when it detects or 410 is notified of defects in the PW or remote AC. This includes 411 translating received PW defect notification messages into NS 412 defect notification messages. 414 Table 1 summarizes the OAM mode used with each VPWS covered in this 415 document. 417 ----------------------------------------------------------------- 418 |VPWS | Single Emulated | Coupled OAM | 419 | | OAM Loop Mode | Loops Mode | 420 ------------------------------------------------------------------ 421 |FR-ATM Interworking | | | 422 |- ATM cell mode PW | X | | 423 ------------------------------------------------------------------ 424 |FR-ATM Interworking | | | 425 |- FR or AAL5 PDU/SDU PW| | X | 426 ------------------------------------------------------------------ 427 |Ethernet Interworking | | X | 428 ------------------------------------------------------------------ 429 |IP Interworking | | X | 430 ----------------------------------------------------------------- 431 Table 1: Summary of Heterogeneous VPWS OAM Modes 433 7. PW Defect State Entry/Exit 435 The details of the PW transmit and receive defect state entry/exit 436 criteria are described in Section 6.2 of [RFC6310]. 438 The consequent actions for an ATM AC are described in sections 7.3.1 439 and 7.3.2 of [RFC6310]. 441 The consequent actions for a FR AC are described in sections 8.3.1 442 and 8.3.2 of [RFC6310]. 444 The consequent actions for an Ethernet AC are described in sections 445 6.1 through 6.4 of [RFC7023]. 447 8. ATM AC Defect State Entry/Exit 449 The details of the ATM AC receive and transmit defect state 450 entry/exit criteria are described in sections 7.1 and 7.2 451 respectively of [RFC6310]. 453 The consequent actions are described in sections 7.3.4 and 7.3.5 of 454 [RFC6310]. 456 Note that all interworking VPWS covered in this document make use of 457 ATM VC as the AC. ATM VP cannot be used as a AC in an interworking 458 VPWS. Therefore only ATM F5 OAM messages are relevant. 460 9. FR AC Defect State Entry/Exit 462 The details of the FR AC receive and transmit defect state 463 entry/exit criteria are described in sections 8.1 and 8.2 464 respectively of [RFC6310]. 466 The consequent actions are described in sections 8.3.4 and 8.3.5 of 467 [RFC6310]. Note however that if the FR AC is part of a FR-ATM 468 interworking VPWS operating in the single emulated OAM loop mode, 469 then the consequent actions are described sections 7.3.4 and 7.3.5 470 of [RFC6310]. 472 10. Ethernet AC Defect State Entry/Exit 474 The details of the Ethernet AC receive and transmit defect state 475 entry/exit criteria are described in sections 5.1 and 5.2 476 respectively of [RFC7023]. 478 The consequent actions are described in sections 6.5 through 6.8 of 479 [RFC7023]. 481 11. PPP AC Defect State Entry/Exit 483 The PPP PW encapsulation [RFC 4618] describes in Section 5.3 the 484 need to generate a PW status notification to the far-end PE if a 485 change to the status of the PPP AC or PW is detected. However, the 486 PPP protocol does not have a standardized OAM mechanism to propagate 487 to the PPP AC defects detected on the PW. 489 This document does not define additional procedures for a PPP AC 490 used in an Ethernet or IP interworking VPWS. 492 12. Security Considerations 494 The mapping messages described in this document do not change the 495 security functions inherent in the actual messages. All generic 496 security considerations applicable to PW traffic specified in 497 Section 10 of [RFC3985] are applicable to NS OAM messages 498 transferred inside the PW. 500 Security considerations in Section 10 of [RFC5085] for VCCV apply to 501 the OAM messages thus transferred. Security considerations 502 applicable to the PWE3 control protocol of [RFC4447] Section 8.2 503 apply to OAM indications transferred using the LDP status message. 505 13. IANA Considerations 507 This document requires no IANA actions. 509 14. References 511 14.1. Normative References 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, March 1997. 516 [RFC6310] Nadeau, T., et al., ''Pseudo Wire (PW) OAM Message Mapping'', 517 RFC 6310, April 2011. 519 [RFC7023] Qiu, R., Mohan, D., Bitar, N., DeLord, S., Niger, P., and 520 A. Sajassi, "MPLS and Ethernet Operations, Administration, and 521 Maintenance (OAM) Interworking ", RFC 7023, October 2013. 523 14.2. Informative References 525 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 526 Label Switching Architecture", RFC 3031, January 2001. 528 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 529 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 531 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 532 Edge (PWE3) Architecture", RFC 3985, March 2005. 534 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 535 MPLS in IP or Generic Routing Encapsulation (GRE)", 536 RFC 4023, March 2005. 538 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 539 Label Switched (MPLS) Data Plane Failures", RFC 4379, 540 February 2006. 542 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 543 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 545 [RFC4618] Martini, L., "Encapsulation Methods for Transport of 546 PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 547 4618, September 2006. 549 [RFC4664] Andersson, L. et. al., "L2VPN Framework", RFC 4664, 550 September 2006. 552 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 553 Connectivity Verification (VCCV): A Control Channel for 554 Pseudowires", RFC 5085, December 2007. 556 [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 557 Detection (BFD) for the Pseudowire Virtual Circuit 558 Connectivity Verification (VCCV)", RFC 5885, June 2010. 560 [RFC6575] Shah, H., et al., ''Address Resolution Protocol (ARP) 561 Mediation for IP Interworking of Layer 2 VPNs'', RFC 6575, June 562 2012. 564 [FRF8.2] Frame Relay Forum, ''FRF 8.2 - Frame Relay / ATM PVC Service 565 Interworking Implementation Agreement'', February 2004. 567 15. Editor's Addresses 569 Mustapha Aissaoui 570 Alcatel-lucent 571 Email: mustapha.aissaoui@alcatel-lucent.com 573 Dave Allan 574 Ericsson 575 david.i.allan@ericsson.com 577 Peter B. Busschbach 578 Alcatel-Lucent 579 Email: peter.busschbach@alcatel-lucent.com 581 Thomas Nadeau 582 Juniper Networks 583 tnadeau@lucidvision.com 585 Monique Morrow 586 Cisco Systems, Inc. 587 EMail: mmorrow@cisco.com