| < draft-ietf-bess-evpn-vpws-10.txt | draft-ietf-bess-evpn-vpws-14.txt > | |||
|---|---|---|---|---|
| skipping to change at page 1, line 13 ¶ | skipping to change at page 1, line 13 ¶ | |||
| INTERNET-DRAFT Sami Boutros | INTERNET-DRAFT Sami Boutros | |||
| Intended Status: Standard Track VMware | Intended Status: Standard Track VMware | |||
| Ali Sajassi | Ali Sajassi | |||
| Samer Salam | Samer Salam | |||
| Cisco Systems | Cisco Systems | |||
| John Drake | John Drake | |||
| Juniper Networks | Juniper Networks | |||
| J. Rabadan | J. Rabadan | |||
| Nokia | Nokia | |||
| Expires: September 1, 2017 February 28, 2017 | Expires: November 15, 2017 May 14, 2017 | |||
| VPWS support in EVPN | Virtual Private Wire Service support in Ethernet VPN | |||
| draft-ietf-bess-evpn-vpws-10.txt | draft-ietf-bess-evpn-vpws-14.txt | |||
| Abstract | Abstract | |||
| This document describes how EVPN can be used to support Virtual | This document describes how Ethernet VPN (EVPN) can be used to | |||
| Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the | support Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN | |||
| following characteristics for VPWS: single-active as well as all- | enables the following characteristics for VPWS: single-active as well | |||
| active multi-homing with flow-based load-balancing, eliminates the | as all-active multi-homing with flow-based load-balancing, eliminates | |||
| need for traditional way of PW signaling, and provides fast | the need for Pseudowire (PW) signaling, and provides fast protection | |||
| protection convergence upon node or link failure. | convergence upon node or link failure. | |||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as | other groups may also distribute working documents as | |||
| Internet-Drafts. | Internet-Drafts. | |||
| skipping to change at page 2, line 21 ¶ | skipping to change at page 2, line 21 ¶ | |||
| 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2 Service interface . . . . . . . . . . . . . . . . . . . . . . . 5 | 2 Service interface . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 2.1 VLAN-Based Service Interface . . . . . . . . . . . . . . . . 5 | 2.1 VLAN-Based Service Interface . . . . . . . . . . . . . . . . 6 | |||
| 2.2 VLAN Bundle Service Interface . . . . . . . . . . . . . . . 6 | 2.2 VLAN Bundle Service Interface . . . . . . . . . . . . . . . 6 | |||
| 2.2.1 Port-Based Service Interface . . . . . . . . . . . . . . 6 | 2.2.1 Port-Based Service Interface . . . . . . . . . . . . . . 7 | |||
| 2.3 VLAN-Aware Bundle Service Interface . . . . . . . . . . . . 6 | 2.3 VLAN-Aware Bundle Service Interface . . . . . . . . . . . . 7 | |||
| 3. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 6 | 3. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 3.1 EVPN Layer 2 attributes extended community . . . . . . . . . 7 | 3.1 EVPN Layer 2 attributes extended community . . . . . . . . . 7 | |||
| 4 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 4 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 5 EVPN Comparison to PW Signaling . . . . . . . . . . . . . . . . 10 | 5 EVPN Comparison to PW Signaling . . . . . . . . . . . . . . . . 11 | |||
| 6 Failure Scenarios . . . . . . . . . . . . . . . . . . . . . . . 11 | 6 Failure Scenarios . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 6.1 Single-Homed CEs . . . . . . . . . . . . . . . . . . . . . . 11 | 6.1 Single-Homed CEs . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 6.2 Multi-Homed CEs . . . . . . . . . . . . . . . . . . . . . . 11 | 6.2 Multi-Homed CEs . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 | 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 11 | 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 | |||
| 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 | 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 10.1 Normative References . . . . . . . . . . . . . . . . . . . 12 | 10.1 Normative References . . . . . . . . . . . . . . . . . . . 13 | |||
| 10.2 Informative References . . . . . . . . . . . . . . . . . . 12 | 10.2 Informative References . . . . . . . . . . . . . . . . . . 13 | |||
| Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 1 Introduction | 1 Introduction | |||
| This document describes how EVPN can be used to support Virtual | This document describes how EVPN can be used to support VPWS in | |||
| Private Wire Service (VPWS) in MPLS/IP networks. The use of EVPN | MPLS/IP networks. The use of EVPN mechanisms for VPWS (EVPN-VPWS) | |||
| mechanisms for VPWS (EVPN-VPWS) brings the benefits of EVPN to p2p | brings the benefits of EVPN to Point to Point (P2P) services. These | |||
| services. These benefits include single-active redundancy as well as | benefits include single-active redundancy as well as all-active | |||
| all-active redundancy with flow-based load-balancing. Furthermore, | redundancy with flow-based load-balancing. Furthermore, the use of | |||
| the use of EVPN for VPWS eliminates the need for traditional way of | EVPN for VPWS eliminates the need for traditional way of PW signaling | |||
| PW signaling for p2p Ethernet services, as described in section 4. | for P2P Ethernet services, as described in section 4. | |||
| [RFC7432] has the ability to forward customer traffic to/from a given | [RFC7432] provides the ability to forward customer traffic to/from a | |||
| customer Attachment Circuit (AC), without any MAC lookup. This | given customer Attachment Circuit (AC), without any Media Access | |||
| capability is ideal in providing p2p services (aka VPWS services). | Control (MAC) lookup. This capability is ideal in providing P2P | |||
| [MEF] defines Ethernet Virtual Private Line (EVPL) service as p2p | services (aka VPWS services). [MEF] defines Ethernet Virtual Private | |||
| service between a pair of ACs (designated by VLANs) and Ethernet | Line (EVPL) service as P2P service between a pair of ACs (designated | |||
| Private Line (EPL) service, in which all traffic flows are between a | by VLANs) and Ethernet Private Line (EPL) service, in which all | |||
| single pair of ports, that in EVPN terminology would mean a single | traffic flows are between a single pair of ports, that in EVPN | |||
| pair of Ethernet Segments ES(es). EVPL can be considered as a VPWS | terminology would mean a single pair of Ethernet Segments ES(es). | |||
| with only two ACs. In delivering an EVPL service, the traffic | EVPL can be considered as a VPWS with only two ACs. In delivering an | |||
| forwarding capability of EVPN based on the exchange of a pair of | EVPL service, the traffic forwarding capability of EVPN is based on | |||
| Ethernet Auto-discovery (A-D) routes is used; whereas, for more | the exchange of a pair of Ethernet Auto-discovery (A-D) routes; | |||
| general VPWS as per [RFC4664], traffic forwarding capability of EVPN | whereas, for more general VPWS as per [RFC4664], traffic forwarding | |||
| based on the exchange of a group of Ethernet AD routes (one Ethernet | capability of EVPN is based on the exchange of a group of Ethernet AD | |||
| AD route per AC/ES) is used. In a VPWS service, the traffic from an | routes (one Ethernet AD route per AC/ES). In a VPWS service, the | |||
| originating Ethernet Segment can be forwarded only to a single | traffic from an originating Ethernet Segment can be forwarded only to | |||
| destination Ethernet Segment; hence, no MAC lookup is needed and the | a single destination Ethernet Segment; hence, no MAC lookup is needed | |||
| MPLS label associated with the per EVPN instance (EVI) Ethernet A-D | and the MPLS label associated with the per EVPN instance (EVI) | |||
| route can be used in forwarding user traffic to the destination AC. | Ethernet A-D route can be used in forwarding user traffic to the | |||
| destination AC. | ||||
| For both EPL and EVPL services, a specific VPWS service instance is | For both EPL and EVPL services, a specific VPWS service instance is | |||
| identified by a pair of per EVI Ethernet A-D routes which together | identified by a pair of per-EVI Ethernet A-D routes which together | |||
| identify the VPWS service instance endpoints and the VPWS service | identify the VPWS service instance endpoints and the VPWS service | |||
| instance. In the control plane the VPWS service instance is | instance. In the control plane the VPWS service instance is | |||
| identified using the VPWS service instance identifiers advertised by | identified using the VPWS service instance identifiers advertised by | |||
| each PE and in the data plane the value of the MPLS label advertised | each Provider Edge node (PE). In the data plane the value of the MPLS | |||
| by one PE is used by the other PE to send traffic for that VPWS | label advertised by one PE is used by the other PE to send traffic | |||
| service instance. As with the Ethernet Tag in standard EVPN, the VPWS | for that VPWS service instance. As with the Ethernet Tag in standard | |||
| service instance identifier has uniqueness within an EVPN instance. | EVPN, the VPWS service instance identifier has uniqueness within an | |||
| EVPN instance. | ||||
| Unlike EVPN where Ethernet Tag ID in EVPN routes are set to zero for | For EVPN routes, the Ethernet Tag IDs are set to zero for Port-based, | |||
| Port-based, vlan-based, and vlan-bundle interface mode and it is set | VLAN-based, and VLAN-bundle interface mode and set to non-zero | |||
| to non-zero Ethernet tag ID for vlan-aware bundle mode, in EVPN-VPWS, | Ethernet Tag IDs for VLAN-aware bundle mode. Conversely, for EVPN- | |||
| for all the four interface modes, Ethernet tag ID in the Ethernet A-D | VPWS, the Ethernet Tag ID in the Ethernet A-D route MUST be set to a | |||
| route MUST be set to a non-zero value in all the service interface | non-zero value for all four service interface types. | |||
| types. | ||||
| In terms of route advertisement and MPLS label lookup behavior, EVPN- | In terms of route advertisement and MPLS label lookup behavior, EVPN- | |||
| VPWS resembles the vlan-aware bundle mode of [RFC7432] such that when | VPWS resembles the VLAN-aware bundle mode of [RFC7432] such that when | |||
| a PE advertises per EVI Ethernet A-D route, the VPWS service instance | a PE advertises per-EVI Ethernet A-D route, the VPWS service instance | |||
| serves as a 32-bit normalized Ethernet tag ID. The value of the MPLS | serves as a 32-bit normalized Ethernet Tag ID. The value of the MPLS | |||
| label in this route represents both the EVI and the VPWS service | label in this route represents both the EVI and the VPWS service | |||
| instance, so that upon receiving an MPLS encapsulated packet, the | instance, so that upon receiving an MPLS encapsulated packet, the | |||
| disposition PE can identify the egress AC from the lookup of the MPLS | disposition PE can identify the egress AC from the MPLS label and | |||
| label alone and perform any required tag translation. For EVPL | subsequently perform any required tag translation. For EVPL service, | |||
| service, the Ethernet frames transported over an MPLS/IP network | the Ethernet frames transported over an MPLS/IP network SHOULD remain | |||
| SHOULD remain tagged with the originating Vlan-ID (VID) and any VID | tagged with the originating VLAN-ID (VID) and any VID translation | |||
| translation MUST be performed at the disposition PE. For EPL service, | MUST be performed at the disposition PE. For EPL service, the | |||
| the Ethernet frames are transported as is and the tags are not | Ethernet frames are transported as is and the tags are not altered. | |||
| altered. | ||||
| The MPLS label value in the Ethernet A-D route can be set to the | The MPLS label value in the Ethernet A-D route can be set to the | |||
| VXLAN Network Identifier (VNI) for VxLAN encap, and this VNI may have | Virtual Extensible LAN (VXLAN) Network Identifier (VNI) for VXLAN | |||
| a global scope or local scope per PE and may also be made equal to | encapsulation as per [RFC7348], and this VNI will have a local scope | |||
| the VPWS service instance identifier set in the Ethernet A-D route. | per PE and may also be equal to the VPWS service instance identifier | |||
| set in the Ethernet A-D route. When using VXLAN encap, the BGP | ||||
| Encapsulation extended community is included in the Ethernet A-D | ||||
| route as described in [ietf-evpn-overlay]. The VXLAN VNI like the | ||||
| MPLS label that will be set in the tunnel header used to tunnel | ||||
| Ethernet packets from all the service interface types defined in | ||||
| section 2. The EVPN-VPWS techniques defined in this document has no | ||||
| dependency on the tunneling technology. | ||||
| The Ethernet Segment identifier encoded in the Ethernet A-D per EVI | The Ethernet Segment identifier encoded in the Ethernet A-D per-EVI | |||
| route is not used to identify the service, however it can be used for | route is not used to identify the service. However it can be used for | |||
| flow-based load-balancing and mass withdraw functions as per | flow-based load-balancing and mass withdraw functions as per the | |||
| [RFC7432] baseline. | [RFC7432] baseline. | |||
| As with standard EVPN, the Ethernet A-D per ES route is used for fast | As with standard EVPN, the Ethernet A-D per-ES route is used for fast | |||
| convergence upon link or node failure and the Ethernet Segment route | convergence upon link or node failure. The Ethernet Segment route is | |||
| is used for auto-discovery of the PEs attached to a given multi-homed | used for auto-discovery of the PEs attached to a given multi-homed | |||
| CE and to synchronize state between them. | Customer Edge node (CE) and to synchronize state between them. | |||
| 1.1 Terminology | 1.1 Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
| EVPN: Ethernet VPN | ||||
| MAC: Media Access Control | MAC: Media Access Control | |||
| MPLS: Multi Protocol Label Switching. | MPLS: Multi Protocol Label Switching. | |||
| OAM: Operations, Administration and Maintenance. | OAM: Operations, Administration and Maintenance. | |||
| PE: Provide Edge Node. | PE: Provide Edge Node. | |||
| ASBR: Autonomous System Border Router | ||||
| CE: Customer Edge device e.g., host or router or switch. | CE: Customer Edge device e.g., host or router or switch. | |||
| EVPL: Ethernet Virtual Private Line. | EVPL: Ethernet Virtual Private Line. | |||
| EPL: Ethernet Private Line. | EPL: Ethernet Private Line. | |||
| EP-LAN: Ethernet Private LAN. | EP-LAN: Ethernet Private LAN. | |||
| EVP-LAN: Ethernet Virtual Private LAN. | EVP-LAN: Ethernet Virtual Private LAN. | |||
| S-VLAN: Service VLAN identifier. | S-VLAN: Service VLAN identifier. | |||
| C-VLAN: Customer VLAN identifier. | C-VLAN: Customer VLAN identifier. | |||
| VID: VLAN-ID. | ||||
| VPWS: Virtual Private Wire Service. | VPWS: Virtual Private Wire Service. | |||
| EVI: EVPN Instance. | EVI: EVPN Instance. | |||
| P2P: Point to Point. | ||||
| VXLAN: Virtual Extensible LAN. | ||||
| DF: Designated Forwarder. | ||||
| L2: Layer 2. | ||||
| MTU: Maximum Transmission Unit. | ||||
| eBGP: Exterior Border Gateway Protocol. | ||||
| iBGP: Internal Border Gateway Protocol. | ||||
| ES: Ethernet Segment on a PE refers to the link attached to it, this | ES: Ethernet Segment on a PE refers to the link attached to it, this | |||
| link can be part of a set of links attached to different PEs in multi | link can be part of a set of links attached to different PEs in multi | |||
| homed cases, or could be a single link in single homed cases. | homed cases, or could be a single link in single homed cases. | |||
| ESI: Ethernet Segment Identifier. | ESI: Ethernet Segment Identifier. | |||
| Single-Active Mode: When a device or a network is multi-homed to two | Single-Active Mode: When a device or a network is multi-homed to two | |||
| or more PEs and when only a single PE in such redundancy group can | or more PEs and when only a single PE in such redundancy group can | |||
| forward traffic to/from the multi-homed device or network for a given | forward traffic to/from the multi-homed device or network for a given | |||
| VLAN, then such multi-homing or redundancy is referred to as "Single- | VLAN, then such multi-homing or redundancy is referred to as "Single- | |||
| skipping to change at page 5, line 49 ¶ | skipping to change at page 6, line 28 ¶ | |||
| one VPWS service identifier. | one VPWS service identifier. | |||
| 2 Service interface | 2 Service interface | |||
| 2.1 VLAN-Based Service Interface | 2.1 VLAN-Based Service Interface | |||
| With this service interface, a VPWS instance identifier corresponds | With this service interface, a VPWS instance identifier corresponds | |||
| to only a single VLAN on a specific interface. Therefore, there is a | to only a single VLAN on a specific interface. Therefore, there is a | |||
| one-to-one mapping between a VID on this interface and the VPWS | one-to-one mapping between a VID on this interface and the VPWS | |||
| service instance identifier. The PE provides the cross-connect | service instance identifier. The PE provides the cross-connect | |||
| functionality between MPLS LSP identified by the VPWS service | functionality between an MPLS LSP identified by the VPWS service | |||
| instance identifier and a specific <port,VLAN>. If the VLAN is | instance identifier and a specific <port,VLAN>. If the VLAN is | |||
| represented by different VIDs on different PEs and different ES(es) | represented by different VIDs on different PEs and different ES(es), | |||
| (e.g., a different VID per Ethernet segment per PE), then each PE | (e.g., a different VID per Ethernet segment per PE), then each PE | |||
| needs to perform VID translation for frames destined to its Ethernet | needs to perform VID translation for frames destined to its Ethernet | |||
| segment. In such scenarios, the Ethernet frames transported over an | segment. In such scenarios, the Ethernet frames transported over an | |||
| MPLS/IP network SHOULD remain tagged with the originating VID, and a | MPLS/IP network SHOULD remain tagged with the originating VID, and a | |||
| VID translation MUST be supported in the data path and MUST be | VID translation MUST be supported in the data path and MUST be | |||
| performed on the disposition PE. | performed on the disposition PE. | |||
| 2.2 VLAN Bundle Service Interface | 2.2 VLAN Bundle Service Interface | |||
| With this service interface, a VPWS service instance identifier | With this service interface, a VPWS service instance identifier | |||
| corresponds to multiple VLANs on a specific interface. The PE | corresponds to multiple VLANs on a specific interface. The PE | |||
| provides the cross-connect functionality between MPLS label | provides the cross-connect functionality between the MPLS label | |||
| identified by the VPWS service instance identifier and a group of | identified by the VPWS service instance identifier and a group of | |||
| VLANs on a specific interface. For this service interface, each VLAN | VLANs on a specific interface. For this service interface, each VLAN | |||
| is presented by a single VID which means no VLAN translation is | is presented by a single VID which means no VLAN translation is | |||
| allowed. The receiving PE, can direct the traffic based on EVPN label | allowed. The receiving PE, can direct the traffic based on EVPN label | |||
| alone to a specific port. The transmitting PE can cross connect | alone to a specific port. The transmitting PE can cross-connect | |||
| traffic from a group of VLANs on a specific port to the MPLS label. | traffic from a group of VLANs on a specific port to the MPLS label. | |||
| The MPLS-encapsulated frames MUST remain tagged with the originating | The MPLS-encapsulated frames MUST remain tagged with the originating | |||
| VID. | VID. | |||
| 2.2.1 Port-Based Service Interface | 2.2.1 Port-Based Service Interface | |||
| This service interface is a special case of the VLAN bundle service | This service interface is a special case of the VLAN bundle service | |||
| interface, where all of the VLANs on the port are mapped to the same | interface, where all of the VLANs on the port are mapped to the same | |||
| VPWS service instance identifier. The procedures are identical to | VPWS service instance identifier. The procedures are identical to | |||
| those described in Section 2.2. | those described in Section 2.2. | |||
| 2.3 VLAN-Aware Bundle Service Interface | 2.3 VLAN-Aware Bundle Service Interface | |||
| Contrary to EVPN, in EVPN-VPWS this service interface maps to VLAN- | Contrary to EVPN, in EVPN-VPWS this service interface maps to a VLAN- | |||
| based service interface (defined in section 2.1) and thus this | based service interface (defined in section 2.1) and thus this | |||
| service interface is not used in EVPN-VPWS. In other words, if one | service interface is not used in EVPN-VPWS. In other words, if one | |||
| tries to define data-plane and control plane behavior for this | tries to define data plane and control plane behavior for this | |||
| service interface, he would realize that it is the same as that of | service interface, one would realize that it is the same as that of | |||
| VLAN-based service. | VLAN-based service. | |||
| 3. BGP Extensions | 3. BGP Extensions | |||
| This document specifies the use of the per EVI Ethernet A-D route to | This document specifies the use of the per-EVI Ethernet A-D route to | |||
| signal VPWS services. The Ethernet Segment Identifier field is set to | signal VPWS services. The Ethernet Segment Identifier field is set to | |||
| the customer ES and the Ethernet Tag ID 32-bit field MUST be set to | the customer ES and the Ethernet Tag ID 32-bit field MUST be set to | |||
| the VPWS service instance identifier value, the VPWS service instance | the VPWS service instance identifier value. The VPWS service instance | |||
| identifier value MAY be set to a 24-bit value, when 24-bit value is | identifier value MAY be set to a 24-bit value and when a 24-bit value | |||
| used, it MUST be right aligned. For both EPL and EVPL services, for a | is used, it MUST be right aligned. For both EPL and EVPL services | |||
| given VPWS service instance the pair of PEs instantiating that VPWS | using a given VPWS service instance, the pair of PEs instantiating | |||
| service instance will each advertise a per EVI Ethernet A-D route | that VPWS service instance will each advertise a per-EVI Ethernet A-D | |||
| with its VPWS service instance identifier and will each be configured | route with its VPWS service instance identifier and will each be | |||
| with the other PE's VPWS service instance identifier. When each PE | configured with the other PE's VPWS service instance identifier. When | |||
| has received the other PE's per EVI Ethernet A-D route the VPWS | each PE has received the other PE's per-EVI Ethernet A-D route, the | |||
| service instance is instantiated. It should be noted that the same | VPWS service instance is instantiated. It should be noted that the | |||
| VPWS service instance identifier may be configured on both PEs. | same VPWS service instance identifier may be configured on both PEs. | |||
| The Route-Target (RT) extended community with which the per EVI | The Route-Target (RT) extended community with which the per-EVI | |||
| Ethernet A-D route is tagged identifies the EVPN instance in which | Ethernet A-D route is tagged identifies the EVPN instance in which | |||
| the VPWS service instance is configured. It is the operator's choice | the VPWS service instance is configured. It is the operator's choice | |||
| as to how many and which VPWS service instances are configured in a | as to how many and which VPWS service instances are configured in a | |||
| given EVPN instance. However, a given EVPN instance MUST NOT be | given EVPN instance. However, a given EVPN instance MUST NOT be | |||
| configured with both VPWS service instances and standard EVPN multi- | configured with both VPWS service instances and standard EVPN multi- | |||
| point services. | point services. | |||
| 3.1 EVPN Layer 2 attributes extended community | 3.1 EVPN Layer 2 attributes extended community | |||
| This draft proposes a new extended community [RFC4360], to be | This document defines a new extended community [RFC4360], to be | |||
| included with the per EVI Ethernet A-D route. This attribute is | included with per-EVI Ethernet A-D routes. This attribute is | |||
| mandatory if multihoming is enabled. | mandatory if multihoming is enabled. | |||
| +------------------------------------+ | +------------------------------------+ | |||
| | Type(0x06)/Sub-type(0x04)(2 octet)| | | Type(0x06)/Sub-type(0x04)(2 octet)| | |||
| +------------------------------------+ | +------------------------------------+ | |||
| | Control Flags (2 octets) | | | Control Flags (2 octets) | | |||
| +------------------------------------+ | +------------------------------------+ | |||
| | L2 MTU (2 octets) | | | L2 MTU (2 octets) | | |||
| +------------------------------------+ | +------------------------------------+ | |||
| | Reserved (2 octets) | | | Reserved (2 octets) | | |||
| skipping to change at page 8, line 10 ¶ | skipping to change at page 8, line 37 ¶ | |||
| P If set to 1 in multihoming single-active scenarios, it | P If set to 1 in multihoming single-active scenarios, it | |||
| indicates that the advertising PE is the Primary PE. | indicates that the advertising PE is the Primary PE. | |||
| MUST be set to 1 for multihoming all-active scenarios by | MUST be set to 1 for multihoming all-active scenarios by | |||
| all active PE(s). | all active PE(s). | |||
| B If set to 1 in multihoming single-active scenarios, it | B If set to 1 in multihoming single-active scenarios, it | |||
| indicates that the advertising PE is the Backup PE. | indicates that the advertising PE is the Backup PE. | |||
| C If set to 1, a Control word [RFC4448] MUST be present | C If set to 1, a Control word [RFC4448] MUST be present | |||
| when sending EVPN packets to this PE. | when sending EVPN packets to this PE. It is recommended to | |||
| include the control word in the absence of Entropy Label. | ||||
| L2 MTU (Maximum Transmission Unit) is a 2-octet value indicating the | L2 MTU (Maximum Transmission Unit) is a 2-octet value indicating the | |||
| MTU in bytes. | MTU in bytes. | |||
| A received L2 MTU=0 means no MTU checking against local MTU is | A received L2 MTU of zero means no MTU checking against local MTU is | |||
| needed. A received non-zero MTU MUST be checked against local MTU and | needed. A received non-zero MTU MUST be checked against local MTU and | |||
| if there is a mismatch, the local PE MUST NOT add the remote PE as | if there is a mismatch, the local PE MUST NOT add the remote PE as | |||
| the EVPN destination for the corresponding VPWS service instance. | the EVPN destination for the corresponding VPWS service instance. | |||
| The usage of the Per ES Ethernet A-D route is unchanged from its | The usage of the Per ES Ethernet A-D route is unchanged from its | |||
| usage in [RFC7432], i.e. the "Single-Active" bit in the flags of the | usage in [RFC7432], i.e., the "Single-Active" bit in the flags of the | |||
| ESI Label extended community will indicate if single-active or all- | ESI Label extended community will indicate if single-active or all- | |||
| active redundancy is used for this ES. | active redundancy is used for this ES. | |||
| In multihoming scenarios, both B and P flags MUST NOT be both set. A | In multihoming scenarios, the B and P flags MUST be cleared. A PE | |||
| PE that receives an update with both B and P flags set MUST treat the | that receives an update with both B and P flags set MUST treat the | |||
| route as a withdrawal. If the PE receives a route with both B and P | route as a withdrawal. If the PE receives a route with both B and P | |||
| unset, it MUST discard the received route from the sender PE. | clear, it MUST treat the route as a withdrawal from the sender PE. | |||
| In a multihoming all-active scenario, there is no DF election, and | In a multihoming all-active scenario, there is no Designated | |||
| all the PEs in the ES that are active and ready to forward traffic | Forwarder (DF) election, and all the PEs in the ES that are active | |||
| to/from the CE will set the P Flag to 1. A remote PE will do per-flow | and ready to forward traffic to/from the CE will set the P Flag. A | |||
| load balancing to the PEs that send P=1 for the same Ethernet Tag and | remote PE will do per-flow load-balancing to the PEs that set the P | |||
| ESI. B Flag in control flags SHOULD NOT be set in the multihoming | Flag for the same Ethernet Tag and ESI. The B Flag in control flags | |||
| all-active scenario and MUST be ignored by receiving PE(s) if set. | SHOULD NOT be set in the multihoming all-active scenario and MUST be | |||
| ignored by receiving PE(s) if set. | ||||
| In multihoming single-active scenario, for a given VPWS service | In multihoming single-active scenario for a given VPWS service | |||
| instance, in steady state, as result of DF election, the Primary | instance, the DF election should result in the Primary-elected PE for | |||
| elected PE for the VPWS service instance should signal P=1,B=0, the | the VPWS service instance advertising the P Flag set and the B Flag | |||
| Backup elected PE should signal P=0,B=1, and the rest of the PEs in | clear, the Backup elected PE should advertise the P Flag clear and | |||
| the same ES should signal P=0,B=0. When the primary PE/ES fails, the | the B Flag set, and the rest of the PEs in the same ES should signal | |||
| primary PE will withdraw the associated Ethernet A-D routes for the | both P and B Flags clear. When the primary PE/ES fails, the primary | |||
| VPWS service instance from the remote PE, the remote PEs should then | PE will withdraw the associated Ethernet A-D routes for the VPWS | |||
| service instance from the remote PE and the remote PEs should then | ||||
| send traffic associated with the VPWS instance to the backup PE. DF | send traffic associated with the VPWS instance to the backup PE. DF | |||
| re-election will happen between the PE(s) in the same ES, and there | re-election will happen between the PE(s) in the same ES, and there | |||
| will be a new elected primary PE and new elected backup PE that will | will be a newly elected primary PE and newly elected backup PE that | |||
| signal the P and B Flags as described. A remote PE SHOULD receive P=1 | will signal the P and B Flags as described. A remote PE SHOULD | |||
| from only one Primary PE and a B=1 from only one Backup PE. However | receive the P Flag set from only one Primary PE and the B Flag set | |||
| during transient situations, a remote PE receiving P=1 from more than | from only one Backup PE. However during transient situations, a | |||
| one PE will select the last advertising PE as the primary PE when | remote PE receiving a P Flag set from more than one PE will select | |||
| forwarding traffic. A remote PE receiving B=1 from more than one PE | the last advertising PE as the primary PE when forwarding traffic. A | |||
| will select only one backup PE. A remote PE MUST receive P=1 from at | remote PE receiving a B Flag set from more than one PE will select | |||
| least one PE before forwarding traffic. | the last advertising PE as the backup PE. A remote PE MUST receive P | |||
| Flag set from at least one PE before forwarding traffic. | ||||
| If a network uses entropy labels per [RFC6790] then the C Flag MUST | If a network uses entropy labels per [RFC6790] then the C Flag MUST | |||
| NOT be set to 1 and control word MUST NOT be used when sending EVPN- | NOT be set and control word MUST NOT be used when sending EVPN- | |||
| encapsulated packets over a P2P LSP. | encapsulated packets over a P2P LSP. | |||
| 4 Operation | 4 Operation | |||
| The following figure shows an example of a P2P service deployed with | The following figure shows an example of a P2P service deployed with | |||
| EVPN. | EVPN. | |||
| Ethernet Ethernet | Ethernet Ethernet | |||
| Native |<--------- EVPN Instance ----------->| Native | Native |<--------- EVPN Instance ----------->| Native | |||
| Service | | Service | Service | | Service | |||
| (AC) | |<-PSN1->| |<-PSN2->| | (AC) | (AC) | |<-PSN1->| |<-PSN2->| | (AC) | |||
| skipping to change at page 9, line 41 ¶ | skipping to change at page 10, line 25 ¶ | |||
| | EVPN Inter-provider point | | | EVPN Inter-provider point | | |||
| | | | | | | |||
| |<---------------- Emulated Service -------------------->| | |<---------------- Emulated Service -------------------->| | |||
| Figure 3: EVPN-VPWS Deployment Model | Figure 3: EVPN-VPWS Deployment Model | |||
| iBGP sessions are established between PE1, PE2, ASBR1 and ASBR3, | iBGP sessions are established between PE1, PE2, ASBR1 and ASBR3, | |||
| possibly via a BGP route-reflector. Similarly, iBGP sessions are | possibly via a BGP route-reflector. Similarly, iBGP sessions are | |||
| established between PE3, PE4, ASBR2 and ASBR4. eBGP sessions are | established between PE3, PE4, ASBR2 and ASBR4. eBGP sessions are | |||
| established among ASBR1, ASBR2, ASBR3, and ASBR4. | established among ASBR1, ASBR2, ASBR3, and ASBR4. | |||
| All PEs and ASBRs are enabled for the EVPN SAFI and exchange per EVI | All PEs and ASBRs are enabled for the EVPN SAFI and exchange per-EVI | |||
| Ethernet A-D routes, one route per VPWS service instance. For inter- | Ethernet A-D routes, one route per VPWS service instance. For inter- | |||
| AS option B, the ASBRs re-advertise these routes with NEXT_HOP | AS option B, the ASBRs re-advertise these routes with the NEXT_HOP | |||
| attribute set to their IP addresses as per [RFC4271]. The link | attribute set to their IP addresses as per [RFC4271]. The link | |||
| between the CE and the PE is either a C-tagged or S-tagged interface, | between the CE and the PE is either a C-tagged or S-tagged interface, | |||
| as described in [802.1Q], that can carry a single VLAN tag or two | as described in [802.1Q], that can carry a single VLAN tag or two | |||
| nested VLAN tags and it is configured as a trunk with multiple VLANs, | nested VLAN tags and it is configured as a trunk with multiple VLANs, | |||
| one per VPWS service instance. It should be noted that the VLAN ID | one per VPWS service instance. It should be noted that the VLAN ID | |||
| used by the customer at either end of a VPWS service instance to | used by the customer at either end of a VPWS service instance to | |||
| identify that service instance may be different and EVPN doesn't | identify that service instance may be different and EVPN doesn't | |||
| perform that translation between the two values. Rather, the MPLS | perform that translation between the two values. Rather, the MPLS | |||
| label will identify the VPWS service instance and if translation is | label will identify the VPWS service instance and if translation is | |||
| needed, it should be done by the Ethernet interface for each service. | needed, it should be done by the Ethernet interface for each service. | |||
| For single-homed CE, in an advertised per EVI Ethernet A-D route the | For single-homed CE, in an advertised per-EVI Ethernet A-D route the | |||
| ESI field is set to 0 and the Ethernet Tag ID is set to the VPWS | ESI field is set to 0 and the Ethernet Tag ID is set to the VPWS | |||
| service instance identifier that identifies the EVPL or EPL service. | service instance identifier that identifies the EVPL or EPL service. | |||
| For a multi-homed CE, in an advertised per EVI Ethernet A-D route the | For a multi-homed CE, in an advertised per-EVI Ethernet A-D route the | |||
| ESI field is set to the CE's ESI and the Ethernet Tag ID is set to | ESI field is set to the CE's ESI and the Ethernet Tag ID is set to | |||
| the VPWS service instance identifier, which MUST have the same value | the VPWS service instance identifier, which MUST have the same value | |||
| on all PEs attached to that ES. This allows an ingress PE in a | on all PEs attached to that ES. This allows an ingress PE in a | |||
| multihoming all-active scenario to perform flow-based load-balancing | multihoming all-active scenario to perform flow-based load-balancing | |||
| of traffic flows to all of the PEs attached to that ES. In all cases | of traffic flows to all of the PEs attached to that ES. In all cases | |||
| traffic follows the transport paths, which may be asymmetric. | traffic follows the transport paths, which may be asymmetric. | |||
| The VPWS service instance identifier encoded in the Ethernet Tag ID | The VPWS service instance identifier encoded in the Ethernet Tag ID | |||
| in an advertised per EVI Ethernet A-D route MUST either be unique | in an advertised per-EVI Ethernet A-D route MUST either be unique | |||
| across all ASs, or an ASBR needs to perform a translation when the | across all ASs, or an ASBR needs to perform a translation when the | |||
| per EVI Ethernet A-D route is re-advertised by the ASBR from one AS | per-EVI Ethernet A-D route is re-advertised by the ASBR from one AS | |||
| to the other AS. | to the other AS. | |||
| Per ES Ethernet A-D route can be used for mass withdraw to withdraw | A per-ES Ethernet A-D route can be used for mass withdraw to withdraw | |||
| all per EVI Ethernet A-D routes associated with the multi-home site | all per-EVI Ethernet A-D routes associated with the multi-home site | |||
| on a given PE. | on a given PE. | |||
| 5 EVPN Comparison to PW Signaling | 5 EVPN Comparison to PW Signaling | |||
| In EVPN, service endpoint discovery and label signaling are done | In EVPN, service endpoint discovery and label signaling are done | |||
| concurrently using BGP. Whereas, with VPWS based on [RFC4448], label | concurrently using BGP. Whereas, with VPWS based on [RFC4448], label | |||
| signaling is done via LDP and service endpoint discovery is either | signaling is done via LDP and service endpoint discovery is either | |||
| through manual provisioning or through BGP. | through manual provisioning or through BGP. | |||
| In existing implementation of VPWS using pseudowires(PWs), redundancy | In existing implementations of VPWS using pseudowires(PWs), | |||
| is limited to single-active mode, while with EVPN implementation of | redundancy is limited to single-active mode, while with EVPN | |||
| VPWS both single-active and all-active redundancy modes can be | implementation of VPWS both single-active and all-active redundancy | |||
| supported. | modes can be supported. | |||
| In existing implementation with PWs, backup PWs are not used to carry | In existing implementations with PWs, backup PWs are not used to | |||
| traffic, while with EVPN, traffic can be load-balanced among | carry traffic, while with EVPN, traffic can be load-balanced among | |||
| different PEs multi-homed to a single CE. | different PEs multi-homed to a single CE. | |||
| Upon link or node failure, EVPN can trigger failover with the | Upon link or node failure, EVPN can trigger failover with the | |||
| withdrawal of a single BGP route per EVPL service or multiple EVPL | withdrawal of a single BGP route per EVPL service or multiple EVPL | |||
| services, whereas with VPWS PW redundancy, the failover sequence | services, whereas with VPWS PW redundancy, the failover sequence | |||
| requires exchange of two control plane messages: one message to | requires exchange of two control plane messages: one message to | |||
| deactivate the group of primary PWs and a second message to activate | deactivate the group of primary PWs and a second message to activate | |||
| the group of backup PWs associated with the access link. | the group of backup PWs associated with the access link. | |||
| Finally, EVPN may employ data plane egress link protection mechanisms | Finally, EVPN may employ data plane egress link protection mechanisms | |||
| not available in VPWS. This can be done by the primary PE (on local | not available in VPWS. This can be done by the primary PE (on local | |||
| AC down) using the label advertised in the per EVI Ethernet A-D route | AC down) using the label advertised in the per-EVI Ethernet A-D route | |||
| by the backup PE to encapsulate the traffic and direct it to backup | by the backup PE to encapsulate the traffic and direct it to the | |||
| PE. | backup PE. | |||
| 6 Failure Scenarios | 6 Failure Scenarios | |||
| On a link or port failure between the CE and the PE for both single | On a link or port failure between the CE and the PE for both single | |||
| and multi-homed CEs, unlike [RFC7432] the PE MUST withdraw all the | and multi-homed CEs, unlike [RFC7432] the PE MUST withdraw all the | |||
| associated Ethernet A-D routes for the VPWS service instances on the | associated Ethernet A-D routes for the VPWS service instances on the | |||
| failed port or link. | failed port or link. | |||
| 6.1 Single-Homed CEs | 6.1 Single-Homed CEs | |||
| Unlike [RFC7432], EVPN-VPWS uses Ethernet A-D route advertisements | Unlike [RFC7432], EVPN-VPWS uses Ethernet A-D route advertisements | |||
| for single-homed Ethernet Segments. Therefore, upon a link/port | for single-homed Ethernet Segments. Therefore, upon a link/port | |||
| failure of this single-homed Ethernet Segment, the PE MUST withdraw | failure of this single-homed Ethernet Segment, the PE MUST withdraw | |||
| the associated per EVI Ethernet A-D routes. | the associated per-EVI Ethernet A-D routes. | |||
| 6.2 Multi-Homed CEs | 6.2 Multi-Homed CEs | |||
| For a faster convergence in multi-homed scenarios with either Single- | For a faster convergence in multi-homed scenarios with either Single- | |||
| Active Redundancy or All-active redundancy, mass withdraw technique | Active Redundancy or All-active redundancy, a mass withdraw technique | |||
| is used. A PE previously advertising a per ES Ethernet A-D route, can | is used. A PE previously advertising a per-ES Ethernet A-D route, can | |||
| withdraw this route signaling to the remote PEs to switch all the | withdraw this route by signaling to the remote PEs to switch all the | |||
| VPWS service instances associated with this multi-homed ES to the | VPWS service instances associated with this multi-homed ES to the | |||
| backup PE | backup PE. | |||
| 7 Acknowledgements | 7 Acknowledgements | |||
| The authors would like to acknowledge Jeffrey Zhang, Wen Lin, Nitin | The authors would like to acknowledge Jeffrey Zhang, Wen Lin, Nitin | |||
| Singh, Senthil Sathappan and Vinod Prabhu for their feedback and | Singh, Senthil Sathappan, Vinod Prabhu, Himanshu Shah, Iftekhar | |||
| Hussain, Alvaro Retana and Acee Lindem for their feedback and | ||||
| contributions to this document. | contributions to this document. | |||
| 8 Security Considerations | 8 Security Considerations | |||
| The mechanisms in this document use EVPN control plane as defined in | The mechanisms in this document use EVPN control plane as defined in | |||
| [RFC7432]. Security considerations described in [RFC7432] are equally | [RFC7432]. Security considerations described in [RFC7432] are equally | |||
| applicable. | applicable. | |||
| This document uses MPLS and IP-based tunnel technologies to support | This document uses MPLS and IP-based tunnel technologies to support | |||
| data plane transport. Security considerations described in [RFC7432] | data plane transport. Security considerations described in [RFC7432] | |||
| skipping to change at page 12, line 4 ¶ | skipping to change at page 12, line 36 ¶ | |||
| The mechanisms in this document use EVPN control plane as defined in | The mechanisms in this document use EVPN control plane as defined in | |||
| [RFC7432]. Security considerations described in [RFC7432] are equally | [RFC7432]. Security considerations described in [RFC7432] are equally | |||
| applicable. | applicable. | |||
| This document uses MPLS and IP-based tunnel technologies to support | This document uses MPLS and IP-based tunnel technologies to support | |||
| data plane transport. Security considerations described in [RFC7432] | data plane transport. Security considerations described in [RFC7432] | |||
| and in [ietf-evpn-overlay] are equally applicable. | and in [ietf-evpn-overlay] are equally applicable. | |||
| 9 IANA Considerations | 9 IANA Considerations | |||
| IANA has allocated the following EVPN Extended Community sub-type: | IANA has allocated the following EVPN Extended Community sub-type: | |||
| SUB-TYPE VALUE NAME Reference | SUB-TYPE VALUE NAME Reference | |||
| 0x04 EVPN Layer 2 attributes [RFCXXXX] | 0x04 EVPN Layer 2 Attributes [RFCXXXX] | |||
| This document creates a registry called "EVPN Layer 2 attributes | This document creates a registry called "EVPN Layer 2 Attributes | |||
| Control Flags". New registrations will be made through the "RFC | Control Flags". New registrations will be made through the "RFC | |||
| Required" procedure defined in [RFC5226]. | Required" procedure defined in [RFC5226]. | |||
| Initial registrations are as follows: | Initial registrations are as follows: | |||
| P Advertising PE is the Primary PE. | P Advertising PE is the Primary PE. | |||
| B Advertising PE is the Backup PE. | B Advertising PE is the Backup PE. | |||
| C Control word [RFC4448] MUST be present | C Control word [RFC4448] MUST be present. | |||
| 10 References | 10 References | |||
| 10.1 Normative References | 10.1 Normative References | |||
| [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, DOI 10.17487/RFC2119, March | Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March | |||
| 1997, <http://www.rfc-editor.org/info/rfc2119>. | 1997, <http://www.rfc-editor.org/info/rfc2119>. | |||
| [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 Ethernet | Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet | |||
| VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc- | VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc- | |||
| editor.org/info/rfc7432>. | editor.org/info/rfc7432>. | |||
| skipping to change at page 12, line 50 ¶ | skipping to change at page 13, line 34 ¶ | |||
| editor.org/info/rfc4271>. | editor.org/info/rfc4271>. | |||
| [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended | [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended | |||
| Communities Attribute", RFC 4360, February 2006, <http://www.rfc- | Communities Attribute", RFC 4360, February 2006, <http://www.rfc- | |||
| editor.org/info/rfc4360>. | editor.org/info/rfc4360>. | |||
| [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
| IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, | IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, | |||
| <http://www.rfc-editor.org/info/rfc5226>. | <http://www.rfc-editor.org/info/rfc5226>. | |||
| [RFC7348] Mahalingam, M., et al, "VXLAN: A Framework for Overlaying | ||||
| Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, August | ||||
| 2014 | ||||
| 10.2 Informative References | 10.2 Informative References | |||
| [MEF] Metro Ethernet Forum, "Ethernet Services Definitions - Phase | [MEF] Metro Ethernet Forum, "Ethernet Services Definitions - Phase | |||
| 2", Technical Specification MEF 6.1, April 2008, | 2", Technical Specification MEF 6.1, April 2008, | |||
| https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_6.1.pdf | https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_6.1.pdf | |||
| [RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for | [RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for | |||
| Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006, | Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006, | |||
| <http://www.rfc-editor.org/info/rfc4664>. | <http://www.rfc-editor.org/info/rfc4664>. | |||
| End of changes. 62 change blocks. | ||||
| 156 lines changed or deleted | 191 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||