Internet DRAFT - draft-peng-rtgwg-mrt-frr-sr
draft-peng-rtgwg-mrt-frr-sr
RTGWG WG Shaofu. Peng
Internet-Draft Ran. Chen
Intended status: Standards Track ZTE Corporation
Expires: March 2, 2017 August 29, 2016
Maximally Redundant Trees Fast Reroute using Segment Routing
draft-peng-rtgwg-mrt-frr-sr-00.txt
Abstract
This document presents a mechanism aimed at providing segment routing
forwarding option for MRT-FRR. It defines five new MRT Profiles,
each using SR-LSP, SR-tunnel, etc., forwarding option respectively.
These MRT Profiles will be very useful in the case of segment routing
network without LDP deployed. On the other hand, MRT-FRR is also a
competitive solution comparing with others for segment routing
network.
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 March 2, 2017.
Copyright Notice
Copyright (c) 2016 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
Peng & Chen Expires March 2, 2017 [Page 1]
Internet-Draft MRT using SR August 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Five New MRT Forwarding Options . . . . . . . . . . . . . . . 3
2.1. Option 1: MRT SR-tunnel Option . . . . . . . . . . . . . 4
2.1.1. Forwarding SR Label Unicast Traffic over MRT Paths . 5
2.1.2. Forwarding IP Unicast Traffic over MRT Paths . . . . 6
2.1.3. Inter-area Forwarding Behavior . . . . . . . . . . . 6
2.1.4. Prefixes Multiply Attached to the MRT Island . . . . 6
2.1.5. FIB examples . . . . . . . . . . . . . . . . . . . . 6
2.2. Option 2: MRT SR-LSP Tunneling with multi-prefix-sid
Option . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Forwarding SR Label Unicast Traffic over MRT Paths . 8
2.2.2. Forwarding IP Unicast Traffic over MRT Paths . . . . 8
2.2.3. Inter-area Forwarding Behavior . . . . . . . . . . . 9
2.2.4. Prefixes Multiply Attached to the MRT Island . . . . 9
2.2.5. FIB examples . . . . . . . . . . . . . . . . . . . . 9
2.3. Option 3: MRT SR-LSP Tunneling with multi-SRGB Option . . 10
2.3.1. Forwarding SR Label Unicast Traffic over MRT Paths . 11
2.3.2. Forwarding IP Unicast Traffic over MRT Paths . . . . 12
2.3.3. Inter-area Forwarding Behavior . . . . . . . . . . . 12
2.3.4. Prefixes Multiply Attached to the MRT Island . . . . 12
2.3.5. FIB examples . . . . . . . . . . . . . . . . . . . . 12
2.4. Option 4: MRT SR-LSP Non-tunneling with multi-SRGB Option 13
2.4.1. Forwarding SR Label Unicast Traffic over MRT Paths . 14
2.4.2. Forwarding IP Unicast Traffic over MRT Paths . . . . 15
2.4.3. Inter-area Forwarding Behavior . . . . . . . . . . . 15
2.4.4. Prefixes Multiply Attached to the MRT Island . . . . 15
2.4.5. FIB examples . . . . . . . . . . . . . . . . . . . . 16
2.5. Option 5: MRT SR-LSP Non-tunneling with multi-prefix-sid
Option . . . . . . . . . . . . . . . . . . . . . . . . . 18
3. Interoperation . . . . . . . . . . . . . . . . . . . . . . . 18
3.1. Multiple Profiles Coexistence . . . . . . . . . . . . . . 19
3.2. Multiple Profiles Interworking . . . . . . . . . . . . . 20
4. Support protecting segment list . . . . . . . . . . . . . . . 21
4.1. Received segment list is {segment F or S->F, vpn label}
or {segment F or S->F} . . . . . . . . . . . . . . . . . 22
4.2. Received segment list is {segment F or S->F, segment D1
or F->D1, segment D2, ..., segment Dn, vpn label} . . . . 23
4.3. Received segment list is {segment D1, segment D2, ...,
segment Dn, vpn label} . . . . . . . . . . . . . . . . . 24
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Normative References . . . . . . . . . . . . . . . . . . 26
Peng & Chen Expires March 2, 2017 [Page 2]
Internet-Draft MRT using SR August 2016
7.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction
MRT-FRR [RFC7812] creates two alternate forwarding trees that are
distinct from the primary next-hop forwarding used during stable
operation. These two trees are maximally diverse from each other,
providing link and node protection for 100% of paths and failures as
long as the failure does not cut the network into multiple pieces.
MRT-FRR has defined some forwarding mechanism options, including LDP
Label Option 1A and 1B, IP Tunnel Option 2A and 2B. Among these
options, LDP Label Option 1A is a more appropriate choice, which is
selected as the forwarding mechanism in MRT default profile.
Segment Routing [I-D.ietf-spring-segment-routing] allows to enforce a
flow through any path and service chain while maintaining per-flow
state only at the ingress node of the SR domain. Segment Routing can
be directly applied to the MPLS architecture [RFC3031] with no change
on the forwarding plane. A segment is encoded as an MPLS label. An
ordered list of segments is encoded as a stack of labels. For each
IGP-prefix segment in the segment list, it will forward packet
according to shortest path to destination corresponding to the
prefix, that has similar characteristics as an LDP LSP, so we can
term it as an SR LSP. For the whole segment list, it will specify a
forwarding path, other than the normal shortest path, so we can term
it as an SR tunnel.
It is necessary to introduce MRT-FRR function as a new choice to
segment routing network for reliability. First, MRT-FRR will bring a
more competitive FRR solution to SR. Second, SR forwarding mechanism
will greatly simplify MRT-FRR function.
2. Five New MRT Forwarding Options
The following five new options for MRT forwarding mechanisms are
introduced.
1. MRT SR-tunnel Option
2. MRT SR-LSP Tunneling with multi-prefix-sid Option
3. MRT SR-LSP Tunneling with multi-SRGB Option
4. MRT SR-LSP Non-tunneling with multi-SRGB Option
5. MRT SR-LSP Non-tunneling with multi-prefix-sid Option
Peng & Chen Expires March 2, 2017 [Page 3]
Internet-Draft MRT using SR August 2016
Respectively, we can define 5 new MRT profiles. Each profile is
almost same as the default MRT profile, except the forwarding
mechanisms would be set to the above value respectively, and allocate
different MRT MT-IDs. For example, the MRT profile which support
"MRT SR-tunnel Option" forwarding mechanism would be as the
following:
MRT Algorithm: MRT Lowpoint algorithm defined in [RFC7811].
MRT-Red MT-ID: To be allocated.
MRT-Blue MT-ID: To be allocated.
GADAG Root Selection Policy: Among the routers in the MRT Island with
the lowest numerical value advertised for GADAG Root Selection
Priority, an implementation MUST pick the router with the highest
Router ID to be the GADAG root. Note that a lower numerical value
for GADAG Root Selection Priority indicates a higher preference for
selection.
Forwarding Mechanisms: MRT SR-tunnel Option
Recalculation: Recalculation of MRTs SHOULD occur. This allows the
MRT forwarding topologies to support IP/LDP fast-reroute traffic.
Area/Level Border Behavior: ABRs/LBRs SHOULD ensure that traffic
leaving the area also exits the MRT-Red or MRT-Blue forwarding
topology.
2.1. Option 1: MRT SR-tunnel Option
MRT SR-tunnel Option will treat the whole MRT-red or MRT-blue path as
a segment list. Only FEC-label binding for the default topology-
scoped FEC is needed. The specified segment list will direct the
packet along the expected MRT path, but totally in the default
topology. In order to forward packet along the expected MRT path
strictly, the specified segment list suggests to be an adjacency
segment list.
Peng & Chen Expires March 2, 2017 [Page 4]
Internet-Draft MRT using SR August 2016
____
[F]---{____}................[D]
| .
| .
| .
[S]---[N1]---[N2]---[N3].......
=======================>
MRT-Red path
Figure 1: MRT SR-tunnel Forwarding Mechanism
In Figure 1 above, supposed that the MRT-Red path is S-N1-N2-N3,
which is used to protect the default primary nexthop F. Packets
could be pushed to the SR-tunnel with segment list {N1,N2,N3} when
the primary nexthop F is failed.
We can optimize a long adjacency segment list to a short node segment
list. However, packets forwarding along a node segment list will not
ensure to be strictly forwarded along the expected MRT path, as each
node segment will always forward packets along the shortest path
according to the newest topology that maybe different with the
topology when doing optimazition, also as each transit node can do
local repair again for further failures, that could cause packet-
forwarding micro-loop among two or more routers. Note that node
segment list allows to try best to protect traffic for multiple
simultaneous failures. Using adjacency segment list or node segment
list is an implementation choice. Optimazition from a adjacency
segment list to a node segment list is out of the scope of this
document.
Note that we can support tunneling traffic along an MRT to a tunnel
endpoint that is not the destination of the traffic.
2.1.1. Forwarding SR Label Unicast Traffic over MRT Paths
When a PLR receives an SR label packet that needs to be forwarded on
the MRT-Red (for example), it first does a label swap operation,
replacing the incoming SR label assigned by the PLR for the FEC with
the SR label assigned by the tunnel endpoint for that FEC, then push
the whole label stack corresponding to the segment list of the MRT-
Red path. The packet will forward to the tunnel endpoint (also MRT
egress), then leave the MRT path to the shortest path to the
destination.
Peng & Chen Expires March 2, 2017 [Page 5]
Internet-Draft MRT using SR August 2016
2.1.2. Forwarding IP Unicast Traffic over MRT Paths
When a PLR receives an IP packet that needs to be forwarded on the
MRT-Red to a particular tunnel endpoint, it does a label stack push
operation. The label stack pushed is the segment list of the MRT-Red
path. The packet will forward to the tunnel endpoint (also MRT
egress), then leave the MRT path to the shortest path to the
destination.
2.1.3. Inter-area Forwarding Behavior
As [RFC7812] described, it is desirable for traffic leaving the area
to also exit MRT-Red or MRT-Blue and return to shortest path
forwarding. However, this option always terminates the SR-tunnel
corresponding to an MRT path at the MRT egress, the packets will
leave the MRT path and continue to be forwarded according to the
default topology-scoped SR label or IP header. There is no MRT
specific perfix-sid in this option to create MRT specific SR LIB
entry. Other considerations see "section 3. interoperation".
2.1.4. Prefixes Multiply Attached to the MRT Island
This option will use tunnel endpoint selection approach to protection
for both multihomed prefix (outside the area) and destinations
outside the MRT Island (but inside the area). The forwarding
behavior for these prefixes and ones that inside the MRT Island are
totally same.
2.1.5. FIB examples
A node S in the MRT Island will maintain the following FTN entry for
a destination prefix: (suppose that the primary nexthop is F, and the
MRT-red path is N1-N2-N3 that is used to protect the primary
nexthop.)
example 1
KEY: MT-ID 0, prefix
Primary NHLFE: F, SRGB_F[prefix-sid]
According to adjacency segment list, the backup NHLFE would be:
Backup NHLFE: N1, adj-sid-N1toN2 ;outermost label
adj-sid-N2toN3
SRGB_N3[prefix-sid]
According to node segment list, the backup NHLFE would be:
Backup NHLFE: N1, SRGB_N1[N1-sid] ;outermost label
SRGB_N1[N2-sid]
SRGB_N2[N3-sid]
SRGB_N3[prefix-sid]
Peng & Chen Expires March 2, 2017 [Page 6]
Internet-Draft MRT using SR August 2016
Also, a LIB entry for FEC (MT-ID 0, prefix) is as the following:
example 2
KEY: SRGB_S[prefix-sid]
Primary NHLFE: F, SRGB_F[prefix-sid]
According to adjacency segment list, the backup NHLFE would be:
Backup NHLFE: N1, adj-sid-N1toN2 ;outermost label
adj-sid-N2toN3
SRGB_N3[prefix-sid]
According to node segment list, the backup NHLFE would be:
Backup NHLFE: N1, SRGB_N1[N1-sid] ;outermost label
SRGB_N1[N2-sid]
SRGB_N2[N3-sid]
SRGB_N3[prefix-sid]
2.2. Option 2: MRT SR-LSP Tunneling with multi-prefix-sid Option
This Option will allocate a different FEC-label binding for each of
the three topology-scoped FECs, i.e. default-FEC, red-FEC, blue-FEC,
originated by routers inside the MRT Island. For example, When a
packet is received with an SR label corresponding to red-FEC, an MRT
transit router will determine the next hop for the MRT-Red forwarding
topology for that FEC, swap the incoming SR label with the outgoing
SR label corresponding to the MRT-Red next-hop router, and forward
the packet.
The above FEC-label binding is caculated by prefix-sid for each of
the three topology-scoped prefixes depending on default topology-
scoped SRGB. Each router inside the MRT Island supporting this
option will allocate three node-sids, i.e. default-node-sid, red-
node-sid, blue-node-sid. In fact, We only need allocate node-sid for
each of the three topology-scoped Node-flag prefixes for each router
inside the MRT Island. Other prefixes inside the MRT Island could
also be allocated the corresponding MRT topology-scoped prefix-sids
besides the default topology-scoped prefix-sid, but it is not
necessary for this option. And, prefixes outside the MRT Island,
especially outside the area/level, need never allocate MRT topology-
scoped prefix-sids, as a simple reason is that routers outsid the MRT
Island have no idea about the MRT Island. Packets to the later two
class prefixes could be tunneled in the SR-LSP to the tunnel endpoint
which is inside the MRT Island. The MRT specific prefix-sid MUST
only be advertised intra the area which the MRT Island belongs to.
Note that we can support tunneling traffic along an MRT to a tunnel
endpoint that is not the destination of the traffic.
Peng & Chen Expires March 2, 2017 [Page 7]
Internet-Draft MRT using SR August 2016
____
[F]---{____}................[D]
| .
| .
| . for node N3:
[S]---[N1]---[N2]---[N3]...... MT-default node-sid: 30
=======================> MT-red node-sid:31
MRT-Red path MT-blue node-sid:32
Figure 2: MRT SR-LSP Tunneling with multi-prefix-sid
Forwarding Mechanism
In Figure 2 above, supposed that the MRT-Red path is S-N1-N2-N3,
which is used to protect the default primary nexthop F to destination
D. Packets could be pushed to the SR LSP destinated to N3 with label
computed by MT-red node-sid 31 when the primary nexthop F is failed.
In MT-red topology there is an LSP build from ingress S to egress N3.
2.2.1. Forwarding SR Label Unicast Traffic over MRT Paths
When a PLR receives an SR label packet that matches a LIB entry
corresponding to a Node-flag prefix inside the MRT Island, and needs
to be forwarded on the MRT-Red (for example), it does a label swap
operation, replacing the incoming SR label for the FEC with the MRT-
Red SR label for that FEC received from the next-hop router in the
MRT-Red computed by the PLR. MRT transit router will determine the
next hop for the MRT-Red forwarding topology for that FEC, swap the
incoming MRT SR label with the outgoing MRT SR label learned from the
MRT-Red next-hop router, and forward the packet.
When a PLR receives an SR label packet that matches a LIB entry
corresponding to a prefix without Node-flag inside the MRT Island, or
a prefix outside the MRT Island, and needs to be forwarded on the
MRT-Red (for example) path to a tunnel endpoint inside the MRT
Island, it first does a label swap operation, replacing the incoming
SR label assigned by the PLR for the FEC with the SR label assigned
by the tunnel endpoint for that FEC, then pushes the MRT-Red SR label
to the tunnel endpoint. The packet will forward to the tunnel
endpoint (also MRT egress), then leave the MRT path to the shortest
path to the destination.
2.2.2. Forwarding IP Unicast Traffic over MRT Paths
When a PLR receives an IP packet that matches an FTN entry
corresponding to a Node-flag prefix inside the MRT Island, and needs
to be forwarded on the MRT-Red (for example), it does a label push
operation, pushing the MRT-Red SR label for that FEC received from
the next-hop router in the MRT-Red computed by the PLR. MRT transit
Peng & Chen Expires March 2, 2017 [Page 8]
Internet-Draft MRT using SR August 2016
router will determine the next hop for the MRT-Red forwarding
topology for that FEC, swap the incoming MRT SR label with the
outgoing MRT SR label learned from the MRT-Red next-hop router, and
forward the packet.
When a PLR receives an IP label packet that matches an FTN entry
corresponding to a prefix without Node-flag inside the MRT Island, or
a prefix outside the MRT Island, and needs to be forwarded on the
MRT-Red (for example) path to a tunnel endpoint inside the MRT
Island, it first pushes the SR label assigned by the tunnel endpoint
for that FEC, then pushes the MRT-Red SR label to the tunnel
endpoint. The packet will forward to the tunnel endpoint (also MRT
egress), then leave the MRT path to the shortest path to the
destination.
2.2.3. Inter-area Forwarding Behavior
This option always terminates the SR-LSP corresponding to an MRT path
at the MRT egress, the packets will leave the MRT path and continue
to be forwarded according to the default topology-scoped SR label or
IP header. Although ABR will compute the MRT specific SR LIB for an
MRT specific prefix-sid corresponding to a destination prefix with
Node-flag inside the MRT Island that the ABR belongs to, the MRT
specific prefix-sid will never leak to another area. It is
impossible for the ABR to receive packets, from one area, containing
an MRT specific SR label to the destination prefix which belongs to
another area. Other considerations see "section 3. interoperation".
2.2.4. Prefixes Multiply Attached to the MRT Island
This option will use tunnel endpoint selection approach to protection
for both multihomed prefix (outside the area) and destinations
outside the MRT Island (but inside the area). The forwarding
behavior for these prefixes and ones without Node-flag that inside
the MRT Island are totally same.
2.2.5. FIB examples
A node S in the MRT Island will maintain the following FTN entry for
a destination Node-flag prefix inside the MRT Island: (suppose that
the primary nexthop is F, and the MRT-red path is N1-N2-N3 that is
used to protect the primary nexthop.)
example 1
KEY: MT-ID 0, prefix
Primary NHLFE: F, SRGB_F[default-prefix-sid]
Backup NHLFE: N1, SRGB_N1[red-prefix-sid]
Peng & Chen Expires March 2, 2017 [Page 9]
Internet-Draft MRT using SR August 2016
Also, a LIB entry for FEC (MT-ID 0, prefix) is as the following:
example 2
KEY: SRGB_S[default-prefix-sid]
Primary NHLFE: F, SRGB_F[default-prefix-sid]
Backup NHLFE: N1, SRGB_N1[red-prefix-sid]
Nodes along the above MRT-red path will maintain the red SR LIB
entry. For example, a LIB entry for FEC (MT-red, prefix) in N1 node
is as the following:
example 3
KEY: SRGB_N1[red-prefix-sid]
NHLFE: N2, SRGB_N2[red-prefix-sid]
Node S can also maintain the following FTN entry for a destination
prefix without Node-flag inside the MRT Island or a destination
prefix outside the MRT Island: (suppose that the primary nexthop is
F, and the MRT-red path is N1-N2-N3 that is used to protect the
primary nexthop.)
example 4
KEY: MT-ID 0, prefix
Primary NHLFE: F, SRGB_F[default-prefix-sid]
Backup NHLFE: N1, SRGB_N1[red-N3-sid] ;outermost label
SRGB_N3[default-prefix-sid]
Also, a LIB entry for FEC (MT-ID 0, prefix) is as the following:
example 5
KEY: SRGB_S[default-prefix-sid]
Primary NHLFE: F, SRGB_F[default-prefix-sid]
Backup NHLFE: N1, SRGB_N1[red-N3-sid] ;outermost label
SRGB_N3[default-prefix-sid]
2.3. Option 3: MRT SR-LSP Tunneling with multi-SRGB Option
This Option will allocate a different FEC-label binding for each of
the three topology-scoped FECs, i.e. default-FEC, red-FEC, blue-FEC,
originated by routers inside the MRT Island. For example, When a
packet is received with an SR label corresponding to red-FEC, an MRT
transit router will determine the next hop for the MRT-Red forwarding
topology for that FEC, swap the incoming SR label with the outgoing
Peng & Chen Expires March 2, 2017 [Page 10]
Internet-Draft MRT using SR August 2016
SR label corresponding to the MRT-Red next-hop router, and forward
the packet.
The above FEC-label binding is caculated by prefix-sid for the
default topology-scoped prefix depending on each topology-scoped
SRGBs. Each router inside the MRT Island supporting this option will
assign three SRGBs, i.e. default-SRGB, red-SRGB, blue-SRGB. In fact,
We only need caculate MRT SR labels for Node-flag prefixes for each
router inside the MRT Island. Other prefixes inside the MRT Island
and all prefixes outside the MRT Island could also caculate the MRT
SR labels depending on the MRT topology-scoped SRGBs besides the
default SR label depending on the default topology-scoped SRGB, but
it is not necessary for this option. Packets to the later two class
prefixes could be tunneled in the SR-LSP to the tunnel endpoint which
is inside the MRT Island.
The details of advertising SRGB per multi-topology will be described
in the related IGP extension document. The MRT specific SRGB MUST
only be advertised intra the area which the MRT Island belongs to.
Note that we can support tunneling traffic along an MRT to a tunnel
endpoint that is not the destination of the traffic.
____
[F]---{____}................[D]
| .
| .
| . for node N3:
[S]---[N1]---[N2]---[N3]...... MT-default SRGB:[100~200]
=======================> MT-red SRGB:[201~300]
MRT-Red path MT-blue SRGB:[301~400]
Figure 3: MRT SR-LSP Tunneling with multi-SRGB
Forwarding Mechanism
In Figure 3 above, supposed that the MRT-Red path is S-N1-N2-N3,
which is used to protect the default primary nexthop F to destination
D. Packets could be pushed to the SR LSP destinated to N3 with label
computed by MT-red SRGB when the primary nexthop F is failed. In MT-
red topology there is an LSP build from ingress S to egress N3.
2.3.1. Forwarding SR Label Unicast Traffic over MRT Paths
Same as section 2.2.1.
Peng & Chen Expires March 2, 2017 [Page 11]
Internet-Draft MRT using SR August 2016
2.3.2. Forwarding IP Unicast Traffic over MRT Paths
Same as section 2.2.2.
2.3.3. Inter-area Forwarding Behavior
This option always terminates the SR-LSP corresponding to an MRT path
at the MRT egress, the packets will leave the MRT path and continue
to be forwarded according to the default topology-scoped SR label or
IP header. Suppose that area1 connects area2 by an ABR, MRT Island 1
is created inside area1 and MRT Island 2 inside area2. Although the
ABR will compute the MRT specific SR LIB, according to specific MRT
SRGB, for a destination prefix with Node-flag inside the MRT Island 2
that the ABR belongs to, a PLR also supporting this option inside the
MRT Island 1 will never compute the MRT specific SR LIB for this
prefix. It is impossible for the ABR to receive packets, from one
area, containing an MRT specific SR label to the destination prefix
which belongs to another area, if both MRT Islands support the same
option. Other considerations see "section 3. interoperation".
2.3.4. Prefixes Multiply Attached to the MRT Island
This option will use tunnel endpoint selection approach to protection
for both multihomed prefix (outside the area) and destinations
outside the MRT Island (but inside the area). The forwarding
behavior for these prefixes and ones without Node-flag that inside
the MRT Island are totally same.
2.3.5. FIB examples
A node S in the MRT Island will maintain the following FTN entry for
a destination Node-flag prefix inside the MRT Island: (suppose that
the primary nexthop is F, and the MRT-red path is N1-N2-N3 that is
used to protect the primary nexthop.)
example 1
KEY: MT-ID 0, prefix
Primary NHLFE: F, default_SRGB_F[prefix-sid]
Backup NHLFE: N1, red_SRGB_N1[prefix-sid]
Also, a LIB entry for FEC (MT-ID 0, prefix) is as the following:
example 2
KEY: default_SRGB_S[prefix-sid]
Primary NHLFE: F, default_SRGB_F[prefix-sid]
Backup NHLFE: N1, red_SRGB_N1[prefix-sid]
Peng & Chen Expires March 2, 2017 [Page 12]
Internet-Draft MRT using SR August 2016
Nodes along the above MRT-red path will maintain the red SR LIB
entry. For example, a LIB entry for FEC (MT-red, prefix) in N1 node
is as the following:
example 3
KEY: red_SRGB_N1[prefix-sid]
NHLFE: N2, red_SRGB_N2[prefix-sid]
Node S can also maintain the following FTN entry for a destination
prefix without Node-flag inside the MRT Island or a destination
prefix outside the MRT Island: (suppose that the primary nexthop is
F, and the MRT-red path is N1-N2-N3 that is used to protect the
primary nexthop.)
example 4
KEY: MT-ID 0, prefix
Primary NHLFE: F, default_SRGB_F[prefix-sid]
Backup NHLFE: N1, red_SRGB_N1[N3-sid] ;outermost label
default_SRGB_N3[prefix-sid]
Also, a LIB entry for FEC (MT-ID 0, prefix) is as the following:
example 5
KEY: default_SRGB_S[prefix-sid]
Primary NHLFE: F, default_SRGB_F[prefix-sid]
Backup NHLFE: N1, red_SRGB_N1[N3-sid] ;outermost label
default_SRGB_N3[prefix-sid]
2.4. Option 4: MRT SR-LSP Non-tunneling with multi-SRGB Option
This Option will allocate a different FEC-label binding for each of
the three topology-scoped FECs, i.e. default-FEC, red-FEC, blue-FEC,
originated by any routers in the SR domain. For example, When a
packet is received with an SR label corresponding to red-FEC, an MRT
transit router will determine the next hop for the MRT-Red forwarding
topology for that FEC, swap the incoming SR label with the outgoing
SR label corresponding to the MRT-Red next-hop router, and forward
the packet.
The above FEC-label binding is caculated by prefix-sid for the
default topology-scoped prefix depending on each topology-scoped
SRGBs. Each router inside the MRT Island supporting this option will
assign three SRGBs, i.e. default-SRGB, red-SRGB, blue-SRGB.
Difference between this option and the option described in section
Peng & Chen Expires March 2, 2017 [Page 13]
Internet-Draft MRT using SR August 2016
2.3 is that we create MRT SR-LSP for every destination prefix, not
only for Node-flag prefix inside the MRT Island.
Note that we only need to allocate and advertise default topology-
scoped prefix-sid in the SR domain, there are no red and blue
topology-scoped prefix-sids. But we need to advertise topology-
scoped SRGBs, i.e. default-SRGB, red-SRGB, blue-SRGB, respectively
intra the area.
The details of advertising SRGB per multi-topology will be described
in the related IGP extension document. The MRT specific SRGB MUST
only be advertised intra the area which the MRT Island belongs to.
____
[F]---{____}................[D]
| .
| .
| . for node N3:
[S]---[N1]---[N2]---[N3]...... MT-default SRGB:[100~200]
=======================> MT-red SRGB:[201~300]
MRT-Red path MT-blue SRGB:[301~400]
Figure 4: MRT SR-LSP Tunneling with multi-SRGB
Forwarding Mechanism
In Figure 4 above, supposed that the MRT-Red path is S-N1-N2-N3,
which is used to protect the default primary nexthop F to destination
D. Packets could be pushed to the SR LSP destinated to D with label
computed by MT-red SRGB when the primary nexthop F is failed. In MT-
red topology there is an LSP build from ingress S to egress D, at
node N3, the incoming label is computed by its own MT-red SRGB, the
outgoing label is computed by next-hop's MT-default SRGB.
2.4.1. Forwarding SR Label Unicast Traffic over MRT Paths
When a PLR receives an SR label packet that needs to be forwarded on
the MRT-Red (for example), it does a label swap operation, replacing
the incoming SR label for the FEC with the MRT-Red SR label for that
FEC received from the next-hop router in the MRT-Red computed by the
PLR. MRT transit router will determine the next hop for the MRT-Red
forwarding topology for that FEC, swap the incoming MRT SR label with
the outgoing MRT SR label learned from the MRT-Red next-hop router,
and forward the packet.
Peng & Chen Expires March 2, 2017 [Page 14]
Internet-Draft MRT using SR August 2016
2.4.2. Forwarding IP Unicast Traffic over MRT Paths
When a PLR receives an IP packet that needs to be forwarded on the
MRT-Red (for example), it does a label push operation, pushing the
MRT-Red SR label for the FEC received from the next-hop router in the
MRT-Red computed by the PLR. MRT transit router will determine the
next hop for the MRT-Red forwarding topology for that FEC, swap the
incoming MRT SR label with the outgoing MRT SR label learned from the
MRT-Red next-hop router, and forward the packet.
2.4.3. Inter-area Forwarding Behavior
For OSPF, the ABR is responsible for advertising the proper prefix-
sid to each neighbor. Assume that an ABR has allocated a default
topology-scoped prefix-sid for a particular destination. To those
routers in the same area as the best route to the destination, the
ABR advertises the prefix-sid as normal. However, to routers in
other areas, the ABR advertises the prefix-sid with Rainbow-Flag.
Prefix-sid with Rainbow-Flag causes the receiving routers to use
default-SRGB of the next-hop to caculate SR out-label for the MRT-
Blue MT-ID and for the MRT-Red MT-ID. The details of advertising
prefix-sid with Rainbow-Flag will be described in another document.
The ABR installs all next hops for the best area: primary next hops
for default-SRGB, MRT-Blue next hops for blue-SRGB, and MRT-Red next
hops for red-SRGB. Because the ABR advertised prefix-sid with
Rainbow-Flag to neighbors not in the best area, packets from those
neighbors will arrive at the ABR with a label caculated by default-
SRGB of the ABR and will be forwarded into the best area along the
default topology. Other considerations see "section 3.
interoperation".
The same essential behavior also applies to IS-IS if one substitutes
IS-IS level for OSPF area. More details see "Appendix A" of
[RFC7812].
2.4.4. Prefixes Multiply Attached to the MRT Island
This option will use named proxy-node approach to protection for both
multihomed prefix (outside the area) and destinations outside the MRT
Island (but inside the area).
According to [RFC7812], a proxy-node attachment router has a special
forwarding role. A proxy-node attachment router is similar with
other routers in the MRT Island to compute and install three ILM
entries for each (MT-ID 0, perfix) outside the MRT Island based on
three different FEC-label bindings. In particular, it will compute
SR out-label, for MRT SR ILM, based on the default-SRGB of the LFIN
Peng & Chen Expires March 2, 2017 [Page 15]
Internet-Draft MRT using SR August 2016
whose cost was used in the selection or the remote endpoint of the
interface that caused the router to advertise the prefix. However,
it will always compute SR out-label based on the default-SRGB of the
shortest path nexthop for default SR ILM.
Note that if the proxy-node attachment router is an ABR, and it also
belongs to another MRT Island supporting this option in the area
which the destination prefix belongs to. It will compute SR out-
label, for MRT SR ILM, based on the red-SRGB or blue-SRGB of the MRT-
red or MRT blue nexthops, in despite of whether or not advertising
the destination prefix to another area. In this case, we can refer
to section "2.4.3. Inter-area Forwarding Behavior".
When a packet is received destined to (MRT-Red, prefix) or (MRT-Blue,
prefix), if the proxy-node attachment router is an IBR, it MUST swap
to the shortest path forwarding topology (e.g., swap to the label
caculated by default-SRGB of the IN) and forward the packet to the IN
whose cost was used in the selection. If the proxy-node attachment
router is not an IBR, then the packet MUST be removed from the MRT
forwarding topology and sent along the interface(s) that caused the
router to advertise the prefix; this interface might be out of the
area/level/AS.
2.4.5. FIB examples
A node S in the MRT Island will maintain the following FTN entry for
a destination prefix: (suppose that the primary nexthop is F, and the
MRT-red path is N1-N2-N3 that is used to protect the primary
nexthop.)
example 1
KEY: MT-ID 0, prefix
Primary NHLFE: F, default_SRGB_F[prefix-sid]
Backup NHLFE: N1, red_SRGB_N1[prefix-sid]
Also, a LIB entry for FEC (MT-ID 0, prefix) is as the following:
example 2
KEY: default_SRGB_S[prefix-sid]
Primary NHLFE: F, default_SRGB_F[prefix-sid]
Backup NHLFE: N1, red_SRGB_N1[prefix-sid]
Nodes along the above MRT-red path will maintain the red SR LIB
entry. For example, a LIB entry for FEC (MT-red, prefix) in N1 node
is as the following:
Peng & Chen Expires March 2, 2017 [Page 16]
Internet-Draft MRT using SR August 2016
example 3
KEY: red_SRGB_N1[prefix-sid]
NHLFE: N2, red_SRGB_N2[prefix-sid]
In particular, if S is a proxy-node attachment router, and suppose
that the LFIN whose cost was used in the selection or the remote
endpoint of the interface that caused S to advertise the prefix is M,
the FTN entry maintained by S would be like the following:
example 4
KEY: MT-ID 0, prefix
Primary NHLFE: F, default_SRGB_F[prefix-sid]
Backup NHLFE: M, default_SRGB_M[prefix-sid]
Also, the LIB entry for FEC (MT-ID 0, prefix) maintained by S would
be like the following:
example 5
KEY: default_SRGB_S[prefix-sid]
Primary NHLFE: F, default_SRGB_F[prefix-sid]
Backup NHLFE: M, default_SRGB_M[prefix-sid]
Also, the LIB entry for FEC (MT-red, prefix) maintained by S would be
like the following:
example 6
KEY: red_SRGB_S[prefix-sid]
NHLFE: M, default_SRGB_M[prefix-sid]
As notice in section 2.4.4, when S is a proxy-node attachment router
and an ABR, and it also belongs to another MRT Island supporting this
option in the area which the destination prefix belongs to. S will
maintain FTN/LIB entries just like example 1,2,3, in despite of
whether or not advertising the destination prefix to another area.
When S has received the the prefix-sid advertisement corresponding to
(MT-ID 0, prefix) with a Rainbow-Flag from its MRT-red nexthop (an
ABR), it will maintain the FTN entry as the following:
example 7
KEY: MT-ID 0, prefix
Primary NHLFE: F, default_SRGB_F[prefix-sid]
Backup NHLFE: ABR, default_SRGB_ABR[prefix-sid]
Peng & Chen Expires March 2, 2017 [Page 17]
Internet-Draft MRT using SR August 2016
Also, a LIB entry for FEC (MT-ID 0, prefix) is as the following:
example 8
KEY: default_SRGB_S[prefix-sid]
Primary NHLFE: F, default_SRGB_F[prefix-sid]
Backup NHLFE: ABR, default_SRGB_ABR[prefix-sid]
Also, a LIB entry for FEC (MT-red, prefix) is as the following:
example 9
KEY: red_SRGB_S[prefix-sid]
NHLFE: ABR, default_SRGB_ABR[prefix-sid]
2.5. Option 5: MRT SR-LSP Non-tunneling with multi-prefix-sid Option
This Option will allocate a different FEC-label binding for each of
the three topology-scoped FECs, i.e. default-FEC, red-FEC, blue-FEC,
originated by any routers in the SR domain. For example, When a
packet is received with an red SR label corresponding to red-FEC, an
MRT transit router will determine the next hop for the MRT-Red
forwarding topology for that FEC, swap the incoming red SR label with
the outgoing red SR label corresponding to the MRT-Red next-hop
router, and forward the packet.
Difference between this option and the option described in section
2.2 is that we create MRT SR-LSP for every destination prefix, not
only for prefix with Node-flag inside the MRT Island. However, this
option can not address the destination prefixes which are outside the
MRT Island, especially outside the area/level, because routers outsid
the MRT Island have no idea about the MRT Island. It is impossible
for these routers to allocate the red or blue topology-scoped prefix-
sids, besides the default topology-scoped prefix-sid. Anorhter
reason is that an MRT specific prefix-sid can never leak between
areas.
This option is waiting for future study.
3. Interoperation
It is possible that a set of routers inside an area support two or
more options at the same time. It is also possible that one set of
routers, supporting one option, interconnect another set of routers
that support another option, both sets could be in the same area or
not. More detailed descriptions of these sceneria are given below.
Peng & Chen Expires March 2, 2017 [Page 18]
Internet-Draft MRT using SR August 2016
3.1. Multiple Profiles Coexistence
[S]---[F]---............[D]
| |
....|.......................|....
. [N1]---[N2]---[N3] .
. | | | .
. [N4]---[N5]---[N6] .
. | | | .
. [N7]---[N8]---[N9] .
. | | | .
. [N10]---[N11]---[N12] .
.................................
Figure 5: Multiple Profiles Coexistence
In Figure 5 above, the shortest path nexthop from S to D is F. S, D,
N1, N2, and N3 support the above all profiles. N4, N5, and N6
support profile with "MRT SR-LSP Tunneling with multi-prefix-sid
Option" forwarding mechanism only. N7, N8, and N9 support profile
with "MRT SR-LSP Tunneling with multi-SRGB Option" forwarding
mechanism only. N10, N11, and N12 support profile with "MRT SR-LSP
Non-tunneling with multi-SRGB Option" forwarding mechanism only. So,
there would be four MRT Islands in Figure 1. For each MRT Island,
suppose that the MRT-red nexthop from S to D is same as the shortest
path nexthop, i.e., F, the MRT-blue nexthop from S to D is Ni.
Specifically, the MRT-blue nexthop is N1 for MRT Island with "MRT SR-
tunnel Option" forwarding mechanism, the MRT-blue nexthop is ECMP
{N1,N4} for MRT Island with "MRT SR-LSP Tunneling with multi-prefix-
sid Option" forwarding mechanism, the MRT-blue nexthop is ECMP
{N1,N7} for MRT Island with "MRT SR-LSP Tunneling with multi-SRGB
Option" forwarding mechanism, the MRT-blue nexthop is ECMP {N1,N10}
for MRT Island with "MRT SR-LSP Non-tunneling with multi-SRGB Option"
forwarding mechanism.
From the perspective of node S, the FTN entry to D corresponding to
each MRT Island is different with each other, e.g., some have single
MRT-blue nexthop, some have ECMP MRT-blue nexthops. These FTN
entries MUST be distinguished by different MT-IDs.
From the perspective of node N1 (also other transit node), the ILM
entry to D corresponding to each MRT Island is also different with
each other. These ILM entries MUST be distinguished by different SR
in-label. Take a look at profile with "MRT SR-LSP Tunneling with
multi-SRGB Option" forwarding mechanism and profile with "MRT SR-LSP
Non-tunneling with multi-SRGB Option" forwarding mechanism, they both
use MRT specific SRGB to caculate MRT specific SR label for a default
topology-scoped prefix-sid. The MRT specific SRGB MUST be different
Peng & Chen Expires March 2, 2017 [Page 19]
Internet-Draft MRT using SR August 2016
between these two profiles. For the same reason, the MRT specific
prefix-sid MUST be different between the profile with "MRT SR-LSP
Tunneling with multi-prefix-sid Option" forwarding mechanism and the
profile with "MRT SR-LSP Non-tunneling with multi-prefix-sid Option"
forwarding mechanism.
3.2. Multiple Profiles Interworking
[S]-------------[A] [P]-------------[D]
| \ / |
| \ / |
| MRT Island 1 [X] MRT Island 2 |
| / \ |
| / \ |
[B] -------------[C] [Q] ------------[R]
Figure 6: Multiple Profiles Interworking
In Figure 6 above, MRT Island 1 contains S, A, B, C, X, MRT Island 2
contains X, P, Q, R, D. If MRT Island 1 is supporting the profile
with "MRT SR-tunnel Option" forwarding mechanism, MRT Island 2 could
be any other profiles. The packets to from S to destination D will
terminate the SR-tunnel corresponding to an MRT path at node X, then
return to shortest path to D.
If MRT Island 1 is supporting the profile with "MRT SR-LSP Tunneling
with multi-prefix-sid Option" or "MRT SR-LSP Tunneling with multi-
SRGB Option" forwarding mechanism, MRT Island 2 could also be any
other profiles. The packets to from S to destination D will
terminate the MRT specific SR-LSP corresponding to an MRT path at
node X, then return to shortest path to D. Note that each node in
MRT Island 1 never compute MRT specific SR LIB for destination D
which is outside MRT Island 1, although X in MRT Island 2 maybe
compute it. X will never receive a packet, from MRT Island 1, which
includes an MRT specific SR label directly to destination D.
If MRT Island 1 is supporting the profile with "MRT SR-LSP Non-
tunneling with multi-SRGB Option" forwarding mechanism, each node in
MRT Island 1 will compute MRT specific SR LIB for destination D
directly. Especially, in node X, i.e., the proxy-node attachment
router, the MRT specific SR LIB computed for destination D will
forward packets to default topology. Hence, if MRT Island 2 is also
supporting the profile with "MRT SR-LSP Non-tunneling with multi-SRGB
Option" forwarding mechanism, X will also compute MRT specific SR LIB
for destination D which will forward packets along MRT path,
overwrite the above default topology forwarding information. In this
case, X MUST advertise prefix-sid with Rainbow flag corresponding to
(MT-ID 0, prefix-D) to neighbors in MRT Island 1, in order to avoid
Peng & Chen Expires March 2, 2017 [Page 20]
Internet-Draft MRT using SR August 2016
receiving packets including an MRT specific SR label for destination
D. If MRT Island 2 is supporting "MRT SR-LSP Tunneling with multi-
SRGB Option" forwarding mechanism, X will also compute MRT specific
SR LIB for destination D which will forward packets along MRT path,
but in-label is different because of different MRT specific SRGB.
4. Support protecting segment list
As RFC7811 said, in some cases the PLR S can not find MRT alternates
to destination D for local repair to protect the primary nexthop F.
For example, if F is D, only link protection is possible. And if
both MRT-Red and MRT-Blue use the primary next hop, then the primary
next hop must be a cut-link, so either MRT could be pruned to avoid
the failed primary next-hop interface.
Thus, if S received a packet which contains a segment list only
including node segment F, we just comply with the MRT computing
result for destination F, try best to forward packet along the MRT
path which has not use the primary next hop. But if S received a
packet which contains a segment list not only including node segment
F as the first segment, but also other subsequent segments, S can
temporarily change the destination to another node D' rather than F,
and send packet along the MRT path to destination D'. A simple
condition which decided to set another destination D' is that the
original destination is a direct neighbor of S. We can easily check
this condition during computing SPF routes, and set the related flag
in the corresponding FTN/ILM entries. In dataplane, if the top label
of the label stack of the packet S received matches an SR-ILM entry
which has set the above flag to indicate the FEC is from a direct
nighbor and the primary next hop of the ILM entry is failed, in
despite of alternate next hops (e.g, MRT alternates) existing, S MAY
check if the next label of the label stack is also an SR-based label,
if so, deduce the next node-segment and directly forward the packet
to the next node-segment according to the FTN/ILM entry corresponding
to the next node-segment after twice label POP operations on the
original label stack. However, S can also simply choose to forward
packets along the alternate next hops of ILM entry corresponding to
the first segment to avoid the aboved complexities. It is a local
choice.
Similarly, if the top label of the label stack of the packet S
received matches an SR-ILM entry corresponding to a local adjacency
segment, S MAY also do the above check and process if the adjacency
is failed, and can also simply choose to forward packets along the
backup adjacencies. It is also a local choice.
It's a bit complicated for the dataplane to deduce the next node-
segment based on the label stack of the received packet. First, It
Peng & Chen Expires March 2, 2017 [Page 21]
Internet-Draft MRT using SR August 2016
can deduce the first node-segment (i.e., F) based on the SR-ILM entry
matched by the top label, the node information can get from the
prefix FEC (F) or from the remote node-id of the adjacency FEC
(S->F). Then, we can get the SRGB of the first node-segment (i.e.,
SRGB_F), and check if the next label is in SRGB_F, if so, we know
that the next segment is a prefix segment and deduce the prefix-sid,
which is then used to compute a label based on SRGB_S to match the
ILM entry correspond to the next node-segment. If the next label is
not in SRGB_F, S can check all F's local adjacencies to see if there
is a label equal to the next label, if so, we know that the next
segment is an adjacency segment and deduce the next node-segment from
the remote node-id of the matched adjacency, and an FTN entry could
be match by the next node-segment. Note that S can maintain ILM
entries for F's all local adjacencies for the above purpose, although
these ILM entries are not used to forward packets directly. The FTN
or ILM entry of the next segment could be used to directly forward
the packet to the next node-segment after twice label POP operations
on the original label stack. If the next label is neither in SRGB_F
nor matching F's any local adjacencies, it must be a non-SR label, in
this case, packets must be simply forwarded along the alternate next
hops of ILM entry corresponding to the first segment, if there are no
alternate next hops, packets would be dropped.
All possible cases are systematically described in the following
sections.
4.1. Received segment list is {segment F or S->F, vpn label} or
{segment F or S->F}
We can determine that only one SR related label existed in label
stack, and the segment is a direct neighbor along the shortest path.
In this case, only link protection is possible.
For MRT forwarding mechanism option 1, the MRT-FRR behavior is:
POP segment F or S->F
set D' = F, goto FTN entry of D', it will:
PUSH SRGB_E[SID_F] ;E is MRT Egress
PUSH the label stack of the SR-tunnel(from S to MRT Egress)
For MRT forwarding mechanism option 2, the MRT-FRR behavior is:
POP segment F or S->F
set D' = F, goto FTN entry of D', it will:
when F is inside MRT Island:
PUSH SRGB_N[mrt_SID_F] ;N is MRT Nexthop
when F is outside MRT Island:
no MRT FRR provided
Peng & Chen Expires March 2, 2017 [Page 22]
Internet-Draft MRT using SR August 2016
For MRT forwarding mechanism option 3, the MRT-FRR behavior is:
POP segment F or S->F
set D' = F, goto FTN entry of D', it will:
when F is inside MRT Island:
PUSH mrt_SRGB_N[SID_F]
when F is outside MRT Island:
no MRT FRR provided
For MRT forwarding mechanism option 4, the MRT-FRR behavior is:
POP segment F or S->F
set D' = F, goto FTN entry of D', it will:
when S is not the proxy-node attachment router:
no_rainbow:PUSH mrt_SRGB_N[SID_F]
rainbow:PUSH default_SRGB_N[SID_F]
when S is the proxy-node attachment router:
no MRT FRR provided
4.2. Received segment list is {segment F or S->F, segment D1 or F->D1,
segment D2, ..., segment Dn, vpn label}
The first segment is a direct neighbor along the shortest path,
followed by other segments.
For MRT forwarding mechanism option 1, the MRT-FRR behavior is:
POP segment F or S->F
POP segment D1 or F->D1
change D'from F to D1, goto FTN or ILM entry of D', it will:
when primary next hop for destination D' is valid:
PUSH SRGB_H[SID_D1] ;H is primary next hop
when primary next hop for destination D' is not valid::
PUSH SRGB_E[SID_D1], ;E is MRT Egress
PUSH label stack of the SR-tunnel(from S to MRT Egress)
For MRT forwarding mechanism option 2, the MRT-FRR behavior is:
Peng & Chen Expires March 2, 2017 [Page 23]
Internet-Draft MRT using SR August 2016
POP segment F or S->F
POP segment D1 or F->D1
change D'from F to D1, goto FTN or ILM entry of D', it will:
when primary next hop for destination D' is valid:
PUSH SRGB_H[default_SID_D1]
when primary next hop for destination D' is not valid:
when D1 is inside MRT Island:
PUSH SRGB_N[mrt_SID_D1] ;N is MRT Nexthop
when D1 is outside MRT Island:
PUSH SRGB_E[default_SID_D1]
PUSH SRGB_N[mrt_SID_E]
For MRT forwarding mechanism option 3, the MRT-FRR behavior is:
POP segment F or S->F
POP segment D1 or F->D1
change D'from F to D1, goto FTN or ILM entry of D', it will:
when primary next hop for destination D' is valid:
PUSH default_SRGB_H[SID_D1]
when primary next hop for destination D' is not valid:
when D1 is inside MRT Island:
PUSH mrt_SRGB_N[SID_D1]
when D1 is outside MRT Island:
PUSH default_SRGB_E[SID_D1]
PUSH mrt_SRGB_N[SID_E]
For MRT forwarding mechanism option 4, the MRT-FRR behavior is:
POP segment F or S->F
POP segment D1 or F->D1
change D'from F to D1, goto FTN or ILM entry of D', it will:
when primary next hop for destination D' is valid:
PUSH default_SRGB_H[SID_D1]
when primary next hop for destination D' is not valid:
when S is not the proxy-node attachment router:
no_rainbow:PUSH mrt_SRGB_N[SID_D1]
rainbow:PUSH default_SRGB_N[SID_D1]
when S is the proxy-node attachment router:
PUSH default_SRGB_M[SID_D1] ;M is nexthop outside Island
4.3. Received segment list is {segment D1, segment D2, ..., segment Dn,
vpn label}
The first segment is not a direct neighbor along the shortest path,
followed by other segments.
For MRT forwarding mechanism option 1, the MRT-FRR behavior is:
Peng & Chen Expires March 2, 2017 [Page 24]
Internet-Draft MRT using SR August 2016
set D' = D1, goto ILM entry of D', it will:
swap segment D1, i.e., SRGB_S[SID_D1] with SRGB_E[SID_D1]
;E is MRT Egress
PUSH label stack of the SR-tunnel(from S to MRT Egress)
For MRT forwarding mechanism option 2, the MRT-FRR behavior is:
set D' = D1, goto ILM entry of D', it will:
when D1 is inside MRT Island:
swap segment D1, i.e., SRGB_S[default_SID_D1] with
SRGB_N[mrt_SID_D1] ;N is MRT Nexthop
when D1 is outside MRT Island:
swap segment D1, i.e., SRGB_S[default_SID_D1] with
SRGB_E[default_SID_D1]
PUSH SRGB_N[mrt_SID_E]
For MRT forwarding mechanism option 3, the MRT-FRR behavior is:
set D' = D1, goto ILM entry of D', it will:
when D1 is inside MRT Island:
swap segment D1, i.e., default_SRGB_S[SID_D1] with
mrt_SRGB_N[SID_D1]
when D1 is outside MRT Island:
swap segment D1, i.e., default_SRGB_S[SID_D1] with
default_SRGB_E[SID_D1]
PUSH mrt_SRGB_N[SID_E]
For MRT forwarding mechanism option 4, the MRT-FRR behavior is:
set D' = D1, goto ILM entry of D', it will:
when S is not the proxy-node attachment router:
no_rainbow:swap segment D1, i.e., default_SRGB_S[SID_D1]
with mrt_SRGB_N[SID_D1]
rainbow:swap segment D1, i.e., default_SRGB_S[SID_D1] with
default_SRGB_N[SID_D1]
when S is the proxy-node attachment router:
swap segment D1, i.e., default_SRGB_S[SID_D1] with
default_SRGB_M[SID_D1] ;M is nexthop outside Island
5. Security Considerations
TBD.
6. IANA Considerations
TBD
Peng & Chen Expires March 2, 2017 [Page 25]
Internet-Draft MRT using SR August 2016
7. References
7.1. Normative 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-07 (work in progress), June 2016.
[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-09 (work in progress), July 2016.
[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-09 (work in progress), July 2016.
[I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Shakir, R.,
jefftant@gmail.com, j., and E. Crabbe, "Segment Routing
with MPLS data plane", draft-ietf-spring-segment-routing-
mpls-05 (work in progress), July 2016.
[RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute
Using Maximally Redundant Trees (MRT-FRR)", RFC 7811,
DOI 10.17487/RFC7811, June 2016,
<http://www.rfc-editor.org/info/rfc7811>.
[RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for
IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-
FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016,
<http://www.rfc-editor.org/info/rfc7812>.
7.2. Informative 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>.
Peng & Chen Expires March 2, 2017 [Page 26]
Internet-Draft MRT using SR August 2016
Authors' Addresses
Shaofu Peng
ZTE Corporation
No.68 Zijinghua Road,Yuhuatai District
Nanjing 210012
China
Email: peng.shaofu@zte.com.cn
Ran Chen
ZTE Corporation
No.50 Software Avenue,Yuhuatai District
Nanjing 210012
China
Email: chen.ran@zte.com.cn
Peng & Chen Expires March 2, 2017 [Page 27]
