idnits 2.17.1 draft-ietf-ospf-multi-instance-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 date (February 27, 2009) is 5536 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 (==), 1 comment (--). 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: August 31, 2009 S. Mirtorabi 6 Cisco Systems 7 February 27, 2009 9 OSPF Multi-Instance Extensions 10 draft-ietf-ospf-multi-instance-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 31, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 OSPFv3 includes a mechanism for supporting multiple instances on the 49 same link. OSPFv2 could benefit from such a mechanism in order to 50 support multiple routing domains on the same subnet. The OSPFv2 51 instance ID is reserved for support of separate OSPFv2 protocol 52 instances. This is different from OSPFv3 where it could be used for 53 other purposes such as putting the same link in multiple areas. 54 OSPFv2 supports this capability using a separate subnet or the OSPF 55 multi-area adjacency capability. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 61 2. OSPFv2 Instance Packet Encoding . . . . . . . . . . . . . . . 4 62 3. OSPF Interface Instance ID . . . . . . . . . . . . . . . . . . 6 63 3.1. Sending and Receiving OSPF packets . . . . . . . . . . . . 6 64 4. State Sharing Optimizations between OSPF instances . . . . . . 7 65 5. Backward Compatibility and Deployment Considerations . . . . . 8 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 69 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 72 1. Introduction 74 OSPFv3 [OSPFV3] includes a mechanism for supporting multiple 75 instances on the same link. OSPFv2 [OSPFV2] could benefit from such 76 a mechanism in order to support multiple routing domains on the same 77 subnet. The OSPFv2 instance ID is reserved for support of separate 78 OSPFv2 protocol instances. This is different from OSPFv3 where it 79 could be used for other purposes such as putting the same link in 80 multiple areas. OSPFv2 supports this capability using a separate 81 subnet or the OSPF multi-area adjacency capability [MULTI-AREA]. 83 1.1. Requirements notation 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC-KEYWORDS]. 89 2. OSPFv2 Instance Packet Encoding 91 OSPFv2 currently doesn't offer a mechanism to differentiate packets 92 for different instances sent and received on the same interface. In 93 support of this capability, this document introduces a modified 94 packet header format when the Authentication Type field is split into 95 an instance ID and type. 97 0 1 2 3 98 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 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | Version # | Type | Packet length | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Router ID | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | Area ID | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Checksum | Instance ID | AuType | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Authentication | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Authentication | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 The OSPFv2 Packet Header 115 Version # 116 The OSPFv2 version number - 2 118 Type 119 The OSPFv2 packet type as specified [OSPFV2]. 121 Packet length 122 The length of the OSPF protocol packet in bytes. This length 123 includes the standard OSPF header. 125 Router ID 126 The Router ID of the packet's source. 128 Area ID 129 A 32-bit number identifying the area corresponding the packet as 130 specified in [OSPFV2]. 132 Checksum 133 OSPFv2 standard checksum calculation as specified in specified in 134 [OSPFV2]. 136 Instance ID 137 Enables multiple instances of OSPF to be run over a single link. 138 Each protocol instance would be assigned a separate Instance ID; 139 the Instance ID has local subnet significance only. Received 140 packets with an Instance ID not equal to one of the configured 141 OSPF Instance IDs on the receiving interface MUST be discarded. 143 AuType 144 OSPFv2 authentication type as specified in specified in [OSPFV2]. 146 Authentication 147 A 64-bit field for Authentication type dependent authentication 148 data. 150 3. OSPF Interface Instance ID 152 OSPF [OSPFV2] describes the conceptual interface data structure in 153 section 9. The OSPF Interface ID will be added to this structure. 154 The Interface Instance ID will default to 0. Its setting to a non- 155 zero value may be accomplished through configuration or implied by 156 some usage beyond the scope of this document. 158 3.1. Sending and Receiving OSPF packets 160 When sending OSPF packets, if the interface instance ID has a non- 161 zero value, it will be set in the OSPF packet header. When receiving 162 OSPF packets, the OSPFv2 Header Instance ID will be used to aid in 163 demultiplexing the packet and routing it to the correct OSPFv2 164 instance. Received packets with an Instance ID not equal to one of 165 the configured OSPF Instance IDs on the receiving interface MUST be 166 discarded. 168 4. State Sharing Optimizations between OSPF instances 170 This is beyond the scope of this draft and is an area for further 171 study. 173 5. Backward Compatibility and Deployment Considerations 175 When there are OSPF routers that support this capability on the same 176 broadcast capable link as those that do not, packets with non-zero 177 Instance IDs will be received by those legacy routers. Since the 178 authentication type will be unknown to them they will not process the 179 packet. This is exactly what is desired. 181 Previously, a concern was that some implementations will log every 182 single authentication type mismatch. However, discussions with 183 implementers have led us to the conclusion that this is not as 184 current a problem as we'd first thought and it will be even less of a 185 problem by the time the mechanism in this draft is standardized, 186 implemented, and deployed. Hence, the controversial mechanisms to 187 avoid legacy routers receiving multicast OSPF packets with a non-zero 188 instance ID have been removed. 190 6. Security Considerations 192 The enhancement described herein doesn't add any additional security 193 considerations to OSPFv2. Security considerations for OSPFv2 are 194 described in [OSPFV2]. 196 Given that only three OSPFv2 authentication types have been 197 standardized, it seems reasonable to reduce the OSPF packet header 198 field to 8 bits. 200 7. IANA Considerations 202 A new registry will be added for OSPF Instance IDs. The allocation 203 is TBD. 205 Dependent on the approach, two new multicast addresses from the IPv4 206 Multicast Addresses registry would need to be allocated. 208 Dependent on the approach, a new protocol ID may need to be allocated 209 from the Protocol Numbers registry. 211 8. Normative References 213 [MULTI-AREA] 214 Mirtorabi, S., Psenak, P., Lindem, A., and A. Oswal, "OSPF 215 Multi-Area Adjacency", RFC 5185, May 2008. 217 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 219 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 220 for IPv6", RFC 5340, July 2008. 222 [RFC-KEYWORDS] 223 Bradner, S., "Key words for use in RFC's to Indicate 224 Requirement Levels", RFC 2119, March 1997. 226 Appendix A. Acknowledgments 228 The RFC text was produced using Marshall Rose's xml2rfc tool. 230 Thanks to Paul Wells for commenting on the backward compatibility 231 issues. 233 Authors' Addresses 235 Acee Lindem 236 Redback Networks 237 102 Carric Bend Court 238 Cary, NC 27519 239 USA 241 Email: acee@redback.com 243 Abhay Roy 244 Cisco Systems 245 225 West Tasman Drive 246 San Jose, CA 95134 247 USA 249 Email: akr@cisco.com 251 Sina Mirtorabi 252 Cisco Systems 253 3 West Plumeria Drive 254 San Jose, CA 95134 255 USA 257 Email: sina@cisco.com