draft-ietf-idr-flow-spec-01.txt   draft-ietf-idr-flow-spec-02.txt 
IDR Working Group P. Marques IDR Working Group P. Marques
Internet-Draft N. Sheth Internet-Draft N. Sheth
Expires: October 4, 2008 R. Raszuk Expires: March 7, 2009 R. Raszuk
Juniper Networks
B. Greene B. Greene
Cisco Systems, Inc. Juniper Networks
J. Mauch J. Mauch
NTT/Verio NTT/Verio
D. McPherson D. McPherson
Arbor Networks Arbor Networks
April 2, 2008 September 3, 2008
Dissemination of flow specification rules Dissemination of flow specification rules
draft-ietf-idr-flow-spec-01 draft-ietf-idr-flow-spec-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 41 skipping to change at page 1, line 40
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.
This Internet-Draft will expire on October 4, 2008. This Internet-Draft will expire on March 7, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines a new BGP NLRI encoding format that can be used This document defines a new BGP NLRI encoding format that can be used
to distribute traffic flow specifications. This allows the routing to distribute traffic flow specifications. This allows the routing
system to propagate information regarding more-specific components of system to propagate information regarding more-specific components of
the traffic aggregate defined by an IP destination prefix. the traffic aggregate defined by an IP destination prefix.
Additionally it defines two applications of that encoding format. Additionally it defines two applications of that encoding format.
One that can be used to automate inter-domain coordination of traffic One that can be used to automate inter-domain coordination of traffic
skipping to change at page 3, line 13 skipping to change at page 3, line 13
administrative processes such as inter-provider peering agreements. administrative processes such as inter-provider peering agreements.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Flow specifications . . . . . . . . . . . . . . . . . . . . . 6 2. Flow specifications . . . . . . . . . . . . . . . . . . . . . 6
3. Dissemination of Information . . . . . . . . . . . . . . . . . 7 3. Dissemination of Information . . . . . . . . . . . . . . . . . 7
4. Traffic filtering . . . . . . . . . . . . . . . . . . . . . . 13 4. Traffic filtering . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Order of traffic filtering rules . . . . . . . . . . . . . 14 4.1. Order of traffic filtering rules . . . . . . . . . . . . . 14
5. Validation procedure . . . . . . . . . . . . . . . . . . . . . 15 5. Validation procedure . . . . . . . . . . . . . . . . . . . . . 15
6. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 16 6. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 17
7. Traffic filtering in RFC2547bis networks . . . . . . . . . . . 18 7. Traffic filtering in RFC2547bis networks . . . . . . . . . . . 19
8. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Security considerations . . . . . . . . . . . . . . . . . . . 20 9. Security considerations . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. Normative References . . . . . . . . . . . . . . . . . . . . . 22 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 12. Normative References . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 27
1. Introduction 1. Introduction
Modern IP routers contain both the capability to forward traffic Modern IP routers contain both the capability to forward traffic
according to aggregate IP prefixes as well as to classify, shape, according to aggregate IP prefixes as well as to classify, shape,
limit filter or redirect packets based on administratively defined limit filter or redirect packets based on administratively defined
policies. policies.
While forwarding information is, typically, dynamically signaled While forwarding information is, typically, dynamically signaled
across the network via routing protocols, there is no agreed upon across the network via routing protocols, there is no agreed upon
skipping to change at page 4, line 25 skipping to change at page 4, line 25
For several applications, it may be necessary to exchange control For several applications, it may be necessary to exchange control
information pertaining to aggregated traffic flow definitions which information pertaining to aggregated traffic flow definitions which
cannot be expressed using destination address prefixes only. cannot be expressed using destination address prefixes only.
An aggregated traffic flow is considered to be an n-tuple consisting An aggregated traffic flow is considered to be an n-tuple consisting
of several matching criteria such as source and destination address of several matching criteria such as source and destination address
prefixes, IP protocol and transport protocol port numbers. prefixes, IP protocol and transport protocol port numbers.
The intention of this document is to define a general procedure to The intention of this document is to define a general procedure to
encode such flow specification rules as a BGP [2] NLRI which can be encode such flow specification rules as a BGP [RFC4271] NLRI which
reused for several different control applications. Additionally, we can be reused for several different control applications.
define the required mechanisms to utilize this definition to the Additionally, we define the required mechanisms to utilize this
problem of immediate concern to the authors: intra and inter provider definition to the problem of immediate concern to the authors: intra
distribution of traffic filtering rules to filter (Distributed) and inter provider distribution of traffic filtering rules to filter
Denial of Service (DoS) attacks. (Distributed) Denial of Service (DoS) attacks.
By expanding routing information with flow specifications, the By expanding routing information with flow specifications, the
routing system can take advantage of the ACL/firewall capabilities in routing system can take advantage of the ACL/firewall capabilities in
the router's forwarding path. Flow specifications can be seen as the router's forwarding path. Flow specifications can be seen as
more specific routing entries to an unicast prefix and are expected more specific routing entries to an unicast prefix and are expected
to depend upon the existing unicast data information. to depend upon the existing unicast data information.
A flow specification received from a external autonomous-system will A flow specification received from a external autonomous-system will
need to be validated against unicast routing before being accepted. need to be validated against unicast routing before being accepted.
If the aggregate traffic flow defined by the unicast destination If the aggregate traffic flow defined by the unicast destination
skipping to change at page 6, line 5 skipping to change at page 5, line 18
reuse both internal route distribution infrastructure (e.g.: route reuse both internal route distribution infrastructure (e.g.: route
reflector or confederation design) and existing external reflector or confederation design) and existing external
relationships (e.g.: inter-domain BGP sessions to a customer relationships (e.g.: inter-domain BGP sessions to a customer
network). network).
While it is certainly possible to address this problem using other While it is certainly possible to address this problem using other
mechanisms, the authors believe that this solution offers the mechanisms, the authors believe that this solution offers the
substantial advantage of being an incremental addition to deployed substantial advantage of being an incremental addition to deployed
mechanisms. mechanisms.
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].
2. Flow specifications 2. Flow specifications
A flow specification is an n-tuple consisting on several matching A flow specification is an n-tuple consisting on several matching
criteria that can be applied to IP traffic. A given IP packet is criteria that can be applied to IP traffic. A given IP packet is
said to match the defined flow if it matches all the specified said to match the defined flow if it matches all the specified
criteria. criteria.
A given flow may be associated with a set of attributes, depending on A given flow may be associated with a set of attributes, depending on
the particular application, such attributes may or may not include the particular application, such attributes may or may not include
reachability information (i.e. NEXT_HOP). Well-known or AS-specific reachability information (i.e. NEXT_HOP). Well-known or AS-specific
community attributes can be used to encode a set of predeterminate community attributes can be used to encode a set of predeterminate
actions. actions.
A particular application is identified by a specific (AFI, SAFI) pair A particular application is identified by a specific (AFI, SAFI) pair
[3] and corresponds to a distinct set of RIBs. Those RIBs should be [RFC4760] and corresponds to a distinct set of RIBs. Those RIBs
treated independently from each other in order to assure non- should be treated independently from each other in order to assure
interference between distinct applications. non-interference between distinct applications.
BGP itself treats the NLRI as an opaque key to an entry in its BGP itself treats the NLRI as an opaque key to an entry in its
databases. Entries that are placed in the Loc-RIB are then databases. Entries that are placed in the Loc-RIB are then
associated with a given set of semantics which is application associated with a given set of semantics which is application
dependent. This is consistent with existing BGP applications. For dependent. This is consistent with existing BGP applications. For
instance IP unicast routing (AFI=1, SAFI=1) and IP multicast reverse- instance IP unicast routing (AFI=1, SAFI=1) and IP multicast reverse-
path information (AFI=1, SAFI=2) are handled by BGP without any path information (AFI=1, SAFI=2) are handled by BGP without any
particular semantics being associated with them until installed in particular semantics being associated with them until installed in
the Loc-RIB. the Loc-RIB.
skipping to change at page 7, line 14 skipping to change at page 7, line 14
3. Dissemination of Information 3. Dissemination of Information
We define a "Flow Specification" NLRI type that may include several We define a "Flow Specification" NLRI type that may include several
components such as destination prefix, source prefix, protocol, components such as destination prefix, source prefix, protocol,
ports, etc. This NLRI is treated as an opaque bit string prefix by ports, etc. This NLRI is treated as an opaque bit string prefix by
BGP. Each bit string identifies a key to a database entry which a BGP. Each bit string identifies a key to a database entry which a
set of attributes can be associated with. set of attributes can be associated with.
This NLRI information is encoded using MP_REACH_NLRI and This NLRI information is encoded using MP_REACH_NLRI and
MP_UNREACH_NLRI attributes as defined in RFC4760 [3]. Whenever the MP_UNREACH_NLRI attributes as defined in RFC4760 [RFC4760]. Whenever
corresponding application does not require Next Hop information, this the corresponding application does not require Next Hop information,
shall be encoded as a 0 octet length Next Hop in the MP_REACH_NLRI this shall be encoded as a 0 octet length Next Hop in the
attribute and ignored on receipt. MP_REACH_NLRI attribute and ignored on receipt.
The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as
a 1 or 2 octet NLRI length field followed by a variable length NLRI a 1 or 2 octet NLRI length field followed by a variable length NLRI
value. The NLRI length is expressed in octets. value. The NLRI length is expressed in octets.
+------------------------------+ +------------------------------+
| length (0xnn or 0xfn nn) | | length (0xnn or 0xfn nn) |
+------------------------------+ +------------------------------+
| NLRI value (variable) | | NLRI value (variable) |
+------------------------------+ +------------------------------+
skipping to change at page 9, line 46 skipping to change at page 9, line 46
Defines a list of {operation, value} pairs used to match the Defines a list of {operation, value} pairs used to match the
code field of an icmp packet. Values are encoded using a code field of an icmp packet. Values are encoded using a
single byte. single byte.
Type 9 - TCP flags Type 9 - TCP flags
Encoding: <type (1 octet), [op, bitmask]+> Encoding: <type (1 octet), [op, bitmask]+>
Bitmask values are encoded using a single byte, using the bit Bitmask values are encoded using a single byte, using the bit
definitions specified in the TCP header format [1]. definitions specified in the TCP header format [RFC0793].
This type uses the bitmask operand format, which differs from This type uses the bitmask operand format, which differs from
the numeric operator format in the lower nibble. the numeric operator format in the lower nibble.
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| e | a | len | 0 | 0 |not| m | | e | a | len | 0 | 0 |not| m |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
+ Top nibble: (End of List bit, And bit and Length field), as + Top nibble: (End of List bit, And bit and Length field), as
skipping to change at page 12, line 28 skipping to change at page 12, line 28
| | | | | | | |
| 0x91 | operator | end-of-list, value-size=2, = | | 0x91 | operator | end-of-list, value-size=2, = |
| | | | | | | |
| 0x1f90 | value | 8080 | | 0x1f90 | value | 8080 |
+--------+----------+------------------------------+ +--------+----------+------------------------------+
This constitutes a NLRI with an NLRI length of 16 octets. This constitutes a NLRI with an NLRI length of 16 octets.
Implementations wishing to exchange flow specification rules MUST use Implementations wishing to exchange flow specification rules MUST use
BGP's Capability Advertisement facility to exchange the Multiprotocol BGP's Capability Advertisement facility to exchange the Multiprotocol
Extension Capability Code (Code 1) as defined in RFC4760 [3]. The Extension Capability Code (Code 1) as defined in RFC4760 [RFC4760].
(AFI, SAFI) pair carried in the Multiprotocol Extension capability The (AFI, SAFI) pair carried in the Multiprotocol Extension
MUST be the same as the one used to identify a particular application capability MUST be the same as the one used to identify a particular
that uses this NLRI-type. application that uses this NLRI-type.
4. Traffic filtering 4. Traffic filtering
Traffic filtering policies have been traditionally considered to be Traffic filtering policies have been traditionally considered to be
relatively static. relatively static.
The popularity of traffic-based denial of service (DoS) attacks, The popularity of traffic-based denial of service (DoS) attacks,
which often requires the network operator to be able to use traffic which often requires the network operator to be able to use traffic
filters for detection and mitigation, brings with it requirements filters for detection and mitigation, brings with it requirements
that are not fully satisfied by existing tools. that are not fully satisfied by existing tools.
skipping to change at page 16, line 5 skipping to change at page 16, line 5
received from a different neighbor AS, which would be affected by received from a different neighbor AS, which would be affected by
that filtering rule. that filtering rule.
The neighboring AS is the immediate destination of the traffic The neighboring AS is the immediate destination of the traffic
described by the Flow Specification. If it requests these flows to described by the Flow Specification. If it requests these flows to
be dropped that request can be honored without concern that it be dropped that request can be honored without concern that it
represents a denial of service in itself. Supposedly, the traffic is represents a denial of service in itself. Supposedly, the traffic is
being dropped by the downstream autonomous-system and there is no being dropped by the downstream autonomous-system and there is no
added value in carrying the traffic to it. added value in carrying the traffic to it.
BGP implementations MUST also enforce that the AS_PATH attribute of a
route received via eBGP contains the neighboring AS in the left-most
position of the AS_PATH attribute. While this rule is optional in
the BGP specification, it becomes necessary to enforce it for
security reasons.
6. Traffic Filtering Actions 6. Traffic Filtering Actions
This specification defines a minimum set of filtering actions that it This specification defines a minimum set of filtering actions that it
standardizes as BGP extended community values [4]. This is not ment standardizes as BGP extended community values [RFC4360]. This is not
to be an inclusive list of all the possible actions but only a subset ment to be an inclusive list of all the possible actions but only a
that can be interpreted consistently across the network. subset that can be interpreted consistently across the network.
Implementations should provide mechanisms that map an arbitrary bgp Implementations should provide mechanisms that map an arbitrary bgp
community value (normal or extended) to filtering actions that community value (normal or extended) to filtering actions that
require different mappings in different systems in the network. For require different mappings in different systems in the network. For
instance, providing packets with a worse than best-effort per-hop instance, providing packets with a worse than best-effort per-hop
behavior is a functionality that is likely to be implemented behavior is a functionality that is likely to be implemented
differently in different systems and for which no standard behavior differently in different systems and for which no standard behavior
is currently known. Rather than attempting to define it here, this is currently known. Rather than attempting to define it here, this
can be accomplished by mapping a user defined community value to can be accomplished by mapping a user defined community value to
platform / network specific behavior via user configuration. platform / network specific behavior via user configuration.
skipping to change at page 16, line 39 skipping to change at page 17, line 39
| type | extended community | encoding | | type | extended community | encoding |
+--------+--------------------+--------------------------+ +--------+--------------------+--------------------------+
| 0x8006 | traffic-rate | 2-byte as#, 4-byte float | | 0x8006 | traffic-rate | 2-byte as#, 4-byte float |
| | | | | | | |
| 0x8007 | traffic-action | bitmask | | 0x8007 | traffic-action | bitmask |
| | | | | | | |
| 0x8008 | redirect | 6-byte Route Target | | 0x8008 | redirect | 6-byte Route Target |
+--------+--------------------+--------------------------+ +--------+--------------------+--------------------------+
Traffic-rate The traffic-rate extended community uses the same Traffic-rate The traffic-rate extended community uses the same
encoding as the "Link Bandwidth" [4] extended community. The rate encoding as the "Link Bandwidth" [RFC4360] extended community.
is is expressed as 4 octets in IEEE floating point format, units The rate is is expressed as 4 octets in IEEE floating point
being bytes per second. A traffic-rate of 0 should result on all format, units being bytes per second. A traffic-rate of 0 should
traffic for the particular flow to be discarded. result on all traffic for the particular flow to be discarded.
Traffic-action The traffic-action extended community consists of 6 Traffic-action The traffic-action extended community consists of 6
bytes of which only the 2 least significant bits of the 6th byte bytes of which only the 2 least significant bits of the 6th byte
(from left to right) are currently defined. (from left to right) are currently defined.
* Terminal action (bit 0). When this bit is set the traffic * Terminal action (bit 0). When this bit is set the traffic
filtering engine will apply any subsequent filtering rules (as filtering engine will apply any subsequent filtering rules (as
defined by the ordering procedure). If not set the evaluation defined by the ordering procedure). If not set the evaluation
of the traffic filter stops when this rule is applied. of the traffic filter stops when this rule is applied.
skipping to change at page 18, line 8 skipping to change at page 19, line 8
match this criteria, the choice between them is a local matter match this criteria, the choice between them is a local matter
(for example, the instance with the lowest Route Distinguisher (for example, the instance with the lowest Route Distinguisher
value can be elected). The traffic marking extended community value can be elected). The traffic marking extended community
instruct a system to modify the DSCP bits of a transiting IP instruct a system to modify the DSCP bits of a transiting IP
packet to the corresponding value. This extended community is packet to the corresponding value. This extended community is
encoded as a sequence of 5 zero bytes followed by the DSCP value. encoded as a sequence of 5 zero bytes followed by the DSCP value.
7. Traffic filtering in RFC2547bis networks 7. Traffic filtering in RFC2547bis networks
Provider-based layer 3 VPN networks, such as the ones using an BGP/ Provider-based layer 3 VPN networks, such as the ones using an BGP/
MPLS IP VPN [5] control plane, have different traffic filtering MPLS IP VPN [RFC4364] control plane, have different traffic filtering
requirements than internet service providers. requirements than internet service providers.
In these environments, the VPN customer network often has traffic In these environments, the VPN customer network often has traffic
filtering capabilities towards their external network connections filtering capabilities towards their external network connections
(e.g. firewall facing public network connection). Less common is the (e.g. firewall facing public network connection). Less common is the
presence of traffic filtering capabilities between different VPN presence of traffic filtering capabilities between different VPN
attachment sites. In an any-to-any connectivity model, which is the attachment sites. In an any-to-any connectivity model, which is the
default, this means that site to site traffic is unfiltered. default, this means that site to site traffic is unfiltered.
In circumstances where a security threat does get propagated inside In circumstances where a security threat does get propagated inside
skipping to change at page 18, line 35 skipping to change at page 19, line 35
The NLRI format for this address family consists of a fixed length The NLRI format for this address family consists of a fixed length
Route Distinguisher field (8 bytes) followed by a flow specification, Route Distinguisher field (8 bytes) followed by a flow specification,
following the encoded defined in this document. The NLRI length following the encoded defined in this document. The NLRI length
field shall includes the both 8 bytes of the Route Distinguisher as field shall includes the both 8 bytes of the Route Distinguisher as
well as the subsequent flow specification. well as the subsequent flow specification.
Propagation of this NLRI is controlled by matching Route Target Propagation of this NLRI is controlled by matching Route Target
extended communities associated with the BGP path advertisement with extended communities associated with the BGP path advertisement with
the VRF import policy, using the same mechanism as described in "BGP/ the VRF import policy, using the same mechanism as described in "BGP/
MPLS IP VPNs" [5] . MPLS IP VPNs" [RFC4364] .
Flow specification rules received via this NLRI apply only to traffic Flow specification rules received via this NLRI apply only to traffic
that belongs to the VRF(s) in which it is imported. By default, that belongs to the VRF(s) in which it is imported. By default,
traffic received from a remote PE is switched via an mpls forwarding traffic received from a remote PE is switched via an mpls forwarding
decision and is not subject to filtering. decision and is not subject to filtering.
Contrary to the behavior specified for the non-VPN NLRI, flow rules Contrary to the behavior specified for the non-VPN NLRI, flow rules
are accepted by default, when received from remote PE routers. are accepted by default, when received from remote PE routers.
8. Monitoring 8. Monitoring
skipping to change at page 21, line 5 skipping to change at page 22, line 5
provide service. provide service.
As long as traffic filtering rules are restricted to match the As long as traffic filtering rules are restricted to match the
corresponding unicast routing paths for the relevant prefixes, the corresponding unicast routing paths for the relevant prefixes, the
security characteristics of this proposal are equivalent to the security characteristics of this proposal are equivalent to the
existing security properties of BGP unicast routing. existing security properties of BGP unicast routing.
Where it not the case, this would open the door to further denial of Where it not the case, this would open the door to further denial of
service attacks. service attacks.
10. Acknowledgments 10. IANA Considerations
A flow specification consists of a sequence of flow components, which
are identified by a an 8-bit component type. Types must be assigned
and interpreted uniquely. The current specification defines types 1
though 12, with the value 0 being reserved.
In order to manage the limited number space and accommodate several
usages the following policies defined by RFC 5226 [RFC5226] are used:
+--------------+-------------------------------+
| Range | Policy |
+--------------+-------------------------------+
| 0 | Invalid value |
| | |
| [1 .. 12] | Defined by this specification |
| | |
| [13 .. 127] | Specification Required |
| | |
| [128 .. 255] | Private Use |
+--------------+-------------------------------+
The specification of a particular "flow component type" must clearly
identify what is the criteria used to match packets forwarded by the
router. This criteria should be meaningful across router hops and
not depend on values that change hop-by-hop such as ttl or layer-2
encapsulation.
The "Traffic-action" extended community defined in this document has
6 unused bits which can be used to convey additional meaning. These
values should be assigned via IETF Consensus rules only.
11. Acknowledgments
The authors would like to thank Yakov Rekhter, Dennis Ferguson and The authors would like to thank Yakov Rekhter, Dennis Ferguson and
Chris Morrow for their comments. Chris Morrow for their comments.
Chaitanya Kodeboyina helped design the flow validation procedure. Chaitanya Kodeboyina helped design the flow validation procedure.
Steven Lin and Jim Washburn ironed out all the details necessary to Steven Lin and Jim Washburn ironed out all the details necessary to
produce a working implementation. produce a working implementation.
11. Normative References 12. Normative References
[1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
September 1981. RFC 793, September 1981.
[2] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
(BGP-4)", RFC 4271, January 2006. Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Extensions for BGP-4", RFC 4760, January 2007. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[4] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006. Communities Attribute", RFC 4360, February 2006.
[5] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
(VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Authors' Addresses Authors' Addresses
Pedro Marques Pedro Marques
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: roque@juniper.net Email: roque@juniper.net
skipping to change at page 23, line 32 skipping to change at page 25, line 32
Robert Raszuk Robert Raszuk
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: raszuk@juniper.net Email: raszuk@juniper.net
Barry Greene Barry Greene
Cisco Systems, Inc. Juniper Networks
170 West Tasman Dr 1194 N. Mathilda Ave.
San Jose, CA 95134 Sunnyvale, CA 94089
US US
Email: bgreene@cisco.com Email: bgreene@juniper.net
Jared Mauch Jared Mauch
NTT/Verio NTT/Verio
8285 Reese Lane 8285 Reese Lane
Ann Arbor, MI 48103-9753 Ann Arbor, MI 48103-9753
US US
Danny McPherson Danny McPherson
Arbor Networks Arbor Networks
Email: danny@arbor.net Email: danny@arbor.net
skipping to change at page 25, line 44 skipping to change at line 851
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 27 change blocks. 
60 lines changed or deleted 106 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/