<?xml version="1.0" encoding="windows-1252"?> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?> "rfc2629-xhtml.ent">

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

  <front>
    <title abbrev="Diversity-Assoc">Path abbrev="PCEP Extension for LSP Diversity Constraint Signaling">Path
    Computation Element Communication Protocol (PCEP) Extension for LSP Label
    Switched Path (LSP) Diversity Constraint Signaling </title>

    <seriesInfo name="RFC" value="8800"/>

    <author initials="S" surname="Litkowski" fullname="Stephane Litkowski">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>slitkows.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="S" surname="Sivabalan" fullname="Siva Sivabalan">
      <organization>Cisco Systems, Inc.</organization>
      <organization>Ciena Corporation</organization>
      <address>
        <postal>
          <street>2000 Innovation Drive</street>
          <city>Kanata</city>
          <region>Ontario</region>
          <code>K2K 3E8</code>
          <country>Canada</country>
        </postal>
        <email>msiva@cisco.com</email>
        <postal/>
        <email>msiva282@gmail.com</email>
      </address>
    </author>
    <author initials="C" surname="Barth" fullname="Colby Barth">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>cbarth@juniper.net</email>
      </address>
    </author>

    <author initials="M" surname="Negi" fullname="Mahendra Singh Negi">
      <organization>Huawei Technologies</organization>
      <organization>RtBrick India</organization>
      <address>
        <postal>
          <street>Divyashree Techno Park, Whitefield</street>
          <street>N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3</street>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <code>560066</code>
          <code>560102</code>
          <country>India</country>
        </postal>
        <email>mahend.ietf@gmail.com</email>
      </address>
    </author>
    <date year="2020"/> year="2020" month="July"/>
    <area>Routing</area>
    <workgroup>PCE Working Group</workgroup>

<keyword>Disjoint</keyword>
<keyword>Disjointness</keyword>
<keyword>Association</keyword>

    <abstract>
      <t>
   This document introduces a simple mechanism to associate a group of Label
   Switched Paths (LSPs) via an extension to the Path Computation Element (PCE) communication
   Communication Protocol (PCEP) with the purpose of computing diverse
   (disjointed) paths for those LSPs.  The proposed extension allows a Path
   Computation Client (PCC) to advertise to a PCE Path Computation Element (PCE)
   that a particular LSP belongs to a particular disjoint-group,
   thus Disjoint Association Group; thus, the PCE
   knows that the LSPs in the same group need to be disjoint from each
   other.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" toc="default"> toc="default" numbered="true">
      <name>Introduction</name>
      <t>
   <xref target="RFC5440"/> target="RFC5440" format="default"/> describes the Path Computation
   Element communication Communication
   Protocol (PCEP) (PCEP), which enables the communication between a Path
   Computation Client (PCC) and a Path Control Element (PCE), (PCE) or between
   two PCEs based on the PCE architecture <xref target="RFC4655"/>. target="RFC4655"
   format="default"/>.
      </t>
      <t>
   The PCEP Extensions for Stateful PCE Model <xref target="RFC8231"/> target="RFC8231" format="default"/>
   describes a set of extensions to PCEP to enable active control of
   MPLS-TE and GMPLS tunnels.
   <xref target="RFC8281"/> target="RFC8281" format="default"/>
   describes the setup and teardown of PCE-initiated LSPs under the
   active stateful PCE model, without the need for local configuration
   on the PCC, thus allowing for a dynamic network.
      </t>
      <t><xref target="I-D.ietf-pce-association-group"/> target="RFC8697" format="default"/> introduces a generic
   mechanism to create a grouping of LSPs in the context of a PCE which that can
   then be used to
   define associations between a set of LSPs and a set of attributes (such
   as configuration parameters or behaviors) and is equally applicable
   to the active and passive modes of a stateful PCE <xref target="RFC8231"/> target="RFC8231"
   format="default"/> or a stateless PCE <xref target="RFC5440"/>.</t> target="RFC4655"
   format="default"/>.</t>

      <t>This document specifies a PCEP extension to signal that a set of LSPs
      in a particular group should use diverse (disjointed) paths, including
      the requested type of diversity.  Sections <xref target="mot"/> target="mot"
      format="counter"/> and <xref target="app"/> target="app" format="counter"/> describe
      the property and use of a disjoint-group. Disjoint Association Group.  A PCC can use
      this extension to signal to a PCE that a particular LSP belongs to a
      particular disjoint-group. Disjoint Association Group.  When a PCE receives LSP states
      belonging to the same disjoint-group Disjoint Association Group from some
      PCCs, the PCE should ensure that the LSPs within the group are disjoint
      from each other.
      </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>
    <section title="Terminology" toc="default"> toc="default" numbered="true">
      <name>Terminology</name>
      <t>The following terminology is used in this document.</t>
      <t>
        <list style="hanging">
          <!--<t hangText="LSR:">Label Switch Router.</t>-->
          <t hangText="DAT:">Disjoint Association Type.</t>
          <t hangText="DAG:">Disjoint Association Group.</t>
          <t hangText="MPLS:">Multiprotocol
      <dl newline="false" spacing="normal" indent="10">

        <dt>DAT:</dt>
        <dd>Disjoint Association Type</dd>
        <dt>DAG:</dt>
        <dd>Disjoint Association Group</dd>
        <dt>MPLS:</dt>
        <dd>Multiprotocol Label Switching.</t>
          <t hangText="OF:">Objective Function.</t>
          <t hangText="PCC:">Path Switching</dd>
        <dt>OF:</dt>
        <dd>Objective Function</dd>
        <dt>PCC:</dt>
        <dd>Path Computation Client. Any client application requesting a
            path computation to be performed by a Path Computation Element.</t>
          <t hangText="PCE:">Path Element.</dd>
        <dt>PCE:</dt>
        <dd>Path Computation Element.  An entity (component, application,
            or network node) that is capable of computing a network path or
	route based on a network graph and applying computational constraints.</t>
          <t hangText="PCEP:">Path
	constraints.</dd>
        <dt>PCEP:</dt>
        <dd>Path Computation Element communication Protocol.</t>
          <t hangText="SRLG:">Shared Communication Protocol</dd>
        <dt>PLSP-ID:</dt>
        <dd>PCEP-specific identifier for the LSP</dd>
        <dt>SRLG:</dt>
        <dd>Shared Risk Link Group.</t>
        </list>
      </t> Group</dd>
      </dl>
    </section>
    <section title="Motivation" toc="default" anchor="mot"> anchor="mot" numbered="true">
      <name>Motivation</name>
      <t>Path diversity is a very common use case in today's IP/MPLS networks networks,
      especially for layer 2 transport over MPLS.
   A customer may request that the operator provide two end-to-end disjoint
   paths across the operator's IP/MPLS core.
   The customer may use these paths as primary/backup or active/active
   configuration.
      </t>
      <t>Different levels of disjointness may be offered:
   <list style="symbols">
   <t>Link
      </t>
      <ul spacing="normal">
        <li>Link disjointness: the paths of the associated LSPs should transit
	different links (but may use common nodes or different links that may
	have some shared
      fate).
</t>
   <t>Node fate).</li>
        <li>Node disjointness: the paths of the associated LSPs should transit
	different nodes (but may use different links that may have some shared fate).
</t>
   <t>SRLG
	fate).</li>
        <li>SRLG disjointness: the paths of the associated LSPs should transit
	different links that do not share fate (but may use common transit nodes).
</t>
   <t>Node+SRLG
	nodes).</li>
        <li>Node+SRLG disjointness: the paths of the associated LSPs should
	transit different links that do not have any common shared fate and
	should transit different nodes.
</t>
   </list>
   </t> nodes.</li>
      </ul>
      <t>
   The associated LSPs may originate from the same or from different head-end(s)
   head end(s) and may terminate at the same or different tail-end(s). tail end(s).
      </t>
    </section>
    <section title="Applicability" toc="default" anchor="app">
     <figure title="Figure 1 - Disjoint paths anchor="app" numbered="true">
      <name>Applicability</name>
      <figure>
        <name>Disjoint Paths with different head-ends Different Head Ends and tail-ends" suppress-title="false">
     <artwork>
	Tail Ends</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
         _________________________________________
        /                                         \
       /        +------+                           \
      |         | PCE  |                            |
      |         +------+                            |
      |                                             |
      |          ***********************&gt;          ***********************>           |
      | +------+           10             +------+  |
CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2
      | +------+       |        |         +------+  |
      |                |        |                   |
      |                |        |                   |
      | +------+       |        |         +------+  |
CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4
      | +------+ ***********************&gt; ***********************> +------+  |
      |                                             |
       \                                           /
        \_________________________________________/

    </artwork>

]]></artwork>
      </figure>
      <t>
   In the figure above, let us consider that the customer wants to have two
   disjoint paths, one between CE1 and CE2 and one between CE3 and CE4. From
   an IP/MPLS network point view, in this example, the CEs are connected to
   different PEs to maximize their disjointness.
   When LSPs originate from different head-ends, head ends, distributed computation of
   diverse paths can be difficult, whereas, whereas computation via a centralized PCE
   ensures path disjointness, correctness correctness, and simplicity.
      </t>
      <t><xref target="svec"/> target="svec" format="default"/> describes the relationship
      between the Disjoint Association Group (DAG) and Synchronization VECtor
      (SVEC) object.</t>
<t>
The PCEP extension for stateful PCE <xref target="RFC8231"/> target="RFC8231" format="default"/>
defined new PCEP messages - -- Path Computation Report (PCRpt), Path Computation
Update (PCUpd) (PCUpd), and Path Computation Initiate (PCInitiate) <xref target="RFC8281"/>.
target="RFC8281" format="default"/>. These messages use a PLSP-ID in the LSP
object for identification. Moreover

Moreover, to allow diversity between LSPs originating from different PCCs, the
generic mechanism to create a grouping of LSPs is described in <xref target="I-D.ietf-pce-association-group"/>
(that that is equally applicable to
the active and passive modes of a stateful PCE).
</t> PCE is described in <xref
target="RFC8697" format="default"/>.</t>
      <t>
Using the extension to PCEP defined in this document, the PCC uses the <xref target="I-D.ietf-pce-association-group"/>
extension defined in <xref target="RFC8697" format="default"/> to indicate
that a group of LSPs are required to be disjoint; such indication should
include disjointness parameters such as like the type of disjointness, the disjoint group Disjoint
Association Group identifiers, and any customization parameters according to the
configured local policy.</t>
      <t>
The management of the disjoint group Disjoint Association Group IDs will be a key point for the operator
as the Association ID field is limited to 65535. The local configuration of
the IPv4/IPv6 association source, Association Source, or Global Association Source/Extended
Association ID allows to ID, can overcome this limitation limitation, as described in <xref target="I-D.ietf-pce-association-group"/>.
target="RFC8697" format="default"/>.
When a PCC or PCE initiates all the LSPs in a particular disjoint-group, Disjoint Association Group, it
can set the IPv4/IPv6 association source Association Source as one of its own IP address. When
disjoint LSPs are initiated from different head-ends, head ends, the association source Association Source
could be the PCE address or any other unique value to identify the DAG.
</t>

<t><figure title="Figure 2 - Sample use-cases
      <figure>
        <name>Sample Use Cases for carrying disjoint-group Carrying Disjoint Association Group over
	PCEP session" suppress-title="false" align="left" alt="" width="" height=""> Session</name>
        <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[ alt=""><![CDATA[
        Initiate Disjoint LSPs
                 |
                 |                       PCReq/PCRpt
                 V                        {DAG Y}
              +-----+                ----------------> +-----+
   _ _ _ _ _ _| PCE |               |                  | PCE |
  |           +-----+               |      ----------> +-----+
  | PCInitiate                      |     |    PCReq/PCRpt
  |{DAG X}                          |     | {DAG Y}
  |                                 |     |
  |              .-----.            |     |         .-----.
  |             (       )           | +-----+      (       )
  |         .--(         )--.       | |PCC 2|--.--(         )--.
  V        (                 )      | +-----+ (                 )
+---+     (                  )      |        (                  )
|PCC|----(   (G)MPLS network )   +-----+    ( (G)MPLS network   )
+---+    (                   )   |PCC 1|-----(                  )
{DAG X}   (                 )    +-----+      (                )
           '--(         )--'                   (           )--'
               (       )                         (        )
                '-----'                            '-----'

Case 1: Disjointness initiated by   Case 2: Disjointness initiated by
    PCE and enforced by PCC              PCC and enforced by PCE
]]></artwork>
          </figure></t>
   <t>Using the disjoint-group
      </figure>

      <t>The Disjoint Association Group within a PCEP messages is used for:
   <list style="symbols">
   <t>Configuration:
      </t>
      <ul spacing="normal">
        <li>Configuration: Used to communicate the configured disjoint
	requirement to a PCEP peer.</t>
   <t>Status: peer.</li>
        <li>Status: Used to communicate the status of the computed disjointness.</t>
   </list>
   </t>
	disjointness.</li>
      </ul>
    </section>
    <section title="Protocol Extension" toc="default"> toc="default" numbered="true">
      <name>Protocol Extension</name>
      <section title="Association Group" anchor="encoding" toc="default"> toc="default" numbered="true">
        <name>Association Group</name>
        <t>As per <xref target="I-D.ietf-pce-association-group"/>, target="RFC8697" format="default"/>, LSPs
     are associated with other LSPs with which they interact by adding
     them to a common association group. As described in <xref target="I-D.ietf-pce-association-group"/>
     target="RFC8697" format="default"/>, the association group is uniquely
	identified by the combination of these the following fields in the ASSOCIATION
	object: Association Type, Association ID, Association Source, and (if
	present) Global Association Source or Extended Association ID.</t>

        <t>This document defines a new Association type, called "Disjoint
        Association" (2), based on the generic ASSOCIATION object. This new
        Association object:
      <list style="symbols">
      <t>Association type = TBD1 Disjoint is also called "DAT", for "Disjoint Association Type (DAT).</t>
      </list>
      </t>
        Type".</t>

        <t><xref target="I-D.ietf-pce-association-group"/> target="RFC8697" format="default"/> specifies the mechanism
	for the capability advertisement of the association 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 DAT (TBD1) MUST (2) <bcp14>MUST</bcp14> be done
	before using the disjointness disjoint association. Thus Thus, the PCEP speaker MUST <bcp14>MUST</bcp14>
	include the DAT in the ASSOC-Type-List TLV and MUST <bcp14>MUST</bcp14> receive the same
	from the PCEP peer before using the Disjoint Association Group (DAG)
	in PCEP messages.</t>
        <t>This association Association type is considered to be both dynamic and
	operator-configured in nature. As per <xref target="I-D.ietf-pce-association-group"/>, target="RFC8697"
	format="default"/>, the association group could be manually created by the
	operator manually on the PCEP peers peers, and the LSPs belonging to this associations is
	association are conveyed via PCEP messages to the PCEP peer; or alternately, the
	association group could be created dynamically by the PCEP speaker speaker, and
	both the association group information and the LSPs belonging to the
	association group is are conveyed to the PCEP peer. The Operator-configured
   Association Range MUST <bcp14>MUST</bcp14> be set for this association-type to mark a range of association identifiers
   Association Identifiers that
   are used for operator-configured associations to avoid any
   association identifier
   Association Identifier clash within the scope of the association
   source. Association
   Source. (Refer to <xref target="I-D.ietf-pce-association-group"/>.)</t> target="RFC8697" format="default"/>.)</t>
        <t>A disjoint group Disjoint Association Group can have two or more LSPs, but a PCE may be
	limited in the number of LSPs it can take into account when computing
	disjointness.
   If a PCE receives more LSPs in the group than it can handle in its
	computation algorithm, it SHOULD <bcp14>SHOULD</bcp14> apply disjointness computation to
	only a subset of LSPs in the group. The subset of disjoint LSPs will
	be decided by PCE as a local policy. Local polices MAY <bcp14>MAY</bcp14> define the
	computational behavior for the other LSPs in the group.  For example,
	the PCE may provide no path, a shortest path, or a constrained path
	based on relaxing disjointness, etc. The disjoint status of the
	computed path is informed to the PCC via DISJOINTNESS-STATUS-TLV the DISJOINTNESS-STATUS TLV (see
	<xref target="tlvs"/>).</t> target="tlvs" format="default"/>).</t>
        <t>There are differet different types of disjointness identified by the flags
	(T, S, N, and L) in the DISJOINTNESS-CONFIGURATION-TLV DISJOINTNESS-CONFIGURATION TLV (see <xref target="tlvs"/>).
	target="tlvs" format="default"/>). All LSPs in a particular disjoint group MUST Disjoint
	Association Group <bcp14>MUST</bcp14> use the same combination of T, S, N, and L flags in the DISJOINTNESS-CONFIGURATION-TLV.
	DISJOINTNESS-CONFIGURATION TLV.  If a PCEP peer receives a PCEP messages
	message for LSPs belonging to the same disjoint group Disjoint Association Group but having an
	inconsistent combination of T, S, N, and L flags, the PCEP peer MUST NOT <bcp14>MUST NOT</bcp14>
	add the LSPs to the disjoint group Disjoint Association Group and MUST <bcp14>MUST</bcp14> reply with a PCErr with Error-type
	Error-Type 26 (Association Error) and Error-Value Error-value 6 (Association
	information mismatch).</t>

    <!--<t>Associating a particular LSP to multiple disjoint groups is authorized from a protocol perspective, however there is no assurance that the PCE will be able to compute properly the multi-disjointness constraint.</t>-->

    <t>A particular LSP MAY <bcp14>MAY</bcp14> be associated to the multiple disjoint groups, Disjoint
    Association Groups, but in that case, the PCE SHOULD <bcp14>SHOULD</bcp14> try to
    consider all the disjoint groups Disjoint Association Groups during path computation computation, if
    possible. Otherwise Otherwise, a local policy MAY <bcp14>MAY</bcp14> define the
    computational behavior.

If a PCE does not support such a path computation computation, it MUST NOT <bcp14>MUST NOT</bcp14>
add the LSP into the association group and <bcp14>MUST</bcp14> return a PCErr with Error-type Error-Type 26
(Association Error) and Error-Value Error-value 7 (Cannot join the association group).</t>
      </section>
      <section title="Disjoint TLVs" anchor="tlvs" toc="default"> toc="default" numbered="true">
        <name>Disjoint TLVs</name>

        <t>
    The disjoint group Disjoint Association Group (ASSOCIATION object with Association type = TBD1
    2 for DAT) MUST <bcp14>MUST</bcp14> carry the following TLV:
    <list style="symbols">
    <t>DISJOINTNESS-CONFIGURATION-TLV:
        </t>
        <ul spacing="normal">
          <li>DISJOINTNESS-CONFIGURATION TLV: Used to communicate some
	  disjointness configuration parameters. This is applicable for all
	  PCEP message messages that includes DAG.</t>
    </list>
    </t> include DAG.</li>
        </ul>
        <t>
    In addition, the disjoint group Disjoint Association Group (ASSOCIATION object with Association type
    = TBD1 2 for DAT) MAY <bcp14>MAY</bcp14> carry the following TLVs:
    <list style="symbols">
    <t>DISJOINTNESS-STATUS-TLV:
        </t>
        <ul spacing="normal">
          <li>DISJOINTNESS-STATUS TLV: Used to communicate the status of the
	  computed disjointness. This is applicable for messages from a PCE to
	  a PCC only (i.e. (i.e., PCUpd, PCInitiate PCInitiate, or PCRep message).</t>
  <t>VENDOR-INFORMATION-TLV: messages).</li>

          <li>VENDOR-INFORMATION-TLV: Used to communicate arbitrary
	  vendor-specific behavioral information, described in <xref target="RFC7470"/>.</t>
   <t>OF-List
	  target="RFC7470" format="default"/>.</li>
          <li>OF-List TLV: Used to communicate the disjointness objective
	  function. See <xref target="Disjointness-objective-functions"/>.</t>
    </list>
    </t> target="Disjointness-objective-functions"
	  format="default"/>.</li>
        </ul>
        <t>
    The DISJOINTNESS-CONFIGURATION-TLV DISJOINTNESS-CONFIGURATION TLV is shown in the following figure:
        </t>
<figure>
  <artwork>
<name>DISJOINTNESS-CONFIGURATION TLV</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 46             |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Flags                               |T|P|S|N|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    </artwork>
    </figure></t>
      <t> Type: TBD2. </t>
    <t> Length: Fixed
]]></artwork>
</figure>

	<dl newline="false" spacing="normal">
        <dt>Type:</dt>
	<dd>46</dd>
        <dt> Length:</dt>
	<dd>Fixed value of 4 bytes.

      <list style="none">
      <t>Flags:
        <list style="symbols">
        <t>L bytes.</dd>

            <dt>Flags:</dt>

            <dd><t><br/></t><dl newline="false" spacing="normal">
              <dt>L (Link diverse) bit: when Diverse) bit:</dt><dd>When set, this indicates that
              the computed paths within the disjoint group MUST NOT Disjoint Association Group
              <bcp14>MUST NOT</bcp14> have any link in common.</t>
        <t>N common.</dd>
              <dt>N (Node diverse) bit: when Diverse) bit:</dt><dd>When set, this indicates that
              the computed paths within the disjoint group MUST NOT Disjoint Association Group
              <bcp14>MUST NOT</bcp14> have any node in common.</t>
        <t>S common.</dd>
              <dt>S (SRLG diverse) bit: when Diverse) bit:</dt><dd>When set, this indicates that
              the computed paths within the disjoint group MUST NOT Disjoint Association Group
              <bcp14>MUST NOT</bcp14> share any SRLG (Shared Risk Link
         Group).</t>
        <t>P
              Group).</dd>
              <dt>P (Shortest path) bit: when Path) bit:</dt><dd>When set, this indicates that the
	      computed path of the LSP SHOULD <bcp14>SHOULD</bcp14> satisfy all the constraints and
	      objective functions first without considering the diversity constraint, this
	      constraint. This means that all of the LSPs with P flag set in
	      the association group are computed first first, as if the disjointness
	      constraint has not been configured, and then configured; then, with those LSPs
	      fixed, the other LSPs with P flag unset in the association group
	      are computed by taking into account the disjointness
	      constraint. The role of P flag is further described with
	      examples in <xref target="P-Flag-Consideration"/>.</t>
        <t>T target="P-Flag-Consideration"
	      format="default"/>.</dd>
              <dt>T (Strict disjointness) bit: when Disjointness) bit:</dt><dd>When set, if disjoint
              paths cannot be found, the PCE MUST <bcp14>MUST</bcp14> return no
              path for LSPs that could not be be disjoint. When unset, the PCE is
              allowed to relax disjointness by <xref target="P-Flag-Consideration"/> either applying a requested
              objective function (cf. <xref target="Disjointness-objective-functions"/> below) (cf.&nbsp;<xref
              target="Disjointness-objective-functions" format="default"/>)
              or using the local policy if no objective function is requested (e.g.
              (e.g., using a lower disjoint type (link instead of node) or
              fully relaxing disjointness constraint). Further see  See <xref target="dis"/> target="dis"
              format="default"/> for details.</t>

        <t>Unassigned further details.</dd>
              <dt>Unassigned bits:</dt><dd>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>
      </list>
      </t> receipt.</dd>

	    </dl></dd>
        </dl>

        <t>
      If a PCEP speaker receives a disjoint-group Disjoint Association Group (ASSOCIATION object with
      Association type = TBD1 2 for DAT) without DISJOINTNESS-CONFIGURATION-TLV, the DISJOINTNESS-CONFIGURATION TLV,
      it SHOULD <bcp14>SHOULD</bcp14> reply with a PCErr Error-type=6 Error-Type 6 (Mandatory Object missing) and Error-value=TBD10 (DISJOINTNESS-CONFIGURATION-TLV
      Error-value 15 (DISJOINTNESS-CONFIGURATION TLV missing).
        </t>
        <t>The DISJOINTNESS-STATUS-TLV DISJOINTNESS-STATUS TLV uses the same format as the DISJOINTNESS-CONFIGURATION-TLV
	DISJOINTNESS-CONFIGURATION TLV with a different type TBD3 47 (in the
	TLV). The L, N, and S flags are set if the respective disjointness
	criterion was requested and the computed paths meet it. The P flag
	indicates that the computed path is the shortest path (computed first
	without taking disjointness constraints into consideration, consideration but
	considering other constraints).</t>
        <t>The T flag has no meaning in the DISJOINTNESS-STATUS-TLV DISJOINTNESS-STATUS TLV and MUST NOT <bcp14>MUST
	NOT</bcp14> be set while sending and MUST <bcp14>MUST</bcp14> be ignored on receipt.
    <!--<figure>
    <artwork>
       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 = [TBD3]         |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Flags                               |T|P|S|N|L|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    </artwork>
    </figure>     -->

        </t>
        <t>Any document defining a new flag for the DISJOINTNESS-CONFIGURATION-TLV
	DISJOINTNESS-CONFIGURATION TLV automatically defines a new flag with
	the same name and in the same location in DISJOINTNESS-STATUS-TLV; DISJOINTNESS-STATUS TLV; the
	semantics of the flag in DISJOINTNESS-STATUS-TLV MUST the DISJOINTNESS-STATUS TLV <bcp14>MUST</bcp14> be specified in
	the document that specifies the flag in DISJOINTNESS-CONFIGURATION-TLV. the
	DISJOINTNESS-CONFIGURATION TLV.
        </t>
      </section>
      <section anchor="Disjointness-objective-functions" title="Disjointness numbered="true"
	       toc="default">
        <name>Disjointness Objective Functions">
      <t>
      An Functions</name>
        <t>An objective function (OF) MAY <bcp14>MAY</bcp14> be applied to the disjointness
      computation to drive the PCE computation behavior.  In this case, the
      OF-List TLV (defined in (<xref target="RFC5541"/>) <xref target="RFC5541" format="default"/>) is
      used as an optional TLV in the Association
   Group Object. ASSOCIATION object. Whereas the
      PCEP OF-List TLV allows multiple OF-codes inside the TLV, a sender SHOULD
      <bcp14>SHOULD</bcp14> include a single OF-code in the OF-List TLV when included in the
	Association Group, and the receiver MUST <bcp14>MUST</bcp14> consider the first OF-code
	only and ignore others if included.
      </t>
      <t>
      To included.</t>

        <t>To minimize the common shared resources (Node, Link Link, or SRLG)
        between a set of paths during path computation computation, three new OF-codes are
   proposed:
      </t>
        defined:</t>

        <t>MSL</t>
      <t>
      <list style="hanging">
      <t hangText="* Name:">Minimize
<ul empty="true"><li>
        <dl newline="false" spacing="compact">
          <dt>Name:</dt>
	  <dd>Minimize the number of shared Shared (common) Links.</t>
      <t hangText="* Objective Links.</dd>
          <dt>Objective Function Code:">TBD4</t>
      <t hangText="* Description:">Find Code:</dt>
	  <dd>15</dd>
          <dt>Description:</dt>
	  <dd>
	    <t>Find a set of paths such that it passes through the least
	    number of shared (common) links.
      <list style="symbols">
                 <t>A links.</t>
            <ul spacing="compact">
              <li>A network comprises a set of N links {Li, (i=1...N)}.</t>

         <t>A (i=1...N)}.</li>
              <li>A path P passes through K links {Lpi,(i=1...K)}.</t>

         <t>A {Lpi,(i=1...K)}.</li>
              <li>A set of paths {P1...Pm} have L links that are
            common to more than one path {Lci,(i=1...L)}.</t>

         <t>Find {Lci,(i=1...L)}.</li>
              <li>Find a set of paths such that the value of L is minimized.</t>
      </list></t>
      </list>
      </t>
	      minimized.</li>
            </ul>
	  </dd>
	</dl>
</li></ul>

      <t>MSS</t>
      <t>
      <list style="hanging">
      <t hangText="* Name:">Minimize
<ul empty="true"><li>
        <dl newline="false" spacing="compact">
          <dt>Name:</dt>
          <dd>Minimize the number of shared Shared (common) SRLGs.</t>
      <t hangText="* Objective SRLGs.</dd>
          <dt>Objective Function Code:">TBD5</t>
      <t hangText="* Description:">Find Code:</dt>
          <dd>16</dd>
          <dt>Description:</dt>
          <dd>
            <t>Find a set of paths such that it passes through the least
	    number of shared (common) SRLGs.
            <list style="symbols">
                 <t>A
            </t>
            <ul spacing="compact">
              <li>A network comprises a set of N links {Li, (i=1...N)}.</t>

         <t>A (i=1...N)}.</li>
              <li>A path P passes through K links {Lpi,(i=1...K)} belonging to
	      unique M SRLGs {Spi,(i=1..M)}.</t>

         <t>A {Spi,(i=1..M)}.</li>
              <li>A set of paths {P1...Pm} have L SRLGs that are
            common to more than one path {Sci,(i=1...L)}.</t>

         <t>Find {Sci,(i=1...L)}.</li>
              <li>Find a set of paths such that the value of L is minimized.</t>
      </list></t>
      </list>
      </t>
	      minimized.</li>
            </ul>
          </dd>
        </dl>
</li></ul>

        <t>MSN</t>
      <t>
      <list style="hanging">
      <t hangText="* Name:">Minimize
<ul empty="true"><li>
        <dl newline="false" spacing="compact">
          <dt>Name:</dt>
          <dd>Minimize the number of shared Shared (common) Nodes.</t>
      <t hangText="* Objective Nodes.</dd>
          <dt>Objective Function Code:">TBD6</t>
      <t hangText="* Description:">Find Code:</dt>
          <dd>17</dd>
          <dt>Description:</dt>
          <dd>
            <t>Find a set of paths such that they pass through the least
	    number of shared (common) nodes.
            <list style="symbols">
                 <t>A
            </t>
            <ul spacing="compact">
              <li>A network comprises a set of N nodes {Ni, (i=1...N)}.</t>

         <t>A (i=1...N)}.</li>
              <li>A path P passes through K nodes {Npi,(i=1...K)}.</t>

         <t>A {Npi,(i=1...K)}.</li>
              <li>A set of paths {P1...Pm} have L nodes that are
            common to more than one path {Nci,(i=1...L)}.</t>

         <t>Find {Nci,(i=1...L)}.</li>
              <li>Find a set of paths such that the value of L is minimized.</t>
      </list></t>
      </list>
      </t>
	      minimized.</li>
            </ul>
          </dd>
        </dl>
      </li></ul>

        <t>If the OF-list OF-List TLV is included in the Association Object, ASSOCIATION object,
   the first OF-code inside the OF Object MUST object <bcp14>MUST</bcp14> be one of the disjoint OFs
   defined in this document. If this condition is not met, the PCEP speaker MUST
   <bcp14>MUST</bcp14> respond with a PCErr message with Error-Type=10 Error-Type 10 (Reception of an
   invalid object) and
   Error-Value=TBD9 Error-value 32 (Incompatible OF code).</t>
      </section>
      <!-- Disjointness-objective-functions -->

     <section title="Relationship to SVEC" toc="default" anchor="svec"> anchor="svec" numbered="true">
        <name>Relationship to SVEC</name>
        <t><xref target="RFC5440"/> target="RFC5440" format="default"/> defines a mechanism for
	the synchronization of a set of path computation requests by using the
	SVEC object, that which specifies the list of synchronized requests that can
   either
	be either dependent or independent.  The SVEC object identifies the
   relationship between the set of path computation requests, identified by
   'Request-ID-number' in the RP (Request Parameters) object.  <xref target="RFC6007"/>
   target="RFC6007" format="default"/> further clarified clarifies the use of the SVEC
   list for synchronized path computations when computing dependent requests as well as described
   and describes a number of usage scenarios for SVEC lists within
	single-domain and multi-domain environments.</t>
        <t>The SVEC object includes a Flags field that indicates the potential
        dependency between the set of path computation requests in a similar
        way as the Flags field in the TLVs defined in this document.  The path
        computation request in the PCReq Path Computation Request (PCReq) message MAY
        <bcp14>MAY</bcp14> use both the SVEC and ASSOCIATION objects to
        identify the related path computation request request, as well as the DAG.
        The PCE MUST <bcp14>MUST</bcp14> try to find a path that meets both the
        constraints.  It is possible that the diversity requirement in the
        association group is different from the one in the SVEC object.  The
        PCE MUST <bcp14>MUST</bcp14> consider both the objects (including the flags
        set inside the objects) as per the processing rules and aim to find a
        path that meets both of these constraints. In case no such path is
        possible, the PCE MUST <bcp14>MUST</bcp14> send a path computation reply
	Path Computation Reply
        (PCRep) with a NO-PATH object indicating path computation failure failure, as
        per <xref target="RFC5440"/>. target="RFC5440" format="default"/>. It should be noted that
        the LSPs in the association group can be fully same or partially
        overlapping with the LSPs grouped by the SVEC object in PCReq
        message.</t>
        <t>Some examples of usage are listed below:
        </t>
        <t>
        <list style="symbols">
        <t> below:</t>
        <ul spacing="normal">
          <li>
        PCReq with SVEC object with node-diverse bit=1 (LSP1,LSP2) and DAG
	with S=1 (LSP1,LSP2) - both node node- and SRLG diverse SRLG-diverse path between LSP1, LSP1 and
	LSP2.
        </t>
        <t>
        </li>
          <li>
        PCReq with SVEC object with link-diverse bit=1 (LSP1,LSP2) and DAG
	with L=1 (LSP1,LSP3) - link diverse link-diverse paths between LSP1 &amp; LSP2, and LSP2 and between
	LSP1 &amp; and LSP3. If the DAG is part of the stateful database, any
	future change in LSP3 will have an impact on LSP1. But any future
	change in LSP2 will have no impact on LSP1, as LSP2 is part of SVEC
	object (which is considered once on receipt of the PCReq message
	only).
        </t>
        </list>
        </t>
        </li>
        </ul>
        <section title="SVEC and OF" toc="default" anchor="svec-of"> anchor="svec-of" numbered="true">
          <name>SVEC and OF</name>
          <t>This document defines three new OF-codes in <xref target="Disjointness-objective-functions"/>
	  target="Disjointness-objective-functions" format="default"/> to
	  maximize diversity as much as possible, in possible. In other words, new OF-codes
	  allow specification of minimization of common shared resources
	  (Node, Link Link, or SRLG) among a set of paths during path
	  computation.</t>
      <t>
        It
          <t>It may be interesting to note that the diversity flags in the
	  SVEC	object and OF for diversity can be used together. Some
	  examples of usage are listed below:
        </t>
        <t>
        <list style="symbols">
        <t>
        SVEC below:</t>
          <ul spacing="normal">
            <li>SVEC object with node-diverse bit=1 - ensure full node-diversity.
        </t>
        <t>
        SVEC
	    node diversity.</li>
            <li>SVEC object with node-diverse bit=1 and OF=MSS - full node diverse
	    diversity with as much SRLG diversity as SRLG-diversity as possible.
        </t>
        <t>
        SVEC possible.</li>
            <li>SVEC object with domain-diverse bit=1;link diverse bit=1 <xref target="RFC8685"/>; node-diverse bit=1, and
	    OF=MSS - full domain and node diverse path diversity with as much
	    SRLG diversity as SRLG-diversity as possible.
        </t>
        <t>
        SVEC possible.</li>
            <li>SVEC object with node-diverse bit=1 and OF=MSN - ensure full node-diversity.
        </t>
        </list>
        </t>
        <t>
        In
	    node diversity.</li>
          </ul>

          <t>In the last example above, it is interesting to note that "OF"
	  becomes redundant as "SVEC object" ensures full node-diversity, however node diversity;
	  however, this specification does not prohibit redundant constraints
	  while using "SVEC object" and "OF" together for diversity.
        </t> diversity.</t>
        </section>
      </section>
      <section title="P Flag Considerations" toc="default" anchor="P-Flag-Consideration"> anchor="P-Flag-Consideration" numbered="true">
        <name>P Flag Considerations</name>
        <t>As mentioned in <xref target="tlvs"/>, target="tlvs" format="default"/>, the P flag
	(when set) indicates that the computed path of the LSP SHOULD satisfies <bcp14>SHOULD</bcp14>
	satisfy all constraints and objective functions first without
	considering the diversity constraint.</t>
        <t>This means that an LSP with the P flag set should be placed first first, as if
	the disjointness constraint has not been configured, while the other
	LSPs in the association with the P flag unset should be placed by taking
	into account the disjointness constraint. Setting the P flag changes
	the relationship between LSPs to a one-sided relationship (LSP 1 with
	P=0 depends on LSP 2 with P=1, but LSP 2 with P=1 does not depend of on
	LSP 1 with P=0). Multiple LSPs in the same disjoint group Disjoint Association Group may have the
	P flag set. In such a case, those LSPs may not be disjoint from each
	other but will be disjoint from other LSPs in the group that have the
	P flag unset.</t>
        <t>This could be required in some primary/backup scenarios where the
        primary path should use the more optimal path available (taking into
        account the other constraints).  When disjointness is computed, it is
        important for the algorithm to know that it should try to optimize the
        path of one or more LSPs in the disjoint group Disjoint Association Group (for instance
        instance, the primary path) path), while other paths are allowed to be
        costlier (compared to a similar path without the disjointness
        constraint).  Without such a hint, the disjointness algorithm may set
        a path for all LSPs that may not completely fulfill the customer's
        requirement.</t>
        <figure title="Figure 3">
     <artwork> anchor="fig4">
          <name>Example Topology with Six Internal Routers</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
         _________________________________________
        /                                         \
       /        +------+                           \
      |         | PCE  |                            |
      |         +------+                            |
      |                                             |
      |                                             |
      | +------+           10             +------+  |
CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2
      | +------+       |        |         +------+  |
      |                |        |                   |
      |                |        |                   |
      | +------+       |        |         +------+  |
CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4
      | +------+ \     |               /  +------+  |
      |           \    |     10       /             |
       \           +-- R5 --------- R6             /
        \_________________________________________/

Cost

]]></artwork>
        </figure>
<t>Note: In <xref target="fig4"/>, the cost of all the links is 1, unless explicitly marked otherwise.
      </artwork>
      </figure>
      <t>
      In
</t>
        <t>In the figure above, a customer has two dual homed dual-homed sites (CE1/CE3
	and CE2/CE4). Let us consider that this customer wants two link
	disjoint paths between the two sites. Due to physical meshing, the
	customer wants to use CE1 and CE2 as the primary (and CE3 and CE4 are
	hosted in a remote site for redundancy purpose).
      </t> purpose).</t>
        <t>Without any hint (constraint) provided, the PCE may compute the two
	link disjoint LSPs together, leading to PE1-&gt;PE2 using a path
	PE1-&gt;R1-&gt;R2-&gt;PE2 and PE3-&gt;PE4 using
	PE3-&gt;R3-&gt;R4-&gt;PE4. In this case, even if the disjointness
	constraint is fulfilled, the path from PE1 to PE2 does not use the
	best optimal path available in the network (path delay may be higher): higher);
	the customer requirement is thus not completely fulfilled.
      </t> fulfilled.</t>
        <t>The usage of the P flag allows the PCE to know that a particular
	LSP should be tied to the best path path, as if the disjointness constraint
	was not requested.</t>
        <t>In our example, if the P flag is set to the LSP PE1-&gt;PE2, the
	PCE should use the path PE1-&gt;R1-&gt;R3-&gt;R4-&gt;R2-&gt;PE2 for
	this LSP, while the other LSP should be link disjoint from this
	path. The second LSP will be placed on PE3-&gt;R5-&gt;R6-&gt;PE4 PE3-&gt;R5-&gt;R6-&gt;PE4, as it
	is allowed to be costlier.</t>
      <t>
      Driving
        <t>Driving the PCE disjointness computation may be done in other ways,
	for instance instance, setting a metric boundary reflecting an a path delay
	boundary. Other constraints may also be used.</t>

        <t>The P flag allows to simply express that the disjointness
	constraint should not make the LSP worst.</t>
      <t>
      Any
        <t>Any constraint added to a path disjointness computation may reduce
	the chance to find suitable paths. The usage of the P flag, as any
	other constraint, may prevent to find finding a disjoint path. In the example
	above, if we consider that the router R5 is down, down and if PE1-&gt;PE2 has
	the P flag set, there is no room available to place PE3-&gt;PE4 (the
	link disjointness constraint cannot be fulfilled). If PE1-&gt;PE2 has
	the P flag unset, the algorithm may be able to place PE1-&gt;PE2 on the
	R1-&gt;R2 link leaving a room for PE3-&gt;PE4 using the R3-&gt;R4
	link. When using the P flag or any additional constraint on top of the
	disjointness constraint, the user should be aware that there is less
	chance to fulfill the disjointness constraint.
      </t> constraint.</t>
        <figure title="Figure 4">
     <artwork> anchor="fig5">
          <name>Example Topology with Four Internal Routers</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
         _________________________________________
        /                                         \
       /        +------+                           \
      |         | PCE  |                            |
      |         +------+                            |
      |                                             |
      |                                             |
      | +------+           10             +------+  |
CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2
      | +------+       |  \     |         +------+  |
      |                |   \2   |                   |
      |                |    \   |                   |
      | +------+       |     \  |         +------+  |
CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4
      | +------+                          +------+  |
      |                                             |
       \                                           /
        \_________________________________________/

Cost

]]></artwork>
        </figure>
<t>Note: In <xref target="fig5"/>, the cost of all the links is 1, unless
explicitly marked otherwise.
      </artwork>
      </figure>
      <t>
      In </t>

        <t>In the figure above, we still consider the same previous
	requirements, so PE1-&gt;PE2 LSP should be optimized (P flag set) set),
	while PE3-&gt;PE4 should be link disjoint and may use a costlier path.
      </t>
      <t>
      Regarding
	path.</t>
        <t>Regarding PE1-&gt;PE2, there are two paths that are satisfying the
	constraints (ECMP): PE1-&gt;R1-&gt;R4-&gt;R2-&gt;PE2 (path 1) and
	PE1-&gt;R1-&gt;R3-&gt;R4-&gt;R2-&gt;PE2 (path 2). An implementation
	may choose one of the paths<!-- or even use both (using both may happen in case Segment Routing TE is used, allowing ECMP)-->.
      </t> paths.</t>
        <t>If the implementation elects only one path, there is a chance that
	picking up one path may prevent link disjointness. In our example, if
	path 2 is used for PE1-&gt;PE2, there is no room left for PE3-&gt;PE4 PE3-&gt;PE4,
	while if path 1 is used, PE3-&gt;PE4 can be placed on R3-&gt;R4
	link.</t>
        <t>When the P flag is set for an LSP and when ECMPs are available, an
	implementation should aim to select a path that allows
	disjointness.</t>
      </section>
      <section title="Disjointness Computation Issues" toc="default" anchor="dis"> anchor="dis" numbered="true">
        <name>Disjointness Computation Issues</name>
        <t>There may be some cases where the PCE is not able to provide a set
	of disjoint paths for one or more LSPs in the association.</t>
        <t>When the T flag is set (Strict disjointness requested), disjointness), if
	disjointness cannot be ensured for one or more LSPs, the PCE MUST <bcp14>MUST</bcp14>
	reply to a Path Computation Request (PCReq) PCReq with a Path Computation Reply (PCRep)
	PCRep message containing a NO-PATH object. In case of a PCRpt
	message, the PCE MUST <bcp14>MUST</bcp14> return a PCErr message with Error-Type 26 "Association
      Error"
	(Association Error) and Error-Value Error-value 7 "Cannot (Cannot join the association group".</t> group).</t>
        <t>In case of a network event leading to an impossible strict
	disjointness, the PCE MUST <bcp14>MUST</bcp14> send a PCUpd message containing an empty ERO
	Explicit Route Object (ERO) to the corresponding PCCs. In addition to
	the empty ERO Object, object,
	the PCE MAY <bcp14>MAY</bcp14> add the NO-PATH-VECTOR TLV (<xref target="RFC5440"/>) <xref target="RFC5440"
	format="default"/> in the LSP Object.</t> object.</t>

        <t>This document adds new bits in the Flags field of the
        NO-PATH-VECTOR TLV:</t>
      <t>
      <list style="none">
      <t>bit "TBD7": when
        <ul spacing="normal">
          <li>bit 11: When set, the PCE indicates that it could not find a
	  disjoint path for this LSP.</t>
      <t>bit "TBD8": when LSP.</li>
          <li>bit 10: When set, the PCE indicates that it does not support
	  the requested disjointness computation.</t>
      </list>
      </t>
      <t>
      When computation.</li>
        </ul>
        <t>When the T flag is unset, <!--the PCE is allowed to relax disjointness by either applying a requested objective function (<xref target="Disjointness-objective-functions"/>) if specified. Otherwise the PCE is allowed to reduce the required level of disjointness (as it deems fit).-->the PCE is allowed to relax disjointness
        by applying a requested objective function (<xref target="Disjointness-objective-functions"/>)
        target="Disjointness-objective-functions" format="default"/>) if
        specified. Otherwise, if no objective function is specified, the PCE
        is allowed to reduce the required level of disjointness as it deems
        fit. The actual level of disjointness of the paths computed by the PCE
        can be reported through the DISJOINTNESS-STATUS-TLV DISJOINTNESS-STATUS TLV by setting the
        appropriate flags in the TLV. While the DISJOINTNESS-CONFIGURATION-TLV DISJOINTNESS-CONFIGURATION TLV
        defines the desired level of disjointness required by configuration,
        the DISJOINTNESS-STATUS-TLV DISJOINTNESS-STATUS TLV defines the achieved level of disjointness computed.
      </t>
      <t>
      There
        computed.</t>
        <t>There are some cases where the PCE may need to completely relax the
	disjointness constraint in order to provide a path to all the LSPs
	that are part of the association. A mechanism that allows the PCE to
	fully relax a constraint is considered by the authors as more global
	to PCEP rather than linked to the disjointness use case. As a
	consequence, it is considered as out of scope of the document. See
	<xref target="I-D.dhody-pce-stateful-pce-optional"/> target="I-D.dhody-pce-stateful-pce-optional" format="default"/>
	for a proposed mechanism.
      </t> mechanism.</t>
      </section>
    </section>
    <section title="Security Considerations" toc="default"> toc="default" numbered="true">
      <name>Security Considerations</name>

      <t>This document defines one new PCEP association Association type, which on by itself
      does not add any new security concerns beyond those discussed in <xref target="RFC5440"/>,
      target="RFC5440" format="default"/>,
      <xref target="RFC8231"/>, target="RFC8231" format="default"/>, <xref target="RFC7470"/> target="RFC7470"
      format="default"/>, and <xref target="I-D.ietf-pce-association-group"/>. But, target="RFC8697" format="default"/>. But
      adding of a spurious LSP into the disjointness association group Disjoint Association Group could
      lead to re-computation recomputation and set-up setup of all LSPs in the group, that which could
      be used to overwhelm the PCE and the network.
      </t> network.</t>
      <t> A spurious LSP can have flags that are inconsistent with those of
      the legitimate LSPs of the group and thus cause LSP allocation for the
      legitimate LSPs to fail with an error. Also, certain combinations of
      flags (notably, the 'T' bit) can result in conflicts that cannot be resolved.
      </t>
      resolved.</t>

      <t>Also, as stated in <xref target="I-D.ietf-pce-association-group"/>, target="RFC8697" format="default"/>, much of
      the information carried in the Disjointness Association ASSOCIATION object reflects information
      that can also be derived from the LSP Database, database, but association provides
      a much easier grouping of related LSPs and messages. The disjointness association This holds true for
      the DAT as well; thus, this could provide an adversary with the
      opportunity to eavesdrop on the relationship between the LSPs and
      understand the network topology.</t>
    <t>Thus
      <t>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.</t> <bcp14>RECOMMENDED</bcp14>.</t>
    </section>
    <section title="IANA Considerations" toc="default"> toc="default" numbered="true">
      <name>IANA Considerations</name>

      <section title="Association Type" toc="default"> toc="default" numbered="true">
        <name>Association Type</name>
        <t>This document defines a new Association type, originally described
        in <xref target="I-D.ietf-pce-association-group"/>. target="RFC8697" format="default"/>. IANA is requested to make has assigned the assignment of a
        following new value for in the
      sub-registry "ASSOCIATION Type Field" (request to be created in subregistry <xref target="I-D.ietf-pce-association-group"/>), as follows:
        target="RFC8697" format="default"/> within the "Path Computation
        Element Protocol (PCEP) Numbers" registry: </t>
            <texttable>
            <ttcol>Association type</ttcol><ttcol>Association Name</ttcol><ttcol>Reference</ttcol>
            <c> TBD1 </c><c> Disjointness Association
        <table align="center">
        <name>ASSOCIATION Type </c> <c> [This.I-D] </c>
            </texttable> 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">2</td>
              <td align="left">Disjoint Association</td>
              <td align="left">RFC 8800</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="PCEP TLVs" toc="default"> toc="default" numbered="true">
        <name>PCEP TLVs</name>
        <t> This document defines the following two new PCEP TLVs and the TLVs. IANA is requested to make has assigned the assignment of new
        following values for in the existing "PCEP TLV Type Indicators" registry as follows:</t>

        <texttable>
          <ttcol>TLV Type</ttcol><ttcol>TLV Name</ttcol><ttcol>Reference</ttcol>
          <c> TBD2 </c><c> Disjointness Configuration TLV </c> <c> [This.I-D] </c>
          <c> TBD3 </c><c> Disjointness Status subregistry within
	the "Path Computation Element Protocol (PCEP)
        Numbers" registry:</t>
        <table align="center">
        <name>PCEP TLV </c> <c> [This.I-D] </c>
        </texttable>

          <t> This document requests that Type Indicators</name>
          <thead>
            <tr>
              <th align="left">TLV Type</th>
              <th align="left">TLV Name</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">46</td>
              <td align="left">DISJOINTNESS-CONFIGURATION</td>
              <td align="left">RFC 8800</td>
            </tr>
            <tr>
              <td align="left">47</td>
              <td align="left">DISJOINTNESS-STATUS</td>
              <td align="left">RFC 8800</td>
            </tr>
          </tbody>
        </table>

        <t>IANA has created a new sub-registry, subregistry, named "Disjointness Configuration
	"DISJOINTNESS-CONFIGURATION TLV Flag Field",
          is created within the
	"Path Computation Element Protocol (PCEP) Numbers" registry to manage
	the Flag Flags field in the Disjointness Configuration DISJOINTNESS-CONFIGURATION 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:</t>
          <t>
          <list style="symbols">
          <t>Bit
        <ul spacing="normal">
          <li>Bit number (count from 0 as the most significant bit)</t>
          <t>Flag Name</t>
          <t>Reference</t>
          </list>
          </t>
        <texttable bit)</li>
          <li>Flag Name</li>
          <li>Reference</li>
        </ul>

<t>The initial contents of this subregistry are shown below:</t>

        <table anchor="Disjointness-Configuration-TLV-IANA" title="Disjointness Configuration TLV">
          <ttcol>Bit Number</ttcol>
          <ttcol>Name</ttcol>
          <ttcol>Reference</ttcol>
          <c>31</c>
          <c>L align="center">
          <name>DISJOINTNESS-CONFIGURATION TLV Flag Field</name>
          <thead>
            <tr>
              <th align="left">Bit</th>
              <th align="left">Name</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">31</td>
              <td align="left">L - Link Diverse</c>
          <c> [This.I-D] </c>
          <c>30</c>
          <c>N Diverse</td>
              <td align="left">RFC 8800</td>
            </tr>
            <tr>
              <td align="left">30</td>
              <td align="left">N - Node Diverse</c>
          <c> [This.I-D] </c>
          <c>29</c>
          <c>S Diverse</td>
              <td align="left">RFC 8800</td>
            </tr>
            <tr>
              <td align="left">29</td>
              <td align="left">S - SRLG Diverse</c>
          <c> [This.I-D] </c>
          <c>28</c>
          <c>P Diverse</td>
              <td align="left">RFC 8800</td>
            </tr>
            <tr>
              <td align="left">28</td>
              <td align="left">P - Shortest Path</c>
          <c> [This.I-D] </c>
          <c>27</c>
          <c>T Path</td>
              <td align="left">RFC 8800</td>
            </tr>
            <tr>
              <td align="left">27</td>
              <td align="left">T - Strict Disjointness</c>
          <c> [This.I-D] </c>
        </texttable> Disjointness</td>
              <td align="left">RFC 8800</td>
            </tr>
            <tr>
              <td align="left">0-26</td>
              <td align="left">Unassigned</td>
              <td align="left"></td>
            </tr>
          </tbody>
        </table>
      </section>

      <section title="Objective Functions" toc="default">
        <t>Three toc="default" numbered="true">
        <name>Objective Functions</name>
        <t>This document defines three new Objective Functions have been defined in this document. objective functions.  IANA is requested to make has made
        the following allocations from in the PCEP "Objective Function" sub-registry:</t>

        <texttable>
          <ttcol>Code Point</ttcol><ttcol>Name</ttcol><ttcol> Reference</ttcol>
          <c> TBD4 </c><c>Minimize
        subregistry within the "Path Computation Element Protocol (PCEP)
        Numbers" registry:</t>
        <table align="center">
        <name>Objective Function</name>
          <thead>
            <tr>
              <th align="left">Code Point</th>
              <th align="left">Name</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">15</td>
              <td align="left">Minimize the number of shared Shared Links (MSL)</c> <c> [This.I-D] </c>
          <c> TBD5 </c><c>Minimize (MSL)</td>
              <td align="left">RFC 8800</td>
            </tr>
            <tr>
              <td align="left">16</td>
              <td align="left">Minimize the number of shared Shared SRLGs (MSS)</c> <c> [This.I-D] </c>
          <c> TBD6 </c><c>Minimize (MSS)</td>
              <td align="left">RFC 8800</td>
            </tr>
            <tr>
              <td align="left">17</td>
              <td align="left">Minimize the number of shared Shared Nodes (MSN)</c> <c> [This.I-D] </c>
        </texttable> (MSN)</td>
              <td align="left">RFC 8800</td>
            </tr>
          </tbody>
        </table>
      </section>

      <section title="NO-PATH-VECTOR toc="default" numbered="true">
        <name>NO-PATH-VECTOR Bit Flags" toc="default"> Flags</name>
        <t>This documents document defines new bits for the NO-PATH-VECTOR TLV in the
	"NO-PATH-VECTOR TLV Flag Field" sub-registry subregistry of the "Path Computation
	Element Protocol (PCEP) Numbers" registry. IANA is requested to make has made
	the following allocation: allocations:
        </t>
        <texttable
        <table anchor="NO-PATH-VECTOR-TLV-IANA" title="NO-PATH-VECTOR TLV">
          <ttcol>Bit Number</ttcol>
          <ttcol>Name</ttcol>
          <ttcol>Reference</ttcol>
          <c>TBD7</c>
          <c>Disjoint align="center">
          <name>NO-PATH-VECTOR TLV Flag Field</name>
          <thead>
            <tr>
              <th align="left">Bit Number</th>
              <th align="left">Name</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">11</td>
              <td align="left">Disjoint path not found</c>
          <c> [This.I-D] </c>
          <c>TBD8</c>
          <c>Requested found</td>
              <td align="left">RFC 8800</td>
            </tr>
            <tr>
              <td align="left">10</td>
              <td align="left">Requested disjoint computation not supported</c>
          <c> [This.I-D] </c>
        </texttable> supported</td>
              <td align="left">RFC 8800</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="PCEP-ERROR Codes" toc="default">

        <t>This toc="default" numbered="true">
        <name>PCEP-ERROR Codes</name>
        <t>
   This document defines two new Error-Value Error-values within existing Error-Type Error-Types
   related to  path protection disjoint association.  IANA is requested to allocate has allocated the following new error values within
   Error-values in the "PCEP-ERROR Object Error Types and Values" sub-registry of subregistry
   within the PCEP Numbers
          registry, as follows:</t>
          <texttable>
           <ttcol> Error-Type </ttcol><ttcol> Meaning </ttcol><ttcol> Reference </ttcol>
           <c> 6 </c> <c> Mandatory "Path Computation Element Protocol (PCEP) Numbers" registry:</t>
        <table align="center">
        <name>PCEP-ERROR Object missing</c> <c><xref target="I-D.ietf-pce-association-group"/></c>
           <c> </c><c> Error-value=TBD10: Error Types and Values</name>
          <thead>
            <tr>
              <th align="left">Error-Type</th>
              <th align="left">Meaning</th>
              <th align="left">Error-value</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">6</td>
              <td align="left">Mandatory Object missing</td>
              <td></td>
              <td align="left"><xref target="RFC5440" format="default"/></td>
            </tr>
            <tr>
              <td align="left"></td>
              <td align="left"></td>
              <td align="left">15: DISJOINTNESS-CONFIGURATION
	      TLV missing</c> <c> [This.I-D] </c>
           <c> 10 </c> <c> Reception missing</td>
              <td align="left">RFC 8800</td>
            </tr>
            <tr>
              <td align="left">10</td>
              <td align="left">Reception of an invalid object</c> <c><xref target="RFC5440"/></c>
           <c> </c> <c> Error-value=TBD9: object</td>
              <td></td>
              <td align="left"><xref target="RFC5440" format="default"/></td>
            </tr>
            <tr>
              <td align="left"></td>
              <td align="left"></td>
              <td align="left">32: Incompatible OF code</c> <c> [This.I-D] </c>
          </texttable> code</td>
              <td align="left">RFC 8800</td>
            </tr>
          </tbody>
        </table>

      </section>
    </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">
        <t>
   An Policy</name>

        <t>An operator SHOULD <bcp14>SHOULD</bcp14> be allowed to configure the disjointness association groups
        Disjoint Association Groups and disjoint parameters at the PCEP peers
        and associate it them with the LSPs.

The Operator-configured Association Range MUST operator <bcp14>MUST</bcp14> be allowed to be set by the operator. Operator-configured
Association Range. The operator SHOULD <bcp14>SHOULD</bcp14> be allowed to set the
local policies to define various disjoint computational behavior at the
PCE.</t>
      </section>
      <section title="Information toc="default" numbered="true">
        <name>Information and Data Models" toc="default"> Models</name>
        <t>An implementation SHOULD <bcp14>SHOULD</bcp14> allow the operator to view the disjoint
	associations configured or created dynamically. Furthermore,
	implementations SHOULD <bcp14>SHOULD</bcp14> allow to view disjoint associations reported by
	each peer, peer and the current set of LSPs in this association. The PCEP
	YANG module <xref target="I-D.ietf-pce-pcep-yang"/> target="I-D.ietf-pce-pcep-yang" format="default"/>
	includes association groups group information.</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"/>.</t> target="RFC5440" format="default"/>.</t>
      </section>
      <section title="Verification toc="default" numbered="true">
        <name>Verification of Correct Operations" toc="default"> Operations</name>
        <t>Apart from the operation
        verification requirements already listed in
        <xref target="RFC5440"/>, target="RFC5440" format="default"/>, a PCEP implementation
   SHOULD
   <bcp14>SHOULD</bcp14> provide parameters related to disjoint path computation, such as
	number of DAG, number of disjoint path computation failures failures, etc. A
	PCEP implementation SHOULD <bcp14>SHOULD</bcp14> log failure events (e.g., incompatible
	Flags).</t>
      </section>
      <section title="Requirements 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 toc="default" numbered="true">
        <name>Impact on Network Operations" toc="default"> Operations</name>
        <t>Mechanisms defined in <xref target="RFC5440"/>, Section 8.6 target="RFC5440" sectionFormat="of"
	section="8.6"/> also apply to PCEP extensions defined in this
	document. Additionally, a PCEP implementation SHOULD <bcp14>SHOULD</bcp14> allow a limit to
	be placed on the number of LSPs that can belong to a DAG.</t>
      </section>
    </section>
  </middle>
  <back>

<displayreference target="I-D.ietf-pce-pcep-yang" to="PCEP-YANG"/>
<displayreference target="I-D.dhody-pce-stateful-pce-optional" to="PCE-OPTIONAL"/>

  <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5541.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7470.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8685.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8697.xml"/>

      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6007.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pce-pcep-yang.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.dhody-pce-stateful-pce-optional.xml"/>
      </references>
    </references>
    <section title="Acknowledgments" toc="default"> toc="default" numbered="false">
      <name>Acknowledgments</name>
      <t>A special thanks to the authors of
      <xref target="I-D.ietf-pce-association-group"/>, target="RFC8697" format="default"/>; this document borrow borrows
      some of the text from it. Authors The authors would also like to thank Adrian Farrel and Julien Meuric <contact
      fullname="Adrian Farrel"/>
      and <contact fullname="Julien Meuric"/> for the valuable comments.</t>
      <t>Thanks to Emmanuel Baccelli <contact fullname="Emmanuel Baccelli"/> for the RTGDIR review.</t>
      <t>Thanks to Dale Worley <contact fullname="Dale Worley"/> for a detailed GENART review.</t>
      <t>Thanks to Alvaro Retana, Benjamin Kaduk, Suresh Krishnan, Roman Danyliw, Alissa Cooper and Eric Vyncke <contact fullname="Alvaro Retana"/>, <contact
      fullname="Benjamin Kaduk"/>, <contact fullname="Suresh Krishnan"/>,
      <contact fullname="Roman Danyliw"/>, <contact fullname="Alissa
      Cooper"/>, and <contact fullname="Eric Vyncke"/> for the IESG review. </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
    <?rfc include="reference.RFC.2119.xml" ?>
    <?rfc include="reference.RFC.8126.xml"?>
    <?rfc include="reference.RFC.5440.xml" ?>
    <?rfc include="reference.RFC.5541.xml" ?>
    <?rfc include="reference.RFC.7470.xml" ?>
    <?rfc include="reference.RFC.8174.xml"?>
    <?rfc include="reference.RFC.8231.xml"?>
    <?rfc include="reference.RFC.8253.xml"?>
    <?rfc include="reference.I-D.ietf-pce-association-group"?>
    </references>
    <references title="Informative References">
        <?rfc include="reference.RFC.4655.xml" ?>
     <?rfc include="reference.RFC.6007.xml" ?>

     <!--<?rfc include="reference.RFC.7420.xml" ?>-->
     <?rfc include="reference.RFC.7525.xml" ?>
     <?rfc include="reference.RFC.8281.xml"?>
     <?rfc include="reference.I-D.ietf-pce-pcep-yang"?>
     <?rfc include="reference.I-D.dhody-pce-stateful-pce-optional"?>
    </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">
  <organization>Huawei Technologies</organization>
  <address>
    <postal>
      <street>Divyashree Techno Park, Whitefield
Bangalore, Karnataka  560066
India

EMail: dhruv.ietf@gmail.com
        ]]></artwork>
        </figure>
      </t> Whitefiled</street>
      <city>Bangalore</city>
      <region>Karnataka</region>
      <code>560066</code>
      <country>India</country>
    </postal>
    <email>dhruv.ietf@gmail.com</email>
  </address>
</contact>

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