| < draft-ietf-bess-evpn-vpws-11.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 13, 2017 March 12, 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-11.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 Pseudowire (PW) signaling, and provides | the need for Pseudowire (PW) signaling, and provides fast protection | |||
| fast 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 . . . . . . . . . . . . . . . . . . . . . . 12 | 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 10.1 Normative References . . . . . . . . . . . . . . . . . . . 12 | 10.1 Normative References . . . . . . . . . . . . . . . . . . . 13 | |||
| 10.2 Informative References . . . . . . . . . . . . . . . . . . 13 | 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] provides the ability to forward customer traffic to/from a | [RFC7432] provides the ability to forward customer traffic to/from a | |||
| given 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 is 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; whereas, for more general VPWS | the exchange of a pair of Ethernet Auto-discovery (A-D) routes; | |||
| as per [RFC4664], traffic forwarding capability of EVPN is based on | whereas, for more general VPWS as per [RFC4664], traffic forwarding | |||
| the exchange of a group of Ethernet AD routes (one Ethernet AD route | capability of EVPN is based on the exchange of a group of Ethernet AD | |||
| per AC/ES). In a VPWS service, the traffic from an originating | routes (one Ethernet AD route per AC/ES). In a VPWS service, the | |||
| Ethernet Segment can be forwarded only to a single destination | traffic from an originating Ethernet Segment can be forwarded only to | |||
| Ethernet Segment; hence, no MAC lookup is needed and the MPLS label | a single destination Ethernet Segment; hence, no MAC lookup is needed | |||
| associated with the per EVPN instance (EVI) Ethernet A-D route can be | and the MPLS label associated with the per EVPN instance (EVI) | |||
| 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. In the data plane the value of the MPLS label advertised by | each Provider Edge node (PE). In the data plane the value of the MPLS | |||
| one PE is used by the other PE to send traffic for that VPWS service | label advertised by one PE is used by the other PE to send traffic | |||
| instance. As with the Ethernet Tag in standard EVPN, the VPWS service | for that VPWS service instance. As with the Ethernet Tag in standard | |||
| instance identifier has uniqueness within an EVPN instance. | EVPN, the VPWS service instance identifier has uniqueness within an | |||
| EVPN instance. | ||||
| For EVPN routes, the Ethernet Tag IDs are set to zero for Port-based, | For EVPN routes, the Ethernet Tag IDs are set to zero for Port-based, | |||
| VLAN-based, and VLAN-bundle interface mode and set to non-zero | VLAN-based, and VLAN-bundle interface mode and set to non-zero | |||
| Ethernet Tag IDs for VLAN-aware bundle mode. Conversely, for EVPN- | Ethernet Tag IDs for VLAN-aware bundle mode. Conversely, for EVPN- | |||
| VPWS, the Ethernet Tag ID in the Ethernet A-D route MUST be set to a | VPWS, the Ethernet Tag ID in the Ethernet A-D route MUST be set to a | |||
| non-zero value for all four service interface types. | non-zero value for all four service interface 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 | |||
| skipping to change at page 4, line 15 ¶ | skipping to change at page 4, line 17 ¶ | |||
| 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 MPLS label and | disposition PE can identify the egress AC from the MPLS label and | |||
| subsequently perform any required tag translation. For EVPL service, | subsequently perform any required tag translation. For EVPL service, | |||
| the Ethernet frames transported over an MPLS/IP network SHOULD remain | the Ethernet frames transported over an MPLS/IP network SHOULD remain | |||
| tagged with the originating VLAN-ID (VID) and any VID translation | tagged with the originating VLAN-ID (VID) and any VID translation | |||
| MUST be performed at the disposition PE. For EPL service, the | MUST be performed at the disposition PE. For EPL service, the | |||
| Ethernet frames are transported as is and the tags are not altered. | Ethernet frames are transported as is and the tags are not 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 equal to the | encapsulation as per [RFC7348], and this VNI will have a local scope | |||
| 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 the | 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. The Ethernet Segment route is | convergence upon link or node failure. The Ethernet Segment route is | |||
| used for auto-discovery of the PEs attached to a given multi-homed CE | used for auto-discovery of the PEs attached to a given multi-homed | |||
| 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 | ASBR: Autonomous System Border Router | |||
| skipping to change at page 5, line 19 ¶ | skipping to change at page 5, line 31 ¶ | |||
| S-VLAN: Service VLAN identifier. | S-VLAN: Service VLAN identifier. | |||
| C-VLAN: Customer VLAN identifier. | C-VLAN: Customer VLAN identifier. | |||
| VID: VLAN-ID. | 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 7, line 22 ¶ | skipping to change at page 7, line 47 ¶ | |||
| 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 defines a new extended community [RFC4360], to be included | This document defines a new extended community [RFC4360], to be | |||
| with per-EVI Ethernet A-D routes. This attribute is mandatory if | included with per-EVI Ethernet A-D routes. This attribute is | |||
| 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 12 ¶ | 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 of zero 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 | |||
| clear, it MUST treat the route as a withdrawal 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. 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 set the P Flag for the same Ethernet | remote PE will do per-flow load-balancing to the PEs that set the P | |||
| Tag and ESI. The B Flag in control flags SHOULD NOT be set in the | Flag for the same Ethernet Tag and ESI. The B Flag in control flags | |||
| multihoming all-active scenario and MUST be ignored by receiving | SHOULD NOT be set in the multihoming all-active scenario and MUST be | |||
| PE(s) if set. | 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, the DF election should result in the Primary-elected PE for | instance, the DF election should result in the Primary-elected PE for | |||
| the VPWS service instance advertising the P Flag set and the B Flag | the VPWS service instance advertising the P Flag set and the B Flag | |||
| clear, the Backup elected PE should advertise the P Flag clear and | clear, the Backup elected PE should advertise the P Flag clear and | |||
| the B Flag set, and the rest of the PEs in the same ES should signal | the B Flag set, and the rest of the PEs in the same ES should signal | |||
| both P and B Flags clear. When the primary PE/ES fails, the primary | both P and B Flags clear. When the primary PE/ES fails, the primary | |||
| PE will withdraw the associated Ethernet A-D routes for the VPWS | PE will withdraw the associated Ethernet A-D routes for the VPWS | |||
| service instance from the remote PE and the remote PEs should then | 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 | |||
| skipping to change at page 13, line 9 ¶ | 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. 21 change blocks. | ||||
| 67 lines changed or deleted | 97 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/ | ||||