<?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-hu-spring-segment-routing-proxy-forwarding-18"
     ipr="trust200902">
  <front>
    <title abbrev="SR-TE Midpoint Restoration">SR-TE Path Midpoint Restoration</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>Segment Routing Traffic Engineering (SR-TE) supports explicit
      paths using segment lists containing adjacency-SIDs, 
	  node-SIDs and binding-SIDs. 
	  The current SR FRR such as TI-LFA provides fast re-route protection
          for the failure of a node along a SR-TE path by the direct 
          neighbor or say point of local repair (PLR) to the failure.
 
	  However, once the IGP converges,
	  the SR FRR is no longer sufficient to forward traffic of the path 
          around the failure, since the non-neighbors
	  of the failure will no longer have a route to the failed node.

	  This document describes a mechanism for the restoration of the 
          routes to the failure of a SR-MPLS TE path after the IGP converges.
          It provides the restoration of the routes to an adjacency segment, 
          a node segment and a binding segment of the path.

          With the restoration of the routes to the failure, 
          the traffic is continuously sent to the neighbor of the 
          failure after the IGP converges. 
          The neighbor as a PLR fast re-routes the traffic around the 
          failure.</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"/> <xref target="RFC8174"/>
      when, and only when, they appear in all capitals, as shown here.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Segment Routing Traffic Engineering (SR-TE) is a technology that implements
      traffic engineering using a segment list. SR-TE supports the creation 
	  of explicit paths using adjacency-SIDs, node-SIDs, anycast-SIDs, and binding-SIDs.
	  A node-SID in the segment list defining an SR-TE path indicates a loose 
	  hop that the SR-TE path should pass through. 

          When the node fails, the network
          may no longer be able to properly forward traffic on that SR-TE path.</t>

      <t><xref target="I-D.ietf-rtgwg-segment-routing-ti-lfa"/> describes 
	  an SR FRR mechanism that provides fast re-route protection for
 	  the failure of a node on a SR-TE path by the direct
 	  neighbor or say point of local repair (PLR) to the failure.
  
	  However, once the IGP converges,
          the SR FRR is no longer sufficient
          to forward traffic of the path around the failure, since the 
          non-neighbors of the failure will no longer have a route to the failed
          node and drop the traffic.</t>

       <t>To solve this problem, 
          <xref target="I-D.ietf-spring-segment-protection-sr-te-paths"/> 
          proposes that a hold timer should be configured on every router in a network.
          After the IGP converges on the event of a node failure, 
          if the node-SID of the failed node becomes unreachable,
          the forwarding changes should not be communicated to the forwarding planes 
          on all configured routers
          (including PLRs for the failed node) until the hold timer expires.

          This solution may not work for some cases such as 
          some of nodes in the network not supporting this solution.</t>
	  
       <t>
	  This document describes a proxy forwarding mechanism
          for the restoration of the 
          routes to the failure of a SR-MPLS TE path after the IGP converges.
          It provides the restoration of the routes to an adjacency segment, 
          a node segment and a binding segment on a failed node along
          the path.

          With the restoration of the routes to the failure, 
          the traffic for the SR-MPLS TE path is continuously sent to 
          the neighbor of the failure after the IGP converges. 
          The neighbor as a PLR fast re-routes the traffic around the 
          failure.</t>

     <section title="Terminology">
     <t>
     <list style="hanging" hangIndent="4">
     <t hangText="SR:">Segment Routing.</t>
     <t hangText="PLR:">Point of Local Repair.</t>
     <t hangText="LSP:">Link State Protocol Data Unit (PDU) in IS-IS.</t>
     <t hangText="LSA:">Link State Advertisement in OSPF.</t>
     <t hangText="LS:">Link State, which is LSP or LSA.</t>
     </list></t>
     </section> <!-- Terminology -->
    </section>

    <section title="Proxy Forwarding">     
       <t>In the proxy forwarding mechanism, each neighbor of a possible 
          failed node advertises its SR proxy forwarding capability in  
          its network domain 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 SR Proxy Forwarding 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 event of 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 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="Protocol Extensions for Proxy Forwarding">
      <t> 
         This section describes the semantic of
         protocol extensions/re-use for advertising 
         the SR proxy forwarding capability of a node in a network 
         domain and the information about each binding segment 
         (including its binding SID and the list of SIDs associated)
         of a node to its direct neighbors.</t>

   <section title="Advertising Proxy Forwarding">
    <t>When a node P is able to do SR proxy forwarding 
    for its neighboring nodes for protecting 
    the failures of these 
    nodes, P advertises its SR proxy forwarding 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>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.
<!--
The mirror SID for N can be used by P as PLR as context to forward 
the traffic with the SID of N to the next hop of 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>Alternatively, P advertises its capability in its LS. 
   For OSPF, P advertises its information opaque LSA
   with one bit (called PF bit) set to one indicating
   that P has the capability for all its neighbors.
   For IS-IS, P advertises its LSP with PF bit. 
    </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 proxy forwarding capability of a node P may be alternatively 
indicated by the mirror SIDs advertised by P.
Mirror SID for a node N (Neighbor of P) can be used as context to forward 
the traffic with the SID of N to the next hop of N when N 
failed. P advertises a mirror SID for each of its neighbors. 
When N failed, its node SID is not reachable.
A remote node X of the failed node N sends the traffic with the SID of 
N to a neighbor such as P of N.
The neighbor (such as P) sends (i.e., re-routes) the traffic to the next hop of 
N when the neighbor advertises the mirror SID for N. 
When the neighbor does not advertise the mirror SID for N,
it pushes the mirror SID advertised by another 
neighbor (say AN) and sends the traffic to AN. AN pops its mirror SID 
as context and uses the SID of N to re-route the 
traffic to the next hop of N. 
    </t>
-->
   </section> <!-- Advertising Proxy Forwarding -->

   <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 LS containing 
    the binding (i.e., the binding SID and the list of the segments)
    in a binding segment TLV.
    The LS is advertised only to each of the node A's neighboring nodes.
    For OSPFv2, the LS is a opaque LSA of LS type 9 
    (i.e., a link local scope LSA). 
    For IS-IS, the TLV is advertised in Circuit Scoped
    Link State PDUs (CS-LSP) <xref target="RFC7356"/>. 
</t>

    <t>Alternatively, when a protocol (such as
       PCE or BGP running on a controller) supports sending a binding 
       on a node A to A, this protocol may be extended to send the binding 
       with node A to A's neighbors if the controller knows the neighbors and
       there are protocol (PCE or BGP) sessions between the controller and
       the neighbors.
    </t>
   </section> <!-- Advertising Binding Segment-->

    </section>  <!-- Protocol Extensions for Proxy Forwarding -->


    <section title="Proxy Forwarding Example">
      <t>This section illustrates the proxy forwarding for 
      a binding SID through an example.
      The proxy forwarding for a node SID and an adjacency SID 
      can refer to <xref target="I-D.ietf-spring-segment-protection-sr-te-paths"/> or 
      Appendix.
      <xref target="top-sr-te-path"/>
      is an example network topology used to illustrate 
      the proxy forwarding mechanism for a binding SID.
     
      Each node N has SRGB = [N000-N999]. RT1 is an ingress node of
      SR domain. 
      RT3 is a failure node.
      RT2 is a Point of Local Repair (PLR) node, i.e., a proxy forwarding node.

      Label Stack 1 uses a node-SID and a binding SID.
      The Binding-SID with label=100 at RT3 represents the ECMP-aware path 
      RT3-&gt;RT4-&gt;RT5. 
      So Label Stack 1, which consists of the node-SID for RT3 following by
      Binding-SID=100, represents the ECMP-aware path
      RT1-&gt;RT3-&gt;RT4-&gt;RT5.
<figure anchor="top-sr-te-path" 
        title="Topology of SR-TE Path">
          <artwork align="center"><![CDATA[
             Node SID:2      Node SID:3
             +-----+          +-----+
             |     |----------+     |
           / |RT2  |          | RT3 |\
          /  +-----+          +-----+ \
         /      | \             /|     \
        /       |  \           / |      \
       /        |   \         /  |       \
      /         |    \       /   |        \
     /          |     \     /    |         \
 Node SID:1     |      \   /     |          \Node SID:4    Node SID:5
+-----+         |       \ /      |           +-----+       +-----+
|     |         |        X       |           |     |-------|     |
| RT1 |         |       / \      |           | RT4 |       | RT5 |
+-----+         |      /   \     |           +-----+       +-----+
   \            |     /     \    |           /
    \           |    /       \   |          /
     \          |   /         \  |         /
      \         |  /           \ |        /
       \        | /             \|       /
        \       |/               |      /
         \   +-----+           +-----+ /
          \  |     |           |     |/
           \ | RT6 |-----------| RT7 |
             +-----+           +-----+
             Node SID:6        Node SID:7
                                                   
+-----------------+  +--------------+               
|    Node SRGB    |  | Adj-SID      |  +-------+  +-------+  +-------+
+-----------------+  +--------------+  |Label  |  |Label  |  |Label  |
| RT1:[1000-1999] |  |RT1->RT2:10012|  |Stack 3|  |Stack 2|  |Stack 1|
+-----------------+  +--------------+  +-------+  +-------+  +-------+
| RT2:[2000-2999] |  |RT2->RT3:20023|  | 10012 |  | 1003  |  | 1003  |
+-----------------+  +--------------+  +-------+  +-------+  +-------+
| RT3:[3000-3999] |  |RT3->RT6:30036|  | 20023 |  | 3004  |  | 100   |
+-----------------+  +--------------+  +-------+  +-------+  +-------+
| RT4:[4000=4999] |  |RT3->RT7:30037|  | 30034 |  | 4005  |   100 is 
+-----------------+  +--------------+  +-------+  +-------+  binding SID
| RT5:[5000-5999] |  |RT3->RT4:30034|  | 40045 |             to 
+-----------------+  +--------------+  +-------+            {30034,40045}
| RT6:[6000-6999] |  |RT7->RT4:70074|
+-----------------+  +--------------+
| RT7:[7000-7999] |  |RT4->RT5:40045|  
+-----------------+  +--------------+]]></artwork>
        </figure>
</t>

      <section title="Advertising Proxy Forwarding">
        <t>If the Point of Local Repair (PLR), for example, RT2, 
        has the capability to do SR proxy 
        forwarding for its neighboring nodes such as RT3,
        it must advertise this capability. 

        When RT3 fails, RT2 needs to maintain
its SR proxy forwarding capability
for a period of time. When the proxy forwarding
        table corresponding to the fault node is deleted,
        the capability is withdrawn. The nodes in the network (for
        example, RT1) learn the prefix/node SID advertised by RT3 and 
the proxy forwarding capability for RT3 
        advertised by RT2. When RT3 is normal, the nodes prefer
        prefix/node SID. When the RT3 fails, the proxy prefix/node SIDs 
        of RT3 for RT2 is preferred.</t>

        <t>For binding-SID 100, 
        which is associated with segment list {30034, 40045},
        RT3 advertises the binding (i.e., 100 bond to {30034, 40045}) 
        to its neighbors RT2, RT4 and RT7.
        RT2 as PLR uses the binding to build an entry 
        for proxy forwarding for binding-SID 100 
        in its Proxy Forwarding Table for RT3. 
        The entry is used when RT3 fails.</t>
      </section>

      <section title="Building Proxy Forwarding Table">
        <t>A SR proxy node P needs to build an independent
        proxy forwarding table for each neighbor N.
        The proxy forwarding table for node N
        contains the following information:</t>

        <t>1: Node N's SRGB range and the difference between the SRGB
        start value of node P and that of node N;</t>

        <t>2: Every adjacency-SID of N and Node-SID of the node pointed to by
        node N's adjacency-SID.</t>

        <t>3: Every binding-SID of N and the label stack associated with
        the binding-SID.</t>

        <t>Node P (PLR) uses a proxy forwarding table based on the next
        segment to find a node N as a backup forwarding entry to the 
        adjacency-SID
        and Node-SID of node N. When node N fails, the proxy forwarding table
        needs to be maintained for a period of time, which is recommended for
        30 minutes.</t>

        <t>Node RT3 in <xref target="top-sr-te-path"/>
        is node N, and node RT2
        is node P (PLR). RT2 builds the proxy forwarding table for
        RT3.  RT2 calculates the proxy forwarding table for RT3,
        as shown in <xref target="proxy-forwarding-table"/>.
		        <figure anchor="proxy-forwarding-table" 
                    title="RT2's Proxy Forwarding Table for RT3">
          <artwork align="center"><![CDATA[
+==========+===============+============+=============+==============+
| In-label | SRGBDiffValue | Next Label |   Action    |   Map Label  |
+==========+===============+============+=============+==============+
| 2003     |    -1000      |    30034   |  Fwd to RT4 |    2004      |
+----------+---------------+------------+-------------+--------------+
                           |    30036   |  Fwd to RT6 |    2006      |
                           +------------+-------------+--------------+
                           |    30037   |  Fwd to RT7 |    2007      |
                           +------------+-------------+--------------+
                           |    100     |  Swap to { 30034, 40045 }  |
                           +------------+-------------+--------------+
 ]]></artwork>
        </figure>
		
		</t>		
      </section>

    <section title="Proxy Forwarding for Binding Segment">
      <t>This Section shows through example 
      how a proxy node uses the SR proxy
      forwarding mechanism to forward traffic to the destination node 
      when a node fails and the
      next segment of label stack is a binding-SID.</t>

        <t>As shown in <xref target="top-sr-te-path"/>, 
        Label Stack 1 {1003, 100} represents
        SR-TE loose path RT1-&gt;RT3-&gt;RT4-&gt;RT5,
        where 100 is a Binding-SID, which represents 
        segment list {30034, 40045}.</t>

        <t>When the node RT3 fails, the proxy forwarding SID implied or advertised by the
        RT2 is preferred to forward the traffic of the RT1 to the PLR node RT2.
        Node RT2 acts as a PLR node and uses Binding-SID to query the proxy
        forwarding table locally built for RT3. The path returned is the
        label forwarding path to RT3's next hop node (RT4), which bypasses
        RT3. The specific steps are as follows:</t>

        <t>a. RT1 swaps label 1003 to out-label 2003 to RT3.</t>

        <t>b. RT2 receives the label forwarding packet whose top label of
        label stack is 2003, and searches for the local Routing Table, the
        behavior found is to lookup Proxy Forwarding table due to RT3
        failure.</t>

        <t>c. RT2 uses Binding-SID:100 (label 2003 has pop) as the in-label to
        lookup the Next Label record of the Proxy Forwarding Table, the
        behavior found is to swap to Segment list {30034, 40045}.</t>

        <t>d. RT2 swaps Binding-SID:100 to Segment list {30034, 40045}, and
        uses the 30034 to lookup the Next Label record of the Proxy
        Forwarding table again. The behavior found is to forward the packet to RT4.</t>

        <t>e. RT2 queries the Routing Table to RT4, using primary or backup path
        to RT4. The next hop is RT7.</t>

        <t>f. RT2 forwards packets
        to RT7. RT7 queries the local routing table to forward the packet to RT4.</t>
      </section>
    </section>

    <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.8402"?>
      <?rfc include="reference.RFC.8667"?>
      <?rfc include="reference.RFC.8174"?>

    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.ietf-rtgwg-segment-routing-ti-lfa"?>
      <?rfc include="reference.I-D.ietf-spring-segment-protection-sr-te-paths"?>
      <?rfc include="reference.I-D.ietf-spring-segment-routing-policy"?>
    </references>

<!-- Appendix -->

   <section title="Proxy Forwarding for Adjacency and Node Segment">
      <t>This Section shows through example 
      how a proxy node forward traffic to the destination node 
      when a node fails and the
      next segment of label stack is an adjacency-SID or node-SID.</t>

     <section title="Next Segment is an Adjacency Segment">
        <t>As shown in <xref target="top-sr-te-path"/>, 
        Label Stack 3 {10012, 20023, 30034, 40045} 
        uses only adjacency-SIDs and represents 
        the SR-TE strict explicit path
        RT1-&gt;RT2-&gt;RT3-&gt;RT4-&gt;RT5.

        When RT3 fails, node RT2 acts as a PLR, and uses next adjacency-SID (30034)
        of the label stack to lookup the proxy forwarding table built by RT2
        locally for RT3. 

        The path returned 
        is the label forwarding path to RT3's next hop node RT4, which 
        bypasses RT3. The specific steps are as follows:</t>

        <t>a. RT1 pops top adjacency-SID 10012, and forwards the packet to RT2;</t>

        <t>b. RT2 uses the label 20023 to identify the next hop node RT3, which
        has failed. RT2 pops label 20023 and 
        queries the Proxy Forwarding Table corresponding to RT3 with 
        label 30034. The query result is 2004. RT2 uses 2004 as the incoming 
		label to query the label forwarding table. The next hop is RT7, 
		and the incoming label is changed to 7004.</t>

        <t>c. So the packet leaves RT2 out the interface to RT7 with label
        stack {7004, 40045}. RT7 forwards it to RT4, where the original path 
        is rejoined.</t>

        <t>d. RT2 forwards packets
        to RT7. RT7 queries the local routing table to forward the packet to RT4.</t>
      </section>

      <section title="Next Segment is a Node Segment">

        <t>As shown in <xref target="top-sr-te-path"/>, 
        Label Stack 2 {1003, 3004, 4005} 
        uses only node-SIDs and represents the ECMP-aware path
        RT1-&gt;RT3-&gt;RT4-&gt;RT5, where
        1003 is the node SID of RT3.</t>

        <t>When the node RT3 fails, the proxy forwarding TLV advertised by the
        RT2 is preferred to direct the traffic of the RT1 to the PLR node RT2.
        Node RT2 acts as a PLR node and queries the proxy forwarding table
        locally built for RT3. The path returned is the label forwarding
        path to RT3's next hop node RT4, which bypasses RT3. The specific
        steps are as follows:</t>

        <t>a. RT1 swaps label 1003 to out-label 2003 to RT3.</t>

        <t>b. RT2 receives the label forwarding packet whose top label of
        label stack is 2003, and searches for the local Routing Table, the
        behavior found is to lookup Proxy Forwarding table due to RT3
        failure, RT2 pops label 2003.</t>

        <t>c. RT2 uses 3004 as the in-label to lookup Proxy Forwarding table,
		The value of Map Label calculated based on SRGBDiffValue is 2004.
        and the query result is forwarding the packet to RT4.</t>

        <t>d. Then RT2 queries the Routing Table to RT4, using the primary or backup 
        path to RT4. The next hop is RT7.</t>

        <t>e. RT2 forwards the packet
        to RT7. RT7 queries the local routing table to forward the packet to RT4.</t>

        <t>f. After RT1 convergences, node SID 1003 is preferred 
        to the proxy SID implied/advertised by RT2. </t>
      </section>
      </section>

  </back>

</rfc>
