draft-ietf-idr-route-filter-01.txt   draft-ietf-idr-route-filter-02.txt 
Network Working Group Enke Chen Network Working Group Enke Chen
Internet Draft Redback Networks, Inc. Internet Draft Redback Networks, Inc.
Expiration Date: April 2001 Yakov Rekhter Expiration Date: May 2001 Yakov Rekhter
Cisco Systems Cisco Systems
Cooperative Route Filtering Capability for BGP-4 Cooperative Route Filtering Capability for BGP-4
draft-ietf-idr-route-filter-01.txt draft-ietf-idr-route-filter-02.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted. produce derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
skipping to change at page 3, line 12 skipping to change at page 3, line 12
match the ORF entry. The semantics of DENY is to ask the peer not to 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. pass updates for the set of routes that match the ORF entry.
4.1. Communities ORF-Type 4.1. Communities ORF-Type
The Community ORF-Type allows to express ORFs in terms of BGP The Community ORF-Type allows to express ORFs in terms of BGP
Communities [BGP-COMMUNITIES]. That is, the Communities ORF-Type Communities [BGP-COMMUNITIES]. That is, the Communities ORF-Type
provides Communities-based route filtering. provides Communities-based route filtering.
Conceptually the ORF-value of the Communities ORF-Type consists of Conceptually the ORF-value of the Communities ORF-Type consists of
<Scope, Communities>. "Scope" indicates the set of routes that must <Scope, Communities list>. "Scope" indicates the set of routes that
be considered by the remote peer for the given ORF request. Scope can must be considered by the remote peer for the given ORF request.
be one of the EXACT or NORMAL. EXACT scope indicates that the remote Scope can be one of the EXACT or NORMAL. EXACT scope indicates that
peer should consider only those routes whose Communities attribute is the remote peer should consider only those routes whose Communities
equal to the Communities list specified in the ORF. NORMAL scope attribute is equal to the Communities list specified in the ORF.
indicates that the remote peer should consider only those routes NORMAL scope indicates that the remote peer should consider only
whose Communities attribute either is equal to the Communities list those routes whose Communities attribute has at least one Community
specified in the ORF, or exhibit a subset relation with the in common with the Communities list specified in the ORF.
Communities list specified in the ORF.
The Communities list is a list of BGP Communities. The Communities list is a list of BGP Communities.
4.2. Extended Communities ORF-Type 4.2. Extended Communities ORF-Type
The Extended Community ORF-Type allows to express ORFs in terms of The Extended Community ORF-Type allows to express ORFs in terms of
BGP Extended Communities [BGP-EXT-COMMUNITIES]. That is, the Extended BGP Extended Communities [BGP-EXT-COMMUNITIES]. That is, the Extended
Communities ORF-Type provides Extended Communities-based route Communities ORF-Type provides Extended Communities-based route
filtering. filtering.
Conceptually the ORF-value of the Extended Communities ORF-Type Conceptually the ORF-value of the Extended Communities ORF-Type
consists of <Scope, Extended Communities>. "Scope" indicates the set consists of <Scope, Extended Communities list>. "Scope" indicates the
of routes that must be considered by the remote peer for the given set of routes that must be considered by the remote peer for the
ORF request. Scope can be one of the EXACT or NORMAL. EXACT scope given ORF request. Scope can be one of the EXACT or NORMAL. EXACT
indicates that the remote peer should consider only those routes scope indicates that the remote peer should consider only those
whose Extended Communities attribute is equal to the Extended routes whose Extended Communities attribute is equal to the Extended
Communities list specified in the ORF. NORMAL scope indicates that Communities list specified in the ORF. NORMAL scope indicates that
the remote peer should consider only those routes whose Extended the remote peer should consider only those routes whose Extended
Communities attribute either is equal to the Extended Communities Communities attribute has at least one Extended Community in common
list specified in the ORF, or exhibit a subset relation with the with the Extended Communities list specified in the ORF.
Extended Communities list specified in the ORF.
The Extended Communities list is a list of BGP Extended Communities. The Extended Communities list is a list of BGP Extended Communities.
5. Carrying ORF entries in BGP 5. Carrying ORF entries in BGP
ORF entries are carried in the BGP ROUTE-REFRESH message [BGP-RR]. A ORF entries are carried in the BGP ROUTE-REFRESH message [BGP-RR]. A
single ROUTE-REFRESH message could carry multiple ORF entries, as single ROUTE-REFRESH message could carry multiple ORF entries, as
long as all these entries share the same AFI/SAFI. long as all these entries share the same AFI/SAFI.
From the encoding point of view each ORF entry consists of a common From the encoding point of view each ORF entry consists of a common
skipping to change at page 4, line 25 skipping to change at page 4, line 25
is encoded as follows: is encoded as follows:
The AFI/SAFI component of an ORF entry is encoded in the AFI/SAFI The AFI/SAFI component of an ORF entry is encoded in the AFI/SAFI
field of the ROUTE-REFRESH message. field of the ROUTE-REFRESH message.
Following the AFI/SAFI component is the one-octet When-to-refresh Following the AFI/SAFI component is the one-octet When-to-refresh
field. The value of this field can be one of IMMEDIATE (0x01) or field. The value of this field can be one of IMMEDIATE (0x01) or
DEFER (0x02). The semantics of IMMEDIATE is to ask the peer to DEFER (0x02). The semantics of IMMEDIATE is to ask the peer to
refresh the routes for the AFI/SAFI carried in the message refresh the routes for the AFI/SAFI carried in the message
immediately after processing the message. The semantics of DEFER immediately after processing the message. The semantics of DEFER
is to ask the peer to defer refreshing of all the routes until it is to ask the peer to defer refreshing of all the routes,
receives a subsequent ROUTE-REFRESH message for the same AFI/SAFI including the newly arrived routes, until it receives a subsequent
either without any ORF entries, or with one or more ORF entries ROUTE-REFRESH message for the same AFI/SAFI either without any ORF
and When-to-refresh set to IMMEDIATE. entries, or with one or more ORF entries and When-to-refresh set
to IMMEDIATE.
Following the When-to-refresh field is a collection of one or more Following the When-to-refresh field is a collection of one or more
ORFs, grouped by ORF-Type. ORFs, grouped by ORF-Type.
The ORF-Type component is encoded as a one-octet field. The ORF-Type component is encoded as a one-octet field.
The Length of ORFs component is a two-octets field that contains The Length of ORFs component is a two-octets field that contains
the length (in octets) of the ORF entries that follows. the length (in octets) of the ORF entries that follows.
+--------------------------------------------------+ +--------------------------------------------------+
skipping to change at page 10, line 24 skipping to change at page 10, line 35
9. Security Considerations 9. Security Considerations
This extension to BGP does not change the underlying security issues. This extension to BGP does not change the underlying security issues.
10. Acknowledgements 10. Acknowledgements
Some of the material in the document is "borrowed" from a proposal Some of the material in the document is "borrowed" from a proposal
for selective updates by Yakov Rekhter, Kannan Varadhan, and Curtis for selective updates by Yakov Rekhter, Kannan Varadhan, and Curtis
Villamizar. Villamizar.
We express our thanks to John Scudder for his comments.
11. References 11. References
[BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP- [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-
4)", RFC 1771, March 1995. 4)", RFC 1771, March 1995.
[BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y., [BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y.,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000
[BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/