< draft-bonica-6man-vpn-dest-opt-05.txt   draft-bonica-6man-vpn-dest-opt-06.txt >
6man R. Bonica 6man R. Bonica
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track C. Lenart Intended status: Standards Track Y. Kamite
Expires: September 24, 2019 Verizon Expires: January 7, 2020 NTT Communications Corporation
C. Lenart
Verizon
N. So N. So
F. Xu F. Xu
Reliance Jio Reliance Jio
G. Presbury G. Presbury
Hughes Network Systems Hughes Network Systems
G. Chen G. Chen
Baidu Baidu
Y. Zhu Y. Zhu
G. Yang G. Yang
China Telecom China Telecom
Y. Zhou Y. Zhou
ByteDance ByteDance
March 23, 2019 July 6, 2019
The IPv6 Virtual Private Network (VPN) Context Information Option The Per-Path Service Instruction (PPSI) Option
draft-bonica-6man-vpn-dest-opt-05 draft-bonica-6man-vpn-dest-opt-06
Abstract Abstract
This document defines a new IPv6 Destination Option that can be used SRv6+ encodes Per-Path Service Instructions (PPSI) in a new IPv6
to encode Virtual Private Network (VPN) context information. It is option, called the PPSI Option. This document describes the PPSI
applicable when VPN payload is transported over IPv6. Option.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 24, 2019. This Internet-Draft will expire on January 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. VPN Context Information . . . . . . . . . . . . . . . . . . . 4 3. PPSI Identifiers . . . . . . . . . . . . . . . . . . . . . . 3
4. The VPN Context Information Option . . . . . . . . . . . . . 5 4. The PPSI Option . . . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Destination Option Header Considerations . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Virtual Private Networks (VPN) . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Virtual Private Network (VPN) technologies allow network providers to An SRv6+ [I-D.bonica-spring-srv6-plus] path provides unidirectional
emulate private networks with shared infrastructure. For example, connectivity from its ingress node to its egress node. While an
assume that a red sites and blue sites connect to a provider network. SRv6+ path can follow the least cost path from ingress to egress, it
The provider network facilitates communication among red sites and can also follow any other path.
facilitates communication among blue sites. However, it prevents
communication between red sites and blue sites.
The IETF has standardized many VPN technologies, including:
o Layer 2 VPN (L2VPN) [RFC6624].
o Layer 3 VPN (L3VPN) [RFC4364].
o Virtual Private LAN Service (VPLS) [RFC4761][RFC4762].
o Ethernet VPN (EVPN) [RFC7432].
o Pseudowires [RFC8077].
The above-mentioned technologies include the following components:
o Customer Edge (CE) devices.
o Provider Edge (PE) devices.
o Routing Instances.
o VPN context information.
o Transport tunnels.
CE devices participate in closed communities called VPNs. CEs that
participate in one VPN can communicate with one another but cannot
communicate with CEs that participate in another VPN.
CE devices connect to provider networks through PE devices. Each PE
maintains one Routing Instance for each VPN that it supports. A
Routing Instance is a VPN specific Forwarding Information Base (FIB).
In EVPN, Routing Instances are called Ethernet Virtual Instances
(EVI).
Assume that one CE sends a packet through a provider network to
another CE. The packet enters the provider network through an
ingress PE and leaves the provider network through an egress PE. The
packet may traverse one or more intermediate nodes on route from PE
to PE.
When the ingress PE receives the packet, it:
o Identifies the Routing Instance that supports the originating CE's
VPN.
o Searches that Routing Instance for the packet's destination.
If the search fails, the ingress PE discards the packet. If the
search succeeds, it yields the following:
o VPN context information.
o The egress PE's IP address.
The ingress PE prepends VPN context information and a transport
header to the packet, in that order. It then forwards the packet
through a transport tunnel to the egress PE.
The egress PE removes the transport header, if it has not already SRv6+ paths are encoded as IPv6 [RFC8200] header chains. When an
been removed by an upstream device. It then examines and removes the SRv6+ ingress node receives a packet, it encapsulates the packet in
VPN context information. Finally, it uses the VPN context an IPv6 header chain. It then forwards the encapsulated packet to
information to forward the packet to its destination (i.e., a the path's egress node. When the egress node receives the packet, it
directly connected CE). processes the SRv6+ payload (i.e., the original packet).
In the above-mentioned VPN technologies, the ingress PE encodes VPN SRv6+ paths are programmable. They support several instruction
context information in a Multiprotocol Label Switching (MPLS) types, including Per-Path Service Instructions (PPSI). PPSIs
[RFC3031] label. Depending upon the transport tunnel type, the determine how path egress nodes process SRv6+ payloads. In the
transport header can be: absence of a PPSI, the egress node processes SRv6+ payloads as
described in [RFC8200].
o A MPLS label or label stack. The following are examples of PPSIs:
o An IPv4 [RFC0791] header. o Remove any SRv6+ encapsulation and forward the SRv6+ payload
through a specified interface.
o An IPv6 [RFC8200] header. o Remove any SRv6+ encapsulation and forward the SRv6+ payload using
a specified routing table.
o A Generic Routing Encapsulation (GRE) [RFC2784] header SRv6+ encodes PPSIs in a new IPv6 option, called the PPSI Option.
encapsulated in IPv4 or IPv6. This document describes the PPSI Option.
Some PE devices cannot process MPLS headers. While these devices PPSIs can be used to support Virtual Private Networks (VPN).
have several alternatives to MPLS-based transport tunnels, they Therefore, Appendix A of this document describes VPN technology and
require an alternative to MPLS-based encoding of VPN context how PPSIs can be used to support a VPN.
information. This document defines a new IPv6 Destination Option
that can be used to encode VPN context information. It is applicable
when VPN payload is transported over IPv6.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. VPN Context Information 3. PPSI Identifiers
VPN context information specifies a forwarding procedure to be
executed by the egress PE. However, VPN context information values
are not globally mapped to forwarding procedures. Each egress PE
maps each forwarding procedure that it supports to a VPN context
information value. Therefore, VPN context information values are
locally scoped to the egress PE.
PE devices can acquire VPN Context Information:
o From one another, using a distributed, control plane protocol
(e.g., BGP [RFC4271] [RFC4760])
o From a controller.
The mechanisms by which PE devices acquire VPN Context Information
are beyond the scope of this document.
4. The VPN Context Information Option
0 1 2 3 PPSI Identifiers identify PPSIs. When a path egress node
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 instantiates a PPSI, it also allocates a PPSI Identifier and
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ associates the PPSI with the identifier.
| Option Type | Opt Data Len | VPN Context Information ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 1 PPSI Identifiers have node-local significance. This means that a
path egress node must assign a unique PPSI Identifier to each PPSI
that it instantiates. However, one path egress node can assign a
PPSI Identifier to an instruction that it instantiates, while another
path egress node can assign the same PPSI Identifier to a different
PPSI that it instantiates.
Figure 1 depicts the VPN Context Information Option. 4. The PPSI Option
Option fields are as follows: The PPSI Option contains the following fields:
o Option Type - VPN Context Information option. Value TBD by IANA. o Option Type: 8-bit selector. PPSI option. Value TBD by IANA.
See Notes below. (Suggested value: 144). See Note below.
o Opt Data Len - Length of Option Data, measured in bytes. o Opt Data Len - 8-bit unsigned integer. Length of the option, in
octets, excluding the Option Type and Option Length fields. This
field MUST be set to 4.
o VPN Context Information - Specifies a forwarding procedure to be o PPSI identifier - (32-bit selector). Identifies a PPSI.
executed by the egress PE.
The VPN Context Information Option MAY appear in a Destination The SRv6+ PPSI option MAY appear in a Destination Options header that
Options header that precedes an upper-layer header. It MUST NOT precedes an upper-layer header. It MUST NOT appear in a Hop-by-hop
appear in a Hop-by-hop Options header and SHOULD NOT appear in a Options header or in a Destination Options header that precedes a
Destination Options header that precedes a Routing header. If it Routing header.
appears in a Hop-by-hop Options header, the processing node will
discard the packet and send an ICMPv6 [RFC4443] Parameter Problem,
Code 2, message to the packet's Source Address, pointing to the
Option Type. If it appears in a Destination Options header that
precedes a Routing header, the processing node will attempt to
process the option, because it has not yet encountered the Routing
header.
If the VPN Context Information appears in a Destination Options When the SRv6+ PPSI option appears in a Destination Options header,
header, it SHOULD be the final option listed in the header. Because it MUST be the only option listed in the header. This is because the
the VPN Context Information Option causes the packet to be PPSI defines all path egress node behaviors.
decapsulated and forwarded, all options listed after the VPN Context
Information Option will be ignored.
NOTE 1: The highest-order two bits of the Option Type (i.e., the NOTE : The highest-order two bits of the Option Type (i.e., the "act"
"act" bits) are 10. These bits specify the action taken by a bits) are 10. These bits specify the action taken by a destination
destination node that does not recognize VPN Context Information node that does not recognize the option. The required action is to
option. The required action is to discard the packet and, regardless discard the packet and, regardless of whether or not the packet's
of whether or not the packet's Destination Address was a multicast Destination Address was a multicast address, send an ICMPv6 [RFC4443]
address, send an ICMPv6 Parameter Problem, Code 2, message to the Parameter Problem, Code 2, message to the packet's Source Address,
packet's Source Address, pointing to the unrecognized Option Type. pointing to the unrecognized Option Type.
NOTE 2: The third highest-order bit of the Option Type (i.e., the The third highest-order bit of the Option Type (i.e., the "chg" bit)
"chg" bit) is 0. This indicates that Option Data cannot be modified is 0. This indicates that Option Data cannot be modified along the
along the path between the packet's source and its destination. path between the packet's source and its destination.
5. Security Considerations 5. Destination Option Header Considerations
A VPN can be deployed: As per [RFC8200], the Destination Options header includes a Next
Header field. The Next Header field identifies the header following
the Destination Options header.
o In a walled-garden environment. SRv6+ can carry Ethernet payload after a Destination option header.
Therefore, this document requests IANA to assign a protocol number
for Ethernet. (The suggested value is 143.)
o In an over-the-top environment. 6. Security Considerations
In a walled-garden environment, all PE devices and all devices that SRv6+ domains MUST NOT span security domains. In order to enforce
connect PEs to one another reside in the same security domain. this requirement, security domain edge routers MUST do one of the
Therefore, there is no risk that a packet might be modified as it following:
travels from PE to PE.
In an over-the-top environment, all PE devices reside in one security o Discard all inbound SRv6+ packets
domain while devices that connect PEs to one another can reside in a
different security domain. In that case, there is significant risk
that a packet might be modified as it travels from PE to PE.
Therefore, the VPN Context Information option MUST be authenticated o Authenticate [RFC4302] [RFC4303] all inbound SRv6+ packets
when used in over-the-top environments. In this scenario, an IPv6
Encapsulating Security Payload (ESP) [RFC4303] MUST proceed the
Destination Options header that carries the VPN Context Information
option. The ESP integrity service MUST be enabled.
6. IANA Considerations 7. IANA Considerations
IANA is requested to allocate a codepoint from the Destination IANA is requested to allocate a code point from the Destination
Options and Hop-by-hop Options registry Options and Hop-by-hop Options registry
(https://www.iana.org/assignments/ipv6-parameters/ (https://www.iana.org/assignments/ipv6-parameters/
ipv6-parameters.xhtml#ipv6-parameters-2). This option is called "VPN ipv6-parameters.xhtml#ipv6-parameters-2). This option is called
Context Information". The "act" bits are 10 and the "chg" bit is 0. "Per-Path Service Instruction Option". The "act" bits are 10 and the
"chg" bit is 0. The suggested value is 144.
7. Acknowledgements IANA is also requested to allocate a code point for Ethernet from the
Assigned Internet Protocol Numbers registry
(https://www.iana.org/assignments/protocol-numbers/protocol-
numbers.xhtml). The suggested value is 143.
Thanks to Brian Carpenter, Adrian Farrel, Tom Herbert and John Leddy 8. Acknowledgements
for their comments.
8. References Thanks to Brian Carpenter, Adrian Farrel, Tom Herbert, John Leddy and
Tony Li for their comments.
8.1. Normative References 9. References
9.1. Normative References
[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+", draft-bonica-spring-srv6-plus-01 (work in
progress), July 2019.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
8.2. Informative References 9.2. Informative References
[I-D.ietf-6man-segment-routing-header]
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-16 (work in
progress), February 2019.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>. <https://www.rfc-editor.org/info/rfc2784>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<https://www.rfc-editor.org/info/rfc4761>. <https://www.rfc-editor.org/info/rfc4761>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP) LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<https://www.rfc-editor.org/info/rfc4762>. <https://www.rfc-editor.org/info/rfc4762>.
skipping to change at page 9, line 5 skipping to change at page 7, line 15
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>. 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and
Maintenance Using the Label Distribution Protocol (LDP)", Maintenance Using the Label Distribution Protocol (LDP)",
STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
<https://www.rfc-editor.org/info/rfc8077>. <https://www.rfc-editor.org/info/rfc8077>.
Appendix A. Virtual Private Networks (VPN)
Virtual Private Network (VPN) technologies allow network providers to
emulate private networks with shared infrastructure. For example,
assume that red sites and blue sites connect to a provider network.
The provider network facilitates communication among red sites and
facilitates communication among blue sites. However, it prevents
communication between red sites and blue sites.
The IETF has standardized many VPN technologies, including:
o Layer 2 VPN (L2VPN) [RFC6624].
o Layer 3 VPN (L3VPN) [RFC4364].
o Virtual Private LAN Service (VPLS) [RFC4761][RFC4762].
o Ethernet VPN (EVPN) [RFC7432].
o Pseudowires [RFC8077].
The above-mentioned technologies include the following components:
o Customer Edge (CE) devices.
o Provider Edge (PE) devices.
o Routing Instances.
o Service Instructions.
o Service Instruction Identifiers.
o Transport tunnels.
CE devices participate in closed communities called VPNs. CEs that
participate in one VPN can communicate with one another but cannot
communicate with CEs that participate in another VPN.
CE devices connect to provider networks through PE devices. Each PE
maintains one Routing Instance for each VPN that it supports. A
Routing Instance is a VPN specific Forwarding Information Base (FIB).
In EVPN, Routing Instances are called Ethernet Virtual Instances
(EVI).
Assume that one CE sends a packet through a provider network to
another CE. The packet enters the provider network through an
ingress PE and leaves the provider network through an egress PE. The
packet may traverse one or more intermediate nodes on route from PE
to PE.
When the ingress PE receives the packet, it:
o Identifies the Routing Instance that supports the originating CE's
VPN.
o Searches that Routing Instance for the packet's destination.
If the search fails, the ingress PE discards the packet. If the
search succeeds, it yields the following:
o A Service Instruction Identifier.
o The egress PE's IP address.
The ingress PE prepends the Service Instruction Identifier and a
transport header to the packet, in that order. It then forwards the
packet through a transport tunnel to the egress PE.
The egress PE removes the transport header, if it has not already
been removed by an upstream device. It then examines and removes the
Service Instruction Identifier. Finally, it executes a service
instruction that is associated with the Service Instruction
Identifier. The service instruction causes the egress PE to forward
the packet to its destination (i.e., a directly connected CE).
In the above-mentioned VPN technologies, the ingress PE encodes
Service Instruction Identifiers in Multiprotocol Label Switching
(MPLS) [RFC3031] labels. Depending upon the transport tunnel type,
the transport header can be:
o A MPLS label or label stack.
o An IPv4 [RFC0791] header.
o An IPv6 [RFC8200] header.
o A Generic Routing Encapsulation (GRE) [RFC2784] header
encapsulated in IPv4 or IPv6.
Some PE devices cannot process MPLS headers. While these devices
have several alternatives to MPLS-based transport tunnels, they
require an alternative to MPLS-based encoding of Service Instruction
Identifiers. The PPSI Option can be used to encode Service
Instruction Identifiers . It is applicable when VPN payload is
transported over IPv6.
Authors' Addresses Authors' Addresses
Ron Bonica Ron Bonica
Juniper Networks Juniper Networks
2251 Corporate Park Drive 2251 Corporate Park Drive
Herndon, Virginia 20171 Herndon, Virginia 20171
USA USA
Email: rbonica@juniper.net Email: rbonica@juniper.net
Yuji Kamite
NTT Communications Corporation
3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
Email: : y.kamite@ntt.com
Chris Lenart Chris Lenart
Verizon Verizon
22001 Loudoun County Parkway 22001 Loudoun County Parkway
Ashburn, Virginia 20147 Ashburn, Virginia 20147
USA USA
Email: chris.lenart@verizon.com Email: chris.lenart@verizon.com
Ning So Ning So
Reliance Jio Reliance Jio
 End of changes. 46 change blocks. 
204 lines changed or deleted 225 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/