Jump to content

Talk:Open Shortest Path First/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

A good introduction article

I think this guy has done a good job on introducing the topic. Its a little Cisco oriented, but unlike the corporate literature, his writting style is human, or what Art Kleiner call "native" in his book The Age of Heretics.

One thing that I found confusing though, what is the explicit message behind this paragraph? Does he imply that OSPF can not scale? I am betting its communication problem as the guy seems to know his stuff really well

"The U.S. Post Office is putting in 38,000 Cisco routers. Note that if we use our rules of thumb, 38,000 divided by 100 routers says we'd need 380 areas. Alternatives include multiple OSPF AS's, and other protocols (like EIGRP). I'd very definitely want healthy route summarization in such a network. Note that since OSPF only allows us to summarize at ABR's, we can only have one level of summarization. With 38,000 routers, we might well want to summarize at the regional, state, and portion of state levels. That can't be done with pure OSPF." [1]

I know Pete Welcher, the author of that link, and have discussed the project with him. Let me put in my own opinion. First, OSPF probably could not scale to 38,000 routers and probably at least times that in subnets. Within a single OSPF process, you only have one level of summarization. Do you create one area for each of the three-digit regional prefixes of ZIP codes? What is an administrative hierarchy that makes sense?
For this sort of network, I'd establish a number of OSPF domains (i.e., an area 0.0.0.0 and some number of nonzero areas), and interconnect them with a backbone-of-backbones running BGP. That is about as scalable a technique as we know. Yes, OSPF is faster converging with a reasonable number of routers and subnets, but making the whole service one relatively flat domain makes you extremely vulnerable to anything going into oscillation.Hcberkowitz 21:07, 14 June 2007 (UTC)

I reverted my unvandalisation, removing the IPstack template, because it's the template which has been vandalised. I don't know how to remove the link to 'ANUS' from it.

MD5 to authenticate ?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


I dont know much about OSPF or Networking, but what I know is MD5 is used for verifying Integrity and not for authentication. May be the line " OSPF Protocol can operate (communicate with other routers about "best-path" routes to save in their LSDBs) securely, using MD5 to authenticate peers before forming adjacencies" shall be considered for correction.

--Empit 21:54, 13 April 2007 (UTC)

OSPF routers can transmit MD5-hashed password in Hello packets to authenticate adjacent routers. MD5 hashing is a basic protection against sniffing the password.
OSPF also supports plaintext passwords. I've had situations where we were not especially concerned with sniffing as a danger, but were in the process of combining OSPF networks of two merged companies. As we converted, we used one password for each of the old networks and another password for the merged network. This kept us from accidentally picking up routers that weren't converted to the new conventions. With our particular router vendor, there were easy-to-code but also easy-to-pick-up-garbage configuration options that could easily bring in things we didn't want in the merged system. If the passwords didn't match, that ended the possibility of a mixed environment.Hcberkowitz 21:11, 14 June 2007 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Full Disclosure and All That

In the section I added on OSPF Applications, I did cite one of my peer-reviewed NANOG presentations, along with one by my esteemed colleague, Dave Katz. One of the reasons that most IS-IS implementations tend to work together is that Dave wrote most of them. There are assorted authors of OSPF implementations. Howard C. Berkowitz 23:28, 19 September 2007 (UTC)

Request for further information

I've just tidied up the article, trying to remove duplication and some citations that don't seem to work (not sure if this was a previous way of doing references?)

Anyway, the thing I don't get from reading the article is how OSPF actually works. It would be really helpful if someone who understands this (and I don't) could write a section on how routes are actually exchanged between routers, and how the optimum routes are actually calculated. Thanks in advance.--Phil Holmes 09:43, 3 October 2007 (UTC)

Once I get some books out of storage, or maybe without (I've been moving), I can get down to that level in OSPF. Some feedback about how detailed an explanation is appropriate here would be useful, as this easily gets to be book-length if all is covered.
Let make some brief comments, just to give a flavor. Some of these are already covered, to some extent, my question is how much more detail is appropriate. It's purely my opinion, but I tend to think packet functios, but not formats, are appropriate for an encyclopedia. OSPF has a standard header on packets it sends out, which should be understood do not use any transport protocol.
When reliable delivery is important, OSPF does its own retransmission. Are the mechanics of that retransmission relevant, especially because it has fault-tolerance mechanisms to allow the Backup Designated Router to take over if the DR goes down?
Standard header discussion?
I should note that things are reasonably straightforward on broadcast (e.g., LAN) and point-to-point media. Things get significantly more complicated on nonbroadcast multiaccess (NBMA, such as Frame Relay) or demand (e.g., dialup).

There are a reasonably small number of packet types; the real complexity is in the Link State Announcements (LSA) that most of them carry:

  1. Hello
  2. Database Description packet
  3. The Link State Request packet
  4. Link State Update packet
  5. The Link State Acknowledgment packet
All but the Hello packet carry one or more LSAs, either in summary or full form. There is what I'd call a basic set of LSAs, and then a newer group, typically used for optional capabilities such as traffic engineering, that need considerably more explanation. Here's the basic set, ignoring two obsolete types:
  1. Router
  2. Network
  3. Summary (two subtypes)
  4. External (two major subtypes, and subcategories of those)
My question to you and all other people concerned: is this level of list, with narrative explanations, adequate for an encyclopedia? Obviously, I haven't gotten into things like how the initialization of new routers' databases takes place, how routes are added and deleted within an area, what packets go in or out of areas, how the basic intra-area computation works (with several versions, some vendor-dependent), how inter-area and externals work if the area type permits them. That's a start. Howard C. Berkowitz 11:09, 3 October 2007 (UTC)
For me, I think I could summarise what I see as important by asking "how does the forwarding/routing table get populated?". So I think the details of packet headers, transmission mechanisms, transmission reliability, etc., are not needed for an encyclopedia article. But how the routers learn routes from each other - that seems to me to be the fundamental function of OSPF, and therefore the fundamental "how to" need.
I hope that's helpful. --Phil Holmes 14:58, 3 October 2007 (UTC)

Initial Comments

TYPE 5 does equal AS External, HELLO???????? —Preceding unsigned comment added by 206.126.163.20 (talk) 16:32, 23 January 2008 (UTC)

type 5, eh??

Summary Net Link States (Area 1)

Link ID   ADV Router   Age     Seq#               Checksum 
0.0.0.0    2.2.2.2     20      0x80000001         0x75C0 
6.0.0.0    2.2.2.2     13      0x80000001         0x2709

—Preceding unsigned comment added by 206.126.163.20 (talk) 16:29, 23 January 2008 (UTC)

The remark concerning Type 5 advertisements and Stub Areas is in fact correct. Type 5 carries AS-external routing information, and a Stub Area only has one connection towards the backbone, thereby eliminating the need for a detailled routing information. Stub Areas are usually only fed a default route and maybe the AS-internal routes (Type 1-4), but they don't need to know about the AS-external routes. Sigkill 02:06, 1 July 2006 (UTC)

"Intra-area routing goes via the backbone"

Is this really correct? It would seem more logical if inter-area routing was done via the backbone. --K. Sperling 10:33, July 20, 2005 (UTC)

True, and is corrected meanwhile. Sigkill 02:06, 1 July 2006 (UTC)

"In contrast to RIP or BGP, OSPF does not use TCP or UDP but uses IP directly, using IP protocol 89."

This sounds incorrect Routers are layer 3 devices so how can they use Transport Layer, Layer 4, services?

While some routing protocols use L4 transports (such as tcp/179 for BGP or udp/520 for RIP), others bring their own L4 protocol (such as (E)IGRP with L4-protcol number 88 or OSPF with L4-protocol number 89). You should distinguish between the actual routing task running on Layer 3, and the inter-router communication, which uses higher-level protocols. Sigkill 02:06, 1 July 2006 (UTC)
I'd hesitate to call the protocol number layer 4. By protocol number, I refer to a field in the IP packet header, which identifies what the packet carries if not pure IP. It can be TCP or UDP, but also ICMP or OSPF or EIGRP. OSPF has its own reliable delivery mechanism with retransmissions and other features built into the protocol, but with lower overhead than TCP. Be careful before trying to force routing protocols into OSI layers, because (1) IP routing protocols were designed without OSI compliance as a goal, and (2) additional ISO documents, such as "OSI Routeing [sic] Framework", identify routing protocols as layer management protocols of the network layer. Layer management is defined in an annex to the basic OSI reference model. Hcberkowitz 21:15, 14 June 2007 (UTC)

Could a list of entry level Products which support OSPF be added, so others can learn by 'doing'?

Added meanwhile. Sigkill 02:06, 1 July 2006 (UTC)


implementation -- why no mention of hardware/appliance vendors?

I appreciate that Wikipedia is open-source-centric and all, but really, in a discussion of the implementations of OSPF there should be something said about Cisco, HP, Nortel/Bay, Extreme, Juniper and the plethora of other mainstream hardware vendors whose devices implement OSPF. Of particular interest would be a chart that compares the support for OSPF v2 versus OSPF v3, vendor extensions and limitations and other information that might be of use to someone doing a vendor comparison, especially to help someone from not falling into the trap of buying a vendor-proprietary extension. —Preceding unsigned comment added by 129.97.15.226 (talk) 19:00, 21 August 2009 (UTC)

Stub area definition

I recently removed an incorrect statement in the paragraph on stub areas (the statement that a stub area can contain only one router). This was then erroneously reverted, the reason given being: "A stub area only has one exit route, thus it has only one router".

Firstly, the statement that a stub area has only one exit route is incorrect. While real-world stub areas will commonly only have a single exit point, this is not a requirement.

Secondly, it's entirely possible (and not uncommon) to have a number of OSPF-speaking routers in a stub area. The stipulations of a stub area are that external routes should not be advertised into the area, and that all routers in a stub area are aware that the area is a stub area. A default route would commonly be advertised into the area by the ABR, but even this is not a requirement.

Rather than simply reverting the reversion, only to be once more incorrectly reverted, maybe a discussion is warranted to clear up this misunderstanding. —Preceding unsigned comment added by 213.94.198.249 (talk) 18:03, 11 September 2009 (UTC)

I think this is to some degree an issue of POV, as a stub area can have many levels of complexity internally. We shouldn't even be so specific in a general purpose article. However, the RFC seems specific that routing is based entirely on a default route which must be advertised into the area. The router awareness of the stub is a feature or enforcement of the protocol itself. I hope you can agree with my changes. Kbrose (talk) 17:10, 17 September 2009 (UTC)

Addition of OSPF Types and LSA Types

I've already added the OSPF Types (according to RFC 3540) and am interested in creating another section on LSA Types, but am lost as to how to proceed.

Should I break the LSAs into OSPFv2 and OSPFv3 or should I combine the two into a single section and make a note of which ones are supported only by OSPFv3?

Likewise, there are some IPv6 specific "Prefix Options" which are ONLY supported by IPv6 and again, I'm at a lost as to how/where to add mention of that. Perhaps a new section? But I don't want to muddy up the wiki page!

If anybody has any ideas on how I should go about breaking them up or combining them together, I'd like to hear those voices prior to me creating the material.

--wbenton (talk) 01:57, 2 March 2010 (UTC)

RFC history

I think that having a huge table of RFCs is not useful at all and the same goes for their graph, so I removed the section from the article. Because it may be useful, if someone wanted to rewrite that section in a better way, I copied the section's contents below. Svick (talk) 01:45, 25 June 2010 (UTC)

RFC history
The following image gives a visual view of how the older OSPF related RFCs have transpired into their current state today.

NumberTitle (Current as of: 2010/02/25)DateMore Info (Obs&Upd)Status
RFC 5709OSPFv2 HMAC-SHA Cryptographic Authentication2009/10/01Updates RFC 2328PROPOSED STANDARD
RFC 5643Management Information Base for OSPFv32009/08/01 PROPOSED STANDARD
RFC 5642Dynamic Hostname Exchange Mechanism for OSPF2009/08/01 PROPOSED STANDARD
RFC 5614Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding2009/08/01 EXPERIMENTAL
RFC 5613OSPF Link-Local Signaling2009/08/01Obsoletes RFC 4813PROPOSED STANDARD
RFC 5523OSPFv3-Based Layer 1 VPN Auto-Discovery2009/04/01 EXPERIMENTAL
RFC 5449OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks2009/02/01 EXPERIMENTAL
RFC 5392OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering2009/01/01 PROPOSED STANDARD
RFC 5340OSPF for IPv62008/07/01Obsoletes RFC 2740PROPOSED STANDARD
RFC 5329Traffic Engineering Extensions to OSPF Version 32008/09/01 PROPOSED STANDARD
RFC 5252OSPF-Based Layer 1 VPN Auto-Discovery2008/07/01 PROPOSED STANDARD
RFC 5250The OSPF Opaque LSA Option2008/07/01Obsoletes RFC 2370PROPOSED STANDARD
RFC 5243OSPF Database Exchange Summary List Optimization2008/05/01 INFORMATIONAL
RFC 5187OSPFv3 Graceful Restart2008/06/01 PROPOSED STANDARD
RFC 5185OSPF Multi-Area Adjacency2008/05/01 PROPOSED STANDARD
RFC 5088OSPF Protocol Extensions for Path Computation Element (PCE) Discovery2008/01/01 PROPOSED STANDARD
RFC 4973OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering2007/07/01 EXPERIMENTAL
RFC 4972Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership2007/07/01 PROPOSED STANDARD
RFC 4970Extensions to OSPF for Advertising Optional Router Capabilities2007/07/01 PROPOSED STANDARD
RFC 4940IANA Considerations for OSPF2007/07/01 BEST CURRENT PRACTICE
RFC 4915Multi-Topology (MT) Routing in OSPF2007/06/01 PROPOSED STANDARD
RFC 4813OSPF Link-Local Signaling2007/03/01Obsoleted by RFC 5613EXPERIMENTAL
RFC 4812OSPF Restart Signaling2007/03/01 INFORMATIONAL
RFC 4811OSPF Out-of-Band Link State Database (LSDB) Resynchronization2007/03/01 INFORMATIONAL
RFC 4750OSPF Version 2 Management Information Base2006/12/01Obsoletes RFC 1850PROPOSED STANDARD
RFC 4577OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)2006/06/01Updates RFC 4364PROPOSED STANDARD
RFC 4552Authentication/Confidentiality for OSPFv32006/06/01 PROPOSED STANDARD
RFC 4222Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance2005/10/01 BEST CURRENT PRACTICE
RFC 4203OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)2005/10/01Updates RFC 3630PROPOSED STANDARD
RFC 4167Graceful OSPF Restart Implementation Report2005/10/01 INFORMATIONAL
RFC 4136OSPF Refresh and Flooding Reduction in Stable Topologies2005/07/01 INFORMATIONAL
RFC 4063Considerations When Using Basic OSPF Convergence Benchmarks2005/04/01 INFORMATIONAL
RFC 4062OSPF Benchmarking Terminology and Concepts2005/04/01 INFORMATIONAL
RFC 4061Benchmarking Basic OSPF Single Router Control Plane Convergence2005/04/01 INFORMATIONAL
RFC 3883Detecting Inactive Neighbors over OSPF Demand Circuits (DC)2004/10/01Updates RFC 1793PROPOSED STANDARD
RFC 3630Traffic Engineering (TE) Extensions to OSPF Version 22003/09/01Updates RFC 2370, Updated by RFC 4203PROPOSED STANDARD
RFC 3623Graceful OSPF Restart2003/11/01 PROPOSED STANDARD
RFC 3509Alternative Implementations of OSPF Area Border Routers2003/04/01 INFORMATIONAL
RFC 3166Request to Move RFC 1403 to Historic Status2001/08/01 INFORMATIONAL
RFC 3137OSPF Stub Router Advertisement2001/06/01 INFORMATIONAL
RFC 3101The OSPF Not-So-Stubby Area (NSSA) Option2003/01/01Obsoletes RFC 1587PROPOSED STANDARD
RFC 2844OSPF over ATM and Proxy-PAR2000/05/01 EXPERIMENTAL
RFC 2740OSPF for IPv61999/12/01Obsoleted by RFC 5340PROPOSED STANDARD
RFC 2676QoS Routing Mechanisms and OSPF Extensions1999/08/01 EXPERIMENTAL
RFC 2370The OSPF Opaque LSA Option1998/07/01Obsoleted by RFC 5250, Updated by RFC 3630PROPOSED STANDARD
RFC 2329OSPF Standardization Report1998/04/01 INFORMATIONAL
RFC 2328OSPF Version 21998/04/01Obsoletes RFC 2178, Updated by RFC 5709STANDARD
RFC 2178OSPF Version 21997/07/01Obsoletes RFC 1583, Obsoleted by RFC 2328DRAFT STANDARD
RFC 2154OSPF with Digital Signatures1997/06/01 EXPERIMENTAL
RFC 1850OSPF Version 2 Management Information Base1995/11/01Obsoletes RFC 1253, Obsoleted by RFC 4750DRAFT STANDARD
RFC 1793Extending OSPF to Support Demand Circuits1995/04/01Updated by RFC 3883PROPOSED STANDARD
RFC 1765OSPF Database Overflow1995/03/01 EXPERIMENTAL
RFC 1745BGP4/IDRP for IP---OSPF Interaction1994/12/01 HISTORIC [pub as:PROPOSED STANDARD]
RFC 1587The OSPF NSSA Option1994/03/01Obsoleted by RFC 3101PROPOSED STANDARD
RFC 1586Guidelines for Running OSPF Over Frame Relay Networks1994/03/01 INFORMATIONAL
RFC 1585MOSPF: Analysis and Experience1994/03/01 INFORMATIONAL
RFC 1584Multicast Extensions to OSPF1994/03/01 HISTORIC [pub as:PROPOSED STANDARD]
RFC 1583OSPF Version 21994/03/01Obsoletes RFC 1247, Obsoleted by RFC 2178DRAFT STANDARD
RFC 1403BGP OSPF Interaction1993/01/01Obsoletes RFC 1364HISTORIC [pub as:PROPOSED STANDARD]
RFC 1370Applicability Statement for OSPF1992/10/01 HISTORIC [pub as:PROPOSED STANDARD]
RFC 1364BGP OSPF Interaction1992/09/01Obsoleted by RFC 1403PROPOSED STANDARD
RFC 1253OSPF Version 2 Management Information Base1991/08/01Obsoletes RFC 1252, Obsoleted by RFC 1850PROPOSED STANDARD
RFC 1252OSPF Version 2 Management Information Base1991/08/01Obsoletes RFC 1248, Obsoleted by RFC 1253PROPOSED STANDARD
RFC 1248OSPF Version 2 Management Information Base1991/07/01Obsoleted by RFC 1252, Updated by RFC 1349PROPOSED STANDARD
RFC 1247OSPF Version 21991/07/01Obsoletes RFC 1131, Obsoleted by RFC 1583, Updated by RFC 1349DRAFT STANDARD
RFC 1246Experience with the OSPF Protocol1991/07/01 INFORMATIONAL
RFC 1245OSPF Protocol Analysis1991/07/01 INFORMATIONAL
RFC 1131OSPF specification1989/10/01Obsoleted by RFC 1247PROPOSED STANDARD
Note: Grayed out RFCs have been obsoleted.

ROSPF (Radio-OSPF)

a variant of Open Shortest Path First (OSPF) that is called Radio-OSPF (ROSPF). ROSPF does not use the OSPF hello protocol for link discovery, etc. Instead, OSPF adjacencies are created and destroyed as a function of MANET information that is distributed by the NTDR routers, both cluster heads and cluster members.

Read about this patent @ http://bbn.com/resources/pdf/6,977,937.pdf —Preceding unsigned comment added by 75.9.141.234 (talk) 02:25, 15 April 2011 (UTC)

Configuration corner

What do people think about the recently added Open Shortest Path First#OSPF Configuration Corner? I have suggested here that it is not suitable and we would like other comments. Johnuniq (talk) 08:19, 13 May 2012 (UTC)

WP:NOTHOWTO certainly applies. No place for it here IMO. — Dgtsyb (talk) 13:21, 20 May 2012 (UTC)

The External Links section has become a morass of clutter with very few links that meet the requirements of WP:EL. I'm removing some of the most blatant commercial links now. Can we discuss links (especially new links) on the Talk page? — UncleBubba T @ C ) 03:56, 9 December 2011 (UTC)

Found an external link that is no longer working that is referenced under Stub Area... http://www.visualland.net/view.php?cid=760 I think that whole domain has gone away. Cpostier (talk) 15:38, 27 September 2012 (UTC)Christian

Stub area — edit to intro

I just wanted to explain edit 614012779 since it was reverted. This duplicates my comment on Johnuniq's Talk page.

The Not-so-stubby area was already introduced and is not a proprietary extension (it has an RFC). The two proprietary extensions discussed by the article are Totally stubby area and NSSA totally stubby area. I believe the sentence I edited intended to introduce these.

@Johnuniq: Indeed, NSSA is 'Not-so-stubby area', but both Stub area and NSSA have proprietary variants called Totally stubby area and NSSA totally stubby area. These are described in the sections just below. Trackpick (talk) 04:46, 23 June 2014 (UTC)

OK. It's a while since I thought about this article or the topic. Happy editing! Johnuniq (talk) 06:09, 23 June 2014 (UTC)

I want to point out that I believe this protocol is in the wrong OSI layer. The RFC, RFC #2328, specifies this runs over the network (IP) layer protocol.

From Section A.1 of the RFC:

A.1 Encapsulation of OSPF packets

 OSPF runs directly over the Internet Protocol's network layer.  OSPF
 packets are therefore encapsulated solely by IP and local data-link
 headers.

I'm thinking this might classify OSPF as layer 3. Please let me know what you think.

LostTemplar (talk) 21:48, 27 March 2009 (UTC)

I agree with you completely, LostTemplar. OSPF definately runs over IP. If you don't have IP running, you have no hope of getting OSPF running. So the link layer, and the IP layer must be up for OSPF to communicate between routers. Are you looking at how OSPF shows up in the link-layer section of the box in the upper right? —fudoreaper (talk) 07:47, 29 March 2009 (UTC)
First of all, you cannot use the terms Link Layer and Network Layer (aka Layer 3) in the same statement for comparison. They are from different models, and the comparison becomes completely meaningless when dealing with the subtleties of protocol semantics. RFC 2328 is not the latest OSPF specification and is only valid for IPv4 implementations. In regards to encapsulation: of course IPv4 OSPF (version 2) runs in IP datagrams, that is not the question or puzzle here and is not the criterion TCP/IP uses for categorization. OSPFv2 was indeed considered to run at the IP subnet level, and with its strong ties to IPv4 there was perhaps some justification to place it into the Internet Layer (but not just because of its encapsulation sequence) but does that justify it? TCP/IP does not layer in terms of encapsulation. An IP subnet usually runs on a single link as well, and since OSPF v2 only operates on the link between routers, collecting link states, and is never routed across networks despite using IP datagrams, it really is a Link Layer protocol in the sense of the TCP/IP model as well. In terms of the OSI model, it surely is a Layer 3 protocol, by encapsulation rule as well as the concept that routing protocols in general are often assigned to a network managment category within Layer 3 (no matter what the encapsulation -- funny how the encapsulation requirement may all of a sudden be broken). OSPF for IPv6 has removed all IP address information from all LSAs, except the update payload LSAs, and the protocol has become network-protocol independent. Furthermore, the protocol operates on a 'per-link' basis, not 'per-subnet' anymore, and uses link-local addressing for inter-router communications. The specification explicitely defines the Link Layer operation of OSPF v3. So, the question in the end is how to document a general 'OSPF' protocol in a general audience article. Clearly the newest OSPF developments put it into the Link Layer, but they do not obsolete the IPv4 documents. So, in fact we have two OSPF protocols. One might split the designation and put a link to OSPFv2 into the Internet Layer and OSPFv3 into the Link Layer, or just put the overall term into the Link Layer (since v2 is really a Link Layer protocol). In terms of OSI, go and figure, but don't mix up that discussion and the terms with TCP/IP. OSPF development has been conducted entirely in terms of TCP/IP terminology. Kbrose (talk) 15:45, 29 March 2009 (UTC)
Both OSPF and EIGRP use multicast packets encapsulated inside multicast layer 2 frames (let it be ethernet, frame-relay, ppp, hdlc). scope of these packets is just link local, this does not mean that ospf works at link layer or eigrp works at link layer. It just means the ttl is 1. the nature of ospf is link-state routing protocol should not mean its only operates at link layer. the highest layer used by ospf for control/management/data plane is internet layer, and not link layer. BGP uses path vector logic, that doesnt mean bgp doesnt fit in the application layer because its scope is between autonomous systems. however ISIS is link layer as clearly frames are involved in transporting in ISIS PDUs. A discussion on this can be found here...https://learningnetwork.cisco.com/thread/82389?tstart=0on Cisco learning network, specifically addressing the wikipedia mentioning ospf under link layer...[1]Pritishp333 (talk) 08:23, 12 March 2015 (UTC)

fudoreaper and Kbrose, thank you for your feedback. fudoreaper, yes, you are right; I was referring to the placement of OSPF in the upper-right box.

I see your point about the IPv4 and IPv6 versions of OSP, Kbrose. Yes, you are right about the differences in TCP/IP, and OSI. I'm thinking this might be more of an issue of Wikipedia considering the entire protocol stack as part of TCP/IP. Correct me if I'm wrong, but I think a year or so earlier, the protocols were listed under the OSI stack rather than the TCP/IP. IMO, this makes it more easy to follow. Some vendors prefer to follow the OSI layer when implementing a particular protocol. I shall have a look around and get some references.

LostTemplar (talk) 04:15, 31 March 2009 (UTC)

I don't really see any evidence that anyone is using OSI to design network protocols anymore. The few vendors that are actually designing new protocols, if they want to have any chance of wide-spread use, align themselves with an IETF work group usually and the IETF virtually never refers to OSI, and, for example, Microsoft as a proprietary developer usually, seems to use the TCP/IP model terminology as well, see for example, the description of LLTD, as a Link Layer protocol. OSPF was a TCP/IP centric protocol since start, and the v3 specs make this even clearer. The only significant use of OSI terms seems to be for descriptions by hardware designers in the hardware layers and data link layers, occasionally referring to L3 as well. But the new technologies developed today in the physical layer and L2 are often so complicated that they have their own detailed layering terminologies and even the OSI sublayers of L2 don't do them much good.
As far as the WP past is concerned, it seems to me that it was more or less a vast disorder of interpretations without much reliance on the original, primary sources of these things. I think some of this resulted from the use of secondary sources, often foreign language text books, that loosely translate technical terms (and get loosely translated back to English) and mix in their own interpretations. Much of this still persists. Kbrose (talk) 14:56, 31 March 2009 (UTC)
I have said it, I'll say it again OSPF is NOT a link layer Protocol. Need an explanation? read here what the Industry Experts (Specifically Cisco VIP Scott Morris-CCDE/4xCCIE/2xJNCIE) have to say https://learningnetwork.cisco.com/thread/82389?start=30&tstart=0 Pritishp333 (talk) 16:53, 19 May 2015 (UTC)

I find it really confusing to be saying that it is a link layer protocol. Yes, it cares about link state etc. and does not propagate further than the LAN. But you could say the same about games which implement multicast discovery for LAN support. They're however not link layer protocols in the sense that they don't provide link-layer services: they are obviously not physical link layers, but they are also *not* data link layers: they do not transfer data for higher protocols, they just happen to operate on the link layer for other layers to work better (IP for OSPF).

That's really confusing for any people trying to understand how networks protocols are basically organized, and have a look at wikipedia to get a clue. OSPF really belongs next to IP in that regard. Isn't that what matters in the end?

--SamuelThibault (talk) 14:46, 28 October 2016 (UTC)

References