idnits 2.17.1 draft-acee-ospf-multi-instance-02.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 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 294. 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 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 (September 21, 2008) is 5690 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: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem 3 Internet-Draft Redback Networks 4 Intended status: Standards Track A. Roy 5 Expires: March 25, 2009 Cisco Systems 6 S. Mirtorabi 7 Nuova Systems 8 September 21, 2008 10 OSPF Multi-Instance Extensions 11 draft-acee-ospf-multi-instance-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 25, 2009. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 OSPFv3 includes a mechanism for supporting multiple instances on the 45 same link. OSPFv2 could benefit from such a mechanism in order to 46 support multiple routing domains on the same subnet. The OSPFv2 47 instance ID is reserved for support of separate OSPFv2 protocol 48 instances. This is different from OSPFv3 where it could be used for 49 other purposes such as putting the same link in multiple areas. 50 OSPFv2 supports this capability using a separate subnet or the OSPF 51 multi-area adjacency capability. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 57 2. OSPFv2 Instance Packet Encoding . . . . . . . . . . . . . . . 4 58 3. OSPF Interface Instance ID . . . . . . . . . . . . . . . . . . 6 59 3.1. Sending and Receiving OSPF packets . . . . . . . . . . . . 6 60 4. State Sharing Optimizations between OSPF instances . . . . . . 7 61 5. Backward Compatibility and Deployment Considerations . . . . . 8 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 65 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 67 Intellectual Property and Copyright Statements . . . . . . . . . . 14 69 1. Introduction 71 OSPFv3 [OSPFV3] includes a mechanism for supporting multiple 72 instances on the same link. OSPFv2 [OSPFV2] could benefit from such 73 a mechanism in order to support multiple routing domains on the same 74 subnet. The OSPFv2 instance ID is reserved for support of separate 75 OSPFv2 protocol instances. This is different from OSPFv3 where it 76 could be used for other purposes such as putting the same link in 77 multiple areas. OSPFv2 supports this capability using a separate 78 subnet or the OSPF multi-area adjacency capability [MULTI-AREA]. 80 1.1. Requirements notation 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC-KEYWORDS]. 86 2. OSPFv2 Instance Packet Encoding 88 OSPFv2 currently doesn't offer a mechanism to differentiate packets 89 for different instances sent and received on the same interface. In 90 support of this capability, this document introduces a modified 91 packet header format when the Authentication Type field is split into 92 an instance ID and type. 94 0 1 2 3 95 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 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | Version # | Type | Packet length | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | Router ID | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | Area ID | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | Checksum | Instance ID | AuType | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Authentication | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Authentication | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 The OSPFv2 Packet Header 112 Version # 113 The OSPFv2 version number - 2 115 Type 116 The OSPFv2 packet type as specified [OSPFV2]. 118 Packet length 119 The length of the OSPF protocol packet in bytes. This length 120 includes the standard OSPF header. 122 Router ID 123 The Router ID of the packet's source. 125 Area ID 126 A 32-bit number identifying the area corresponding the packet as 127 specified in [OSPFV2]. 129 Checksum 130 OSPFv2 standard checksum calculation as specified in specified in 131 [OSPFV2]. 133 Instance ID 134 Enables multiple instances of OSPF to be run over a single link. 135 Each protocol instance would be assigned a separate Instance ID; 136 the Instance ID has local subnet significance only. Received 137 packets with an Instance ID not equal to one of the configured 138 OSPF Instance IDs on the receiving interface MUST be discarded. 140 AuType 141 OSPFv2 authentication type as specified in specified in [OSPFV2]. 143 Authentication 144 A 64-bit field for Authentication type dependent authentication 145 data. 147 3. OSPF Interface Instance ID 149 OSPF [OSPFV2] describes the conceptual interface data structure in 150 section 9. The OSPF Interface ID will be added to this structure. 151 The Interface Instance ID will default to 0. Its setting to a non- 152 zero value may be accomplished through configuration or implied by 153 some usage beyond the scope of this document. 155 3.1. Sending and Receiving OSPF packets 157 When sending OSPF packets, if the interface instance ID has a non- 158 zero value, it will be set in the OSPF packet header. When receiving 159 OSPF packets, the OSPFv2 Header Instance ID will be used to aid in 160 demultiplexing the packet and routing it to the correct OSPFv2 161 instance. Received packets with an Instance ID not equal to one of 162 the configured OSPF Instance IDs on the receiving interface MUST be 163 discarded. 165 4. State Sharing Optimizations between OSPF instances 167 This is beyond the scope of this draft and is an area for further 168 study. 170 5. Backward Compatibility and Deployment Considerations 172 When there are OSPF routers that support this capability on the same 173 broadcast capable link as those that do not, packets with non-zero 174 Instance IDs will be received by those legacy routers. Since the 175 authentication type will be unknown to them they will not process the 176 packet. This is exactly what is desired. 178 Previously, a concern was that some implementations will log every 179 single authentication type mismatch. However, discussions with 180 implementers have led us to the conclusion that this is not as 181 current a problem as we'd first thought and it will be even less of a 182 problem by the time the mechanism in this draft is standardized, 183 implemented, and deployed. Hence, the controversial mechanisms to 184 avoid legacy routers receiving multicast OSPF packets with a non-zero 185 instance ID have been removed. 187 6. Security Considerations 189 The enhancement described herein doesn't add any additional security 190 considerations to OSPFv2. Security considerations for OSPFv2 are 191 described in [OSPFV2]. 193 Given that only three OSPFv2 authentication types have been 194 standardized, it seems reasonable to reduce the OSPF packet header 195 field to 8 bits. 197 7. IANA Considerations 199 A new registry will be added for OSPF Instance IDs. The allocation 200 is TBD. 202 Dependent on the approach, two new multicast addresses from the IPv4 203 Multicast Addresses registry would need to be allocated. 205 Dependent on the approach, a new protocol ID may need to be allocated 206 from the Protocol Numbers registry. 208 8. Normative References 210 [MULTI-AREA] 211 Mirtorabi, S., Psenak, P., Lindem, A., and A. Oswal, "OSPF 212 Multi-Area Adjacency", RFC 5185, May 2008. 214 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 216 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 217 for IPv6", RFC 5340, July 2008. 219 [RFC-KEYWORDS] 220 Bradner, S., "Key words for use in RFC's to Indicate 221 Requirement Levels", RFC 2119, March 1997. 223 Appendix A. Acknowledgments 225 The RFC text was produced using Marshall Rose's xml2rfc tool. 227 Thanks to Paul Wells for commenting on the backward compatibility 228 issues. 230 Authors' Addresses 232 Acee Lindem 233 Redback Networks 234 102 Carric Bend Court 235 Cary, NC 27519 236 USA 238 Email: acee@redback.com 240 Abhay Roy 241 Cisco Systems 242 225 West Tasman Drive 243 San Jose, CA 95134 244 USA 246 Email: akr@cisco.com 248 Sina Mirtorabi 249 Nuova Systems 250 3 West Plumeria Drive 251 San Jose, CA 95134 252 USA 254 Email: sina@nuovasystems.com 256 Full Copyright Statement 258 Copyright (C) The IETF Trust (2008). 260 This document is subject to the rights, licenses and restrictions 261 contained in BCP 78, and except as set forth therein, the authors 262 retain all their rights. 264 This document and the information contained herein are provided on an 265 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 266 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 267 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 268 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 269 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 270 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 272 Intellectual Property 274 The IETF takes no position regarding the validity or scope of any 275 Intellectual Property Rights or other rights that might be claimed to 276 pertain to the implementation or use of the technology described in 277 this document or the extent to which any license under such rights 278 might or might not be available; nor does it represent that it has 279 made any independent effort to identify any such rights. Information 280 on the procedures with respect to rights in RFC documents can be 281 found in BCP 78 and BCP 79. 283 Copies of IPR disclosures made to the IETF Secretariat and any 284 assurances of licenses to be made available, or the result of an 285 attempt made to obtain a general license or permission for the use of 286 such proprietary rights by implementers or users of this 287 specification can be obtained from the IETF on-line IPR repository at 288 http://www.ietf.org/ipr. 290 The IETF invites any interested party to bring to its attention any 291 copyrights, patents or patent applications, or other proprietary 292 rights that may cover technology that may be required to implement 293 this standard. Please address the information to the IETF at 294 ietf-ipr@ietf.org. 296 Acknowledgment 298 Funding for the RFC Editor function is provided by the IETF 299 Administrative Support Activity (IASA).