From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6667.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc6667.txt (limited to 'doc/rfc/rfc6667.txt') 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] + -- cgit v1.2.3