[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]