Network Working Group X. Xu Internet-Draft M. Chen Intended status: Standards Track Huawei Expires: June 28, 2014 December 25, 2013 Advertising Global Labels or SIDs Using IS-IS draft-xu-isis-global-label-sid-adv-00 Abstract 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. 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 June 28, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Xu & Chen Expires June 28, 2014 [Page 1] Internet-Draft December 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Advertising Label Bindings for Prefixes using IS-IS . . . . . 3 4. Advertising SID Bindings for Prefixes using IS-IS . . . . . . 4 5. Requesting Label Bindings for Prefixes using IS-IS . . . . . 5 6. Requesting SID Bindings for Prefixes using IS-IS . . . . . . 5 7. Mapping Server Redundancy . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 11.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction 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 Xu & Chen Expires June 28, 2014 [Page 2] Internet-Draft December 2013 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] . 1.1. Requirements Language 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]. 2. Terminology This memo makes use of the terms defined in [I-D.filsfils-rtgwg-segment-routing] and [RFC4971]. 3. Advertising Label Bindings for Prefixes using IS-IS 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. o TLV-135 (IPv4) [RFC5305] o TLV-235 (MT-IPv4) [RFC5120] o TLV-236 (IPv6) [RFC5308] o TLV-237 (MT-IPv6) [RFC5120] 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD Xu & Chen Expires June 28, 2014 [Page 3] Internet-Draft December 2013 Length: 4 P-Flag: if set, the penultimate hop router MUST perform PHP action on the allocated MPLS label. For a given prefix, the P-Flag in the Label Binding Sub-TLV MUST be set to the same value as that of the P-Flag in the Label Request Sub-TLV if a label request message (See Section 5 of this document) for that prefix is received by the mapping server. MPLS Label: a global label for the prefix which is carried in the TLV containing this sub-TLV. 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. 4. Advertising SID Bindings for Prefixes using IS-IS 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD Length: 4 SID: a SID for the prefix which is carried in the TLV containing this sub-TLV. Xu & Chen Expires June 28, 2014 [Page 4] Internet-Draft December 2013 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. 5. Requesting Label Bindings for Prefixes using IS-IS 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD Length: 4 P-Flag: if set, the penultimate hop router MUST perform PHP action on the required label. 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. 6. Requesting SID Bindings for Prefixes using IS-IS 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 Xu & Chen Expires June 28, 2014 [Page 5] Internet-Draft December 2013 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. 7. Mapping Server Redundancy 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD Length: 1 Priority: the priority for mapping server election. Xu & Chen Expires June 28, 2014 [Page 6] Internet-Draft December 2013 8. Acknowledgements The authors would like to thank . 9. IANA Considerations TBD. 10. Security Considerations This document does not introduce any new security considerations. 11. References 11.1. Normative References [I-D.previdi-isis-segment-routing-extensions] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., and S. Litkowski, "IS-IS Extensions for Segment Routing", draft-previdi-isis-segment-routing-extensions-04 (work in progress), October 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, July 2007. [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. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008. [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008. 11.2. Informative References Xu & Chen Expires June 28, 2014 [Page 7] Internet-Draft December 2013 [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", draft-filsfils-rtgwg- segment-routing-01 (work in progress), October 2013. Authors' Addresses Xiaohu Xu Huawei Email: xuxiaohu@huawei.com Mach Chen Huawei Email: mach.chen@huawei.com Xu & Chen Expires June 28, 2014 [Page 8]