| Network Working Group | X.X. Xu |
| Internet-Draft | M.C. Chen |
| Intended status: Standards Track | Huawei |
| Expires: June 27, 2014 | December 24, 2013 |
Advertising Global Labels or SIDs Using IS-IS
draft-xu-isis-global-label-sid-adv-00
Segment Routing (SR) is a new MPLS paradigm in which each SR-capable router is required to advertise global MPLS labels or Segment IDs (SID ) for its attached prefixes by using link-state IGPs, e.g., IS-IS. One major challenge associated with such global MPLS label or SID advertisement mechanism is how to avoid a given global MPLS label or SID from being allocated by different routers to different prefixes. Although such global label or SID allocation collision problem can be addressed through manual allocation , it is error-prone and nonautomatic therefore may not be suitable in large-scale SR network environments. This document proposes an alternative approach for allocating and advertising global MPLS labels or SIDs via IS-IS so as to eliminate the potential risk of label allocation collision.
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 June 27, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Segment Routing (SR) [I-D.filsfils-rtgwg-segment-routing] is a new MPLS paradigm in which each SR-capable router is required to advertise global MPLS labels or Segment IDs (SID) for its attached prefixes by using link-state IGPs, e.g., IS-IS[I-D.previdi-isis-segment-routing-extensions] . One major challenge associated with such global MPLS label or SID advertisement mechanism is how to avoid a given global MPLS label or SID from being allocated by different routers to different prefixes. Although such global label or SID allocation collision problem can be addressed through manual allocation , it is error-prone and nonautomatic therefore may not be suitable in large-scale SR network environments.
This document proposes an alternative approach for allocating and advertising global MPLS labels or SIDs via IS-IS so as to eliminate the potential risk of label allocation collision. The basic idea of this approach is to allow a particular IGP router to allocate global MPLS labels or SIDs for those prefixes attached to each SR-capable router and meanwhile advertise the corresponding label or SID bindings in the IGP domain scope. That particular IGP rouer is therefore refered to as a mapping server. As for how the mapping server know which prefixes need to be allocated with global labels or SIDs, it can be achieved either by configuration on the mapping server or by advertisement from SR-capable routers. In the multi-level scenario where route summarization between levels is enabled, the IP longest-match algorithm SHOULD be used by SR-capable routers when processing label or SID bindings advertised by the mapping server, just as the mechanism defined in [RFC5283] .
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This memo makes use of the terms defined in [I-D.filsfils-rtgwg-segment-routing] and [RFC4971].
A mapping server could uses one or more of the following TLVs to advertise global labels for those prefixes which need to be allocated with global labels.
A Label Binding Sub-TLV (TBD) as shown below is associated with a prefix which is contained in one of the above TLVs:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P| Reserved | MPLS Label (20 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Since the mapping server uses these TLVs for label binding advertisement purpose other than building the normal IP routing table, the Metric field MUST be set to a value larger than MAX_PATH_METRIC (i.e., 0xFE000000) according to the following specification as defined in [RFC5305] "...If a prefix is advertised with a metric larger then MAX_PATH_METRIC (0xFE000000, see paragraph 3.0), this prefix MUST NOT be considered during the normal SPF computation. This allows advertisement of a prefix for purposes other than building the normal IP routing table...". In addition, when propagating those TLVs across levels, the Label Binding Sub-TLVs contained in them MUST be preserved.
A mapping server could uses one or more of the Extended IP Reachability TLVs (i.e., TLV-135, TLV-235, TLV-236 and TLV-237) to advertise SIDs for those prefixes which need to be allocated with SIDs.
A SID Binding Sub-TLV (TBD) as shown below is associated with a prefix which is contained in one of the above TLVs:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Since the mapping server uses these TLVs for label binding advertisement purpose other than building the normal IP routing table, the Metric field MUST be set to a value larger than MAX_PATH_METRIC (i.e., 0xFE000000). In addition, when propagating those TLVs across levels, the SID Binding Sub-TLVs contained in them MUST be preserved.
When advertising IP reachability information by using one of the Extended IP Reachability TLVs (i.e., TLV-135, TLV-235, TLV-236 and TLV-237), SR-capable IS-IS routers SHOULD mark those attached prefixes which need to be allocated with global labels by associating each of these prefixes with a Label Request sub-TLV (type code=TBD) as shown below. In addition, when propagating those TLVs across levels, the Label Request Sub-TLVs contained in them MUST be preserved.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the multi-level scenario where route summarization between levels is required, separate Extended IP Reachability TLVs other than those for IP reachability advertisement purpose SHOULD be used for label binding request purpose. Since these separate TLVs are not used for the purpose of building the normal IP routing table, the Metric field MUST be set to a value larger than MAX_PATH_METRIC (i.e., 0xFE000000). In addition, when propagating those TLVs across levels, the Label Request Sub-TLVs contained in them MUST be preserved.
When advertising IP reachability information by using one of the Extended IP Reachability TLVs (i.e., TLV-135, TLV-235, TLV-236 and TLV-237), SR-capable IS-IS routers SHOULD mark those attached prefixes which need to be allocated with SIDs by associating each of these prefixes with a SID Request sub-TLV (Type Code=TBD and Length=0)
In the multi-level scenario where route summarization between levels is required, separate Extended IP Reachability TLVs other than those for IP reachability advertisement purpose SHOULD be used for SID binding request purpose. Since these separate TLVs are not used for the purpose of building the normal IP routing table, the Metric field MUST be set to a value larger than MAX_PATH_METRIC (i.e., 0xFE000000). In addition, when propagating those TLVs across levels, the SID Request Sub-TLVs contained in them MUST be preserved.
For redundancy purpose, more than one router could be configured as candidates for mapping servers. Each candidate for mapping servers SHOULD advertise its capability of being a mapping servers by using IS-IS Router Capability TLV. The one with the highest priority SHOULD be elected as the primary mapping server which is eligible to allocate and advertise global labels or SIDs for prefixes on behalf of SR-capable routers. The comparison of IS-IS System ID breaks the tie between two or more candidates with the same highest priority. Meanwhile, the one with the second highest priority SHOULD be elected as a backup mapping server. This backup mapping server SHOULD advertise the same label bindings as those advertised by the primary mapping server. In this way, the unnecessary changes to the data plane (i.e., MPLS forwarding table) of SR-capable routers can be avoided in the event of mapping server failover.
Each candidate mapping server SHOULD advertise its capability of being a mapping server and the corresponding priority for mapping server election by attaching a Mapping Server Capability Sub-TLV (type code=TBD) shown as below to an IS-IS Router Capability TLV [RFC4971] with the S flag set (with domain-wide flooding scope).
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Length | Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The authors would like to thank .
TBD.
This document does not introduce any new security considerations.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5305] | Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008. |
| [RFC4971] | Vasseur, JP., Shen, N. and R. Aggarwal, "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, July 2007. |
| [RFC5308] | Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008. |
| [I-D.previdi-isis-segment-routing-extensions] | Previdi, S., Filsfils, C., Bashandy, A., Gredler, H. and S. Litkowski, "IS-IS Extensions for Segment Routing", Internet-Draft draft-previdi-isis-segment-routing-extensions-04, October 2013. |
| [RFC5120] | Przygienda, T., Shen, N. and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008. |
| [RFC5283] | Decraene, B., Le Roux, JL. and I. Minei, "LDP Extension for Inter-Area Label Switched Paths (LSPs)", RFC 5283, July 2008. |
| [I-D.filsfils-rtgwg-segment-routing] | Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Ytti, S., Henderickx, W., Tantsura, J. and E. Crabbe, "Segment Routing Architecture", Internet-Draft draft-filsfils-rtgwg-segment-routing-01, October 2013. |