IDR WG Sandy. Zhang Internet-Draft ZTE Corporation Intended status: Standards Track Ying. Cheng Expires: January 7, 2016 China Unicom July 6, 2015 Upstream Assigned Label Collision Solution draft-zhang-idr-upstream-assigned-label-solution-00.txt Abstract The upstream-assigned label is used to identify the specific multicast flow. In MVPN technology RFC6513, it says: "This procedure requires each egress PE to support a separate label space for every other PE. The egress PEs creates a forwarding entry for the upstream-assigned MPLS label, allocated by the ingress PE, in this label space." In common scenario, the "separate label space" is planned by network administrator in advance. For the stable network, the method of allocating the separate label space is easy and practicable. But when the network changes dynamically, it is very hard to allocate the separate label space in advance. The planned label space is probably insufficient. That leads to collision when PE uses the common label space to allocate upstream-assigned label. Therefore we need a flexible solution for the collision of upstream-assigned label in the dynamically changing 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 January 7, 2016. Zhang & Cheng Expires January 7, 2016 [Page 1] Internet-Draft UPSTREAM LABEL COLLISION SOLUTION July 2015 Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Timestamp Attribute . . . . . . . . . . . . . . . . . . . . . 3 2.1. Applicability Restriction and Cautions . . . . . . . . . 4 2.2. Handing a malformed UALRT Attribute . . . . . . . . . . . 4 2.3. Restriction . . . . . . . . . . . . . . . . . . . . . . . 4 3. Originating and Sending the UALRT attribute . . . . . . . . . 4 4. Receiving the UALRT attribute . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction As the development of MVPN technology, data center interconnection technology, and BIER (Bit Indexed Explicit Replication) technology, etc. Multicast is more and more used. Upstream-assigned label is used for egress PEto indicate a specific multicast flow. uppose at a L3VPN network which was used for MVPN only is expanded to support the interconnection of DC. Many VxLan which each need an upstream- assigned label to indicate lead to lack of the label space and it will comsumes a lot of manpower to adjust the label space on every PE. Adjusting the label space on every PE will be difficult and cost more manpower. In this document, we define a new BGP attribute, named UALRT: "upstream-assigned label route's timestamp". When the collision of upstream-assigned label occurs, all the PEs in the L3VPN, will find out those routes which are feasible with use of the common algorithm. And the PE which announces the collision upstream-assigned label will adjust the label to avoid collision. Zhang & Cheng Expires January 7, 2016 [Page 2] Internet-Draft UPSTREAM LABEL COLLISION SOLUTION July 2015 ------- | PEa | --------------------------------- ------- | | ------- | MVPN | | PEc | ------- | | ------- | PEb | --------------------------------- ------- Figure 1: collision of upstream-assigned label in MVPN For example, PEa and PEb send MVPN flows to PEc with a same I-PMSI. PEa send (vpn1, S1, G1) flows to PEc, PEb send (vpn1, S2, G2) flows to PEc similar. PEa and PEb advertise the two multicast routes by upstream-assigned label to let PEc distinguish the two flows. If network manager has not programmed the separate space for upstream- assigned label on every PE, PEa and PEb may advertise the same label for each route. When PEc receives the two multicast flows from the common I-PMSI tunnel, PEc can not distinguish the two flows correctly, and PEc then forward the two flows to wrong receivers. 2. Timestamp Attribute The UALRT attribute is an optional, non-transitive BGP path attribute. The attribute type code for the UALRT attribute is TBD. The value field of the UALRT attribute is defined here to be a set of elements encoded as "Type/Length/Value" (i.e., a set of TLVs). Each such TLV is encoded as shown in Figure 1. 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ | Value +-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Figure 2: UALRT TLV o Type: A single octet encoding the TLV Type. Only type 1, "UALRT TLV", is defined in this document. Use of other TLV types is outside the scope of this document. o Length: Two octets encoding the length in octets of the TLV, including the Type and Length fields. The length is encoded as an unsigned binary integer. o Value: A field containing eight octets of timestamp. Zhang & Cheng Expires January 7, 2016 [Page 3] Internet-Draft UPSTREAM LABEL COLLISION SOLUTION July 2015 This document defines only a single such TLV, the "UALRT TLV". The UALRT TLV is encoded as follows: o Type: 1 o Length: 11 o Value: timestamp. The value field of the UALRT TLV is always 8 octets long, and its value is interpreted as an unsigned 64-bit integer. The time clock when the label is assigned are frequently expressed as 4-octet fragment. By using an 8-octet field, we can be more accurate for high rate clock. When an UALRT attribute is created, it SHOULD contain no more than one UALRT TLV. However, if it contains more than one UALRT TLV, only the first one is used as described the generation of routes. 2.1. Applicability Restriction and Cautions The documents only consider the use of UALRT attribute in MVPN networks, the interconnection of data center, BIER, etc, where the PEs generate upstream-assigned label for multicast routes. 2.2. Handing a malformed UALRT Attribute When receiving a BGP Update message which contains a malformed UALRT attribute, the attribute should be treated as if it was an unrecognized non-transitive attribute. That is, it MUST be quietly ignored and not passed along to other BGP peers. If the UALRT attribute is received and its value is set to 0x0 or the maximum value of 0xFFFFFFFFFFFFFFFF, the attribute should be considered to be malformed and SHOULD be ignored. 2.3. Restriction In this document we discuss the UALRT attribute should be used in intranet of network. The use of UALRT attribute across multi-ASs May be out of the scope of this document. 3. Originating and Sending the UALRT attribute When a PE decides to generate a UALRT attribute for multicast routes with upstream-assigned label, the PE should set the value of UALRT to the time when the route is generated. The PE sends the route with UALRT attribute and other attributes to other PEs to let all the PEs Zhang & Cheng Expires January 7, 2016 [Page 4] Internet-Draft UPSTREAM LABEL COLLISION SOLUTION July 2015 receive the routes with UALRT attribute. The UALRT attribute MUST be transferred by RR. To avoid all the PEs to generate label in the first label space, each PE SHOULD start assign the label with a random offset. 4. Receiving the UALRT attribute When a PE received an upstream-assigned label multicast routes, it will check if there is a BGP UALRT attribute. If the UALRT value is correct, the PE will store the route with the UALRT. Then PE will check if the label is conflict with any exist upstream-assigned label, include the lable generated by the PE or other PEs. If there is a collision, the PE MUST choose the one which timestamp was earlier as the legal route. If the timestamp of two conflict routes are equal, the PE will use the BGP peer address to judge which one is legal. The PE SHOULD choose the one which was advertised by the peer with smaller BGP peer address or larger BGP peer address. If the other conflict label is generated by the PE itself, the PE will adjust the upstream-assigned label to other value, and the PE MUST re-advertise a route with new label and new UALRT attribute. If the other conflict route was not generated by the PE itself, the PE will do nothing until other PE re-advertise a route with new upstream-assigned label and the UALRT attribute. When the PE receives route with new upstream-assigned label and the UALRT attribute, the PE will repeat the store and conflict check function. 5. Security Considerations For general BGP Security Considerations. 6. IANA Considerations IANA is requested to allocate BGP path attribute for UALRT TLVs. 7. Normative References [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008. [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012. Zhang & Cheng Expires January 7, 2016 [Page 5] Internet-Draft UPSTREAM LABEL COLLISION SOLUTION July 2015 [RFC7432] Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, February 2015. Authors' Addresses Sandy Zhang ZTE Corporation No. 50 Software Ave, Yuhuatai Distinct Nanjing 210000 China Phone: +86-025-88014634 Email: zhang.zheng@zte.com.cn Ying Cheng China Unicom Beijing China Phone: +86-10-68799999-7702 Email: chengying10@chinaunicom.cn Zhang & Cheng Expires January 7, 2016 [Page 6]