< draft-ietf-pals-redundancy-spe-01.txt   draft-ietf-pals-redundancy-spe-02.txt >
Network Working Group J. Dong Network Working Group J. Dong
Internet-Draft H. Wang Internet-Draft H. Wang
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: November 5, 2015 May 4, 2015 Expires: February 5, 2016 August 4, 2015
Pseudowire Redundancy on S-PE Pseudowire Redundancy on S-PE
draft-ietf-pals-redundancy-spe-01 draft-ietf-pals-redundancy-spe-02
Abstract Abstract
This document describes Multi-Segment Pseudowire (MS-PW) protection This document describes Multi-Segment Pseudowire (MS-PW) protection
scenarios in which the pseudowire redundancy is provided on the scenarios in which the pseudowire redundancy is provided on the
Switching-PE (S-PE). Operations of the S-PEs which provide PW Switching-PE (S-PE). Operations of the S-PEs which provide PW
redundancy are specified in this document. Signaling of the redundancy are specified in this document. Signaling of the
preferential forwarding status as defined in [RFC 6870] is reused. preferential forwarding status as defined in RFC 6870 is reused.
This document does not require any change to the T-PEs of MS-PW. This document does not require any change to the T-PEs of MS-PW.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "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].
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 5, 2015. This Internet-Draft will expire on February 5, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Typical Scenarios of PW Redundancy on S-PE . . . . . . . . . 2 2. Typical Scenarios of PW Redundancy on S-PE . . . . . . . . . 3
2.1. MS-PW Redundancy on S-PE . . . . . . . . . . . . . . . . 3 2.1. MS-PW Redundancy on S-PE . . . . . . . . . . . . . . . . 3
2.2. MS-PW Redundancy on S-PE with S-PE Protection . . . . . . 3 2.2. MS-PW Redundancy on S-PE with S-PE Protection . . . . . . 3
3. S-PE Operations . . . . . . . . . . . . . . . . . . . . . . . 4 3. S-PE Operations . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Operations of Scenario 1 . . . . . . . . . . . . . . . . 5 3.1. Operations of Scenario 1 . . . . . . . . . . . . . . . . 5
3.2. Operations of Scenario 2 . . . . . . . . . . . . . . . . 6 3.2. Operations of Scenario 2 . . . . . . . . . . . . . . . . 6
4. VCCV Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. VCCV Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
skipping to change at page 2, line 41 skipping to change at page 2, line 41
[RFC6718] describes the framework and requirements for pseudowire [RFC6718] describes the framework and requirements for pseudowire
(PW) redundancy, and [RFC6870] specifies Pseudowire (PW) redundancy (PW) redundancy, and [RFC6870] specifies Pseudowire (PW) redundancy
mechanism for scenarios where a set of redundant PWs is configured mechanism for scenarios where a set of redundant PWs is configured
between provider edge (PE) nodes in single-segment pseudowire (SS-PW) between provider edge (PE) nodes in single-segment pseudowire (SS-PW)
[RFC3985] applications, or between terminating provider edge (T-PE) [RFC3985] applications, or between terminating provider edge (T-PE)
nodes in multi-segment pseudowire (MS-PW) [RFC5659] applications. nodes in multi-segment pseudowire (MS-PW) [RFC5659] applications.
In some MS-PW scenarios, there are benefits to provide PW redundancy In some MS-PW scenarios, there are benefits to provide PW redundancy
on S-PEs, such as reducing the burden on the access T-PE nodes, and on S-PEs, such as reducing the burden on the access T-PE nodes, and
faster protection switching. This document describes some scenarios enabling faster protection switching compared to the end-to-end MS-PW
in which PW redundancy is provided on S-PEs, and specifies the protection mechanisms. This document describes some scenarios in
which PW redundancy is provided on S-PEs, and specifies the
operations of the S-PEs. Signaling of the preferential forwarding operations of the S-PEs. Signaling of the preferential forwarding
status as defined in [RFC6870] is reused. This document does not status as defined in [RFC6870] is reused. This document does not
require any change to the T-PEs of MS-PW. require any change to the T-PEs of MS-PW.
2. Typical Scenarios of PW Redundancy on S-PE 2. Typical Scenarios of PW Redundancy on S-PE
In some MS-PW deployment scenarios, there are benefits to provide PW In some MS-PW deployment scenarios, there are benefits to provide PW
redundancy on S-PEs. This section describes typical scenarios of PW redundancy on S-PEs. This section describes typical scenarios of PW
redundancy on S-PE. redundancy on S-PE.
skipping to change at page 5, line 14 skipping to change at page 5, line 14
The S-PEs connect to the neighboring T-PEs or other S-PEs on two The S-PEs connect to the neighboring T-PEs or other S-PEs on two
sides with PW segments. For the S-PE which provides PW redundancy sides with PW segments. For the S-PE which provides PW redundancy
for an MS-PW, on one side there is a single PW segment, which is for an MS-PW, on one side there is a single PW segment, which is
called the single-homed side, and on the other side there are called the single-homed side, and on the other side there are
multiple PW segments, which is called the multi-homed side. The multiple PW segments, which is called the multi-homed side. The
scenario in which the S-PE has two multi-homed sides is out of scope. scenario in which the S-PE has two multi-homed sides is out of scope.
In general, the S-PE MUST work as a Slave node for the single-homed In general, the S-PE MUST work as a Slave node for the single-homed
side, and MUST work in Independent mode for the multi-homed side. side, and MUST work in Independent mode for the multi-homed side.
The S-PE MUST pass the preferential forwarding status received from Consequently, The T-PE on the single-homed side MUST work in the
the single-homed side unchanged to the PW segments on the multi-homed Master mode, and the T-PEs on the multi-homed side MUST work in the
side. The S-PE MUST advertise Standby status to the single-homed Independent mode. The S-PE MUST pass the preferential forwarding
side if it receives Standby status from all the PW segments on the status received from the single-homed side unchanged to the PW
multi-homed side, and it MUST advertise Active status to the single- segments on the multi-homed side. The S-PE MUST advertise Standby
homed side if it receives Active status from any of the PW segments status to the single-homed side if it receives Standby status from
on the multi-homed side. For the single-homed side, the active PW all the PW segments on the multi-homed side, and it MUST advertise
segment is determined by the T-PE on this side, which works as the Active status to the single-homed side if it receives Active status
Master node. On the multi-homed side, the PW segment which has both from any of the PW segments on the multi-homed side. For the single-
local and remote Up/Down status and Preferential Forwarding status as homed side, the active PW segment is determined by the T-PE on this
Up and Active MUST be selected for traffic forwarding. side, which works as the Master node. On the multi-homed side, since
both the S-PE and T-PEs work in the Independent mode, the PW segment
which has both local and remote Up/Down status and Preferential
Forwarding status as Up and Active MUST be selected for traffic
forwarding.
The Signaling of Preferential Forwarding bit as defined in [RFC6870] The Signaling of Preferential Forwarding bit as defined in [RFC6870]
and [RFC6478] is reused in these scenarios. and [RFC6478] is reused in these scenarios.
3.1. Operations of Scenario 1 3.1. Operations of Scenario 1
For the scenario in Figure 1, assume the AC from CE2 to T-PE2 is For the scenario in Figure 1, assume the AC from CE2 to T-PE2 is
active. In normal operation, S-PE1 would receive Active Preferential active. In normal operation, S-PE1 would receive Active Preferential
Forwarding status bit on the single-homed side from T-PE1, then it Forwarding status bit on the single-homed side from T-PE1, then it
would advertise Active Preferential Forwarding status bit on both PW- would advertise Active Preferential Forwarding status bit on both PW-
skipping to change at page 7, line 21 skipping to change at page 7, line 21
reach the target PE. The hop count from one T-PE to the target PE reach the target PE. The hop count from one T-PE to the target PE
can be obtained either via SP-PE TLVs, through MS-PW path trace or can be obtained either via SP-PE TLVs, through MS-PW path trace or
based on management plane information. based on management plane information.
5. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
6. Security Considerations 6. Security Considerations
This document has the same security properties as in the PWE3 control This document specifies the mechanisms of providing PW redundancy on
protocol [RFC4447], [RFC6870] and [RFC6478]. the S-PEs of MS-PWs. The security considerations specified in
[RFC4447], [RFC6073], [RFC6870] and [RFC6478] apply to this document.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Mach Chen, Lizhong Jin, Mustapha The authors would like to thank Mach Chen, Lizhong Jin, Mustapha
Aissaoui, Luca Martini, Matthew Bocci and Stewart Bryant for their Aissaoui, Luca Martini, Matthew Bocci and Stewart Bryant for their
valuable comments and discussions. valuable comments and discussions.
8. References 8. References
8.1. Normative References 8.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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
Heron, "Pseudowire Setup and Maintenance Using the Label G. Heron, "Pseudowire Setup and Maintenance Using the
Distribution Protocol (LDP)", RFC 4447, April 2006. Label Distribution Protocol (LDP)", RFC 4447,
DOI 10.17487/RFC4447, April 2006,
<http://www.rfc-editor.org/info/rfc4447>.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. Aissaoui, "Segmented Pseudowire", RFC 6073,
DOI 10.17487/RFC6073, January 2011,
<http://www.rfc-editor.org/info/rfc6073>.
[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci,
"Pseudowire Status for Static Pseudowires", RFC 6478, May "Pseudowire Status for Static Pseudowires", RFC 6478,
2012. DOI 10.17487/RFC6478, May 2012,
<http://www.rfc-editor.org/info/rfc6478>.
[RFC6870] Muley, P. and M. Aissaoui, "Pseudowire Preferential [RFC6870] Muley, P., Ed. and M. Aissaoui, Ed., "Pseudowire
Forwarding Status Bit", RFC 6870, February 2013. Preferential Forwarding Status Bit", RFC 6870,
DOI 10.17487/RFC6870, February 2013,
<http://www.rfc-editor.org/info/rfc6870>.
8.2. Informative References 8.2. Informative References
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge (PWE3) Architecture", RFC 3985, March 2005. Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005,
<http://www.rfc-editor.org/info/rfc3985>.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
Connectivity Verification (VCCV): A Control Channel for Circuit Connectivity Verification (VCCV): A Control
Pseudowires", RFC 5085, December 2007. Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
December 2007, <http://www.rfc-editor.org/info/rfc5085>.
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
October 2009. DOI 10.17487/RFC5659, October 2009,
<http://www.rfc-editor.org/info/rfc5659>.
[RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire [RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire
Redundancy", RFC 6718, August 2012. Redundancy", RFC 6718, DOI 10.17487/RFC6718, August 2012,
<http://www.rfc-editor.org/info/rfc6718>.
Authors' Addresses Authors' Addresses
Jie Dong Jie Dong
Huawei Technologies Huawei Technologies
Huawei Building, No.156 Beiqing Rd. Huawei Building, No.156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: jie.dong@huawei.com Email: jie.dong@huawei.com
 End of changes. 17 change blocks. 
36 lines changed or deleted 56 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/