| IDR | S. Sangli |
| Internet-Draft | R. Bonica |
| Intended status: Standards Track | Juniper Networks Inc. |
| Expires: January 6, 2020 | July 5, 2019 |
BGP based Virtual Private Network (VPN) Services over SRv6+ enabled IPv6 networks
draft-ssangli-idr-bgp-vpn-srv6-plus-00
This document defines BGP protocol extensions for encoding and carrying SRv6+ Per-Path Service Instruction information to support Virtual Private Network services. This is applicable when the VPN services are offered in a SRv6+ enabled IPv6 network such that the VPN payload is transported over IPv6. The Per-Path Service Instruction information is encoded in the IPv6 Destination Option Header in the IPv6 data packets.
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 January 6, 2020.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
Virtual Private Network (VPN) technologies allow network providers to emulate private networks with shared infrastructure. For example, assume that a set of red sites, set of blue sites and a set of green sites connect to a provider network. Furthermore, assume that red sites and blue sites wish to interconnect, exchange packets. However, the green sites wish to communicate with green sites only. The provider should allow its infrastructure network to scale to both the requirements without having to create multiple parallel network infrastructures. The IETF has standardized many VPN technologies viz. Layer 3 VPN (L3VPN), Layer 2 VPN (L2VPN), Virtual Private LAN Service (VPLS), [RFC4762], Ethernet VPN (EVPN), Pseudowires to enable Layer 3 and Layer 2 VPN services.
The aforementioned technologies leverage MPLS network architecture :
In pure IPv6 deployments where there may be non-MPLS capable routers, it would be desirable to have alternate mechanism to provide VPN connectivity. This document describes BGP extensions and procedures applicable for SRv6+ enabled IPv6 networks, to provide VPN services over BGP.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC8174] when, and only when, they appear in all capitals, as shown here.
A SRv6+ segment provides unidirectional connectivity from an ingress node to an egress node. A SRv6+ path contains one or more such segments. SRv6+ introduces the concept of Per-Segment Service Instruction and Per-Path Service Instruction. These instructions describe the additional packet processing performed on a node. The Per-Segment Service Instruction is executed on the segment egress node while the Per-Path Service Instruction is executed on the path egress node. The SR Path egress node advertises the reachability information to SR Path ingress node via Multi Protocol extensions in BGP [RFC4760].
For providing VPN services, aforementioned BGP extensions rely on MPLS architecture [RFC3031]. The BGP extensions specify the new encoding for Network Layer Reachability Information (NLRI) to include the MPLS VPN labels [RFC8277]. Such a MPLS VPN label is associated with a forwarding decision in the VPN Routing Instance on the egress BGP Router. The ingress BGP router will push the VPN label on the data packet destined to the egress BGP router. The transport tunnel from ingress router to egress router can be MPLS or GRE or L2TPv3, but inner payload is a MPLS packet as described in [RFC4023], [RFC4817], [RFC7510]. The intermediate routers do not process the VPN label [a.k.a.] embedded label as described in [I-D.ietf-idr-tunnel-encaps].
To provide BGP based VPN services on a non-MPLS IPv6 networks, it would be beneficial to retain the benefits of BGP protocol extensions while leveraging the benefits of IPv6 [RFC8200]. [I-D.bonica-6man-vpn-dest-opt] describes SRv6+ paths as programmable with Per-Path Service Instructions (PPSI) that determine how egress nodes process SRv6+ payloads. The PPSIs are carried in the PPSI Option encoded in the IPv6 Destination Option Header [RFC8200].
The Per-Path Service Instruction (PPSI) Identifier is defined as follows:
The PPSI Identifier have node-local significance and is assigned by the egress BGP router. The value of zero is reserved. The PPSI Identifier will serve 2 purposes.
The structure of 3 octet PPSI Identifier will be updated in the next version of this document.
The encoding of the Per-Path Service Instruction Identifier for VPNs is described in Section 7 and Section 8.
This document defines a new Tunnel type : SRv6+. The format is as per below.
[I-D.ietf-idr-tunnel-encaps] defines many sub-TLVs for the tunnels. The encoding for them are as follows:
The Tunnel Encapsulation Attribute is a an Optional Transitive attribute as described in [I-D.ietf-idr-tunnel-encaps]. This attribute with SRv6+ tunnel type MUST be present in the BGP update carrying the Network Layer Reachability Information encoded with the PPSI Information. This document refers to the NLRI that is associated with SRv6+ Tunnel Encapsulation attribute as SRv6+_NLRI. The document [I.D.ietf-idr-tunnel-encaps-12] defines the encoding for sub-TLV as follows.
The Remote Endpoint sub-TLV can specify the IPv6 address of the egress router as the final destination address of SRv6+ packet which is also referred to as SR Path destination address. The sub-fields on this sub-TLV is encoded as below.
The Value field may be set to 0 which indicates that next hop value in the NLRI should be chosen for the SRv6+ Path destination address.
The Embedded Label Handling sub-TLV describes how the label field in the NLRI should be interpreted.
The value of 2 indicates that the label field in the NLRI MUST be ignored at the ingress router.
The PPSI Information instructs the egress router to de-encapsulate the packet and forward the newly exposed payload inner packet through the specified interface or forward using the specified Routing Instance. The PPSI Identifier described in Section 3 will be assigned by the egress BGP Router.
When the egress BGP Speaker advertises the NLRI, it will include the PPSI Information in the encoding described in Section 7 and Section 8. The egress BGP Speaker MUST include the Tunnel Encapsulation Attribute with Route type SRv6+ as described in Section 4 in such BGP updates.
By tagging the BGP update with Tunnel Encapsulation attribute of SRv6+ type, the BGP Speaker informs how the SRv6+_NLRI should be decoded and processed by the receiving BGP Speaker.
Via the Remote Tunnel Endpoint Sub-TLV encoding, the egress BGP router may specify the SRv6+ Path Destination Address. The Protocol type Sub-TLV and the Color Sub-TLV may be used by the egress BGP router to influence the payload packets to be put on SRv6+ path. The Embedded Label Handling Sub-TLV MUST be set to 2 to inform that the MPLS label field should be ignored.
A single PPSI Identifier may be associated with all the prefixes in a Routing Instance or a unique PPSI Identifier may be associated for each prefix in the Routing Instance. The choice is left to the Network Operator and is outside the scope of this document.
Upon receiving a BGP update, the receiving BGP Speaker will look for Tunnel Encapsulation attribute. If the tunnel type carried in the Tunnel Encapsulation attribute is SRv6+, the BGP updates is said to be carrying the SRv6+_NLRI and the Label field in the Network Layer Reachability Information is treated as Per-Path Service Instruction (PPSI) Identifier.
The tuple (PPSI Identifier, Prefix) is programmed in the forwarding infrastructure of the router. The manner in which this tuple is stored in the router is outside the scope of this document. If SRv6+ has been enabled on the router, such a tuple SHOULD be used for encoding the Destination Options Header as described in [I-D.bonica-6man-vpn-dest-opt].
[I.D.ietf-idr-tunnel-encaps-12] describes how Remote Tunnel Endpoint Sub-TLV has to be processed. It also describes the usage of the Protocol type Sub-TLV and the Color Sub-TLV. This may be used by the ingress BGP router to select the payload packets that should be put on SRv6+ path.
The Embedded Label Handling Sub-TLV value that is set to 2 indicates that ingress BGP router to ignore the MPLS label field.
The Egress and Ingress BGP speakers form a BGP peering session to exchange a set of prefixes described in [RFC4271] and Multi protocol extensions [RFC4760]. The BGP Router capable of SRv6+ that is enabled to carry L3 VPN services over IPv6 networks should follow the procedures mentioned in Section 5 and Section 6. The manner in which a BGP Router is configured for SRv6+ underlay and L3 VPN overlay is outside the scope of this document.
The IPv4 L3 VPN over IPv6 is defined in [RFC5549]. The MP_REACH NLRI and Tunnel Encapsulation attribute encoding is as per below:
The PPSI Identifier is associated with VPN Routing Instance on the Egress PE. The Tunnel Encapsulation attribute with SRv6+ type MUST be appended to the Path attributes associated with the NLRI.
The IPv6 L3 VPN over IPv6 is defined in [RFC4659]. The MP_REACH NLRI and Tunnel Encapsulation attribute encoding is as per below:
The PPSI Identifier is associated with VPN Routing Instance on the Egress PE. The Tunnel Encapsulation attribute with SRv6+ type MUST be appended to the Path attribute associated with the NLRI.
The IPv4 L3 VPN over IPv6 is defined in [RFC5549]. The MP_REACH NLRI and Tunnel Encapsulation attribute encoding is per below:
The PPSI Identifier is associated with VPN Routing Instance on the Egress PE. The Tunnel Encapsulation attribute with SRv6+ type MUST be appended to the Path attribute associated with the NLRI.
The [RFC7432] describes the BGP extensions for carrying the Ethernet Virtual Private Network Overlay on MPLS network. It defines 4 types of EVPN NLRI. This document specifies changes to certain fields for those NLRIs.
The MP_REACH and MP_UNREACH attributes will carry this route in the NLRI encoding described in [RFC7432]. In addition to Tunnel Encapsulation attribute encoding, this document recommends to follow the [RFC4732] encoding except the following.
The MPLS label field is not part of the route but treated as route attribute. For procedures and usage of this route, refer to [RFC7432]. The Tunnel Encapsulation attribute with SRv6+ type MUST be appended to the Path attribute associated with the NLRI.
The MP_REACH and MP_UNREACH attributes will carry this route in the NLRI encoding described in [RFC7432]. In addition to Tunnel Encapsulation attribute encoding, this document recommends to follow the [RFC4732] encoding except the following.
The MPLS label field is not part of the route but treated as route attribute. For procedures and usage of this route, refer to [RFC7432]. The Tunnel Encapsulation attribute with SRv6+ type MUST be appended to the Path attribute associated with the NLRI.
This document proposes to reuse the NLRI encoding for BGP L3VPN and EVPN Network Layer Routing Information. However, care should be taken when BGP VPN overlay services are enabled on SRv6+ underlay such that Tunnel Encapsulation Path attribute with SRv6+ type MUST be appended. When a BGP router advertises SRv6+_NLRI, it MUST not remove the Tunnel Encapsulation Path attribute.
The SRv6+ underlay is similar to other "tunnel" technologies viz MPLS, GRE, IP-in-IP, L2TPv3. The egress and ingress BGP routers can be connected via one or more such underlay technologies. A BGP speaker can advertise the VPN NLRI with the nexthop reachable via one or more such underlay paths. Each such mechanism can co-exist together as ships-in-night. However, when SRv6+_NLRI is advertised by a egress BGP speaker and received by an ingress BGP speaker, they MUST follow the procedures mentioned in this document.
For migrating a BGP router to SRv6+ the following procedures can be followed.
The extension proposed in this document is backward compatible with procedures described for BGP enabled services.
This document does not introduce any new security considerations beyond those already specified in [RFC4271], [RFC8277] and [I.D.ietf-idr-tunnel-encaps-12].
IANA is requested to assign a code point for SRv6+ Route Type for BGP Tunnel Encapsulation Path Attribute from BGP Tunnel Encapsulation Attribute Tunnel Types Registry.
The authors would like to thank Jeff Haas for careful review and suggestions.
| [I-D.bonica-6man-vpn-dest-opt] | Bonica, R., Lenart, C., So, N., Xu, F., Presbury, G., Chen, G., Zhu, Y., Yang, G. and Y. Zhou, "The IPv6 Virtual Private Network (VPN) Context Information Option", Internet-Draft draft-bonica-6man-vpn-dest-opt-05, March 2019. |
| [I-D.bonica-spring-srv6-plus] | Bonica, R., Hegde, S., Kamite, Y., Alston, A., Henriques, D., Halpern, J. and J. Linkova, "IPv6 Support for Segment Routing: SRv6+", Internet-Draft draft-bonica-spring-srv6-plus-01, July 2019. |
| [I-D.ietf-idr-tunnel-encaps] | Patel, K., Velde, G., Ramachandra, S. and E. Rosen, "The BGP Tunnel Encapsulation Attribute", Internet-Draft draft-ietf-idr-tunnel-encaps-12, May 2019. |
| [RFC0791] | Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC4303] | Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005. |
| [RFC4443] | Conta, A., Deering, S. and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
| [RFC8200] | Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017. |