idnits 2.17.1 draft-dong-idr-sr-policy-vtn-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 : ---------------------------------------------------------------------------- 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 date (October 30, 2020) is 1273 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 (-26) exists of draft-ietf-idr-segment-routing-te-policy-09 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-19 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-08 == Outdated reference: A later version (-06) exists of draft-dong-6man-enhanced-vpn-vtn-id-01 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-06 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group J. Dong 3 Internet-Draft Z. Hu 4 Intended status: Standards Track Huawei Technologies 5 Expires: May 3, 2021 R. Pang 6 China Unicom 7 October 30, 2020 9 BGP SR Policy Extensions for Virtual Transport Network 10 draft-dong-idr-sr-policy-vtn-00 12 Abstract 14 Segment Routing (SR) Policy is a set of candidate paths, each 15 consisting of one or more segment lists and the associated 16 information. The header of a packet steered in an SR Policy is 17 augmented with an ordered list of segments associated with that SR 18 Policy. In scenarios where multiple Virtual Transport Networks 19 (VTNs) exist in the network, the VTN in which the SR policy is 20 instantiated may also need to be specified, so that the header of 21 packet can also be augmented with the information associated with the 22 VTN. An SR Policy candidate path can be distributed using BGP SR 23 Policy. This document defines extensions to BGP SR policy to specify 24 the VTN associated with the SR policy. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 3, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 62 3. VTN Information Encoding in SR Policy . . . . . . . . . . . . 3 63 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 69 8.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 The concept of Segment Routing (SR) policy is defined in 75 [I-D.ietf-spring-segment-routing-policy]. An SR Policy is a set of 76 candidate paths, each consisting of one or more segment lists. The 77 head end of an SR Policy may learn multiple candidate paths for an SR 78 Policy. The header of a packet steered in an SR Policy is augmented 79 with an ordered list of segments associated with that SR Policy. The 80 BGP extensions to distribute SR Policy candidate paths is defined in 81 [I-D.ietf-idr-segment-routing-te-policy]. 83 The concept of Virtual Transport Network (VTN) is introduced in 84 [I-D.ietf-teas-enhanced-vpn]. A VTN is a virtual underlay network 85 which has customized network topology and a set of dedicated or 86 shared network resources. In a network, different VTNs may be 87 created to meet different service requirements, and different 88 services can be mapped to different VTNs. 90 In scenarios where multiple virtual networks (VTNs) exist in the 91 network, the identifier of VTN in which the SR policy is instantiated 92 may also need to be specified, so that the header of data packet can 93 also be augmented with the information of the associated VTN. This 94 document defines the BGP extensions to specify the VTN ID associated 95 with a candidate path of SR policy. 97 2. Specification of Requirements 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 3. VTN Information Encoding in SR Policy 105 In order to specify the VTN the candidate path of SR policy is 106 associated with, a new sub-TLV called "VTN sub-TLV" is defined in the 107 BGP Tunnel Encapsulation Attribute [I-D.ietf-idr-tunnel-encaps]. The 108 VTN sub-TLV can be carried in the BGP Tunnel Encapsulation Attribute 109 with the tunnel type set to SR Policy. 111 The VTN sub-TLV is optional and MUST NOT appear more than once for 112 one SR Policy candidate path. If the VTN sub-TLV appears more than 113 once, the associated BGP SR Policy NLRI is considered malformed and 114 the "treat-as-withdraw" strategy of [RFC7606] is applied. 116 The VTN sub-TLV has the following format: 118 0 1 2 3 119 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Type | Length | Flags | RESERVED | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | VTN ID (4 octets) | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 Figure 1. VTN Sub-TLV 127 where: 129 o Type: TBA 131 o Length: 6 133 o Flags: 1-octet flag field. None is defined at this stage. The 134 flags SHOULD be set to zero on transmission and MUST be ignored on 135 receipt. 137 o RESERVED: 1 octet of reserved bits. It SHOULD be set to zero on 138 transmission and MUST be ignored on receipt. 140 o VTN ID: A 32-bit global significant identifier which is used to 141 identify a VTN. Value 0 and 0xFFFFFFFF are reserved. 143 The encoding structure of BGP SR Policy with the VTN sub-TLV is 144 expressed as below: 146 SR Policy SAFI NLRI: 147 Attributes: 148 Tunnel Encaps Attribute (23) 149 Tunnel Type: SR Policy 150 Binding SID 151 Preference 152 Priority 153 Policy Name 154 Explicit NULL Label Policy (ENLP) 155 VTN 156 Segment List 157 Weight 158 Segment 159 Segment 160 ... 161 ... 163 4. Procedures 165 When a candidate path of SR policy is associated with a specific VTN, 166 the originating node of SR policy SHOULD include the associated VTN 167 in the BGP Tunnel Encapsulation Attribute of the BGP SR policy. The 168 setting of other fields and attributes in BGP SR policy SHOULD 169 follows the mechanism as defined in 170 [I-D.ietf-idr-segment-routing-te-policy]. 172 When a BGP speaker receives an SR Policy which is acceptable and 173 usable according to the rules as defined in 174 [I-D.ietf-idr-segment-routing-te-policy], and the SR Policy candidate 175 path selected as the best candidate path is associated with a VTN, 176 the BGP speaker SHOULD encapsulate VTN-specific information to the 177 header of packets steered to the SR policy. For SR Policy with IPv6 178 data plane, the possible approach is to encapsulate the VTN-ID to the 179 packets using the mechanism defined in 180 [I-D.dong-6man-enhanced-vpn-vtn-id]. For SR Policy with MPLS data 181 plane, the usage of the VTN information is similar, the mechanism 182 will be defined in a separate document and is out of the scope of 183 this document. 185 Although the proposed mechanism allows that different candidate paths 186 in one SR policy be associated with different VTNs, in normal network 187 scenarios it is considered that the mapping between service to VTN is 188 consistent, in such case all candidate paths of one SR policy are 189 associated with the same VTN. 191 5. Security Considerations 193 The security considerations of BGP and BGP SR policy apply to this 194 document. 196 6. IANA Considerations 198 This document requests IANA to allocate a new sub-TLV type as defined 199 in Section 3 from "BGP Tunnel Encapsulation Attribute sub-TLVs" 200 registry. 202 Value Description Reference 203 ---------------------------------------------------- 204 TBA VTN This document 206 7. Acknowledgments 208 The authors would like to thank Guoqi Xu, Lei Bao and Haibo Wang for 209 the review and discussion of this document. 211 8. References 213 8.1. Normative References 215 [I-D.ietf-idr-segment-routing-te-policy] 216 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 217 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 218 Routing Policies in BGP", draft-ietf-idr-segment-routing- 219 te-policy-09 (work in progress), May 2020. 221 [I-D.ietf-idr-tunnel-encaps] 222 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 223 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 224 encaps-19 (work in progress), September 2020. 226 [I-D.ietf-spring-segment-routing-policy] 227 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 228 P. Mattes, "Segment Routing Policy Architecture", draft- 229 ietf-spring-segment-routing-policy-08 (work in progress), 230 July 2020. 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, 234 DOI 10.17487/RFC2119, March 1997, 235 . 237 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 238 Patel, "Revised Error Handling for BGP UPDATE Messages", 239 RFC 7606, DOI 10.17487/RFC7606, August 2015, 240 . 242 8.2. Informative References 244 [I-D.dong-6man-enhanced-vpn-vtn-id] 245 Dong, J., Li, Z., Xie, C., and C. Ma, "Carrying Virtual 246 Transport Network Identifier in IPv6 Extension Header", 247 draft-dong-6man-enhanced-vpn-vtn-id-01 (work in progress), 248 July 2020. 250 [I-D.ietf-teas-enhanced-vpn] 251 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 252 Framework for Enhanced Virtual Private Networks (VPN+) 253 Service", draft-ietf-teas-enhanced-vpn-06 (work in 254 progress), July 2020. 256 Authors' Addresses 258 Jie Dong 259 Huawei Technologies 261 Email: jie.dong@huawei.com 263 Zhibo Hu 264 Huawei Technologies 266 Email: huzhibo@huawei.com 268 Ran Pang 269 China Unicom 271 Email: pangran@chinaunicom.cn