summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6667.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6667.txt')
-rw-r--r--doc/rfc/rfc6667.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc6667.txt b/doc/rfc/rfc6667.txt
new file mode 100644
index 0000000..56eb3f5
--- /dev/null
+++ b/doc/rfc/rfc6667.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) K. Raza
+Request for Comments: 6667 S. Boutros
+Category: Standards Track C. Pignataro
+ISSN: 2070-1721 Cisco Systems
+ July 2012
+
+
+ LDP 'Typed Wildcard' Forwarding Equivalence Class (FEC) for
+ PWid and Generalized PWid FEC Elements
+
+Abstract
+
+ The "Typed Wildcard Forwarding Equivalence Class (FEC) Element"
+ defines an extension to the Label Distribution Protocol (LDP) that
+ can be used when requesting, withdrawing, or releasing all label
+ bindings for a given FEC Element type is desired. However, a Typed
+ Wildcard FEC Element must be individually defined for each FEC
+ Element type. This specification defines the Typed Wildcard FEC
+ Elements for the Pseudowire Identifier (PWid) (0x80) and Generalized
+ PWid (0x81) FEC Element types.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by
+ the Internet Engineering Steering Group (IESG). Further
+ information on Internet Standards is available in Section 2 of
+ RFC 5741.
+
+ Information about the current status of this document, any
+ errata, and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6667.
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+
+
+
+
+Raza, et al. Standards Track [Page 1]
+
+RFC 6667 PWid and Gen. PWid Typed Wildcard FEC July 2012
+
+
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may not be modified, and derivative works of it may not
+ be created, except to format it for publication as an RFC or to
+ translate it into languages other than English.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Typed Wildcard for PW FEC Elements ..............................3
+ 3. Applicability Statement .........................................4
+ 4. Operation .......................................................4
+ 4.1. PW Consistency Check .......................................5
+ 4.2. PW Graceful Shutdown .......................................5
+ 4.3. Wildcard PW Status .........................................5
+ 4.4. Typed Wildcard MAC Withdrawal in VPLS ......................6
+ 5. Security Considerations .........................................6
+ 6. Acknowledgments .................................................7
+ 7. References ......................................................7
+ 7.1. Normative References .......................................7
+ 7.2. Informative References .....................................7
+
+1. Introduction
+
+ An extension to the Label Distribution Protocol (LDP) [RFC5036]
+ defines the general notion of a "Typed Wildcard Forwarding
+ Equivalence Class (FEC) Element" [RFC5918]. This can be used when
+ requesting, releasing, or withdrawing all label bindings for a given
+ type of FEC Element is desired. However, a Typed Wildcard FEC
+ Element must be individually defined for each type of FEC Element.
+
+ [RFC4447] defines the "PWid FEC Element" and "Generalized PWid FEC
+ Element", but does not specify the Typed Wildcard format for these
+ elements. This document specifies the format of the Typed Wildcard
+ FEC Element for the "PWid FEC Element" and "Generalized PWid FEC
+ Element". The procedures for Typed Wildcard processing for PWid and
+ Generalized PWid FEC Elements are the same as described in [RFC5918]
+ for any Typed Wildcard FEC Element type.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+
+
+
+Raza, et al. Standards Track [Page 2]
+
+RFC 6667 PWid and Gen. PWid Typed Wildcard FEC July 2012
+
+
+2. Typed Wildcard for PW FEC Elements
+
+ The format of the Typed Wildcard FEC Element for PWid and Generalized
+ PWid is specified as:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Typed Wcard=0x5| Type=PW FEC | Len = 2 |R| PW type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | . . . |
+ +-+-+-+-+-+-+-+-+
+
+ Figure 1: Format of Typed Wildcard FEC Element for
+ PW FEC Element Types
+
+ Where:
+
+ Typed Wcard (one octet): Typed Wildcard FEC Element type (0x05)
+ as specified in [RFC5918].
+
+ [FEC Element] Type (one octet): PW FEC Element type:
+
+ PWid: (type 0x80 [RFC4447])
+ Generalized PWid: (type 0x81 [RFC4447])
+
+ Len [FEC Type Info] (one octet): Two. (There is additional
+ FEC info to scope the Typed Wildcard.)
+
+ R bit (Reserved bit): MUST be set to ZERO on transmit and ignored
+ on receipt.
+
+ PW type (15-bits): PW type as specified in [RFC4447]. This field
+ is used to scope the wildcard FEC operation to limit all PWs
+ of a given type. This MUST be set to "Wildcard" type
+ (0x7FFF), as defined in [IANA-PWE3], when referring PWs of
+ all types (see Section 4 for its usage).
+
+ [RFC4447] defines the "PW Grouping ID TLV" that can be used for
+ wildcard withdrawal or status messages related to Generalized PWid
+ FECs. When the Typed Wildcard FEC for Generalized PWid FEC element
+ is in use, the "PW Grouping ID TLV" MUST NOT be present in the same
+ message. If present, the receiving Label Switching Router (LSR) MUST
+ ignore this TLV silently and process the rest of the message.
+
+
+
+
+
+
+
+Raza, et al. Standards Track [Page 3]
+
+RFC 6667 PWid and Gen. PWid Typed Wildcard FEC July 2012
+
+
+3. Applicability Statement
+
+ The Typed Wildcard FEC Elements defined in this document for the PWid
+ and Generalized PWid FEC Elements provide a finer degree of
+ granularity when compared to the wildcard FEC mechanics defined in
+ [RFC5036].
+
+ The PWid FEC Element as defined in [RFC4447] contains a Group ID
+ field. This field is defined as an arbitrary 32-bit value that
+ represents a group of PWs and is used to create groups in the PW
+ space, including potentially a single group of all PWs for a given
+ FEC Element type. This grouping enables an LSR to send "wildcard"
+ label withdrawals and/or status notification messages corresponding
+ to a PW group upon physical port failures. Similarly, [RFC4447]
+ defines the "PW Grouping ID TLV" used in the same fashion for the
+ Generalized PWid FEC Element.
+
+ The PWid Typed Wildcard FEC Elements defined in this document help us
+ achieve similar functionality as the "Group ID" field or "PW Grouping
+ ID TLV" for label withdrawal and status notification messages.
+ Additionally, the Typed Wildcard procedures [RFC5918] provide a more
+ generalized and comprehensive solution by allowing:
+
+ 1. Typed Wildcard Label Request messages
+
+ 2. Label TLVs in label messages to further constrain the wildcard to
+ all FECs of the specified FEC type [and its specific filter] that
+ are also bound to the specified label.
+
+ This document allows use of the Typed Wildcard PW FEC Element in any
+ LDP message that specifies a FEC TLV as a mandatory or optional
+ parameter of the message. In addition to LDP label messages, this
+ also applies to notification messages (containing PW Status) and
+ Address Withdraw (for MAC address withdrawal [RFC4762]) messages in
+ the context of LDP PW signaling. When a Typed Wildcard PW FEC
+ Element is used in an Address Withdraw message for Virtual Private
+ LAN Service (VPLS) Media Access Control (MAC) address withdrawal, the
+ MAC List TLV MUST contain an empty list.
+
+4. Operation
+
+ The use of Typed Wildcard FEC Elements for PW can be useful under
+ several scenarios. This section describes some use cases to
+ illustrate their application. The following use cases consider two
+ LSR nodes, A and B, with an LDP session between them to exchange
+ Layer 2 Virtual Private Network (L2VPN) PW bindings.
+
+
+
+
+
+Raza, et al. Standards Track [Page 4]
+
+RFC 6667 PWid and Gen. PWid Typed Wildcard FEC July 2012
+
+
+4.1. PW Consistency Check
+
+ A user may request a control-plane consistency check at LSR A for the
+ Generalized PWid FEC bindings that it learned from LSR B over the LDP
+ session. To perform this consistency check, LSR A marks all its
+ learned Generalized PWid FEC bindings from LSR B as stale, and then
+ sends a Label Request message towards LSR B for the Typed Wildcard
+ FEC Element for Generalized PWid FEC Element type with the PW type
+ set to "Wildcard" (0x7FFF). Upon receipt of such a request, LSR B
+ replays its database related to the Generalized PWid FEC Element
+ using one or more Label Mapping messages. As a PW binding is
+ received at LSR A, the associated binding state is marked as
+ refreshed (not stale). When replay completes for the Generalized
+ PWid FEC type, LSR B marks the end of its replay by sending an
+ End-of-LIB notification [RFC5919] corresponding to the Generalized
+ PWid FEC Element type. Upon receipt of this notification at LSR A,
+ any remaining stale PW binding of the Generalized PWid FEC type
+ learned from the peer LSR B is cleaned up and removed from the
+ database. This completes the consistency check with LSR B at LSR A
+ for Generalized PWid FEC type.
+
+4.2. PW Graceful Shutdown
+
+ It may be desirable to perform shutdown/removal of existing PW
+ bindings advertised towards a peer in a graceful manner -- i.e., all
+ advertised PW bindings are to be removed from a peer without session
+ flap. For example, to request a graceful delete of the PWid FEC and
+ Generalized PWid FEC bindings at LSR A learned from LSR B, LSR A
+ would send a Label Withdraw message towards LSR B with Typed Wildcard
+ FEC Elements pertaining to the PWid FEC Element (with PW type set to
+ 0x7FFF) and Generalized PWid FEC Element (with PW type set to
+ 0x7FFF). Upon receipt of such a message, LSR B would delete all PWid
+ and Generalized PWid bindings learned from LSR A. Afterwards, LSR B
+ would send Label Release messages corresponding to received Label
+ Withdraw messages with the Typed FEC Element.
+
+4.3. Wildcard PW Status
+
+ The Typed Wildcard FEC Elements for PW FECs can be very useful to
+ convey PW status amongst LSRs. The Provider Edge (PE) devices can
+ send the "PW Status TLV" in an LDP Notification message to indicate
+ PW status (i.e., a Pseudowire Status Code denoting, for example, a
+ particular fault) to their remote peers [RFC4447]. In case of a
+ global failure affecting all PWs, an LSR typically sends one PW
+ Status LDP Notification message per PW. This per-PW-Status message
+ has scalability implications in a large-scale network with a large
+ number of PWs.
+
+
+
+
+Raza, et al. Standards Track [Page 5]
+
+RFC 6667 PWid and Gen. PWid Typed Wildcard FEC July 2012
+
+
+ Using Typed Wildcard FEC Element for a given type of PW FEC Element,
+ the LSR will need to send only one PW Status Notification message
+ with the Typed Wildcard PW FEC specified to notify about the common
+ status applicable to all PWs as scoped by the PW Typed Wildcard FEC.
+
+4.4. Typed Wildcard MAC Withdrawal in VPLS
+
+ [RFC4762] defines a pseudowire-based solution to implement Virtual
+ Private LAN Service (VPLS). Section 6.2 of RFC 4762 describes MAC
+ Withdrawal procedures and extensions in a VPLS environment. These
+ procedures use the LDP Address Withdraw message containing the FEC
+ TLV (with the PW FEC element corresponding to the VPLS instance) and
+ MAC List TLV (to specify addresses to be withdrawn). The procedures
+ described in RFC 4762 also allow MAC address withdrawal wildcarding
+ for a given VPLS instance.
+
+ Using RFC 4762 procedures, a PE LSR can withdraw all MAC addresses
+ for a given VPLS instance by sending an Address Withdraw message with
+ a VPLS instance corresponding to the PW FEC element in a FEC TLV, and
+ a MAC List TLV with an empty list of addresses. If there is more
+ than one VPLS instance on a given PE LSR node, separate Address
+ Withdraw messages need to be sent by the PE LSR if it wishes to
+ withdraw MAC addresses for all or a subset of VPLS instances upon
+ some global failure or configuration. Per-PW (VPLS instance) MAC
+ Withdraw message may have some scalability implications in a large-
+ scale network.
+
+ As stated in Section 3, this document allows use of the Typed
+ Wildcard PW FEC in Address Withdraw messages corresponding to VPLS
+ MAC Withdrawal. The use of PW Typed Wildcard FEC enhances the scope
+ of MAC withdrawal beyond just a single VPLS instance and allows a PE
+ node to wildcard withdraw all MAC addresses for:
+
+ o all VPLS instances; or
+ o all VPLS instances corresponding to a given PW type.
+
+5. Security Considerations
+
+ No new security considerations beyond those that apply to
+ specifications [RFC5036], [RFC4447], [RFC4762], [RFC5918], and
+ [RFC5920] apply to the use of the PW Typed Wildcard FEC Element types
+ described in this document.
+
+
+
+
+
+
+
+
+
+Raza, et al. Standards Track [Page 6]
+
+RFC 6667 PWid and Gen. PWid Typed Wildcard FEC July 2012
+
+
+6. Acknowledgments
+
+ The authors would like to thank Eric Rosen, Reshad Rahman, Siva
+ Sivabalan, and Zafar Ali for their review and valuable comments. We
+ also acknowledge Daniel Cohn for suggesting use of the Typed Wildcard
+ PW FEC for VPLS MAC withdrawal.
+
+ This document was prepared using 2-Word-v2.0 template.dot.
+
+7. References
+
+7.1. Normative References
+
+ [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
+ "LDP Specification", RFC 5036, October 2007.
+
+ [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution
+ Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
+ (FEC)", RFC 5918, August 2010.
+
+ [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas,
+ "Signaling LDP Label Advertisement Completion", RFC 5919,
+ August 2010.
+
+ [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
+ G. Heron, "Pseudowire Setup and Maintenance Using the
+ Label Distribution Protocol (LDP)", RFC 4447, April 2006.
+
+ [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private
+ LAN Service (VPLS) Using Label Distribution Protocol
+ (LDP) Signaling", RFC 4762, January 2007.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to
+ Indicate Requirement Levels", BCP 14, RFC 2119, March
+ 1997.
+
+7.2. Informative References
+
+ [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
+ Networks", RFC 5920, July 2010.
+
+ [IANA-PWE3] Internet Assigned Numbers Authority, "Pseudo Wires Name
+ Spaces (PWE3)",
+ http://www.iana.org/assignments/pwe3-parameters, May
+ 2011.
+
+
+
+
+
+
+Raza, et al. Standards Track [Page 7]
+
+RFC 6667 PWid and Gen. PWid Typed Wildcard FEC July 2012
+
+
+Authors' Addresses
+
+ Kamran Raza
+ Cisco Systems, Inc.
+ 2000 Innovation Drive
+ Ottawa ON K2K-3E8
+ Canada
+ EMail: skraza@cisco.com
+
+ Sami Boutros
+ Cisco Systems, Inc.
+ 3750 Cisco Way
+ San Jose, CA 95134
+ USA
+ EMail: sboutros@cisco.com
+
+ Carlos Pignataro
+ Cisco Systems, Inc.
+ 7200 Kit Creek Road
+ Research Triangle Park, NC 27709-4987
+ USA
+ EMail: cpignata@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raza, et al. Standards Track [Page 8]
+