idnits 2.17.1 draft-agrewal-idr-accept-own-nexthop-00.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 abstract seems to contain references ([I-D.ietf-bess-service-chaining], [RFC4271]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2017) is 2375 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) == Outdated reference: A later version (-06) exists of draft-ietf-bess-service-chaining-03 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR A. Grewal 3 Internet-Draft N. Sheth 4 Intended status: Standards Track K. Vairavakkalai 5 Expires: April 22, 2018 Juniper Networks 6 October 19, 2017 8 BGP accept-own-nexthop community attribute 9 draft-agrewal-idr-accept-own-nexthop-00 11 Abstract 13 Various Service chain techniques utilize a Controller to inject 14 Border Gateway Protocol (BGP) Virtual Private Network (VPN) routes to 15 help steer traffic through a given path. The Controller does so by 16 controlling how these VPN routes are imported into various Virtual 17 Routing and Forwarding (VRF) tables at routers along the desired 18 path. A couple of such approaches are specified in 19 [I-D.ietf-bess-service-chaining]. These approaches rely on the 20 Controller modifying the Route Target (RT) list and next-hop of a VPN 21 route received from a downstream router and redistributing these 22 modified routes to upstream routers. This is done such that - 24 o routes originated by an ingress VRF at the downstream router are 25 imported into the egress VRF at the immediately preceding upstream 26 router and 28 o next-hop advertised to the upstream router is the address of the 29 immediately succeeding downstream router. 31 This forces the traffic to flow through a sequence of network 32 functions creating a service chain. 34 This works fine as long as the VRF importing the route received from 35 the Controller is on a different router than the VRF that originally 36 exported the route to the Controller. This is because BGP protocol 37 [RFC4271] specifies that a router reject routes received with its own 38 next-hop. This document proposes a new community the reception of 39 which relaxes this particular rule in the BGP protocol standard and 40 describes at least one way of how next-hops of such routes could be 41 resolved. 43 Requirements Language 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in [RFC2119]. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at https://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on April 22, 2018. 66 Copyright Notice 68 Copyright (c) 2017 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (https://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with respect 76 to this document. Code Components extracted from this document must 77 include Simplified BSD License text as described in Section 4.e of 78 the Trust Legal Provisions and are provided without warranty as 79 described in the Simplified BSD License. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 84 2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 85 3. accept-own-nexthop community . . . . . . . . . . . . . . . . 5 86 3.1. New BGP behavior . . . . . . . . . . . . . . . . . . . . 5 87 3.2. Configuration Control . . . . . . . . . . . . . . . . . . 5 88 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 90 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 92 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 93 7.2. Informative References . . . . . . . . . . . . . . . . . 6 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 96 1. Introduction 98 The BGP ACCEPT_OWN Community Attribute standard [RFC7611] defined a 99 technique to let the route reflector modify the RT list of a VPN 100 route and redistribute it back to the originating Provider Edge (PE). 101 This enables the route reflector to control how a route originated 102 within one VRF at the PE is imported into other VRFs at the 103 originating PE. However, the ACCEPT_OWN standard does not specify 104 how the forwarding next-hop for such an accepted route is derived. 105 It is understood that once the source VRF is located, the original 106 route for this prefix in this source VRF is located and the next-hop 107 information of the original route is used as the forwarding state for 108 the received route. The standard also mandates that the route 109 received from the route reflector be originated by a source VRF on 110 the receiving router. 112 This document proposes a new community - BGP accept-own-nexthop - 113 whose usage means - 'accept a route with one's own next-hop' 114 (regardless of whether the route was originated by the PE). Doing 115 so, enables some new useful use cases. The scope of this community 116 does not mandate the route be originated by a source VRF on the 117 receiving router as was the case in BGP ACCEPT_OWN community 118 attribute. Also, the usage of this community does not specify how 119 the forwarding next-hop of such a route is derived. One different 120 approach, than the implicit approach used in BGP ACCEPT_OWN standard, 121 to obtain the forwarding information of the received route is 122 described below. 124 2. Use Case 126 Let us walk through an example of how a router could redirect 127 traffic, that it is receiving in the Ingress VRF, towards a Layer 2 128 Physical Network Function (PNF) before the traffic exits this router. 129 A gateway in the form of a router is necessary to have Layer 2 PNFs 130 become part of a service chain. 132 +--------------------------------------+ 133 | Layer 2 Physical network function | 134 +-------------^------------|-----------+ 135 | | 136 | | 137 | | 138 +---------------|------------|---------------+ 139 | | | | 140 | +----|----+ +----v----+ | 141 | | Service | | Service | | 142 | +--> in-VRF | | out-VRF ---+ | 143 | | | | | | | | 144 | | +---------+ +---------+ | | 145 | | | | 146 | +----|----+ +----v----+ | 147 | | Ingress | | Egress | | 148 ---------> VRF | | VRF ---------> 149 | | | | | | 150 | +---------+ +---------+ | 151 | | 152 | Router | 153 +--------------------------------------------+ 155 Figure 1: A Layer 2 PNF as part of service chain 157 In the service chaining scenario involving a Layer 2 PNF - a PE (Fig. 158 1) advertises a static route - configured inside a VRF (service in- 159 VRF) - whose next-hop is the interface that a (transparent layer-2) 160 service instance (viz., firewall, anti-virus system etc.) is 161 connected to. The prefix for this route is an address that also 162 belongs to the same subnet as this interface's address. The 163 destination address will be in a different vrf (Service out-VRF) at 164 the PE itself where the serviced traffic coming from the service will 165 be received to be sent to it's destination. 167 PE will advertise this route with next-hop as itself and a label that 168 identifies the interface on the PE that the service is connected to. 170 A Controller acting as an extended route reflector could now steer 171 the traffic for a particular destination - for which the controller 172 wants the traffic to be serviced - by sending a VPN route for that 173 destination, with PE's own address as the next-hop and the above 174 label. The RT that Controller attaches to such a route would allow 175 it to be imported to the Ingress VRF. Such a route will be resolved 176 using the received VPN label - that the PE itself advertised - to 177 point to whatever next-hop information that is associated with this 178 label locally. A controller may create multiple such service VRFs on 179 the PE and follow the above procedure for each service to construct a 180 service chain by advertising routes with different RTs for the same 181 destination prefix with different labels, where each label identifies 182 the interface towards that particular service. 184 3. accept-own-nexthop community 186 A new well-known BGP community in the First Come First Served 187 [RFC5226] range called accept-own-nexthop has been assigned value of 188 0XFFF008 by IANA. 190 3.1. New BGP behavior 192 A change to default BGP behavior is proposed such that a router that 193 receives a route, whose NEXT_HOP value matches one of the addresses 194 configured on itself, MAY accept the route if and only if the 195 following are true: 197 o The received route is carrying the accept-own-nexthop community. 199 o Processing of the accept-own-nexthop community is enabled by 200 configuration on the receiving router. 202 3.2. Configuration Control 204 The processing - as defined above - of accept-own-nexthop community 205 is disabled by default. An implementation SHOULD provide a 206 configuration statement to enable a router to activate the behavior 207 specified in this document. 209 4. IANA Considerations 211 IANA has assigned the value 0xFFFF0008 in the "BGP Well-known 212 Communities" registry for the accept-own-nexthop community. 214 5. Security Considerations 216 accept-own-nexthop community allows a router to accept a route with 217 it's own next-hop. If the originator of that route is that router 218 itself and if the router accepts the received route to the same VRF 219 from where it was originated route oscillations would happen if this 220 new route is more preferable than the original route. That is so 221 because the receiving router preferring the received route would lead 222 to it withdrawing its advertisement for the original route. This 223 will prompt the Controller to withdraw the re-originated route. This 224 in turn will prompt the PE to re-advertise the original route and the 225 cycle would continue. 227 Since these routes are like any other BGP VPN route, all the 228 vulnerabilities applicable to any other BGP VPN route are also 229 applicable to these routes. Such vulnerabilities for BGP VPN routes 230 have been described in [RFC4364]. 232 6. Acknowledgements 234 The authors would like to thank John Scudder, Jeff Haas and Minto 235 Jeyanath for their valuable comments and suggestions. 237 7. References 239 7.1. Normative References 241 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 242 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 243 DOI 10.17487/RFC4271, January 2006, 244 . 246 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 247 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 248 2006, . 250 7.2. Informative References 252 [I-D.ietf-bess-service-chaining] 253 Fernando, R., Mackie, S., Rao, D., Rijsman, B., Napierala, 254 M., and T. Morin, "Service Chaining using Virtual Networks 255 with BGP VPNs", draft-ietf-bess-service-chaining-03 (work 256 in progress), July 2017. 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", BCP 14, RFC 2119, 260 DOI 10.17487/RFC2119, March 1997, 261 . 263 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 264 IANA Considerations Section in RFCs", RFC 5226, 265 DOI 10.17487/RFC5226, May 2008, 266 . 268 [RFC7611] Uttaro, J., Mohapatra, P., Smith, D., Raszuk, R., and J. 269 Scudder, "BGP ACCEPT_OWN Community Attribute", RFC 7611, 270 DOI 10.17487/RFC7611, August 2015, 271 . 273 Authors' Addresses 275 Ashutosh Grewal 276 Juniper Networks 277 1133 Innovation Way 278 Sunnyvale, CA 94089 279 USA 281 EMail: agrewal@juniper.net 283 Nischal Sheth 284 Juniper Networks 285 1133 Innovation Way 286 Sunnyvale, CA 94089 287 USA 289 EMail: nsheth@juniper.net 291 Kaliraj Vairavakkalai 292 Juniper Networks 293 1133 Innovation Way 294 Sunnyvale, CA 94089 295 USA 297 EMail: kaliraj@juniper.net