idnits 2.17.1 draft-freedman-l3vpn-ospf2-4364-ce-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** 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.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 15, 2012) is 4300 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: 'PE1' is mentioned on line 145, but not defined == Missing Reference: 'PE2' is mentioned on line 145, but not defined == Missing Reference: 'CE1' is mentioned on line 114, but not defined == Missing Reference: 'CE2' is mentioned on line 114, but not defined == Missing Reference: 'O-CE1' is mentioned on line 149, but not defined == Missing Reference: 'O-CE2' is mentioned on line 149, but not defined == Unused Reference: 'RFC2119' is defined on line 256, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3392 (Obsoleted by RFC 5492) Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Freedman 3 Internet-Draft Claranet 4 Intended status: Standards Track July 15, 2012 5 Expires: January 16, 2013 7 OSPF Version 2 as the Customer Edge/Customer Protocol for BGP/MPLS IP 8 VPNs 9 draft-freedman-l3vpn-ospf2-4364-ce-01 11 Abstract 13 RFC4577 (OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP 14 VPNs) proposes a mechanism for the use of the Open Shortest Path 15 First V2 ("OSPF", RFC2328) protocol between the Provider Edge ("PE") 16 and Customer Edge ("CE") routers within a BGP/MPLS IP Virtual Private 17 Network ("IPVPN", RFC4364). 19 The standard provides for use of such a provider VPN to join 20 discontiguous locations together, preserving the OSPF area and domain 21 behaviour. 23 This document describes a technique for utilising the same, IPVPN 24 network infrastructure without the requirement to enable the OSPF 25 protocol on the PE/CE interface and thus relieve the PE router of 26 OSPF duties. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 16, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Solution Statement . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Sham Links . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 6. Behavioral Considerations . . . . . . . . . . . . . . . . . . 9 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 70 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 [RFC4577] describes a mechanism whereby discontiguous locations 76 belonging to the same OSPF area and domain are connected by use of an 77 [RFC4364] IPVPN network. 79 The premise (see Figure 1) is that OSPF [RFC2328] routing information 80 from a site is learned by the attached PE router through an OSPF 81 adjacency with the site's CE router. This OSPF routing information 82 is learned in the context of a Virtual Routing and Forwarding ("VRF") 83 instance intended to trigger redistribution into the provider BGP as 84 a VPN-IPv4 route through the addition of various Extended Communities 85 [RFC4360] such as "Route Target" (to select the desired destination 86 VRFs when imported by other PE routers), "OSPF Domain Identifier" (to 87 determine if the route should be treated as internal or external to 88 the CE OSPF domain) and "OSPF Route Type" (to encode the LSA type as 89 it was received from the OSPF neighbor). 91 When a remote PE router, importing such routes into a VRF (due to a 92 matching Route-Target in a VRF import policy), locates the OSPF 93 extended communities, it uses them to originate OSPF LSAs to its 94 attached CE. Providing the OSPF domain ID is the same, BGP routes 95 can be redistributed back into the CE-attached OSPF area using the 96 information encoded in the BGP update, fooling the attached site into 97 thinking that there is a contiguous OSPF domain. 99 "Sham Links" may then be created between VPN residing endpoints on 100 all involved PE routers, to provide simulated intra-area links, 101 ensuring that any "Backdoor" links between C routers are not 102 automatically selected by OSPF in preference to the provider network 103 links (which would normally be treated as inter-area had the Sham 104 Link not been present). 106 Sham Link 107 _____________ 108 / \ 109 / ,-----. \ 110 [PE1]; IPVPN +[PE2] 111 | : BGP + | 112 OSPF | `-----' | OSPF 113 | | 114 Site A [CE1] [CE2] Site B 115 | Area 0 | 116 OSPF | | OSPF 117 [ C1] [C3 ] 118 OSPF ,-' `. OSPF 119 [ C2] [C4 ] 120 \__________________/ 121 Backdoor Link 123 Figure 1 125 2. Problem Statement 127 The author infers from the title and language in RFC4577 that the 128 original intention of the document was to provide OSPF functionality 129 over an IPVPN network through use of the Provider's PE routers. 130 Since the Provider may use the PE router for multiple customers, and 131 OSPF is based on repeated execution of the Shortest Path First 132 ("SPF") algorithm, this approach may create computation scaling 133 considerations for the PE as the number or complexity of customer 134 topologies using this technology on the PE increases. 136 3. Solution Statement 138 This document proposes a mechanism for providing this OSPF 139 functionality over IPVPN networks, using only CE routers in a single 140 OSPF domain. A CE router that performs this function is to be known 141 as an O-CE router. Only IP and BGP are therefore required between 142 the O-CE and PE, this is illustrated below in Figure 2 144 ,-----. 145 [PE1]; IPVPN +[PE2] 146 | : + | 147 BGP | `-----' | BGP 148 | Sham | 149 Site A [O-CE1]--------- [O-CE2] Site B 150 | Link | 151 OSPF | Area 0 | OSPF 152 [ C1] [C3 ] 153 OSPF ,-' `. OSPF 154 [ C2] [C4 ] 155 \__________________/ 156 Backdoor Link 158 Figure 2 160 By removing the OSPF from the PE router and placing the 161 responsibility on the O-CE, the provider's existing IPVPN PE routers 162 are no longer forced to run the SPF algorithm since this task can be 163 delegated to the O-CE which does not have the same scaling concerns 164 (it does not share this task with multiple customer domains). 166 4. Domains 168 An O-CE is intended to only operate in one OSPF domain, known as the 169 O-CD (O-CE Domain). Though the O-CD is intended to be operator 170 configured on the O-CE, it may instead be automatically discovered 171 (but such mechanisms are outside the scope of this document). It is 172 assumed that the reachability signalled in the O-CD reflects the 173 reachability inside the corresponding attached provider VRF. 175 An O-CE receiving reachability information via BGP from the IPVPN 176 network from the provider VRF should interact with the C router 177 domain with respect to the O-CD in line with [RFC4577] Section 4.1. 178 In these cases, the O-CE MAY choose to accept reachability concerning 179 a domain other than the O-CD, in such case the O-CE must flood this 180 information as extra-area (type 5/7). 182 5. Sham Links 184 RFC4577 makes the following requirement of creating Sham Links (Sec 185 4.2.7.3): 187 An OSPF protocol packet is regarded as having been received on a 188 particular Sham Link if and only if the following three conditions 189 hold: 191 - The packet arrives as an MPLS packet, and its MPLS label stack 192 causes it to be "delivered" to the local Sham Link endpoint 193 address. 195 - The packet's IP destination address is the local Sham Link 196 endpoint address. 198 - The packet's IP source address is the remote Sham Link endpoint 199 address. 201 Although RFC4577 marks the use of Sham Links as "OPTIONAL", creation 202 of such links, with respect to the above stated, require that the 203 implementation transmit the OSPF protocol packets over MPLS 204 transport. 206 Since the intention of this document is to ensure that only IP and 207 BGP are required between O-CE routers, this document relaxes the 208 requirements stated in this RFC section, by removing the requirement 209 for the packet to arrive as an MPLS packet. Since the routing 210 information is redistributed into the BGP and labelled by the PE 211 router for use within the Provider's IPVPN network, an additional 212 MPLS LSP is not required. 214 This document adds the requirement that BGP should be used as a PE/ 215 O-CE protocol and that Extended Communities be made available to both 216 peers through mutual negotiation of the relevant BGP capability 217 [RFC3392]. 219 6. Behavioral Considerations 221 This document makes the following summary recommendations in respect 222 to behavior: 224 1. That the requirement stated in Section 3 (Requirements) of 225 RFC4577, that OSPF is used as a PE/CE routing protocol be 226 relaxed, such that BGP is used as a PE/O-CE routing protocol and 227 that BGP extended communities are enabled between PE and O-CE. A 228 mechanism to filter said communities SHOULD be made available to 229 the operator to ensure that no other (unwanted) extended 230 communities are injected to or from the provider space. 232 2. That the requirement stated in Section 4.2.7.3 (OSPF Protocol on 233 Sham Links) of RFC4577 with regards to the requirement that the 234 OSPF protocol packet be received as an MPLS packet, be relaxed in 235 an O-CE router implementation. In its place, the O-CE router 236 MUST verify that the OSPF protocol packet is valid based on the 237 operator configuration of valid Sham Link endpoints. 239 7. Security Considerations 241 The Behavioral Considerations (Section 6) specify that particular 242 behavioral patterns of RFC4577 be relaxed, references to ensuring 243 appropriate security of these modified behaviors can be found here. 245 It is important to note that the O-CE operates only in the context of 246 the O-CD, this means that the RFC4577 requirements supporting 247 multiple domain/instance behaviors are not relevant in the scope of 248 the O-CE. 250 8. Acknowledgements 252 The author would like to thank Paul Wells for his valuable input. 254 9. Normative References 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, March 1997. 259 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 261 [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement 262 with BGP-4", RFC 3392, November 2002. 264 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 265 Communities Attribute", RFC 4360, February 2006. 267 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 268 Networks (VPNs)", RFC 4364, February 2006. 270 [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the 271 Provider/Customer Edge Protocol for BGP/MPLS IP Virtual 272 Private Networks (VPNs)", RFC 4577, June 2006. 274 Author's Address 276 David Freedman 277 Claranet 278 London 279 UK 281 Phone: +44 20 7685 8000 282 Email: david.freedman@uk.clara.net