Network Working Group L. Cheng Internet-Draft M. Sun Intended status: Informational ZTE Corporation Expires: March 3, 2012 August 31, 2011 Auto-Configuration Extention in Virtual Aggregation draft-cheng-grow-va-auto-extensions-00 Abstract Auto-Configuration in Virtual Aggregation as specified in [I-D.ietf-grow-va-auto] requires configuration of a "VP-range list" in ASBRs connected to transit and peer ISPs. These ASBRs simply tag some routes whose prefix falls within the VP-Range with a "can- suppress" tag to indicate whether these routes should be FIB installed. This draft specified an extended auto-configuration mechanism in Virtual Aggregation to support the configuration of both "VP-List" and "popular prefixes". Specifically, based on this mechanism, the ratio of lost packets when VP routes fail could be minimized. 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 3, 2012. Copyright Notice Copyright (c) 2011 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 Cheng & Sun Expires March 3, 2012 [Page 1] Internet-Draft Auto-Configuration Extention August 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Routes Classification and Routes Tagging . . . . . . . . . 4 3.2. Routes Installation . . . . . . . . . . . . . . . . . . . 5 3.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 5 4. Operation under Special Scenario . . . . . . . . . . . . . . . 7 4.1. Non-tagging Routers Operation . . . . . . . . . . . . . . 7 4.2. Tagging Routers Operation . . . . . . . . . . . . . . . . 8 4.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Cheng & Sun Expires March 3, 2012 [Page 2] Internet-Draft Auto-Configuration Extention August 2011 1. Introduction Virtual Aggregation specified in [I-D.ietf-grow-va] requires configuration of a static "VP-List" on all routers. "VP-List" allows routers to know which prefixes may or may not be FIB installed. Auto-configuration mechanism [I-D.ietf-grow-va-auto] provides an optional method for routers to do routes decision with less configuration. Auto-configuration is an optional alternative to the VP-list that requires far less configuration. However, further concentrates should be focused on some scenarios where packets transmission maybe seriously influenced based on this mechanism. Furthermore, this mechanism could also be extended to provide more excellent service. This draft specifies Auto-Configuration Extension Operation, which includes the following two aspects: o VP routes to be specified particularly. Based on current auto- configuration, tagging routers must not tag VP routes with can- suppress tag. If the ISP has a policy of FIB-installing customer routes, then routes received from customers should also not be tagged. Consequently, there may be three kinds of routes are non- tagged in the AS: routes whose prefix out scope of VP-Range, VP routes and customer routes. According to these tagging rules, non-tagging routers will not be able to identify VP routes. As a result, in the case where all VP routes for a given VP are withdrawn, non-tagging routers would not be able to FIB-install sub-prefixes within the VP. This will influence the normal transmission of data packets seriously. o Extensions to realize popular prefixes auto-configuration. As specified in [I-D.ietf-grow-va], deployment of Visual Aggregation will cause path stretch. To minimize the latency and load associated with the longer path, ISP could measure traffic volume over time and install the high volume prefixes. These prefixes which are within a VP, but still be FIB installed are called popular prefixes. Furthermore, popular prefixes could also be consisted of policy-based prefixes and static list prefixes. Customer prefixes could be considered as one kind of policy- based prefixes. Consequently, tagging routers could also be configured with a popular prefixes list, and realize popular prefixes auto- configuration by not tag routes whose prefix falls within this list. Cheng & Sun Expires March 3, 2012 [Page 3] Internet-Draft Auto-Configuration Extention August 2011 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 [RFC2119]. 2. Terminology This draft uses terms defined in [I-D.ietf-grow-va]. This section defines some new terms used in this document. Tagging router: ASBRs which are configured with "VP range" and "Popular-Prefix list". These routers tag routes with different tags based on route type. Typically, all ASBRs that connect to one or more transit provider ISPs must be configured as tagging routers. ASBRs that connect to one or more peer ISPs should be configured as tagging routers. ASBRs that connect to customer networks should not be configured as tagging routers. Non-tagging router: The VA routers in AS which are not tagging routers. Popular-Prefix list: List of popular prefixes. Suppress tag: Tags used by tagging routers to tag routes. Routes with this tag may not be FIB installed by routers. This tag could be attached to a route as a Non-transitive Extended Communities Attribute. Install tag: Tags used by tagging routers to tag routes. Router with this tag must be FIB installed by any router. This tag could be attached to a route as a Non-transitive Extended Communities Attribute. 3. Specification 3.1. Routes Classification and Routes Tagging With this extended auto-configuration approach, every tagging router will be configured with the same "VP-range list" and "popular prefix list". "VP-range list" consists of the ranges of IP address that are collectively covered by all VPs in the AS [I-D.ietf-grow-va-auto]. "Popular-Prefix list" is a list of popular prefixes. These popular prefixes are all regular prefixes, and could be selected by ISPs Cheng & Sun Expires March 3, 2012 [Page 4] Internet-Draft Auto-Configuration Extention August 2011 individually based on their requirements. With the extended auto-configuration approach, ASBRs which are tagging routers first classify all routes into three types based on the "VP range" and "Popular-Prefix list" configured in them: Type1: VP routes which MUST be FIB installed by any router; Type2: Routes whose prefix falls within "Popular-Prefix list", and routes whose prefix is not fall within "VP range"; Type3: Routes whose prefix falls within "VP range", and meantime are out scope of Type 1 and Type 2 routes. Tagging routers tag routes explicitly according to route types. 1. All VP routes (type 1) MUST be tagged with a "install tag". 2. All routes falls within Type 2 SHOULD NOT be tagged. 3. All routes falls within Type 3 MAYBE tagged with a "suppress tag". 3.2. Routes Installation Routers install or suppress FIB entries according to the following rules. 1. Routes with "install tag" MUST be FIB-installed. 2. Routes without any tag SHOULD be FIB-installed. 3. Routes with "suppress tag" MAY be FIB-suppressed. 4. APRs MUST FIB-install routes for sub-prefixes that fall within the APRs!_ VPs, whether or not the route is tagged. Note: tagging routers conceptually follow these rules after tagging (or not tagging) the route. Note: these rules apply only to the route used by the routers as the best route. 3.3. Implementation An instance of mechanism operation is depicted in this subsection. Consider the scenario depicted in Figure. 1. Cheng & Sun Expires March 3, 2012 [Page 5] Internet-Draft Auto-Configuration Extention August 2011 +--------------------+ +-----------------------------------------+ | | | +-----+ ____ | | Transit Network | | VP route: 22/8| | / Connect | | (23.1.1.0/24) |\ | ____| NTR1|/ To | | | \ | / | |\ Other | +--------------------+ \ | +------+ / +-----+ \____ Routers | ---+-| ASBR |/ | | | | |\ | ____ | +--------------------+ ---+-| (TR) | \ +-----+ / Connect | | | / | +------+ \____| |/ To | | Peer Network | / | | NTR2|\ Other | | (22.1.0.0/16) |/ | | | \____ Routers | | | | +-----+ | +--------------------+ +-----------------------------------------+ +----------------------+ TR: Tagging Router | VP Range: 22/7 | NTR: Non-Tagging router | P-P list: 22.1.1.0/24| P-P list: Popular Prefix list +----------------------+ Figure. 1 In this situation, an ASBR connected to transit network (23.1.1.0/24) and peer network (22.1.0.0/16) is selected to be a TR (tagging router). TR is configured with a VP range 22/7 and a popular prefix list contains 23.1.1.0/24. The NTR1 (Non-Tagging Router 1) is an APR (Aggregate Point Router) who announces a VP route 22/8. To describe operation of different elements, assume that following routes will be received by TR, NTR1 and NTR2. Routes Prefix ------------------------------- 1 22/8 2 22.1.1.1/32 3 22.1.0.1/32 4 23.1.1.1/32 TR Operation: o For route with prefix 22/8, as this route is a VP route announced by NTR1, TR will tag it with a "install tag". o The prefix 22.1.1.1/32 falls within the popular prefix list, TR will not tag it, although the route's prefix falls within the VP range. Cheng & Sun Expires March 3, 2012 [Page 6] Internet-Draft Auto-Configuration Extention August 2011 o TR perceives that prefix 22.1.0.1/32 falls within the VP range and is not a popular prefix. This route will be tagged with a "suppress tag". o For route with prefix 23.1.1.1/32, as the prefix falls within VP range 22/7, this route will also be tagged with a "suppress tag". NTR Operation: o For route with prefix 22/8, as this route is tagged with "install tag", all NTRs must FIB install it. o For route with prefix 22.1.1.1/32, as this route is not tagged, NTRs should FIB install it. Especially for NTR1, as the prefix falls within the VP (22/8) it announced, it must FIB install the route. It should be noticed that in this scenario, NTR1 is an APR, and NTR2 is a non-APR. These two kinds of routers will implement different operation upon some suppress tagged routes. o According to NTR2, as the router is a non-APR, all routes with "suppress tag" should not be installed. As a result, NTR2 will not FIB install 22.1.0.1/32 and 23.1.1.1/32. o Now consider the operation of NTR1. * FOr the route 22.1.0.1/32 with "suppress tag", NTR1 perceives that prefix falls within 22/8, and will FIB install the route. * According to route 23.1.1.1/32 with "suppress tag", NTR1 doesn't have to FIB install it, as NTR1 is not the APR for this route. 4. Operation under Special Scenario Based on analysis in section 1, when VP routes are not tagged specially, VP routes failing will influence the packets transmission seriously. From perspective of non-tagging routers, VP routes could be identified through the "install tag" based on extended auto- configuration mechanism. This section assumes a special scenario that all VP routes for a given VP are withdrawn. Proper operation of tagging routers and non-tagging routers is described as following. 4.1. Non-tagging Routers Operation When the non-tagging routers find that all VP routes for a given VP withdrawn, they will immediately look up the routing table in the RIB, select and FIB install the suppress tagged routes whose prefixes Cheng & Sun Expires March 3, 2012 [Page 7] Internet-Draft Auto-Configuration Extention August 2011 fall within the withdrawn VP. 4.2. Tagging Routers Operation When the tagging routers find that all VP routes for a given VP are withdrawn, they will implement the following operation: o Look up the routing table in the RIB, select and FIB install the suppress tagged routes whose prefixes fall within the withdrawn VP; o Record VP information of the withdrawn VP routes; o When there is an invalid record for a given VP, all routes received by the tagging routers whose prefixs falls within this VP should not be tagged. According to existence of invalid VP records, once receiving a VP route, tagging routers will compare the VP prefix received with the VP prefixes recorded. If the received prefix match an invalid prefix record, they will implement the following operation: o Delete the invalid VP prefix record; o Tag received VP route with "install tag"; o Tag all Type 3 routes whose prefix falls within this VP with "suppress tag". 4.3. Implementation Consider the implementation usecase depicted in Figure. 1. Assume that all VP routes for the VP 22/8 are withdrawn. According to this problem, NTRs (include APRs) check their routing table in RIB, and find out suppress tagged routes whose prefixes fall within the VP 22/8, such as routes with 22.1.0.1/32. NTRs will FIB install these routes, and forward packets based on them. According to this problem, TRs will also FIB install the suppressed tagged routes whose prefixes fall within the VP 22/8. Furthermore, TRs will record the prefix information of VP 22/8. During the period that VP 22/8 is withdrawn, all routes whose prefix falls within the VP will not be tagged by TRs, indicates that routes such like 22.1.1.1/32 and 22.1.0.1/32 should be FIB installed. Every TR maintains a record of the withdrawn VP 22/8. When the TR receives a new VP route with prefix 22/8, it will consider this situation as "VP Recovery". Withdrawn record of 22/8 will be deleted, and the new VP route will be tagged with "install tag". Furthermore, the Type 3 routes whose prefixes fall within the 22/8 such as 22.1.0.1/32 will be tagged with "suppress tag". Cheng & Sun Expires March 3, 2012 [Page 8] Internet-Draft Auto-Configuration Extention August 2011 5. IANA Considerations IANA is requested to assign, from the registry "BGP Assigned non- transitive extended communities", values TBD for "must install" and "can suppress". Registry Name: BGP Assigned non-transitive extended communities Name Type Value ------------ ------------- must install TBD can suppress TBD 6. Security Considerations TBD 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. 7.2. Informative References [I-D.ietf-grow-va] Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and L. Zhang, "FIB Suppression with Virtual Aggregation", draft-ietf-grow-va-05 (work in progress), June 2011. [I-D.ietf-grow-va-auto] Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and L. Zhang, "Auto-Configuration in Virtual Aggregation", draft-ietf-grow-va-auto-04 (work in progress), June 2011. [I-D.ietf-idr-reserved-extended-communities] Decraene, B. and B. Decraene, "Assigned BGP extended communities", draft-ietf-idr-reserved-extended-communities-01 (work in progress), May 2011. Cheng & Sun Expires March 3, 2012 [Page 9] Internet-Draft Auto-Configuration Extention August 2011 Authors' Addresses Li Cheng ZTE Corporation Zijinghua Road No.68 NanJing, Yuhuatai District 210012 P.R.China Email: cheng.li2@zte.com.cn Mo Sun ZTE Corporation Zijinghua Road No.68 NanJing, Yuhuatai District 210012 P.R.China Phone: +86-025-52871474 Email: sun.mo@zte.com.cn Cheng & Sun Expires March 3, 2012 [Page 10]