idnits 2.17.1 draft-ietf-ospf-2547-dnbit-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([VPN], [OSPF-VPN]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2003) is 7526 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: 'VPN-OSPF' is mentioned on line 137, but not defined == Unused Reference: 'OSPF' is defined on line 238, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-rfc2547bis-01 == Outdated reference: A later version (-06) exists of draft-ietf-l3vpn-ospf-2547-00 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Eric C. Rosen 3 Internet Draft Peter Psenak 4 Expiration Date: March 2004 Cisco Systems, Inc. 6 Padma Pillay-Esnault 7 Juniper Networks, Inc. 9 September 2003 11 Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs 13 draft-ietf-ospf-2547-dnbit-01.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 [VPN] describes a method by which a Service Provider (SP) may 38 provide an "IP VPN" service to its customers. In VPNs of that sort, 39 a Customer Edge (CE) Router and a Provider Edge Router become routing 40 peers, and the customer routes are sent to the SP. BGP is then used 41 to carry the customer routes across the SP's backbone to other PE 42 routers, and the routes are then sent to other CE routers. Since CE 43 routers and PE routers are routing peers, it is customary to run a 44 routing protocol between them. [VPN] allows a number of different 45 PE-CE protocols. If OSPF is used as the PE-CE routing protocol, the 46 PE must execute additional procedures not specified in [VPN]; these 47 procedures are specified in [OSPF-VPN]. These additional procedures 48 translate customer OSPF routes from a CE router into BGP routes. The 49 BGP routes are sent to the other PE routers, which translate them 50 back into OSPF routes, and then distribute them to CE routers. 51 During this translation, some of the information needed to prevent 52 loops may be lost. The procedures specified in this document remedy 53 this situation by specifying that one of the OSPF options bits be 54 used to ensure that when a VPN route is sent from a PE to a CE, the 55 route will be ignored by any PE which receives it back from a CE. 57 Table of Contents 59 1 Specification of Requirements ........................ 2 60 2 Introduction ......................................... 2 61 3 Information Loss and Loops ........................... 4 62 4 Using the LSA Options to Prevent Loops ............... 5 63 5 Acknowledgments ...................................... 5 64 6 Authors' Addresses ................................... 5 65 7 Normative References ................................. 6 67 1. Specification of Requirements 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119. 73 2. Introduction 75 [VPN] describes a method by which a Service Provider (SP) can use its 76 IP backbone to provide an "IP VPN" service to customers. In that 77 sort of service, a customer's edge devices (CE devices) are connected 78 to the provider's edge routers (PE routers). Each CE device is in a 79 single VPN. Each PE device may attach to multiple CEs, of the same 80 or of different VPNs. A VPN thus consists of a set of "network 81 segments" connected by the SP's backbone. 83 A CE exchanges routes with a PE, using a routing protocol that is 84 jointly agreed to by the customer and the SP. The PE runs that 85 routing protocol's decision process (i.e., performs the routing 86 computation) to determine the set of IP address prefixes for which 87 the following two conditions hold: 89 - each address prefix in the set can be reached via that CE 91 - the path from that CE to each such address prefix does NOT 92 include the SP backbone (i.e., does not include any PE routers). 94 The PE routers which attach to a particular VPN redistribute routes 95 to these address prefixes into BGP, so that they can use BGP to 96 distribute the VPN's routes to each other. BGP carries these routes 97 in the "VPN-IP address family", so that they are distinct from 98 ordinary Internet routes. The VPN-IP address family also extends the 99 IP addresses on the left so that address prefixes from two different 100 VPNs are always distinct to BGP, even if both VPNs use the same piece 101 of the private RFC1918 address space. Thus routes from different 102 VPNs can be carried by a single BGP instance, and can be stored in a 103 common BGP table, without fear of conflict. 105 If a PE router receives a particular VPN-IP route via BGP, and if 106 that PE is attached to a CE in the VPN to which the route belongs, 107 then BGP's decision process may install that route in the BGP route 108 table. If so, the PE translates the route back into an IP route, and 109 redistributes it to the routing protocol which is running on the link 110 to that CE. 112 This methodology provides a "peer model"; CE routers peer with PE 113 routers, but CE routers at different sites do not peer with each 114 other. 116 If a VPN uses OSPF as its internal routing protocol, it is not 117 necessarily the case that the CE routers of that VPN use OSPF to peer 118 with the PE routers. Each site in a VPN can use OSPF as its intra- 119 site routing protocol, while using, e.g., BGP or RIP to distribute 120 routes to a PE router. However, it is certainly convenient, when 121 OSPF is being used intra-site, to use it on the PE-CE link as well, 122 and [VPN] explicitly allows this. In this case, a PE will run a 123 separate instance of OSPF for each VPN which is attached to the PE; 124 the PE will in general have multiple VPN-specific OSPF routing 125 tables. 127 When OSPF is used on a PE-CE link which belongs to a particular VPN, 128 the PE router must redistribute to that VPN's OSPF instance certain 129 routes which have been installed in the BGP routing table. 130 Similarly, a PE router must redistribute to BGP routes which have 131 been installed in the VPN-specific OSPF routing tables. Procedures 132 for this are specified in [VPN-OSPF]. 134 The routes which are redistributed from BGP to OSPF are advertised in 135 LSAs that are originated by the PE. The PE acts as an OSPF border 136 router, advertising some of these routes in AS-external LSAs, and 137 some in summary LSAs, as specified in [VPN-OSPF]. 139 Similarly, when a PE router receives an LSA from a CE router, it runs 140 the OSPF routing computation. Any route that gets installed in the 141 OSPF routing table must be translated into a VPN-IP route and then 142 redistributed into BGP. BGP will then distribute these routes to the 143 other PE routers. 145 3. Information Loss and Loops 147 A PE, say PE1, may learn a route to a particular VPN-IP address 148 prefix via BGP. This may cause it to generate a summary LSA or an 149 AS-external LSA in which it reports that address prefix. This LSA 150 may then be distributed to a particular CE, say CE1. The LSA may 151 then be distributed throughout a particular OSPF area, reaching 152 another CE, say CE2. CE2 may then distribute the LSA to another PE, 153 say PE2. 155 As stated in the previous section, PE2 must run the OSPF routing 156 computation to determine whether a particular address prefix, 157 reported in an LSA from CE2, is reachable from CE2 via a path which 158 does not include any PE router. Unfortunately, there is no standard 159 way to do this. The OSPF LSAs do not necessarily carry the 160 information needed to enables PE2 to determine that the path to 161 address prefix X in a particular LSA from CE2 is actually a path that 162 includes, say, PE1. If PE2 then leaks X into BGP as a VPN-IP route, 163 then PE2 is violating one of the constraints for loop-freedom in BGP, 164 viz., that routes learned from a particular BGP domain not be 165 redistributed back into that BGP domain. This could cause a routing 166 loop to be created. 168 It is therefore necessary to have a means by which an LSA may carry 169 the information that a particular address prefix has been learned 170 from a PE router. Any PE router which receives an LSA with this 171 information would omit the information in this LSA from its OSPF 172 routing computation, and thus would not leak the information back 173 into BGP. 175 When a PE generates an AS-external LSA, it could use a distinct tag 176 value to indicate that the LSA is carrying information about an 177 address prefix for whom the path includes a PE router. However, this 178 method is not available in the case where the PE generates a Summary 179 LSA. Per [OSPF-VPN], each PE router must function as an OSPF area 0 180 router. If the PE-CE link is an area 0 link, then it is possible for 181 the PE to receive, over that link, a summary LSA which originated at 182 another PE router. Thus we need some way of marking a summary LSA to 183 indicate that it is carrying information about a path via a PE 184 router. 186 4. Using the LSA Options to Prevent Loops 188 The high-order bit of the LSA Options field (a previously unused bit) 189 is used to solve the problem described in the previous section. We 190 refer to this bit as the DN bit. When an LSA is sent from a PE to a 191 CE, the DN bit MUST be set. 193 +-------------------------------------+ 194 | DN | * | DC | EA | N/P | MC | E | * | 195 +-------------------------------------+ 197 Options Field with DN Bit 198 (RFC 2328, Section A.2) 200 When the PE receives, from a CE router, an LSA with the DN bit set, 201 the information from that LSA MUST NOT be used during the OSPF route 202 calculation. As a result, the LSA is not translated into a BGP 203 route. 205 This prevents routes learned via BGP from being redistributed to BGP. 207 5. Acknowledgments 209 The idea of using the high-order options bit for this purpose is due 210 to Derek Yeung. Thanks to Yakov Rekhter for his contribution to this 211 work. We also wish to thank Acee Lindem for his helpful comments. 213 6. Authors' Addresses 215 Eric C. Rosen 216 Cisco Systems, Inc. 217 1414 Massachusetts Avenue 218 Boxborough, MA 01719 220 E-mail: erosen@cisco.com 221 Peter Psenak 222 Parc Pegasus, 223 De Kleetlaan 6A 224 1831 Diegem 225 Belgium 227 E-mail: ppsenak@cisco.com 229 Padma Pillay-Esnault 230 Juniper Networks 231 1194 N. Mathilda Avenue 232 Sunnyvale, CA 94089 234 E-mail: padma@juniper.net 236 7. Normative References 238 [OSPF] "OSPF Version 2", RFC 2328, Moy, J., April 1998 240 [VPN] "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis-01.txt, Rosen, 241 Rekhter, et. al., September 2003 243 [OSPF-VPN] "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", draft- 244 ietf-l3vpn-ospf-2547-00.txt, Rosen, Psenak, Pillay-Esnault, June 2003