idnits 2.17.00 (12 Aug 2021) /tmp/idnits61132/draft-shen-isis-ospf-p2p-over-lan-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 121: '... circuit MUST include the IP interf...' RFC 2119 keyword, line 128: '... LAN IIHs, it MUST discard the inco...' RFC 2119 keyword, line 129: '...e point-to-point IIHs, it MUST discard...' RFC 2119 keyword, line 132: '...-lan circuit, it MUST discard the pack...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 2001) is 7638 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: 5 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Naiming Shen 2 Internet Draft Acee Lindem 3 Expiration Date: December 2001 Jenny Yuan 4 File name: draft-shen-isis-ospf-p2p-over-lan-00.txt Redback Networks 5 June 2001 7 Point-to-point operation over LAN 8 in link-state routing protocols 10 draft-shen-isis-ospf-p2p-over-lan-00.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 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 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as 26 "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 Two different circuit types are commonly used by link state routing 37 protocols: point-to-point and broadcast. It is important to identify 38 the correct circuit type in forming adjacency with neighbors, 39 in flooding link state database packets, in representation of the 40 circuit subnet. This document describes a simple mechanism to treat 41 the broadcast media as point-to-point connection from IP routing 42 protocol point of view if there are only two devices on the LAN 43 media. 45 1. Introduction 47 Point-to-point and broadcast media are two most common circuit 48 types used by link state routing protocols such as IS-IS [ref1] 49 [ref2] and OSPF [ref3]. They are treated differently with respect 50 to establishing neighbor adjacencies, link state database flooding, 51 representation of the media subnet, SPF calculation and protocol 52 packets. The most important difference is there is a designated 53 router concept associated with the broadcast media and pseudo node 54 is used to represent the information on the LAN media. 56 Compared with broadcast circuits, point-to-point circuits are 57 afford more straightforward IGP operation. There is no designated 58 router involved and there is no representation of the pseudo-node 59 or network LSA in the link state database. For ISIS, there also no 60 periodic database synchronization. Conversely, if there are more 61 than two routers on the LAN media, the traditional view of the 62 broadcast media will reduce the routing information in the network. 64 When there are only two routers on the broadcast media, it makes 65 more sense to treat the connection between the two routers as a 66 point-to-point one. This document describes the mechanism to 67 allow link state routing protocols to operate using point-to-point 68 connection over broadcast media under this condition. Some 69 implication with forwarding IP packets on this type of circuit 70 is also discussed. We will refer to this as p2p-over-lan circuit 71 in this document. 73 2. Motivation 75 Even though the broadcast media is meant to handle more than two 76 devices, there exist cases where only two routers are interconnected 77 over the physical or logical broadcast media: 79 o simply only two routers on the physical LAN. 80 o two routers are connected directly back to back using 81 broadcast media, mainly for long-haul operation. 82 o only two routers exist on the virtual LAN. 84 In any of the above cases, the link state routing protocols will 85 normally still treat the circuit as a broadcast type. Thus it will 86 have the overhead involved with protocol LAN operation but without 87 the benefit of reducing routing information designed for the LAN 88 environment. 90 Even when there are multiple routers on the LAN an ISP may want 91 to sub-group the routers into multiple vLANs since this allows 92 them to assign different costs to IGP neighbors. When there are 93 only two routers in some of the vLANs, this broadcast media can be 94 viewed by the IGP as a mesh of point-to-point connections. As a 95 side benefit, unnumbered interface can also be applied over LAN. 97 3. Point-to-point connection over LAN media 99 The idea is very simple: provide a configuration mechanism to 100 inform the IGP that the circuit is type point-to-point 101 irrespective of the physical media type. For the IGP, this implies 102 that it will send protocol packets with the appropriate 103 point-to-point information and expects to receive protocol packets 104 as they would be received on a point-to-point circuit. Over LAN 105 media, the MAC header must contain the correct multicast MAC address 106 to be received by the other side of the connection. For vLAN 107 environments, the MAC header must also contain the proper vLAN ID. 109 3.1 Operation of IS-IS 111 This p2p-over-lan circuit extension for IS-IS is only concerned 112 in pure IP routing and forwarding operation. 114 Since physically the circuit is a broadcast one, the IS-IS packets 115 need to have MAC addresses for this p2p-over-lan circuit. From 116 link layer point of view, those packets are IS-IS LAN packets. The 117 Multi-destination address, either AllL1ISs or AllL2ISs defined 118 in [ref1], is used for the point-to-point IS-IS PDUs. 120 The circuit needs to have IP address(es) and the p2p IIH over this 121 circuit MUST include the IP interface address(es) as defined in 122 [ref2]. The IP address(es) can be numbered or unnumbered. Note 123 that the term "unnumbered" here means this interface sets the 124 IP address to any one of the other IP addresses belong to this 125 router. 127 If the circuit is configured as point-to-point type and receives 128 LAN IIHs, it MUST discard the incoming packets; If the circuit 129 is a LAN type and receive point-to-point IIHs, it MUST discard 130 the incoming packets. If the system ID of incoming IIH does not 131 match the system ID of already established adjacency over this 132 p2p-over-lan circuit, it MUST discard the packet. The 133 implementation should offer enough logging or debugging 134 information to detect mis-configurations. 136 3.2 Operation of OSPF 138 OSPF routers supporting the capabilities described herein must 139 support an additional interface configuration parameter specifying 140 the interface topology type. For LAN (i.e., broadcast capable) 141 media, the interface may be viewed as a point-to-point interface. 142 Both routers on the LAN will simply join the AllSPFRouters 143 (224.0.0.5) multicast group and send all OSPF packets to 224.0.0.5. 144 This is identical to operation over a physical point-to-point link 145 as described in sections 8.1 and 8.2 of [ref3]. 147 3.3 IP forwarding and ARP 149 Unlike normal point-to-point IGP circuit, the IP nexthop for the 150 routes using this p2p-over-lan circuit as outbound interface is not 151 optional. The IP nexthop address has to be a valid interface or 152 internal address on the adjacent router. This address is used by 153 local router to obtain the MAC address for IP packet forwarding. 154 Proxy ARP has to be enabled if the address is not the adjacent 155 interface IP address. 157 In the case where unnumbered IP addresses are used for p2p-over-lan 158 circuit, the source IA of ARP request and the target interface IA 159 are usually on different subnets. The ARP should reply only if this 160 circuit is a p2p-over-lan type and the source IA of the ARP request 161 is the same as the neighbor's interface IP address at the other end. 162 The neighbor's address is learned from IGP hello exchanges over this 163 circuit. 165 4. Compatibility 167 Routers on both sides of the broadcast media connection have to 168 support this p2p-over-lan extension in order to establish adjacency 169 to each other. Otherwise, the traditional LAN model for the IGP 170 has to be used on this media. 172 5. Scalability Issues 174 There is obvious advantage to use this extension if the broadcast 175 media between two routers are connected back-to-back. To model 176 the LAN as a number of vLANs with this extension does sacrifice 177 the scalability property of the LAN representation for link-state 178 routing protocols. It will in general increase the link-state 179 database size, the amount of packets to be flooded and the 180 route calculation time thus the network overall convergence time. 182 The network design engineers should carefully balance between the 183 need of more precise routing control and the scalability of the 184 network. The scalability impact is less of a concern if the LAN 185 and routers involved are within a single link-state subdomain 186 in hierarchical IGP routing. 188 6. Security Issues 190 This document does not introduce any new security issues to ISIS or 191 OSPF. For ARP to support unnumbered IP interface addresses, it needs 192 to verify the p2p-over-lan circuit type described in this document 193 and to verify the ARP packet source IA to match the IGP adjacency 194 interface IP address. This is due to normal ARP sanity check for 195 common subnet can not be applied in this case. 197 7. Acknowledgments 199 TBA. 201 8. References 203 [ref1] ISO. Information Technology - Telecommunications and 204 Information Exchange between Systems - Intermediate System 205 to Intermediate System Routing Exchange Protocol for 206 Use in Conjunction with the Protocol for Providing the 207 Connectionless-Mode Network Service. ISO, 1990. 209 [ref2] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual 210 Environments. INTERNET-RFC, Internet Engineering Task Force, 211 December 1990. 213 [ref3] J. Moy. OSPF Version 2. Technical Report RFC2328 Internet 214 Engineering Task Force, 1998. 216 9. Authors' Addresses 218 Naiming Shen 219 Redback Networks 220 350 Holger Way 221 San Jose, CA, 95134 USA 222 naiming@redback.com 224 Acee Lindem 225 Redback Networks 226 102 Carric Bend Court 227 Apex, NC 27502 USA 228 acee@redback.com 230 Jenny Yuan 231 Redback Networks 232 350 Holger Way 233 San Jose, CA, 95134 USA 234 jenny@redback.com