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