Network Working Group K.Nagahashi Internet-Draft The Univ. of Tokyo Expires: April 24, 2006 T.Yoshida NTT Communications K.Kondo Intec Netcore October 24, 2005 IRIS - A Routing Registry (rreg) Type for the Internet Registry Information Service draft-kengo-crisp-iris-rreg-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 June 16, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes an IRIS registry schema for Internet Routing information. The schema extends the necessary query and result operations of IRIS to provide the kengo, et al. Expires June 16, 2005 [Page 1] Internet-Draft iris-rreg December 2004 functional information service needs for syntaxes and results used by Internet Protocol address registries. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Feedback from Operators. . . . . . . . . . . . . . . . . . . . 5 Intellectual Property and Copyright Statements . . . . . . . . 5 Kengo, et al. Expires August 14, 2005 [Page 2] Internet-Draft iris-rreg December 2004 1. Introduction This document describes an IRIS namespace for Internet routing registries using an XML Schema [9] derived from and using the IRIS [2] schema. This schema and registry type are provided to demonstrate the extensibility of the IRIS framework beyond the use of domains, a criteria defined in CRISP [4]. The schema given is this document is specified using the Extensible Markup Language (XML) 1.0 as described in XML [6], XML Schema notation as described in XML_SD [8] and XML_SS [9], and XML Namespaces as described in XML_NS [7]. 1.1 Motivation Our intention to apply CRISP framework into Routing Registry is due to the current messy architecture of routing registries. They are scattered around the world but neither hierarchical strcutre nor recursive look-up are performed. This derives an inaccurate routing information in Routing Registry. We have strong motivation to improve accuracy of the routing registries by introducing CRISP framework into routing registries. 2 steps must be taken to improve the situation , (1) defines XML Schema for Routing Registry and (2)deploy CRISP enabled Routing Registry. This document only focuses on the definition of XML schema for routing registries, and the deployment issues will be described in another document. Kengo, et al. Expires April 24, 2006 [Page 3] Internet-Draft iris-rreg October 2005 2. Document Terminology 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 RFC2119. 3. Requirements and Consideration 3.1 Requirements Like other iris schema e.g. areg, dreg, routing registry should be defined XML schema which comprises query and responce. The query and responce in routing registry is similer with areg since main objective of routing registry is to manage prefix, autonomous system and contact information. Followings are architectual requirements for implementing rreg, which is obviously different with other regs. 1)RREG is intended to adapt into IRR(Internet Routing Registry), IRR offers various kinds of routing information such as prefix related information say who maintain its prefix and origin-as, or Autonomous System information, say, what's policy AS represents like who imports, and export? This syntax itself is defined by RPSL (Routing Policy Specification Language) and requires not only to interpret the language but also to support data transfer way in current IRR architecture. A current data transfer way in IRR is mirroring. mirroring offers both advantages and disadvantages; the most important advantage is to guarantee "local copy" of all IRR databases. Unlike address or domain registry, routing registry requires "guarantee for data access" strictly. Suppose one ISP launches IRR database and mirroring every 30 min, the ISP generates configuration from IRR database, if all network from IRR database will be down, no actual configurations are made. This story demands for highly redundancy where even if network is isolated, data access is still guaranteed. 2)root resolution Since a routing registry are distributed without strong relation, root resolution is a hard issue to solve. One of straight forward solution is to decide the root e.g. "rreg.nro.net" uniquely but it still requires to discuss about it. 3)query and registration A word "IRR" includes both query and registration, however, scope of rreg is only for query mechanism, no registration mechanism is comprised. A registration protocol is standalized as EPP[11] and this will be described at 3.2.2. Kengo, et al. Expires April 24, 2006 [Page 4] Internet-Draft iris-rreg October 2005 3.2 Architectual Consideration 3.2.1 mirroring mirroring is an extreme implementatation of high redundancy. If all IRR databases are mirroring each other, every IRR database can guarantee local data access. On the other hand, mirroring lacks scalability; if a number of IRR database is increased, mirrorring overhead is likely increased. In that context, scalability and redundancy are trade-off parameters to design routing registry architecture. 2 architectures can be assumemed for providing redundant rreg; 1)to provide mirroring functionality into rreg 2)to employ redundancy mechanism in CRISP framework As for 1), a simple idea is to define mirroring protocol and put the protocol into rreg specification. The protocol itself is not complicated; almost required function is to provide data synchronisation with updating serial number. In about 2), IRIS framework provides S-NAPTR[12] cohabitation, this framework is not complete solution for "guarantee for data access" but this is another candidate for providing redundancy. 3.2.2 query and registration relation with EPP As shown in requirement, data registration is another property of IRR functions. However, rreg does not provide data registration only provides query mechanism. 2 approaches can be assumed for 1)introducing registration function into rreg spec 2)out of scope with rreg spec Since one of current issues in IRR is non-real time mirroring, where due to non-real time update, all data does not propagate correctly. This issue is not derived from registration but from query mechanism. Our intention is to improve query mecanism with employing CRISP framework. Thus data registration is out of scope with rreg spec. Kengo, et al. Expires April 24, 2006 [Page 5] Internet-Draft iris-rreg October 2005 4.Feedbacks from Operators TBD 5. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [2] Newton, A., "Internet Registry Information Service", draft-ietf-crisp-iris-core-07 (work in progress), July 2004. [3] Newton, A., "Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)", draft-ietf-crisp-iris-beep-07 (work in progress), July 2004. [4] Newton, A., "Cross Registry Internet Service Protocol (CRISP) Requirements", RFC 3707, February 2004. [5] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [6] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, . [7] World Wide Web Consortium, "Namespaces in XML", W3C XML Namespaces, January 1999, . [8] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XML Schema, October 2000, . [9] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XML Schema, October 2000, . [10] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", RFC 1700, STD 2, October 1994. [11] S. Hollenbeck,Extensible Provisioning Protocol (EPP) Mar 2004,RFC3730 [12] L. Daigle, A. Newton, Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS) Jan 2005, RFC3958 Kengo, et al. Expires April 24, 2006 [Page 6] Internet-Draft iris-rreg October 2005 Authors' Addresses Kengo Nagahashi The University of Tokyo 403 3rd. Eng. Bldng. 7-6-1 Hongo, Bunkyo-ku Japan Phone: +81 3 5841 7465 EMail: kengo@nagahashi.org Tomoya Yoshida NTT Communications Kuniaki Kondo Intec Netcore Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.