draft-dhody-pce-recv-srlg-07.xml

<?xml version="1.0" encoding="us-ascii"?>
<!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" ?>
<rfc ipr="trust200902" category="std" docName="draft-dhody-pce-recv-srlg-07" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
  <front>
    <title abbrev="PCE-SRLG">PCEP Extensions for Receiving SRLG Information</title>
    <author initials="D" surname="Dhody" fullname="Dhruv Dhody">
      <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>dhruv.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="F" surname="Zhang" fullname="Fatai Zhang">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Bantian, Longgang District</street>
          <city>Shenzhen</city>
          <region>Guangdong</region>
          <code>518129</code>
          <country>P.R.China</country>
        </postal>
        <email>zhangfatai@huawei.com</email>
      </address>
    </author>
    <author fullname="Xian Zhang" initials="X." surname="Zhang">
      <organization>Huawei Technologies</organization>
      <address>
    <postal>
      <street>Bantian, Longgang District
      </street>
      <city>Shenzhen</city>
      <region>Guangdong</region>
      <code>518129</code>
      <country>P.R.China</country>
    </postal>
    <email>zhang.xian@huawei.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>
        <author fullname="Victor Lopez" initials="V." surname="Lopez">
            <organization>Telefonica I+D</organization>
      <address>
    <postal>
      <street>Distrito Telefonica</street>
      <street>Edificio Sur 3, 3rd floor</street>
      <city>Madrid</city>
      <region></region>
      <code>28050</code>
      <country>Spain</country>
    </postal>
    <email>victor.lopezalvarez@telefonica.com</email>
      </address>
    </author>
        <author fullname="Oscar Gonzalez de Dios" initials="O." surname="Gonzalez de Dios">
      <organization>Telefonica I+D</organization>
      <address>
    <postal>
      <street>Distrito Telefonica</street>
      <street>Edificio Sur 3, 3rd floor</street>
      <city>Madrid  </city>
      <region></region>
      <code>28050</code>
      <country>Spain</country>
    </postal>
    <email>oscar.gonzalezdedios@telefonica.com</email>
      </address>
    </author>
    <date month="October" year="2018" />
    <area>Routing</area>
    <workgroup>PCE Working Group</workgroup>
    <abstract>
      <t>The Path Computation Element (PCE) provides functions of path
   computation in support of traffic engineering (TE) in networks controlled
   by Multi-Protocol Label Switching (MPLS) and Generalized MPLS
   (GMPLS).</t>
   <t>This document provides extensions for the Path Computation Element
   Protocol (PCEP) to receive Shared Risk Link Group (SRLG)
   information during path computation via encoding this information
   in the path computation reply message.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" toc="default">
    <t>As per <xref target="RFC4655"/>, PCE based path computation model is
    deployed in large, multi-domain, multi-region, or multi-layer networks.
    In such case PCEs may cooperate with each other to provide end to end
    optimal path. </t>
    <t>It is important to understand which TE links in the network might be
   at risk from the same failures.  In this sense, a set of links can
   constitute a 'shared risk link group' (SRLG) if they share a resource
   whose failure can affect all links in the set <xref target="RFC4202"/>.
   H-LSP (Hierarchical LSP) or S-LSP (Stitched LSP) can be used for carrying
   one or more other LSPs as described in <xref target="RFC4206"/> and
   <xref target="RFC6107"/>. H-LSP and S-LSP may be computed by PCE(s) and
   further form as a TE link. The SRLG information of such LSPs can be
   obtained during path computation itself and encoded in the PCEP Path Computation
   Reply (PCRep) message.  <xref target='I-D.zhang-ccamp-gmpls-uni-app'/> describes
   the use of a PCE for end to end User-Network Interface (UNI) path computation.</t>

   <t>Note that <xref target='RFC8001'/> specifies
   a extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
   where SRLG information is collected at the time of signaling. But in case a PCE
  or cooperating PCEs are used for path computation it is recommended that SRLG information is
   provided by the PCE(s) during the path computation itself to the ingress (PCC) rather
   than receiving this information during signaling. </t>

   <t>Further, for other path setup types (PST), (such as segment routing (SR), PCE as central controller (PCECC)) using a PCEP based approach for 
    SRLG information is useful.</t>

   <t><xref target='RFC7926'/> describes a
   scaling problem with SRLGs in multi-layer environment and introduce a concept of
   Macro SRLG (MSRLG). Lower layer SRLG are abstracted at the time of path computation and can
   be the basis to generate such a Macro SRLG at the PCE.</t>
      <section title="Requirements Language"
               toc="default">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 <xref target="RFC2119" /> <xref target="RFC8174"/> when, and only when, they
      appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section title="Terminology" toc="default">
      <t>The following terminology is used in this document.</t>
      <t>
        <list style="hanging">
          <t hangText="CPS:">Confidential Path Segment.  A segment of a path that contains
          nodes and links that the policy requires not to be disclosed
          outside the domain.</t>
          <t hangText="PCE:">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="SRLG:">Shared Risk Link Group.</t>
          <t hangText="UNI:">User-Network Interface.</t>
        </list>
      </t>
    </section>
    <section title="Usage of SRLG" toc="default">
    <t><xref target="RFC4202"/> states that a set of links can constitute
    a 'shared risk link group' (SRLG) if they share a resource whose failure
    can affect all links in the set. For example, two fibers in the same
    conduit would be in the same SRLG. If an LSR is required to have
    multiple diversely routed LSPs to another LSR, the path computation
    should attempt to route the paths so that they do not have any links
    in common, and such that the path SRLGs are disjoint.</t>
    <t>In case a PCE or cooperating PCEs are used for path computation,
    the SRLG information is provided by the PCE(s). For example, disjoint paths
    for inter-domain or inter-layer LSPs.  In order to achieve path computation
    for a secondary (backup) path, a PCC may request the PCE for a route that must
    be SRLG disjoint from the primary (working) path. The Exclude Route Object
    (XRO) <xref target="RFC5521"/> is used to specify SRLG information to be
    explicitly excluded.</t>
    </section>

    <section title="PCEP Requirements" toc="default">

    <t>Following key requirements are identified for PCEP to
    receive SRLG information during path computation:</t>
    <t>
        <list style="hanging">
          <t hangText="SRLG Indication:">The PCEP speaker SHOULD be capable
   of indicating whether the SRLG information of the path is to be received during
   the path computation procedure to PCE.</t>
          <t hangText="SRLG:">If requested, the SRLG information SHOULD be
   received during the path computation and encoded in the PCEP message from PCE.</t>
        </list>
      </t>
      <t>Cooperating PCEs <xref target="RFC4655"/> with inter-PCE communication
      work together to provide the end to end optimal path as well as the SRLG
      information of this path. During inter-domain or inter-layer path computation,
      the aggregating PCE (Parent PCE <xref target="RFC6805"/> or Ingress PCE(1)
      <xref target="RFC5441"/> or Higher-Layer PCE <xref target="RFC5623"/>)
      should receive the SRLG information of path segments from other PCEs and
      provide the end to end SRLG information of the optimal path to the Path
      Computation Client (PCC).</t>
    </section>
    <section title="Extension to PCEP" toc="default">
    <t>This document defines a new TLV that can be carried in the LSPA (LSP Attributes) object
   <xref target="RFC5440"/> so that a PCEP speaker can request SRLG information
   along with the path from the PCE. The SRLG subobject maybe carried inside
   the Explicit Route Object (ERO) in the PCEP message from PCE.</t>
    <section title="SRLG Information TLV" toc="default">
    <t>This document specify a new TLV for the LSPA Object to indicate that the PCE SHOULD provide the SRLG information along with the path. Its format is
   shown in the following figure:</t>
    <figure title="SRLG-INFO TLV" suppress-title="false" align="left" alt="" width="" height="">
        <artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height=""><![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                |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Reserved             |            Flags            |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ]]></artwork>
      </figure>
      <t>The Type for the TLV is TBD. The length is fixed value of 4. The value portion consist of - 
        <list>
          <t>Reserved (16-bit): MUST be set to zero while sending and ignored on receipt.</t>
          <t>Flags (16-bit): Currently one flag is defined - 
            <list style="hanging">
              <t hangText="S (SRLG - 1 bit):">when set, in a PCReq message, this
      indicates that the SRLG information of the path
      SHOULD be provided in the PCRep message.  Otherwise, when
      cleared, this indicates that the SRLG information SHOULD NOT be
      included in the PCRep message.  In a PCRep message, when the S bit is
      set this indicates that the returned path in ERO also carry the
      SRLG information;
      otherwise (when the S bit is cleared), the returned path does not
      carry SRLG information. Further incase of PCRpt <xref target="RFC8231"/> message for delegated LSP the flag indicates that when PCE computes the path, it SHOULD provide the SRLG information in PCUpd <xref target="RFC8231"/> message. Incase of PCUpd and PCInitiate <xref target="RFC8281"/> message, the flag indicates that the ERO also carry the SRLG information.</t>
            </list></t>
        </list>
      </t>

    </section>
    <section title="SRLG Subobject in ERO" toc="default">
    <t>As per <xref target="RFC5440"/>, ERO is used to encode the path
    and is carried within a PCRep message to provide the computed path
    when computation was successful. Further as per <xref target="RFC8231"/> and <xref target="RFC8281"/>, the ERO is also encoded in PCUpd and PCInitiate message for stateful operations.</t>
    <t>The SRLG of a path is
    the union of the SRLGs of the links in the path <xref target="RFC4202"/>.
    The SRLG subobject is defined in <xref target='RFC8001'/>
    for  ROUTE_RECORD object (RRO). The same subobject format (reproduced below)
    can be used by the ERO object in the PCEP messages.</t>
    <figure title="" suppress-title="false" align="left" alt="" width="" height="">
        <artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height=""><![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     |     Length    |D|          Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 SRLG ID 1 (4 octets)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                           ......                              ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 SRLG ID n (4 octets)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ]]></artwork>
      </figure>
    <t>The meaning and description of Type, Length, D-Bit and SRLG ID can be found in
    <xref target='RFC8001'/>. Reserved field
    MUST be set to zero on transmission and MUST be ignored on receipt.</t>
    <t>The SRLG subobject should be encoded inside the ERO object in the PCEP messages by the PCE
    when the S-Bit is set in the SRLG-INFO TLV (inside LSPA object). Incase no SRLG information
    is present for the path, an empty SRLG subobject with Length as 4 (and no SRLG-IDs) is included.</t>
    </section>
    </section>
    <section title="Other Considerations" toc="default">
    <section title="Other Path Setup Types" toc="default">
      <t>Initially PCEP was used for LSPs
   that are set up using the RSVP-TE signaling protocol.  However, other
   TE path setup methods are possible within the PCE architecture such as SR <xref target="I-D.ietf-pce-segment-routing"/>.</t>
   <t><xref target='RFC8001'/> describes
      SRLG information collection via RSVP-TE extension, which can
      not be used for Segment Routing (SR), making PCE
      the best source for the SRLG information for SR.</t>
    </section>  
    <section title="Backward Compatibility" toc="default">
    <t>If a PCE receives a PCEP message and the PCE does not understand the
   new TLV in the LSPA object, then as per <xref target="RFC5440"/>,
   it would ignore the TLV. In which case, the PCC will receive ERO with
   no SRLG subobject and can determine that the PCE does not support the
   PCEP extention as defined in this document.</t>
   <t>If PCEP speaker receives a PCEP message with SRLG subobject that it does
   not support or recognize, it would act according to the existing processing
   rules of the ERO as per <xref target="RFC5440"/>.</t>
    </section>
    <section title="Confidentiality via PathKey" toc="default">
    <t><xref target="RFC5520"/> defines a mechanism to hide the contents of a segment
   of a path, called the Confidential Path Segment (CPS). The CPS may
   be replaced by a path-key that can be conveyed in the PCEP
   and signaled within in a RSVP-TE ERO.</t>
   <t>When path-key confidentiality is used, encoding
   SRLG information in PCRep along with the path-key could be useful to compute a SRLG
   disjoint backup path at the later instance.</t>
   <t>The path segment that needs to be hidden (that is, CPS) MAY be
    replaced in the ERO with a PKS. The PCE MAY use the SRLG Sub-objects
    in the ERO along with the PKS sub-object.</t>
    </section>
    <section title="Coherent SRLG IDs" toc="default">
    <t>
   In a multi-layer multi-domain scenario, SRLG ids may be configured by
   different management entities in each layer/domain.  In such
   scenarios, maintaining a coherent set of SRLG IDs is a key
   requirement in order to be able to use the SRLG information properly.
   Thus, SRLG IDs must be unique.  Note that current procedure is
   targeted towards a scenario where the different layers and domains
   belong to the same operator, or to several coordinated administrative
   groups.  Ensuring the aforementioned coherence of SRLG IDs is beyond
   the scope of this document. Further scenarios, where coherence in the SRLG IDs cannot be
   guaranteed are out of the scope of the present document and are left
   for further study.
    </t>
    </section>
    </section>
    <section title="Security Considerations" toc="default">
      <t> The procedures defined in
   this document permit the transfer of SRLG data between layers or
   domains during the path computation of LSPs, subject to policy at
   the PCE.  It is recommended that PCE
   policies take the implications of releasing SRLG information into
   consideration and behave accordingly during path computation. Other
      security concerns are discussed in <xref target="RFC5440"/>.
      An analysis of the
   security issues for routing protocols that use TCP (including PCEP)
   is provided in <xref target='RFC6952'/>, while <xref target='RFC8253'/> discusses a TLS based
   approach to provide secure transport for PCEP.</t>
    </section>
    <section title="Manageability Considerations" toc="default">
      <section title="Control of Function and Policy" toc="default">
        <t>A PCE involved in inter-domain or inter-layer path
        computation should be capable of being configured with a
        SRLG processing policy to specify if the SRLG IDs of the domain
        or specific layer network can be exposed to the PCEP peer outside the domain
        or layer network, or whether they should be summarized, mapped
        to values that are comprehensible to PCC outside the domain or
        layer network, or removed entirely.</t>
      </section>
      <section title="Information and Data Models" toc="default">
        <t><xref target='RFC7420'/> describes the PCEP MIB and <xref target="I-D.ietf-pce-pcep-yang"/> specify PCEP YANG, there are no new MIB Objects
        or YANG changes for this document.</t>
      </section>
      <section title="Liveness Detection and Monitoring" toc="default">
        <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>
      </section>
      <section title="Verify Correct Operations" toc="default">
        <t>Mechanisms defined in this document do not imply any new operation
        verification requirements in addition to those already listed in
        <xref target="RFC5440"/> and <xref target="RFC8231"/>.</t>
      </section>
      <section title="Requirements On Other Protocols" toc="default">
        <t>Mechanisms defined in this document do not imply any new requirements
        on other protocols. Note that, <xref target='RFC8001'/>
        provide similar requirements for signaling protocol.</t>
      </section>
      <section title="Impact On Network Operations" toc="default">
        <t>Mechanisms defined in this document do not have any impact on
        network operations in addition to those already listed in
        <xref target="RFC5440"/> and <xref target="RFC8231"/>.</t>
      </section>
    </section>
    <section title="IANA Considerations" toc="default">
    <t>IANA assigns values to PCEP parameters in registries defined in
   <xref target="RFC5440"/>.  IANA is requested to make the following
   additional assignments.</t>
   <section title="New TLV" toc="default">
   <t>IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
   registry and the "PCEP TLV Type
   Indicators" sub-registry. IANA is requested to allocate a codepoint for -</t>
   <texttable  style="none" suppress-title="true">
          <ttcol align="center" width='40%'>Type</ttcol>
          <ttcol align="left" width='40%'>Meaning </ttcol>
          <ttcol align="left" width='40%'>Reference </ttcol>
          <c>TBD</c><c>SRLG-INFO</c><c>This document</c>
        </texttable>
   <t>This document requests that a new sub-registry, named "SRLG-INFO
   TLV Flag Field", is created within the "Path Computation Element
   Protocol (PCEP) Numbers" registry to manage the Flag field of the
   this TLV.  New values are to be assigned by Standards Action
   <xref target="RFC8126"/>.  Each bit should be tracked with the following qualities:
   <list style="symbols">

   <t>Bit number (counting from bit 0 as the most significant bit)</t>

   <t>Capability description</t>

   <t>Defining RFC</t>
   </list></t>

   <t>The following values are defined in this document:</t>
   <texttable  style="none" suppress-title="true">
          <ttcol align="center" width='40%'>Bit</ttcol>
          <ttcol align="left" width='40%'>Description </ttcol>
          <ttcol align="left" width='40%'>Reference </ttcol>
          <c>31</c><c>SRLG (S-bit)</c><c>This document</c>
        </texttable>
   </section>
   <section title="New Subobjects for the ERO Object" toc="default">
   <t>PCEP uses the ERO registry maintained for RSVP at
   http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml.
   Within this registry IANA maintains sub-registry for ERO subobject at
   http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml#rsvp-parameters-25</t>


 <t>Upon approval of this document, IANA is requested to make identical additions to the registry as
    follows (which is un-assigned right now):</t>
    <t>
        <figure title="" suppress-title="false" align="left" alt="" width="" height="">
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
    Subobject Type                          Reference
    34        SRLG sub-object               [This I.D.]
 ]]></artwork>
        </figure>
      </t>
   <t>Note that, an allocation for SRLG sub-object for RRO in
   RSVP-TE is made for <xref target='RFC8001'/>.</t>
   </section>
    </section>

    <section title="Acknowledgments" toc="default">
      <t>Special thanks to the authors of
      <xref target='RFC8001'/>. This document
      borrows some of text from it.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
    <?rfc include="reference.RFC.2119.xml" ?>
    <?rfc include="reference.RFC.5440.xml" ?>
    <?rfc include="reference.RFC.8001.xml" ?>
    <?rfc include="reference.RFC.8126.xml" ?>
    <?rfc include="reference.RFC.8174.xml" ?>
    <?rfc include="reference.RFC.8231.xml" ?>
    <?rfc include="reference.RFC.8281.xml" ?>
    
    </references>
    <references title="Informative References">
      <?rfc include="reference.RFC.4202.xml" ?>
      <?rfc include="reference.RFC.4206.xml" ?>
      <?rfc include="reference.RFC.4655.xml" ?>
      <?rfc include="reference.RFC.5441.xml" ?>
      <?rfc include="reference.RFC.5520.xml" ?>
      <?rfc include="reference.RFC.5521.xml" ?>
      <?rfc include="reference.RFC.5623.xml" ?>
      <?rfc include="reference.RFC.6107.xml" ?>
      <?rfc include="reference.RFC.6805.xml" ?>
      <?rfc include="reference.RFC.6952.xml" ?>
      <?rfc include="reference.RFC.7420.xml" ?>
      <?rfc include="reference.RFC.7926.xml" ?>
      <?rfc include="reference.RFC.8253.xml" ?>
      <?rfc include="reference.I-D.ietf-pce-segment-routing"?>

      <?rfc include="reference.I-D.ietf-pce-pcep-yang"?>

      <?rfc include="reference.I-D.zhang-ccamp-gmpls-uni-app"?>
    </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[
Udayasree Palle

EMail: udayasreereddy@gmail.com

Avantika
India

EMail: s.avantika.avantika@gmail.com
        ]]></artwork>
        </figure>
      </t>
    </section>
  </back>
</rfc>