idnits 2.17.1 draft-ietf-trill-directory-extensions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 8, 2016) is 2849 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald Eastlake 2 Intended status: Proposed Standard Linda Dunbar 3 Huawei 4 Radia Perlman 5 EMC 6 Fangwei Hu 7 ZTE 8 Expires: January 7, 2017 July 8, 2016 10 TRILL Directory Extensions 11 13 Abstract 15 TRILL (Transparent Interconnection of Lots of Links) push and pull 16 directories (RFC 7067) specified in draft-ietf-trill-directory- 17 assist-mechanisms provide directory services to TRILL switches but 18 not to end stations. This document extends those services so that end 19 stations can pull directory information from Pull Directory severs 20 and can have directory information pushed to them from Push Directory 21 servers. In each case, at least one co-operating edge TRILL switch is 22 required. 24 Status of This Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Distribution of this document is unlimited. Comments should be sent 30 to the authors or the TRILL working group mailing list: 31 trill@ietf.org 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 45 Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 Table of Contents 50 1. Introduction............................................3 51 1.1 Terminology............................................3 53 2. Extensions to Pull Directory............................4 55 3. Extensions to Push Directory............................5 57 4. IANA Considerations.....................................6 59 5. Security Considerations.................................7 61 Normative References.......................................8 62 Informative References.....................................8 64 Acknowledgments............................................8 66 Authors' Addresses.........................................9 68 1. Introduction 70 TRILL (Transparent Interconnection of Lots of Links) [RFC6325] push 71 and pull directories [RFC7067] specified in [Directory] provide 72 directory services to TRILL switches but not to end stations. This 73 document extends those services so that end stations can pull 74 directory information from Pull Directory severs and can have 75 directory information pushed to them from Push Directory servers. In 76 each case, at least one co-operating edge RBridge is required. 78 Section 2 specifies the extensions to Pull Directories. Section 3 79 Specifies the extensions to Push Directories. 81 1.1 Terminology 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 TBD 89 2. Extensions to Pull Directory 91 Pull Directory support is optionally extended to end station clients 92 as specified in this section. 94 When Pull Directory support is provided by an edge RBridge to end 95 stations, the messages used are as specified in [Directory] for the 96 support of a Pull Directory hosted on an end station with the 97 following changes: 99 (1) a different RBridge Channel [RFC7178] protocol number is used, 100 and 102 (2) the roles of the end station and edge RBridge are reversed, that 103 is, instead of the edge RBridge using a Pull Directory on an end 104 station there is an end station using a Pull Directory service 105 through an edge RBridge. 107 An end station can tell which, if any, of the edge RBridges to which 108 it is attached support this service by examining their TRILL IS-IS 109 Hellos messages to see if they support the "Pull Directory Service to 110 End Station" RBridge Channel Protocol (see Section 4). 112 3. Extensions to Push Directory 114 TBD 116 4. IANA Considerations 118 IANA is requested to assign an RBridge Channel protocol number from 119 the range assigned based on standards action as the "Pull Directory 120 Service to End Station" protocol adding a line to the RBridge Channel 121 Protocols registry on the TRILL Parameters web page as follows: 123 Protocol Description Reference 124 -------- ----------- --------- 125 TBD Pull Directory Service to End Station [this document] 127 5. Security Considerations 129 TBD 131 For security considerations of directory services, see [Directory]. 133 For general TRILL security considerations, see [RFC6325]. 135 Normative References 137 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 138 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 139 March 1997, . 141 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 142 Ghanwani, "Routing Bridges (RBridges): Base Protocol 143 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 144 . 146 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 147 Ward, "Transparent Interconnection of Lots of Links (TRILL): 148 RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 149 2014, . 151 [Directory] - D. Eastlake, L. Dunbar, R. Perlman, Y. Li, "TRILL: Edge 152 Directory Assist Mechanisms", draft-ietf-trill-directory- 153 assist-mechanisms, work in progress. 155 Informative References 157 [RFC7067] - Dunbar, et, al "Directory Assistance Problem and High- 158 Level Design Proposal", RFC7067, Nov, 2013. 160 Acknowledgments 162 The document was prepared in raw nroff. All macros used were defined 163 within the source file. 165 Authors' Addresses 167 Donald Eastlake 168 Huawei Technologies 169 155 Beaver Street 170 Milford, MA 01757 USA 172 Phone: +1-508-333-2270 173 Email: d3e3e3@gmail.com 175 Linda Dunbar 176 Huawei Technologies 177 5340 Legacy Drive, Suite 175 178 Plano, TX 75024, USA 180 Phone: +1-469-277-5840 181 Email: linda.dunbar@huawei.com 183 Radia Perlman 184 EMC 185 2010 256th Avenue NE, #200 186 Bellevue, WA 98007 USA 188 Email: Radia@alum.mit.edu 190 Fangwei Hu 191 ZTE Corporation 192 No.889 Bibo Rd 193 Shanghai 201203 China 195 Phone: +86 21 68896273 196 Email: hu.fangwei@zte.com.cn 198 Copyright, Disclaimer, and Additional IPR Provisions 200 Copyright (c) 2016 IETF Trust and the persons identified as the 201 document authors. All rights reserved. 203 This document is subject to BCP 78 and the IETF Trust's Legal 204 Provisions Relating to IETF Documents 205 (http://trustee.ietf.org/license-info) in effect on the date of 206 publication of this document. Please review these documents 207 carefully, as they describe your rights and restrictions with respect 208 to this document. Code Components extracted from this document must 209 include Simplified BSD License text as described in Section 4.e of 210 the Trust Legal Provisions and are provided without warranty as 211 described in the Simplified BSD License. The definitive version of 212 an IETF Document is that published by, or under the auspices of, the 213 IETF. Versions of IETF Documents that are published by third parties, 214 including those that are translated into other languages, should not 215 be considered to be definitive versions of IETF Documents. The 216 definitive version of these Legal Provisions is that published by, or 217 under the auspices of, the IETF. Versions of these Legal Provisions 218 that are published by third parties, including those that are 219 translated into other languages, should not be considered to be 220 definitive versions of these Legal Provisions. For the avoidance of 221 doubt, each Contributor to the IETF Standards Process licenses each 222 Contribution that he or she makes as part of the IETF Standards 223 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 224 language to the contrary, or terms, conditions or rights that differ 225 from or are inconsistent with the rights and licenses granted under 226 RFC 5378, shall have any effect and shall be null and void, whether 227 published or posted by such Contributor, or included with or in such 228 Contribution.