idnits 2.17.1 draft-dong-pwe3-redundancy-spe-04.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-pwe3-redundancy-bit]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 22, 2012) is 4144 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) == Unused Reference: 'RFC3985' is defined on line 286, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-pwe3-redundancy-bit-08 ** Downref: Normative reference to an Informational RFC: RFC 3985 ** Downref: Normative reference to an Informational RFC: RFC 5659 ** Downref: Normative reference to an Informational RFC: RFC 6718 -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft H. Wang 4 Intended status: Standards Track Huawei Technologies 5 Expires: May 26, 2013 November 22, 2012 7 Pseudowire Redundancy on S-PE 8 draft-dong-pwe3-redundancy-spe-04 10 Abstract 12 This document describes Multi-Segment Pseudowire (MS-PW) protection 13 scenarios in which the pseudowire redundancy is provided on the 14 Switching-PE (S-PE). Operations of the S-PEs which provide PW 15 redundancy are specified. Signaling of the preferential forwarding 16 status as defined in [I-D.ietf-pwe3-redundancy-bit] is reused. This 17 document does not require any change to the T-PEs of MS-PW. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 26, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. PW Redundancy on S-PE . . . . . . . . . . . . . . . . . . . . . 3 61 3. S-PE Operations . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. VCCV Considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 [RFC6718] describes the framework and requirements for pseudowire 74 (PW) redundancy, and [I-D.ietf-pwe3-redundancy-bit] specifies 75 Pseudowire (PW) redundancy mechanism for scenarios where a set of 76 redundant PWs is configured between provider edge (PE) nodes in 77 single-segment pseudowire (SS-PW) [RFC3985]applications, or between 78 terminating provider edge (T-PE) nodes in multi-segment pseudowire 79 (MS-PW) [RFC5659] applications. 81 In some MS-PW scenarios, there are some benefits to provide PW 82 redundancy on S-PEs, such as reducing the burden on the access T-PE 83 nodes, and faster protection switching. This document describes some 84 scenarios in which PW redundancy is provided on S-PEs, and specifies 85 the operations of the S-PEs. Signaling of the preferential 86 forwarding status as defined in [I-D.ietf-pwe3-redundancy-bit] is 87 reused. This document does not require any change to the T-PEs of 88 MS-PW. 90 2. PW Redundancy on S-PE 92 In some MS-PW deployment scenarios, there are some benefits to 93 provide PW redundancy on S-PEs. This section gives some examples of 94 PW redundancy on S-PE. 96 +-----+ 97 +---+ +-----+ | | +---+ 98 | | | |------|T-PE2|----| | 99 | | +-----+ | ..PW-Seg2.......| | | 100 | | |....PW-Seg1..... | +-----+ | | 101 |CE1|----|T-PE1|------|S-PE1| |CE2| 102 | | | | | . | +-----+ | | 103 | | +-----+ | ..PW-Seg3.......| | | 104 | | | |------|T-PE3|----| | 105 +---+ +-----+ | | +---+ 106 +-----+ 107 Figure 1.MS-PW Redundancy on S-PE 109 As illustrated in Figure 1, CE1 is connected to T-PE1 while CE2 is 110 dual-homed to T-PE2 and T-PE3. T-PE1 is connected to S-PE1 only, and 111 S-PE1 is connected to T-PE2 and T-PE3. The MS-PW is switched on 112 S-PE1, and PW-Seg2 and PW-Seg3 provides resiliency on S-PE1 for 113 failure of T-PE2 or T-PE3 or the connected ACs. PW-Seg2 is selected 114 as primary PW segment, and PW-Seg3 is secondary PW segment. 116 MS-PW redundancy on S-PE is beneficial for the scenario in Figure 1 117 since T-PE1 as an access node may not be able to provide PW 118 redundancy, especially when the PW-Seg1 between T-PE1 and S-PE1 is 119 statically configured. And with PW redundancy on S-PE, the number of 120 PW segments needed between T-PE1 and S-PE1 is only half of the number 121 of PW segments needed for end-to-end MS-PW redundancy. In addition, 122 PW redundancy on S-PE could provide faster protection switching than 123 end-to-end protection switching of MS-PW. 125 +---+ +-----+ +-----+ +-----+ 126 | | | | | | | | 127 | | |......PW1-Seg1......PW1-Seg2........| 128 | | | . | | | 129 |CE1|----|T-PE1|------|S-PE1|-----------|T-PE2| 130 | | | . | | . | PW1-Seg3 | | +---+ 131 | | +---.-+ | ......... ......|----| | 132 | | |. | | . .| | | | 133 +---+ |. +-----+ . . +-----+ | | 134 |. . . |CE2| 135 |. .. | | 136 |. +-----+ . . +-----+ | | 137 |. | | . .| |----| | 138 |...PW2-Seg1.......... ......| +---+ 139 | | . | PW2-Seg2 | | 140 ----------|S-PE2|-----------|T-PE3| 141 | . | | | 142 | .....PW2-Seg3........| 143 | | | | 144 +-----+ +-----+ 145 Figure 2. MS-PW Redundancy on S-PE with S-PE protection 147 As illustrated in Figure 2, CE1 is connected to T-PE1 while CE2 is 148 dual-homed to T-PE2 and T-PE3. T-PE1 is connected to S-PE1 and 149 S-PE2, and both S-PE1 and S-PE2 are connected to T-PE2 and T-PE3. 150 There are two MS-PWs which are switched at S-PE1 and S-PE2 151 respectively to provide S-PE node protection. For MS-PW1, the S-PE1 152 provides resiliency using PW1-Seg2 and PW1-Seg3. For MS-PW2, the 153 S-PE2 provides resiliency using PW2-Seg2 and PW2-Seg3. MS-PW1 is the 154 primary PW and PW1-Seg2 is the primary PW segment. 156 MS-PW redundancy on S-PE is beneficial for the scenario in Figure 2 157 since it reduces the number of end-to-end MS-PWs required for both 158 T-PE and S-PE protection. In addition, PW redundancy on S-PE could 159 provide faster protection switching than end-to-end protection 160 switching of MS-PW. 162 3. S-PE Operations 164 For an S-PE which provides PW redundancy, it is important to 165 advertise proper preferential forwarding status to the PW segments on 166 both sides and perform protection switching according to the received 167 status. This section specifies the operations of S-PEs on which PW 168 redundancy is provisioned. This document does not make any change to 169 the T-PEs of MS-PW. 171 The S-PE SHOULD work as a Slave node for the single-connected side, 172 and SHOULD work in Independent mode for the multi-connected side. 173 The S-PE SHOULD pass the preferential forwarding status received from 174 the single-connected side unchanged to the PW segments on the multi- 175 connected side. The S-PE SHOULD advertise Standby status to the 176 single-connected side if it receives Standby status from all the PW 177 segments on the multi-connected side, and it SHOULD advertise Active 178 status to the single-connected side if it receives Active status from 179 any of the PW segments on the multi-connected side. For the single- 180 connected side, the active PW segment is determined by the T-PE on 181 this side, which works as the Master node. On the multi-connected 182 side, the PW segment which has both local and remote Preferential 183 Forwarding status as Active SHOULD be selected for traffic 184 forwarding. 186 The Signaling of Preferential Forwarding bit defined in 187 [I-D.ietf-pwe3-redundancy-bit] is reused in these scenarios. 189 For the scenario in Figure 1, assume the AC from CE2 to T-PE2 is 190 active. In normal operation, S-PE1 would receive Active Preferential 191 Forwarding status bit on the single-connected side from T-PE1, then 192 it would advertise Active Preferential Forwarding status bit on both 193 PW-Seg2 and PW-Seg3. T-PE2 and T-PE3 would advertise Active and 194 Standby preferential status bit respectively to S-PE1, reflecting the 195 forwarding state of the two ACs to CE2. By matching the local and 196 remote Up/Down status and Preferential Forwarding status, PW-Seg2 197 would be used for traffic forwarding. 199 On failure of the AC between CE2 and T-PE2, the forwarding state of 200 AC on T-PE3 is changed to Active. T-PE3 then advertises Active 201 Preferential Status to S-PE1, and T-PE2 would advertise the 202 Preferential Status bit of Standby to S-PE1. S-PE1 would perform the 203 switchover according to the updated local and remote Preferential 204 Forwarding status, and select PW-Seg3 for traffic forwarding. Since 205 S-PE1 still connects to an Active PW segment on the multi-connected 206 side, it will not advertise any change of the PW Preferential 207 Forwarding status to T-PE1. T-PE1 would not be aware of the 208 switchover on S-PE1. 210 For scenario of Figure 2, assume the AC from CE2 to T-PE2 is active. 211 T-PE1 works in Master mode and it would advertise Active and Standby 212 Preferential Forwarding status bit respectively to S-PE1 and S-PE2. 214 According to the received Preferential Forwarding status bit, S-PE1 215 would advertise Active Preferential Forwarding status bit to both 216 T-PE2 and T-PE3, and S-PE2 would advertise Standby Preferential 217 Forwarding status bit to both T-PE2 and T-PE3. T-PE2 would advertise 218 Active Preferential Forwarding status bit to both S-PE1 and S-PE2, 219 and T-PE3 would advertise Standby Preferential Forwarding status bit 220 to both S-PE1 and S-PE2, reflecting the forwarding state of the two 221 ACs to CE2. By matching the local and remote Up/Down Status and 222 Preferential Forwarding status, PW1-Seg2 from S-PE1 to T-PE2 would be 223 used for traffic forwarding. Since S-PE1 connects to the Active PW 224 segment on the multi-connected side, it would advertise Active 225 Preferential Forwarding status bit to T-PE1, and S-PE2 would 226 advertise Standby Preferential Forwarding status bit to T-PE1 since 227 it does not have any Active PW segment on the multi-connected side. 229 On failure of the AC between CE2 and T-PE2, the forwarding state of 230 AC on T-PE3 is changed to Active. T-PE3 would then advertise Active 231 Preferential Forwarding status bit to both S-PE1 and S-PE2, and T-PE2 232 would advertise Standby Preferential Forwarding status bit to both 233 S-PE1 and S-PE2. S-PE1 would perform the switchover according to the 234 updated local and remote Preferential Forwarding status, and select 235 PW1-Seg3 for traffic forwarding. Since S-PE1 still has an Active PW 236 segment on the multi-connected side, it would not advertise any 237 change of the PW status to T-PE1. Thus T-PE1 would not be aware of 238 the switchover on S-PE1. 240 If S-PE1 fails, T-PE1 would notice this through some detection 241 mechanism and then advertise the Active Preferential Forwarding 242 status bit to S-PE2, and PW2-Seg1 would be selected by T-PE1 for 243 traffic forwarding. On receipt of the newly changed Preferential 244 Forwarding status, S-PE2 would advertise the Active Preferential 245 Forwarding status to both T-PE2 and T-PE3. T-PE2 and T-PE3 would 246 also notice the failure of S-PE1 by some detection mechanism. Then 247 by matching the local and remote Up/Down and Preferential Forwarding 248 status, PW2-Seg2 would be selected for traffic forwarding. 250 4. VCCV Considerations 252 PW VCCV [RFC5085] CC type 1 "PW ACH" can be used with S-PE redundancy 253 mechanism. VCCV CC type 2 "Router Alert Label" is not supported for 254 MS-PW as specified in [RFC6073]. If VCCV CC type 3 "TTL Expiry" is 255 to be used, the hop count from one T-PE to the remote T-PE needs to 256 be obtained in advance. This can be achieved either by control plane 257 SP-PE TLVs or through data plane tracing of the MS-PW. 259 5. IANA Considerations 261 This document makes no request of IANA. 263 6. Security Considerations 265 This document has the same security properties as in the PWE3 control 266 protocol [RFC4447] and [I-D.ietf-pwe3-redundancy-bit]. 268 7. Acknowledgements 270 The authors would like to thank Mach Chen, Lizhong Jin, Mustapha 271 Aissaoui, Luca Martini, Matthew Bocci and Stewart Bryant for their 272 comments and discussions. 274 8. References 276 8.1. Normative References 278 [I-D.ietf-pwe3-redundancy-bit] 279 Muley, P. and M. Aissaoui, "Pseudowire Preferential 280 Forwarding Status Bit", draft-ietf-pwe3-redundancy-bit-08 281 (work in progress), September 2012. 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, March 1997. 286 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 287 Edge (PWE3) Architecture", RFC 3985, March 2005. 289 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 290 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 291 October 2009. 293 [RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire 294 Redundancy", RFC 6718, August 2012. 296 8.2. Informative References 298 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 299 Heron, "Pseudowire Setup and Maintenance Using the Label 300 Distribution Protocol (LDP)", RFC 4447, April 2006. 302 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 303 Connectivity Verification (VCCV): A Control Channel for 304 Pseudowires", RFC 5085, December 2007. 306 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 307 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 309 Authors' Addresses 311 Jie Dong 312 Huawei Technologies 313 Huawei Building, No.156 Beiqing Rd. 314 Beijing 100095 315 China 317 Email: jie.dong@huawei.com 319 Haibo Wang 320 Huawei Technologies 321 Huawei Building, No.156 Beiqing Rd. 322 Beijing 100095 323 China 325 Email: rainsword.wang@huawei.com