idnits 2.17.1 draft-scudder-idr-rt-constrain-lite-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 25, 2009) is 5419 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'AFI' is mentioned on line 102, but not defined == Missing Reference: 'SAFI' is mentioned on line 102, but not defined Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Scudder 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track J. Uttaro 5 Expires: December 27, 2009 AT&T 6 P. Mohapatra 7 Cisco Systems 8 June 25, 2009 10 RT-Constrain Lite for Provider Edge Routers 11 draft-scudder-idr-rt-constrain-lite-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on December 27, 2009. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 RFC 4684, "Constrained Route Distribution for Border Gateway 60 Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol 61 (IP) Virtual Private Networks (VPNs)" provides a powerful and general 62 means for BGP speakers to exchange and propagate Route Target 63 reachability information which is used for cooperative route 64 filtering. However, the complexity of implementing the entire 65 specification may have impeded its widespread deployment. This 66 document specifies the subset of functionality which is required for 67 a provider edge router ("PE") to originate Route Target NLRI. Such 68 PEs need not implement any filtering functionality. 70 1. Introduction 72 [RFC4684], "Constrained Route Distribution for Border Gateway 73 Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol 74 (IP) Virtual Private Networks (VPNs)" provides a powerful and general 75 means for BGP speakers to exchange and propagate Route Target 76 reachability information which is used for cooperative route 77 filtering. However, the complexity of implementing the entire 78 specification may have impeded its widespread deployment. We observe 79 that the functionality required for a BGP speaker functioning solely 80 as a provider edge router ("PE") is substantially simpler than that 81 required for a speaker which serves as a route reflector or ASBR. 82 Specifically, the PE need only implement the ability to send Route 83 Target Membership NLRI; it need not have the ability to receive, 84 store and filter upon such information. 86 This document specifies the subset of functionality which is required 87 for a PE to originate Route Target NLRI. Since this document simply 88 specifies a subset, any BGP implementation which conforms with 89 [RFC4684] by definition also conforms with this specification. 91 1.1. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 2. Route Target Membership NLRI Advertisements 99 A PE implementing this specification advertises its Route Targets of 100 interest as Route Target membership NLRI in BGP UPDATE messages using 101 the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The 102 [AFI, SAFI] value pair used to identify this NLRI is (AFI=1, 103 SAFI=132). 105 The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix 106 of 0 to 96 bits, encoded as defined in Sections 3 and 4 of [RFC4760]. 108 This prefix is structured as follows: 110 +-------------------------------+ 111 | origin AS (4 octets) | 112 +-------------------------------+ 113 | route target (8 octets) | 114 + + 115 | | 116 +-------------------------------+ 118 Except for the default route target, which is encoded as a zero- 119 length prefix, the minimum prefix length is 32 bits, since the origin 120 AS field cannot be interpreted as a prefix. 122 Although route targets can be expressed as prefixes as discussed in 123 [RFC4684], this specification does not mandate that such 124 functionality be provided. An implementation MAY choose to implement 125 the ability to advertise route target prefixes. 127 Although the default route target can be used to indicate to a peer 128 the willingness to receive all VPN route advertisements as discussed 129 in [RFC4684], this functionality is of dubious utility for a PE and 130 thus this specification does not mandate that such functionality be 131 provided. An implementation MAY choose to implement the ability to 132 advertise the default route target. 134 3. Capability Advertisement 136 A BGP speaker that wishes to advertise Route Target membership 137 information MUST use the Multiprotocol Extensions Capability 138 [RFC5492] Code, as defined in [RFC4760], to advertise the 139 corresponding (AFI, SAFI) pair, and MUST NOT advertise Route Target 140 membership information unless its peer has similarly advertised the 141 (AFI, SAFI) pair. 143 4. Operation 145 A BGP speaker implementing this specification MAY ignore all received 146 Route Target Membership NLRI routes. Such routes need not be stored, 147 they MAY be completely discarded without further processing. A 148 consequence of this is that a BGP speaker implementing this 149 specification MAY advertise its VPN NLRI without regard to what Route 150 Target membership information its peers may or may not have 151 advertised. 153 A BGP speaker implementing this specification MUST advertise a Route 154 Target Membership NLRI for each Route Target which it has been 155 configured to import into a local VRF. When the speaker's 156 configuration is updated to add or remove a Route Target import, the 157 speaker MUST generate Route Target Membership NLRI updates 158 (advertisements and/or withdrawals) to convey the necessary changes. 160 As a hint that initial RT membership exchange is complete, 161 implementations SHOULD generate an End-of-RIB marker, as defined in 162 [RFC4724], for the Route Target membership (afi, safi), regardless of 163 whether graceful restart is enabled on the BGP session. 165 5. Deployment Observations 167 We observe that when a BGP speaker supporting [RFC4684] and acting as 168 a route reflector ("the RR") peers with a BGP speaker which 169 implements this specification ("the PE"), the PE can be expected to 170 send all its VPN routes to the RR just as it would if no Cooperative 171 Route Filtering were in use. The RR would not be expected to apply 172 any filtering to those routes as a consequence of this specification 173 or [RFC4684]. However, the RR would be expected to build an outbound 174 filter towards the PE based on Route Target membership information 175 received from the PE. This is a consequence of the normal operation 176 of [RFC4684]; refer to that specification for more detail. 178 6. Acknowledgements 180 This document relies entirely on the functionality defined in 181 [RFC4684]. As such, thanks are due to the authors of that document. 182 Jim Guichard also made valuable contributions. 184 7. IANA Considerations 186 This memo includes no request to IANA. 188 8. Security Considerations 190 This specification makes no changes to the security considerations of 191 [RFC4684]. 193 9. Normative References 195 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 196 Requirement Levels", BCP 14, RFC 2119, March 1997. 198 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 199 R., Patel, K., and J. Guichard, "Constrained Route 200 Distribution for Border Gateway Protocol/MultiProtocol 201 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 202 Private Networks (VPNs)", RFC 4684, November 2006. 204 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 205 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 206 January 2007. 208 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 209 "Multiprotocol Extensions for BGP-4", RFC 4760, 210 January 2007. 212 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 213 with BGP-4", RFC 5492, February 2009. 215 Authors' Addresses 217 John G. Scudder 218 Juniper Networks 220 Email: jgs@juniper.net 222 Jim Uttaro 223 AT&T 225 Email: uttaro@att.com 227 Pradosh Mohapatra 228 Cisco Systems 230 Email: pmohapat@cisco.com