Internet DRAFT - draft-bowers-spring-adv-per-algorithm-label-blocks
draft-bowers-spring-adv-per-algorithm-label-blocks
SPRING Working Group C. Bowers
Internet-Draft P. Sarkar
Intended status: Standards Track H. Gredler
Expires: April 7, 2016 Juniper Networks
U. Chunduri
Ericsson Inc
October 5, 2015
Advertising Per-Topology and Per-Algorithm Label Blocks
draft-bowers-spring-adv-per-algorithm-label-blocks-02
Abstract
When segment routing is used in a network that is controlled by a
link state IGP (such as ISIS or OSPF), each node in the network can
be assigned one or more index numbers, known as "node-SIDs". The
node-SIDs are unique within the network, and are known to all the
nodes in the network. If an ingress node has a data packet to be
sent to an egress node, the ingress node may select a node-SID
corresponding to the egress node, and "translate" that node-SID to an
MPLS label. The MPLS label represents a particular path to the
egress node; the path is determined by applying a routing algorithm
to a particular view of the network topology and a particular set of
metric assignments to the links of that topology. The packet can
then be forwarded by pushing the label on the packet's label stack
and transmitting the packet to the next hop on the corresponding path
to the egress node. This document compares two different procedures
for translating a node-SID to the MPLS label that represents a path
chosen by a particular algorithm operating on a particular topology.
It also specifies the ISIS extensions needed to support one of the
procedures (known as the "per-topology/per-algorithm label block"
procedure).
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 http://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."
Bowers, et al. Expires April 7, 2016 [Page 1]
Internet-Draft Per-Topology/Per-Algorithm Label Blocks October 2015
This Internet-Draft will expire on April 7, 2016.
Copyright Notice
Copyright (c) 2015 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
(http://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. Destination-based forwarding using other algorithms . . . . . 3
3. Multi-topology routing . . . . . . . . . . . . . . . . . . . 5
4. Example: Adding Nodes when Multiple Algorithms are In Use . . 6
5. Proposed configured offset mapping method for assigning per-
topology/per-algorithm node-SIDs when using Option 1 . . . . 7
6. Flexibility to create easy-to-interpret label values . . . . 9
7. Robustness against misconfiguration . . . . . . . . . . . . . 10
8. ISIS extensions to encode per-topology/per-algorithm label
blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. OSPF extensions to encode per-topology/per-algorithm label
blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. A note on algorithms and topologies . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
12. Management Considerations . . . . . . . . . . . . . . . . . . 12
13. Security Considerations . . . . . . . . . . . . . . . . . . . 13
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
15.1. Normative References . . . . . . . . . . . . . . . . . . 13
15.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
[I-D.ietf-spring-segment-routing] describes the segment routing
architecture. When segment routing is used in a network that is
controlled by a link state IGP (such as ISIS or OSPF), each node in
the network can be assigned one or more index numbers, known as
"node-SIDs". The node-SIDs are unique within the network, and are
Bowers, et al. Expires April 7, 2016 [Page 2]
Internet-Draft Per-Topology/Per-Algorithm Label Blocks October 2015
known to all the nodes in the network. If an ingress node has a data
packet to be sent to an egress node, the ingress node may select a
node-SID corresponding to the egress node, and "translate" that node-
SID to an MPLS label. The MPLS label represents a particular path to
the egress node; the path is determined by applying a routing
algorithm to a particular view of the network topology and a
particular set of metric assignments to the links of that topology.
The packet can then be forwarded by pushing the label on the packet's
label stack and transmitting the packet to the next hop on the
corresponding path to the egress node.
When a particular network is using a single routing algorithm and a
single topology, the procedure for translating a node-SID to an MPLS
label is straightforward. Figure 1 shows the formula used to
translate a node-SID into an MPLS label when the paths are selected
by using the default routing algorithm (Dijkstra's shortest path
first algorithm) and the default topology.
SPF_Label(X,D) = Label_Block(X) + Node_Index(D)
D is the destination node
X is the next-hop along the path to D
Figure 1: Translating Node-SID to Label: The Default Case
As a simple example, when the computing node (Y) needs to forward a
packet ultimately destined for node D, Y first determines the
shortest path next-hop node to reach D, which in this example is X.
Y then adds the Node_Index value advertised by D to the Label_Block
value advertised by X to determine the label value to apply to the
packet before sending it to X.
2. Destination-based forwarding using other algorithms
Figure 2 shows two options for generalizing the above formula, to
determine locally significant labels corresponding to forwarding
next-hops computed using other algorithms.
Bowers, et al. Expires April 7, 2016 [Page 3]
Internet-Draft Per-Topology/Per-Algorithm Label Blocks October 2015
Option 1a: per-algorithm node index
Label(X,D,A) = Label_Block(X) + Node_Index(D,A)
Option 2a: per-algorithm label block
Label(X,D,A) = Label_Block(X,A) + Node_Index(D)
A is the algorithm for computing destination-based
forwarding next-hops
D is the destination node
X is the next hop along the path to D that is
determined by algorithm A
Figure 2: Translating Node-SID to Label: Algorithm-Specific Options
Suppose router Y needs to forward a packet to node D along a path
computed by algorithm A. Using either option, Y determines the next-
hop computed by algorithm A to reach D, which in this example is X.
Y then needs to figure out the correct label to apply to the packet
so that so that X will also understand that the packet is to be sent
to node D along a path computed by algorithm A. The two options
shown in Figure 2 differ in how Y determines that label value.
In Option 1a each node advertises a single label block, but
advertises a different node index for each algorithm. Y determines
the label value of local significance to X to reach D using algorithm
A by adding the Node_Index advertised by node D for algorithm A to
the Label_Block advertised by node X. We refer to this as the per-
algorithm node index option.
In Option 2a each node advertises only a single node index, but
advertises a different label block for each algorithm. Y determines
the label value of local significance to X to reach D using algorithm
A by adding the Node_Index advertised by node D to the Label_Block
for algorithm A advertised by node X. We refer to this as the per-
algorithm label block option.
The extensions currently defined in
[I-D.ietf-isis-segment-routing-extensions] and
[I-D.ietf-ospf-segment-routing-extensions] specify encodings for
Option 1a, the per-algorithm node index option. This draft proposes
extensions that can be used to support option 2a, the per-algorithm
label block option. However, before discussing those extensions, we
generalize the formula in Figure 2 further to take into account
multiple topologies. This will allow us to define extensions that
address the use of both multiple topologies and multiple algorithms.
Bowers, et al. Expires April 7, 2016 [Page 4]
Internet-Draft Per-Topology/Per-Algorithm Label Blocks October 2015
3. Multi-topology routing
The IGP extensions to support multi-topology routing are defined in
[RFC4915] for OSPF and [RFC5120] for IS-IS. Figure 3 further
generalizes the formulas above to take into account multiple
topologies. It shows two options for determining locally significant
labels for different topologies and algorithms.
Option 1: per-topology / per-algorithm node index
Label(X,D,T,A) = Label_Block(X) + Node_Index(D,T,A)
Option 2: per-topology / per-algorithm label block
Label(X,D,T,A) = Label_Block(X,T,A) + Node_Index(D)
T is the topology
A is the algorithm for computing destination-based
forwarding next-hops
D is the destination node
X is the next hop along the path to D that is
determined by algorithm A for topology T
Figure 3: Translating Node-SID to Label: Topology and Algorithm-
Specific Options
In Option 1 each node advertises a single label block, but advertises
a different node index for each combination of topology and algorithm
used. In order for Y to determine the label value that tells X to
reach D via the path chosen by algorithm A for topology T, Y adds the
Node_Index advertised by node D for topology T and algorithm A to the
Label_Block advertised by node X. We refer to this as the per-
topology/per-algorithm node index option.
In Option 2 each node advertises a single node index and a unique
label block along for each combination of topology and algorithm
used. In order for Y to determine the label value that tells X to
reach D via the path chosen by algorithm A for topology T, Y adds the
Node_Index advertised by node D to the Label_Block advertised by node
X for topology T and algorithm A. We refer to this as the per-
topology/per-algorithm label block option.
Note that the formulas in Figure 3 can of course be applied even if
there is only one algorithm and/or only one topology. For example,
if the use case uses multiple topologies but only uses the default
shortest path algorithm (algorithm=0), then option 2 can be written
as: Label(X,D,T,0) = Label_Block(X,T,0) + Node_Index(D), which is
Bowers, et al. Expires April 7, 2016 [Page 5]
Internet-Draft Per-Topology/Per-Algorithm Label Blocks October 2015
independent of algorithm. Similarly, if the use case only uses the
default topology (topology=0) but uses different algorithms, then
option 2 can be written as Label(X,D,0,A) = Label_Block(X,0,A) +
Node_Index(D).
4. Example: Adding Nodes when Multiple Algorithms are In Use
The following example illustrates the practical difficulties
associated with using the per-topology/per-algorithm node index
option alone (option 1 in Figure 3 ). This example is intentionally
simplified to illustrate the need for some kind of convention to
manage the assignment of the unique node index values required by
option 1, even in a simple scenario. The sections below discuss a
more complex example, as well as a specific proposal to manage the
assignment of unique node index values. This simplified example
assumes that the operator does not use multi-topology routing, i.e.
that the default topology is used.
Suppose an operator has a network with 100 nodes, which we will refer
to as R0-R99. The operator assigns the unique node index values 0-99
to those nodes for algorithm=0, in order to accomplish shortest path
routing based on IGP metrics with SR labels. Each node will need to
advertise a label block of size=100.
Assume that at some future point in time, the IETF defines
algorithm=2 to mean shortest path routing based on latency, and
vendors implement this. (See section Section 10 for more discussion
of this example.) Suppose that the operator wants to use latency-
based SPF routes for some traffic and metric-based SPF routes for
other traffic. The operator will need to define a new set of unique
node index values for algorithm=2. A reasonable choice would be to
assign node index values of 100-199 to R0-R99 for algorithm=2. Each
node will now need to advertise a label block of size=200. So far
the need for per-algorithm node index values is an annoyance, but not
too difficult to deal with.
Now assume that the operator needs to add 10 new nodes to the SR
domain, specifically nodes R100-R109. Each node will now need to
advertise a label block of size=220. The main issue is deciding how
to assign per-algorithm node index for the 10 new nodes. One option
is to redo the node index numbering scheme so that R0-R109 have node
index values 0-109 for algorithm=0 and node index values 110-229 for
algorithm=2. However, this requires renumbering existing nodes. The
other option is to avoid renumbering of nodes by assigning nodes
R100-R109 node index values 200-209 for algorithm=0 and node index
values 210-219 for algorithm=1. Each of these approaches has
drawbacks. The first requires renumbering existing nodes, while the
Bowers, et al. Expires April 7, 2016 [Page 6]
Internet-Draft Per-Topology/Per-Algorithm Label Blocks October 2015
second is difficult to maintain since there is no obvious
relationship between the node index values for different algorithms.
In order to reduce the complexity associated with option 1 in this
simple example, a certain amount of pre-planning together with some
convention for assigning node index values to algorithms or
topologies would be useful. Specific proposals for managing unique
node index values when using option 1 are discussed below. First
however, we illustrate the advantages of option 2 for this simple
example.
The use of per-algorithm label blocks avoids the problems associated
with assigning and maintaining unique node index values for each
forwarding algorithm.
When the SR domain is initially deployed, R0-R99 can be assigned node
index values 0-99, as one would expect. When support for algorithm=1
gets added, the operator does not need to assign and configure any
new node index values. Instead, the routers automate the process by
advertising different label blocks for each forwarding algorithm.
When another 10 nodes are added to the SR domain, R100-R109 get
assigned node index values 100-109 as one would expect. And the
router advertises a label block of size=110 for each algorithm, as
one would expect. Adding new nodes in the presence of multiple
forwarding algorithms is simplified significantly with the use of
per-algorithm label blocks.
5. Proposed configured offset mapping method for assigning per-
topology/per-algorithm node-SIDs when using Option 1
If a network operator uses option 1, which requires the assignment of
unique per-topology/per-algorithm node-SIDs, then it is clear that a
common convention or methodology would be useful to help assign and
maintain those unique node-SIDs. The methodology described in this
section represents the authors' understanding of a proposal to manage
assignment of node-SIDs when using option 1, as discussed on the
SPRING mailing list.
The proposed method for managing the assignment of unique node index
values for each topology/algorithm pair involves configuring a
mapping from each topology/algorithm pair to an offset value. This
offset mapping would need to be configured identically on every
router in the network. Figure 4 shows the formula for a router Y to
compute its own unique node index value for each topology/algorithm
pair. Y would then treat those computed node index values as if they
were directly configured via CLI or via Netconf/Yang, advertising
Bowers, et al. Expires April 7, 2016 [Page 7]
Internet-Draft Per-Topology/Per-Algorithm Label Blocks October 2015
them into the IGP and installing the appropriate label operations in
the FIB.
Node_Index(Y,T,A) = Configured_Offset(T,A) + Base_Node_Index(Y)
Y is the computing router
T is the topology
A is the algorithm
Figure 4: Proposed configured offset mapping method to manage
assignment of unique per-topology/per-algorithm node index values
when using Option 1
We illustrate the operation of the configured offset mapping method
with a specific example. In this example, the operator has a network
with 500 nodes, and wants to support four different topologies using
different algorithms. The default topology (topology=0) needs to
support algorithms 0, 4, and 5. Topology 2 and topology 6 need to
support algorithm 0, while topology 7 needs to support algorithm 2.
There are a total of six topology/algorithm pairs. In order to avoid
renumbering the network in the event of unanticipated increases in
the number of nodes or the number of topology/algorithm pairs, the
operator sizes the label offsets and overall label block size to
accomodate 1000 nodes and 12 topology/algorithm pairs.
Figure 5 shows the configuration data required on each of the 500
routers using option 1 together with the configured offset mapping
method to manage node index assignment.
base_node_index=123
label_block_size=12000
topology=0 algorithm=0 offset=0
topology=0 algorithm=4 offset=1000
topology=0 algorithm=5 offset=2000
topology=2 algorithm=0 offset=3000
topology=6 algorithm=0 offset=4000
topology=7 algorithm=2 offset=5000
Figure 5: Required configuration data using option 1
The base_node_index value is the unique node index for a given node,
and will thus be different for each node. The other values define
the overall size of the label block and associate topology algorithm
pairs with an offset value. This set of values must be configured
identically across all routers in the network in order avoid
advertising duplicate node index values. Advertisement of duplicate
Bowers, et al. Expires April 7, 2016 [Page 8]
Internet-Draft Per-Topology/Per-Algorithm Label Blocks October 2015
node index values would disrupt forwarding. The configuration above
would result in R123 computing node index values of 123, 1123, 2123,
3123, 4123, and 5123 for the corresponding topology/algorithm pairs.
For comparison, Figure 6 shows the configuration data required on
each of the 500 routers using option 2. Since the per-topology/per-
algorithm label blocks are advertised independently by each node,
option 2 requires no additional configuration beyond what is required
for default topology shortest path forwarding (topology=0,
algorithm=0).
node_index=123
label_block_size=1000
Figure 6: Required configuration data using option 2
6. Flexibility to create easy-to-interpret label values
For some applications, it may be desirable to arrange things so that
the meaning of label values used for forwarding can be readily
understood by people trouble-shooting the network. When using the
configured offset mapping method with option 1, if one configures a
meaningful base value for the single label block, then the configured
offset values can also be chosen to provide understandable label
values. In the example above with 500 nodes and 6 topology/algorithm
pairs, if the single logically advertised label block consists of a
single numerically contiguous label block from 20000 through 31999
across all routers in the network, then the label values
corresponding to forwarding to R123 using different topology/
algorithm pairs will be meaningful to a people. They will be 20123,
21123, 22123, 23123, 24123, and 25123 for the corresponding topology/
algorithm pairs, so an operator who remembers the mapping between
topology/algorithm pair and offset can tell that 25123 is the label
corresponding to topology=7, algorithm=2, node=123.
When using option 2 (per-topology/per-algorithm label blocks) and
requiring that the topology, algorithm, and node associated with a
label value be easy to interpret, each topology/algorithm pair needs
to have an associated label_block_base configured on every router.
Figure 7 show an example configuration of a mapping from topology/
algorithm pairs to label_block_base values.
Bowers, et al. Expires April 7, 2016 [Page 9]
Internet-Draft Per-Topology/Per-Algorithm Label Blocks October 2015
node_index=123
label_block_size=1000
topology=0 algorithm=0 label_block_base=100000
topology=0 algorithm=4 label_block_base=104000
topology=0 algorithm=5 label_block_base=105000
topology=2 algorithm=0 label_block_base=120000
topology=6 algorithm=0 label_block_base=160000
topology=7 algorithm=2 label_block_base=172000
Figure 7: Configuration data for 500 node example with option 2,
Note in this example that we have taken advantage of the additional
flexibility of option 2 to create label values that are more readable
than from option 1. In this example, a first digit of "1" indicates
that this is a SPRING node label. The second and third digits are
readable as the topology and algorithm, while the last three digits
encode the node number. So 172123 would indicate the node label for
topology=7, algorithm=2, node=123.
In the above example, we have illustrated the flexibility of option 2
to create more readable labels in a hypothetical network with no
constraints on label space. However, it is likely that in a multi-
vendor network with multiple generations of hardware supporting
different MPLS applications there will exist constraints regarding
the location and size of contiguous label blocks for use by SPRING.
This would impose constraints on one's ability to construct readable
label values using option 1 with the configured offset mapping.
Option 2 provides more flexibility to construct easy-to-interpret
label values in such a network.
7. Robustness against misconfiguration
Option 2 is much more robust against misconfiguration than is option
1. This is true both in scenarios that require easy-to-interpret
label values and in scenarios that do not.
In the simple case where the application does not require easy-to-
interpret label values, option 2 has clear advantages over option 1
in terms of robustness again misconfiguration. Option 1 requires
identical offset mapping configurations on all routers for proper
forwarding. Option 2 requires no configuration, so there is nothing
to misconfigure.
In scenarios requiring easy-to-interpret label values, where option 2
requires a label_block_base mapping configuration, option 2 is still
more robust against misconfiguration than option 1. Misconfiguration
of the label_block_base mapping in option 2 does not affect
forwarding. The explicit advertisement of the per-topology/per-
Bowers, et al. Expires April 7, 2016 [Page 10]
Internet-Draft Per-Topology/Per-Algorithm Label Blocks October 2015
algorithm label blocks ensures that forwarding will continue to work
properly.
8. ISIS extensions to encode per-topology/per-algorithm label blocks
Below is a concrete proposal for encoding per-topology/per-algorithm
label blocks in ISIS compatible with the encodings in
[I-D.ietf-isis-segment-routing-extensions].
The newly-defined Topology-Algorithm-Label-Block sub-TLV is shown in
Figure 8. It is carried in the IS-IS Router Capability TLV-242. It
contains a 12-bit MT-ID field as well as an 8-bit Algorithm field
which associates the SRGB Descriptor entries carried in the sub-TLV
with a particular topology and algorithm. Otherwise, the structure
and interpretation of the Topology-Algorithm-Label-Block sub-TLV is
identical to that of the SR-Capabilities sub-TLV defined in section
3.1 of [I-D.ietf-isis-segment-routing-extensions].
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 |R|R|R|R| MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Flags | One or more |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRGB Descriptor entries (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Topology-Algorithm-Label-Block sub-TLV
A single network must use either option 1 or option 2 for all
routers. Mixed mode operation is not supported. When the Topology-
Algorithm-Label-Block sub-TLV is present with a given pair of
topology and algorithm values, routers MUST determine the label
values associated with that topology/algorithm pair using the per-
topology/per-algorithm label block method and the concatenated label
block carried by the Topology-Algorithm-Label-Block sub-TLV. The
node indices used in this calculation are those carried in Node-SID
advertisements with algorithm value=0 in TLV-135(IPv4) or TLV-
236(IPv6).
The Topology-Algorithm-Label-Block sub-TLV MUST NOT be advertised
with both MT-ID=0 and Algorithm value=0. In this way, the
concatenated label block used to compute the label values for the
default topology and algorithm=0 can only be carried by the SR
Capabilities sub-TLV.
Bowers, et al. Expires April 7, 2016 [Page 11]
Internet-Draft Per-Topology/Per-Algorithm Label Blocks October 2015
When using the Topology-Algorithm-Label-Block sub-TLV in a network,
nodes SHOULD only advertise a node index value corresponding to
algorithm=0 in Node-SID advertisements in TLV-135(IPv4) and/or TLV-
236(IPv6). Node index values (with algorithm=0 or any other value)
SHOULD NOT be advertised in TLV-235(MT-IPv4) and TLV-237(MT-IPv6).
If a node originates the Topology-Algorithm-Label-Block sub-TLV
(meaning that it supports option 2), then it MUST ignore the receipt
of node indices for non-zero algorithms in TLV-135 and TLV-236 and
any node index values in TLV-235 and TLV-237.
9. OSPF extensions to encode per-topology/per-algorithm label blocks
OSPF extensions to encode per-topology/per-algorithm label blocks
will be provided in a future version of this draft.
10. A note on algorithms and topologies
The example given in Section 4 supposes that at some point in the
future the IETF defines algorithm=2 to mean shortest path routing
based on latency. This simple example was chosen since it is easy to
understand. However, the same result could also have been achieved
by defining a second topology which uses latency as the metric for
that topology, and running the default SPF algorithm on that second
topology.
In general, when using other algorithms for computing next-hops for
destination-based forwarding, it is not possible to achieve the same
results by simply defining a new topology with modified metrics and
running the default SPF algorithm. An example of such an algorithm
is that used to compute Maximally Redundant Trees (MRTs), as defined
in [I-D.ietf-rtgwg-mrt-frr-algorithm].
11. IANA Considerations
This document requests the following registration in the "sub-TLVs
for TLV 242" registry.
Value: TBA (suggested value 20)
Description: Topology-Algorithm-Label-Block
Reference: This document (Section 8)
12. Management Considerations
This document proposes the use of per-topology/per-algorithm label
blocks (option 2) to support destination-based forwarding along next-
hops computed using different algorithms for different topologies.
Bowers, et al. Expires April 7, 2016 [Page 12]
Internet-Draft Per-Topology/Per-Algorithm Label Blocks October 2015
The automated advertisement of per-topology/per-algorithm label
blocks significantly simplifies network management compared to
configuration and maintenance of unique per-topology/per-algorithm
node indices.
13. Security Considerations
TBD
14. Acknowledgements
The authors thank John Scudder and Eric Rosen for their helpful
review of this document and suggestions.
15. References
15.1. Normative References
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007,
<http://www.rfc-editor.org/info/rfc4915>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<http://www.rfc-editor.org/info/rfc5120>.
15.2. Informative References
[I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
Extensions for Segment Routing", draft-ietf-isis-segment-
routing-extensions-05 (work in progress), June 2015.
[I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-05 (work in progress), June 2015.
[I-D.ietf-rtgwg-mrt-frr-algorithm]
Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
Gopalan, "Algorithms for computing Maximally Redundant
Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr-
algorithm-05 (work in progress), July 2015.
Bowers, et al. Expires April 7, 2016 [Page 13]
Internet-Draft Per-Topology/Per-Algorithm Label Blocks October 2015
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and r. rjs@rob.sh, "Segment Routing Architecture", draft-
ietf-spring-segment-routing-04 (work in progress), July
2015.
Authors' Addresses
Chris Bowers
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: cbowers@juniper.net
Pushpasis Sarkar
Juniper Networks
Embassy Business Park
Bangalore, KA 560093
India
Email: psarkar@juniper.net
Hannes Gredler
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: hannes@juniper.net
Uma Chunduri
Ericsson Inc
300 Holger Way
San Jose, CA 95134
US
Email: uma.chunduri@ericsson.com@
Bowers, et al. Expires April 7, 2016 [Page 14]
