PWE3 Working Group Paul Kwok Internet Draft Pranjal Kumar Dutta Intended status: Standards Track Alcatel-Lucent Expires: January 2012 Fredric Jounay France Telecom July 11, 2011 Pseudowire Communities draft-pkwok-pwe3-pw-communities-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 11, 2009. Copyright Notice Copyright (c) 2011 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 Kwok, et. Al. Expires January 11, 2012 [Page 1] Internet-Draft PW Communities July 2011 carefully, as they describe your rights and restrictions with respect to this document. Abstract [RFC4447] describes a set of procedures for Pseudowire set-up and maintenance using LDP as signaling protocol. [DYN-MSPW} extends the mechanisms described in [RFC4447] for dynamic placement of multi- segment pseudowires. This document describes an extension to [RFC4447] procedures which may be used to pass additional information to S-PE/T-PEs when SS-PWs or MS-PWs are set-up. The intention of the proposed technique is to aid in policy administration, specifically during MS-PW set-up across various S-PEs. The proposed method is very generic so that it can support the management of various parameters or rules while setting up pseudowires with minimal overhead. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................4 3. PW Communities.................................................4 4. Security Considerations........................................5 5. IANA Considerations............................................5 5.1. Normative References......................................5 5.2. Informative References....................................5 6. Acknowledgments................................................6 1. Introduction A Multi-Segment PW (MS-PW) is defined as a set of two or more contiguous segments that behave and function as a single point-to- point PW. An MS-PW enables service providers to extend the reach of PWs across multiple PSN domains. To facilitate and simplify the control of dynamic MS-PW set-up across S-PEs, this document proposes a grouping or "coloring" of PWs so that PW set-up decision can also be based on the identity of the group. Such a scheme is expected to significantly simplify dynamic MS-PW signaling [DYN-MSPW] that controls the MS-PW set-up across the Switching Provider Edge (S-PE) devices. Kwok, et. al. Expires January 11, 2012 [Page 2] Internet-Draft PW Communities July 2011 MS-PW spans across multiple autonomous systems or administrative domains. For security reasons, strict access control is required at S-PEs through which a PW enters another administrative domain. One way is for operators to define a policy at the S-PE that would match the PW set-up requests based on Target Attachment Individual Identifier (TAII) or Source Attachment Individual Identifier (SAII) or Attachment Group Identifier (AGI) etc. Such policies can be complex or very large, leading to administrative overheads or configuration mistakes. Rather, operators could define several tags/colors which can be associated with individual PWs when they are signaled. S-PEs can then apply PW policies based on the received tags, accordingly. This example application eliminates the primary motivation for a complex policy database that may result in the generation of very large PW prefix-based filter rules. A smaller policy database such as this also requires less maintenance, so shortening or eliminating out-of-band maintenance delays. Another application of PW policies is in underlying transport applications. Each S-PE independently chooses a unidirectional PSN tunnel to map a set of PW segments to their next S-PE or T-PE. Such PSN Tunnels could be Label Distribution Protocol (LDP) [RFC5036] or Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) [RFC3209] or Labeled BGP [RFC3107] based LSPs. There is currently no signaling support in [DYN-MSPW] to signal a preference for the type of PSN tunnel to bind a PW to at the S-PEs when multiple tunnel types are available. For example, LDP can be preferred over BGP tunnels when both forms of tunnels are available at an S-PE. Secondly, it is also possible that only a specific RSVP tunnel is preferable to provide a traffic class or QoS treatment, or protection capability, and some form of control is required that LSPs are correctly used by S-PEs. One possible way is to manually configure filter rules by PW ID or AGI/SAII/TAII, but such rules can create significant maintenance overhead and be prone to configuration errors. Further, signaling each of the various types of PSN tunnel selection criteria/preferences in PW set-up messages adds significant burden to LDP label mapping procedures. To address such policy management issues, this draft proposes a very simple solution that allows minimal manual intervention and configuration with no overhead in PW signaling. It introduces a concept of "PW Communities" that can be thought of as templates provisioned at a S-PE/T-PE, based on which of a certain set of rules are applied to all PWs that are tagged as belonging to same community. Note that PW Community is different from PW Grouping (as defined using PW Group ID) defined in [RFC4447]. PW Grouping is associated Kwok, et. al. Expires January 11, 2012 [Page 3] Internet-Draft PW Communities July 2011 with binding of a set of PWs to a common event group for reduced signaling of various intensive events such as Label withdraw or PW Status Notification etc. However, PW Communities can be thought of a coloring of PWs from policy management perspective. It is not necessary that PW Grouping and PW Communities associated with a PW be corelated. 2. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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 0. 3. PW Communities The PW Community attribute is carried in an Interface Parameters Sub-TLV as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter ID | Length | PW Community ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Community ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameter ID = 0x18 Length = 4 PW Community ID = 32 bit identifier for the community to which the PW belongs to. A PW community can be considered as a template that has a set of rules defined locally by a T-PE or S-PE. Each T-PE or S-PE can define its own set of rules and its upto the administrative domain to maintain congruities among PW community rules through which PW set-up process would follow. A LDP peer may use this interface parameter to control information it accepts, prefers or distributes to other peers. Kwok, et. al. Expires January 11, 2012 [Page 4] Internet-Draft PW Communities July 2011 A LDP peer receiving a PW set-up request (label mapping message) that does not carry the PW Community MAY append a PW community TLV when propagating the label mapping message to next S-PE/T-PE. A LDP peer receiving a PW set-up request with PW Community MAY modify the PW community according to local policy while propagating the request to the next-hop. 4. Security Considerations This document does not impose additional security considerations to what is defined in [RFC5036],[RFC4447] and [DYN-MSPW]. 5. IANA Considerations This document proposes a PW Community Interface Parameters Sub-TLV, with a proposed type of 0x18, to be allocated from the PWE3 Pseudowire Interface Parameters sub-TLV type registry. References 5.1. Normative References [RFC5036] Andersson, Minei, Thomas. "LDP Specification" RFC5036, October 2007 [RFC4447] "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", Martini L.,et al, RFC 4447, June 2005. [DYN-MSPW] "Dynamic Placement of Multi Segment Pseudo Wires", Martini L., et al, draft-ietf-pwe3-dynamic-ms-pw-13.txt, October 2010. [RFC3219] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5.2. Informative References TBD. Kwok, et. al. Expires January 11, 2012 [Page 5] Internet-Draft PW Communities July 2011 6. Acknowledgments The authors would like to acknowledge the valuable comments and suggestions from Mathew Bocci and Wim Henderickx. This document was prepared using 2-Word-v2.0.template.dot. Kwok, et. al. Expires January 11, 2012 [Page 6] Internet-Draft PW Communities July 2011 Authors' Addresses Paul Kwok Alcatel-Lucent 701 E Middlefield Road Mountain View, CA 94043 USA. Email: paul.kwok@alcatel-lucent.com Pranjal Kumar Dutta Alcatel-Lucent 701 E Middlefield Road Mountain View, CA 94043 USA. Email: pranjal.dutta@alcatel-lucent.com Frederic Jounay France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: frederic.jounay@orange-ftgroup.com Kwok, et. al. Expires January 11, 2012 [Page 7]