<?xml version="1.0"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<?rfc toc="yes"?>

<rfc category='std' ipr='trust200902' docName='draft-nadeau-pwe3-vccv2-00.txt'>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC3985 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3985.xml'>
<!ENTITY RFC4385 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4385.xml'>
<!ENTITY RFC5085 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5085.xml'>
<!ENTITY RFC5586 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5586.xml'>
<!ENTITY RFC5880 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5880.xml'>
<!ENTITY RFC5885 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5885.xml'>
<!ENTITY RFC5994 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5994.xml'>
<!ENTITY I-D.ietf-pwe3-vccv-for-gal SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pwe3-vccv-for-gal.xml'>
<!ENTITY I-D.ietf-pwe3-vccv-impl-survey-results SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pwe3-vccv-impl-survey-results.xml'>
]>

<front>
<title abbrev="VCCV2">Virtual Circuit Connectivity Verification version 2 (VCCV2)</title>

<author fullname="Thomas D. Nadeau" initials="T." surname="Nadeau">
 <organization>Juniper Networks</organization>
 <address>
  <email>tnadeau@juniper.net</email>
 </address>
</author>

<author fullname="Carlos Pignataro" initials="C.M." surname="Pignataro">
 <organization>Cisco Systems, Inc.</organization>
 <address>
  <postal>
   <street>7200-12 Kit Creek Road</street>
   <street>PO Box 14987</street>
   <city>Research Triangle Park</city>
   <code>27709</code>
   <region>NC</region>
   <country>USA</country>
  </postal>
  <email>cpignata@cisco.com</email>
 </address>
</author>

<author initials="YJ" surname="Stein" fullname="Yaakov (Jonathan) Stein">
<organization>RAD Data Communications</organization>
 <address>
  <postal>
   <street>24 Raoul Wallenberg St., Bldg C</street>
   <city>Tel Aviv</city>
   <code>69719</code>
   <country>ISRAEL</country>
  </postal>
  <email>yaakov_s@rad.com</email>
 </address>
</author>

<date day="4" month="July" year="2012" />
<area>Internet</area>
<workgroup>PWE3</workgroup>

<keyword>VCCV2</keyword>
<keyword>VCCV</keyword>
<keyword>PW OAM</keyword>
<keyword>pseudowire OAM</keyword>
<keyword>pseudowire control channel</keyword>

<abstract>
<t>
   This document describes VCCV2, a new version of Virtual Circuit Connectivity Verification (VCCV), 
   the pseudowire OAM mechanism. This new version is backwards compatible with VCCV for MPLS PWs
   for modes that the versions share, although the Router Alert (RA) CV type is not supported by VCCV2. 
   Furthermore, this document collects the complete description of VCCV2 into a single specification.
</t>
</abstract>

</front>

<middle>

<section title="Introduction">
<t>
 Virtual Circuit Connectivity Verification (VCCV), the pseudowire OAM mechanism
 is described in <xref target="RFC5085"/>, <xref target="RFC5885"/>, and <xref target="I-D.ietf-pwe3-vccv-for-gal"/>. 
 This mechanism has been widely implemented and deployed,
 but it has been reported <xref target="I-D.ietf-pwe3-vccv-impl-survey-results"/>
 that the large number of VCCV options has led to interoperability issues.
</t>

<t>
 <xref target="RFC5085"/> together with <xref target="I-D.ietf-pwe3-vccv-for-gal"/> 
 define four Control Channel (CC) types for MPLS PWs:
 <list style="hanging">     
   <t hangText="Type 1"> using the control word (CW), </t> 
   <t hangText="Type 2"> using the Router Alert label (label=1) above the PW label, </t>
   <t hangText="Type 3"> using TTL expiry, </t> 
   <t hangText="Type 4"> using G-ACh Label (label=13) <xref target="RFC5586"/> below the PW label. </t>
 </list>
 In order to simplify implementations and operations, we herein obsolete Type 2, 
 and provide guidance as to when to use the remaining three types.
</t>   
 
<t>
 <xref target="RFC5085"/> together with <xref target="RFC5885"/>  
 define four Connectivity Verification (CV) types for MPLS PWs:
 <list>     
   <t> ICMP ping, </t> 
   <t> LSP ping, </t>
   <t> BFD with UDP/IP encapsulation, </t> 
   <t> raw BFD (without IP encapsulation), </t>
 </list> 
 and BFD  has several options of its own (see <xref target="RFC5880"/>).
 The description of what and how to implement these is spread over several documents,
 and we herein attempt to summarize the entire functionality set in one place.
</t> 
 
<t>
 This document only describes OAM for PWs over MPLS.
 Functionality for L2TPv2-based PWs remains as presently specified.
</t> 

<t>
 The present version of this document is a skeleton only,
 intended to initiate discussion.
 Once the principles are agreed upon, the authors will flesh out the rest.
</t>

</section>

<section title="Overview of the PW OAM Channel">
<t>
  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",       
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this       
  document are to be interpreted as described in <xref target="RFC2119"/>.
</t>   
<t>
 VCCV and VCCV2 are fault OAM mechanisms to verify liveliness and to further diagnose the pseudowire 
 forwarding path. This section will provide an overview of the requirements and architecture of PW OAM.
</t> 
</section>

<section title="Abbreviations">
<t>
 <list style='hanging'>
  <t hangText="AC">Attachment Circuit <xref target="RFC3985"/>	</t>
  <t hangText="CC">Control Channel (used as CC Type)</t>
  <t hangText="CE">Customer Edge</t>
  <t hangText="CV">Connectivity Verification (used as CV Type)</t>
  <t hangText="CW">Control Word <xref target="RFC3985"/></t>
  <t hangText="GACh">Generic Associated Channel <xref target="RFC5586"/> </t>
  <t hangText="GAL">GACh Channel Label <xref target="RFC5586"/> </t>
  <t hangText="MPLS-TP">MPLS-Transport Profile</t>
  <t hangText="OAM">Operations, Administration and Maintenance</t>
  <t hangText="PE">Provider Edge</t>
  <t hangText="PSN">Packet Switched Network <xref target="RFC3985"/></t>
  <t hangText="PW">Pseudowire <xref target="RFC3985"/></t>
  <t hangText="PW-ACH">PW Associated Channel Header <xref target="RFC4385"/></t>
  <t hangText="VCCV">Virtual Circuit Connectivity Verification</t>
 </list>
</t>
</section>

<section title="The Protocol and its Options">
<t>
 This section will detail all the CC and CV options,
 the signaling needed to choose each of them, the bit-masks and codings.
 The description will be concise, yet readable.
</t>   

<t>
 In particular, CC Type 2 is obsoleted.
 Subsections will discuss Types 1, 3, and 4.
</t>
 
<t>
 In addition, the text will provide guidance for selection of CC types, as follows:
 When the PW employs a CW then CC Type 1 SHOULD be used.
 TDM PWs always use the CW, and thus SHOULD always use Type 1.
 Legacy (ATM, port mode frame relay, and HDLC PWs) without CWs SHOULD use Type 3.
 <xref target="RFC5994"/> states that Ethernet PWs over MPLS-TP MUST use the CW, 
 and thus they SHOULD use Type 1, but MAY use Type 4.
</t>

<t>
 Discussion is needed as to whether all CV types are required.
 Subsections will detail the use of the different CV types.
</t>
  
</section>

<section title="Security Considerations">
<t>
 Are there significant threats on PWs based on VCCV?
</t>
</section>

<section title="IANA Considerations">
<t>
 It is not clear what needs to be put here.
 Will CC Type 2 be removed?
</t>
</section>

</middle>
 
<back>
<references title="Normative References">
   &RFC2119; 
   &RFC3985;
   &RFC4385;
   &RFC5085;
   &RFC5586;
   &RFC5880;
   &RFC5885;
   &RFC5994;
   &I-D.ietf-pwe3-vccv-for-gal;
</references>
<references title="Informative References">             
   &I-D.ietf-pwe3-vccv-impl-survey-results;
</references>
</back>

</rfc>
