idnits 2.17.00 (12 Aug 2021) /tmp/idnits55807/draft-davey-ccamp-gmpls-te-mib-ipv6-addr-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 3978, Section 5.1.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 233. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 255. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 261. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 225), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. 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 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 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 (March 2005) is 6276 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3473' is mentioned on line 161, but not defined == Unused Reference: 'RFC2119' is defined on line 176, but no explicit reference was found in the text == Outdated reference: draft-ietf-ccamp-gmpls-te-mib has been published as RFC 4802 -- Obsolete informational reference (is this intentional?): RFC 2740 (Obsoleted by RFC 5340) -- Obsolete informational reference (is this intentional?): RFC 3784 (Obsoleted by RFC 5305) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT A. Davey 2 draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00 Data Connection Ltd (DCL) 3 Category: Informational A. Farrel 4 Expires: September 2005 Old Dog Consulting 5 T. Nadeau 6 Cisco Systems, Inc. 7 March 2005 9 Handling IPv6 Sources and Destinations in the 10 MPLS and GMPLS TE MIB Modules 11 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright Notice 40 Copyright (C) The Internet Society 2005. All Rights Reserved. 42 Abstract 44 This document describes how to configure or monitor a Multiprotocol 45 Label Switching (MPLS) or Generalized MPLS (GMPLS) Traffic Engineered 46 (TE) Label Switched Path (LSP) using the MPLS and GMPLS TE MIB module 47 where the ingress and/or egress routers are identified using IPv6 48 addresses. 50 1. Terms 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119. 56 2. Overview 58 This document defines a method of defining or monitoring an LSP 59 tunnel using the MPLS TE MIB module [RFC3812] and GMPLS TE MIB module 60 [GMPLSTEMIB] where the ingress and/or egress routers are identified 61 using 128-bit IPv6 addresses. That is, where the 62 mplsTunnelIngressLSRId and mplsTunnelEgressLSRId objects in the 63 mplsTunnelTable [RFC3812] cannot be used to carry the tunnel end 64 point address and Extended Tunnel Id fields from the signaled Session 65 Object because the IPv6 variant (LSP_TUNNEL_IPv6_SESSION object) is 66 in use. 68 3. Identifying LSRs 70 For this feature to be used, all LSRs in the network MUST advertise a 71 32-bit value that can be used to identify the LSR. In this document, 72 this is referred to as the 32-bit router ID. The 32-bit router ID 73 may be, for example, the OSPFv3 router ID [RFC2740] or the ISIS IPv4 74 TE Router ID [RFC3784]. 76 4. Configuring GMPLS tunnels with IPv6 Source and Destination Addresses 78 When setting up RSVP TE tunnels, it is common practice to copy the 79 values of the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields 80 in the MPLS TE MIB mplsTunnelTable [RFC3812] into the Extended Tunnel 81 ID and IPv4 tunnel end point address fields, respectively, in the 82 RSVP-TE LSP_TUNNEL_IPv4 SESSION object [RFC3209]. 84 This approach cannot be used when the ingress and egress routers are 85 identified by 128-bit IPv6 addresses as the mplsTunnelIngressLSRId 86 and mplsTunnelEgressLSRId fields are defined to be 32-bit values 87 [RFC3811] and [RFC3812]. 89 Instead, the IPv6 addresses SHOULD be configured in the mplsHopTable 90 as the first and last hops of the mplsTunnelHopTable entries defining 91 the explicit route for the tunnel. Note that this implies that a 92 tunnel with IPv6 source and destination addresses MUST have an 93 explicit route configured, although it should be noted that the 94 configuration of an explicit route in this way does not imply that 95 an explicit route will be signaled. 97 In more detail, the tunnel is configured at the ingress router as 98 follows. See [RFC3812] for definitions of MIB table objects and for 99 default (that is, "normal") behavior. 101 The mplsTunnelIndex and mplsTunnelInstance fields are set as normal. 103 The mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields SHOULD be 104 set to 32-bit router IDs for ingress and egress LSR respectively. 106 The mplsTunnelHopTableIndex MUST be set to a non-zero value. That 107 is, an explicit route MUST be specified. 109 The first hop of the explicit route MUST have mplsTunnelHopAddrType 110 field set to ipv6(2) and SHOULD have the mplsTunnelHopIpAddr field 111 set to a global scope IPv6 address of the ingress router that is 112 reachable in the control plane. 114 The last hop of the explicit route MUST have mplsTunnelHopAddrType 115 field set to ipv6(2) and SHOULD have the mplsTunnelHopIpAddr field 116 set to a global scope IPv6 address of the egress router that is 117 reachable in the control plane. 119 The ingress router SHOULD set the signaled values of the Extended 120 Tunnel ID and IPv6 tunnel end point address fields, respectively, 121 of the RSVP-TE LSP_TUNNEL_IPv6 SESSION object [RFC3209] from the 122 mplsTunnelHopIpAddr object of the first and last hops in the 123 configured explicit route. 125 5. Managing and Monitoring Tunnel Table Entries 127 The TE MIB module may be used for managing and monitoring MPLS and 128 GMPLS TE LSPs, as well as configuring them as described in section 4. 129 This function is particularly important at egress and transit LSRs. 131 For a tunnel with IPv6 source and destination addresses, an LSR 132 implementation SHOULD return values in the mplsTunnelTable as follows 133 (where "normal" behavior is the default taken from [RFC3812]). 135 The mplsTunnelIndex and mplsTunnelInstance fields are set as normal. 137 The mplsTunnelIngressLSRId field and mplsTunnelEgressLSRId are set to 138 32-bit router IDs. That is, each transit and egress router maps from 139 the IPv6 address in the Extended Tunnel ID field to the 32-bit router 140 ID of the ingress LSR. Each transit router also maps from the IPv6 141 address in the IPv6 tunnel end point address field to the 32-bit 142 router ID of the egress LSR. 144 6. Mixed IPv4 and IPv6 Source and Destination 146 This document has focused on the case where both ingress and egress 147 are identified by IPv6 addresses. It is also possible that only one 148 of the two addresses comes from the IPv6 space. In this case only the 149 text applying to the ingress or egress (as appropriate) should be 150 applied. 152 7. Security Considerations 154 This informational document describes procedures for using existing 155 MIB modules and signaling protocols but does not define any new 156 behavior of the signaling protocol, nor any new configuration 157 operations. As such, no new security considerations are introduced. 159 Readers should be aware of the security considerations set out in the 160 related MIB documents [RFC3812] and [GMPLSTEMIB], as well as those 161 described for the signaling protocols in [RFC3209] and [RFC3473]. 163 8. IANA Considerations 165 This document raises no new IANA considerations. 167 9. References 169 9.1 Normative References 171 [GMPLSTEMIB] Thomas D. Nadeau and Adrian Farrel, editors, 172 "Generalized Multiprotocol Label Switching (GMPLS) 173 Traffic Engineering Management Information Base", 174 draft-ietf-ccamp-gmpls-te-mib, (work in progress). 176 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 177 Requirement Levels", RFC 2119, March 1997. 179 [RFC3209] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for 180 LSP Tunnels," RFC 3209, December 2001. 182 [RFC3811] Nadeau, T. and J. Cucchiara, "Definition of Textual 183 Conventions and for Multiprotocol Label Switching 184 (MPLS) Management", RFC 3811, June 2004. 186 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 187 "Multiprotocol Label Switching (MPLS) Traffic 188 Engineering (TE) Management Information Base (MIB)", 189 RFC 3812, June 2004. 191 9.2 Informative References 193 [RFC2740] Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", 194 RFC 2740, April 1998. 196 [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic 197 Engineering", RFC 3784, June 2004. 199 10. Authors' Addresses 201 Alan Davey 202 Data Connection Ltd 203 100 Church Street 204 EN2 6BQ 205 U.K. 206 Phone: +44 20 8366 1177 207 Email: alan.davey@dataconnection.com 209 Adrian Farrel 210 Old Dog Consulting 211 Phone: +44-(0)-1978-860944 212 Email: adrian@olddog.co.uk 214 Thomas D. Nadeau 215 Cisco Systems, Inc. 216 300 Apollo Drive 217 Chelmsford, MA 01824 218 Phone: +1-978-244-3051 219 Email: tnadeau@cisco.com 221 11. Full Copyright Statement 223 Copyright (C) The Internet Society (2005). This document is subject 224 to the rights, licenses and restrictions contained in BCP 78, and 225 except as set forth therein, the authors retain all their rights. 227 This document and the information contained herein are provided on an 228 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 229 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 230 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 231 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 232 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 233 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 235 This document may not be modified, and derivative works of it may 236 not be created, except to publish it as an RFC and to translate it 237 into languages other than English. 239 Intellectual Property Statement 241 The IETF takes no position regarding the validity or scope of any 242 Intellectual Property Rights or other rights that might be claimed to 243 pertain to the implementation or use of the technology described in 244 this document or the extent to which any license under such rights 245 might or might not be available; nor does it represent that it has 246 made any independent effort to identify any such rights. Information 247 on the procedures with respect to rights in IETF Documents can be 248 found in BCP 78 and BCP 79. 250 Copies of IPR disclosures made to the IETF Secretariat and any 251 assurances of licenses to be made available, or the result of an 252 attempt made to obtain a general license or permission for the use of 253 such proprietary rights by implementers or users of this 254 specification can be obtained from the IETF on-line IPR repository at 255 http://www.ietf.org/ipr. 257 The IETF invites any interested party to bring to its attention any 258 copyrights, patents or patent applications, or other proprietary 259 rights that may cover technology that may be required to implement 260 this standard. Please address the information to the IETF at 261 ietf-ipr@ietf.org.