< draft-ietf-pwe3-iccp-07.txt   draft-ietf-pwe3-iccp-08.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: August 7, 2012 Cisco Expires: December 20, 2012 Cisco
Matthew Bocci Satoru Matsushima Matthew Bocci Satoru Matsushima
Alcatel-Lucent Softbank Alcatel-Lucent Softbank
Thomas Nadeau Thomas Nadeau
CA Technologies CA Technologies
February 7, 2012 June 20, 2012
Inter-Chassis Communication Protocol for L2VPN PE Redundancy Inter-Chassis Communication Protocol for L2VPN PE Redundancy
draft-ietf-pwe3-iccp-07.txt draft-ietf-pwe3-iccp-08.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 August 7, 2012 This Internet-Draft will expire on December 20, 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 65, line 35 skipping to change at page 65, line 35
For VPLS, there could be multiple ACs per service instance (i.e. 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 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 Active. If ALL ACs are Standby, then the PW status should be
Standby. Standby.
In this case, the PW-RED application does not synchronize PW status In this case, the PW-RED application does not synchronize PW status
across chassis, per se. Rather, the AC Redundancy application should across chassis, per se. Rather, the AC Redundancy application should
synchronize AC status between chassis, in order to determine which AC synchronize AC status between chassis, in order to determine which AC
(and subsequently which PE) is Active or Standby for a given service. (and subsequently which PE) is Active or Standby for a given service.
When that is determined, each PE will then adjust its local PWs state When that is determined, each PE will then adjust its local PWs state
according to the rules described above. 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 On the other hand, if an AC redundancy mechanism is not in use, then
the PW-RED application is used to synchronize pseudowire state. This the PW-RED application is used to synchronize pseudowire state. This
is done by sending the "PW-RED State TLV" whenever the pseudowire is done by sending the "PW-RED State TLV" whenever the pseudowire
state changes on a PE. This includes changes to the local end as state changes on a PE. This includes changes to the local end as
well as the remote end of the 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
skipping to change at page 74, line 12 skipping to change at page 74, 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 16 skipping to change at page 76, line 16
[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.
[IEEE-802.1AX] IEEE Std. 802.1AX-2008, "IEEE Standard for Local and [IEEE-802.1AX] IEEE Std. 802.1AX-2008, "IEEE Standard for Local and
metropolitan area networks- Link Aggregation", metropolitan area networks- Link Aggregation", IEEE Computer
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
Preferential Forwarding Status Bit",
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
Cisco Systems, Inc. Cisco Systems, Inc.
skipping to change at page 77, line 31 skipping to change at page 77, line 31
Thomas Nadeau Thomas Nadeau
CA Technologies CA Technologies
273 Corporate Dr. 273 Corporate Dr.
Portsmouth, NH 03801 Portsmouth, NH 03801
USA USA
e-mail: Thomas.Nadeau@ca.com e-mail: Thomas.Nadeau@ca.com
Copyright Notice Copyright Notice
Copyright (c) 2011 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
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
skipping to change at line 3311 skipping to change at page 78, line 13
Contributions published or made publicly available before November Contributions published or made publicly available before November
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
 End of changes. 10 change blocks. 
8 lines changed or deleted 14 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/