draft-ietf-idr-route-filter-02.txt   draft-ietf-idr-route-filter-03.txt 
Network Working Group Enke Chen Network Working Group Enke Chen
Internet Draft Redback Networks, Inc. Internet Draft Redback Networks, Inc.
Expiration Date: May 2001 Yakov Rekhter Expiration Date: October 2001 Yakov Rekhter
Cisco Systems Juniper Networks
Cooperative Route Filtering Capability for BGP-4 Cooperative Route Filtering Capability for BGP-4
draft-ietf-idr-route-filter-02.txt draft-ietf-idr-route-filter-03.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 list>. "Scope" indicates the set of routes that <Scope, Communities>. "Scope" indicates the set of routes that must
must be considered by the remote peer for the given ORF request. be considered by the remote peer for the given ORF request. Scope can
Scope can be one of the EXACT or NORMAL. EXACT scope indicates that be one of the EXACT or NORMAL. EXACT scope indicates that the remote
the remote peer should consider only those routes whose Communities peer should consider only those routes whose Communities attribute is
attribute is equal to the Communities list specified in the ORF. equal to the Communities list specified in the ORF. NORMAL scope
NORMAL scope indicates that the remote peer should consider only indicates that the remote peer should consider only those routes
those routes whose Communities attribute has at least one Community whose Communities attribute either is equal to the Communities list
in common with the Communities list specified in the ORF. specified in the ORF, or exhibit a subset relation with the
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 list>. "Scope" indicates the consists of <Scope, Extended Communities>. "Scope" indicates the set
set of routes that must be considered by the remote peer for the of routes that must be considered by the remote peer for the given
given ORF request. Scope can be one of the EXACT or NORMAL. EXACT ORF request. Scope can be one of the EXACT or NORMAL. EXACT scope
scope indicates that the remote peer should consider only those indicates that the remote peer should consider only those routes
routes whose Extended Communities attribute is equal to the Extended 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 has at least one Extended Community in common Communities attribute either is equal to the Extended Communities
with the Extended Communities list specified in the ORF. list specified in the ORF, or exhibit a subset relation with the
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, is to ask the peer to defer refreshing of all the routes until it
including the newly arrived routes, until it receives a subsequent receives a subsequent ROUTE-REFRESH message for the same AFI/SAFI
ROUTE-REFRESH message for the same AFI/SAFI either without any ORF either without any ORF entries, or with one or more ORF entries
entries, or with one or more ORF entries and When-to-refresh set and When-to-refresh set to IMMEDIATE.
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 6, line 4 skipping to change at page 5, line 49
+---------------------------------+ +---------------------------------+
| Action (2 bit) | | Action (2 bit) |
+---------------------------------+ +---------------------------------+
| Match (1 bit) | | Match (1 bit) |
+---------------------------------+ +---------------------------------+
| Reserved (5 bits) | | Reserved (5 bits) |
+---------------------------------+ +---------------------------------+
| Type specific part (variable) | | Type specific part (variable) |
+---------------------------------+ +---------------------------------+
Fig 2. ORF entry encoding
Fig 2. ORF entry encoding
When the Action component of an ORF entry specifies REMOVE-ALL, When the Action component of an ORF entry specifies REMOVE-ALL,
the entry consists of only the common part. the entry consists of only the common part.
5.1. Type specific encoding (Communities ORF-Type) 5.1. Type specific encoding (Communities ORF-Type)
The value of the ORF-Type for the Communities ORF-Type is 2. The value of the ORF-Type for the Communities ORF-Type is 2.
The type-specific part of Communities ORF-Type consists of <Scope, The type-specific part of Communities ORF-Type consists of <Scope,
Communities>, and is encoded as follows: Communities>, and is encoded as follows:
skipping to change at page 10, line 36 skipping to change at page 10, line 25
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
4)", RFC 1771, March 1995. (BGP-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
BGP-4", RFC2842, May 2000 BGP-4", RFC2842, May 2000
[BGP-COMMUNITIES] Chandra, R., Traina, P., and Li, T., "BGP [BGP-COMMUNITIES] Chandra, R., Traina, P., and Li, T., "BGP
Communities Attribute", RFC1997, August 1996. Communities Attribute", RFC1997, August 1996.
skipping to change at page 11, line 34 skipping to change at page 11, line 14
12. Author Information 12. Author Information
Enke Chen Enke Chen
Redback Networks, Inc. Redback Networks, Inc.
350 Holger Way 350 Holger Way
San Jose, CA 95134 San Jose, CA 95134
e-mail: enke@redback.com e-mail: enke@redback.com
Yakov Rekhter Yakov Rekhter
Cisco Systems, Inc. Juniper Networks
170 West Tasman Drive e-mail: yakov@juniper.net
San Jose, CA 95134
e-mail: yakov@cisco.com
 End of changes. 

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