Routing area S. Hegde
Internet-Draft C. Bowers
Intended status: Informational Juniper Networks, Inc.
Expires: May 3, 2018 S. Litkowski
Orange
October 30, 2017
Node Protection for SR-TE Paths
draft-hegde-spring-node-protection-for-sr-te-paths-02
Abstract
Segment routing supports the creation of explicit paths using
adjacency-sids, node-sids, and binding-sids. It is important to
provide fast reroute (FRR) mechanisms to respond to failures of links
and nodes in the Segment-Routed Traffic-Engineered(SR-TE) path. A
point of local repair (PLR) can provide FRR protection against the
failure of a link in an SR-TE path by examining only the first (top)
label in the SR label stack. In order to protect against the failure
of a node, a PLR may need to examine the second label in the stack as
well in order to determine SR-TE path beyond the failed node. This
document specifies how a PLR can use the first and second label in
the label stack describing an SR-TE path to provide protection
against node failures.
Requirements Language
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 RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2018.
Hegde, et al. Expires May 3, 2018 [Page 1]
Internet-Draft Node Protection for SR-TE Paths October 2017
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Node Failures Along SR-TE Paths . . . . . . . . . . . . . . . 3
2.1. Node protection for node-sid explicit paths . . . . . . . 3
2.2. Node-Protection for Anycast-SIDs . . . . . . . . . . . . 4
2.3. Node-protection for adj-sid explicit paths . . . . . . . 5
2.4. Node-protection of binding-sid explicit paths . . . . . . 6
3. Detailed Solution using Context Tables . . . . . . . . . . . 6
3.1. Building Context Tables . . . . . . . . . . . . . . . . . 6
3.2. Node protection for node SIDs . . . . . . . . . . . . . . 7
3.3. Node protection for ajacency SIDs . . . . . . . . . . . . 8
3.4. Node protection for binding sids . . . . . . . . . . . . 9
3.5. Node protection for edge nodes . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
It is possible for a routing device to completely go out of service
abruptly due to power failure, hardware failure or software crashes.
Node protection is an important property of the Fast Reroute
mechanism. It provides protection against a node failure by
rerouting traffic around the failed node. For example, the
mechanisms described in Loop Free Alternates [RFC5286] and Remote
loop free alternates [I-D.ietf-rtgwg-rlfa-node-protection] can be
used to provide node protection to ensure minimal traffic loss after
a node failure.
Hegde, et al. Expires May 3, 2018 [Page 2]
Internet-Draft Node Protection for SR-TE Paths October 2017
Section 2 describes problems with SR-TE paths and need for a
specialized mechanism to provide node protection for the SR-TE paths.
Section 3 describes the solution applied to paths built using
adjacency-sids, node-sids and binding-sids. Section 3.5 describes
the solution applied to egress node protection.
2. Node Failures Along SR-TE Paths
The topology shown in Figure 1. illustrates a example network
topology with SPRING enabled on each node.
Node Node Node Node Node
sid:1 sid:2 sid:3 sid:4 sid:5
+----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+
| R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 |
+----+ +----+ +----+ +----+ +----+
\ \ /
\ 10 \ 100 / 60
\ \ /
\ +----+ +----+
+--| R7 |------------------| R8 |
+----+ 30 +----+
/ Node Node Label stack:
/ sid:7 sid:8 +------------+
+----+ SRGB: | 1008 (top)|
| R6 | 3000-4000 +------------+
+----+ | 3005 |
Node +------------+
sid:6
Figure 1: Example topology. The segment index for each node is shown
in the diagram. All nodes have SRGB = [1000-2000], except for R8
which has SRGB = [3000-4000]. A label stack that represents the path
R1->R7->R8->R4->R5 is shown as well.
2.1. Node protection for node-sid explicit paths
Consider an explicit path in the topology in Figure 1 from R1->R5 via
R1->R7->R8->R4->R5. This path can be built using the shortest paths
from R1-to-R8 and R8-to-R5. The label stack to instantiate this path
contains two node-sids 1008 and 3005. The 1008 label will take the
packet from R1 to R8 via R7 and get popped. The next label in the
stack 3005 will take the packet from R8 to the destination R5 via R4.
If the node R8 goes down, it is not possible for R7 to perform FRR
without examining the second label in the incoming label stack
(3005).
Hegde, et al. Expires May 3, 2018 [Page 3]
Internet-Draft Node Protection for SR-TE Paths October 2017
Note that in the absence of a failure, R7 does not need to understand
the meaning of the second label (3005) in order to perform normal
forwarding. However, in order to support node protection, R7 will
need to understand the meaning of label 3005 in order to determine
where the packet is headed after R8.
2.2. Node-Protection for Anycast-SIDs
A prefix segment advertised as a node SID may only be advertised by
one node in the network. Instead, an anycast prefix segment may be
advertised by more than one node. In some situations, one can use
anycast SIDs to construct SR-TE paths that are protected against node
failure, without the need for the mechanism described in this
document.
+----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+
| R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 |
+----+ +----+ +----+ +----+ +----+
\ \ / |
\ 10 \100 60/ |
\ \ / |
\ +----+ 30 +----+ |
+--| R7 |------------------| R8 | |
+----+ +----+ |
/ \ Anycast +
/ \ sid:100 /
+----+ \ /
| R6 | \ 40 +----+ /60
+----+ +---------------| R9 |+ Label stack:
+----+ +------------+
Anycast | 1100 (top)|
sid:100 +------------+
| 1005 |
+------------+
Figure 2: Topology illustrating use of anycast-sids to protect
against node failures. All nodes have SRGB = [1000-2000].
An example of this is shown in Figure 2. In this example, R8 and R9
advertise an anycast SID of 100. The label stack in this example =
[1100, 1005];. The top label (1100) corresponds to the anycast SID
advertised by both R8 and R9. In the absence of a failure, the
packet sent by R1 with this label stack will follow the path from
R1->R5 along R1->R7->R8->R4->R5.
If R7 is performing a per-prefix LFA calculation [RFC5286], then R7
will install a backup next-hop to R9 for this anycast SID, protecting
against the failure of the primary next-hop to R8. This backup path
Hegde, et al. Expires May 3, 2018 [Page 4]
Internet-Draft Node Protection for SR-TE Paths October 2017
does not pass through R8, so it is would not be affected by a
complete failure of node R8. As illustrated by this example, for
some topologies node-protecting SR-TE paths can constructed through
the use of anycast SIDs, as opposed to the mechanism described in
this document.
2.3. Node-protection for adj-sid explicit paths
Adj-sid:
R3-R8:9044
Node Node Node Node Node
sid:1 sid:2 sid:3 sid:4 sid:5
+----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+
| R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 |
+----+ +----+ +----+ +----+ +----+
\ \ / |
\ 10 \ 100 / 60 | 10
\ \ / |
\ +----+ +----+ +----+
+--| R7 |------------------| R8 |---------------| R9 |
+----+ 30 +----+ 10 +----+
/ Node Node Node
/ sid:7 sid:8 sid:9
+----+ SRGB:
| R6 | 3000-4000 Label stack:
+----+ +------------+
Node Adj-sids: | 1003 (top)|
sid:6 R8-R4:9054 +------------+
| 9044 |
+------------+
| 9054 |
+------------+
| 1005 |
+------------+
Figure 3: Explicit path using an adjacency sid. All nodes have SRGB
= [1000-2000], except for R8 which has SRGB = [3000-4000].
Consider an explicit path from R1->R5 via R1->R2->R3->R8->R4->R5.
This path can be built using a combination of node sids and adjacency
sids, as shown in Figure 3. The diagram shows shows the label stack
needed to instantiate this path, as well as several adjacency sids
advertised by nodes involved in this path. When a packet leaving R1
with this label stack reaches R3, the top label is 9044, which will
take the packet to R8. The next-next-hop in the path is R4. To
provide protection for the failure of node R8, R3 would need to send
the the packet to R4 without going through R8. However, the only way
Hegde, et al. Expires May 3, 2018 [Page 5]
Internet-Draft Node Protection for SR-TE Paths October 2017
R3 can learn that the packet needs to go to the R4 is to examine the
next label in the stack, label 9054. Since R3 knows that R8 has
advertised label 9054 as the adjacency segment for the link from R8
to R4, R3 knows that a backup path can merge back into the original
explicit path at R4.
2.4. Node-protection of binding-sid explicit paths
Binding sids (defined in SR architecture
[I-D.ietf-spring-segment-routing]) allow the SR-TE path to be built
using a hierarchy of sub-paths. The binding sid provides a single
label to represent a set of nodes and links. If the node advertising
the binding sid goes down, the traffic needs to be protected. The
label stack involving the binding-sid contains next label in the
stack which corresponds to the end point represented by the binding-
sid. The penultimate node of the binding-sid advertiser cannot know
the meaning of the next label in the stack.
3. Detailed Solution using Context Tables
3.1. Building Context Tables
[RFC5331] introduced the concept of Context Specific Label Spaces and
there are various applications making use of this concept.A context
label table on a router represents the Label Forwarding Information
Base (LFIB) from the point of view of a particular neighbor . Context
tables are built by constructing incoming label mappings advertised
by the neighbor and the actions corresponding to those labels. The
labels advertised by each node are local to the node and may not be
unique across the segment routing domain. The context tables are
separate tables built on a per-neighbor basis on every node to ensure
they represent LFIBs of a particular neighbor.
When a node requires to protect an SRTE path against the failure of a
neighbor N, it MUST create a context table associated to N. This
context table MUST be populated with the following segment routing
forwarding entries:
- All the Prefix-SIDs of the network. The programmed ILM MUST use
the SRGB of N to compute the input label value. The NHLFE SHOULD
be constructed by looking into all the nexthops for the prefix-SID
and choosing a loop-free path as explained in Section 3.2
- All the Adjacency SIDs advertised by N. The NHLFE SHOULD be
constructed as explained in Section 3.3
- All the Binding SIDs advertised by N. The NHLFE SHOULD be
constructed as explained in Section 3.4
Hegde, et al. Expires May 3, 2018 [Page 6]
Internet-Draft Node Protection for SR-TE Paths October 2017
The following section illustrates how the context table is
constructed to allow the PLR to provide node-protecting paths for the
next-next hops in the topology shown in Figure 1 and Figure 3.
3.2. Node protection for node SIDs
Figure 4 shows the routing table entries on R7 corresponding to the
node SIDs to reach R1 and R8 for the topology in Figure 1. In the
absence of a failure, a packet with a label stack whose top label is
1008 will have its top label popped by R7 (assuming PHP behavior),
and R7 will forward the packet to R8. When the interface to R8 is
down, the backup next-hop entry is used. R7 will pop the top label
of 1008, and use the context table that R7 computed for R8 to
evaluate the next label on the stack.
R7's Routing Table (partial)
Transits routes for Node SIDs for R1 and R8
+=============+=============================================+
| In label | Outgoing label action |
+=============+=============================================+
| 1001 | Primary: pop, fwd to R1 |
| | Backup: pop, lookup context.r1 |
+-------------+---------------------------------------------+
| 1008 | Primary: pop, fwd to R8 |
| | Backup: pop, lookup context.r8 |
+-------------+---------------------------------------------+
R7's Context Table for R8 (context.r8, partial)
+=============+=============================================+
| In label | Outgoing label action |
+=============+=============================================+
| 3004 | swap 1004, fwd to R1 |
+-------------+---------------------------------------------+
| 3005 | swap 1005, fwd to R1 |
+-------------+---------------------------------------------+
| 3008 | swap 1008, fwd to R1 |
+-------------+---------------------------------------------+
Figure 4: Building node-protecting backup paths for SR-TE paths
involving node SIDs
R7 builds context table for R8 using the following process. R7
computes the mapping of incoming label to node-sid that R8 expects to
see based on the SRGB advertised by R8. In the example in Figure 1,
R7 can determine that R8 interprets in incoming label of 3005 as
mapping to the the node SID for R5.
Hegde, et al. Expires May 3, 2018 [Page 7]
Internet-Draft Node Protection for SR-TE Paths October 2017
R7 then computes a loop-free backup path to reach R5 which is node-
protecting with respect to the failure of R8. In this example, the
backup path computed by R7 to reach R5 without passing through R8 can
be achieved forwarding the packet to R1 with a top label of 1005,
corresponding to the node SID for R5 in the context of R1's SRGB.
The loop-free path computation may be based on a mechanism such as
LFA, R-LFA, TI-LFA, or constraint based SPF avoiding failure. To
populate the context table for R8, R7 maps the out label actions
corresponding to the backup path to R5 to the incoming label 3005.
This results in the entry for label 3005 showin in context.r8 in
Figure 4.
Therefore, when a packet arrives at R7 with label stack = [1008,
3005], and the link from R7 to R8 has recently failed, R7 will use
backup next-hop entry for label 1008 in its main routing table.
Based on this entry, R7 will pop label 1008, and use context.r8 to
lookup the new top label = 3005. R7 will swap label 3005 for 1005
and forward the packet to R1. This will get the packet to R5 on a
node protecting backup path.
Note that R7 activates the node-protecting backup path when it
detects that the link to R8 has failed. R7 does not know that node
R8 has actually failed. However, the node-protecting backup path is
computed assuming that the failure of the link to R8 implies that R8
has failed.
3.3. Node protection for ajacency SIDs
This section gives an example of how to constuct node-protecting
backup paths when the SR-TE path uses adjacency SIDs. Figure 5 shows
some of the routing table entries for R3 corresponding to the sample
network shown in Figure 3. When the top label of the label stack is
an adjacency SID, the PLR needs to recognize that in order to provide
a node-protecting backup path, it needs to pop the top label and
examine the next label in the context of the next-hop router
identified by the top label adjacency SID. In this example, when R3
is constructing its routing table, it recognizes that label 9044
corresponds to a next-hop of R8, so it installs a backup entry,
corresponding to the failure of the link to R8, when pops label 9044,
and then examines the new top label in the context of R8.
Hegde, et al. Expires May 3, 2018 [Page 8]
Internet-Draft Node Protection for SR-TE Paths October 2017
R3's Routing Table (partial)
Transit route for Adj SID
+=============+=============================================+
| In label | Outgoing label action |
+=============+=============================================+
| 9044 | Primary: pop, fwd to R8 |
| | Backup: pop, lookup context.r8 |
+-------------+---------------------------------------------+
R3's Context Table for R8 (context.r8, partial)
+=============+=============================================+
| In label | Outgoing label action |
+=============+=============================================+
| 3005 | swap 1005, fwd to R4 |
+-------------+---------------------------------------------+
| 9054 | pop, fwd to R4 |
+-------------+---------------------------------------------+
Figure 5: Building node-protecting backup paths for SR-TE paths
involving adjacency SIDs
R3 constructs its context table for R8 by determining which labels R8
expects to receive to accomplish different forwarding actions. The
entry for incoming label 3005 in context.r8 in Figure 5 corresponds
to a node SID. This entry is computed using the methods described in
Section 3.2
The entry for incoming label 9054 in context.r8 corresponds to an
adjacency SID. R3 recognizes that R8 has advertised this adjacency
SID for the link from R8 to R4 in Figure 3. So R3 determines the
outgoing label action needed to reach R4 without passing through R8.
This can be accomplished by popping the label 9054, and forwarding
the packet directly on the link from R3 to R4.
3.4. Node protection for binding sids
Figure 6 shows a sample network where R2 advertises a binding sid
2014 for the path R2->R3->R8->R4. This mechanism is very useful in
compressing the label stack depth as a sub-path can be represented
using a single label. The explicit path R7->R1->R2->R3->R8->R4->R5
can be represented by a 3 label stack as shown in Figure 6. If the
node that advertises the binding-sid goes down, protection mechanisms
are needed for the binding sid that the node advertised.
Hegde, et al. Expires May 3, 2018 [Page 9]
Internet-Draft Node Protection for SR-TE Paths October 2017
Binding sid
to reach R4:
8014
Node Node Node Node Node
sid:1 sid:2 sid:3 sid:4 sid:5
+----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+
| R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 |
+----+ +----+ +----+ +----+ +----+
\ \ /
\ 10 \ 100 / 60
\ \ /
\ +----+ +----+
+--| R7 |------------------| R8 | Label stack
+----+ 30 +----+ for packet fwd
/ Node Node from R7 to R1
/ sid:7 sid:8 +------------+
+----+ SRGB: | 1002 (top)|
| R6 | 3000-4000 +------------+
+----+ | 8014 |
Node +------------+
sid:6 | 1005 |
+------------+
Figure 6: Building node-protecting backup paths for SR-TE paths
involving binding SIDs
In the example topology, R7 forwards a packet to R1 with label stack
= [1002,8014,1005]. In the absence of a failure, R1 pops the label
1002 (assuming PHP behavior) and forwards the packet with label stack
= [8014,1005] to R2. R2 recognizes label 8014 as the binding SID it
advertised for a path to reach R4 so it pops the label 8014 and uses
some forwarding mechanism to have the packet reach R4 with label
stack = [1005].
If node R2 fails, it is up to R1 to figure out where traffic would
have been sent by R2, had it reached R2, by looking deeper into the
label stack. In this example, R1 recognizes that the second label in
the stack corresponds to the binding SID advertised by R2 with R4 as
the tail-end of the advertised path. R1 therefore pops label 1002,
swaps label 8014 with 1004 (the node SID to reach R4), and forwards
the packet to R7.
Note that the PLR (R1 in this example) needs to receive and
understand the binding SID advertisement in order to be able to
determine the tail-end of the path advertised by the binding SID.
This would be the case with binding SIDs advertised using the IGP.
Hegde, et al. Expires May 3, 2018 [Page 10]
Internet-Draft Node Protection for SR-TE Paths October 2017
If other mechanisms are used for advertising binding SIDs, the PLR
may not automatically have access to this information.
3.5. Node protection for edge nodes
The node protection mechanism described in previous sections depends
on the assumption that the label below the top label in the label
stack are understood in the IGP domain. In the example topology in
Figure 7, CE-A and CE-B are customer edge routers receiving services
from provider edge routers. The provider edge routers are exchanging
service labels via BGP or some other non-IGP mechanism. A packet
with label stack = [1005,70099] sent from PE1 to R2 would be
forwarded along the path PE1->R2->R3->R4->PE5. Assuming PHP
behavior, PE5 receives the packet with the label stack = [70099].
PE5 uses the service label 70099 to send the packet to CE-B with the
appropriate service characteristics. If PE5 fails, R4 needs to act
as the PLR. However, R4 does not understand the meaning of the
service label 70099.
Hegde, et al. Expires May 3, 2018 [Page 11]
Internet-Draft Node Protection for SR-TE Paths October 2017
Primary PE:
context 1.1.1.1
prefix sid: 201
Node Node Node Node Node
sid:1 sid:2 sid:3 sid:4 sid:5
+---+ 10 +----+ 10 +----+ 10 +----+ 10 +---+ +----+
|PE1|--------| R2 |--------| R3 |--------| R4 |------|PE5|---|CE-A|
+---+ +----+ +----+ +----+ +---+ +----+
\ \ / \ /
\ 10 \ 100 / 60 \/
\ \ / /\
\ +----+ +----+ +---+/ +----+
+--| R7 |------------------| R8 |-------------|PE9+---|CE-B|
+----+ 30 +----+ 10 +---+ +----+
/ Node Node Node
/ sid:7 sid:8 sid:9
+----+
| R6 | Protector PE:
+----+ context 1.1.1.1
Node prefix sid: 201
sid:6 binding sid:8002
Normal Protection
label stack label stack
+------------+ +------------+
| 1201 (top)| | 1201 (top)|
+------------+ +------------+
| 70099 | | 8002 |
+------------+ +------------+
| 70099 |
+------------+
Figure 7: Node Protection for edge nodes
The service mirroring use case is described in
[I-D.filsfils-spring-segment-routing-use-cases]. The customer edge
(CE) routers are multi-homed to provider edge (PE) routers, and one
of the PE's acts in a primary role and the other in protector role.
The two PEs advertise a context ip address for each customer site and
attaches a prefix-sid to the context. The protector PE advertises a
binding sid with M bit set which implies mirroring capability for the
context. Protector PE builds the context table for the BGP service
labels advertised by the primary PE for the same context. The BGP
service is built using a stack of labels with context-sid at the
bottom of the label stack.
Hegde, et al. Expires May 3, 2018 [Page 12]
Internet-Draft Node Protection for SR-TE Paths October 2017
Each node acting as a PLR with respect to failure of the Primary PE
installs a backup routing entry that accomplishes two things. The
routes gets the packet to the Protector PE. And it positions the
context-label immediately above the service label in the label stack,
so that the Protector PE is able to identify the correct context
table to interpret the service label.
In the example in Figure 7, R4 makes sure that the packet originally
destined for PE5 is forwarded on the interface to R8 with label stack
= [1201,8002,70099]. This gets the packet to PE9 with label stack =
[8002,70099] (assuming PHP behavior). PE9 then uses the context
label of 8002 to identify the context table corresponding to PE5.
4. Security Considerations
TBD
5. IANA Considerations
6. Acknowledgments
7. References
7.1. Normative References
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008,
<https://www.rfc-editor.org/info/rfc5286>.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space",
RFC 5331, DOI 10.17487/RFC5331, August 2008,
<https://www.rfc-editor.org/info/rfc5331>.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015,
<https://www.rfc-editor.org/info/rfc7490>.
7.2. Informative References
Hegde, et al. Expires May 3, 2018 [Page 13]
Internet-Draft Node Protection for SR-TE Paths October 2017
[I-D.filsfils-spring-segment-routing-use-cases]
Filsfils, C., Francois, P., Previdi, S., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.
Crabbe, "Segment Routing Use Cases", draft-filsfils-
spring-segment-routing-use-cases-01 (work in progress),
October 2014.
[I-D.francois-rtgwg-segment-routing-ti-lfa]
Francois, P., Bashandy, A., Filsfils, C., Decraene, B.,
and S. Litkowski, "Abstract", draft-francois-rtgwg-
segment-routing-ti-lfa-04 (work in progress), December
2016.
[I-D.ietf-rtgwg-rlfa-node-protection]
Sarkar, P., Hegde, S., Bowers, C., Gredler, H., and S.
Litkowski, "Remote-LFA Node Protection and Manageability",
draft-ietf-rtgwg-rlfa-node-protection-13 (work in
progress), January 2017.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and R. Shakir, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-12 (work in progress), June 2017.
[I-D.minto-rsvp-lsp-egress-fast-protection]
Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP
egress fast-protection", draft-minto-rsvp-lsp-egress-fast-
protection-03 (work in progress), November 2013.
[ISO10589]
"Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473), ISO/IEC
10589:2002, Second Edition.", Nov 2002.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Hegde, et al. Expires May 3, 2018 [Page 14]
Internet-Draft Node Protection for SR-TE Paths October 2017
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
Authors' Addresses
Shraddha Hegde
Juniper Networks, Inc.
Exora Business Park
Bangalore, KA 560103
India
Email: shraddha@juniper.net
Chris Bowers
Juniper Networks, Inc.
Email: cbowers@juniper.net
Stephane Litkowski
Orange
Email: stephane.litkowski@orange.com
Hegde, et al. Expires May 3, 2018 [Page 15]