Internet DRAFT - draft-bowers-spring-advertising-lsps-with-sr
draft-bowers-spring-advertising-lsps-with-sr
SPRING Working Group C. Bowers
Internet-Draft H. Gredler
Intended status: Standards Track Juniper Networks
Expires: May 21, 2016 U. Chunduri
Ericsson Inc.
November 18, 2015
Advertising LSPs with Segment Routing
draft-bowers-spring-advertising-lsps-with-sr-02
Abstract
Segment routing uses globally-known labels to accomplish forwarding
along shortest paths, and label stacks to accomplish explicit routing
along arbitrary paths. These labels are advertised using an IGP.
This draft describes how label bindings corresponding to RSVP, LDP,
BGP labeled-unicast, and static LSPs are advertised in segment
routing and how these labels can be combined with other segment
routing labels to create forwarding paths. This draft also describes
how context labels for egress node protection are advertised in using
segment routing IGP extensions.
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."
This Internet-Draft will expire on May 21, 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
Bowers, et al. Expires May 21, 2016 [Page 1]
Internet-Draft Advertising LSPs with Segment Routing November 2015
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. Segment routing label binding advertisements . . . . . . . . 3
3. Conventions used in the following examples . . . . . . . . . 5
4. Advertising an RSVP-TE LSP . . . . . . . . . . . . . . . . . 5
4.1. Advertising a backup ERO . . . . . . . . . . . . . . . . 7
5. Advertising an LDP LSP . . . . . . . . . . . . . . . . . . . 8
6. Advertising a BGP labeled-unicast LSP . . . . . . . . . . . . 9
7. Advertising a static LSP . . . . . . . . . . . . . . . . . . 11
8. Advertising a context label for egress node protection . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Management Considerations . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
[I-D.ietf-spring-segment-routing] describes the segment routing
architecture. In segment routing, LDP-like forwarding behavior along
shortest paths is achieved using globally-known node labels.
Globally-known node labels can be distributed in one of two ways.
Each router can directly advertise a globally unique node label in
the IGP. Or each router can advertise a globally unique node index
value as well as a locally assigned label block, allowing any router
in the IGP area to determine the mapping of locally-assigned label to
globally unique node index for any other router in the area.
In order to forward traffic along strict explicit paths, segment
routing uses stacks of local adjacency labels. Each router uses the
IGP to advertise locally significant adjacency labels corresponding
to each of the router's outgoing interfaces. This allows any router
in the IGP area to construct an arbitrary forwarding path by imposing
a stack of adjacency labels on a packet. Forwarding is accomplished
at each router by reading the top label on the stack to determine
next-hop interface (based on its adjacency label to interface
Bowers, et al. Expires May 21, 2016 [Page 2]
Internet-Draft Advertising LSPs with Segment Routing November 2015
mapping), popping that top label, and forwarding the packet out the
next-hop interface.
The above is only a short description of the use of node and
adjacency labels in segment routing. See
[I-D.ietf-spring-segment-routing] for more detail on node and
adjacency label semantics as well as combining node and adjacency
labels in a label stack.
In addition to node and adjacency label advertisements, which
advertise label bindings corresponding to nodes and interfaces, it is
useful to advertise more abstract label bindings in the IGP, using a
Binding advertisement. This draft describes how label bindings
corresponding to RSVP, LDP, BGP labeled-unicast, and static LSPs are
advertised in segment routing and how these labels can be combined
with other segment routing labels to create forwarding paths. This
draft also describes how context labels for egress node protection
are advertised using a Binding advertisement.
2. Segment routing label binding advertisements
An LSP and its associated label is advertised in the IGP using the
Binding advertisement extensions defined in
[I-D.ietf-isis-segment-routing-extensions] and
[I-D.ietf-ospf-segment-routing-extensions]. The router which is the
ingress for the LSP advertises the label as well as the Forwarding
Equivalency Class(FEC) associated with the LSP. The advertisement
may include other information that describes the LSP. An Explicit
Route Object(ERO) may be included to describe the path taken by the
LSP. An ERO metric value may be included to indicate the cumulative
IGP or TE metric associated with the LSP along the path described by
the ERO.
+-----+ +-----+ +-----+
| | | | | |
R1--| |--R4--| |--R7--| |--R10
| | | | | |
+-----+ +-----+ +-----+
Figure 1: Example network
Consider the network shown in Figure 1. A router R4 advertising a
label L1 and a FEC F using a Binding advertisement to advertise an
LSP is indicating the following forwarding behavior. (See
[I-D.ietf-spring-segment-routing] for a description of the segment
routing label operation and forwarding terminology.) Assume that a
particular packet P arrives at R4 with a segment list/label stack
whose incoming active segment is label L1. R4 performs a NEXT
Bowers, et al. Expires May 21, 2016 [Page 3]
Internet-Draft Advertising LSPs with Segment Routing November 2015
operation on the segment list (equivalent to a label POP operation).
Assume that this results in a label stack of depth m-1, with the m-1
label being the new active segment with respect to segment routing
forwarding actions. R4 forwards P to the router associated with FEC
F (call it R7) by means of a Label Switched Path. The precise set of
MPLS label operations that get P from R4 to R7 is not specified.
However, the label operations MUST satisfy the properties of a "Label
Switched Path of level m" described in [RFC3031] Section 3.15, where
R4 plays the role of LSP Ingress and R7 plays the role of LSP Egress.
In particular, if R4 (acting as the LSP Ingress) pushes a level m
label onto P's label stack, then the forwarding decision on each
router between R4 and R7 cannot make use of label information below
the level m label in the label stack.
Instead, the forwarding decision at R7 (acting as the LSP Egress)
does make use of label information (or packet header information)
below the level m label. Note that the level m LSP from R4 to R7 is
not exclusively reserved for carrying traffic that enters at R4 via
the segment routing mechanism described above. In general, it will
also carry labeled or unlabeled packets that enter the LSP via other
mechanisms. Also, the packets may have entered the LSP at a router
other than R4 in the case of label merging. For example, in
situations where R7 needs to make use of the value of the level m
label for the processing of other traffic, R7 may distribute a non-
null label to the penultimate hop router in the level m LSP from R4
to R7. R7 needs to be able to properly and consistently process the
packet P that originated at R4 via the segment routing mechanism
described above, regardless of the details of how R7 is performing
the LSP egress role for other traffic.
If m=1, then R7 should forward P based on the received packet header
information. If m>1, then the m-1 label of P at R7 MUST correspond
to a label distributed by R7. If the m-1 label corresponds to a
segment routing label, then R7 MUST treat the m-1 label as the
incoming active segment and perform the corresponding incoming label
operations and forwarding action. R7 MUST the perform any necessary
additional label operations to ensure that the next SR-capable router
that receives the packet can correctly determine the incoming active
segment. For example, if R7 distributed a non-null or explicit null
label to the penultimate hop router in the level m LSP from R4 to R7,
then R7 MUST POP that label before performing the segment routing
label operation required by the incoming active segment, the m-1
label.
Continuing with the example above, a segment routing capable router
R1 uses the information describing the LSP contained in the Binding
advertisement (FEC, ERO, metric, etc.) to determine if it wants to
use that LSP as part of a longer forwarding path. If so, R1 uses the
Bowers, et al. Expires May 21, 2016 [Page 4]
Internet-Draft Advertising LSPs with Segment Routing November 2015
label L1 advertised by R4 for the LSP in the construction of a label
stack. R1 can use any combination of segment routing labels stacked
above L1 to define a path to reach R1. The only requirement is that
label L1 be the incoming active segment when the packet reaches R4.
This will ensure that R4 forwards the packet to R7. If R1 has
determined that R7 supports segment routing, then R1 can also include
additional segment routing labels below L1 in the label stack to
specify the forwarding path beyond R7.
The description above assumes that R1 is responsible for computing
the forwarding path and the associated label stack. However, the
same forwarding behavior can be achieved if a centralized controller
is used to compute the path and communicate the associated label
stack to R1 via PCEP with the appropriate segment routing extensions
(see [I-D.ietf-pce-segment-routing]). The same is true of the
examples for specific label distribution protocols provided below.
3. Conventions used in the following examples
To simplify the diagrams and descriptions of the examples in this
draft, we assume that all routers advertise a router-id of the form
192.0.2.XX, where XX is the router number of the form RXX. For
example, in Figure 2 R16 advertises router-id=192.0.2.16 as a
loopback address.
Unless otherwise stated, links between routers all have the same IGP
metric of 10.
The node-SID index value for a router with name RXX will be XX. For
example, R23 in Figure 2 has an index value of 23. We assume that
all routers are advertising the same SR Global Block of 1000-1099.
For example, for R11 Figure 2 to send a packet to R23 on the shortest
path, R11 sends the packet to R13 with the top label equal to 1023.
4. Advertising an RSVP-TE LSP
+-R35-+
/ \
R11-------R13--R14--R15--R16--R17--R18
| | | | | | |
R21--R22--R23--R24--R25--R26--R27--R28
|<--- SR --->| |<--- SR --->|
|<------RSVP------>|
Figure 2: Example network with segment routing and RSVP
Bowers, et al. Expires May 21, 2016 [Page 5]
Internet-Draft Advertising LSPs with Segment Routing November 2015
Figure 2 shows a network that uses both segment routing and RSVP.
Segment routing is enabled on R11, R13, R21, R22, R23, R16, R17, R18,
R26, R27, and R28. RSVP is enabled on R13, R14, R15, R16, R23, R24,
R25, R26, and R35. Note that both segment routing and RSVP are
enabled on R13, R23, R16, and R26. R23 uses RSVP to signal an LSP
from R23 to R16, following the path R23->R24->R25->R26->R16. R23
uses a Binding advertisement to advertise the following values:
o label value = 2099
o FEC = 192.0.2.16/32
o ERO = (192.0.2.24[strict], 192.0.2.25[strict], 192.0.2.26[strict],
192.0.2.16[strict])
R11 receives the Binding advertisement and decides (based on some
policy) to forward traffic from R11 to R18 along a path that consists
of the following partial paths:
o the shortest path from R11 to R23
o the path from R23 to R16 following the explicit path
R23->R24->R25->R26->R16
o the shortest path from R16 to R18
In order to accomplish this, R11 sends packets to R13 with the label
stack = <1023,2099,1018>. Label 1023 corresponds to the node-SID
label for R23, and thus results in forwarding along the shortest path
from R11 to R23. The packets will arrive at R23 with label stack =
<2099,1018>. The top label value of 2099 at R23 will result in
forwarding of packets along the path R23->R24->R25->R26->R16 using
the label SWAP operations signalled by RSVP for this LSP. With
penultimate hop popping, the packets will arrive at R16 with label
stack = <1018>. Label 1018 corresponds to the node-SID label for
R18, and thus results in forwarding along the shortest path from R16
to R18.
R11 may use the information about the primary path in this Binding
advertisement to decide whether or not to construct SR label stacks
that use this RSVP LSP. For example, R11 may have a requirement to
avoid forwarding traffic over primary paths that include R35. The
ERO advertised in this Binding advertisement satisfies this
requirement.
Note that the scenario described in this example is very similar to
the commonly deployed LDP-over-RSVP architecture, with shortest path
routing with LDP at the edges and explicit routing with RSVP in the
Bowers, et al. Expires May 21, 2016 [Page 6]
Internet-Draft Advertising LSPs with Segment Routing November 2015
core. However, it is difficult to achieve fine-grained forwarding
behavior described in this example using LDP-over-RSVP. In an LDP-
over-RSVP network, the only way to influence which LDP/edge traffic
gets tunnelled over which RSVP LSPs is to advertise the RSVP LSPs as
forwarding adjacencies (FAs) and tune the IGP metrics of the FAs. It
may be difficult or impossible to achieve the desired mapping of LDP/
edge traffic over RSVP LSPs by tuning the metrics of FAs.
Instead, with the SR-and-RSVP architecture described above, it is
possible to achieve an arbitrary mapping of edge traffic to core RSVP
LSPs using a maximum label stack depth of 3, assuming shortest path
forwarding between edge and core nodes via node-SIDs.
One could also build label stacks using adjacency labels advertised
by SR-capable routers in the edge networks in order to forward
traffic along non-shortest paths in the edge networks. More explicit
control of forwarding paths in the edge networks would come at the
expense of deeper label stacks.
4.1. Advertising a backup ERO
Continuing with the example of Figure 2, it may also be desirable for
R23 to provide information about backup paths that may be used in the
event of a failure affecting the primary path. For example, assume
that R23 has signalled a primary LSP along the path
R23->R24->R25->R26->R16 and a backup LSP along the path
R23->R13->R14->R35->R16. R23 uses a Binding advertisement to
advertise the following values:
o label value = 2099
o FEC = 192.0.2.16/32
o ERO = (192.0.2.24[strict], 192.0.2.25[strict], 192.0.2.26[strict],
192.0.2.16[strict])
o backup ERO = (192.0.2.13[strict], 192.0.2.14[strict],
192.0.2.35[strict], 192.0.2.16[strict])
R11 may use the information about the backup path in this Binding
advertisement to decide whether or not to construct SR label stacks
that use this RSVP LSP. For example, R11 may have a requirement to
avoid forwarding traffic over primary or backup paths that include
R35.
Bowers, et al. Expires May 21, 2016 [Page 7]
Internet-Draft Advertising LSPs with Segment Routing November 2015
5. Advertising an LDP LSP
R31--R32--R33--R34--R35--R36
|<------ SR ----->|
|<--- LDP --->|
Figure 3: Example network with segment routing and LDP
Figure 3 shows a network that uses both segment routing and LDP.
Segment routing is enabled on R31-34, while LDP is enabled on R34-36.
Note that both segment routing and LDP are enabled on R34. Also note
that LDP is NOT enabled on R31, R32 and R33. R34 has received a
label mapping for FEC=192.0.2.36/32 from R35 using LDP, corresponding
to an LDP LSP from R34 to R36 along the shortest path. R34 uses a
Binding advertisement to advertise the following values:
o label value = 2088
o FEC = 192.0.2.36/32
After receiving this Binding advertisement, R31 can forward traffic
to R36 by sending packets to next-hop R32 with label stack =
<1034,2088>. The packets will arrive at R34 with label stack =
<2088>. The top label value of 2088 at R34 will result in forwarding
of packets along the shortest path to R36 using the label SWAP
operations for FEC = 192.0.2.36/32 signalled by LDP.
Now we look at what is needed to forward labeled traffic from R36 in
the LDP-only domain to R31 in the SR-only domain. R34 can get a
packet to R31 using R31's node-SID label (1031). In order for R34 to
apply label=1031 to packets in FEC 192.0.2.31, packets need to arrive
at R34 with a label corresponding to FEC 192.0.2.31. Therefore R34
should not use penultimate hop popping when it distributes a label to
the LDP-only domain.
The routers in the LDP-only domain (R34, R35, and R36) advertise
label mappings for FEC 192.0.2.31/32 using LDP. This corresponds to
normal LDP behavior based on [RFC5036] since R34, R35, and R36 each
has an entry in its routing table for 192.0.2.31/32, and in the
absence of segment routing, R34 is an egress LSR with respect to FEC
192.0.2.31/32. This will allow packets to travel from R36 to R34
using LDP labels. Via LDP, R34 advertises the label value 3154 for
FEC 192.0.2.31/32 (instead of implicit or explicit null). Packets
from R36 arrive at R34 with label=3154. R34 recognizes that
label=3154 corresponds to FEC 192.0.2.31/32, so it swaps the label
with outgoing label=1031 (the node-SID for R31), and forwards the
Bowers, et al. Expires May 21, 2016 [Page 8]
Internet-Draft Advertising LSPs with Segment Routing November 2015
packet to next-hop R33. The packet will ultimately be delivered to
R31 over the shortest path in the SR-only network using the node-SID.
Note that [I-D.filsfils-spring-segment-routing-ldp-interop] describes
a different method (utilizing a Segment Routing Mapping Server) to
allow SR-enabled nodes to send traffic to LDP nodes that do not
support SR.
6. Advertising a BGP labeled-unicast LSP
region 1 | region 2 | region 3
R71-------R72-----R81-------R82-----R91-------R92
| | | | | |
R73--R74--R75-----R83--R84--R85-----R93--R94--R95
|<---- SR ---->|<----- LDP ----->|<---- LDP --->|
^ ^ ^ ^ ^ ^ ^ ^
\___/ \_____/ \___/ \_____/
BGP-LU BGP-LU BGP-LU BGP-LU
Figure 4: Example network with segment routing and BGP labeled
unicast
Figure 4 shows a network that uses segment routing together with BGP
labeled-unicast (BGP-LU) [RFC3107]. In this example, segment routing
is enabled on R71-75 (region 1). LDP is enabled on R81-85 (region 2)
and R91-95 (region 3). In addition, BGP-LU sessions exist between
R75 and R83, R83 and R85, R85 and R93, and R93 and R95. Via LDP, R93
learns a label value of 3009 from R94 corresponding to FEC
192.0.2.95/32. Via its BGP-LU session with R85, R93 advertises a
label value of 4021 corresponding to prefix 192.0.2.95/32, with a
next-hop of 192.0.2.93. Via its BGP-LU session with R83, R85
advertises a label value of 4031 corresponding to prefix
192.0.2.95/32, with a next-hop of 192.0.2.85. Via its BGP-LU session
with R75, R83 advertises a label value of 4041 corresponding to
prefix 192.0.2.95/32, with a next-hop of 192.0.2.83. R75 uses a
segment routing Binding advertisement to advertise the following
values:
o label value = 2077
o FEC = 192.0.2.95/32
o ERO = (192.0.2.83[strict])
Bowers, et al. Expires May 21, 2016 [Page 9]
Internet-Draft Advertising LSPs with Segment Routing November 2015
In this example, R75 has included an ERO list with a single element
corresponding to the directly connected next-hop from R75 to R83.
Its inclusion by R75 is optional, but the information may be useful
to routers that receive the Binding advertisement. R75 could also
optionally include a loose hop for R93 in the ERO since it knows that
information from the BGP Originator_ID attribute of the BGP-LU
advertisement.
R71 receives the Binding advertisement via the IGP. In order to send
a labeled packet to R95, R71 needs to construct a label stack that
causes the packet to arrive at R75 with top label=2077. If R71 wants
the packet to take the shortest path from R71 to R75, then it sends
the packet to R72 with label stack = <1075,2077>. (Label 1075 is the
node-SID for R75 based on the conventions in Section 3.) The packet
arrives at R75 with label stack = <2077>. R75 swaps label 2077 with
label 4041 and forwards the packet to next-hop R83. R83 swaps label
4031 with label 4021, pushes the LDP label distributed by R84 for
FEC=192.0.2.85, and forwards the packet to next-hop R84. The packet
arrives at R85 with label 4031 exposed, so R85 swaps label 4031 with
label 4021, and forwards the packet to next-hop R93. Finally R93
swaps label 4021 with label 3009 and forwards the packet to next-hop
R94, allowing the packet to be delivered to R95 via LDP label
operations.
If instead R71 wants the packet to take the path R71->R73->R74->R75,
then it would send the packet to R73 with two adjacency labels
corresponding to the links between R73 and R74 and between R74 and
R75, followed by the label 2077.
The above description accounts for sending labeled packets from a
source in a segment routing region to a destination in another region
using paths established by BGP-LU. Since the example is not
symmetric with respect to source and destination, for completeness,
we illustrate how traffic to send traffic from another region to a
destination in a segment routing region using LSPs established by
BGP-LU, which in this example corresponds to sending a packet from
R95 to R71.
R75 knows that it can send a packet to R71 by imposing a node-SID
label of 1071. Via its BGP-LU session with R83, R75 advertises a
label value of 4052 for prefix 192.0.2.71/32, with a next-hop of
192.0.2.75. The string of BGP-LU sessions from R83 to R85 to R93 to
R95 advertise label bindings for prefix 192.0.2.71/32 such that R95
can send a packet to R93 with the appropriate BGP-LU label that the
packet will arrive at R75 with label 4052 exposed as the top label.
When R75 receives this packet, it swaps label 4052 with label 1071
and forwards the packet to next-hop R72, resulting in the packet
being delivered to R71.
Bowers, et al. Expires May 21, 2016 [Page 10]
Internet-Draft Advertising LSPs with Segment Routing November 2015
7. Advertising a static LSP
+-R54-+
/ \
+-R51 AS5 R53--+
/ \ / \
/ +-R52-+ R71---R74
R41----R42----R43 | AS7 |
| | \ +-R66-+ R72---R73
| | \ / \ /
| AS4 | +-R61 R65--+
| | | AS6 |
| | | |
R44----R45----R46----R62 R64
\ /
+-R63-+
|<---- SR ----->|
Figure 5: Example network using segment routing extensions to
advertise a static lsp
In Figure 5, each grouping of routers (R41-46, R51-54, R61-66, and
R71-74) represents a different autonomous system (AS 4,5,6, and 7
respectively). Segment routing is enabled on R41-46. R43 has two
interfaces that connect to routers outside of its AS. One egress
interface connects to R51 while another connects to R61. It is
desirable for routers in AS4 to be able to send traffic to R43 with a
label stack that indicates the interface that R43 should use to send
the traffic. This can be accomplished by having R43 advertise label
bindings for one-hop static LSPs corresponding to each of its egress
interfaces. In order to advertise the egress interface connected to
R51, R43 uses a segment routing Binding advertisement to advertise
the following values:
o label value = 2033
o FEC = 192.0.2.51/32
o ERO = (192.0.2.51[strict])
In order to advertise the egress interface connected to R61, R43 uses
a segment routing Binding advertisement to advertise the following
values:
Bowers, et al. Expires May 21, 2016 [Page 11]
Internet-Draft Advertising LSPs with Segment Routing November 2015
o label value = 2034
o FEC = 192.0.2.61/32
o ERO = (192.0.2.61[strict])
R41 receives the Binding advertisements via the IGP. In order to
send a packet out R43's interface to R51, R41 constructs a packet
with label stack = <1043,2033> and sends it to R42. (Label 1043 is
the node-SID for R43 based on the conventions in Section 3.) The
packet arrives at R43 with label stack = <2033>. R43 will POP label
2033 and send the unlabeled packet out the interface to R51.
Similarly in order to send a packet out R43's interface to R56, R41
constructs a packet with label stack = <1043,2034> and sends it to
R42.
8. Advertising a context label for egress node protection
/- RR -\
/ \
PE3---P7----------P8---PE5
/ | | \
CE1 | | CE2
\ | | /
PE4---P9---P10---P11---PE6
|<--------- LDP ---------->|
Figure 6: Example network using segment routing extensions to
advertise a context label for egress node protection
[I-D.minto-2547-egress-node-fast-protection] describes a mechanism to
provide fast protection of RFC 2547/4364 based VPN traffic against
egress PE failure. In the example in Figure 6, CE1 and CE2 are each
dual-homed to two different PEs and belong to the VPN-A. In the
absence of a failure, traffic travels from CE1 to CE2 over the path
CE1->PE3->P7->P8->PE5->CE2. Using the mechanism described in
[I-D.minto-2547-egress-node-fast-protection], upon the failure of
PE5, the point of local repair (P8) can use a loop-free alternate
(LFA) to divert the traffic destined for protected PE (PE5) to a
Protector function co-located with an alternate egress PE for CE2
(PE6). Before forwarding the traffic to PE6, P8 pushes a context
label associated with PE5 (the protected PE). This context label
allows PE6 to interpret the VPN label in the context of PE5 VPN label
advertisements, since the VPN label on these packets was originally
Bowers, et al. Expires May 21, 2016 [Page 12]
Internet-Draft Advertising LSPs with Segment Routing November 2015
imposed by the ingress PE (PE3) based on the assumption that they
would be delivered to PE5.
We assume in this example that there is a single context-identifier
corresponding to the protected PE (PE5) with a value of 203.0.113.5.
The prefix 203.0.113.5/32 is advertised in the IGP and in LDP by PE5.
PE5 advertises VPN-IP prefixes via BGP with next-hop = 203.0.113.5.
This causes VPN traffic from PE3 to PE5 will take an LDP transport
tunnel corresponding to FEC 203.0.113.5/32.
PE6 advertises a context label for context-identifier 203.0.113.5
using a segment routing Binding advertisement with the following
values:
o label value = 2066
o FEC = 203.0.113.5/32
o Mirror context = TRUE
When P8 receives this Binding advertisement via the IGP, it creates a
forwarding table entry for LDP traffic in FEC 203.0.113.5 that will
be activated immediately when the link to PE5 fails. This behavior
is triggered by setting Mirror context = TRUE in the advertisement.
This backup forwarding table entry uses a loop-free alternate (LFA)
or remote LFA to send traffic to PE6 (using FEC 192.0.2.6 which is
the router-id of PE6) along a path that avoids passing through PE5.
Importantly, the backup forwarding table entry pushes label 2066 into
the packet before applying any labels associated with the repair path
to PE6.
When the link to PE5 fails and P8 activates the backup forwarding
table entry for LDP traffic in FEC 203.0.113.5, that traffic will be
diverted to PE6. The packets will arrive at PE6 with top label =
2066, followed by the VPN label advertised by PE5. PE6 pops label
2066, and interprets the next label as a VPN label advertised by PE5.
PE6 has been listening in on PE5s BGP advertisements, so it knows the
mapping between a given VPN label advertised by PE5 and the actual
VPN.
9. IANA Considerations
This document introduces no new IANA Considerations.
Bowers, et al. Expires May 21, 2016 [Page 13]
Internet-Draft Advertising LSPs with Segment Routing November 2015
10. Management Considerations
TBD
11. Security Considerations
TBD
12. Acknowledgements
The authors would like to thank Bruno Decraene and Nick Slabakov for
their suggestions and review.
13. References
13.1. Normative References
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,
<http://www.rfc-editor.org/info/rfc3107>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>.
13.2. Informative References
[I-D.filsfils-spring-segment-routing-ldp-interop]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing interoperability with LDP", draft-
filsfils-spring-segment-routing-ldp-interop-02 (work in
progress), September 2014.
[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-03 (work in progress), October 2014.
Bowers, et al. Expires May 21, 2016 [Page 14]
Internet-Draft Advertising LSPs with Segment Routing November 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-04 (work in progress), February 2015.
[I-D.ietf-pce-segment-routing]
Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
Raszuk, R., Lopez, V., and J. Tantsura, "PCEP Extensions
for Segment Routing", draft-ietf-pce-segment-routing-00
(work in progress), October 2014.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,
and E. Crabbe, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-01 (work in progress), February
2015.
[I-D.minto-2547-egress-node-fast-protection]
Jeganathan, J., Gredler, H., and B. Decraene, "2547 egress
PE Fast Failure Protection", draft-minto-2547-egress-node-
fast-protection-03 (work in progress), July 2014.
Authors' Addresses
Chris Bowers
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: cbowers@juniper.net
Hannes Gredler
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: hannes@juniper.net
Bowers, et al. Expires May 21, 2016 [Page 15]
Internet-Draft Advertising LSPs with Segment Routing November 2015
Uma Chunduri
Ericsson Inc.
300 Holger Way
San Jose, CA 95134
US
Email: uma.chunduri@ericsson.com
Bowers, et al. Expires May 21, 2016 [Page 16]
