idnits 2.17.00 (12 Aug 2021) /tmp/idnits56535/draft-davey-ccamp-gmpls-ipv6-if-index-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 173. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 195. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 201. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 165), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3471]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2005) is 6304 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) == Outdated reference: draft-ietf-ospf-ospfv3-traffic has been published as RFC 5329 == Outdated reference: draft-ietf-isis-ipv6-te has been published as RFC 6119 == Outdated reference: draft-ietf-mpls-bundle has been published as RFC 4201 Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Davey 3 INTERNET-DRAFT N. Neate 4 Updates: RFC3471 Data Connection Ltd (DCL) 5 Expires: August 2005 6 February 2005 8 Generalized Multi-Protocol Label Switching (GMPLS) 9 Control Channel Separation with an IPv6 Control Plane 10 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 or will be disclosed, and any of which I become aware will be 17 disclosed, in accordance with RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Copyright Notice 37 Copyright (C) The Internet Society 2005. All Rights Reserved. 39 Abstract 41 This document specifies extensions to GMPLS signalling with control 42 channel separation, [RFC3471], to use 128-bit IPv6 addresses to 43 identify routers in an IPv6 control plane. 45 1. Terms 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119. 51 2. Overview 53 Currently, GMPLS signalling with control channel separation 54 identifies the particular data channel being controlled by providing 55 interface identification information TLVs [RFC3471]. For unnumbered 56 and component interfaces, interface indentification is achieved 57 through the tuple of a 32-bit IP address and an interface ID. The IP 58 address field may carry either an IP address of a link or an IP 59 address associated with the router, where associated address is the 60 value carried in a router address TLV of routing. 62 An IPv6 address of a link is clearly 128-bits. Also, drafts to 63 define traffic engineering extensions to IGP protocols for use in 64 IPv6 networks use 128-bit router addresses: see definition of "Router 65 IPv6 Address" in [OSPFv3-TE] and "IPv6 TE Router ID" in [ISIS-TE]. 67 This document proposes a simple extension to [RFC3471] that allows 68 GMPLS signalling with control channel separation to be used with 69 an IPv6 control plane. 71 3. Interface Identification 73 A new TLV type is defined to extend the Interface_ID defined in 74 [RFC3471]. The type is 6, IPv6_IF_INDEX (suggested value; to be 75 assigned by IANA). The length is 24 and the value fields have the 76 following format. 78 0 1 2 3 79 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 80 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 81 | IPv6 Address | 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 | IPv6 Address (continued) | 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 85 | IPv6 Address (continued) | 86 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 87 | IPv6 Address (continued) | 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | Interface ID | 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 IPv6 Address: 128 bits 94 The IPv6 address field may carry either an IPv6 address of a 95 link or an IPv6 address associated with the router, where 96 associated address is the value carried in an IPv6 router 97 address TLV of routing. That is, the "Router 98 IPv6 Address", [OSPFv3-TE], when the IGP is OSPFv3 and "IPv6 99 TE Router ID", [ISIS-TE], when the IGP is IS-IS. 101 Interface ID: 32 bits 103 As defined in [RFC3471]. 105 Note that [RFC3471] defines two other types, COMPONENT_IF_DOWNSTREAM 106 and COMPONENT_IF_UPSTREAM with the same format as the IF_INDEX type. 107 However, these types have been deprecated by [MPLS-BUNDLE]. 108 Therefore, no IPv6 equivalents to COMPONENT_IF_DOWNSTREAM and 109 COMPONENT_IF_UPSTREAM are defined. 111 6. Security Considerations 113 This document raises no new security considerations. 115 7. IANA Considerations 117 This document defines a new value for the Interface_ID Type: 6. 119 8. References 121 8.1 Normative References 123 [RFC3471] L. Berger, Editor, "Generalized Multi-Protocol Label 124 Switching (GMPLS) Signaling Functional Description" 125 RFC3471, January 2003. 127 [OSPFv3-TE] 128 K. Ishiguro and T. Takada, "Traffic Engineering Extensions 129 to OSPF version 3", draft-ietf-ospf-ospfv3-traffic-02.txt, 130 July 2004 (work in progress). 132 [ISIS-TE] J. Harrison, J. Berger and M. Bartlett, "IPv6 Traffic 133 Engineering in IS-IS", draft-ietf-isis-ipv6-te-00.txt, 134 January 2005 (work in progress). 136 8.2 Informative References 138 [MPLS-BUNDLE] 139 K.Kompella, Y.Rekhter and L.Berger, "Link Bundling in MPLS 140 Traffic Engineering", draft-ietf-mpls-bundle-06.txt, 141 December 2004 (work in progress). 143 9. Authors' Addresses 145 Alan Davey 146 Data Connection Ltd 147 100 Church Street 148 EN2 6BQ 149 U.K. 150 Phone: +44 20 8366 1177 151 Email: alan.davey@dataconnection.com 153 Nic Neate 154 Data Connection Ltd 155 100 Church Street 156 EN2 6BQ 157 U.K. 158 Phone: +44 20 8366 1177 159 Email: nic.neate@dataconnection.com 161 9. Full Copyright Statement 163 Copyright (C) The Internet Society (2005). This document is subject 164 to the rights, licenses and restrictions contained in BCP 78, and 165 except as set forth therein, the authors retain all their rights. 167 This document and the information contained herein are provided on an 168 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 169 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 170 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 171 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 172 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 173 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 175 This document may not be modified, and derivative works of it may 176 not be created, except to publish it as an RFC and to translate it 177 into languages other than English. 179 Intellectual Property Statement 181 The IETF takes no position regarding the validity or scope of any 182 Intellectual Property Rights or other rights that might be claimed to 183 pertain to the implementation or use of the technology described in 184 this document or the extent to which any license under such rights 185 might or might not be available; nor does it represent that it has 186 made any independent effort to identify any such rights. Information 187 on the procedures with respect to rights in IETF Documents can be 188 found in BCP 78 and BCP 79. 190 Copies of IPR disclosures made to the IETF Secretariat and any 191 assurances of licenses to be made available, or the result of an 192 attempt made to obtain a general license or permission for the use of 193 such proprietary rights by implementers or users of this 194 specification can be obtained from the IETF on-line IPR repository at 195 http://www.ietf.org/ipr. 197 The IETF invites any interested party to bring to its attention any 198 copyrights, patents or patent applications, or other proprietary 199 rights that may cover technology that may be required to implement 200 this standard. Please address the information to the IETF at 201 ietf-ipr@ietf.org.