draft-ietf-idr-route-filter-07.txt   draft-ietf-idr-route-filter-08.txt 
Network Working Group Enke Chen Network Working Group Enke Chen
Internet Draft Redback Networks, Inc. Internet Draft Redback Networks, Inc.
Expiration Date: June 2003 Yakov Rekhter Expiration Date: July 2003 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-07.txt draft-ietf-idr-route-filter-08.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 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
2. Abstract 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 RFC2119 [RFC2119].
3. Abstract
This document defines a BGP-based mechanism that allows a BGP speaker This document defines a BGP-based mechanism that allows a BGP speaker
to send to its BGP peer a set of route filters that the peer would to send to its BGP peer a set of route filters that the peer would
use to constrain/filter its outbound routing updates to the speaker. use to constrain/filter its outbound routing updates to the speaker.
3. Introduction 4. Introduction
Currently it is not uncommon for a BGP speaker to receive, and then Currently it is not uncommon for a BGP speaker to receive, and then
filter out some unwanted routes from its peers based on its local filter out some unwanted routes from its peers based on its local
routing policy. Since the generation and transmission of routing routing policy. Since the generation and transmission of routing
updates by the sender, as well as the processing of routing updates updates by the sender, as well as the processing of routing updates
by the receiver consume resources, it may be beneficial if the by the receiver consume resources, it may be beneficial if the
generation of such unwanted routing updates can be avoided in the generation of such unwanted routing updates can be avoided in the
first place. first place.
This document defines a BGP-based mechanism that allows a BGP speaker 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 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 peer would then apply these filters, in addition to its locally
configured outbound filters (if any), to constrain/filter its configured outbound filters (if any), to constrain/filter its
outbound routing updates to the speaker. outbound routing updates to the speaker.
4. Outbound Route Filter (ORF) 5. Outbound Route Filter (ORF)
Conceptually an ORF entry is a tuple of the form <AFI/SAFI, ORF-Type, Conceptually an ORF entry is a tuple of the form <AFI/SAFI, ORF-Type,
Action, Match, ORF-value>; an ORF consists of one or more ORF entries Action, Match, ORF-value>; an ORF consists of one or more ORF entries
that have a common AFI/SAFI and ORF-Type. An ORF is identified by that have a common AFI/SAFI and ORF-Type. An ORF is identified by
<AFI/SAFI, ORF-Type>. <AFI/SAFI, ORF-Type>.
The "AFI/SAFI" component provides a coarse granularity control by The "AFI/SAFI" component provides a coarse granularity control by
limiting the ORF to only the routes whose NLRI matches the "AFI/SAFI" limiting the ORF to only the routes whose NLRI matches the "AFI/SAFI"
component of the ORF. component of the ORF.
The "ORF-Type" component determines the content of the ORF-value. The "ORF-Type" component determines the content of the ORF-value.
The "Action" component controls handling of the ORF Request by the The "Action" component controls handling of the ORF Request by the
remote peer. Action can be one of ADD, REMOVE, REMOVE-ALL. ADD adds 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 an ORF entry to the ORF on the remote peer; REMOVE deletes a
previously installed ORF entry on the remote peer; REMOVE-ALL deletes previously installed ORF entry on the remote peer; REMOVE-ALL deletes
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 can be one of PERMIT or DENY. The semantics of The "Match" component is used if support matching granularity on a
PERMIT is to ask the peer to pass updates for the set of routes that per ORF entry basis is needed, in which case the "Match" component
match the ORF entry. The semantics of DENY is to ask the peer not to can be one of PERMIT or DENY. The semantics of PERMIT is to ask the
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.
4.1. Communities ORF-Type The semantics of DENY is to ask the peer not to pass updates for the
set of routes that match the ORF entry.
5.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 a
<Scope, Communities>. "Scope" indicates the set of routes that must single Community.
be considered by the remote peer for the given ORF request. Scope can
be one of the EXACT or NORMAL. EXACT scope indicates that the remote
peer should consider only those routes whose Communities attribute is
equal to the Communities list specified in the ORF. NORMAL scope
indicates that the remote peer should consider only those routes
whose Communities attribute either is equal to the Communities list
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 sender SHOULD set the value of the Match field to PERMIT; the
receiver SHOULD ignore the value of the Match field.
4.2. Extended Communities ORF-Type 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.
5.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 a single Extended Community.
of routes that must be considered by the remote peer for the given
ORF request. Scope can be one of the EXACT or NORMAL. EXACT scope
indicates that the remote peer should consider only those routes
whose Extended Communities attribute is equal to the Extended
Communities list specified in the ORF. NORMAL scope indicates that
the remote peer should consider only those routes whose Extended
Communities attribute either is equal to the Extended Communities
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 sender SHOULD set the value of the Match field to PERMIT; the
receiver SHOULD ignore the value of the Match field.
5. Carrying ORF entries in BGP 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.
6. 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 page 4, line 27 skipping to change at page 4, line 27
part and type-specific part. part and type-specific part.
The common part consists of <AFI/SAFI, ORF-Type, Action, Match>, and The common part consists of <AFI/SAFI, ORF-Type, Action, Match>, and
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 and DEFER are discussed
refresh the routes for the AFI/SAFI carried in the message in the "Operation" section of this document.
immediately after processing the message. The semantics of DEFER
is to ask the peer to defer refreshing of all the routes until it
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.
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 8 skipping to change at page 6, line 4
+---------------------------------+ +---------------------------------+
| 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) 6.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 single
Communities>, and is encoded as follows: Community encoded as a four-octets field.
Scope is a one-octet field. The EXACT Scope has the value of 1.
The NORMAL Scope has the value of 2.
Communities are encoded as a one octet Number of Communities
field, followed by one or more Communities, where each Community
is encoded as a four-octets field.
5.2. Type specific encoding (Extended Communities ORF-Type) 6.2. Type specific encoding (Extended Communities ORF-Type)
The value of the ORF-Type for the Extended Communities ORF-Type is 3. 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 The type-specific part of Extended Communities ORF-Type consists of a
<Scope, Extended Communities>, and is encoded as follows: single Extended Community encoded as an eight-octets field.
Scope is a one-octet field. The EXACT Scope has the value of 1.
The NORMAL Scope has the value of 2.
Extended Communities are encoded as a one octet Number of Extended
Communities field, followed by one or more Extended Communities,
where each Extended Community is encoded as a eight-octets field.
6. Cooperative Route Filtering Capability 7. 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:
Capability code: 3 Capability code: 3
skipping to change at page 8, line 27 skipping to change at page 8, line 5
This field contains the value of an ORF Type. This field contains the value of an ORF Type.
Send/Receive: Send/Receive:
This field indicates whether the sender is (a) willing to This field indicates whether the sender is (a) willing to
receive ORF entries from its peer (value 1), (b) would like 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) send ORF entries to its peer (value 2), or (c) both (value 3)
for the ORF Type that follows. for the ORF Type that follows.
7. Operation 8. Operation
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 would like to send ORF entries to its peer should advertise the or would like to send ORF entries to its peer SHOULD advertise the
Cooperative Route Filtering Capability to the peer using BGP Cooperative Route Filtering Capability to the peer using BGP
Capabilities advertisement [BGP-CAP]. Capabilities advertisement [BGP-CAP].
A BGP speaker that implements the Cooperative Route Filtering A BGP speaker that implements the Cooperative Route Filtering
Capability must support BGP ROUTE-REFRESH message, as defined in Capability must support BGP ROUTE-REFRESH message, as defined in
[BGP-RR]. A BGP speaker that advertises the Cooperative Route [BGP-RR]. A BGP speaker that advertises the Cooperative Route
Filtering Capability to a peer using BGP Capabilities advertisement Filtering Capability to a peer using BGP Capabilities advertisement
[BGP-CAP] doesn't have to advertise the BGP Route Refresh capability [BGP-CAP] doesn't have to advertise the BGP Route Refresh capability
to that peer. to that peer.
Consider a BGP speaker that advertises the Cooperative Route Consider a BGP speaker that advertises the Cooperative Route
Filtering Capability indicating its willingness to receive a Filtering Capability indicating its willingness to receive a
particular set of <AFI, SAFI, ORF-Type> from its peer, and that particular set of <AFI, SAFI, ORF-Type> from its peer, and that
receives the Cooperative Route Filtering Capability indicating the receives the Cooperative Route Filtering Capability indicating the
desire of the peer to send a particular set <AFI, SAFI, ORF-Type> to desire of the peer to send a particular set <AFI, SAFI, ORF-Type> to
the speaker. If for a given <AFI, SAFI> the intersection between the speaker. If for a given <AFI, SAFI> the intersection between
these two sets are not-empty, the speaker should not advertise to the these two sets are not-empty, the speaker SHOULD NOT advertise to the
peer any routes with that <AFI, SAFI> prior to receiving from the peer any routes with that <AFI, SAFI> prior to receiving from the
peer any ROUTE-REFRESH message carrying that <AFI, SAFI>, where 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 message could be either without any ORF entries, or with one or more
ORF entry and When-to-refresh field set to IMMEDIATE. If, on the ORF entry and When-to-refresh field set to IMMEDIATE. If, on the
other hand, for a given <AFI, SAFI> the intersection between these other hand, for a given <AFI, SAFI> the intersection between these
two sets is empty, the speaker should follow normal BGP procedures. two sets is empty, the speaker SHOULD follow normal BGP procedures.
A BGP speaker may send a ROUTE-REFRESH message with one or more ORF 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 entries to its peer only if the peer advertises to the speaker the
Cooperative Route Filtering Capability indicating its willingness to Cooperative Route Filtering Capability indicating its willingness to
receive ORF entries from the speaker, and the speaker advertises to receive ORF entries from the speaker, and the speaker advertises to
the peer the Cooperative Route Filtering Capability indicating its the peer the Cooperative Route Filtering Capability indicating its
desire to send ORF entries to the peer. The message may contain only desire to send ORF entries to the peer. The message may contain only
ORF entries of <AFI, SAFI, ORF-type> that the peer is willing to ORF entries of <AFI, SAFI, ORF-type> that the peer is willing to
receive, as advertised to the speaker in the Cooperative Route receive, as advertised to the speaker in the Cooperative Route
Filtering Capability. Filtering Capability.
skipping to change at page 9, line 35 skipping to change at page 9, line 12
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 should re- the ORF entries carried in the message the speaker re-advertises to
advertise to the peer routes from the Adj-RIB-Out that have the same the peer routes from the Adj-RIB-Out associated with the peer that
AFI/SAFI as what is carried in the message, and taking into account have the same AFI/SAFI as what is carried in the message, and taking
all the ORF entries received from the peer. into account all the ORF entries received from the peer. However,
the routes that have not be affected by the ORF entries carried in
the message SHOULT NOT be re-advertised to the peer.
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 ORF
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.
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).
8. IANA Considerations 9. IANA Considerations
As specified in this document, an ORF enty contains the ORF-Type As specified in this document, an ORF enty contains the ORF-Type
field. ORF-Type value 0 is reserved. ORF-Type values 1 through 63 field. ORF-Type value 0 is reserved. ORF-Type values 1 through 63
are to be assigned by IANA using the "IETF Consensus" policy defined are to be assigned by IANA using the "IETF Consensus" policy defined
in RFC2434. ORF-Type values 64 through 127 are to be assigned by 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, using the "First Come First Served" policy defined in RFC2434.
ORF-Type values 128 through 255 are vendor-specific, and values in ORF-Type values 128 through 255 are vendor-specific, and values in
this range are not to be assigned by IANA. this range are not to be assigned by IANA.
9. Security Considerations 10. 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 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.
11. 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)", 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.
[BGP-EXT-COMMUNITIES] Ramachandra, S., Tappan, D., "BGP Extended [BGP-EXT-COMMUNITIES] Ramachandra, S., Tappan, D., "BGP Extended
Communities Attribute", draft-ramachandra-bgp-ext-communities-02.txt Communities Attribute", draft-ramachandra-bgp-ext-communities-02.txt
[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
Requirement Levels", BCP 14, RFC 2119, March 1997.
12. Author Information 13. 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
Juniper Networks Juniper Networks
e-mail: yakov@juniper.net e-mail: yakov@juniper.net
 End of changes. 

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