IDR Working Group J. Dong Internet-Draft Z. Hu Intended status: Standards Track Huawei Technologies Expires: May 3, 2021 R. Pang China Unicom October 30, 2020 BGP SR Policy Extensions for Virtual Transport Network draft-dong-idr-sr-policy-vtn-00 Abstract Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. In scenarios where multiple Virtual Transport Networks (VTNs) exist in the network, the VTN in which the SR policy is instantiated may also need to be specified, so that the header of packet can also be augmented with the information associated with the VTN. An SR Policy candidate path can be distributed using BGP SR Policy. This document defines extensions to BGP SR policy to specify the VTN associated with the SR policy. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 3, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Dong, et al. Expires May 3, 2021 [Page 1]
Internet-Draft BGP SR Policy for VTN October 2020 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 3. VTN Information Encoding in SR Policy . . . . . . . . . . . . 3 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The concept of Segment Routing (SR) policy is defined in [I-D.ietf-spring-segment-routing-policy]. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. The head end of an SR Policy may learn multiple candidate paths for an SR Policy. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. The BGP extensions to distribute SR Policy candidate paths is defined in [I-D.ietf-idr-segment-routing-te-policy]. The concept of Virtual Transport Network (VTN) is introduced in [I-D.ietf-teas-enhanced-vpn]. A VTN is a virtual underlay network which has customized network topology and a set of dedicated or shared network resources. In a network, different VTNs may be created to meet different service requirements, and different services can be mapped to different VTNs. In scenarios where multiple virtual networks (VTNs) exist in the network, the identifier of VTN in which the SR policy is instantiated may also need to be specified, so that the header of data packet can also be augmented with the information of the associated VTN. This document defines the BGP extensions to specify the VTN ID associated with a candidate path of SR policy. Dong, et al. Expires May 3, 2021 [Page 2]
Internet-Draft BGP SR Policy for VTN October 2020 2. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. VTN Information Encoding in SR Policy In order to specify the VTN the candidate path of SR policy is associated with, a new sub-TLV called "VTN sub-TLV" is defined in the BGP Tunnel Encapsulation Attribute [I-D.ietf-idr-tunnel-encaps]. The VTN sub-TLV can be carried in the BGP Tunnel Encapsulation Attribute with the tunnel type set to SR Policy. The VTN sub-TLV is optional and MUST NOT appear more than once for one SR Policy candidate path. If the VTN sub-TLV appears more than once, the associated BGP SR Policy NLRI is considered malformed and the "treat-as-withdraw" strategy of [RFC7606] is applied. The VTN sub-TLV has the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VTN ID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. VTN Sub-TLV where: o Type: TBA o Length: 6 o Flags: 1-octet flag field. None is defined at this stage. The flags SHOULD be set to zero on transmission and MUST be ignored on receipt. o RESERVED: 1 octet of reserved bits. It SHOULD be set to zero on transmission and MUST be ignored on receipt. o VTN ID: A 32-bit global significant identifier which is used to identify a VTN. Value 0 and 0xFFFFFFFF are reserved. The encoding structure of BGP SR Policy with the VTN sub-TLV is expressed as below: Dong, et al. Expires May 3, 2021 [Page 3]
Internet-Draft BGP SR Policy for VTN October 2020 SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint> Attributes: Tunnel Encaps Attribute (23) Tunnel Type: SR Policy Binding SID Preference Priority Policy Name Explicit NULL Label Policy (ENLP) VTN Segment List Weight Segment Segment ... ... 4. Procedures When a candidate path of SR policy is associated with a specific VTN, the originating node of SR policy SHOULD include the associated VTN in the BGP Tunnel Encapsulation Attribute of the BGP SR policy. The setting of other fields and attributes in BGP SR policy SHOULD follows the mechanism as defined in [I-D.ietf-idr-segment-routing-te-policy]. When a BGP speaker receives an SR Policy which is acceptable and usable according to the rules as defined in [I-D.ietf-idr-segment-routing-te-policy], and the SR Policy candidate path selected as the best candidate path is associated with a VTN, the BGP speaker SHOULD encapsulate VTN-specific information to the header of packets steered to the SR policy. For SR Policy with IPv6 data plane, the possible approach is to encapsulate the VTN-ID to the packets using the mechanism defined in [I-D.dong-6man-enhanced-vpn-vtn-id]. For SR Policy with MPLS data plane, the usage of the VTN information is similar, the mechanism will be defined in a separate document and is out of the scope of this document. Although the proposed mechanism allows that different candidate paths in one SR policy be associated with different VTNs, in normal network scenarios it is considered that the mapping between service to VTN is consistent, in such case all candidate paths of one SR policy are associated with the same VTN. Dong, et al. Expires May 3, 2021 [Page 4]
Internet-Draft BGP SR Policy for VTN October 2020 5. Security Considerations The security considerations of BGP and BGP SR policy apply to this document. 6. IANA Considerations This document requests IANA to allocate a new sub-TLV type as defined in Section 3 from "BGP Tunnel Encapsulation Attribute sub-TLVs" registry. Value Description Reference ---------------------------------------------------- TBA VTN This document 7. Acknowledgments The authors would like to thank Guoqi Xu, Lei Bao and Haibo Wang for the review and discussion of this document. 8. References 8.1. Normative References [I-D.ietf-idr-segment-routing-te-policy] Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., Rosen, E., Jain, D., and S. Lin, "Advertising Segment Routing Policies in BGP", draft-ietf-idr-segment-routing- te-policy-09 (work in progress), May 2020. [I-D.ietf-idr-tunnel-encaps] Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- encaps-19 (work in progress), September 2020. [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", draft- ietf-spring-segment-routing-policy-08 (work in progress), July 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. Dong, et al. Expires May 3, 2021 [Page 5]
Internet-Draft BGP SR Policy for VTN October 2020 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <https://www.rfc-editor.org/info/rfc7606>. 8.2. Informative References [I-D.dong-6man-enhanced-vpn-vtn-id] Dong, J., Li, Z., Xie, C., and C. Ma, "Carrying Virtual Transport Network Identifier in IPv6 Extension Header", draft-dong-6man-enhanced-vpn-vtn-id-01 (work in progress), July 2020. [I-D.ietf-teas-enhanced-vpn] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Framework for Enhanced Virtual Private Networks (VPN+) Service", draft-ietf-teas-enhanced-vpn-06 (work in progress), July 2020. Authors' Addresses Jie Dong Huawei Technologies Email: jie.dong@huawei.com Zhibo Hu Huawei Technologies Email: huzhibo@huawei.com Ran Pang China Unicom Email: pangran@chinaunicom.cn Dong, et al. Expires May 3, 2021 [Page 6]