idnits 2.17.1 draft-xu-src-dst-bgp-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 'Intended status' indicated for this document; assuming Proposed Standard 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 (March 21, 2016) is 2958 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) ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) == Outdated reference: A later version (-15) exists of draft-ietf-idr-add-paths-10 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Xu 3 Internet-Draft S. Yang 4 Expires: September 22, 2016 J. Wu 5 Tsinghua University 6 March 21, 2016 8 Source/Destination Routing Using BGP-4 9 draft-xu-src-dst-bgp-00 11 Abstract 13 This document describes the changes necessary for BGP-4 to route 14 traffic from a specified prefix to a specified prefix. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 22, 2016. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 This document may contain material from IETF Documents or IETF 49 Contributions published or made publicly available before November 50 10, 2008. The person(s) controlling the copyright in some of this 51 material may not have granted the IETF Trust the right to allow 52 modifications of such material outside the IETF Standards Process. 53 Without obtaining an adequate license from the person(s) controlling 54 the copyright in such materials, this document may not be modified 55 outside the IETF Standards Process, and derivative works of it may 56 not be created outside the IETF Standards Process, except to format 57 it for publication as an RFC or to translate it into languages other 58 than English. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2. Theory of Routing . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Extended NLRI Encodings . . . . . . . . . . . . . . . . . . . 3 66 4. Dealing with Ambiguity . . . . . . . . . . . . . . . . . . . 4 67 5. Src-Dst Capability . . . . . . . . . . . . . . . . . . . . . 4 68 6. Compatibility Considerations . . . . . . . . . . . . . . . . 5 69 7. Deployment Issues . . . . . . . . . . . . . . . . . . . . . . 5 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 74 10.2. Informative References . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 77 1. Introduction 79 This specification builds on BGP-4 [RFC4271]. It defines the 80 extended NLRI encodings for an appended source prefix, to define 81 routes from a source prefix to a destination prefix. 83 Traditionally, routing protocols make routing decisions solely based 84 on destination IP addresses, packets towards the same destination 85 will be delivered to the same next hop no matter where they come 86 from. However, considering policy-based routing, traffic engineering 87 and security, source information is also important for making routing 88 decisions. 90 In this document, we extend the NLRI field to support source prefix. 91 This implies not simply routing "to a destination", but routing "to 92 that destination AND from a specified source". Traffic within the 93 network could be source/destination routed as well, or could be 94 implicitly or explicitly routed from "any prefix", ::/0. 96 1.1. Requirements Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2. Theory of Routing 104 The primary function of BGP is to exchange network reachability 105 information, compute the routes towards destination prefixes, and 106 select the best routes according the pre-defined selection rules. 107 BGP-4 can support only those policies which conform to the 108 destination-based forwarding paradigm. 110 In this context, the route is qualified by a source prefix. 111 Intrinsically, in traditional routing model, the object being routed 112 to is a destination prefix; in the new routing model, the object 113 being routed might be a destination prefix given that the packet 114 sports a certain source prefix. 116 Routes that lack a source prefix match any source prefix (i.e., 117 ::/0), by definition. 119 3. Extended NLRI Encodings 121 In order to carry the source prefix information in an UPDATE message, 122 the existing NLRI encodings are extended by prepending the source 123 prefix. 125 The NLRI encodings specified in [RFC4271] and [RFC4760] are extended 126 as following: 128 +--------------------------------+ 129 | Type (4 octets) | 130 +--------------------------------+ 131 | Length (1 octet) | 132 +--------------------------------+ 133 | Prefix (variable) | 134 +--------------------------------+ 136 Extended NLRI Encodings based on RFC4271 and RFC4760 138 and the NLRI encoding specified in [RFC3107] is extended as the 139 following: 141 +--------------------------------+ 142 | Type (4 octets) | 143 +--------------------------------+ 144 | Length (1 octet) | 145 +--------------------------------+ 146 | Label (3 octets) | 147 +--------------------------------+ 148 | ... | 149 +--------------------------------+ 150 | Prefix (variable) | 151 +--------------------------------+ 153 Extended NLRI encodings based on RFC3107 155 Type: Assinged by IANA. 157 Length: Indicates the length in bits of the IP address prefix. 159 Label: Carrying label information as defined in [RFC3107] 161 Prefix: The Prefix field contains an IP address prefix, followed by 162 enough trailing bits to make the end of the field fall on an octet 163 boundary. 165 4. Dealing with Ambiguity 167 Ambiguity could happen when there are two routes: A and B, where 168 source prefix of A is more specific than source prefix of B, and 169 destination prefix of B is more specific than destination prefix of 170 A. 172 In this context, the matching rule follows that in 173 [I-D.baker-ipv6-ospf-dst-src-routing], the FIB lookup MUST yield the 174 route with the longest matching destination prefix that also matches 175 the source prefix constraint. In the event of a tie on the 176 destination prefix, it MUST also match the longest matching source 177 prefix among those options. 179 5. Src-Dst Capability 181 The capability to carry both source and destination prefixes in BGP 182 udpate messages (src-dst capability) is a new BGP capability 183 [RFC5492]. The Capability Code for this capability is specified in 184 the IANA. The Capability Length field of this capability is zero. 186 6. Compatibility Considerations 188 To be compatible with [I-D.ietf-idr-add-paths], the Type field 189 (defined in Section Section 3) should be carefully defined by IANA. 191 7. Deployment Issues 193 Router without src-dst capability should discard the BGP messages 194 with extended NRLI, and it falls back to traditional destination- 195 based routing when this happens. 197 8. Security Considerations 199 While source/destination routing could be used as part of a security 200 solution, it could be considered similar to an access list that is 201 managed by and scales with routing. 203 9. IANA Considerations 205 The Type field in Section Section 3, and the new capability code 206 should be defined by IANA. 208 10. References 210 10.1. Normative References 212 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 213 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 214 DOI 10.17487/RFC4271, January 2006, 215 . 217 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 218 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 219 2009, . 221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 222 Requirement Levels", BCP 14, RFC 2119, 223 DOI 10.17487/RFC2119, March 1997, 224 . 226 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 227 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 228 . 230 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 231 "Multiprotocol Extensions for BGP-4", RFC 4760, 232 DOI 10.17487/RFC4760, January 2007, 233 . 235 10.2. Informative References 237 [I-D.ietf-idr-add-paths] 238 Walton, D., Retana, A., Chen, E., and J. Scudder, 239 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 240 add-paths-10 (work in progress), October 2014. 242 [I-D.baker-ipv6-ospf-dst-src-routing] 243 Baker, F., "IPv6 Source/Destination Routing using OSPFv3", 244 draft-baker-ipv6-ospf-dst-src-routing-03 (work in 245 progress), August 2013. 247 Authors' Addresses 249 Mingwei Xu 250 Tsinghua University 251 Department of Computer Science, Tsinghua University 252 Beijing 100084 253 P.R. China 255 Phone: +86-10-6278-1572 256 Email: xumw@tsinghua.edu.cn 258 Shu Yang 259 Graduate School at Shenzhen, Tsinghua University 260 Division of Information Science and Technology 261 Shenzhen 518055 262 P.R. China 264 Phone: +86-755-2603-6059 265 Email: yang.shu@sz.tsinghua.edu.cn 267 Jianping Wu 268 Tsinghua University 269 Department of Computer Science, Tsinghua University 270 Beijing 100084 271 P.R. China 273 Phone: +86-10-6278-5983 274 Email: jianping@cernet.edu.cn