< draft-ietf-pwe3-pw-typed-wc-fec-02.txt   draft-ietf-pwe3-pw-typed-wc-fec-03.txt >
PWE3 Working Group Kamran Raza PWE3 Working Group Kamran Raza
Internet Draft Cisco Systems Internet Draft Sami Boutros
Intended Status: Standards Track Intended Status: Standards Track Carlos Pignataro
Expiration Date: July 11, 2012 Sami Boutros Expiration Date: August 5, 2012
Cisco Systems
Carlos Pignataro
Cisco Systems Cisco Systems
January 12, 2012 February 6, 2012
LDP Typed Wildcard FEC for PWid and Generalized PWid LDP Typed Wildcard FEC for PWid and Generalized PWid
FEC Elements FEC Elements
draft-ietf-pwe3-pw-typed-wc-fec-02.txt draft-ietf-pwe3-pw-typed-wc-fec-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified, provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English. as an RFC and to translate it into languages other than English.
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
skipping to change at page 1, line 41 skipping to change at page 1, line 38
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any 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 July 11, 2012. This Internet-Draft will expire on August 5, 2012.
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 2, line 37 skipping to change at page 2, line 38
Table of Contents Table of Contents
1. Introduction .................................................. 3 1. Introduction .................................................. 3
2. Typed Wildcard for PW FEC Elements ............................ 3 2. Typed Wildcard for PW FEC Elements ............................ 3
3. Applicability Statement ....................................... 4 3. Applicability Statement ....................................... 4
4. Operation ..................................................... 5 4. Operation ..................................................... 5
4.1. PW Consistency Check ...................................... 5 4.1. PW Consistency Check ...................................... 5
4.2. PW Graceful Shutdown ...................................... 5 4.2. PW Graceful Shutdown ...................................... 5
4.3. Wildcard PW Status ........................................ 6 4.3. Wildcard PW Status ........................................ 6
5. Security Considerations ....................................... 6 4.4. Typed Wildcard MAC Withdrawal in VPLS ..................... 6
6. IANA Considerations ........................................... 6 5. Security Considerations ....................................... 7
7. Acknowledgments ............................................... 6 6. IANA Considerations ........................................... 7
8. References .................................................... 6 7. Acknowledgments ............................................... 7
8.1. Normative References ...................................... 6 8. References .................................................... 7
8.2. Informative References .................................... 7 8.1. Normative References ...................................... 7
Authors' Addresses ............................................... 7 8.2. Informative References .................................... 8
Authors' Addresses ............................................... 8
1. Introduction 1. Introduction
An extension [RFC5918] to the Label Distribution Protocol (LDP) An extension [RFC5918] to the Label Distribution Protocol (LDP)
[RFC5036] defines the general notion of a "Typed Wildcard Forwarding [RFC5036] defines the general notion of a "Typed Wildcard Forwarding
Equivalence Class (FEC) Element". This can be used when it is Equivalence Class (FEC) Element". This can be used when it is
desired to request all label bindings for a given type of FEC desired to request all label bindings for a given type of FEC
Element, or to release or withdraw all label bindings for a given Element, or to release or withdraw all label bindings for a given
type of FEC element. However, a typed wildcard FEC element must be type of FEC element. However, a typed wildcard FEC element must be
individually defined for each type of FEC element. individually defined for each type of FEC element.
skipping to change at page 5, line 8 skipping to change at page 5, line 8
achieve the similar functionality as "Group ID" field or "PW Grouping achieve the similar functionality as "Group ID" field or "PW Grouping
ID TLV" for label withdrawal and status notification messages; ID TLV" for label withdrawal and status notification messages;
Additionally, the Typed Wildcard procedures [RFC5918] also provide Additionally, the Typed Wildcard procedures [RFC5918] also provide
more generalized and comprehensive solution by allowing: more generalized and comprehensive solution by allowing:
1. Typed-Wildcard Label Request messages 1. Typed-Wildcard Label Request messages
2. Label TLV in label messages to further constraint the wildcard to 2. Label TLV in label messages to further constraint the wildcard to
all FECs of the specified FEC type [and its specific filter] that all FECs of the specified FEC type [and its specific filter] that
are also bound to the specified label. are also bound to the specified label.
This document allows the use of Typed Wildcard PW FEC Element in any
LDP message that specifies a FEC TLV as 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]) in the
context of LDP PW signaling. When a Typed Wildcard PW FEC element is
used in a Address Withdraw message for VPLS MAC address withdrawal,
the MAC List TLV MUST contain an empty list.
4. Operation 4. Operation
The use of Typed Wildcard FEC elements for PW can be useful under The use of Typed Wildcard FEC elements for PW can be useful under
several scenarios. This section describes some use cases to several scenarios. This section describes some use cases to
illustrate their usage. The following use cases consider two LSR illustrate their usage. The following use cases consider two LSR
nodes, A and B, with LDP session between them to exchange L2VPN PW nodes, A and B, with LDP session between them to exchange L2VPN PW
bindings. bindings.
4.1. PW Consistency Check 4.1. PW Consistency Check
skipping to change at page 6, line 22 skipping to change at page 6, line 32
affecting all PWs, an LSR typically sends one PW Status LDP affecting all PWs, an LSR typically sends one PW Status LDP
Notification message per PW. This per PW Status message has Notification message per PW. This per PW Status message has
scalability implications in a large-scale network with large number scalability implications in a large-scale network with large number
of PWs. of PWs.
Using Typed Wildcard FEC Element for given type of PW FEC Element, Using Typed Wildcard FEC Element for given type of PW FEC Element,
the LSR will need to send only one PW Status Notification message the LSR will need to send only one PW Status Notification message
with Typed Wildcard PW FEC specified to notify about the common with Typed Wildcard PW FEC specified to notify about the common
status applicable to all PWs as scoped by the PW Typed Wildcard FEC. 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 an VPLS environment. These
procedures use LDP Address Withdraw message containing FEC TLV (with
PW FEC element corresponding to the VPLS instance) and MAC List TLV
(to specify addresses to be withdrawn). RFC-4762 procedures also
allow MAC addresses 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
VPLS instance corresponding PW FEC element in a FEC TLV, and MAC List
TLV with an empty list of addresses. If there are more than one VPLS
instance on a given PE LSR node, separate Address Withdraw messages
will need to be sent by PE LSR if it wishes to withdraw MAC addresses
for all or subset of VPLS instances upon some global failure or
configuration. This per PW (VPLS instance) MAC Withdraw messages may
have some scalability implications in large-scale network.
As stated in section 3, this document allows use of Typed Wildcard PW
FEC in Address Withdraw messages corresponding to VPLS MAC
Withdrawal. The usage 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 5. Security Considerations
No new security considerations beyond that apply to the base LDP No new security considerations beyond that apply to the base LDP
specification [RFC5036], [RFC4447] and [RFC5920] apply to the use of specification [RFC5036], [RFC4447], [RFC4762], and [RFC5920] apply to
the PW Typed Wildcard FEC Element types described in this document. the use of the PW Typed Wildcard FEC Element types described in this
document.
6. IANA Considerations 6. IANA Considerations
None. None.
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Eric Rosen, Siva Sivabalan, and Zafar The authors would like to thank Eric Rosen, Reshad Rahman, Siva
Ali for their valuable comments. Sivabalan, and Zafar Ali for their review and valuable comments. We
also acknowledge Daniel Cohn for suggesting the use of Typed Wildcard
PW FEC for VPLS MAC withdrawal.
This document was prepared using 2-Word-v2.0 template.dot. This document was prepared using 2-Word-v2.0 template.dot.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP Specification", [RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP Specification",
RFC 5036, September 2007. RFC 5036, September 2007.
[RFC5918] R. Asati, I. Minei, and B. Thomas, "LDP Typed Wildcard [RFC5918] R. Asati, I. Minei, and B. Thomas, "LDP Typed Wildcard
Forwarding Equivalence Class", RFC 5918, August 2010. Forwarding Equivalence Class", RFC 5918, August 2010.
[RFC5919] R. Asati, P. Mohapatra, E. Chen, and B. Thomas, "Signaling [RFC5919] R. Asati, P. Mohapatra, E. Chen, and B. Thomas, "Signaling
LDP Label Advertisement Completion", RFC 5919, August 2009. LDP Label Advertisement Completion", RFC 5919, August 2009.
[RFC4447] L. Martini, E. Rosen, El-Aawar, T. Smith, and G. Heron, [RFC4447] L. Martini, E. Rosen, El-Aawar, T. Smith, and G. Heron,
"Pseudowire Setup and Maintenance using the Label "Pseudowire Setup and Maintenance using the Label
Distribution Protocol", RFC 4447, April 2006. Distribution Protocol", RFC 4447, April 2006.
[RFC4762] M. Lasserre, and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997. Requirement Levels", BCP 14, RFC2119, March 1997.
8.2. Informative References 8.2. Informative References
[RFC5920] L. Fang (Editor), et al., "Security Framework for MPLS and [RFC5920] L. Fang (Editor), et al., "Security Framework for MPLS and
GMPLS Networks", RFC 5920, July 2010. GMPLS Networks", RFC 5920, July 2010.
[IANA-PWE3] Internet Assigned Numbers Authority, "Pseudo Wires Name [IANA-PWE3] Internet Assigned Numbers Authority, "Pseudo Wires Name
Spaces (PWE3)", http://www.iana.org/assignments/pwe3- Spaces (PWE3)", http://www.iana.org/assignments/pwe3-
parameters, May 2011. parameters, May 2011.
Authors' Addresses Authors' Addresses
Kamran Raza Kamran Raza
Cisco Systems, Inc., Cisco Systems, Inc.,
2000 Innovation Drive, 2000 Innovation Drive,
Ottawa, ON K2K-3E8, Canada. Ottawa, ON K2K-3E8, Canada.
Email: skraza@cisco.com Email: skraza@cisco.com
Sami Boutros Sami Boutros
 End of changes. 12 change blocks. 
24 lines changed or deleted 67 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/