idnits 2.17.1 draft-sajassi-bess-evpn-vpws-fxc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 113 has weird spacing: '...cluding singl...' == Line 256 has weird spacing: '...ed, the lower...' -- The document date (November 1, 2016) is 2732 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'EVPN-VPWS' is mentioned on line 446, but not defined == Missing Reference: 'RFC2119' is mentioned on line 124, but not defined == Missing Reference: 'EVPN-Overlay' is mentioned on line 344, but not defined == Unused Reference: 'EVPN-IRB' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'EVPN-PREFIX' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'RFC6718' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'RFC6870' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'BGP-PIC' is defined on line 503, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-bess-evpn-inter-subnet-forwarding-00 == Outdated reference: A later version (-11) exists of draft-ietf-bess-evpn-prefix-advertisement-02 ** Downref: Normative reference to an Informational RFC: RFC 6718 Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup A. Sajassi 3 INTERNET-DRAFT P. Brissette 4 Intended Status: Standards Track Cisco 5 J. Uttaro 6 ATT 7 J. Drake 8 W. Lin 9 Juniper 10 S. Boutros 11 VMWare 12 J. Rabadan 13 Nokia 15 Expires: May 1, 2017 November 1, 2016 17 EVPN VPWS Flexible Cross-Connect Service 18 draft-sajassi-bess-evpn-vpws-fxc-01.txt 20 Abstract 22 This document describes a new EVPN VPWS VLAN-aware bundle service 23 type referred to as flexible cross-connect service. It also describes 24 the rational for this new service as well as a solution to deliver 25 such service. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2012 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1 VLAN-Unaware Flexible Xconnect - Single-Homing . . . . . . . 7 70 4.2 VLAN-Aware Flexible Xconnect . . . . . . . . . . . . . . . . 8 71 4.2.1 Local Switching . . . . . . . . . . . . . . . . . . . . 9 72 4.3 VLAN-Unaware Flexible Xconnect - Multi-Homing . . . . . . . 9 73 5. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 9 74 6 Failure Scenarios . . . . . . . . . . . . . . . . . . . . . . . 11 75 6.2 EVPN VPWS service Failure . . . . . . . . . . . . . . . . . 11 76 6.2 Attachment Circuit Failure . . . . . . . . . . . . . . . . . 11 77 6.3 PE Port Failure . . . . . . . . . . . . . . . . . . . . . . 11 78 6.4 PE Node Failure . . . . . . . . . . . . . . . . . . . . . . 11 79 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 11 80 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 81 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 9.1 Normative References . . . . . . . . . . . . . . . . . . . 11 83 9.2 Informative References . . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 86 1 Introduction 88 [EVPN-VPWS] describes a solution to deliver P2P services using BGP 89 constructs defined in [RFC7432]. It delivers this P2P service between 90 a pair of Attachment Circuits (ACs), where an AC can designate on a 91 PE, a port, a VLAN on a port, or a group of VLANs on a port. It also 92 leverages multi-homing and fast convergence capabilities of [RFC7432] 93 in delivering these VPWS services. Multi-homing capabilities include 94 the support of single-active and all-active redundancy mode and fast 95 convergence is provided using "mass withdraw" message in control- 96 plane and fast protection switching using prefix independent 97 convergence in data-plane upon node or link failure. Furthermore, the 98 use of EVPN BGP constructs eliminates the need for multi-segment PW 99 auto-discovery and signaling if the VPWS service need to span across 100 multiple ASes. 102 Some service providers have very large number of ACs (in millions) 103 that require tag manipulation (e.g., VLAN translation) to be back 104 hauled across their MPLS/IP network. These service providers want to 105 multiplex a large number of ACs across several physical interfaces 106 (e.g., several Ethernet Segments) onto a single VPWS service tunnel 107 in order to a) reduce number of EVPN service labels associated with 108 VPWS service tunnels and thus the associated OAM monitoring, and b) 109 reduce EVPN BGP signaling (e.g., not to signal each AC as it is the 110 case in [EVPN-VPWS]). 112 These service provider want the above functionality without 113 scarifying any of the capabilities of [EVPN-VPWS] including single- 114 active and all-active multi-homing, and fast convergence. 116 This document presents a solution based on extensions to [EVPN-VPWS] 117 to meet the above requirements. 119 1.1 Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 MAC: Media Access Control 127 MPLS: Multi Protocol Label Switching 129 OAM: Operations, Administration and Maintenance 131 PE: Provide Edge Node 132 CE: Customer Edge device e.g., host or router or switch 134 EVPL: Ethernet Virtual Private Line 136 EPL: Ethernet Private Line 138 ES: Ethernet Segment 140 VPWS: Virtual private wire service 142 EVI: EVPN Instance 144 VPWS Service Tunnel: It is represented by a pair of EVPN service 145 labels associated with a pair of endpoints. Each label is downstream 146 assigned and advertised by the disposition PE through an Ethernet A-D 147 per-EVI route. The downstream label identifies the endpoint on the 148 disposition PE. A VPWS service tunnel can be associated with many 149 VPWS service identifiers for VLAN-aware VPWS service where each 150 identifier is a normalized VID. 152 Single-Active Mode: When a device or a network is multi-homed to two 153 or more PEs and when only a single PE in such redundancy group can 154 forward traffic to/from the multi-homed device or network for a given 155 VLAN, then such multi-homing or redundancy is referred to as "Single- 156 Active". 158 All-Active: When a device is multi-homed to two or more PEs and when 159 all PEs in such redundancy group can forward traffic to/from the 160 multi-homed device for a given VLAN, then such multi-homing or 161 redundancy is referred to as "All-Active". 163 2 Requirements 165 Two of the main motivations for service providers seeking a new 166 solution are: 1) to reduce number of VPWS service tunnels by 167 multiplexing large number of ACs across different physical interfaces 168 instead of having one VPWS service tunnel per AC, and 2) to reduce 169 the signaling of ACs as much as possible. Besides these two 170 requirements, they also want multi-homing and fast convergence 171 capabilities of [EVPN-VPWS]. 173 In [EVPN-VPWS], a PE signals an AC indirectly by first associating 174 that AC to a VPWS service tunnel (e.g., a VPWS service instance) and 175 then signaling the VPWS service tunnel via a per-EVI Ethernet AD 176 route with Ethernet Tag field set to a 24-bit VPWS service instance 177 identifier (which is unique within the EVI) and ESI field set to a 178 10-octet identifier of the Ethernet Segment corresponding to that AC. 180 Therefore, a PE device that receives such EVPN routes, can associate 181 the VPWS service tunnel to the remote Ethernet Segment, and when the 182 remote ES fails and the PE receives the "mass withdraw" message 183 associated with the failed ES per [RFC7432], it can update its BGP 184 path list for that VPWS service tunnel quickly and achieve fast 185 convergence for multi-homing scenarios. Even if fast convergence were 186 not needed, there would still be a need for signaling each AC failure 187 (via its corresponding VPWS service tunnel) associated with the 188 failed ES, so that the BGP path list for each of them gets updated 189 accordingly and the packets are sent to backup PE (in case of single- 190 active multi-homing) or to other PEs in the redundancy group (in case 191 of all-active multi-homing). In absence of updating the BGP path 192 list, the traffic for that VPWS service tunnel will be black-holed. 194 When a single VPWS service tunnel multiplexes many ACs across number 195 of Ethernet Segments (number of physical interfaces) and the ACs are 196 not signaled via EVPN BGP to remote PE devices, then the remote PE 197 devices neither know the association of the received Ethernet Segment 198 to these ACs (and in turn to their local ACs) nor they know the 199 association of the VPWS service tunnel (e.g., EVPN service label) to 200 the far-end ACs - i.e, the remote PEs only know the association of 201 their local ACs to the VPWS service tunnel but not the far-end ACs. 202 Thus upon a connectivity failure to the ES, they don't know how to 203 redirect traffic via another multi-homing PE to that ES. In other 204 words, even if an ES failure is signaled via EVPN to the remote PE 205 devices, they don't know what to do with such message because they 206 don't know the association among the ES, their ACs, and the VPWS 207 service tunnel. 209 In order to address this issue when multiplexing large number of ACs 210 onto a single VPWS service tunnel, two mechanisms are devised: one to 211 support VPWS services between two single-homed endpoints and another 212 one to support VPWS services where one of the endpoints is multi- 213 homed. An endpoint can be an AC, MAC-VRF, IP-VRF, global table, or 214 etc. 216 For single-homed endpoints, it is OK not to signal each AC in BGP 217 because upon connection failure to the ES, there is no alternative 218 path to that endpoint. However, the ramification for not signaling an 219 AC failure is that the traffic destined to the failed AC, is sent 220 over MPLS/IP core and then gets discarded at the destination PE - 221 i.e., it can waste network resources. However, when there is a 222 connection failure, the application layer will eventually stop 223 sending traffic and thus this wastage of network resources should be 224 transient. Section 4.1 describes a solution for such single-homing 225 VPWS service which is called VLAN-Unaware flexible cross-connect 226 service. 228 For VPWS services where one of the endpoints is multi-homed, there 229 are two options: 231 1) to signal each AC via BGP so that the path list can be updated 232 upon a failure that impacts those ACs. This solution is described in 233 section 4.2 and it is called VLAN-Aware flexible cross-connect 234 service. 236 2) to bundle several ACs on an ES together per destination end-point 237 (e.g., ES, MAC-VRF, etc.) and associated such bundle to a single VPWS 238 service tunnel. This is similar to VLAN-bundle service interface 239 described in [EVPN-VPWS]. This solution is described in section 4.3. 241 4 Solution 243 This section describes a solution for providing a new VPWS service 244 between two PE devices where a large number of ACs (e.g., VLANs) that 245 span across many Ethernet Segments (i.e., physical interfaces) on 246 each PE are multiplex onto a single P2P EVPN LSP tunnel. Since 247 multiplexing is done across several physical interfaces, there can be 248 overlapping VLAN IDs across these interfaces; therefore, in such 249 scenarios, the VLAN IDs (VIDs) MUST be translated into unique VIDs to 250 avoid collision. Furthermore, if the number of VLANs that are getting 251 multiplex onto a single VPWS service tunnel, exceed 4K, then a single 252 tag to double tag translation MUST be performed. This translation of 253 VIDs into unique VIDs (either single or double) is referred to as 254 "VID normalization". When single normalized VID is used, the lower 255 12-bit of Ethernet tag field in EVPN routes is set to that VID and 256 when double normalized VID is used, the lower 12-bit of Ethernet tag 257 field is set to inner VID and the higher 12-bit is set to the outer 258 VID. 260 Since there is only a single EVPN VPWS service tunnel associated with 261 many normalized VIDs (either single or double), MPLS lookup at the 262 disposition PE is no longer sufficient to forward the packet to the 263 right egress endpoint/interface. Therefore, in addition to an EVPN 264 label lookup corresponding to the VPWS service tunnel, a VID lookup 265 (either single or double) is also required. On the disposition PE, 266 one can think of the lookup of EVPN label results in identification 267 of a VID-VRF, and the lookup of normalized VID(s) in that table, 268 results in identification of egress endpoint/interface. The tag 269 manipulation (translation from normalized VID(s) to local VID) can be 270 performed either as part of the VID table lookup or at the egress 271 interface itself. 273 Since VID lookup (single or double) needs to be performed at the 274 disposition PE, then VID normalization MUST be performed prior to the 275 MPLS encapsulation on the ingress PE. This requires that both 276 imposition and disposition PE devices be capable of VLAN tag 277 manipulation, such as re-write (single or double), addition, deletion 278 (single or double) at their endpoints (e.g., their ES's, MAC-VRFs, 279 etc.). 281 4.1 VLAN-Unaware Flexible Xconnect - Single-Homing 283 In this mode of operation, many ACs across several Ethernet Segments 284 are multiplex into a single EVPN VPWS service tunnel represented by a 285 single VPWS service ID. VLAN-Unaware mode for this solution means 286 that VLANs (normalized VIDs) are not signaled via EVPN BGP among the 287 PEs. In this solution, there is only a single P2P EVPN LSP tunnel 288 between a pair of PEs for all their ACs that are single-homed. 290 As discussed previously, since the VPWS service tunnel is used to 291 multiplex ACs across different ES's (e.g., physical interfaces), the 292 EVPN label alone is not sufficient for proper forwarding of the 293 received packets (over MPLS/IP network) to egress interfaces. 294 Therefore, normalized VID lookup is required in the disposition 295 direction to forward packets to their proper egress end-points - 296 i.e., the EVPN label lookup identifies a VID-VRF and subsequently, 297 the normalized VID lookup in that table, identifies the egress 298 interface. 300 In this solution, on each PE, the single-homing ACs represented by 301 their normalized VIDs are associated with a single VPWS service 302 tunnel (in a given EVI). The EVPN route that gets generated is an 303 EVPN Ethernet AD per EVI route with ESI=0, Ethernet Tag field set to 304 VPWS service instance ID, MPLS label field set to dynamically 305 generated EVPN service label representing the EVPN VPWS service 306 tunnel. This route is sent with an RT representing the EVI. This RT 307 can be auto-generated from the EVI per section 5.1.2.1 of [EVPN- 308 Overlay]. Furthermore, this route is sent with the EVPN Layer-2 309 Extended Community defined in section 3.1 of [EVPN-VPWS] with two new 310 flags (defined in section 5) that indicate: 1) this VPWS service 311 tunnel is for VLAN-unaware Flexible Cross-Connect, and 2) normalized 312 VID type (single versus double). The receiving PE uses these new 313 flags for consistency check and MAY generate an alarm if it detects 314 inconsistency but doesn't bring down the VPWS service because such 315 inconsistency may be intentional - i.e., one side is configured for 316 VLAN-aware VPWS service and another side is configured for VLAN- 317 unaware VPWS service. 319 It should be noted that in this mode of operation, a single Ethernet 320 AD per EVI route is sent upon configuration of the first AC (ie, 321 normalized VID). Later, when additional ACs are configured and 322 associated with this EVPN VPWS service tunnel, the PE does not 323 advertise any additional EVPN BGP routes. The PE only associates 324 locally these ACs with the already created VPWS service tunnel. 326 4.2 VLAN-Aware Flexible Xconnect 328 In this mode of operation, just as the VLAN-unaware mode, many 329 normalized VIDs (ACs) across several different ES's/interfaces are 330 multiplexed into a single EVPN VPWS service tunnel; however, this 331 single tunnel is represented by many VPWS service IDs (one per 332 normalized VID) and these normalized VIDs are signaled using EVPN 333 BGP. 335 In this solution, on each PE, the multi-homing ACs represented by 336 their normalized VIDs are configured with a single EVI. There is no 337 need to configure VPWS service instance ID in here as it is the same 338 as the normalized VID. For each normalized VID on each ES, the PE 339 generates an EVPN Ethernet AD per EVI route where ESI field 340 represents the ES ID, the Ethernet Tag field is set to the normalized 341 VID, MPLS label field is set to dynamically generated EVPN label 342 representing the P2P EVPN LSP tunnel. This route is sent with an RT 343 representing the EVI. As before, this RT can be auto-generated from 344 the EVI per section 5.1.2.1 of [EVPN-Overlay]. Furthermore, this 345 route is sent with the EVPN Layer-2 Extended Community defined in 346 section 3.1 of [EVPN-VPWS] with two new flags (defined in section 5) 347 that indicate: 1) this VPWS service tunnel is for VLAN-aware Flexible 348 Cross-Connect, and 2) normalized VID type (single versus double). The 349 receiving PE uses these new flags for consistency check and MAY 350 generate an alarm if it detects inconsistency but doesn't bring down 351 the VPWS service because such inconsistency may be intentional - 352 i.e., one side is configured for VLAN-aware VPWS service and another 353 side is configured for VLAN-unaware VPWS service. 355 It should be noted that in this mode of operation, the PE sends a 356 single Ethernet AD route for each AC that is configured - i.e., each 357 normalized VID that is configured per ES results in generation of an 358 EVPN Ethernet AD per EVI. 360 This mode of operation provides automatic cross checking of 361 normalized VIDs used for EVPL services because these VIDs are 362 signaled in EVPN BGP. For example, if the same normalized VID is 363 configured on three PE devices (instead of two) for the same EVI, 364 then when a PE receives the second EVPN EAD per-EVI route, it 365 generates an error message unless the two EVPN EAD per-EVI routes 366 include the same ESI. Such cross-checking is not feasible in VLAN- 367 unaware FXC because the normalized VIDs are not signaled. 369 4.2.1 Local Switching 371 When cross-connection is between two ACs belonging to two multi-homed 372 Ethernet Segments on the same set of multi-homing PEs, then 373 forwarding between the two ACs MUST be performed locally during 374 normal operation (e.g., in absence of a local link failure) - i.e., 375 the traffic between the two ACs MUST be locally switched within the 376 PE. 378 In terms of control plane processing, this means that when the 379 receiving PE receives an Ethernet A-D per-EVI route whose ESI is a 380 local ESI, the PE does not alter its forwarding state based on the 381 received route. This ensures that the local switching takes 382 precedence over forwarding via MPLS/IP network. This scheme of 383 locally switched preference is consistent with baseline EVPN [RFC 384 7432] where it describes the locally switched preference for MAC/IP 385 routes. 387 In such scenarios, the Ethernet A-D per EVI route should be 388 advertised with the MPLS label either associated with the destination 389 Attachment Circuit or with the destination Ethernet Segment in order 390 to avoid any ambiguity in forwarding. In other words, the MPLS label 391 cannot represent the same VID-VRF used in section 4.2 because the 392 same normalized VID can be reachable via two Ethernet Segments. In 393 case of using MPLS label per destination AC, then this same solution 394 can be used for VLAN-based VPWS or VLAN-bundle VPWS services per 395 [EVPN-VPWS]. 397 4.3 VLAN-Unaware Flexible Xconnect - Multi-Homing 399 In this mode of operation, a group of normalized VIDs (ACs) on a 400 single ES that are destined to a single endpoint are multiplexed into 401 a single EVPN VPWS service tunnel represented by a single VPWS 402 service ID. This mode of operation is the same as VLAN-bundle service 403 interface of [EVPN-VPWS] except for the fact that VIDs on Ethernet 404 frames are normalized before getting sent over the LSP tunnel. 406 In the previous two modes of operation, only a single EVPN VPWS 407 service tunnel is needed per pair of PEs. However, in this mode of 408 operation, there can be lot more service tunnels per pair of PEs - 409 i.e, there is one tunnel per group of VIDs per pair of PEs and there 410 can be many groups between a pair of PEs, thus resulting in many EVPN 411 service tunnels. 413 5. BGP Extensions 414 This draft uses the EVPN Layer-2 attribute extended community defined 415 in [EVPN-VPWS] with two additional flags added to this EC as 416 described below. This EC is to be advertised with Ethernet A-D per 417 EVI route per section 4. 419 +------------------------------------+ 420 | Type(0x06)/Sub-type(TBD)(2 octet) | 421 +------------------------------------+ 422 | Control Flags (2 octets) | 423 +------------------------------------+ 424 | L2 MTU (2 octets) | 425 +------------------------------------+ 426 | Reserved (2 octets) | 427 +------------------------------------+ 429 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | MBZ | V | M |C|P|B| (MBZ = MUST Be Zero) 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 The following bits in the Control Flags are defined; the remaining 435 bits MUST be set to zero when sending and MUST be ignored when 436 receiving this community. 438 Name Meaning 440 B,P,C per definition in [EVPN-VPWS] 442 M 00 mode of operation as defined in [EVPN-VPWS] 443 01 VLAN-aware FXC 444 10 VLAN-unaware FXC 446 V 00 operating per [EVPN-VPWS] 447 01 single-VID normalization 448 10 double-VID normalization 450 The M and V fields are OPTIONAL on transmission and ignored at 451 reception for forwarding purposes. They are used for error 452 notifications. 454 6 Failure Scenarios 456 6.2 EVPN VPWS service Failure 458 The failure detection of an EVPN VPWS service can be performed via 459 OAM mechanisms such as VCCV-BFD and upon such failure detection, the 460 switch over procedure to the backup S-PE is the same as the one 461 described above. 463 6.2 Attachment Circuit Failure 465 6.3 PE Port Failure 467 6.4 PE Node Failure 469 In the case of PE node failure, the operation is similar to the steps 470 described above, albeit that EVPN route withdrawals are performed by 471 the Route Reflector instead of the PE. 473 7 Security Considerations 475 TBD. 477 8 IANA Considerations 479 TBD 481 9 References 483 9.1 Normative References 485 [RFC7432] Sajassi et al., "Ethernet VPN", RFC 7432, February 2015. 487 [EVPN-IRB] Sajassi et al., "Integrated Routing and Bridging in EVPN", 488 draft-ietf-bess-evpn-inter-subnet-forwarding-00, work in 489 progress, November 2014. 491 [EVPN-PREFIX] Rabadan et al., "IP Prefix Advertisement in EVPN", 492 draft-ietf-bess-evpn-prefix-advertisement-02, work in 493 progress, September 2015. 495 [RFC6718] Muley P., et al., "Pseudowire Redundancy", RFC 6718, August 496 2012. 498 [RFC6870] Muley P., et al., "Pseudowire Preferential Forwarding 499 Status Bit", RFC 6870, February 2013. 501 9.2 Informative References 503 [BGP-PIC] Bashandy A. et al., "BGP Prefix Independent Convergence", 504 draft-rtgwg-bgp-pic-02.txt, work in progress, October 505 2013. 507 Authors' Addresses 509 A. Sajassi 510 Cisco 511 EMail: sajassi@cisco.com 513 P. Brissette 514 Cisco 515 EMail: pbrisset@cisco.com 517 J. Uttaro 518 ATT 519 EMail: ju1738@att.com 521 J. Drake 522 Juniper 523 EMail: jdrake@juniper.net 525 S. Boutros 526 ATT 527 EMail: boutros.sami@gmail.com 529 W. Lin 530 Juniper 531 EMail: wlin@juniper.net 532 J. Rabadan 533 jorge.rabadan@nokia.com