<?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-hc-lsr-sr-proxy-fw-01"
     ipr="trust200902">
  <front>
    <title abbrev="SR Proxy">LSR for SR Proxy Forwarding</title>
 
   <author fullname="Zhibo Hu" initials="Z. " surname="Hu">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Huawei Bld., No.156 Beiqing Rd.</street>
          <city>Beijing</city>
          <code>100095</code>
          <country>China</country>
        </postal>
        <email>huzhibo@huawei.com</email>
      </address>
    </author>

     <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>Huaimo.chen@futurewei.com</email>
      </address>
    </author>


    <author fullname="Junda Yao" initials="J. " surname="Yao">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Huawei Bld., No.156 Beiqing Rd.</street>
          <city>Beijing</city>
          <code>100095</code>
          <country>China</country>
        </postal>
        <email>yaojunda@huawei.com</email>
      </address>
    </author>

    <author fullname="Chris Bowers" initials="C. " surname="Bowers">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street>1194 N. Mathilda Ave.</street>
          <city>Sunnyvale, CA</city>
          <code>94089</code>
          <country>USA</country>
        </postal>
        <email>cbowers@juniper.net</email>
      </address>
    </author>

    <author fullname="Yongqing" initials="Y. " surname="Zhu">
      <organization>China Telecom</organization>
      <address>
        <postal>
          <street>109, West Zhongshan Road, Tianhe District</street>
          <city>Guangzhou</city>
          <code>510000</code>
          <country>China</country>
        </postal>
        <email>zhuyq8@chinatelecom.cn</email>
      </address>
    </author>
	
	<author fullname="Yisong" initials="Y. " surname="Liu">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <code>510000</code>
          <country>China</country>
        </postal>
        <email>liuyisong@chinamobile.com</email>
      </address>
    </author>
	
    <date year="2022"/>

    <abstract>
      <t>
	  This document describes extensions to OSPF and IS-IS 
          to support SR proxy forwarding mechanism for
          fast protecting the failure of a node with segments on a SR-TE path.
          The segments of the node include adjacency, node or binding
          segments. 
     </t>

      <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> 
      <xref target="I-D.hu-spring-segment-routing-proxy-forwarding"/>
      describes a SR proxy forwarding for protection.
          Each neighbor of a possible 
          failed node advertises its SR proxy forwarding capability  
          when it has the capability. This capability 
          indicates that the neighbor (the Proxy Forwarder) will forward 
          traffic on behalf of the failed node.  
          A router receiving the capability from the 
	  neighbors of a failed node will send traffic using the node-SID 
          of the failed node to the nearest Proxy Forwarder  
          after the IGP converges on the failure.</t>

       <t>Once the affected traffic reaches a Proxy Forwarder, it 
	  sends the traffic on the post-failure shortest path to the node 
	  immediately following the failed node in the segment list.</t>

       <t>For a binding segment of a possible failed node, the node
          advertises the information about the binding segment, 
          including the binding SID and the list of SIDs associated with 
          the binding SID, to its direct neighbors only. 
          Note that the information is not advertised in the network domain.</t>

       <t>After the node fails and the IGP converges on the failure,
          the traffic with the binding SID of the failed node
          will reach its neighbor having SR Proxy Forwarding capability.
          Once receiving the traffic, the neighbor swaps the binding SID
          with the list of SIDs/segments associated 
          with the binding SID and 
          sends the traffic along the post-failure shortest path to the 
          first node in the segment list.</t>  
    </section>

    <section title="IGP Extensions/Re-uses for Proxy Forwarding">
      <t> 
         This section defines IGP extensions for advertising 
         the information about each binding segment 
         (including its binding SID and the list of SIDs/segments
          associated with the binding SID)
         of a node to its direct neighbors.
         It describes IGP re-uses/extensions for advertising 
         the SR proxy forwarding capability of a node in a network 
         domain.</t>

   <section title="OSPF Extensions/Re-uses">

   <section title="Advertising Binding Segment">
    <t>For a binding segment (or binding for short) on a node A, 
    which consists of a binding SID and a list of segments, 
    node A advertises an LSA containing 
    the binding (i.e., the binding SID and the list of the segments).
    The LSA is advertised only to each of the node A's neighboring nodes.
    For OSPFv2, the LSA is a opaque LSA of LS type 9 
    (i.e., a link local scope LSA). </t>

    <t>A binding segment is represented by binding segment TLV 
    of the format as shown in <xref target="ospf-binding-seg-tlv"/>. 
<figure anchor="ospf-binding-seg-tlv" 
        title="OSPF Binding Segment 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            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Reserved            |BindingSID Type|   SIDs Type   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                   Binding SID Sub-TLV/value                   ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                       SID Sub-TLVs/values                     ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
   It comprises a binding SID and a list of segments (SIDs). 
The fields of this TLV are defined as follows:
</t>

<t>Type: 2 octets, its value (TBD2) is to be assigned by IANA.</t>
<t>Length: 2 octets, its value is (4 + length of Sub-TLVs/values).</t>

        <t>Binding SID Type (BT): 1 octet indicates 
        whether the binding SID is represented by a Sub-TLV or a value
        included in the TLV.
        For the binding SID represented by a value, 
        it indicates the type of binding SID. 

        The following BT values are defined:</t>

        <t>o BT = 0: The binding SID is represented by a Sub-TLV 
        (i.e., Binding SID Sub-TLV) in the TLV. 
        A binding SID Sub-TLV is a SID/Label Sub-TLV defined in
        <xref target="RFC8665"/>.

        BT != 0 indicates that the binding SID is represented by a value.</t>

        <t>o BT = 1: The binding SID value is a label, 
        which is represented by the 20 rightmost bits. 
        The length of the value is 3 octets.</t>

        <t>o BT = 2: The binding SID value is a 32-bit SID.  
        The length of the value is 4 octets.</t>
     
        <t>SIDs Type (ST): 1 octet indicates 
        whether the list of segments (SIDs) are represented by Sub-TLVs or values
        included in the TLV.
        For the SIDs represented by values, 
        it indicates the type of SIDs. 

        The following ST values are defined:</t>

        <t>o ST = 0: The SIDs are represented by Sub-TLVs 
        (i.e., SID Sub-TLVs) in the TLV.
        A SID Sub-TLV is an Adj-SID Sub-TLV, a Prefix-SID Sub-TLV
        or a SID/Label Sub-TLV defined in 
        <xref target="RFC8665"/>.

        ST != 0 indicates that the SIDs are represented by values.</t>

        <t>o ST = 1: Each of the SID values is a label, 
        which is represented by the 20 rightmost bits. 
        The length of the value is 3 octets.</t>

        <t>o ST = 2: Each of the SID values is a 32-bit SID.  
        The length of the value is 4 octets.</t>

    <t>The opaque LSA of LS Type 9 containing the binding segment
    (i.e., the binding SID and the list of the segments) 
    has the format as shown in <xref target="ospfv2-binding-seg-opaque-lsa"/>. 
    It may have Opaque Type of x (the exact type is to be assigned by IANA) 
    for Binding Segment Opaque LSA.
 <figure anchor="ospfv2-binding-seg-opaque-lsa" 
        title="OSPFv2 Binding Segment Opaque LSA">
  <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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            LS age             |     Options   |  LS Type (9)  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Opaque Type(x)|                 Opaque ID                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Advertising Router                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     LS sequence number                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         LS checksum           |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 :                      Binding Segment TLVs                     :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
    For every binding on a node A, 
    the LSA originated by A contains a binding segment TLV for it.</t>

    <t>For node A running OSPFv3, it originates a link-local scoping LSA 
    of a new LSA function code (TBD3) containing binding segment TLVs
    for the bindings on it. 
    The format of the LSA is illustrated in 
    <xref target="ospfv3-binding-seg-opaque-lsa"/>.
<figure anchor="ospfv3-binding-seg-opaque-lsa" 
        title="OSPFv3 Binding Segment Opaque LSA">
  <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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            LS age             |0|0|0|       BS-LSA (TBD3)     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Link State ID                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      Advertising Router                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      LS Sequence Number                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         LS checksum           |           Length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 :                      Binding Segment TLVs                     :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
The U-bit is set to 0, and the scope is set to 00 for link-local scoping.
</t>
   </section> <!-- Advertising Binding Segment-->


   <section title="Advertising Proxy Forwarding">
    <t>When a node P has the capability to do a SR proxy forwarding 
    for its neighboring nodes for protecting 
    the failures of these 
    nodes, P advertises its capability
    for these nodes. 

    The mirror SID <xref target="RFC8402"/><xref target="RFC8667"/> 
    for a node N (Neighbor of P) advertised by P
    indicates the capability of P for N.</t> 

    <t>Alternatively, P advertises its capability
    in its router information opaque LSA with
    Router Functional Capabilities TLV 
    <xref target="RFC7770"/>. 

    One bit (called PF bit) in the Functional Capabilities field 
    of the TLV is used to indicate node P's capability. 
    
    When this bit is set to one by node P, it indicates that node P is 
    capable of doing a SR proxy forwarding for its neighboring nodes.</t>

    <t>For a node X in the network, it learns the prefix/node SID of 
    node N, which is originated and advertised 
    by node N.

    It creates a proxy prefix/node SID of node N for node P if node P is 
    capable of doing SR proxy forwarding for node N. 
    The proxy prefix/node SID of node N for node P is a copy of the prefix/node SID 
    of node N originated by node N, but stored under 
    (or say, associated with) node P.
    The route to the proxy prefix/node SID is through 
    proxy forwarding capable nodes.</t>

    <t>In normal operations, node X prefers to use the prefix/node SID of 
    node N. When node N fails, node X prefers to use the proxy prefix/node SID 
    of node N. Thus node X will forward the traffic targeting to the prefix/node 
    SID of node N 
    to node P when node N fails, and node P will do a SR proxy forwarding 
    for node N and forward the traffic towards its final destination without 
    going through node N. </t>

    <t>Note that the behaviors of normal IP forwarding and routing convergences 
    in a network are not changed at all by the SR proxy forwarding. 
    For example, the next hop used by BGP is an IP address (or prefix). 
    The IGP and BGP converge in normal ways for changes in the network.
    The packet with its IP destination to this next hop is forwarded
    according to the IP forwarding table (FIB) derived from IGP 
    and BGP routes.</t>


<!--
    <t>If node P can not do a SR proxy forwarding for all its neighboring nodes,
    but for some of them, then
    it advertises the node SID of each of the nodes as a proxy node SID,
    indicating that it is able to do proxy forwarding for the node SID.</t>

    <t>A new TLV, called Proxy Node SIDs TLV, is defined for 
    node P to advertise the node SIDs of some of its neighboring nodes. 
      It has the format as shown in <xref target="ospf-proxy-node-sids-tlv"/>. 

<figure anchor="ospf-proxy-node-sids-tlv" 
        title="OSPF Proxy Node SIDs 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 (TBD1)           |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Node SID Sub-TLVs                      |
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
      The Type (TBD1) is to be assigned by IANA. 
      The TLV contains a number of Node SID Sub-TLVs.
      The Length is the total size of the Node SID Sub-TLVs
      included in the TLV.
      A Node SID Sub-TLV is the Prefix SID Sub-TLV defined in
      <xref target="RFC8665"/>.</t>

      <t>A proxy forwarding node P originates an Extended Prefix 
      Opaque LSA containing 
      this new TLV. The TLV includes the Node SID Sub-TLVs for 
      the node SIDs of some of P's neighboring nodes. 
      For each of some of P's neighboring nodes, the Node SID Sub-TLV 
      for its prefix/node SID is included the TLV. 
      This prefix/node SID is called a proxy prefix/node SID.
      </t>
-->
<!--
      <t>A proxy forwarding node will originate an Extended Prefix 
      Opaque LSA, which includes a Proxy Node SIDs TLV.
      The format of the LSA is shown in
      <xref target="ospfv2-ex-prefix-opaque-lsa"/>.</t>

    <t>For a proxy forwarding node P, having a number of neighboring nodes, 
    P originates and maintains an Extended Prefix Opaque LSA, 
    which includes a Proxy Node SIDs TLV. The TLV contains 
    the Prefix/Node SID Sub-TLV for each of some of the neighboring nodes 
    after node P creates the corresponding proxy forwarding entries 
    for protecting the failure of some of the neighboring nodes.

<figure anchor="ospfv2-ex-prefix-opaque-lsa" 
        title="OSPFv2 Extended Prefix Opaque LSA">
  <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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            LS age             |     Options   |   LS Type     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Opaque Type(7)|                 Opaque ID                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Advertising Router                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     LS sequence number                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         LS checksum           |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 :                             TLVs                              :
 :                (including Proxy Node SIDs TLV)                :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
</t>

    <t>When an neighboring node fails, 
    P maintains the LSA with the TLV containing the Prefix/Node SID Sub-TLV 
    for the neighboring node for a given period of time. 
    After the given period of time, the Prefix/Node SID Sub-TLV for the neighboring node 
    is removed from the TLV in the LSA and 
    then after a given time the corresponding proxy forwarding entries 
    for protecting the failure of the neighboring node is removed.</t>


    <t>For a node X in the network, 
    it learns the prefix/node SID of node N and 
    the proxy prefix/node SID of node N.
    The former is originated and advertised by node N, 
    and the latter is originated and advertised by the proxy forwarding 
    node P of node N. 
    Note that the proxy Prefix/Node SID Sub-TLV for node N does not contain 
    a prefix of node N, and the prefix is the prefix associated 
    with the prefix/node SID of node N originated by node N.</t>

    <t>In normal operations, 
    node X prefers to use the prefix/node SID of node N. 
    When node N fails, 
    node X prefers to use the proxy prefix/node SID of node N. 
    Thus node X will forward the traffic targeting to node N to node P 
    when node N fails, 
    and node P will do a proxy forwarding for node N and 
    forward the traffic towards its destination 
    without going through node N.</t>
-->
   </section> <!-- Advertising Proxy Forwarding -->
   </section> <!-- Extensions to OSPF -->


   <section title="IS-IS Extensions/Re-uses">
      <section title="Advertising Binding Segment">
        <t>
        For supporting binding SID proxy forwarding,
        a new IS-IS TLV, called Binding Segment TLV, is defined.
        It contains a binding SID and a list of segments (SIDs).
        This TLV is advertised in Circuit Scoped Link State PDUs (CS-LSP) 
        <xref target="RFC7356"/>.
        Its format is shown in <xref target="isis-binding-seg-tlv"/>. 
        <figure anchor="isis-binding-seg-tlv" 
                    title="IS-IS Binding Segment TLV">
          <artwork align="center"><![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    |BindingSID Type|   SIDs Type   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                   Binding SID value/Sub-TLV                   ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                      SID values/Sub-TLVs                      ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure>
</t>
        <t>The fields of this TLV are defined as follows:</t>

        <t>Type: 1 octet Suggested value 152 (to be assigned by IANA)</t> 

        <t>Length: 1 octet (2 + length of Sub-TLVs/values).</t>

        <t>The other fields are the same as those in
           <xref target="ospf-binding-seg-tlv"/>. </t>
      </section> <!-- Advertising Binding Segment -->

      <section title="Advertising Proxy Forwarding">
        <t>When a node P has the capability to do a SR proxy forwarding 
        for its neighboring nodes, 
        P advertises its capability in its LSP 
        with a Router Capability TLV of Type 242 including 
        a SR capabilities sub-TLV of sub-Type 2. </t>

        <t>One bit (called PF bit) 
        in the Flags field of the SR capabilities 
        sub-TLV is defined to indicate node P's capability.
        When this bit is set to one by node P, it indicates that node P is 
        capable of doing a SR proxy forwarding for its neighboring nodes.</t> 

        <t>If node P can not do a SR proxy forwarding for all its neighboring
        nodes, but for some of them, then it advertises the node SID of each
        of the nodes as a proxy node SID, indicating that it is able to do
        proxy forwarding for the node SID.</t>

        <t>The IS-IS SID/Label Binding TLV (suggested value 149) is defined in
        <xref target="RFC8667"/>. A Proxy
        Forwarder uses the SID/Label Binding TLV to advertise the node SID of its
        neighboring node. The Flags field of the SID/Label
        Binding TLV is extended to include a P flag as shown in 
        <xref target="sid-label-binding-tlv"/>.  
        The prefix/node SID in prefix/node SID Sub-TLV
		included in SID/Label Binding TLV is identified as a proxy 
		forwarding prefix/node SID.</t>

        <t><figure anchor="sid-label-binding-tlv" 
                    title="SID/Label Binding TLV">
          <artwork align="center"><![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    |     Flags     |     RESERVED  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Range              | Prefix Length |     Prefix    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //               Prefix (continued, variable)                  //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    SubTLVs (variable)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                    0 1 2 3 4 5 6 7
                                   +-+-+-+-+-+-+-+-+
                                   |F|M|S|D|A|P|   |
                                   +-+-+-+-+-+-+-+-+
                                         Flags]]></artwork>
        </figure></t>

        <t>Where:</t>

        <t>P-Flag: Proxy forwarding flag. If set, this prefix/node SID is
        advertised by the proxy node.  This TLV is used to announce that the
        node has the ability to proxy forward the prefix/node SID.</t>
		
		<t>When the P-flag is set in the SID/Label Binding TLV, the following 
		usage rules apply. </t> 

		<t>The Range, Prefix Length and Prefix field are not used. 
                They should be set to zero 
		on transmission and ignored on receipt.</t> 
		
		<t>SID/Label Binding TLV contains a number of prefix/node SID Sub-TLVs.
                The TLV advertised by a proxy forwarding node P contains
                prefix/node SID Sub-TLVs for the node SIDs of P's neighbor nodes.
                Each of the Sub-TLVs is a prefix/node SID Sub-TLV defined in 
                <xref target="RFC8667"/>.

		From the SID in a prefix/node SID Sub-TLV advertised by the Proxy 
                Forwarding node, its prefix can be obtained through matching 
                corresponding prefix/node SID advertised by the neighbor/protected node
	        using TLV-135 (or 235, 236, or 237) 
		together with the prefix/node SID Sub-TLV.</t> 
		
      </section> <!-- Advertising Proxy Forwarding -->
      </section> <!-- Extensions to IS-IS -->
    </section>  <!-- Extensions to IGP for Proxy Forwarding -->

    <section anchor="Security" title="Security Considerations">
      <t>The extensions to OSPF and IS-IS described in this 
      document result in two types of behaviors in data plane
      when a node in a network fails.
      One is that for a node, which is a upstream (except for 
      the direct upstream) node of the failed node along a SR-TE
      path, it continues to send the traffic to the failed node
      along the SR-TE path for an extended period of time. 
      The other is that for a node, which is the direct upstream
      node of the failed node, it fast re-routes the traffic
      around the failed node to the direct downstream node
      of the failed node along the SR-TE path. 
      These behaviors are internal to a network and should not
      cause extra security issues.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
    <section anchor="OSPFv2" title="OSPFv2">
      <t>Under Subregistry Name 
      "OSPF Router Functional Capability Bits" within the
      "Open Shortest Path First v2 (OSPFv2) Parameters"
      <xref target="RFC7770"/>, IANA is requested to assign
      one bit for Proxy Forwarding Capability as follows:
<figure>
  <artwork> 
  +============+==================+===================+
  | Bit number | Capability Name  |  Reference        |
  +============+==================+===================+
  |     31     | Proxy Forwarding |  This document    |
  +------------+------------------+-------------------+
  </artwork>
</figure>
      </t>

      <t>Under Registry Name 
      "OSPFv2 Extended Prefix Opaque LSA TLVs" 
      <xref target="RFC7684"/>,
      IANA is requested to assign one new TLV value for 
      OSPF Proxy Node SIDs as follows:
<figure>
  <artwork> 
  +============+=====================+================+
  | TLV Value  |    TLV Name         | Reference      |
  +============+=====================+================+
  |    2       | Proxy Node SIDs TLV | This document  |
  +------------+---------------------+----------------+
  </artwork>
</figure>
</t> 

      <t>Under Registry Name 
      "Opaque Link-State Advertisements (LSA) Option Types"
       <xref target="RFC5250"/>, IANA is requested to assign
       new Opaque Type registry values for Binding Segment LSA
       as follows:
<figure>
  <artwork> 
  +================+==================+================+
  | Registry Value |  Opaque Type     | Reference      |
  +================+==================+================+
  |     10         |  Binding Segment | This document  |
  +----------------+------------------+----------------+
  </artwork>
</figure>
</t>

<t>
IANA is requested to create and maintain new registries: 
<list style="hanging">
  <t hangText=" o"> OSPFv2 Binding Segment Opaque LSA TLVs</t>
</list>

Initial values for the registry are given below. 
The future assignments are to be made through IETF Review 
<xref target="RFC5226"/>.
<figure>
 <artwork> 
    Value          TLV Name                  Definition
    -----         -----------------------    ----------
    0             Reserved
    1             Binding Segment TLV        This Document
    2-32767       Unassigned
    32768-65535   Reserved
 </artwork>
</figure>
</t>
    </section> <!-- OSPFv2 -->

    <section anchor="OSPFv3" title="OSPFv3">
      <t>Under Registry Name "OSPFv3 LSA Function Codes",
      IANA is requested to assign new registry values for 
      Binding Segment LSA as follows:
<figure>
  <artwork>
  +========+========================+================+
  | Value  | LSA Function Code Name | Reference      |
  +========+========================+================+
  |  16    | Binding Segment LSA    | This document  |
  +--------+------------------------+----------------+ 
  </artwork>
</figure>
</t>

<t>
IANA is requested to create and maintain new registries: 
<list style="hanging">
  <t hangText=" o"> OSPFv3 Binding Segment LSA TLVs</t>
</list>

Initial values for the registry are given below. 
The future assignments are to be made through IETF Review 
<xref target="RFC5226"/>.
<figure>
 <artwork> 
    Value          TLV Name                  Definition
    -----         -----------------------    ----------
    0             Reserved
    1             Binding Segment TLV        This Document
    2-32767       Unassigned
    32768-65535   Reserved
 </artwork>
</figure>
</t>
    </section> <!-- OSPFv3 -->

    <section anchor="IS-IS" title="IS-IS">
      <t>Under Registration "Segment Routing Capability" 
      in the "sub-TLVs for TLV 242" registry 
      <xref target="RFC8667"/>, 
      IANA is requested to assign
      one bit flag for Proxy Forwarding Capability as follows:
<figure>
  <artwork> 
  +============+=======================+===============+
  | Bit number | Capability Name       | Reference     |
  +============+=======================+===============+
  |     2      | Proxy Forwarding (PF) | This document |
  +------------+-----------------------+---------------+
  </artwork>
</figure>
      </t>

     <t>Under Registration "Segment Identifier/Label Binding TLV 149"
      <xref target="RFC8667"/>, 
      IANA is requested to assign
      one bit P-Flag as follows:
<figure>
  <artwork> 
  +============+=================+===============+
  | Bit number | Flag Name       | Reference     |
  +============+=================+===============+
  |     5      | P-Flag          | This document |
  +------------+-----------------+---------------+
  </artwork>
</figure>
     </t>

     <t>Under Registry Name: IS-IS TLV Codepoints,
     IANA is requested to assign one new TLV value for 
     IS-IS Binding Segment as follows:
<figure>
 <artwork>
  +========+======================+===============+ 
  | Value  | TLV Name             | Reference     |
  +========+======================+===============+
  |  152   | Binding Segment TLV  | This Document |
  +--------+----------------------+---------------+
  </artwork>
</figure>
</t> 
    </section> <!-- IS-IS -->
    </section>


    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Peter Psenak, 
      Acee Lindem, Les Ginsberg, Bruno Decraene and Jeff Tantsura
      for their comments to this work.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.5250"?>
      <?rfc include="reference.RFC.5226"?>
      <?rfc include="reference.RFC.7356"?>
      <?rfc include="reference.RFC.7684"?>
      <?rfc include="reference.RFC.7770"?>
      <?rfc include="reference.RFC.8665"?>
      <?rfc include="reference.RFC.8667"?>
    </references>

    <references title="Informative References">
 
      <?rfc include="reference.RFC.8402"?>
      <?rfc include="reference.I-D.hu-spring-segment-routing-proxy-forwarding"?>
      <?rfc include="reference.I-D.ietf-spring-segment-routing-policy"?>
    </references>

  </back>

</rfc>
