From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5291.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc5291.txt (limited to 'doc/rfc/rfc5291.txt') diff --git a/doc/rfc/rfc5291.txt b/doc/rfc/rfc5291.txt new file mode 100644 index 0000000..d35e722 --- /dev/null +++ b/doc/rfc/rfc5291.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group E. Chen +Request for Comments: 5291 Cisco Systems +Category: Standards Track Y. Rekhter + Juniper Networks + August 2008 + + + Outbound Route Filtering Capability for BGP-4 + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document defines a BGP-based mechanism that allows a BGP speaker + to send to its BGP peer a set of Outbound Route Filters (ORFs) that + the peer would use to constrain/filter its outbound routing updates + to the speaker. + +1. Introduction + + Currently, it is not uncommon for a BGP speaker [BGP-4] to receive, + and then filter out some unwanted routes from its peers based on its + local routing policy. Since the generation and transmission of + routing updates by the sender, as well as the processing of routing + updates by the receiver consume resources, it may be beneficial if + the generation of such unwanted routing updates can be avoided in the + first place. + + This document defines a BGP-based mechanism that allows a BGP speaker + to send to its BGP peer a set of Outbound Route Filters (ORFs). The + peer would then apply these filters, in addition to its locally + configured outbound filters (if any), to constrain/filter its + outbound routing updates to the speaker. + +2. 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 [RFC2119]. + + + + + + +Chen & Rekhter Standards Track [Page 1] + +RFC 5291 ORF Capability for BGP-4 August 2008 + + +3. Outbound Route Filter (ORF) + + This document uses the terms "Address Family Identifier (AFI)" and + "Subsequent Address Family Identifier (SAFI)". In the context of + this document, the meaning of these terms is the same as in [BGP-MP]. + + Conceptually, an ORF entry is a tuple of the form ; an ORF consists of one or more ORF + entries that have a common AFI/SAFI and ORF-Type. An ORF is + identified by . + + The "AFI/SAFI" component provides a coarse granularity control by + limiting the ORF to only the routes whose Network Layer Reachability + Information (NLRI) matches the "AFI/SAFI" component of the ORF. + + The "ORF-Type" component determines the content of the ORF-value. + + The "Action" component controls handling of the ORF Request by the + remote peer. Action can be one of ADD, REMOVE, REMOVE-ALL. ADD adds + an ORF entry to the ORF on the remote peer; REMOVE deletes a + previously installed ORF entry on the remote peer; REMOVE-ALL deletes + the previously installed entries in the specified ORF on the remote + peer. + + The "Match" component is used to support matching granularity on a + per ORF entry basis. It can be either PERMIT or DENY. The semantics + of PERMIT is to ask the peer to pass updates for the set of routes + that match the ORF entry. The semantics of DENY is to ask the peer + not to pass updates for the set of routes that match the ORF entry. + + When an ORF is defined, an ORF-specific matching rule MUST be + specified so that there is no ambiguity regarding which ORF entry is + considered as the matching entry in the ORF when a route is passed + through the ORF. + + + + + + + + + + + + + + + + + +Chen & Rekhter Standards Track [Page 2] + +RFC 5291 ORF Capability for BGP-4 August 2008 + + +4. Carrying ORF Entries in BGP + + ORF entries are carried in the BGP ROUTE-REFRESH message [BGP-RR]. + + A BGP speaker can distinguish an incoming ROUTE-REFRESH message that + carries one or more ORF entries from an incoming plain ROUTE-REFRESH + message by using the Message Length field in the BGP message header. + + A single ROUTE-REFRESH message MAY carry multiple ORF entries in one + or more ORFs, as long as all these entries share the same AFI/SAFI. + + From the encoding point of view, each ORF entry consists of a common + part and type-specific part, as shown in Figures 1 and 2. + + The common part consists of , and + is encoded as follows: + + The AFI/SAFI component of an ORF entry is encoded in the AFI/SAFI + field of the ROUTE-REFRESH message. + + Following the AFI/SAFI component is the one-octet When-to-refresh + field. The value of this field can be either IMMEDIATE (0x01) or + DEFER (0x02). The semantics of IMMEDIATE and DEFER are discussed + in the "Operation" section of this document. + + Following the When-to-refresh field is a collection of one or more + ORFs, grouped by ORF-Type. + + The ORF-Type component is encoded as a one-octet field. + + The "Length of ORF entries" component is a two-octet field that + contains the total length (in octets) of the ORF entries that + follows for the specified ORF type. + + + + + + + + + + + + + + + + + + +Chen & Rekhter Standards Track [Page 3] + +RFC 5291 ORF Capability for BGP-4 August 2008 + + + +--------------------------------------------------+ + | Address Family Identifier (2 octets) | + +--------------------------------------------------+ + | Reserved (1 octet) | + +--------------------------------------------------+ + | Subsequent Address Family Identifier (1 octet) | + +--------------------------------------------------+ + | When-to-refresh (1 octet) | + +--------------------------------------------------+ + | ORF Type (1 octet) | + +--------------------------------------------------+ + | Length of ORF entries (2 octets) | + +--------------------------------------------------+ + | First ORF entry (variable) | + +--------------------------------------------------+ + | Second ORF entry (variable) | + +--------------------------------------------------+ + | ... | + +--------------------------------------------------+ + | N-th ORF entry (variable) | + +--------------------------------------------------+ + | ORF Type (1 octet) | + +--------------------------------------------------+ + | Length of ORF entries (2 octets) | + +--------------------------------------------------+ + | First ORF entry (variable) | + +--------------------------------------------------+ + | Second ORF entry (variable) | + +--------------------------------------------------+ + | ... | + +--------------------------------------------------+ + | N-th ORF entry (variable) | + +--------------------------------------------------+ + | ... | + +--------------------------------------------------+ + + Figure 1: Carrying ORF Entries in the ROUTE-REFRESH Message + + + + + + + + + + + + + + +Chen & Rekhter Standards Track [Page 4] + +RFC 5291 ORF Capability for BGP-4 August 2008 + + + The rest of the components in the common part are encoded in the + first octet of each ORF-entry (from the most significant to the least + significant bit) as shown in Figure 2: + + Action is a two-bit field. The value of this field is 0 for ADD, + 1 for REMOVE, and 2 for REMOVE-ALL. + + Match is a one-bit field. The value of this field is 0 for PERMIT + and 1 for DENY. This field is significant only when the value of + the Action field is either ADD or REMOVE. + + Reserved is a 5-bit field. It is set to 0 on transmit and ignored + on receipt. + + +---------------------------------+ + | Action (2 bit) | + +---------------------------------+ + | Match (1 bit) | + +---------------------------------+ + | Reserved (5 bits) | + +---------------------------------+ + | Type specific part (variable) | + +---------------------------------+ + + Figure 2: ORF Entry Encoding + + When the Action component of an ORF entry specifies REMOVE-ALL, + the entry consists of only the common part. + + + + + + + + + + + + + + + + + + + + + + + +Chen & Rekhter Standards Track [Page 5] + +RFC 5291 ORF Capability for BGP-4 August 2008 + + +5. Outbound Route Filtering Capability + + A BGP speaker that is willing to receive ORF entries from its peer, + or a BGP speaker that would like to send ORF entries to its peer, + advertises this to the peer by using the Outbound Route Filtering + Capability, as described below. + + The Outbound Route Filtering Capability is a new BGP Capability + [BGP-CAP] defined as follows: + + Capability code: 3 + + Capability length: variable + + Capability value: one or more of the entries as shown in Figure 3. + + +--------------------------------------------------+ + | Address Family Identifier (2 octets) | + +--------------------------------------------------+ + | Reserved (1 octet) | + +--------------------------------------------------+ + | Subsequent Address Family Identifier (1 octet) | + +--------------------------------------------------+ + | Number of ORFs (1 octet) | + +--------------------------------------------------+ + | ORF Type (1 octet) | + +--------------------------------------------------+ + | Send/Receive (1 octet) | + +--------------------------------------------------+ + | ... | + +--------------------------------------------------+ + | ORF Type (1 octet) | + +--------------------------------------------------+ + | Send/Receive (1 octet) | + +--------------------------------------------------+ + + Figure 3: Outbound Route Filtering Capability Encoding + + The use and meaning of these fields are as follows: + + Address Family Identifier (AFI): + + This field is the same as the one used in [BGP-MP]. + + Subsequent Address Family Identifier (SAFI): + + This field is the same as the one used in [BGP-MP]. + + + + +Chen & Rekhter Standards Track [Page 6] + +RFC 5291 ORF Capability for BGP-4 August 2008 + + + Number of ORF Types: + + This field contains the number of Filter Types to be listed in + the following fields. + + ORF Type: + + This field contains the value of an ORF Type. + + Send/Receive: + + This field indicates whether the sender is (a) willing to + receive ORF entries from its peer (value 1), (b) would like to + send ORF entries to its peer (value 2), or (c) both (value 3) + for the ORF Type. + +6. Operation + + A BGP speaker that is willing to receive ORF entries from its peer, + or would like to send ORF entries to its peer SHOULD advertise the + Outbound Route Filtering Capability to the peer using BGP + Capabilities advertisement [BGP-CAP]. + + A BGP speaker that implements the Outbound Route Filtering Capability + MUST support the BGP ROUTE-REFRESH message, as defined in [BGP-RR]. + A BGP speaker that advertises the Outbound Route Filtering Capability + to a peer using BGP Capabilities advertisement [BGP-CAP] does not + have to advertise the BGP Route Refresh Capability to that peer. + + Consider a BGP speaker that advertises the Outbound Route Filtering + Capability indicating its willingness to receive a particular set of + from its peer, and that receives the Outbound + Route Filtering Capability indicating the desire of the peer to send + a particular set to the speaker. If for a given + AFI/SAFI the intersection between these two sets is non-empty, the + speaker SHOULD NOT advertise to the peer any routes with that + AFI/SAFI prior to receiving from the peer any ROUTE-REFRESH message + carrying that AFI/SAFI, where the message could be either without any + ORF entries, or with one or more ORF entry and the When-to-refresh + field set to IMMEDIATE. If, on the other hand, for a given AFI/SAFI + the intersection between these two sets is empty, the speaker MUST + follow normal BGP procedures. + + A BGP speaker may send a ROUTE-REFRESH message with one or more ORF + entries to its peer only if the peer advertises to the speaker the + Outbound Route Filtering Capability indicating its willingness to + receive ORF entries from the speaker, and the speaker advertises to + the peer the Outbound Route Filtering Capability indicating its + + + +Chen & Rekhter Standards Track [Page 7] + +RFC 5291 ORF Capability for BGP-4 August 2008 + + + desire to send ORF entries to the peer. The message may contain only + ORF entries of that the peer is willing to + receive, as advertised to the speaker in the Outbound Route Filtering + Capability. + + When a BGP speaker receives a ROUTE-REFRESH message with one or more + ORF entries from its peer, then the speaker performs the following + actions. If an carried by the message does not + match that the speaker is willing to receive + from the peer (as advertised to the peer in the Outbound Route + Filtering Capability), the specified ORF entries in the message are + ignored. Otherwise, the speaker modifies the specified ORF + previously received, according to the ORF entries carried in the + message. If any of the fields of an ORF entry in the message + contains an unrecognized value, the whole specified ORF previously + received is removed. + + If the Action component of an ORF entry is REMOVE, but the ORF + previously received does not contain the specified entry, the ORF + entry in the message is ignored. + + ORF entries with either REMOVE or REMOVE-ALL cannot remove locally + configured outbound route filters. + + If the When-to-refresh indicates IMMEDIATE, then after processing all + the ORF entries carried in the message the speaker re-advertises to + the peer routes from the Adj-RIB-Out associated with the peer that + have the same AFI/SAFI as what is carried in the message, and taking + into account all the ORF entries for that AFI/SAFI received from the + peer. The speaker MUST re-advertise all the routes that have been + affected by the ORF entries carried in the message, but MAY also re- + advertise the routes that have not been affected by the ORF entries + carried in the message. + + If the When-to-refresh indicates DEFER, then after processing all the + ORF entries carried in the message the speaker defers re- + advertisement to the peer routes from the Adj-RIB-Out associated with + the peer that have the same AFI/SAFI as what is carried in the + message, and taking into account all the ORF entries received from + the peer until the speaker receives a subsequent ROUTE-REFRESH + message for the same AFI/SAFI either without any ORF entries, or with + one or more ORF entries and When-to-refresh set to IMMEDIATE. + + If the speaker receives from the peer a ROUTE-REFRESH message without + any ORF entries, then the speaker sends to the peer all routes from + the Adj-RIB-Out associated with the peer whose AFI/SAFI is the same + as what is carried in the message and taking into account the ORFs + (if any) previously received from the peer. + + + +Chen & Rekhter Standards Track [Page 8] + +RFC 5291 ORF Capability for BGP-4 August 2008 + + + The set of ORF entries that the speaker sends to the peer expresses + the speaker's local preference, that the peer may or may not decide + to honor. + + During a single BGP session, the speaker MAY pass multiple ORF + entries to the peer. + + After a BGP speaker makes changes to the ORF entries previously sent + to a peer, the speaker MUST send to the peer the updated ORF entries + with either (a) When-to-refresh set to IMMEDIATE, or (b) When-to- + refresh set to DEFER followed by a plain ROUTE-REFRESH message. The + latter MUST be used by the speaker when there are other policy + changes (in addition to the ORF entries) that require the peer to + re-advertise all the routes. + + The lifetime of an ORF is the duration of the BGP session during + which the ORF is exchanged. + + An ORF is removed when the last ORF entry is removed (either via + REMOVE-ALL, or via a sequence of REMOVE). + + If a particular route maintained by a BGP speaker does not match any + of the ORF entries of any of the (non-empty) ORFs associated with a + particular peer, then this route SHOULD NOT be advertised to the + peer. + + If a BGP speaker maintains multiple ORFs of different ORF-Types for a + particular peer, then the decision by the speaker to advertise a + route to the peer is determined by passing the route through each + such ORF, and combining the results (combining of PERMIT and DENY + results in DENY). + +7. IANA Considerations + + This document defines a new BGP Capability - Outbound Route Filtering + Capability. The Capability Code for the Outbound Route Filtering + Capability is 3. + + As specified in this document, an ORF entry contains the ORF-Type + field for which IANA has created and now maintains a registry + entitled "BGP Outbound Route Filtering (ORF) Types". + + + + + + + + + + +Chen & Rekhter Standards Track [Page 9] + +RFC 5291 ORF Capability for BGP-4 August 2008 + + + IANA maintains and registers values for ORF-Type field as follows: + + - ORF-Type value 0 is reserved. + + - ORF-Type values 1 through 63 are to be assigned by IANA using + either the Standards Action process defined in RFC 5226 + [RFC5226], or the Early IANA Allocation process defined in RFC + 4020 [RFC4020]. + + - ORF-Type values 64 through 127 are to be assigned by IANA, using + the "First Come First Served" policy defined in RFC 5226 + [RFC5226]. + + - ORF-Type values 128 through 255 are vendor-specific, and values + in this range are not to be assigned by IANA. + +8. Manageability Considerations + + The management objects for BGP ORFs will be defined separately, + outside this document. However, it is suggested that the following + management objects be defined: + + The ORF Capability object, which describes the ORF Capability + exchanged over a BGP session, should include the ORF types and the + Send/Receive values advertised and received for a BGP peer. + + The ORF entry object should contain the ORF entries of each ORF sent + and received for a BGP peer. + +9. Security Considerations + + This extension to BGP does not change the underlying security issues + [BGP-4]. + +10. Acknowledgments + + Some of the material in the document is adapted from a proposal for + selective updates by Yakov Rekhter, Kannan Varadhan, and Curtis + Villamizar. + +11. Normative References + + [BGP-4] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border + Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. + + [BGP-MP] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, + "Multiprotocol Extensions for BGP-4", RFC 4760, January + 2007. + + + +Chen & Rekhter Standards Track [Page 10] + +RFC 5291 ORF Capability for BGP-4 August 2008 + + + [BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement + with BGP-4", RFC 3392, November 2002. + + [BGP-RR] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, + September 2000. + + [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 + + Enke Chen + Cisco Systems, Inc. + 170 W. Tasman Dr. + San Jose, CA 95134 + + Email: enkechen@cisco.com + + + Yakov Rekhter + Juniper Networks + 1194 N. Mathilda Ave + Sunnyvale, CA 94089 + + Email: yakov@juniper.net + + + + + + + + + + + + + + + + + + +Chen & Rekhter Standards Track [Page 11] + +RFC 5291 ORF Capability for BGP-4 August 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + 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. + + 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, THE IETF TRUST 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. + +Intellectual Property + + 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. + + + + + + + + + + + + +Chen & Rekhter Standards Track [Page 12] + -- cgit v1.2.3