<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<rfc number="6829" category="std" updates="4379"
 submissionType="IETF" consensus="yes" ipr="trust200902">
  <front>
    <title abbrev="PW LSP Ping for IPv6">Label Switched Path (LSP) Ping for
    Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6</title>

    <author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
      <organization>Huawei Technologies Co., Ltd</organization>

      <address>
        <postal>
          <street>No. 3 Xinxi Road, Shang-di, Hai-dian District</street>

          <city>Beijing</city>

          <code>100085</code>

          <country>China</country>
        </postal>

        <email>mach@huawei.com</email>
      </address>
    </author>

    <author fullname="Ping Pan" initials="P." surname="Pan">
      <organization>Infinera</organization>

      <address>
        <postal>
          <street/>

          <!--
          <street>Sri Mohana Satya Srinivas Singamsetty </street>
          -->

          <city/>

          <code/>

          <country>US</country>
        </postal>

        <email>ppan@infinera.com</email>
      </address>
    </author>

    <author fullname="Carlos Pignataro" initials="C.M." surname="Pignataro">
      <organization abbrev="Cisco">Cisco Systems</organization>

      <address>
        <postal>
          <street>7200-12 Kit Creek Road</street>

          <street/>

          <city>Research Triangle Park</city>

          <code>27709</code>

          <region>NC</region>

          <country>US</country>
        </postal>

        <!--
                <phone>+1-919-392-7428</phone>
                <facsimile>+1-919-869-1438</facsimile>
            -->

        <email>cpignata@cisco.com</email>
      </address>
    </author>

    <author fullname="Rajiv Asati" initials="R." surname="Asati">
      <organization abbrev="Cisco">Cisco Systems</organization>

      <address>
        <postal>
          <street>7025-6 Kit Creek Road</street>

          <street/>

          <city>Research Triangle Park</city>

          <code>27709</code>

          <region>NC</region>

          <country>US</country>
        </postal>

        <email>rajiva@cisco.com</email>
      </address>
    </author>

    <date month="January" year="2013"/>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on http://www.rfc-editor.org/rfcsearch.html. -->

<keyword>example</keyword>
    <abstract>
      <t>The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping
      and traceroute mechanisms are commonly used to detect and isolate data plane failures in all MPLS LSPs, including LSPs used for each direction
      of an MPLS Pseudowire (PW). However, the LSP Ping and traceroute elements used
      for PWs are not specified for IPv6 address usage.</t>

      <t>This document extends the PW LSP Ping and traceroute mechanisms so
      they can be used with PWs that are set up and maintained using IPv6 LDP
      sessions. This document updates RFC 4379.</t>
    </abstract>

  </front>

  <middle>
    <section title="Introduction">
      <t>Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping
      and traceroute are defined in <xref target="RFC4379"/>. These mechanisms
      can be used to detect data plane failures in all MPLS LSPs,
      including Pseudowires (PWs). However, the PW LSP Ping and traceroute
      elements are not specified for IPv6 address usage.</t>

      <t>Specifically, the PW Forwarding Equivalence Class (FEC) sub-TLVs for the Target FEC Stack in the LSP
      Ping and traceroute mechanism are defined only for IPv4 Provider Edge
      (PE) routers and are not applicable for the case where PEs use IPv6
      addresses. Three PW-related Target FEC sub-TLVs are currently defined (FEC 128 Pseudowire-Deprecated, FEC 128
      Pseudowire-Current, and FEC 129 Pseudowire, see Sections 3.2.8 through
      3.2.10 of <xref target="RFC4379"/>). These sub-TLVs contain the source
      and destination addresses of the LDP session, and currently only an IPv4
      LDP session is covered. Despite the fact that the PE IP address family
      is not explicit in the sub-TLV definition, this can be inferred
      indirectly by examining the lengths of the Sender's/Remote PE Address
      fields or calculating the length of the sub-TLVs (see Section 3.2 of
      <xref target="RFC4379"/>). When an IPv6 LDP session is used, these existing sub-TLVs cannot be used since the addresses will not
      fit. Additionally, all other sub-TLVs are defined in pairs, one for IPv4
      and another for IPv6, but not the PW sub-TLVs.</t>

      <t>This document updates <xref target="RFC4379"/> to explicitly
      constrain the existing PW FEC sub-TLVs for IPv4 LDP sessions and
      extends the PW LSP Ping to IPv6 LDP sessions (i.e., when IPv6 LDP
      sessions are used to signal the PW, the Sender's and Receiver's IP
      addresses are IPv6 addresses). This is done by renaming the existing PW
      sub-TLVs to indicate "IPv4" and also by defining two new Target FEC sub-TLVs
      (FEC 128 Pseudowire IPv6 sub-TLV and FEC 129 Pseudowire IPv6 sub-TLV) to
      extend the application of PW LSP Ping and traceroute to IPv6 usage
      when an IPv6 LDP session <xref target="MPLS-LDP"/> is used
      to signal the Pseudowire. Note that FEC 128 Pseudowire (Deprecated) is
      not defined for IPv6 in this document.</t>

      <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">RFC 2119</xref>.</t>
    </section>


    <section anchor="IPv4" title="Pseudowire IPv4 Target FEC Stack Sub-TLVs">
      <t>This document updates Section 3.2 and Sections 3.2.8 through 3.2.10
      of <xref target="RFC4379"/> as follows and as indicated in Sections <xref
      target="Summary" format="counter"/> and <xref target="IANA" format="counter"/>. This is done to avoid any
      potential ambiguity and confusion and to clarify that these TLVs carry
      only IPv4 addresses. Note that the changes are limited to the names of
      fields; there are no semantic changes.</t>

      <t>Sections 3.2.8 through 3.2.10 of <xref target="RFC4379"/> list the PW
      sub-TLVs and state: <list>
          <t>"FEC 128" Pseudowire (Deprecated)</t>

          <t>"FEC 128" Pseudowire</t>

          <t>"FEC 129" Pseudowire</t>
        </list>These names and titles are now changed to: <list>
          <t>"FEC 128" Pseudowire - IPv4 (Deprecated)</t>

          <t>"FEC 128" Pseudowire - IPv4</t>

          <t>"FEC 129" Pseudowire - IPv4</t>
        </list></t>

      <t>Additionally, when referring to the PE addresses, Sections 3.2.8
through 3.2.10 of [RFC4379] state: <list>
          <t>Sender's PE Address</t>

          <t>Remote PE Address</t>
        </list> These are now updated to say: <list>
          <t>Sender's PE IPv4 Address</t>

          <t>Remote PE IPv4 Address</t>
        </list></t>
    </section>

    <section anchor="IPv6" title="Pseudowire IPv6 Target FEC Stack Sub-TLVs">
      <section title="FEC 128 Pseudowire">
        <t>The FEC 128 Pseudowire IPv6 sub-TLV has a structure consistent with
        the FEC 128 Pseudowire sub-TLV as described in Section 3.2.9 of <xref
        target="RFC4379"/>. The encoding of the FEC 128 Pseudowire IPv6 sub-TLV is
        as follows:</t>

        <t><figure align="center" anchor="Fig1"
            title="FEC 128 Pseudowire - IPv6">
            <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      FEC 128 PW IPv6 Type     |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   Sender's PE IPv6 Address                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Remote PE IPv6 Address                     ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             PW ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            PW Type            |          Must Be Zero         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure></t>

        <t>FEC 128 PW IPv6 Type: 24. 2 octets.</t>

        <t>Length: Defines the length in octets of the value field of the
        sub-TLV and its value is 38. 2 octets.</t>

        <t>Sender's PE IPv6 Address: The source IP address of the target IPv6
        LDP session. 16 octets.</t>

        <t>Remote PE IPv6 Address: The destination IP address of the target
        IPv6 LDP session. 16 octets.</t>

        <t>PW ID: Same as FEC 128 Pseudowire IPv4 <xref
        target="RFC4379"/>.</t>

        <t>PW Type: Same as FEC 128 Pseudowire IPv4 <xref
        target="RFC4379"/>.</t>
      </section>

      <section title="FEC 129 Pseudowire">
        <t>The FEC 129 Pseudowire IPv6 sub-TLV has a structure consistent with the
        FEC 129 Pseudowire sub-TLV as described in Section 3.2.10 of <xref
        target="RFC4379"/>. The encoding of FEC 129 Pseudowire IPv6 is as
        follows:</t>

        <t><figure align="center" anchor="Fig2"
            title="FEC 129 Pseudowire - IPv6">
            <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      FEC 129 PW IPv6 Type     |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   Sender's PE IPv6 Address                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Remote PE IPv6 Address                     ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            PW Type            |   AGI Type    |  AGI Length   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                           AGI Value                           ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   AII Type    |  SAII Length  |      SAII Value               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    SAII Value (continued)                     ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   AII Type    |  TAII Length  |      TAII Value               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    TAII Value (continued)                     ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  TAII (cont.) |  0-3 octets of zero padding                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure></t>

        <t>FEC 129 PW IPv6 Type: 25. 2 octets.</t>

        <t>Length: Defines the length in octets of the value field of the
        sub-TLV. 2 octets</t>

        <t>The length of this TLV is 40 + AGI (Attachment Group
Identifier) length + SAII (Source Attachment Individual Identifier) length +
TAII (Target
Attachment Individual Identifier) length. Padding is used to make the total length a multiple of 4; the
        length of the padding is not included in the Length field.</t>

        <t>Sender's PE IPv6 Address: The source IP address of the target IPv6
        LDP session. 16 octets.</t>

        <t>Remote PE IPv6 Address: The destination IP address of the target
        IPv6 LDP session. 16 octets.</t>

        <t>The other fields are the same as FEC 129 Pseudowire IPv4 <xref
        target="RFC4379"/>.</t>
      </section>
    </section>

    <section anchor="Summary" title="Summary of Changes">
      <t>Section 3.2 of <xref target="RFC4379"/> tabulates all the sub-TLVs
      for the Target FEC Stack. Per the change described in Sections <xref
      target="IPv4" format="counter"/> and <xref target="IPv6" format="counter"/>, the table would show the
      following: <figure>
          <artwork><![CDATA[
Sub-Type       Length        Value Field
--------       ------        -----------
  ...
       9           10        "FEC 128" Pseudowire - IPv4 (Deprecated)
      10           14        "FEC 128" Pseudowire - IPv4
      11          16+        "FEC 129" Pseudowire - IPv4
  ...
      24           38        "FEC 128" Pseudowire - IPv6
      25          40+        "FEC 129" Pseudowire - IPv6
   ]]></artwork>
        </figure></t>
    </section>

    <section title="Operation">
      <t>This document does not define any new procedures. The process
      described in <xref target="RFC4379"/> MUST be used.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>IANA has made the following assignments in the
      "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping
      Parameters" registry.</t>

      <t>The following sub-TLV changes, which comprise three updates and two
      additions, are made for the TLV Type 1 "Target FEC Stack" in the
      "TLVs and sub-TLVs" sub-registry.</t>

      <t>The names of the Value fields of these three Sub-TLVs have been
updated to include the "IPv4" qualifier (see <xref target="IPv4"/>), and the
      Reference has been updated to point to this document: <figure>
          <artwork><![CDATA[
Type       Sub-Type        Value Field
----       --------        -----------
   1            9          "FEC 128" Pseudowire - IPv4 (Deprecated)
   1           10          "FEC 128" Pseudowire - IPv4
   1           11          "FEC 129" Pseudowire - IPv4
   ]]></artwork>
        </figure></t>

      <t>Two new entries for the Sub-Type field of the Target FEC TLV (see
      <xref target="IPv6"/>) have been created: <figure>
          <artwork><![CDATA[
Type       Sub-Type        Value Field
----       --------        -----------
   1           24          "FEC 128" Pseudowire - IPv6
   1           25          "FEC 129" Pseudowire - IPv6
   ]]></artwork>
        </figure></t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document does not introduce any new security issues; the security
      mechanisms defined in <xref target="RFC4379"/> apply here.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors gratefully acknowledge the review and comments of Vanson Lim,
      Tom Petch, Spike Curtis, Loa Andersson, and Kireeti Kompella.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.4379"?>
    </references>

    <references title="Informative References">

<reference anchor="MPLS-LDP">
<front>
<title>Updates to LDP for IPv6</title>

<author initials='R' surname='Asati' fullname='Rajiv Asati'>
    <organization />
</author>

<author initials='V' surname='Manral' fullname='Vishwas Manral'>
    <organization />
</author>

<author initials='R' surname='Papneja' fullname='Rajiv Papneja'>
    <organization />
</author>

<author initials='C' surname='Pignataro' fullname='Carlos Pignataro'>
    <organization />
</author>

<date month='June' day='8' year='2012' />

<abstract>
<t>The Label Distribution Protocol (LDP) specification defines procedures to
exchange label bindings over either IPv4, IPv6 or both networks. This document
corrects and clarifies the LDP behavior when IPv6 network is used (with or
without IPv4). This document updates RFC 5036.
</t>
</abstract>
</front>

<seriesInfo name="Work in" value="Progress" />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-ipv6-07.txt' />
</reference>
</references>
  </back>
</rfc>
