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, . [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, . 7.2. Informative References [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . 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]