Network Working Group                                     Renhai Zhang 
Internet Draft                                              Mach Chen  
Expires: April 2007                         Huawei Technologies Co,LTD 
                                                      October 12, 2006 
                                   
 
                                      
               Nexthop Based Outbound Route Filter for BGP-4 
                   draft-chen-idr-bgp-nexthop-orf-00.txt 


Status of this Memo 

   By submitting this Internet-Draft, each author represents that       
   any applicable patent or other IPR claims of which he or she is       
   aware have been or will be disclosed, and any of which he or she       
   becomes aware will be disclosed, in accordance with Section 6 of       
   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 12, 2007. 

Abstract 

   This document defines a new Outbound Route Filter type for BGP, 
   termed "Nexthop Outbound Route Filter", which can be used to provide 
   Nexthop based route filtering. 

Specification of requirements 

   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. 

 
 
 
Mach                   Expires April 12, 2007                 [Page 1] 

Internet-Draft draft-chen-idr-bgp-nexthop-orf-00.txt       October 2006 
    

Table of Contents 

    
   1. Introduction.................................................2 
   2. Motivation...................................................2 
   3. Nexthop ORF-type.............................................4 
   4. Nexthop ORF Encoding.........................................5 
   5. Capability Specification for Nexthop ORF.....................5 
   6. Nexthop ORF Matching.........................................5 
   7. Security Considerations......................................6 
   8. IANA Considerations..........................................6 
   9. References...................................................6 
      9.1. Normative References....................................6 
      9.2. Informative References..................................6 
   Author's Addresses..............................................6 
   Intellectual Property Statement.................................7 
   Copyright Statement.............................................7 
   Acknowledgment..................................................7 
    
1. Introduction 

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

   This document defines a new Outbound Route Filter type for BGP, 
   termed "Nexthop Outbound Route Filter", which can be used to perform 
   Nexthop based route filtering. The Nexthop ORF only supports exact 
   nexthop address matching. 

    

2. Motivation 

   Advertisement of Multiple Paths (referred to as AMP) in BGP has been 
   defined in [ADD-PATH] and [MULTI-NEXTHOP]. So a BGP speaker, 
   especially route reflector and IX server, MAY advertise multiple 
   paths to its peer for a specific prefix. When we deploy AMP in our 
   network, multiple paths for each prefix MAY be advertised between a 
   BGP speaker and its BGP peer. But in some cases, a BGP router doesn't 
   want to receive those routes with a specific nexthop address from its 
   BGP peers. An alternative method for a BGP router to filter out those 
   routes is based on local routing policy when it received them, but 
   using Nexthop based ORF MAY be a better choice in such a scenario. 

   Consider the following scenarios: 
 
 
Mach                   Expires April 12, 2007                 [Page 2] 

Internet-Draft draft-chen-idr-bgp-nexthop-orf-00.txt       October 2006 
    

                  +------------------------+ 
                  |          AS1           |  
                  |  +-----+      +-----+  |  
                  |  |ASBR1|      |ASBR2|  |  
                  |  +-----+      +-----+  |  
                  +----|--------------|----+  
                       |              | 
                       |              | 
             +---------|--------------|--------+  
             |       +-----+      +-----+      |  
             |       |ASBR3|      |ASBR4|      |  
             |       +-----+      +-----+      |  
             |            \       /            |  
             |            +\-----/+     AS2    |  
             |            |  RR   |            |  
             |            +--/-\--+            |  
             |              /   \              |  
             |      +------+     +------+      |  
             |      |  R1  |     |  R2  |      |  
             |      +------+     +------+      |  
             +---------------------------------+  
             Figure 1: AMP scenario 

   As illustrated above in Figure 1, if we deploy AMP in AS2, that is 
   each router in AS2 has the AMP capability. So the RR MAY advertise 
   two paths to R1 and R2 respectively for each prefix. However, in some 
   cases, R1 or R2 doesn't want to receive those routes which are sent 
   from ASBR1 or ASBR2. In order to avoid unwanted routing updates, R1 
   or R2 MAY send a Nexthop based Outbound Route Filer to its peer (RR) 
   and the RR would apply this filter when it advertises routes to R1 or 
   R2. So, using Nexthop based ORF is a simple method which can satisfy 
   the above requirement in such scenario. 














 
 
Mach                   Expires April 12, 2007                 [Page 3] 

Internet-Draft draft-chen-idr-bgp-nexthop-orf-00.txt       October 2006 
    

                  +------------------------+  
                  |       +-----+          |  
                  |       |ASBR1|          |  
                  |       +-----+      AS1 |  
                  +----------|-------------+  
                             |        
             +---------------|----------------+  
             |           +-------+     AS2    |  
             |           | ASBR21|            |  
             |           +-/---\-+            |  
             |            /     \             |  
             |   +------+/       \+------+    |  
             |   |  R1  |         |  R2  |    |  
             |   +------+\       /+------+    |  
             |            \     /             |  
             |           +-\---/-+            |  
             |           | ASBR22|            |  
             |           +---|---+            |  
             +---------------|----------------+  
                             |  
                  +----------|-------------+  
                  |       +-----+      AS3 |  
                  |       |ASBR3|          |  
                  |       +-----+          |  
                  +------------------------+  
               Figure 2: Multi-homing scenario 

   Figure 2 is another scenario. As usual, in such a scenario R1 and R2 
   MAY receive two paths for each prefix, one with nexthop address of 
   ASBR1 is from ASBR21 and the other with nexthop address of ASBR3 is 
   from ASBR22. But for some reason, R1 prefers to choose ASBR21 as its 
   exit ASBR and R2 prefers to choose ASBR22 as its exit ASBR. So R1 
   doesn't need to receive those routes with nexthop address of ASBR1, 
   and R2 also doesn't need to receive those routes with nexthop address 
   of ASBR3. R1 or R2 can use the local policy to filter out those 
   unwanted routes when it received them. But in such a scenario, using 
   Nexthop based ORF is easier to do so.   

3. Nexthop ORF-type 

   The Nexthop ORF allows one to express ORFs in terms of nexthop 
   address. That is, it provides nexthop address based route filtering, 
   including nexthop address based matching. 

   Conceptually a Nexthop ORF entry consists of the 
   fields<Sequence,Match,Length,Nexthop>. 

 
 
Mach                   Expires April 12, 2007                 [Page 4] 

Internet-Draft draft-chen-idr-bgp-nexthop-orf-00.txt       October 2006 
    

   The "Sequence" field specifies the relative ordering of the entry, 
   this field is an unsigned 32-bit value. 

   The "Match" field specifies whether this entry is "PERMIT" (value 0) 
   or "DENY" (value 1). 

   The Length field specifies the length of Nexthop measured in octets, 
   this field is an unsigned 16-bit value. 

   The Nexthop filed contains the Network Address of the next router on 
   the path to the destination. This field MAY be an IPv4 address, IPv6 
   address or any other kinds of addresses. 

4. Nexthop ORF Encoding 

   The value of the ORF-type for Nexthop ORF-type is <TBD>. 

   A Nexthop ORF entry is encoded as follows. The "Match" field of the 
   entry is encoded in the "Match" field of the common part[BGP-ORF], 
   and the remaining fields of the entry is encoded as follows: 

                  +--------------------------------+ 
                  |   Sequence (4 octets)          | 
                  +--------------------------------+     
                  |   Length   (2 octet)           | 
                  +--------------------------------+      
                  |   Nexthop  ( variable length)  | 
                  +--------------------------------+ 
              Figure 3: Nexthop ORF entry format 

   The "Nexthop" field is a variable length string whose length is 
   determined by "Length" field. This field contains the next hop 
   address which COULD be used by its peer to filter outbound route 
   updates to the speaker. 

5. Capability Specification for Nexthop ORF 

   The Outbound Route Filter capability has been defined in [BGP-ORF]. 
   In this document, in order to implement Nexthop based ORF, we just 
   need to add a new ORF-type for Nexthop based Outbound Route Filter. 
   The Nexthop ORF-type is <TBD. 

6. Nexthop ORF Matching 

   In addition to the general matching rules defined in [BGP-ORF],   
   there are no more other specific matching rules for Nexthop based ORF. 
   Nexthop based ORF only supports exact nexthop address matching. 
 
 
Mach                   Expires April 12, 2007                 [Page 5] 

Internet-Draft draft-chen-idr-bgp-nexthop-orf-00.txt       October 2006 
    

7. Security Considerations 

   This extension to BGP does not change the underlying security issues. 

8. IANA Considerations 

   This document specifies a new Outbound Route Filter (ORF) type: 
    Nexthop ORF type. The value of the ORF-type is <TBD>. 

9. References 

9.1. Normative References 

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

   [BGP-ORF] Chen, E., and Rekhter, Y., "Outbound Route Filtering 
             Capability for BGP-4", draft-ietf-idr-route-filter-15.txt, 
             July 2006. 

   [ASPATH-ORF] Keyur, P., and Susan, H., "Aspath Based Outbound Route 
             Filter for BGP-4", draft-ietf-idr-aspath-orf-08.txt, 
             January  2006. 

   [PREFIX-ORF] Chen, E., and Sangli S., " Address Prefix Based Outbound 
             Route Filter for BGP-4", draft-ietf-idr-bgp-prefix-orf-
             04.txt, July 2006. 

   [ADD-PATH] Walton, D., and Chen, E., "Advertisement of Multiple Paths 
             in BGP", draft-walton-bgp-add-paths-05.txt, February 2006. 

   [MULTI-NEXTHOP] Bhatia, M., Joel, M., and Jakma, P., "Advertising 
             Multiple NextHop Routes in BGP", draft-bhatia-bgp-multiple-
             next-hops-01.txt, August 2006. 

9.2. Informative References 

Author's Addresses 

   Mach Chen 
   Huawei Technologies CO,.LTD. 
   KuiKe Building, No.9 Xinxi Rd., 
   Shang-Di Information Industry Base, 
   Hai-Dian District Beijing P.R. China 100085 
    
   Email: mach@huawei.com 
    
 
 
Mach                   Expires April 12, 2007                 [Page 6] 

Internet-Draft draft-chen-idr-bgp-nexthop-orf-00.txt       October 2006 
    

Intellectual Property Statement 

   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights.  Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 

   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 

   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at 
   ietf-ipr@ietf.org. 

   Disclaimer of Validity 

   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 

Copyright Statement 

   Copyright (C) The Internet Society (2006). 

   This document is subject to the rights, licenses and restrictions 
   contained in BCP 78, and except as set forth therein, the authors 
   retain all their rights. 

Acknowledgment 

   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 

 
 
Mach                   Expires April 12, 2007                 [Page 7]