draft-ietf-idr-route-filter-13.txt   draft-ietf-idr-route-filter-14.txt 
Network Working Group Enke Chen Network Working Group Enke Chen
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expiration Date: September 2006 Yakov Rekhter Expiration Date: December 2006 Yakov Rekhter
Juniper Networks Juniper Networks
Cooperative Route Filtering Capability for BGP-4 Cooperative Route Filtering Capability for BGP-4
draft-ietf-idr-route-filter-13.txt draft-ietf-idr-route-filter-14.txt
Status of this Memo Status of this Memo
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-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at line 91 skipping to change at line 91
the previously installed entries in the specified ORF on the remote the previously installed entries in the specified ORF on the remote
peer. peer.
The "Match" component is used if support matching granularity on a The "Match" component is used if support matching granularity on a
per ORF entry basis is needed, in which case the "Match" component per ORF entry basis is needed, in which case the "Match" component
can be one of PERMIT or DENY. The semantics of PERMIT is to ask the can be one of 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. 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 The semantics of DENY is to ask the peer not to pass updates for the
set of routes that match the ORF entry. set of routes that match the ORF entry.
3.1. Communities ORF-Type
The Community ORF-Type allows to express ORFs in terms of BGP
Communities [BGP-COMMUNITIES]. That is, the Communities ORF-Type
provides Communities-based route filtering.
Conceptually the ORF-value of the Communities ORF-Type consists of a
single Community.
The sender SHOULD set the value of the Match field to PERMIT; the
receiver SHOULD ignore the value of the Match field.
The remote peer should consider only those routes whose Communities
attribute has at least one Community in common with the Communities
list specified in the ORF.
3.2. Extended Communities ORF-Type
The Extended Community ORF-Type allows to express ORFs in terms of
BGP Extended Communities [BGP-EXT-COMMUNITIES]. That is, the Extended
Communities ORF-Type provides Extended Communities-based route
filtering.
Conceptually the ORF-value of the Extended Communities ORF-Type
consists of a single Extended Community.
The sender SHOULD set the value of the Match field to PERMIT; the
receiver SHOULD ignore the value of the Match field.
The remote peer should consider only those routes whose Extended
Communities attribute has at least one Extended Community in common
with the Extended Communities list specified in the ORF.
4. Carrying ORF entries in BGP 4. Carrying ORF entries in BGP
ORF entries are carried in the BGP ROUTE-REFRESH message [BGP-RR]. ORF entries are carried in the BGP ROUTE-REFRESH message [BGP-RR].
A BGP speaker can distinguish an incoming ROUTE-REFRESH message that A BGP speaker can distinguish an incoming ROUTE-REFRESH message that
carries one or more ORF entries from an incoming plain ROUTE-REFRESH carries one or more ORF entries from an incoming plain ROUTE-REFRESH
message by using the Message Length field in the BGP message header. message by using the Message Length field in the BGP message header.
A single ROUTE-REFRESH message could carry multiple ORF entries, as A 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.
skipping to change at line 223 skipping to change at line 190
| 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.
4.1. Type specific encoding (Communities ORF-Type)
The value of the ORF-Type for the Communities ORF-Type is 2.
The type-specific part of Communities ORF-Type consists of single
Community encoded as a four-octets field.
4.2. Type specific encoding (Extended Communities ORF-Type)
The value of the ORF-Type for the Extended Communities ORF-Type is 3.
The type-specific part of Extended Communities ORF-Type consists of a
single Extended Community encoded as an eight-octets field.
5. Cooperative Route Filtering Capability 5. Cooperative Route Filtering Capability
A BGP speaker that is willing to receive ORF entries from its peer, 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 or a BGP speaker that would like to send ORF entries to its peer
advertises this to the peer by using the Cooperative Route Filtering advertises this to the peer by using the Cooperative Route Filtering
Capability, as described below. Capability, as described below.
The Cooperative Route Filtering Capability is a new BGP capability The Cooperative Route Filtering Capability is a new BGP capability
[BGP-CAP] defined as follows: [BGP-CAP] defined as follows:
skipping to change at line 360 skipping to change at line 313
speaker modifies the specified ORF, as specified in the ORF entries speaker modifies the specified ORF, as specified in the ORF entries
carried by the message. If any of the fields within an ORF entry carried by the message. If any of the fields within an ORF entry
contain an unrecognized value, the whole specified ORF is removed. contain an unrecognized value, the whole specified ORF is removed.
If the Action component of an ORF entry is REMOVE, but the ORF If the Action component of an ORF entry is REMOVE, but the ORF
doesn't contain the specified entry, the entry is ignored. doesn't contain the specified entry, the entry is ignored.
ORF entries with either REMOVE or REMOVE-ALL can not remove locally ORF entries with either REMOVE or REMOVE-ALL can not remove locally
configured outbound route filters. configured outbound route filters.
If the When-to-Refresh indicates IMMEDIATE, then after processing all If the When-to-refresh indicates IMMEDIATE, then after processing all
the ORF entries carried in the message the speaker re-advertises to 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 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 have the same AFI/SAFI as what is carried in the message, and taking
into account all the ORF entries received from the peer. However, into account all the ORF entries for that AFI/SAFI received from the
the routes that have not be affected by the ORF entries carried in peer. The speaker MUST re-advertise all the routes that have been
the message SHOULT NOT be re-advertised to the peer. 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 If the When-to-refresh indicates DEFER, then after processing all the
ORF entries carried in the message the speaker defers re- ORF entries carried in the message the speaker defers re-
advertisement to the peer routes from the Adj-RIB-Out associated with 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 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 message, and taking into account all the ORF entries received from
the peer until the speaker receives a subsequent ROUTE-REFRESH the peer until the speaker receives a subsequent ROUTE-REFRESH
message for the same AFI/SAFI either without any ORF entries, or with 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. one or more ORF entries and When-to-refresh set to IMMEDIATE.
If the speaker receives from the peer a ROUTE-REFRESH message without 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 any ORF entries, then the speaker sends to the peer all routes from
skipping to change at line 390 skipping to change at line 345
as what is carried in the message and taking into account the ORF as what is carried in the message and taking into account the ORF
received from the peer. received from the peer.
The set of ORF entries that the speaker sends to the peer expresses 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 the speaker's local preference, that the peer may or may not decide
to honor. to honor.
During a single BGP session the speaker may pass multiple ORF entries During a single BGP session the speaker may pass multiple ORF entries
to the peer. to the peer.
After a BGP speaker makes changes to the ORF entries previously sent
to a peer, the speaker SHOULD 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 ROUTE-REFRESH message. The
latter SHALL 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 The lifetime of an ORF is the duration of the BGP session during
which the ORF is exchanged. which the ORF is exchanged.
An ORF is removed when the last ORF entry is remove (either via An ORF is removed when the last ORF entry is remove (either via
REMOVE-ALL, or via a sequence of REMOVE). REMOVE-ALL, or via a sequence of REMOVE).
If a particular route maintained by a BGP speaker doesn't match any If a particular route maintained by a BGP speaker doesn't match any
of the ORF entries of any of the (non-empty) ORFs associated with a 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 particular peer, then this route SHOULD NOT be advertised to the
peer. peer.
If a BGP speaker maintains multiple ORFs of different ORF-Types for a If a BGP speaker maintains multiple ORFs of different ORF-Types for a
particular peer, then the decision by the speaker to advertise a particular peer, then the decision by the speaker to advertise a
route to the peer is determined by passing the route through each route to the peer is determined by passing the route through each
such ORF, and and-ing the results (and-ing of PERMIT and DENY results such ORF, and and-ing the results (and-ing of PERMIT and DENY results
in DENY). in DENY).
7. IANA Considerations 7. IANA Considerations
As specified in this document, an ORF enty contains the ORF-Type As specified in this document, an ORF entry contains the ORF-Type
field. ORF-Type value 0 is reserved. ORF-Type values 1 through 63 field for which IANA is to create and maintain a registry entitled
are to be assigned by IANA using the "IETF Consensus" policy defined "BGP ORF Type".
in RFC2434. ORF-Type values 64 through 127 are to be assigned by
IANA, using the "First Come First Served" policy defined in RFC2434. IANA will maintain and register values for ORF-Type field as follows:
ORF-Type values 128 through 255 are vendor-specific, and values in
this range are not to be assigned by IANA. - ORF-Type value 0 is reserved.
- ORF-Type values 1 through 63 are to be assigne dby IANA using
either the Standards Action process defined in RFC2434, or the
Early IANA Allocation process defined in RFC4020.
- ORF-Type values 64 through 127 are to be assigned by IANA, using
the "First Come First Served" policy defined in RFC2434.
- ORF-Type values 128 through 255 are vendor-specific, and values
in this range are not to be assigned by IANA.
8. Security Considerations 8. Security Considerations
This extension to BGP does not change the underlying security issues. This extension to BGP does not change the underlying security issues.
9. Intellectual Property Considerations 9. Intellectual Property Considerations
This section is taken from Section 5 of RFC 3668. This section is taken from Section 5 of RFC 3668.
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
skipping to change at line 472 skipping to change at line 445
11. Acknowledgements 11. 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.
12. Normative References 12. Normative References
[BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995. (BGP-4)", RFC4271, January 2006.
[BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y., [BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y.,
[BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with "Multiprotocol Extensions for BGP-4", RFC2858, June 2000.
[BGP-COMMUNITIES] Chandra, R., Traina, P., and Li, T., "BGP
Communities Attribute", RFC1997, August 1996.
[BGP-EXT-COMMUNITIES] Ramachandra, S., Tappan, D., "BGP Extended [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with
Communities Attribute", draft-ramachandra-bgp-ext-communities-02.txt BGP-4", RFC3392, November 2002.
[BGP-RR] Chen, E., "Route Refresh Capability for BGP-4", RFC2918, [BGP-RR] Chen, E., "Route Refresh Capability for BGP-4", RFC2918,
September 2000 September 2000.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
13. Author Information 13. Author Information
Enke Chen Enke Chen
Cisco Systems, Inc. Cisco Systems, Inc.
e-mail: enkechen@cisco.com e-mail: enkechen@cisco.com
 End of changes. 13 change blocks. 
68 lines changed or deleted 39 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/