<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std"
     docName="draft-chen-pce-bier-te-ingress-protect-04"
     ipr="trust200902">
  <front>
    <title abbrev="BIER-TE Ingress Protection">PCE for BIER-TE Ingress Protection</title>
     <author initials="H" surname="Chen" fullname="Huaimo Chen">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <street></street>
          <city>Boston, MA</city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>hchen.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Mike McBride" initials="M" surname="McBride">
      <organization>Futurewei</organization>
      <address>
        <email>michael.mcbride@futurewei.com</email>
      </address>
    </author>

    <author fullname="Gyan S. Mishra" initials="G" surname="Mishra">
      <organization>Verizon Inc.</organization>
      <address>
        <postal>
          <street>13101 Columbia Pike</street>
          <city>Silver Spring</city>
          <code>MD 20904</code>
          <country>USA</country>
        </postal>
        <phone> 301 502-1347</phone>
        <email>gyan.s.mishra@verizon.com</email>
      </address>
    </author>

     <author initials="Y" fullname="Yisong Liu" 
            surname="Liu">
      <organization>China Mobile</organization>
      <address>
        <email>liuyisong@chinamobile.com</email>
      </address>
    </author>

     <author initials="A" fullname="Aijun Wang" 
            surname="Wang">
      <organization>China Telecom</organization>
      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>
          <city>Beijing</city>
          <region> </region>
          <code>102209</code>
          <country>China</country>
        </postal>
        <email>wangaj3@chinatelecom.cn</email>
      </address>
    </author>

   <author initials="L" fullname="Lei Liu" 
            surname="Liu">
      <organization>Fujitsu</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>liulei.kddi@gmail.com</email>
      </address>
    </author>

   <author initials="X" fullname="Xufeng Liu" 
            surname="Liu">
      <organization>Alef Edge</organization>
      <address>
        <postal>
          <street> </street>
          <city>McLean</city>
          <region>VA</region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>xufeng.liu.ietf@gmail.com</email>
      </address>
    </author>

    <date year="2024"/>

    <abstract>
      <t>This document describes extensions to Path
      Computation Element (PCE) communication Protocol (PCEP)
      for protecting the ingress of a BIER-TE path.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">	
     <t>The fast protection of a transit node of a 
     "Bit Index Explicit Replication" (BIER) Traffic  Engineering 
     (BIER-TE) path or tunnel is described 
     in <xref target="I-D.chen-bier-te-frr"/>.
     <xref target="RFC8424"></xref> presents extensions to RSVP-TE for 
     the fast protection of the ingress node of 
     a traffic engineering (TE) Label Switching Path (LSP).
     However, these documents do not discuss any protocol extensions 
     for the fast protection of 
     the ingress node of a BIER-TE path or tunnel.</t>

     <t>This document fills that gap and specifies protocol extensions to
     Path Computation Element (PCE) communication Protocol (PCEP)
     for the fast protection of the ingress node of a BIER-TE 
     path or tunnel. 
     Ingress node and ingress, fast protection and protection as well as
     BIER-TE path and BIER-TE tunnel 
     will be used exchangeably in the following sections.</t> 
    </section> <!-- Introduction -->


    <section title="Terminologies">
    <t>The following terminologies are used in this document.
     <list style="hanging">
       <t hangText="PCE:">Path Computation Element</t>
       <t hangText="PCEP:">PCE communication Protocol</t>
       <t hangText="PCC:">Path Computation Client</t>
       <t hangText="BIER:">Bit Index Explicit Replication</t>
       <t hangText="CE:">Customer Edge</t>
       <t hangText="PE:">Provider Edge</t>
       <t hangText="TE:">Traffic Engineering</t>
      </list>
     </t>
    </section> <!-- Terminologies -->


    <section title="BIER-TE Path Ingress Protection Example">
    <t><xref target = "BIER-TE-Protect-Ingress-PE1"/> 
    shows an example of protecting
    ingress PE1 of a BIER-TE path, 
    which is from ingress PE1 to egress nodes PE3 and PE4. 
    This primary BIER-TE path is represented by *** in the figure.
    The ingress of the primary BIER-TE path is called primary ingress.

<figure anchor="BIER-TE-Protect-Ingress-PE1" 
 title="Protecting Ingress PE1 of BIER-TE Path">
  <artwork> <![CDATA[
             *******  *******   
         [PE1]-----[P1]-----[PE3]        PE1 Primary Ingress
         / |       #|*\#####  |          PEx Provider Edge
        /  |       #| *\__    |          CEx Customer Edge
   [CE1]   |       #|  ***\   |          Px  Non Provider Edge
        \  |       #|     *\  |          *** Primary BIER-TE Path
         \ |       #|      *\ |          ### Backup BIER-TE Path
         [PE2]-----[P2]-----[PE4]        PE2 Backup Ingress
              #####    #####      ]]></artwork>
</figure>
 
    The backup BIER-TE path is from ingress PE2 to 
    egress nodes PE3 and PE4, 
    which is represented by ### in the figure.
    The ingress of the backup BIER-TE path is called backup ingress.</t>

 <t>In normal operations, CE1 sends the packets with 
    a multicast group and source
    to ingress PE1,
    which imports/encapsulates the packets into the BIER-TE path
    through adding a BIER-TE header. The header contains the 
    BIER-TE path from ingress PE1 to egress nodes PE3 and PE4.</t>

    <t>When CE1 detects the failure of ingress PE1 using
    a failure detection mechanism such as BFD, 
    it switches the traffic to backup ingress PE2, 
    which imports the traffic from CE1 into the backup BIER-TE path. 

    When the traffic is imported into the backup path, 
    it is sent to the egress nodes PE3 and PE4 along the path.</t>

<t>
Given the traffic source (e.g., CE1), ingress (e.g., PE1) and egresses
(e.g., PE3 and PE4) of the primary BIER-TE path, 
the PCE computes a backup ingress (e.g., PE2),
a backup BIER-TE path from the backup ingress to the egresses,
and sends the backup BIER-TE path to the PCC of the backup ingress.
It also sends the backup ingress, primary ingress and the 
traffic description 
to the PCC of the traffic source (e.g., CE1).</t>

<t>When the PCC of the traffic source receives the backup ingress, 
primary ingress and traffic description,
it sets up the fast detection of the primary ingress failure and
the switch over target backup ingress.
This setup lets the traffic source node switch the traffic (to be
sent to the primary ingress)
to the backup ingress when it detects the failure of the
primary ingress.</t>

<t>When the PCC of the backup ingress receives the backup BIER-TE path,
it adds a forwarding entry into its BIFT. 
This entry encapsulates the packets from the traffic source 
in the backup BIER-TE path.
This makes the backup ingress send the traffic received from the 
traffic source to the egress nodes via the backup BIER-TE path.</t>
	  
    </section> <!-- BIER-TE Path Ingress Protection Example --> 


    <section title="Behavior around Ingress Failure">
      <t>This section describes the behavior of some nodes 
         connected to the ingress before and after the ingress 
         fails. These nodes are the traffic source (e.g., CE1) and 
         the backup ingress (e.g., PE2). 
         It presents three ways in which these nodes work together
         to protect the ingress. 
         The first way is called source detect, where
         the traffic source is responsible for fast 
         detecting the failure of the ingress.

         The second way is called backup ingress detect, in which
         the backup ingress is responsible for 
         fast detecting the failure of the ingress.

         The third way is called both detect, where both the 
         traffic source and the backup ingress are responsible for 
         fast detecting the failure of the ingress.</t>

      <section title="Source Detect">
        <t>In normal operations, i.e., before the failure of the ingress,
        the traffic source sends the traffic to the ingress of the 
        primary BIER-TE path.

        The backup ingress (e.g., PE2) is ready to import the traffic 
        from the traffic source into the backup BIER-TE path installed.</t>

        <t>When the traffic source detects the failure of the ingress,
        it switches the traffic to the backup ingress, 
        which delivers the traffic to the egress nodes of the BIER-TE path 
        via the backup BIER-TE path.</t>
      </section> <!-- Source Detect --> 

      <section title="Backup Ingress Detect">
        <t>The traffic source (e.g., CE1) always sends the traffic to 
           both the ingress (e.g., PE1) of the primary BIER-TE path
           and the backup ingress (e.g., PE2).</t>

        <t>The backup ingress does not import any traffic 
           from the traffic source into the backup BIER-TE path 
           in normal operations.

          When it detects the failure of the ingress of the primary BIER-TE path, 
          it imports the traffic from the source into the backup BIER-TE path.</t>

       <t>For the backup ingress to fast detect the failure of
          the primary ingress, it SHOULD directly connect to the 
          primary ingress. When a PCE computes a backup ingress
          and a backup BIER-TE path, it SHOULD consider this.</t>
     </section> <!-- Backup Ingress Detect --> 


      <section title="Both Detect">
        <t>In normal operations, i.e., before the failure of the ingress,
           the traffic source sends the traffic to the ingress of the 
           primary BIER-TE path.

           When it detects the failure of the ingress,
           it switches the traffic to the backup ingress.</t>

        <t>The backup ingress does not import any traffic 
           from the traffic source into the backup BIER-TE path 
           in normal operations.

           When it detects the failure of the ingress of the primary BIER-TE path, 
           it imports the traffic from the source into the backup BIER-TE path.</t>
     </section> <!-- Both Detect --> 

    </section> <!-- Behavior after Ingress Failure -->


    <section title="Extensions to PCEP">
      <t>A PCC runs on each of the edge nodes such as PEs and CEs 
      of a network normally.
      A PCE runs on a server as a controller to communicate with PCCs.
      The PCE and the PCCs running on backup ingress PEs and traffic source CEs
      work together to support protection for the ingress
      of a BIER-TE path.</t>

    <section title="Capability for Ingress Protection">

    <section title="Capability for Ingress Protection with Backup Ingress">
      <t>When a PCE and a PCC running on a backup ingress 
      establish a PCEP session between them, 
      they exchange their capabilities of supporting protection for 
      the ingress node of a BIER-TE path/tunnel.</t>

      <t>A new sub-TLV called BIER-TE_INGRESS_PROTECTION_CAPABILITY is defined.
      It is included in the PATH_SETUP_TYPE_CAPABILITY TLV with PST = TBD1 
      (suggested value 2 for protecting the ingress of a BIER-TE path/tunnel)
      in the OPEN object, which is exchanged in Open messages 
      when a PCC and a PCE establish a PCEP session between them. 
      Its format is illustrated below.</t>
<t>
<figure anchor="bier-te-ingress-protection-cap-sub-tlv" 
        title="BIER-TE_INGRESS_PROTECTION_CAPABILITY sub-TLV">
<artwork> <![CDATA[  
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Type = TBD2          |           Length=4            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Reserved            |        Flags              |D|A|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
</t>
<t>
     <list style="hanging">
       <t hangText="Type:"> TBD2 is to be assigned by IANA.</t>
       <t hangText="Length:"> 4. </t>
       <t hangText="Reserved:"> 2 octets. Must be set to zero in transmission 
          and ignored on reception. </t>
       <t hangText="Flags:"> 2 octets. Two flag bits are defined. 
          <list style="hanging">
            <t hangText="o"> D flag bit: A PCC sets this flag to 1 to indicate 
               that it is able to detect its adjacent node's failure quickly.</t>
            <t hangText="o"> A flag bit: A PCE sets this flag to 1 to request a PCC 
               to let the forwarding entry for the backup BIER-TE
               path/tunnel be Active.</t>
          </list>
       </t>
      </list>
</t>
      <t>A PCC, which supports ingress protection for a BIER-TE tunnel/path, 
      sends a PCE an Open message containing 
      BIER-TE_INGRESS_PROTECTION_CAPABILITY
      sub-TLV. This sub-TLV indicates that the PCC is capable of supporting 
      the ingress protection for a BIER-TE tunnel/path.</t>

      <t>A PCE, which supports ingress protection for a BIER-TE tunnel/path, 
      sends a PCC an Open message containing 
      BIER-TE_INGRESS_PROTECTION_CAPABILITY 
      sub-TLV. This sub-TLV indicates that the PCE is capable of supporting 
      the ingress protection for a BIER-TE tunnel/path.</t>

      <t>If both a PCC and a PCE support 
      BIER-TE_INGRESS_PROTECTION_CAPABILITY, 
      each of the Open messages sent by the PCC and PCE contains 
      PATH-SETUP-TYPE-CAPABILITY TLV with a PST list containing PST=TBD1 and 
      a BIER-TE-INGRESS_PROTECTION_CAPABILITY sub-TLV.</t>

      <t>If a PCE receives an Open message without a 
      BIER-TE_INGRESS_PROTECTION_CAPABILITY sub-TLV from a PCC, 
      then the PCE MUST not send the PCC any request for ingress protection 
      of a BIER-TE path/tunnel.</t>

      <t>If a PCC receives an Open message without a 
      BIER-TE_INGRESS_PROTECTION_CAPABILITY sub-TLV from a PCE, 
      then the PCC MUST ignore any request for ingress protection 
      of a BIER-TE path/tunnel from the PCE.</t>

      <t>If a PCC sets D flag to zero, then the PCE SHOULD send the PCC 
      an Open message with A flag set to one and the fast detection of 
      the failure of the primary ingress MUST be done by the traffic source. 
      When the PCE sends the PCC a message for initiating 
      a backup BIER-TE path, 
      the PCC MUST let the forwarding entry for the backup 
      BIER-TE path be Active.</t>

    </section> <!-- Capability for Ingress Protection with Backup Ingress -->


    <section title="Capability for Ingress Protection with Traffic Source">
      <t>When a PCE and a PCC running on a traffic source node 
      establish a PCEP session between them, 
      they exchange their capabilities of supporting protection for 
      the ingress node of a BIER-TE path/tunnel.</t>

      <t>The PCECC-CAPABILITY sub-TLV defined in 
      <xref target="I-D.ietf-pce-pcep-extension-for-pce-controller"/> 
      is included
      in the OPEN object in the PATH-SETUP-TYPE-CAPABILITY TLV, 
      which is exchanged in Open messages 
      when a PCC and a PCE establish a PCEP session between them. </t>

<!--
       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=TBD12      |          Length=4             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Flags                         |P|L|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Figure 7: PCECC Capability sub-TLV
-->

      <t>A new flag bit P is defined in the Flags field of the 
      PCECC-CAPABILITY sub-TLV:
       <list style="symbols">
         <t>P flag (for Ingress Protection): 
         if set to 1 by a PCEP speaker, the P flag indicates
         that the PCEP speaker supports and is willing to handle the PCECC
         based central controller instructions for ingress protection.  
         The bit
         MUST be set to 1 by both a PCC and a PCE for the PCECC ingress 
         protection instruction
         download/report on a PCEP session.</t>
       </list>
 </t>

    </section> <!-- Capability for Ingress Protection with Traffic Source -->
    </section> <!-- Capability for Ingress Protection -->

    <section title="BIER-TE Path Ingress Protection">
      <t>This section specifies the extensions to PCEP for
         the backup ingress and 
         the traffic source.

         The extensions let the traffic source 
          <list style="hanging">
            <t hangText="  S1:">fast detect the failure of the primary
               ingress and switch the traffic to the backup ingress 
               when the traffic source detects the failure
               of the primary ingress, or </t> 
            <t hangText="  S2:">always send the traffic to both 
               the primary ingress and the backup ingress.</t>
          </list>
      </t>

      <t>The extensions let the backup ingress 
          <list style="hanging">
            <t hangText="  B1:">always import the traffic 
               received from the traffic source with possible
               service ID into the backup BIER-TE path, or </t>
            <t hangText="  B2:">import the traffic with possible 
               service ID into the backup BIER-TE path when the backup
               ingress detects the failure of the primary ingress.</t>
          </list>

        The following lists the combinations of Si and Bi (i = 1,2) for 
        different ways of failure detects.
          <list style="hanging">
            <t hangText="  Source Detect:">S1 and B1.</t>
            <t hangText="  Backup Ingress Detect:">S2 and B2.</t>
            <t hangText="  Both Detect:">S1 and B2.</t>
          </list> 
      </t>

    <section title="Extensions for Backup Ingress">

      <t>For the packets from the traffic source, 
      if the primary ingress (i.e., the ingress of the primary BIER-TE path)
      encapsulates the packets with a service ID or label into
      the BIER-TE path, the backup ingress MUST have this service ID 
      or label and encapsulates the packets with the service ID or label
      into the backup BIER-TE path when the primary ingress fails.</t>

      <t>If the backup ingress is requested to detect the failure of
      the primary ingress, it MUST have the information about the primary
      ingress such as the address of the primary ingress.</t>

      <t>A new TLV called BIER-TE_INGRESS_PROTECTION TLV is defined
      to transfer the information about the primary ingress and/or 
      the service ID or label.

      When a PCE sends the PCC of a backup ingress 
      a PCInitiate message for initiating 
      a backup BIER-TE path/tunnel to protect the primary ingress 
      of a primary BIER-TE path/tunnel, the message contains this TLV 
      in the RP/SRP object. 
      Its format is illustrated below.</t>
<t>
<figure anchor="bier-te-ingress-protection-tlv" 
        title="BIER-TE_INGRESS_PROTECTION TLV">
<artwork> <![CDATA[
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Type = TBD3           |        Length (variable)      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Reserved            |        Flags                |A|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                                                               ~
 ~                        sub-TLVs (optional)                    ~
 ~                                                               ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
</t>
<t>
     <list style="hanging">
       <t hangText="Type:"> TBD3 is to be assigned by IANA.</t>
       <t hangText="Length:"> Variable. </t>
       <t hangText="Reserved:"> 2 octets. Must be set to zero in transmission 
          and ignored on reception. </t>
       <t hangText="Flags:"> 2 octets. One flag bit is defined. 
          <list style="hanging">
            <t hangText=" "> A flag bit: it is set to 1 or 0 by PCE.
               <list style="hanging">

               <t hangText="o"> 1 is to request the backup ingress 
               to let the forwarding entry for the backup BIER-TE
               path/tunnel be Active always. 
               In this case, the traffic source detects the failure 
               of the primary ingress and switches the traffic 
               to the backup ingress when it detects the failure.</t>

               <t hangText="o"> 0 is to request the backup ingress
               to detect the failure of the primary ingress and 
               let the forwarding entry for the backup BIER-TE
               path/tunnel be Active when the primary ingress fails.
               In this case, the TLV includes the primary ingress address 
               in a Primary-Ingress sub-TLV.
               The traffic source can send the traffic
               to both the primary ingress and the backup ingress.
               It may switch the traffic to the backup ingress from
               the primary ingress when it detects the failure of 
               the primary ingress.
               </t>
               </list>
            </t>
          </list>
          </t>
      </list>
</t>

      <t>Two optional sub-TLVs are defined. 
         One is Service sub-TLV. 
         The other is Primary-Ingress sub-TLV.

         The Multicast Flow Specification TLV for IPv4 or IPv6, 
         which is defined in <xref target="I-D.ietf-pce-pcep-flowspec"/>, 
         is used as a sub-TLV to  
         indicate the traffic to be imported into the backup 
         BIER-TE path.
<!--
     <list style="hanging">
       <t hangText="Service sub-TLV:">
          contains a service ID or label to be added into a packet 
          to be carried by the backup BIER-TE path/tunnel.</t>
       <t hangText="Primary-Ingress sub-TLV:">
          indicates the IP address of the primary ingress node.</t>
      </list>
-->
 </t>

    <section anchor="Service-sub-TLV" 
             title="Service sub-TLV">
      <t>A Service sub-TLV contains a service label such as 
      VPN service label or ID to be added 
      into a packet to be carried by a BIER-TE path/tunnel.
      It has two formats: one for the service identified by a label
      and the other for the service identified by a service 
      identifier (ID) of 32 or 128 bits, 
      which are illustrated below.</t>
<t>
<figure anchor="service-label-sub-tlv" 
        title="Service Label sub-TLV">
<artwork> <![CDATA[
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Type = TBD4           |          Length (4)           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        zero           |       Service Label (20 bits)         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
</t>
<t>
     <list style="hanging">
       <t hangText="Type:"> TBD4 is to be assigned by IANA.</t>
       <t hangText="Length:"> 4.</t>
       <t hangText="Service Label:">the least significant 20 bits. 
          It represents a label of 20 bits.</t>
      </list>
</t>

<t>
<figure anchor="service-ID-sub-tlv" 
        title="Service ID sub-TLV">
<artwork> <![CDATA[
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Type = TBD5           |         Length (4/16)         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Service ID (4 or 16 octets)            |
 ~                                                               ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
</t>
<t>
     <list style="hanging">
       <t hangText="Type:"> TBD5 is to be assigned by IANA.</t>
       <t hangText="Length:"> 4 or 16.</t>
       <t hangText="Service ID:"> 4 or 16 octets. 
          It represents Identifier (ID) of a service 
          in 4 or 16 octets.</t>
      </list>
</t>
    </section> <!--  Service sub-TLV -->

    <section anchor="Primary-Ingress-sub-TLV" 
             title="Primary-Ingress sub-TLV">
      <t>A Primary-Ingress sub-TLV indicates the IP address of the 
      primary ingress node of a primary BIER-TE path/tunnel.
      It has two formats: one for primary ingress node IPv4 address
      and the other for primary ingress node IPv6 address, 
      which are illustrated below.</t>
<t>
<figure anchor="primary-ingress-ipv4-sub-tlv" 
        title="Primary Ingress IPv4 Address sub-TLV">
<artwork> <![CDATA[
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Type = TBD6           |          Length (4)           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Primary Ingress IPv4 Address (4 octets)            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
</t>
<t>
     <list style="hanging">
       <t hangText="Type:"> TBD6 is to be assigned by IANA.</t>
       <t hangText="Length:"> 4.</t>
       <t hangText="Primary Ingress IPv4 Address:">4 octets. It represents
          an IPv4 host address of the primary ingress node of a 
          BIER-TE path/tunnel.</t>
      </list>
</t>

<t>
<figure anchor="primary-ingress-ipv6-sub-tlv" 
        title="Primary Ingress IPv6 Address sub-TLV">
<artwork> <![CDATA[
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Type = TBD7           |         Length (16)           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Primary Ingress IPv6 Address (16 octets)           |
 ~                                                               ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
</t>
<t>
     <list style="hanging">
       <t hangText="Type:"> TBD7 is to be assigned by IANA.</t>
       <t hangText="Length:"> 16.</t>
       <t hangText="Primary Ingress IPv6 Address:">16 octets. It represents
          an IPv6 host address of the primary ingress node of a 
          BIER-TE path/tunnel.</t>
      </list>
</t>

    </section> <!--  Primary-Ingress sub-TLV -->
    </section> <!--  Extensions for Backup Ingress -->


    <section title="Extensions for Traffic Source">
      <t>If the traffic source is requested to detect the failure 
      of the primary ingress and switch the traffic (to be sent to
      the primary ingress) to the backup ingress when the primary
      ingress fails, it MUST have the information about the 
      backup ingress, the primary ingress and the traffic.
      This information may be transferred via a 
      CCI object for BIER-TE-INGRESS-PROTECTION 
      to the PCC of the traffic source node from a PCE.</t>

      <t>If the traffic source PCC does not accept the request from 
         the PCE or support the extensions, the PCE SHOULD have 
         the information about the behavior of the traffic source configured
         such as whether it detects the failure of the primary 
         ingress. Based on the information, 
         the PCE instructs the backup ingress accordingly.</t>

      <t>The Central Control Instructions (CCI) Object is defined
      in <xref target="I-D.ietf-pce-pcep-extension-for-pce-controller"/>
      for a PCE as a controller to send instructions for LSPs 
      to a PCC. 
      This document defines a new object-type (TBDt)
      for BIER-TE ingress protection
      based on the CCI object.

      The body of the object with the new object-type is 
      illustrated below. The object may be in PCRpt, PCUpd, 
      or PCInitiate message.

<figure anchor="ingress-protection-object" 
        title="BIER-TE-INGRESS-PROTECTION Object Body">
<artwork> <![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            CC-ID                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Reserved             |             Flags         |B|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                        Optional TLV                         //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

     <list style="hanging">
       <t hangText="CC-ID:"> It is the same as described in
          <xref target="I-D.ietf-pce-pcep-extension-for-pce-controller"/>.</t>

       <t hangText="Flags:"> Two flag bits D and B are defined as follows:
               <list style="hanging">

               <t hangText="D:"> D = 1 instructs the PCC of the traffic source
               to Detect the failure 
               of the primary ingress and switch the traffic 
               to the backup ingress when it detects the failure.</t>

               <t hangText="B:"> B = 1 instructs the PCC of the traffic source
               to send the traffic
               to Both the primary ingress and the backup ingress.</t>
               </list>
         </t>

       <t hangText="Optional TLV:">Primary ingress TLV, 
          backup ingress TLV and/or Multicast Flow Specification TLV.</t>
     </list>
</t>

      <t>The primary ingress sub-TLV defined above is used as a TLV 
      to contain the information
      about the primary ingress in the object.
      The Multicast Flow Specification TLV for IPv4 or IPv6, 
      which is defined in <xref target="I-D.ietf-pce-pcep-flowspec"/>, 
      is used to contain the information about the
      traffic in the object.
      A new TLV, called backup ingress TLV, is defined
      to contain the information about the backup ingress in the object. </t>
<!-- CCI Object
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ObjectClass=TBD|  OT=1 |Res|P|I|      Object Length (bytes)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            CC-ID                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Reserved1            |             Flags         |C|O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Label                 |     Reserved2         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                        Optional TLV                         //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-->
    <section anchor="Backup-Ingress-sub-TLV" 
             title="Backup-Ingress TLV">
      <t>A Backup-Ingress TLV indicates the IP address of the 
      ingress node of a backup BIER-TE path/tunnel.
      It has two formats: one for backup ingress node IPv4 address
      and the other for backup ingress node IPv6 address, 
      which are illustrated below. They have the same format as 
      the Primary-Ingress sub-TLVs.</t>
<t>
<figure anchor="backup-ingress-ipv4-sub-tlv" 
        title="Backup Ingress IPv4 Address TLV">
<artwork> <![CDATA[
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Type = TBD8           |          Length (4)           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             Backup Ingress IPv4 Address (4 octets)            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
</t>
<t>
     <list style="hanging">
       <t hangText="Type:"> TBD8 is to be assigned by IANA.</t>
       <t hangText="Length:"> 4.</t>
       <t hangText="Backup Ingress IPv4 Address:">4 octets. It represents
          an IPv4 host address of the backup ingress.</t>
      </list>
</t>

<t>
<figure anchor="backup-ingress-ipv6-sub-tlv" 
        title="Backup Ingress IPv6 Address TLV">
<artwork> <![CDATA[
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Type = TBD9           |         Length (16)           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             Backup Ingress IPv6 Address (16 octets)           |
 ~                                                               ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
</t>
<t>
     <list style="hanging">
       <t hangText="Type:"> TBD9 is to be assigned by IANA.</t>
       <t hangText="Length:"> 16.</t>
       <t hangText="Backup Ingress IPv6 Address:">16 octets. It represents
          an IPv6 host address of the backup ingress node.</t>
      </list>
</t>

    </section> <!--  Backup-Ingress TLV -->
    </section> <!--  Extensions for Traffic Source -->

    </section> <!-- BIER-TE Path Ingress Protection -->
    </section>  <!-- Extensions to PCE -->


 
    <section anchor="IANA" title="IANA Considerations">
      <t>TBD</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBD</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.5440"?>
      <?rfc include="reference.RFC.8231"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.8402"?>
      <?rfc include="reference.RFC.8424"?>
      <?rfc include="reference.I-D.chen-bier-te-frr"?>
      <?rfc include="reference.I-D.ietf-pce-pcep-flowspec"?>
      <?rfc include="reference.I-D.ietf-pce-pcep-extension-for-pce-controller"?>

    </references>

  </back>

</rfc>
