< draft-ietf-pwe3-iccp-08.txt   draft-ietf-pwe3-iccp-09.txt >
Internet Engineering Task Force Luca Martini Internet Engineering Task Force Luca Martini
Internet Draft Samer Salam Internet Draft Samer Salam
Intended status: Standards Track Ali Sajassi Intended status: Standards Track Ali Sajassi
Expires: December 20, 2012 Cisco Expires: January 30, 2013 Cisco
Matthew Bocci Satoru Matsushima Matthew Bocci Satoru Matsushima
Alcatel-Lucent Softbank Alcatel-Lucent Softbank
Thomas Nadeau Thomas Nadeau
CA Technologies Juniper Networks
June 20, 2012 July 30, 2012
Inter-Chassis Communication Protocol for L2VPN PE Redundancy Inter-Chassis Communication Protocol for L2VPN PE Redundancy
draft-ietf-pwe3-iccp-08.txt draft-ietf-pwe3-iccp-09.txt
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 Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 20, 2012 This Internet-Draft will expire on January 30, 2012
Abstract Abstract
This document specifies an inter-chassis communication protocol This document specifies an inter-chassis communication protocol
(ICCP) that enables Provider Edge (PE) device redundancy for Virtual (ICCP) that enables Provider Edge (PE) device redundancy for Virtual
Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS)
applications. The protocol runs within a set of two or more PEs, applications. The protocol runs within a set of two or more PEs,
forming a redundancy group, for the purpose of synchronizing data forming a redundancy group, for the purpose of synchronizing data
amongst the systems. It accommodates multi-chassis attachment circuit amongst the systems. It accommodates multi-chassis attachment circuit
as well as pseudowire redundancy mechanisms. as well as pseudowire redundancy mechanisms.
skipping to change at page 3, line 46 skipping to change at page 3, line 46
6.4 RG Notification Message .............................. 30 6.4 RG Notification Message .............................. 30
6.4.1 Notification Message TLVs ............................ 31 6.4.1 Notification Message TLVs ............................ 31
6.5 RG Application Data Message .......................... 34 6.5 RG Application Data Message .......................... 34
7 Application TLVs ..................................... 34 7 Application TLVs ..................................... 34
7.1 Pseudowire Redundancy (PW-RED) Application TLVs ...... 34 7.1 Pseudowire Redundancy (PW-RED) Application TLVs ...... 34
7.1.1 PW-RED Connect TLV ................................... 34 7.1.1 PW-RED Connect TLV ................................... 34
7.1.2 PW-RED Disconnect TLV ................................ 36 7.1.2 PW-RED Disconnect TLV ................................ 36
7.1.2.1 PW-RED Disconnect Cause TLV .......................... 36 7.1.2.1 PW-RED Disconnect Cause TLV .......................... 36
7.1.3 PW-RED Config TLV .................................... 37 7.1.3 PW-RED Config TLV .................................... 37
7.1.3.1 Service Name TLV ..................................... 39 7.1.3.1 Service Name TLV ..................................... 39
7.1.3.2 PW ID TLV ............................................ 39 7.1.3.2 PW ID TLV ............................................ 40
7.1.3.3 Generalized PW ID TLV ................................ 40 7.1.3.3 Generalized PW ID TLV ................................ 41
7.1.4 PW-RED State TLV ..................................... 41 7.1.4 PW-RED State TLV ..................................... 42
7.1.5 PW-RED Synchronization Request TLV ................... 43 7.1.5 PW-RED Synchronization Request TLV ................... 43
7.1.6 PW-RED Synchronization Data TLV ...................... 44 7.1.6 PW-RED Synchronization Data TLV ...................... 45
7.2 Multi-chassis LACP (mLACP) Application TLVs .......... 45 7.2 Multi-chassis LACP (mLACP) Application TLVs .......... 46
7.2.1 mLACP Connect TLV .................................... 46 7.2.1 mLACP Connect TLV .................................... 46
7.2.2 mLACP Disconnect TLV ................................. 47 7.2.2 mLACP Disconnect TLV ................................. 47
7.2.2.1 mLACP Disconnect Cause TLV ........................... 47 7.2.2.1 mLACP Disconnect Cause TLV ........................... 48
7.2.3 mLACP System Config TLV .............................. 48 7.2.3 mLACP System Config TLV .............................. 48
7.2.4 mLACP Aggregator Config TLV .......................... 49 7.2.4 mLACP Aggregator Config TLV .......................... 49
7.2.5 mLACP Port Config TLV ................................ 51 7.2.5 mLACP Port Config TLV ................................ 51
7.2.6 mLACP Port Priority TLV .............................. 53 7.2.6 mLACP Port Priority TLV .............................. 53
7.2.7 mLACP Port State TLV ................................. 55 7.2.7 mLACP Port State TLV ................................. 55
7.2.8 mLACP Aggregator State TLV ........................... 57 7.2.8 mLACP Aggregator State TLV ........................... 57
7.2.9 mLACP Synchronization Request TLV .................... 59 7.2.9 mLACP Synchronization Request TLV .................... 59
7.2.10 mLACP Synchronization Data TLV ....................... 61 7.2.10 mLACP Synchronization Data TLV ....................... 61
8 LDP Capability Negotiation ........................... 62 8 LDP Capability Negotiation ........................... 62
9 Client Applications .................................. 63 9 Client Applications .................................. 63
9.1 Pseudowire Redundancy Application Procedures ......... 63 9.1 Pseudowire Redundancy Application Procedures ......... 63
9.1.1 Initial Setup ........................................ 64 9.1.1 Initial Setup ........................................ 64
9.1.2 Pseudowire Configuration Synchronization ............. 64 9.1.2 Pseudowire Configuration Synchronization ............. 64
9.1.3 Pseudowire Status Synchronization .................... 65 9.1.3 Pseudowire Status Synchronization .................... 65
9.1.4 PE Node Failure ...................................... 66 9.1.3.1 Independent Mode ..................................... 66
9.2 Attachment Circuit Redundancy Application Procedures . 66 9.1.3.2 Master/Slave Mode .................................... 67
9.2.1 Common AC Procedures ................................. 66 9.1.4 PE Node Failure ...................................... 67
9.2.2 AC Failure ........................................... 67 9.2 Attachment Circuit Redundancy Application Procedures . 68
9.2.3 PE Node Failure ...................................... 67 9.2.1 Common AC Procedures ................................. 68
9.2.4 PE Isolation ......................................... 67 9.2.1.1 AC Failure ........................................... 68
9.2.5 Ethernet AC Procedures ............................... 67 9.2.1.2 PE Node Failure ...................................... 68
9.2.6 Multi-chassis LACP (mLACP) Application Procedures .... 67 9.2.1.3 PE Isolation ......................................... 68
9.2.6.1 Initial Setup ........................................ 67 9.2.1.4 Determining Pseudowire State ......................... 68
9.2.6.2 mLACP Aggregator and Port Configuration .............. 69 9.2.2 Multi-chassis LACP (mLACP) Application Procedures .... 69
9.2.6.3 mLACP Aggregator and Port Status Synchronization ..... 70 9.2.2.1 Initial Setup ........................................ 69
9.2.6.4 Failure and Recovery ................................. 72 9.2.2.2 mLACP Aggregator and Port Configuration .............. 71
10 Security Considerations .............................. 73 9.2.2.3 mLACP Aggregator and Port Status Synchronization ..... 72
11 IANA Considerations .................................. 73 9.2.2.4 Failure and Recovery ................................. 74
11.1 MESSAGE TYPE NAME SPACE .............................. 73 10 Security Considerations .............................. 75
11.2 TLV TYPE NAME SPACE .................................. 74 11 IANA Considerations .................................. 75
11.3 ICC RG Parameter Type Space .......................... 74 11.1 MESSAGE TYPE NAME SPACE .............................. 75
11.4 STATUS CODE NAME SPACE ............................... 75 11.2 TLV TYPE NAME SPACE .................................. 76
12 Acknowledgments ...................................... 75 11.3 ICC RG Parameter Type Space .......................... 76
13 Normative References ................................. 76 11.4 STATUS CODE NAME SPACE ............................... 77
14 Informative References ............................... 76 12 Acknowledgments ...................................... 77
15 Author's Addresses ................................... 76 13 Normative References ................................. 78
14 Informative References ............................... 78
15 Author's Addresses ................................... 78
1. Specification of Requirements 1. Specification of Requirements
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. document are to be interpreted as described in RFC 2119.
2. Introduction 2. Introduction
Network availability is a critical metric for service providers as it Network availability is a critical metric for service providers as it
skipping to change at page 38, line 43 skipping to change at page 38, line 43
-i. Synchronized (0x01) -i. Synchronized (0x01)
Indicates that the sender has concluded transmitting all Indicates that the sender has concluded transmitting all
pseudowire configuration for a given service. pseudowire configuration for a given service.
-ii. Purge Configuration (0x02) -ii. Purge Configuration (0x02)
Indicates that the pseudowire is no longer configured Indicates that the pseudowire is no longer configured
for PW-RED operation. for PW-RED operation.
-iii. Independent Mode (0x04)
Indicates that the pseudowire is configured for
redundancy using the Independent Mode of operation, per
section 5.1 of [RED-BIT].
-iv. Independent Mode with Request Switchover (0x08)
Indicates that the pseudowire is configured for
redundancy using the Independent Mode of operation with
the use of the "Request Switchover" bit, per section 6.3
of [RED-BIT].
-v. Master Mode (0x10)
Indicates that the pseudowire is configured for
redundancy using the Master/Slave Mode of operation,
with the advertising PE acting as Master, per section
5.2 of [RED-BIT].
-vi. Slave Mode (0x20)
Indicates that the pseudowire is configured for
redundancy using the Master/Slave Mode of operation,
with the advertising PE acting as Slave, per section 5.2
of [RED-BIT].
- Sub-TLVs - Sub-TLVs
The "PW-RED Config TLV" includes the following two sub-TLVs: The "PW-RED Config TLV" includes the following two sub-TLVs:
-i. Service Name TLV -i. Service Name TLV
-ii. PW ID TLV or Generalized PW ID TLV -ii. PW ID TLV or Generalized PW ID TLV
The format of the sub-TLVs is as follows: The format of the sub-TLVs is as follows:
skipping to change at page 42, line 40 skipping to change at page 43, line 13
Length fields. Length fields.
- ROID - ROID
As defined in the ROID section above. As defined in the ROID section above.
- Local PW State - Local PW State
The status of the PW as determined by the sending PE, encoded in The status of the PW as determined by the sending PE, encoded in
the same format as the "Status Code" field of the "PW Status TLV" the same format as the "Status Code" field of the "PW Status TLV"
defined in [RFC4447]. defined in [RFC4447] and extended in [RED-BIT].
- Remote PW State - Remote PW State
The status of the PW as determined by the remote peer of the The status of the PW as determined by the remote peer of the
sending PE. Encoded in the same format as the "Status Code" field sending PE. Encoded in the same format as the "Status Code" field
of the "PW Status TLV" defined in [RFC4447]. The same code points of the "PW Status TLV" defined in [RFC4447] and extended in
listed above are used here as well. [RED-BIT].
7.1.5. PW-RED Synchronization Request TLV 7.1.5. PW-RED Synchronization Request TLV
The PW-RED Synchronization Request TLV is used in the RG Application The PW-RED Synchronization Request TLV is used in the RG Application
Data message. This TLV is used by a device to request from its peer Data message. This TLV is used by a device to request from its peer
to retransmit configuration or operational state. The following to retransmit configuration or operational state. The following
information can be requested: information can be requested:
- configuration and/or state for one or more pseudowires - configuration and/or state for one or more pseudowires
skipping to change at page 64, line 5 skipping to change at page 63, line 48
ICCP capability is advertised to a LDP peer if there is at least one ICCP capability is advertised to a LDP peer if there is at least one
RG enabled on the local PE. RG enabled on the local PE.
9. Client Applications 9. Client Applications
9.1. Pseudowire Redundancy Application Procedures 9.1. Pseudowire Redundancy Application Procedures
This section defines the procedures for the Pseudowire Redundancy This section defines the procedures for the Pseudowire Redundancy
(PW-RED) Application. (PW-RED) Application.
It should be noted that the PW-RED application SHOULD NOT be enabled
together with an AC Redundancy application for the same service
instance. This simplifies the operation of the multi-chassis
redundancy solution (Figure 1) and eliminates the possibility of
deadlock conditions between the AC and PW redundancy mechanisms.
9.1.1. Initial Setup 9.1.1. Initial Setup
When an RG is configured on a system and multi-chassis pseudowire When an RG is configured on a system and multi-chassis pseudowire
redundancy is enabled in that RG, the PW-RED application MUST send an redundancy is enabled in that RG, the PW-RED application MUST send an
"RG Connect" message with "PW-RED Connect TLV" to each PE that is a "RG Connect" message with "PW-RED Connect TLV" to each PE that is a
member of the same RG. The sending PE MUST set the A bit to 1 if it member of the same RG. The sending PE MUST set the A bit to 1 if it
has already received a "PW-RED Connect TLV" from its peer; otherwise, has already received a "PW-RED Connect TLV" from its peer; otherwise,
the PE MUST set the A bit to 0. If a PE, that has sent the TLV with the PE MUST set the A bit to 0. If a PE, that has sent the TLV with
the A bit set to 0, receives a "PW-RED Connect TLV" from a peer, it the A bit set to 0, receives a "PW-RED Connect TLV" from a peer, it
MUST repeat its advertisement with the A bit set to 1. The PW-RED MUST repeat its advertisement with the A bit set to 1. The PW-RED
skipping to change at page 64, line 44 skipping to change at page 64, line 46
service instances. The advertisement MUST be initiated when the PW- service instances. The advertisement MUST be initiated when the PW-
RED application connection first comes up. To that end, the system RED application connection first comes up. To that end, the system
sends "RG Application Data" messages with "PW-RED Config TLVs" as sends "RG Application Data" messages with "PW-RED Config TLVs" as
part of an unsolicited synchronization. A PE MUST use a pair of "PW- part of an unsolicited synchronization. A PE MUST use a pair of "PW-
RED Synchronization Data TLVs" to delimit the set of TLVs that are RED Synchronization Data TLVs" to delimit the set of TLVs that are
being sent as part of this unsolicited advertisement. being sent as part of this unsolicited advertisement.
In the case of a configuration change, a PE MUST re-advertise the In the case of a configuration change, a PE MUST re-advertise the
most up to date information for the affected pseudowires. most up to date information for the affected pseudowires.
As part of the configuration synchronization, a PE advertizes the As part of the configuration synchronization, a PE advertises the
ROID associated with the pseudowire. This is used to correlate the ROID associated with the pseudowire. This is used to correlate the
pseudowires that are protecting each other on different PEs. A PE pseudowires that are protecting each other on different PEs. As well,
also advertizes a priority value that is used to determine the a PE advertises the configured PW redundancy mode. This can be one of
precedence of a given pseudowire to assume the Active role in a the following four options: Master Mode, Slave Mode, Independent Mode
redundant setup. Furthermore, a PE advertizes a Service Name that is or Independent Mode with Request Switchover. If the received
global in the context of an RG and is used to identify which redundancy mode does not match the locally configured mode for the
pseudowires belong to the same service. Finally, a PE also advertizes same ROID, then the PE MUST respond with an "RG Notification Message"
the pseudowire identifier as part of this synchronization. to NAK the "PW-RED Config TLV". The PE MUST disable the associated
local pseudowire until a satisfactory "PW-RED Config TLV" is received
9.1.3. Pseudowire Status Synchronization from the peer. This guarantees that device mis-configuration does not
lead to network wide problems (e.g. by creating forwarding loops).
The mechanism for synchronizing pseudowire state depends on whether The PE SHOULD also raise an alarm to alert the operator. If a PE
or not an AC redundancy mechanism is in use. If an AC mechanism is in receives a NAK for an advertised "PW-RED Config TLV", it MUST disable
use, then on a given PE, the forwarding status of the PW (Active or the associated pseudowire and SHOULD raise an alarm to alert the
Standby) is derived from the state of the associated AC(s). This operator.
simplifies the operation of the multi-chassis redundancy solution
(Figure 1) and eliminates the possibility of deadlock conditions
between the AC and PW redundancy mechanisms. The rules by which the
PW state is derived from the AC state are as follows:
- VPWS
For VPWS, there's a single AC per service instance. If the AC is
Active, then the PW status should be Active. If the AC is
Standby, then the PW status should be Standby.
- VPLS Furthermore, a PE advertises in its "PW-RED Config TLVs" a priority
value that is used to determine the precedence of a given pseudowire
to assume the Active role in a redundant setup. A PE also adverties a
Service Name that is global in the context of an RG and is used to
identify which pseudowires belong to the same service. Finally, a PE
also advertises the pseudowire identifier as part of this
synchronization.
For VPLS, there could be multiple ACs per service instance (i.e. 9.1.3. Pseudowire Status Synchronization
VFI). If AT LEAST ONE AC is Active, then the PW status should be
Active. If ALL ACs are Standby, then the PW status should be
Standby.
In this case, the PW-RED application does not synchronize PW status PEs, that are member of an RG, synchronize pseudowire status for the
across chassis, per se. Rather, the AC Redundancy application should purpose of identifying, on a per ROID basis, which pseudowire will be
synchronize AC status between chassis, in order to determine which AC actively used for forwarding and which pseudowire(s) will be placed
(and subsequently which PE) is Active or Standby for a given service. in standby state.
When that is determined, each PE will then adjust its local PWs state
according to the rules described above. The reduncancy bit described
in [RED-BIT] is used for this purpose.
On the other hand, if an AC redundancy mechanism is not in use, then Synchronization of pseudowire status is done by sending the "PW-RED
the PW-RED application is used to synchronize pseudowire state. This State TLV" whenever the pseudowire state changes on a PE. This
is done by sending the "PW-RED State TLV" whenever the pseudowire includes changes to the local end as well as the remote end of the
state changes on a PE. This includes changes to the local end as pseudowire.
well as the remote end of the pseudowire.
A PE may request that its peer retransmit previously advertised PW- A PE may request that its peer retransmit previously advertised PW-
RED state. This is useful for instance when the PE is recovering from RED state. This is useful for instance when the PE is recovering from
a soft failure. To request such retransmission, a PE MUST send a set a soft failure. To request such retransmission, a PE MUST send a set
of one or more "PW-RED Synchronization Request TLVs". of one or more "PW-RED Synchronization Request TLVs".
A PE MUST respond to a "PW-RED Synchronization Request TLV" by A PE MUST respond to a "PW-RED Synchronization Request TLV" by
sending the requested data in a set of one or more PW-RED TLVs sending the requested data in a set of one or more PW-RED TLVs
delimited by a pair of "PW-RED Synchronization Data TLVs". The TLVs delimited by a pair of "PW-RED Synchronization Data TLVs". The TLVs
comprising the response MUST be ordered such that the Synchronization comprising the response MUST be ordered such that the Synchronization
skipping to change at page 66, line 34 skipping to change at page 66, line 28
the system from the burden of updating state that will ultimately be the system from the burden of updating state that will ultimately be
overwritten by the synchronization response. Note that TLVs overwritten by the synchronization response. Note that TLVs
pertaining to other pseudowires or services are to continue to be pertaining to other pseudowires or services are to continue to be
processed per normal in the interim. processed per normal in the interim.
If a PE receives a synchronization request for a pseudowire or If a PE receives a synchronization request for a pseudowire or
service that doesn't exist or is not known to the PE, then it MUST service that doesn't exist or is not known to the PE, then it MUST
trigger an unsolicited synchronization of all pseudowire information trigger an unsolicited synchronization of all pseudowire information
(i.e. replay the initialization sequence). (i.e. replay the initialization sequence).
In the subsections that follow, we describe the details of pseudowire
status synchronization for each of the PW redundancy modes defined in
[RED-BIT].
9.1.3.1. Independent Mode
This section covers the operation in Independent Mode with or without
Request Switchover capability.
In this mode, the operator must ensure that for a given RO, the PW
Priority values configured for all associated pseudowires on a given
PE are collectively higher (or lower) than those configured on other
PEs in the same RG. If this condition is not satisfied after the PEs
have exchanged "PW-RED State TLVs", a PE MUST disable the associated
pseudowire(s) and SHOULD raise an alarm to alert the operator. Note
that the PW Priority MAY be the same as the PW Precedence defined in
[RED-BIT].
For a given RO, after the all the PEs in an RG have exchanged their
"PW-RED State TLVs", the PE with the best PW Priority (i.e. least
numeric value) advertises Active preferential forwarding status in
LDP on all its associated pseudowires. Whereas, all other PEs in the
RG advertise Standby preferential forwarding status in LDP on their
associated pseudowires.
If the service is VPWS, then only a single pseudowire per service
will be selected for forwarding. This is the pseudowire that is
independently advertised with Active preferential forwarding status
on both endpoints, as described in [RED-BIT].
If the service is VPLS, then one or multiple pseudowires per service
will be selected for forwarding. These are the pseudowires that are
independently advertised with Active preferential forwarding status
on both PW endpoints, as described in [RED-BIT].
9.1.3.2. Master/Slave Mode
In this mode, the operator must ensure that for a given RO, the PW
Priority values configured for all associated pseudowires on a given
PE are collectively higher (or lower) than those configured on other
PEs in the same RG. If this condition is not satisfied after the PEs
have exchanged "PW-RED State TLVs", a PE MUST disable the associated
pseudowire(s) and SHOULD raise an alarm to alert the operator. Note
that the PW Priority MAY be the same as the PW Precedence defined in
[RED-BIT]. In addition, the operator must ensure that, for a given
RO, all the PEs in the RG are consistently configured as Master or
Slave.
In the context of a given RO, if the PEs in the RG are acting as
Master, then the PE with the best PW Priority (i.e. least numeric
value) advertises Active preferential forwarding status in LDP on
only a single pseudowire, following the procedures in sections 5.2
and 6.2 of [RED-BIT]. Whereas, all the other pseudowires on other PEs
in the RG are advertised with Standby preferential forwarding status
in LDP.
9.1.4. PE Node Failure 9.1.4. PE Node Failure
When a PE node detects that a remote PE, that is member of the same When a PE node detects that a remote PE, that is member of the same
RG, has gone down, the local PE examines if it has redundant PWs for RG, has gone down, the local PE examines if it has redundant PWs for
the affected services. If the local PE has the highest priority the affected services. If the local PE has the highest priority
(after the failed PE) then it becomes the active node for the (after the failed PE) then it becomes the active node for the
services in question, and subsequently activates its associated PWs. services in question, and subsequently activates its associated
PW(s).
9.2. Attachment Circuit Redundancy Application Procedures 9.2. Attachment Circuit Redundancy Application Procedures
9.2.1. Common AC Procedures 9.2.1. Common AC Procedures
This section describes generic procedures for AC Redundancy This section describes generic procedures for AC Redundancy
applications, independent of the type of the AC (ATM, FR or applications, independent of the type of the AC (ATM, FR or
Ethernet). Ethernet).
9.2.2. AC Failure 9.2.1.1. AC Failure
When the AC Redundancy mechanism on the Active PE detects a failure When the AC Redundancy mechanism on the Active PE detects a failure
of the AC, it should send an ICCP Application Data message to inform of the AC, it should send an ICCP Application Data message to inform
the redundant PEs of the need to take over. The AC failures can be the redundant PEs of the need to take over. The AC failures can be
categorized into the following scenarios: categorized into the following scenarios:
- Failure of CE interface connecting to PE - Failure of CE interface connecting to PE
- Failure of CE uplink to PE - Failure of CE uplink to PE
- Failure of PE interface connecting to CE - Failure of PE interface connecting to CE
9.2.3. PE Node Failure 9.2.1.2. PE Node Failure
When a PE node detects that a remote PE, that is member of the same When a PE node detects that a remote PE, that is member of the same
RG, has gone down, the local PE examines if it has redundant ACs for RG, has gone down, the local PE examines if it has redundant ACs for
the affected services. If the local PE has the highest priority the affected services. If the local PE has the highest priority
(after the failed PE) then it becomes the active node for the (after the failed PE) then it becomes the active node for the
services in question, and subsequently activates its associated ACs. services in question, and subsequently activates its associated ACs.
9.2.4. PE Isolation 9.2.1.3. PE Isolation
When a PE node detects that is has been isolated from the core When a PE node detects that is has been isolated from the core
network (i.e. all core facing interfaces/links are not operational), network (i.e. all core facing interfaces/links are not operational),
then it should instruct its AC Redundancy mechanism to change the then it should ensure that its AC Redundancy mechanism will change
status of any active ACs to Standby. The AC Redundancy application the status of any active ACs to Standby. The AC Redundancy
should then send ICCP Application Data messages in order to trigger application should then send ICCP Application Data messages in order
failover to a standby PE. to trigger failover to a standby PE.
9.2.5. Ethernet AC Procedures 9.2.1.4. Determining Pseudowire State
9.2.6. Multi-chassis LACP (mLACP) Application Procedures If the PEs in an RG are running an AC Redundancy application over
ICCP, then the Independent Mode of PW Redundancy, as defined in
[RED-BIT], MUST be used. On a given PE, the Preferential Forwarding
status of the PW (Active or Standby) is derived from the state of the
associated AC(s). This simplifies the operation of the multi-chassis
redundancy solution (Figure 1) and eliminates the possibility of
deadlock conditions between the AC and PW redundancy mechanisms. The
rules by which the PW status is derived from the AC status are as
follows:
- VPWS
For VPWS, there's a single AC per service instance. If the AC is
Active, then the PW status should be Active. If the AC is
Standby, then the PW status should be Standby.
- VPLS
For VPLS, there could be multiple ACs per service instance (i.e.
VFI). If AT LEAST ONE AC is Active, then the PW status should be
Active. If ALL ACs are Standby, then the PW status should be
Standby.
In this case, the PW-RED application is not used to synchronize PW
status between PEs. Rather, the AC Redundancy application should
synchronize AC status between PE, in order to establish which AC (and
subsequently which PE) is Active or Standby for a given service. When
that is determined, each PE will then derive its local PWs state
according to the rules described above. The Preferential Forwarding
status bit, described in [RED-BIT], is used to advertise PW status to
the remote peers.
9.2.2. Multi-chassis LACP (mLACP) Application Procedures
This section defines the procedures that are specific to the multi- This section defines the procedures that are specific to the multi-
chassis LACP (mLACP) application. chassis LACP (mLACP) application, which is applicable for Ethernet
ACs.
9.2.6.1. Initial Setup 9.2.2.1. Initial Setup
When an RG is configured on a system and mLACP is enabled in that RG, When an RG is configured on a system and mLACP is enabled in that RG,
the mLACP application MUST send an "RG Connect" message with "mLACP the mLACP application MUST send an "RG Connect" message with "mLACP
Connect TLV" to each PE that is member of the same RG. The sending PE Connect TLV" to each PE that is member of the same RG. The sending PE
MUST set the A bit to 1 in the said TLV if it has received a MUST set the A bit to 1 in the said TLV if it has received a
corresponding "mLACP Connect TLV" from its peer PE; otherwise, the corresponding "mLACP Connect TLV" from its peer PE; otherwise, the
sending PE MUST set the A bit to 0. If a PE receives an "mLACP sending PE MUST set the A bit to 0. If a PE receives an "mLACP
Connect TLV" from its peer after sending the said TLV with the A bit Connect TLV" from its peer after sending the said TLV with the A bit
set to 0, it MUST resend the TLV with the A bit set to 1. A system set to 0, it MUST resend the TLV with the A bit set to 1. A system
considers the mLACP application connection to be operational when it considers the mLACP application connection to be operational when it
skipping to change at page 69, line 25 skipping to change at page 71, line 21
System Priority values to be used ubiquitously. To achieve this, System Priority values to be used ubiquitously. To achieve this,
every PE MUST use the values for the two parameters that are supplied every PE MUST use the values for the two parameters that are supplied
by the PE with the numerically lowest value (among RG members) of by the PE with the numerically lowest value (among RG members) of
System Aggregation Priority. This guarantees that the PEs always System Aggregation Priority. This guarantees that the PEs always
agree on uniform values, which yield the highest System Priority. agree on uniform values, which yield the highest System Priority.
When the mLACP application is disabled on the device, or is When the mLACP application is disabled on the device, or is
unconfigured for the RG in question, the system MUST send an "RG unconfigured for the RG in question, the system MUST send an "RG
Disconnect" message with "mLACP Disconnect TLV". Disconnect" message with "mLACP Disconnect TLV".
9.2.6.2. mLACP Aggregator and Port Configuration 9.2.2.2. mLACP Aggregator and Port Configuration
A system MUST synchronize the configuration of its mLACP enabled A system MUST synchronize the configuration of its mLACP enabled
Aggregators and ports with other RG members. This is achieved via the Aggregators and ports with other RG members. This is achieved via the
use of "mLACP Aggregator Config TLVs" and "mLACP Port Config TLVs", use of "mLACP Aggregator Config TLVs" and "mLACP Port Config TLVs",
respectively. An implementation MUST advertise the configuration of respectively. An implementation MUST advertise the configuration of
Aggregators prior to advertising the configuration of any of their Aggregators prior to advertising the configuration of any of their
associated member ports. associated member ports.
The PEs in an RG MUST all agree on the MAC address to be associated The PEs in an RG MUST all agree on the MAC address to be associated
with a given Aggregator. It is possible to achieve this via with a given Aggregator. It is possible to achieve this via
skipping to change at page 70, line 45 skipping to change at page 72, line 41
case. case.
When mLACP is unconfigured on a port/Aggregator, a PE MUST send a When mLACP is unconfigured on a port/Aggregator, a PE MUST send a
"Port/Aggregator Config TLV" with the "Purge Configuration" flag "Port/Aggregator Config TLV" with the "Purge Configuration" flag
asserted. This allows receiving PEs to purge any state maintained for asserted. This allows receiving PEs to purge any state maintained for
the decommissioned port/Aggregator. If a PE receives a the decommissioned port/Aggregator. If a PE receives a
"Port/Aggregator Config TLV" with the "Purge Configuration" flag "Port/Aggregator Config TLV" with the "Purge Configuration" flag
asserted, and the PE is not maintaining any state for that asserted, and the PE is not maintaining any state for that
port/Aggregator, then it MUST silently discard the TLV. port/Aggregator, then it MUST silently discard the TLV.
9.2.6.3. mLACP Aggregator and Port Status Synchronization 9.2.2.3. mLACP Aggregator and Port Status Synchronization
PEs within an RG need to synchronize their state-machines for proper PEs within an RG need to synchronize their state-machines for proper
mLACP operation with a multi-homed device. This is achieved by having mLACP operation with a multi-homed device. This is achieved by having
each system advertise its Aggregators and ports running state in each system advertise its Aggregators and ports running state in
"mLACP Aggregator State TLVs" and "mLACP Port State TLVs", "mLACP Aggregator State TLVs" and "mLACP Port State TLVs",
respectively. Whenever any LACP parameter for an Aggregator or a respectively. Whenever any LACP parameter for an Aggregator or a
port, whether on the Partner (i.e. multi-homed device) or the Actor port, whether on the Partner (i.e. multi-homed device) or the Actor
(i.e. PE) side, is changed a system MUST transmit an updated TLV for (i.e. PE) side, is changed a system MUST transmit an updated TLV for
the affected Aggregator and/or port. Moreover, when the the affected Aggregator and/or port. Moreover, when the
administrative or operational state of an Aggregator or port changes, administrative or operational state of an Aggregator or port changes,
skipping to change at page 72, line 23 skipping to change at page 74, line 19
Key that doesn't exist or is not known to the PE, then it MUST Key that doesn't exist or is not known to the PE, then it MUST
trigger an unsolicited synchronization of all system, Aggregator and trigger an unsolicited synchronization of all system, Aggregator and
port information (i.e. replay the initialization sequence). port information (i.e. replay the initialization sequence).
If a PE learns, as part of a synchronization operation from its peer, If a PE learns, as part of a synchronization operation from its peer,
that the latter is advertising a Node ID value which is different that the latter is advertising a Node ID value which is different
from the value previously advertised, then the PE MUST purge all from the value previously advertised, then the PE MUST purge all
port/aggregator data previously learnt from that peer prior to the port/aggregator data previously learnt from that peer prior to the
last synchronization. last synchronization.
9.2.6.4. Failure and Recovery 9.2.2.4. Failure and Recovery
When a PE that is active for a multi-chassis link aggregation group When a PE that is active for a multi-chassis link aggregation group
encounters a fault, it SHOULD attempt to fail-over to a peer PE which encounters a fault, it SHOULD attempt to fail-over to a peer PE which
hosts the same RO. To that effect, the faulty PE SHOULD lower its hosts the same RO. To that effect, the faulty PE SHOULD lower its
port priority (by using a larger numeric value) and advertise this port priority (by using a larger numeric value) and advertise this
change in the "mLACP Port Priority TLV". If the PE is not capable of change in the "mLACP Port Priority TLV". If the PE is not capable of
lowering its own port priority any further, it SHOULD trigger a lowering its own port priority any further, it SHOULD trigger a
failover to the redundant PE by sending an "mLACP Port Priority TLV" failover to the redundant PE by sending an "mLACP Port Priority TLV"
in which it requests the redundant PE to raise the latter's port in which it requests the redundant PE to raise the latter's port
priority to the maximum permitted in [IEEE-802.1AX] (i.e. the priority to the maximum permitted in [IEEE-802.1AX] (i.e. the
skipping to change at page 74, line 12 skipping to change at page 76, line 12
0x0702 RG Notification Message 0x0702 RG Notification Message
0x0703 RG Application Data Message 0x0703 RG Application Data Message
11.2. TLV TYPE NAME SPACE 11.2. TLV TYPE NAME SPACE
This document use a new LDP TLV type, IANA already maintains a This document use a new LDP TLV type, IANA already maintains a
registry of name "TLV TYPE NAME SPACE" defined by [RFC5036]. The registry of name "TLV TYPE NAME SPACE" defined by [RFC5036]. The
following value is suggested for assignment: following value is suggested for assignment:
TLV Type Description TLV Type Description
0x700 ICCP capability TLV. 0x700 ICCP capability TLV.
0x701 LDP TCP/IP Port TLV.
11.3. ICC RG Parameter Type Space 11.3. ICC RG Parameter Type Space
IANA needs to set up a registry of "ICC RG parameter type". These are IANA needs to set up a registry of "ICC RG parameter type". These are
14-bit values. Parameter Type values 1 through 0x000F are specified 14-bit values. Parameter Type values 1 through 0x000F are specified
in this document, Parameter Type values 0x0010 through 0x1FFF are to in this document, Parameter Type values 0x0010 through 0x1FFF are to
be assigned by IANA, using the "Expert Review" policy defined in be assigned by IANA, using the "Expert Review" policy defined in
[RFC5226]. Parameter Type values 0x2000 through 0x2FFF, 0x3FFF, and 0 [RFC5226]. Parameter Type values 0x2000 through 0x2FFF, 0x3FFF, and 0
are to be allocated using the IETF consensus policy defined in are to be allocated using the IETF consensus policy defined in
[RFC5226]. Parameter Type values 0x3000 through 0x3FFE are reserved [RFC5226]. Parameter Type values 0x3000 through 0x3FFE are reserved
skipping to change at page 76, line 5 skipping to change at page 77, line 40
0x00010007 0 ICCP Administratively Disabled 0x00010007 0 ICCP Administratively Disabled
0x00010010 0 ICCP RG Removed 0x00010010 0 ICCP RG Removed
0x00010011 0 ICCP Application Removed from RG 0x00010011 0 ICCP Application Removed from RG
12. Acknowledgments 12. Acknowledgments
The authors wish to acknowledge the important contributions of Dennis The authors wish to acknowledge the important contributions of Dennis
Cai, Neil McGill, Amir Maleki, Dan Biagini, Robert Leger, Sami Cai, Neil McGill, Amir Maleki, Dan Biagini, Robert Leger, Sami
Boutros, Neil Ketley and Mark Christopher Sains. Boutros, Neil Ketley and Mark Christopher Sains.
The authors also thank Daniel Cohn, Lizhong Jin and Ran Chen for the
valuable input, discussions and comments.
13. Normative References 13. Normative References
[RFC5036] L. Andersson et al, "LDP Specification", RFC 5036, [RFC5036] L. Andersson et al, "LDP Specification", RFC 5036,
October 2007. October 2007.
[RFC5561] "LDP Capabilities", RFC5561, July 2009. [RFC5561] "LDP Capabilities", RFC5561, July 2009.
[RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L.,
et al., rfc4447 April 2006. et al., rfc4447 April 2006.
skipping to change at page 76, line 26 skipping to change at page 78, line 26
metropolitan area networks- Link Aggregation", IEEE Computer metropolitan area networks- Link Aggregation", IEEE Computer
Society, November 2008. Society, November 2008.
[RFC2863] K. McCloghrie, F. Kastenholz, "The Interfaces Group MIB", [RFC2863] K. McCloghrie, F. Kastenholz, "The Interfaces Group MIB",
rfc2863, June 2000. rfc2863, June 2000.
14. Informative References 14. Informative References
[RED-BIT] Praveen Muley, Mustapha Aissaoui, "Pseudowire [RED-BIT] Praveen Muley, Mustapha Aissaoui, "Pseudowire
Preferential Forwarding Status Bit", Preferential Forwarding Status Bit",
draft-ietf-pwe3-redundancy-bit-07.txt, May 2012, Work in progress. draft-ietf-pwe3-redundancy-bit-07.txt, May 2012,
Work in progress.
[RFC5880] D. Katz, D. Ward, "Bidirectional Forwarding Detection", [RFC5880] D. Katz, D. Ward, "Bidirectional Forwarding Detection",
RFC5880, June 2010 RFC5880, June 2010
[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
15. Author's Addresses 15. Author's Addresses
Luca Martini Luca Martini
skipping to change at page 77, line 23 skipping to change at page 79, line 23
White Waltham, Berks, UK. SL6 3TN White Waltham, Berks, UK. SL6 3TN
e-mail: matthew.bocci@alcatel-lucent.co.uk e-mail: matthew.bocci@alcatel-lucent.co.uk
Satoru Matsushima Satoru Matsushima
Softbank Telecom Softbank Telecom
1-9-1, Higashi-Shinbashi, Minato-ku 1-9-1, Higashi-Shinbashi, Minato-ku
Tokyo 105-7313, JAPAN Tokyo 105-7313, JAPAN
e-mail: satoru.matsushima@tm.softbank.co.jp e-mail: satoru.matsushima@tm.softbank.co.jp
Thomas Nadeau Thomas Nadeau
CA Technologies Juniper Networks
273 Corporate Dr. 10 Technology Park Drive,
Portsmouth, NH 03801 Westford, MA 01886
USA USA
e-mail: Thomas.Nadeau@ca.com e-mail: tnadeau@juniper.net
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 78, line 14 skipping to change at page 80, line 14
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Expiration Date: December 2012 Expiration Date: January 2013
 End of changes. 37 change blocks. 
99 lines changed or deleted 216 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/