Internet Engineering Task Force A. Utgikar Internet-Draft November 7, 2015 Intended status: Standards Track Expires: May 5, 2016 Selective route refresh for BGP draft-utgikar-serr-00 Abstract This document proposes a new Route Refresh mechanism which provides ability to perform route refresh for a smaller subset of updates than the entire Adj-RIB-Out. It is applicable to multiple deployment scenarios like , BGP-LS [I-D.draft-ietf-idr-ls-distribution-11] , EVPN [RFC7432]. The suggested capability will help faster convergence and minimize overhead for routing policy changes. This document updates [RFC7313]. 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] . 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 May 5, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Utgikar Expires May 5, 2016 [Page 1] Internet-Draft draft-utgikar-serr-00 November 2015 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. Motivation and Applications . . . . . . . . . . . . . . . . . 3 3. Existing Route Refresh Mechanisms . . . . . . . . . . . . . . 3 4. Selective Route refresh mechanism . . . . . . . . . . . . . . 3 5. Selective Route refresh format . . . . . . . . . . . . . . . 4 6. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Operation . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2. Interoperation with ERR and ORF . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction When a routing policy changes or to validate consistency of routes, route refresh mechanism helps in synchronizing the routes between BGP peers. In BGP-LS [I-D.draft-ietf-idr-ls-distribution-11] , link state and traffic information is carried by BGP. A route distinguisher is used to differentiate routes of distinct virtual private networks (VPN) [RFC4364]. This document proposes a new BGP Route Refresh mechanism which would allow route refresh operation between BGP speakers for certain subset/subclass of AFI/SAFI. The subset could be specified by parameters specific to application. For example, BGP-LS can specify one or more of Route distinguisher, ASN+LS-ID, protocol-Instance and NLRI-type. Besides BGP-LS, other existing AFI/SAFI like EVPN can benefit from the capability today already. Utgikar Expires May 5, 2016 [Page 2] Internet-Draft draft-utgikar-serr-00 November 2015 2. Motivation and Applications In current BGP-RR [RFC2918], mechanism, a route refresh will trigger replay of all routes in the corresponding AFI-SAFI. For BGP-LS, this implies significant overhead since it includes all segment-IDs, all protocols, all instances. This can be made more efficient by specifying the subset to be refreshed with segment-ID, or protocol or the instance. In an EVPN deployment, a PE router 'A' advertises a configured ES to its other peers, via an ES route. If any of the peers is not configured for the ES announced, it drops the message, as recommended by the RFC. If such a peer is later configured to participate in the ES, it will need to request refresh of all EVPN SAFI, which can trigger the re-advertisement of tens of millions of MACs. This can be easily avoided by specifying the route type to refresh described in this draft. 3. Existing Route Refresh Mechanisms A BGP speaker advertises capabilities [RFC2918], at session initiation. Thus speaker knows if peer supports route refresh capability [RFC2842], or enhanced route refresh capability [RFC7313], or both. A BGP speaker requests REFRESH of routes specific to the AFI-SAFI [RFC2918]. The peer responds with its latest view of route information. The BGP Type 5: ROUTE-REFRESH message [RFC7313], adds several values on the originally reserved byte: Message Format: One < AFI, SAFI > encoded as 0 7 15 23 31 +-------+-------+-------+-------+ | AFI | Res. | SAFI | +-------+-------+-------+-------+ Figure (1): The Enhanced Route Refresh format. The reserved field value indicates type of message. In particular, value 0 = request, 1 = BoRR, 2 = EoRR. 4. Selective Route refresh mechanism The BGP protocol extensions introduced in this document include the definition of a new BGP capability, named Selective Route Refresh Capability", and the specification of the message formats for the Utgikar Expires May 5, 2016 [Page 3] Internet-Draft draft-utgikar-serr-00 November 2015 ROUTE-REFRESH message. The Capability Length field of this capability is variable. Capability value: one entry per AFI-SAFI (for which the SERR is supported) as shown below in figure: +--------------------------------------------------+ | Address Family Identifier (2 octets) | +--------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +--------------------------------------------------+ // AFI-SAFI specific filter TLVs // +--------------------------------------------------+ Figure (2): Capability value entry for proposed Selective route refresh format. AFI-SAFI specific filter TLVs are as shown in Figure (4). By advertising this capability to a peer, a BGP speaker conveys that it supports refreshing a subset of routes in an AFI-SAFI. This subset may be specified through filters to match parameters on NLRIs. These filters can be specified in extensible TLV format. For BGP-LS, the filters allow us to constrain - (a) Route distinguisher (b) Autonomous System Number + Link State-ID (c) IGP Protocol + Instance identifier (d) NLRI type For EVPN, the filters allow us to constrain route type, segment ID etc: (a) Route distinguisher (b) Route type (c) Ethernet segment ID 5. Selective Route refresh format The format of the proposed route refresh (request and response) messages is shown in the following figure: Utgikar Expires May 5, 2016 [Page 4] Internet-Draft draft-utgikar-serr-00 November 2015 0 7 15 23 31 +-------+-------+-------+-------+ | AFI | Res. | SAFI | +-------+-------+-------+-------+ |Length | +-------+-------+-------+-------+ | AFI-SAFI specific | // filter TLVs // | (variable) | +-------+-------+-------+-------+ Figure (3): The Proposed Selective route refresh format. This format is used only when the reserved byte field in Enhanced Route Refresh message takes on values defined as: 3: Selective Route refresh request. 4: BoRR for Selective Route refresh 5: EoRR for Selective Route refresh Also, the AFI-SAFI specific filter TLVs are included in all message types (3,4,5). Thus upon receiving refresh data (and type 4,5 messages), BGP receiver can mark local entries matching the filter TLVs as stale and cleanup obsolete ones after receiving EORR. The meaning, use and encoding of < AFI,Res., SAFI > fields are the same as defined in [RFC2918], . Length indicates number of AFI/SAFI specific TLVs. Length of 0 is valid and indicates set of all NLRIs in the AFI/SAFI. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-------+-------+-------+-----+ // Value (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure (4): AFI-SAFI specific filter TLV format. Type is inferred as per the application specific filter table e.g. Table 2, 3. Utgikar Expires May 5, 2016 [Page 5] Internet-Draft draft-utgikar-serr-00 November 2015 +------+---------------------------+ | Type | Filter Parameter | +------+---------------------------+ | 1 | RD | | 2 | ASN + LS-ID | | 3 | Protocol | | 4 | Proto-Instance | | 5 | NLRI Type | +------+---------------------------+ Table (2): Specific Filter TLVs for BGP-LS The value of NLRI Type is as per [BGP-LS, Table 1]. The value of Protocol Type is as per [BGP-LS, Table 2]. The value of Proto-Instance is as per [BGP-LS, Table 3]. +------+---------------------------+ | Type | Filter Parameter | +------+---------------------------+ | 1 | Route Type | | 2 | RD | | 3 | Ethernet Segment ID | +------+---------------------------+ Table (3): Specific Filter TLVs for BGP-EVPN 6. Functionality 6.1. Operation Operationally, Selective route refresh is fully compatible with existing BGP procedures. Type 5 route refresh message format [RFC2918] has been developed further, by redefining the reserved value field and appending application specific parameter TLV fields. A BGP speaker that is willing to receive the Selective ROUTE-REFRESH message from its peer should advertise the Capability to the peer using BGP Capabilities advertisement [RFC2842]. A BGP speaker may send an Selective ROUTE-REFRESH message to its peer only if it has received the Capability from its peer. The < AFI, SAFI > carried in such a message should be one of the < AFI, SAFI > that the peer has advertised to the speaker at the session establishment time via capability advertisement. Utgikar Expires May 5, 2016 [Page 6] Internet-Draft draft-utgikar-serr-00 November 2015 If a BGP speaker receives from its peer an Selective ROUTE-REFRESH message with the < AFI, SAFI > that the speaker didn't advertise to the peer at the session establishment time via capability advertisement, the speaker shall ignore such a message. If a BGP speaker receives Selective ROUTE-REFRESH request (type 3) from a peer for AFI-SAFI with filters it does not support, it will treat it as Enhanced ROUTE-REFRESH (type 0) message. Otherwise, the BGP speaker shall process the message as per value of the reserved field. Values 0, 1, 2 indicate conventional BGP-ERR [RFC7313], processing. Value of 3 implies request to re-advertise to that peer the subsection of Adj-RIB-Out of the < AFI, SAFI > carried in the message, matching the parameters in the request message [section 6]. The receiver MUST send Selective ROUTE-REFRESH messages (BoRR and EoRR, values 4, 5 resp) before and after the transmission of routes. Upon receiving Selective ROUTE-REFRESH message with value of 4, (BoRR message), BGP speaker must extract the parameters in the filter field. It must mark routes for that AFI-SAFI matching specified parameters as stale. All routes received subsequently must replace the stale routes. After receiving EoRR message, all routes that are still marked stale must be removed. A BoRR received, not in response to a request message, should also be processed similarly. An EoRR message received without a BoRR preceding it, MUST be ignored. As an example, for BGP-LS : +---------------------------------+----------------------------------------------+ | SERR request TLVs | SERR NLRI Response (besides BoRR, EoRR) | +---------------------------------------------+----------------------------------+ | (1) Route distinguisher (RD*) | All ASN+LS-ID matching given RD | | only | All Proto-Instances therein with all NLRIs | +---------------------------------------------+----------------------------------+ | (2) RD* + ASN + LS-ID | All Proto-Instances matching given | | | parameters + All NLRIs therein | +---------------------------------------------+----------------------------------+ | (3) RD* + ASN + LS-ID + Proto + | All NLRI types matching given parameters | | + Instance-ID + NLRI type | | +---------------------------------------------+----------------------------------+ | (4) RD* + ASN + LS-ID + Proto + | All NLRIs of the specified type | | + Instance-ID + NLRI type | matching given parameters | +---------------------------------+----------------------------------------------+ * Route distinguisher (RD) is relevant only for SAFI VPN (not SAFI-71). Utgikar Expires May 5, 2016 [Page 7] Internet-Draft draft-utgikar-serr-00 November 2015 6.2. Interoperation with ERR and ORF A BGP speaker may support both ORF and SERR capabilities. When the reserved field of ROUTE-REFRESH message is 0, ORF encoding may follow as usual. When the reserved field of ROUTE-REFRESH message is 3, SERR format MUST follow as specified above. A SERR-capable speaker may receive SERR (type 3) followed by Enhanced ROUTE-REFRESH request (type 0). It MUST completely process SERR (BoRR type 4 and EoRR type 5) before starting to process Enhanced ROUTE-REFRESH (type 1 and 2). A SERR-capable speaker may receive multiple SERR (type 3) request messages from a peer. It MUST completely process one request before starting another. Thus a ROUTE-REFRESH (BoRR - EoRR) session MUST complete before next RR session begins. It may look like one of the sequences -- BoRR (type 1) -- EoRR (type 2) -- BoRR (type 4) -- EoRR (type 5) OR BoRR (type 4) -- EoRR (type 5) -- BoRR (type 1) -- EoRR (type 2) If a speaker receives route refresh messages in the sequence : BoRR (SERR, type 4) -- BoRR ( ERR, type 1) -- EoRR (type 2 or 5), it MUST ignore all data until it receives both EoRR(type 5) and EORR( type 2). It MUST then issue new ERR (type 0). The behavior should be the same for the following message sequence also: BoRR (type 1) -- BoRR (type 4) -- EoRR (type 2 or 5) If messages are received in any other out of sequence order, a speaker MUST notify the peer and close the connection. 7. Security Considerations Implementations must assure that malformed TLV and Sub-TLV permutations do not result in errors which cause hard protocol failures. 8. Normative References [I-D.draft-ietf-idr-ls-distribution-11] Gredler, H., "North-Bound Distribution of Link-State and TE Information using BGP", internet-draft draft-ietf-idr- ls-distribution-11, June 2015. [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 4)", RFC 1771, DOI 10.17487/RFC1771, March 1995, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Utgikar Expires May 5, 2016 [Page 8] Internet-Draft draft-utgikar-serr-00 November 2015 [RFC2842] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 2842, DOI 10.17487/RFC2842, May 2000, . [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, DOI 10.17487/RFC2858, June 2000, . [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, DOI 10.17487/RFC2918, September 2000, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, August 2008, . [RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced Route Refresh Capability for BGP-4", RFC 7313, DOI 10.17487/RFC7313, July 2014, . [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . Author's Address Anant Utgikar 300 Holger Way San Jose, CA 95134 USA Email: anant.ietf@gmail.com Utgikar Expires May 5, 2016 [Page 9]