One document matched: draft-zeng-one-time-prefix-orf-00.txt

Network working group                                         Q. Zeng 
Internet Draft                                                J. Dong 
Intended status: Standards Track                   Huawei Technologies 
Expires: April 2011                                    October 18, 2010 
 
                                      
       One-time Address-Prefix Based Outbound Route Filter for BGP-4 
                                      
                   draft-zeng-one-time-prefix-orf-00.txt 


Abstract  

   This document defines a new Outbound Router Filter (ORF) type for 
   BGP, termed "One-time Address Prefix Outbound Route Filter", which 
   would allow a BGP speaker to send to its BGP peer a route refresh 
   request with a set of address-prefix-based filters to make the peer 
   re-advertise only the specific routes matching the filters to the 
   speaker. This ORF-type enables a BGP speaker to recover some 
   specific "problematic" routes without requiring its peer to re-
   advertise the whole Adj-RIB-Out of specific address family, which 
   makes the trouble shooting operation (such as packets tracking) more 
   efficient and reduces the impact on network stability. This filter 
   does not change the outbound route filters on BGP peers and should 
   only be used for one-time filtering. 

Status of this Memo 

   This Internet-Draft is submitted to IETF in full conformance with 
   the provisions of BCP 78 and BCP 79. 

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 

   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." 

   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt. 

   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 

   This Internet-Draft will expire on April 18, 2011.  

 
 
 
Zeng, et al.           Expires April 18, 2011                 [Page 1] 

Internet-Draft    One-time Address-Prefix Based ORF       October 2010 
    

Copyright Notice 

   Copyright (c) 2010 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. 

Conventions used in this document 

   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]. 

Table of Contents 

   1. Introduction................................................2 
   2. One-time Address Prefix ORF-Type............................3 
   3. Operation...................................................4 
   4. Security Considerations.....................................4 
   5. IANA Considerations.........................................4 
   6. Acknowledgments.............................................4 
   7. References..................................................4 
      7.1. Normative References...................................4 
   Authors' Addresses.............................................5 
    
   1. Introduction 

   The Outbound Route Filtering Capability defined in [RFC5291] 
   provides a mechanism for a BGP speaker to send to its BGP peer a set 
   of Outbound Route Filters (ORFs) that can be used by its peer to 
   filter its outbound routing updates to the speaker.  

   During some network maintenance, BGP speaker only needs to retrieve 
   some specific "problematic" routes from its peer if the routes are 
   possibly lost or contain some problematic attributes for some reason, 
   but send ROUTE-REFRESH will lead to the peer re-advertising its 
   whole Adj-RIB-Out. Such large numbers of updates include a lot of 
   unnecessary routes which would make trouble shooting operation (such 

 
 
Zeng, et al.           Expires April 18, 2011                 [Page 2] 

Internet-Draft    One-time Address-Prefix Based ORF       October 2010 
    

   as packets tracking) more difficult, and is a waste of processing 
   resources and bandwidth. Even configured with ORF mechanism as 
   defined in [RFC5291], on receipt of a ROUTE-REFRESH message, the 
   peer will re-advertise all the routes matching current outbound 
   route filters, i.e., the whole Adj-Rib-Out for this BGP speaker. 
   Since in this case the BGP speaker does not want to change the 
   outbound route filters on its peer, this problem cannot be solved by 
   current ORF mechanism.  

   This document defines a new Outbound Router Filter (ORF) type for 
   BGP, termed "One-time Address Prefix Outbound Route Filter", which 
   would allow a BGP speaker to send to its BGP peer a route refresh 
   request with a set of address-prefix-based filters to make the peer 
   re-advertise only the specific routes matching the filters to the 
   speaker. This ORF-type enables a BGP speaker to recover some 
   specific "problematic" routes without requiring its peer to re-
   advertise the whole Adj-RIB-Out of specific address family, which 
   makes the trouble shooting operation (such as packets tracking) more 
   efficient and reduces the impact on network stability. This filter 
   does not change the outbound route filters on BGP peers and should 
   only be used for one-time filtering. 

   2. One-time Address Prefix ORF-Type 

   This document defines a new ORF type: One-time Address Prefix ORF. 

   As specified in the [RFC5291], an ORF entry is a tuple of the form 
   <AFI/SAFI, ORF-Type, Action, Match, ORF-value> an ORF consists of 
   one or more ORF entries that have a common AFI/SAFI and ORF-Type. An 
   ORF is identified by <AFI/SAFI, ORF-Type>. 

   The format of One-time Address Prefix ORF-Type entry is the same as 
   the encoding of Address Prefix ORF in [RFC5292], the specific fields 
   are defined as follows: 

   Since the semantics of this new ORF-Type is always "one-time 
   filtering" and has no impact on existing ORFs, so the Action field 
   MUST be ignored. 

   The matching rules of the One-time Address Prefix ORF are the same 
   as defined in Address-Prefix-Based ORF [RFC-5292]. 

   The ORF entries of this type are used as one-time filters that MUST 
   not change any previously installed ORF entry on the remote peer. 



 
 
Zeng, et al.           Expires April 18, 2011                 [Page 3] 

Internet-Draft    One-time Address-Prefix Based ORF       October 2010 
    

   3. Operation 

   The capability negotiation of <AFI/SAFI, One-time Address Prefix 
   ORF> MUST NOT delay the advertisement of routes with this AFI/SAFI. 

   The received One-time Address Prefix ORF entries SHOULD only be used 
   for one-time route filtering and MUST NOT be saved locally. The 
   received One-time Address Prefix ORF entries MUST NOT modify the 
   outbound route filters on the receiver (either locally configured or 
   received from peer through ORF). 

   On receipt of ROUTE-REFRESH message with One-time Address Prefix ORF 
   entries, the receiver SHOULD re-advertise to the peer the routes 
   from the Adj-RIB-Out associated with the peer which pass the entries 
   carried in the One-time Address Prefix ORF and taking into account 
   the locally saved ORFs (if any) received from the peer. 

   4. Security Considerations 

   This extension to BGP does not change the underlying security issues 
   in [RFC4271]. 

   5. IANA Considerations 

   This document specifies a new Outbound Route Filtering (ORF) type, 
   One-time Address-Prefix ORF. The value of the ORF-type needs to be 
   assigned by the IANA. 

   6. Acknowledgments 

   The authors would like to thank Keyur Patel, Enke Chen, Rob Shakir, 
   Susan Hares, Haibo Wang, Jiawei Dong, Yaqun Xiao, Mach Chen for 
   their valuable suggestions and comments to this document. 

   7. References 

      7.1. Normative References 

   [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 
             Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. 

   [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 
             September 2000. 

   [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 
             Capability for BGP-4", RFC 5291, August 2008. 

 
 
Zeng, et al.           Expires April 18, 2011                 [Page 4] 

Internet-Draft    One-time Address-Prefix Based ORF       October 2010 
    

   [RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound 
             Route Filter for BGP-4", RFC 5292, August 2008. 

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
             Requirement Levels", BCP 14, RFC 2119, March 1997. 

   [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 
             Standards Track Code Points", BCP 100, RFC 4020, February 
             2005. 

   [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 
             IANA Considerations Section in RFCs", BCP 26, RFC 5226, 
             May 2008. 

Authors' Addresses 

   Qing Zeng 
      Huawei Technologies Co.,Ltd. 
      Huawei Building, No.3 Xinxi Rd., 
      Hai-Dian District 
      Beijing, 100085 
      P.R. China 
              
      Email: zengqing@huawei.com 
    
   Jie Dong  
      Huawei Technologies Co.,Ltd. 
      Huawei Building, No.3 Xinxi Rd., 
      Hai-Dian District 
      Beijing, 100085 
      P.R. China 
              
      Email: dongjie_dj@huawei.com 











 
 
Zeng, et al.           Expires April 18, 2011                 [Page 5]