Internet DRAFT - draft-utgikar-serr
draft-utgikar-serr
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,
<http://www.rfc-editor.org/info/rfc1771>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
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,
<http://www.rfc-editor.org/info/rfc2842>.
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858,
DOI 10.17487/RFC2858, June 2000,
<http://www.rfc-editor.org/info/rfc2858>.
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
DOI 10.17487/RFC2918, September 2000,
<http://www.rfc-editor.org/info/rfc2918>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering
Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291,
August 2008, <http://www.rfc-editor.org/info/rfc5291>.
[RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced
Route Refresh Capability for BGP-4", RFC 7313,
DOI 10.17487/RFC7313, July 2014,
<http://www.rfc-editor.org/info/rfc7313>.
[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, <http://www.rfc-editor.org/info/rfc7432>.
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]
