<?xml version="1.0" encoding="windows-1252"?> version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8745" consensus="true" category="std" docName="draft-ietf-pce-stateful-path-protection-11" ipr="trust200902"> ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

  <front>

    <title abbrev="Stateful PCE LSP Path Protection">PCEP Protection">Path Computation Element
    Communication Protocol (PCEP) Extensions for Associating Working and
    Protection LSPs Label Switched Paths (LSPs) with Stateful PCE</title>

<seriesInfo name="RFC" value="8745"/>
    <author fullname="Hariharan Ananthakrishnan" initials="H." surname="Ananthakrishnan">
      <organization>Netflix</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>hari@netflix.com</email>
      </address>
    </author>
    <author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
      <organization>Cisco</organization>
      <address>
        <postal>
          <street>2000 Innovation Drive</street>
                <city>Kananta, Ontaria K2K 3E8</city>
          <city>Kanata</city><region>Ontario</region><code>K2K 3E8</code>
          <country>Canada</country>
        </postal>
        <email>msiva@cisco.com</email>
      </address>
    </author>
    <author fullname="Colby Barth" initials="C." surname="Barth">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street>1194 N Mathilda Ave,</street>
                <city>Sunnyvale, CA, 94086</city>
                <country>USA</country> Ave</street>
          <city>Sunnyvale</city>
	  <region>CA</region><code>94086</code>
          <country>United States of America</country>
        </postal>
        <email>cbarth@juniper.net</email>
      </address>
    </author>
    <author fullname="Ina Minei" initials="I." surname="Minei">
      <organization>Google, Inc</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View, CA, 94043</city>
                <country>USA</country> View</city>
	  <region>CA</region><code>94043</code>
          <country>United States of America</country>
        </postal>
        <email>inaminei@google.com</email>
      </address>
    </author>
    <author initials="M" surname="Negi" fullname="Mahendra Singh Negi">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Divyashree Techno Park, Whitefield</street>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <code>560066</code>
          <country>India</country>
        </postal>
        <email>mahend.ietf@gmail.com</email>
      </address>
    </author>
    <!-- month and day will be generated automatically by XML2RFC;
be sure the year is current.-->

    <date year="2019"/> <!--02 as uploaded--> year="2020" month="March"/>

    <workgroup>PCE Working Group</workgroup>
    <keyword>PCEP</keyword>
    <abstract>
      <t> An active stateful Path Computation Element (PCE) is capable of computing as well as controlling via
Path Computation Element Communication Protocol (PCEP) Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Label Switched Paths (LSPs).
Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs. This document defines the PCEP extension to associate two or more LSPs to provide end-to-end path protection.</t>
    </abstract>
  </front>
  <middle>

    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="RFC5440"/> target="RFC5440" format="default"/> describes Path Computation
      Element Communication Protocol (PCEP) for communication between a Path
      Computation Client (PCC) and a PCE or between a pair of PCEs as per
      <xref target="RFC4655"/>. target="RFC4655" format="default"/>.  A PCE computes paths for
      MPLS-TE Label Switched Paths (LSPs) based on various constraints and
      optimization criteria. </t>
      <t>Stateful PCE <xref target="RFC8231"/> target="RFC8231" format="default"/> specifies a set of extensions to PCEP to enable
stateful control of paths such as MPLS-TE LSPs between and across PCEP sessions in compliance with <xref target="RFC4657"/>. target="RFC4657" format="default"/>.
It includes mechanisms to affect LSP state synchronization between PCCs and PCEs,
delegation of control of LSPs to PCEs, and PCE control of timing and
sequence of path computations within and across PCEP sessions. The
focus is on a model where LSPs are configured on the PCC PCC, and control
over them is delegated to the Stateful stateful PCE.

Furthermore, <xref target="RFC8281"/> target="RFC8281" format="default"/> specifies a mechanism to
dynamically instantiate LSPs on a PCC based on the requests from a
stateful PCE or a controller using stateful PCE.

</t>
      <t>Path protection <xref target="RFC4427"/> target="RFC4427" format="default"/> refers to a paradigm in which the working LSP is protected by one or more protection LSP(s).
When the working LSP fails, protection LSP(s) is/are activated. When the working LSPs are computed and controlled
by the PCE, there is benefit in a mode of operation where protection LSPs are also computed and controlled
by the same PCE. <xref target="RFC8051"/> target="RFC8051" format="default"/> describes the applicability of path protection in PCE deployments.</t>
      <t>This document specifies a stateful PCEP extension to associate two or more LSPs for the purpose of setting up
path protection. The extension defined in this document covers the following scenarios:
    <list style="symbols">
    <t>A
      </t>
      <ul spacing="normal">
        <li>A PCC initiates a protection LSP and retains the control of the LSP. The PCC computes the path itself or makes a
        request for path computation to a PCE. After the path setup, it reports the information and state of the path to the PCE.
        This includes the association group identifying the working and protection LSPs.
        This is the passive stateful mode <xref target="RFC8051"/>.
    </t>
    <t>A target="RFC8051" format="default"/>.
    </li>
        <li>A PCC initiates a protection LSP and delegates the control of the
        LSP to a stateful PCE. During delegation delegation, the association group
        identifying the working and protection LSPs is included. The PCE
        computes the path for the protection LSP and updates the PCC with the
        information about the path as long as it controls the LSP.  This is
        the active stateful mode <xref target="RFC8051"/>.
    </t>

    <t>A target="RFC8051" format="default"/>.
    </li>
        <li>A protection LSP could be initiated by a stateful PCE, which retains the control of the LSP.
    The PCE is responsible for computing the path of the LSP and updating to the PCC with the information about the path.
    This is the PCE-Initiated mode <xref target="RFC8281"/>.
    </t>

      </list> target="RFC8281" format="default"/>.
    </li>
      </ul>
      <t>

   Note that a protection LSP can be established (signaled) before
   the failure (in which case the LSP is said to be either in standby mode
   <xref target="RFC4427"/> target="RFC4427" format="default"/> or a Primary primary LSP <xref target="RFC4872"/>) target="RFC4872" format="default"/>) or after failure of the
   corresponding working LSP (known as a secondary LSP <xref target="RFC4872"/>). target="RFC4872" format="default"/>).
   Whether to establish it before or after failure is according
   to operator choice or policy.

</t>
      <t><xref target="I-D.ietf-pce-association-group"/> target="RFC8697" format="default"/> introduces a generic mechanism to
   create a grouping of LSPs, which can then be used to define
   associations between a set of LSPs.  The mechanism is equally
   applicable to stateful PCE (active and passive modes) and stateless
   PCE.</t>
      <t>This document specifies a PCEP extension to associate one working LSP with one or more
   protection LSPs using the generic association mechanism.</t>
      <t>This document describes a PCEP
   extension to associate protection LSPs by creating the Path Protection Association Group (PPAG)
   and encoding this association in PCEP messages for stateful PCEP
   sessions.
      </t>

      <section title="Requirements Language" toc="default">
        <t>The toc="default" numbered="true">
        <name>Requirements Language</name>

        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>

      </section>
    </section> <!-- Introduction -->

 <section title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>
      <t>The following terminologies terms are used in this document:
      <list style="hanging">
        <t hangText="ERO:">
      </t>
<ul empty="true">
<li>
      <dl newline="false" spacing="normal">
        <dt>ERO:</dt>
        <dd> Explicit Route Object.</t>
        <t hangText="LSP:"> Object</dd>
        <dt>LSP:</dt>
        <dd> Label Switched Path.</t>
        <t hangText="PCC:"> Path</dd>
        <dt>PCC:</dt>
        <dd> Path Computation Client.</t>
        <t hangText="PCE:"> Client</dd>
        <dt>PCE:</dt>
        <dd> Path Computation Element</t>
        <t hangText="PCEP:"> Element</dd>
        <dt>PCEP:</dt>
        <dd> Path Computation Element Communication Protocol.</t>
        <t hangText="PPAG:"> Protocol</dd>
        <dt>PPAG:</dt>
        <dd> Path Protection Association Group.</t>
        <t hangText="TLV:"> Group</dd>
        <dt>TLV:</dt>
        <dd> Type, Length, and Value.</t>
      </list>
      </t> Value</dd>
      </dl>
</li>
</ul>

 </section> <!-- Terminology -->

    <section anchor="Extension-Overview" title="PCEP Extensions"> numbered="true" toc="default">
      <name>PCEP Extensions</name>
      <section anchor="Path-Protection-Association-Type" title="Path numbered="true" toc="default">
        <name>Path Protection Association Type"> Type</name>
        <t>As per <xref target="I-D.ietf-pce-association-group"/>, target="RFC8697"
        format="default"/>, LSPs are not associated by listing the other LSPs
        with which they interact, but rather interact but, rather, by making them belong to an
        association groups. group. All LSPs join an association group
        individually. The generic ASSOCIATION object is used to associate two
        or more LSPs as specified in <xref target="I-D.ietf-pce-association-group"/>.
        target="RFC8697" format="default"/>. This
        document defines a new Association type called "Path Protection
        Association Type" of value TBD1 1 and a "Path Protection Association
        Group" (PPAG).  A member LSP of a PPAG can take the role of working or
        protection LSP.  A PPAG can have one working LSP and/or one or more
        protection LSPs. The source, destination, Tunnel ID (as carried in
        LSP-IDENTIFIERS TLV <xref target="RFC8231"/>, target="RFC8231" format="default"/>, with
        description as per <xref target="RFC3209"/>), target="RFC3209" format="default"/>), and
        Protection Type (PT) (in Path Protection Association TLV) of all LSPs
        within a PPAG MUST <bcp14>MUST</bcp14> be the same. As per <xref target="RFC3209"/>,
        target="RFC3209" format="default"/>, a TE tunnel is used to associate a
        set of LSPs during reroute or to spread a traffic trunk over multiple
        paths.</t>
        <t>The format of the Association ASSOCIATION object used for PPAG is specified in
<xref target="I-D.ietf-pce-association-group"/>.</t>

<!--<figure anchor="PPAG-IPv4-Association-Object-Fmt" title="PPAG IPv4 ASSOCIATION Object format">
<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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Reserved            |              Flags            |R|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Association type = TBD1    |          Association            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                IPv4 Association Source                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //            Optional TLVs                                    //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          ]]></artwork>
        </figure>

<figure anchor="PPAG-IPv6-Association-Object-Fmt" title="PPAG IPv6 ASSOCIATION Object format">
        <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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Reserved            |              Flags            |R|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Association type = TBD1     |          Association            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  |                IPv6 Association Source                        |
  |                                                               |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //            Optional TLVs                                    //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            ]]></artwork>
        </figure>
--> target="RFC8697" format="default"/>.</t>

        <t><xref target="I-D.ietf-pce-association-group"/> target="RFC8697" format="default"/> specifies the mechanism for the
   capability advertisement of the Association types supported by a PCEP
   speaker by defining a an ASSOC-Type-List TLV to be carried within an
   OPEN object.  This capability exchange for the Association type
   described in this document (i.e. (i.e.,  Path Protection Association Type) MAY <bcp14>MAY</bcp14> be
   done before using this association, i.e., the PCEP speaker MAY <bcp14>MAY</bcp14>
   include the Path Protection Association Type (TBD1) (1) in the ASSOC-Type-List TLV
   before using the PPAG in the PCEP messages.</t>
        <t>This Association type is dynamic in nature and created by the PCC
        or PCE for the LSPs belonging to the same TE tunnel (as described in
        <xref target="RFC3209"/>) target="RFC3209" format="default"/>) originating at the same
        head node and terminating at the same destination.  These associations
        are conveyed via PCEP messages to the PCEP peer. As per <xref target="I-D.ietf-pce-association-group"/>,
        target="RFC8697" format="default"/>, the
        association source is set to the local PCEP speaker address that
        created the association, association unless local policy dictates
        otherwise. Operator-configured Association Range MUST NOT <bcp14>MUST
        NOT</bcp14> be set for this Association type and MUST <bcp14>MUST</bcp14>
        be ignored.</t>
      </section>
      <section anchor="Path-Protection-Association-TLV" title="Path numbered="true" toc="default">
        <name>Path Protection Association TLV"> TLV</name>
        <t>The Path Protection Association TLV is an optional TLV for use in
        the ASSOCIATION Object object with the Path Protection Association Type. The
        Path Protection Association TLV MUST NOT <bcp14>MUST NOT</bcp14> be present
        more than once.  If it appears more than once, only the first
        occurrence is processed and any others MUST <bcp14>MUST</bcp14> be
        ignored. </t>
        <t> The Path Protection Association TLV follows the PCEP TLV format of
	<xref target="RFC5440"/>. target="RFC5440" format="default"/>. </t>

        <t> The type Type (16 bits) of the TLV is TBD2. 38. The length Length
field (16 bit) bits) has a fixed value of 4.</t>
        <t>The value comprises is comprised of a single field, the Path Protection Association
   Flags (32 bits), where each bit represents a flag option.</t>
<!--<t>The value comprises of two fields, the Protection Scheme (PS) (6 bits) and the Path Protection Association Flags (26 bits) (where each bit represents a
flag option). </t>-->

        <t> The format of the <xref target="PPAG-TLV-Fmt"> Path Protection Association TLV</xref> TLV (<xref
	target="PPAG-TLV-Fmt" format="default"/>) is as
        follows:</t>
        <figure anchor="PPAG-TLV-Fmt" title="Path anchor="PPAG-TLV-Fmt">
          <name>Path Protection Association TLV format">
        <artwork><![CDATA[ Format</name>
          <artwork name="" type="" align="left" alt=""><![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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Type = TBD2 38             |            Length = 4         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   PT      |               Unassigned Flags                |S|P|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            ]]></artwork>
        </figure>
        <t>Path Protection Association Flags (32 bits) -  The bits)</t><t>The following flags are currently defined -
    <list>
    <t>Protecting defined:
        </t>
        <ul empty="false" spacing="normal">
          <li>Protecting (P): 1 bit - This bit is as defined in Section 14.1 of <xref target="RFC4872"/>
          target="RFC4872" sectionFormat="of" section="14.1"/> to indicate if
          the LSP is a working (0) or protection (1) LSP.</t>
    <t>Secondary LSP.</li>
          <li>Secondary (S): 1 bit - This bit is as defined in Section 14.1 of <xref target="RFC4872"/>
          target="RFC4872" sectionFormat="of" section="14.1"/> to indicate if
          the LSP is a primary (0) or secondary (1) LSP. The S flag is ignored
          if the P flag is not set.</t>
    <t>Protection set.</li>

          <li>Protection Type (PT): 6 bits - This field is as defined in Section 14.1 of <xref target="RFC4872"/>
          target="RFC4872" sectionFormat="of" section="14.1"/> (as "LSP
          (Protection Type) Flags") to indicate the LSP protection type in
          use. Any type already defined or that could be defined in the future
          for use in the RSVP-TE PROTECTION object is acceptable in this TLV
          unless explicitly stated otherwise.</t>
    <t>Unassigned otherwise.</li>
          <li>Unassigned bits are considered reserved.  They MUST <bcp14>MUST</bcp14> be set to 0 on
   transmission and MUST <bcp14>MUST</bcp14> be ignored on receipt. </t>
 </list></t> </li>
        </ul>

        <t>If the TLV is missing in the PPAG ASSOCIATION object, it is
        considered that the LSP is a working LSP (i.e. (i.e., as if the P bit is
        unset).</t>
      </section> <!-- PPAG TLV -->

    </section> <!-- PCEP extensions -->

    <section anchor="Operation" title="Operation"> numbered="true" toc="default">
      <name>Operation</name>
      <t>An LSP is associated with
   other LSPs with which it interacts by adding them to a common
   association group via the ASSOCIATION object. All procedures and error-handling error handling for the ASSOCIATION
   object is as per <xref target="I-D.ietf-pce-association-group"/>.</t> target="RFC8697" format="default"/>.</t>
      <section anchor="Operation-State-Sync" title="State Synchronization"> numbered="true" toc="default">
        <name>State Synchronization</name>
        <t>During state synchronization, a PCC reports all the existing LSP states as described in <xref target="RFC8231"/>. target="RFC8231" format="default"/>.
   The association group membership pertaining to an LSP is also reported as per <xref target="I-D.ietf-pce-association-group"/>. target="RFC8697" format="default"/>. This
   includes PPAGs.</t>
      </section> <!-- State Synchronization -->

      <section anchor="Operation-PCC-Init" title="PCC-Initiated LSPs"> numbered="true" toc="default">
        <name>PCC-Initiated LSPs</name>
        <t>A PCC can associate a set of LSPs under its control for path
        protection purposes. Similarly, the PCC can remove one or more LSPs
        under its control from the corresponding PPAG. In both cases, the PCC
        reports the change in association to PCE(s) via a Path Computation
        Report (PCRpt) messages. message. A PCC can also delegate the working and
        protection LSPs to an active stateful PCE, where the PCE would control
        the LSPs. The stateful PCE could update the paths and attributes of
        the LSPs in the association group via a Path Computation Update (PCUpd)
        message. A PCE could also update the association to the PCC via a PCUpd
        message. These procedures are described in <xref target="I-D.ietf-pce-association-group"/>.
        target="RFC8697" format="default"/>.
</t>
        <t>It is expected that both working and protection LSPs are delegated together (and to the same PCE) to avoid any race conditions. Refer to <xref target="I-D.litkowski-pce-state-sync"/> target="I-D.litkowski-pce-state-sync" format="default"/> for the problem description.</t>
      </section> <!-- PCC-Initiated LSPs -->

      <section anchor="Operation-PCE-Init" title="PCE-Initiated LSPs"> numbered="true" toc="default">
        <name>PCE-Initiated LSPs</name>
        <t>A PCE can create/update working and protection LSPs independently.
    As specified in <xref target="I-D.ietf-pce-association-group"/>, target="RFC8697" format="default"/>,
    Association Groups can be created by both the PCE and the PCC.
    Further,
    Furthermore, a PCE can remove a protection LSP from a PPAG as specified in
    <xref target="I-D.ietf-pce-association-group"/>. target="RFC8697" format="default"/>. The PCE uses PCUpd
    or Path Computation Initiate (PCInitiate) messages to communicate the association information to the PCC.</t>
      </section> <!-- PCE-Initiated LSPs -->

      <section anchor="Session-Termination" title="Session Termination"> numbered="true" toc="default">
        <name>Session Termination</name>
        <t>As per <xref target="I-D.ietf-pce-association-group"/> target="RFC8697"
        format="default"/>, the association information is cleared along with
        the LSP state information.  When a PCEP session is terminated, after
        expiry of State Timeout Interval at the PCC, the LSP state associated
        with that PCEP session is reverted to operator-defined default
        parameters or behaviors as per <xref target="RFC8231"/>. target="RFC8231"
        format="default"/>. The same procedure is also followed for the
        association information.  On session termination at the PCE, when the
        LSP state reported by PCC is cleared, the association information is
        also cleared as per <xref target="I-D.ietf-pce-association-group"/>. target="RFC8697"
        format="default"/>.  Where there are no LSPs in a an association group,
        the association is considered to be deleted.</t>
      </section> <!-- State Synchronization -->

      <section anchor="Operation-Error-Handling" title="Error Handling"> numbered="true" toc="default">
        <name>Error Handling</name>
        <t>As per the processing rules specified in section 6.4 of <xref target="I-D.ietf-pce-association-group"/>,
        target="RFC8697" sectionFormat="of"
        section="6.4"/>, if a PCEP speaker does not support this Path
        Protection Association Type, it would return a PCErr message with
        Error-Type 26 "Association Error" and Error-Value 1 "Association type
        is not supported".</t>

        <t>All LSPs (working or protection) within a PPAG MUST <bcp14>MUST</bcp14>
        belong to the same TE Tunnel tunnel (as described in <xref target="RFC3209"/>) target="RFC3209"
        format="default"/>) and have the same source and destination.  If a
        PCEP speaker attempts to add or update an LSP to a PPAG and the Tunnel
        ID (as carried in the LSP-IDENTIFIERS TLV <xref target="RFC8231"/>, target="RFC8231"
        format="default"/>, with a description as per <xref target="RFC3209"/>) target="RFC3209"
        format="default"/>) or source or destination of the LSP is different
        from the LSP(s) in the PPAG, the PCEP speaker MUST <bcp14>MUST</bcp14> send
        PCErr with Error-Type 26 (Association Error) <xref target="I-D.ietf-pce-association-group"/>
        target="RFC8697" format="default"/> and
        Error-Value TBD3 9 (Tunnel ID or End points endpoints mismatch for Path Protection
        Association). In case of Path Protection, an LSP-IDENTIFIERS TLV SHOULD
        <bcp14>SHOULD</bcp14> be included for all LSPs (including Segment
        Routing (SR) <xref target="I-D.ietf-pce-segment-routing"/>). target="RFC8664"
        format="default"/>). If the Protection Type (PT) (in the Path Protection
        Association TLV) is different from the LSPs in the PPAG, the PCEP
        speaker MUST <bcp14>MUST</bcp14> send PCErr with Error-Type 26 (Association
        Error) <xref target="I-D.ietf-pce-association-group"/> target="RFC8697"
        format="default"/> and Error-Value 6 (Association information
        mismatch) as per <xref target="I-D.ietf-pce-association-group"/>.</t> target="RFC8697"
        format="default"/>.</t>
        <t>When the PCEP peer does not support the protection type set in PPAG, the PCEP peer MUST <bcp14>MUST</bcp14> send PCErr with Error-Type 26 (Association Error)
  <xref target="I-D.ietf-pce-association-group"/> target="RFC8697" format="default"/> and Error-Value TBD5 11 (Protection type is not supported).</t>
        <t>A given LSP MAY <bcp14>MAY</bcp14> belong to more than one PPAG. If there is a conflict between any of the two PPAGs, the PCEP peer MUST <bcp14>MUST</bcp14> send PCErr with Error-Type 26 (Association Error) <xref target="I-D.ietf-pce-association-group"/> target="RFC8697" format="default"/> and Error-Value 6 (Association information mismatch) as per <xref target="I-D.ietf-pce-association-group"/>.</t> target="RFC8697" format="default"/>.</t>
        <t>When the protection type is set to 1+1 (i.e., protection type=0x08
        or 0x10), there MUST <bcp14>MUST</bcp14> be at maximum, maximum only one working LSP
        and one protection LSP within a PPAG.  If a PCEP speaker attempts to
        add another working/protection LSP, the PCEP peer MUST <bcp14>MUST</bcp14>
        send PCErr with Error-Type 26 (Association Error) <xref target="I-D.ietf-pce-association-group"/>
        target="RFC8697" format="default"/> and Error-Value TBD4 10 (Attempt to add
        another working/protection LSP for Path Protection Association).</t>
        <t>When the protection type is set to 1:N (i.e., protection
        type=0x04), there MUST <bcp14>MUST</bcp14> be at maximum, maximum only one working LSP protection
        LSP, and the number of protection working LSPs MUST NOT <bcp14>MUST NOT</bcp14> be more
        than N within a PPAG. If a PCEP speaker attempts to add another
        working/protection LSP, the PCEP peer MUST <bcp14>MUST</bcp14> send PCErr
        with Error-Type 26 (Association Error) <xref target="I-D.ietf-pce-association-group"/> target="RFC8697"
        format="default"/> and Error-Value TBD4 10 (Attempt to add another
        working/protection LSP for Path Protection Association).</t>

  <!--<t>When the protection type is set to 1:N with N>1:
  <list>
  <t>If there is only one PPAG, there MUST be only one working LSP and number of protection LSPs MUST NOT be more than N within a PPAG.</t>
  <t>If there are multiple PPAGs, in each PPAG there must be only one working LSP and total number of protection LSPs in all the PPAGs MUST NOT be more than N.</t>
  <t>If above conditions are not satisfied, the PCEP peer MUST send PCErr with Error-Type 26 (Early allocation by IANA) (Association Error)
    <xref target='I-D.ietf-pce-association-group'></xref> and Error-Value 6 (Association information mismatch).</t>

  <t>If PCEP peer does not support 1:N protection, the PCEP peer MUST send PCErr with Error-Type 26 (Early allocation by IANA) (Association Error)
    <xref target='I-D.ietf-pce-association-group'></xref> and Error-Value TBD5 (Protection type is not supported).</t>
  </list>
  </t>-->

        <t>During the make-before-break (MBB) procedure, two paths will
        briefly coexist. The error handling related to the number of LSPs allowed
        in a PPAG MUST NOT <bcp14>MUST NOT</bcp14> be applied during MBB.</t>
        <t>All processing as per <xref target="I-D.ietf-pce-association-group"/> target="RFC8697" format="default"/> continues to apply.</t>
      </section> <!-- Error Handling -->

    </section> <!-- Operation -->

    <section title="Other Considerations"> numbered="true" toc="default">
      <name>Other Considerations</name>
      <t>The working and protection LSPs are typically resource disjoint
      (e.g., node, SRLG Shared Risk Link Group [SRLG] disjoint).  This ensures that
      a single failure will not affect both the working and protection
      LSPs. The disjoint requirement for a group of LSPs is handled via
      another Association type called "Disjointness Association", Association" as described
      in <xref target="I-D.ietf-pce-association-diversity"/>. target="I-D.ietf-pce-association-diversity" format="default"/>.
      The diversity requirements for the protection LSP are also handled by
      including both ASSOCIATION objects identifying both the protection
      association group and the disjoint association group for the group of
      LSPs. The relationship between the Synchronization VECtor (SVEC) object
      and the Disjointness Association is described in section 5.3 of <xref target="I-D.ietf-pce-association-diversity"/>.</t>
      target="I-D.ietf-pce-association-diversity" sectionFormat="of" section="5.4"/>.</t>
      <t><xref target="RFC4872"/> target="RFC4872" format="default"/> introduces the concept and
      mechanisms to support the association of one LSP to another LSP across
      different RSVP Traffic Engineering (RSVP-TE) sessions using the ASSOCIATION
      and PROTECTION object.  The information in the Path Protection
      Association TLV in PCEP as received from the PCE is used to trigger the
      signaling of the working LSP and protection LSP, with the Path Protection
      Association Flags mapped to the corresponding fields in the PROTECTION Object
      object in RSVP-TE.</t>
    </section>
    <section title="IANA Considerations">
<t>[Note to RFC Editor and IANA: Sections 3.1, 3.2, and 4.5 contain "TBD1" through
"TBD5" those should be replaced by the values that IANA assigns.]</t> numbered="true" toc="default">
      <name>IANA Considerations</name>

      <section title="Association Type"> numbered="true" toc="default">
        <name>Association Type</name>
        <t>This document defines a new Association type, originally
    defined in <xref target="I-D.ietf-pce-association-group"/>, target="RFC8697" format="default"/>, for path protection.
    IANA is requested to make the assignment of a has assigned new value for in the
    sub-registry
    "ASSOCIATION Type Field" (request to be created in subregistry (created by <xref target="I-D.ietf-pce-association-group"/>), target="RFC8697" format="default"/>) as follows: </t>
            <texttable>
            <ttcol>Association type Value</ttcol><ttcol>Association Name    </ttcol><ttcol>Reference</ttcol>
            <c> TBD1 </c><c> Path Protection Association</c> <c> This     document </c>
            </texttable>

        <table align="center">
<name>ASSOCIATION Type Field
</name>
          <thead>
            <tr>
              <th align="left">Type</th>
              <th align="left">Name</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">1</td>
              <td align="left">Path Protection Association</td>
              <td align="left">RFC 8745</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="Path numbered="true" toc="default">
        <name>Path Protection Association TLV"> TLV</name>
        <t> This document defines a new TLV for carrying the additional information of LSPs within a path protection association group.
      IANA is requested to make the assignment of has assigned a new value for in the
   existing
   "PCEP TLV Type Indicators" registry subregistry as follows:</t>

        <texttable>
        <ttcol>TLV
        <table align="center">
<name>PCEP TLV Type Value</ttcol><ttcol>TLV Name</ttcol><ttcol> Reference</ttcol>
        <c> TBD2 </c><c>Path Indicators
</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">38</td>
              <td align="left">Path Protection Association Group TLV</c> <c> This document </c>
        </texttable> TLV</td>
              <td align="left">RFC 8745</td>
            </tr>
          </tbody>
        </table>
        <t> This document requests that Per this document, a new sub-registry, subregistry named "Path
        protection Association Group TLV Flag Field",
is Field" has been created within the
        "Path Computation Element Protocol (PCEP) Numbers" registry to manage
        the Flag field in the Path Protection Association Group TLV.  New
        values are to be assigned by Standards Action <xref target="RFC8126"/>. target="RFC8126"
        format="default"/>.  Each bit should be tracked with the following
        qualities:
<list style="symbols">
    <t>Bit
</t>
        <ul spacing="normal">
          <li>Bit number (count from 0 as the most significant bit) </t>
    <t>Name flag </t>
    <t>Reference </t>
</list>
</t>

<texttable bit)</li>
          <li>Name of the flag</li>
          <li>Reference</li>
        </ul>
        <table anchor="PPAG-TLV-Table-IANA" title="Path align="center">
          <name>Path Protection Association Group TLV Flag Field">
    <ttcol align="center">Bit Number</ttcol>
    <ttcol align="center">Name</ttcol>
    <ttcol align="center">Reference</ttcol>
    <c>31</c>
    <c>P Field</name>
          <thead>
            <tr>
              <th align="center">Bit</th>
              <th align="center">Name</th>
              <th align="center">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">31</td>
              <td align="center">P - PROTECTION-LSP</c>
    <c>This document </c>
    <c>30</c>
    <c>S PROTECTION-LSP</td>
              <td align="center">RFC 8745 </td>
            </tr>
            <tr>
              <td align="center">30</td>
              <td align="center">S - SECONDARY-LSP</c>
    <c>This document</c>
    <c>6-29</c>
    <c>Unassigned</c>
    <c>This document</c>
    <c>0-5</c>
    <c>Protection SECONDARY-LSP</td>
              <td align="center">RFC 8745</td>
            </tr>
            <tr>
              <td align="center">6-29</td>
              <td align="center">Unassigned</td>
              <td align="center">RFC 8745</td>
            </tr>
            <tr>
              <td align="center">0-5</td>
              <td align="center">Protection Type Flags</c>
    <c>This document </c>
</texttable> Flags</td>
              <td align="center">RFC 8745 </td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="PCEP Errors"> numbered="true" toc="default">
        <name>PCEP Errors</name>
        <t>This document defines new Error-Values related to path protection
        association for Error-type 26 "Association Error" defined in <xref target="I-D.ietf-pce-association-group"/>.
        target="RFC8697" format="default"/>.  IANA is requested to allocate has allocated new error values within the "PCEP-ERROR Object
        Error Types and Values" sub-registry subregistry of the PCEP Numbers
   registry, registry as
        follows:</t>
          <!--<t>Error-type: 26 "Association Error" <xref target="I-D.ietf-pce-association-group"/></t> -->
          <texttable>
           <ttcol> Error-type </ttcol><ttcol> Error-value </ttcol><ttcol>

        <table align="center">
<name>PCEP-ERROR Object Error Types and Values
</name>
          <thead>
            <tr>
              <th align="left"> Error-Type </th>
              <th align="left"> Meaning </ttcol><ttcol> </th>
              <th align="left"> Error-value </th>
              <th align="left"> Reference </ttcol>
           <c> </th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left"> 26 </c> <c></c><c>Association Error</c><c><xref target="I-D.ietf-pce-association-group"/></c>
           <c></c><c></c><c></c><c></c>
           <c></c><c> TBD3 </c> <c>Tunnel </td>
              <td align="left">Association Error</td>
              <td align="left"/>
              <td align="left">
                <xref target="RFC8697" format="default"/></td>
            </tr>

            <tr>
              <td align="left"/>
              <td align="left"/>
              <td align="left">9: Tunnel ID or End points endpoints mismatch for Path Protection Association</c> <c> This document</c>

           <c></c><c> TBD4 </c> <c>Attempt Association</td>
              <td align="left">RFC 8745</td>
            </tr>
            <tr>
              <td align="left"/>
              <td align="left"/>
              <td align="left">10: Attempt to add another working/protection LSP for Path Protection Association</c> <c> This document</c>

           <c></c><c> TBD5 </c> <c>Protection Association</td>
              <td align="left">RFC 8745</td>
            </tr>
            <tr>
              <td align="left"/>
              <td align="left"/>
              <td align="left">11: Protection type is not supported</c> <c> This document</c>

          </texttable> supported</td>
              <td align="left">RFC 8745</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>

 <t>
               The security considerations described in <xref target="RFC8231"/>, target="RFC8231"
               format="default"/>, <xref target="RFC8281"/>, target="RFC8281" format="default"/>,
               and <xref target="RFC5440"/> target="RFC5440" format="default"/> apply to the
               extensions described in this document as well.  Additional
               considerations related to associations where a malicious PCEP
               speaker could be spoofed and could be used as an attack vector
               by creating associations as are described in <xref target="I-D.ietf-pce-association-group"/>.
               target="RFC8697" format="default"/>.
               Adding a spurious protection LSP to the Path Protection
               Association group could give a false sense of network
               reliability, which leads to issues when the working LSP is down
               and the protection LSP fails as well. Thus Thus, securing the PCEP
               session using Transport Layer Security (TLS) <xref target="RFC8253"/>,
               target="RFC8253" format="default"/>, as per the recommendations
               and best current practices in BCP 195 <xref target="RFC7525"/>, target="RFC7525"
               format="default"/>, is
   RECOMMENDED. <bcp14>RECOMMENDED</bcp14>.
      </t>
    </section>
    <section title="Manageability Considerations" toc="default"> toc="default" numbered="true">
      <name>Manageability Considerations</name>
      <section title="Control toc="default" numbered="true">
        <name>Control of Function and Policy" toc="default"> Policy</name>
        <t>Mechanisms defined in this document do not imply any control or policy
            requirements in addition to those already listed in
        <xref target="RFC5440"/>, target="RFC5440" format="default"/>, <xref target="RFC8231"/>, target="RFC8231" format="default"/>, and
        <xref target="RFC8281"/>.</t> target="RFC8281" format="default"/>.</t>
      </section>
      <section title="Information toc="default" numbered="true">
        <name>Information and Data Models" toc="default"> Models</name>
        <t><xref target="RFC7420"/> target="RFC7420" format="default"/> describes the PCEP MIB, MIB; there are no new MIB Objects
        for this document.</t>
        <t>The PCEP YANG module <xref target="I-D.ietf-pce-pcep-yang"/> target="I-D.ietf-pce-pcep-yang" format="default"/> supports
        associations.</t>
      </section>
      <section title="Liveness toc="default" numbered="true">
        <name>Liveness Detection and Monitoring" toc="default"> Monitoring</name>
        <t>Mechanisms defined in this document do not imply any new liveness detection
        and monitoring requirements in addition to those already listed in
        <xref target="RFC5440"/>, target="RFC5440" format="default"/>, <xref target="RFC8231"/>, target="RFC8231" format="default"/>, and
        <xref target="RFC8281"/>.</t> target="RFC8281" format="default"/>.</t>
      </section>
      <section title="Verify toc="default" numbered="true">
        <name>Verify Correct Operations" toc="default"> Operations</name>
        <t>Mechanisms defined in this document do not imply any new operation
        verification requirements in addition to those already listed in
        <xref target="RFC5440"/>, target="RFC5440" format="default"/>, <xref target="RFC8231"/>, target="RFC8231" format="default"/>, and
        <xref target="RFC8281"/>.</t> target="RFC8281" format="default"/>.</t>
      </section>
      <section title="Requirements On toc="default" numbered="true">
        <name>Requirements on Other Protocols" toc="default"> Protocols</name>
        <t>Mechanisms defined in this document do not imply any new requirements
        on other protocols.</t>
      </section>
      <section title="Impact On toc="default" numbered="true">
        <name>Impact on Network Operations" toc="default"> Operations</name>
        <t>Mechanisms defined in this document do not have any impact on
        network operations in addition to those already listed in
        <xref target="RFC5440"/>, target="RFC5440" format="default"/>, <xref target="RFC8231"/>, target="RFC8231" format="default"/>, and
        <xref target="RFC8281"/>.</t> target="RFC8281" format="default"/>.</t>
      </section>
    </section>

  </middle>
  <back>

<displayreference target="I-D.ietf-pce-pcep-yang" to="PCEP-YANG"/>

<displayreference target="I-D.ietf-pce-association-diversity" to="PCEP-LSP-EXT"/>

<displayreference target="I-D.litkowski-pce-state-sync" to="STATE-PCE-SYNC"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4872.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8697.xml"/>
      </references>

      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4427.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4657.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7420.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8051.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pce-pcep-yang.xml"/>

<!-- draft-ietf-pce-association-diversity-13: I-D exists-->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pce-association-diversity.xml"/>

<!-- I-D.ietf-pce-segment-routing: Published as RFC 8664-->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8664.xml"/>

<!-- draft-litkowski-pce-state-sync-06: I-D expired-->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.litkowski-pce-state-sync.xml"/>
      </references>
    </references>

    <section title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>We would like to thank Jeff Tantsura, Xian Zhang and Greg Mirsky  <contact fullname="Jeff Tantsura"/>,  <contact
      fullname="Xian Zhang"/>, and  <contact fullname="Greg Mirsky"/> for
      their contributions to this document.</t>
      <t>Thanks to Ines Robles <contact fullname="Ines Robles"/> for the RTGDIR review.</t>
      <t>Thanks to Pete Resnick <contact fullname="Pete Resnick"/> for the GENART review.</t>
      <t>Thanks to Donald Eastlake <contact fullname="Donald Eastlake"/> for the SECDIR review.</t>
      <t>Thanks to Barry Leiba, Benjamin Kaduk, Eric Vyncke, and Roman Danyliw  <contact fullname="Barry Leiba"/>,  <contact
      fullname="Benjamin Kaduk"/>,  <contact fullname="Éric Vyncke"/>, and  <contact
      fullname="Roman Danyliw"/> for the IESG review.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">

        <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119"?>
        <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209"?>
        <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4872"?>
        <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440"?>
        <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7525"?>
        <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126"?>
        <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174"?>
        <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8231"?>
        <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8253"?>
        <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8281"?>
        <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pce-association-group"?>
    </references>
    <references title="Informative References">
        <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4427"?>
        <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655"?>
        <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4657"?>
        <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7420"?>

        <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8051"?>

        <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pce-pcep-yang"?>
        <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pce-association-diversity"?>
        <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pce-segment-routing"?>
        <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.litkowski-pce-state-sync"?>
    </references>

    <section title="Contributor Addresses" toc="default">
    <t>
    <figure title="" suppress-title="false" align="left" alt="" width="" height="">
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Dhruv Dhody
Huawei Technologies
Divyashree toc="default" numbered="false">
      <name>Contributors</name>

    <contact fullname="Dhruv Dhody"
            initials="D"
            surname="Dhody">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Divyashree Techno Park, Whitefield
Bangalore, Karnataka  560066
India

EMail: dhruv.ietf@gmail.com
        ]]></artwork>
        </figure>
  </t>

  <t>
    <figure title="" suppress-title="false" align="left" alt="" width="" height="">
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Raveendra Torvi
Juniper Networks
1194 Whitefield</street>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <code>560066</code>
          <country>India</country>
        </postal>
        <email>dhruv.ietf@gmail.com</email>
      </address>
    </contact>

 <contact fullname="Raveendra Torvi" initials="R"
            surname="Torvi">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street>1194 N Mathilda Ave,
Sunnyvale, CA, 94086
USA

EMail: rtorvi@juniper.net

        ]]></artwork>
        </figure>
  </t>

  <t>
    <figure title="" suppress-title="false" align="left" alt="" width="" height="">
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Edward Crabbe
Individual Contributor

EMail: edward.crabbe@gmail.com
        ]]></artwork>
        </figure>
  </t> Ave</street>

          <city>Sunnyvale</city>

          <region>CA</region>

          <code>94086</code>

          <country>United States of America</country>
        </postal>

        <email>rtorvi@juniper.net</email>

      </address>
 </contact>

 <contact fullname="Edward Crabbe" initials="E" surname="Crabbe">
      <organization>Individual Contributor</organization>

      <address>
        <postal/>
        <email>edward.crabbe@gmail.com</email>

      </address>
 </contact>

    </section>
  </back>
</rfc>