Speaking as WG member: I was going to wait to comment on this due to more important tasks but it appears the discussion is under way. This requirement surfaced about 25-30 years back. In fact, there was one SP (who will remain anonymous) that actually had a OSPF monitoring function that kept OSPF neighbors in Exchange state indefinitely just to learn the topology w/o participating in it. This wrecked with implementations trying to recover sessions that weren’t making progress in transition to Full state.
For OSPFv3, we already have and have always had the Router-LSA R-bit to prevent a router from being used to in the topology. In OSPFv2, we have RFC 8770 which prevents an OSPFv2 router from being used for transit traffic. Now you can argue the stub links are still being. However, for these you could either use an unnumbered link or simply omit the stub-links from your router LSA. Or use RFC 6860 to hide them. Now one could argue that you still have these links in your topology. However, they are essentially “bridges to nowhere”. If you really don’t want them, then just don’t advertise them in the monitoring node’s Router-LSA. After 30 years of this requirement already being satisfied, I see no reason to introduce new machinery into the protocols. To me, this seems like a draft that the OSPF protocol(s) and LSR WG could do better without. Thanks, Acee From: Lsr <lsr-boun...@ietf.org> on behalf of Robert Raszuk <rob...@raszuk.net> Date: Monday, March 7, 2022 at 9:59 AM To: Alvaro Retana <alvaro.ret...@futurewei.com> Cc: Lin Han <lin....@futurewei.com>, "lsr@ietf.org" <lsr@ietf.org> Subject: Re: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node) Hi Alvaro, Practically speaking, yes Monitor nodes are cool to have. But so are the Controller nodes. The difference would be that in both cases there is no topology information being injected by such nodes, however in the latter case the additional information could be injected. Such information could be related to providing extra data to computation of topologies by other "Full IGP nodes" or could also be injecting or relaying discovery information related to IGP or BGP (for example RRs). Have you considered widening the scope a bit to accomplish this extra delta ? Thx Robert On Mon, Mar 7, 2022 at 1:17 PM Alvaro Retana <alvaro.ret...@futurewei.com<mailto:alvaro.ret...@futurewei.com>> wrote: Hi! Lin and I just published a draft that specifies mechanisms for an active OSPF monitor: one that can be authenticated into the network but does not affect the topology. This mechanism contrasts to a passive monitor: listen-only node on a multiaccess link. The primary prompt for this work is that we have some applications where the monitor node will be on the other end of a p2p interface. Therefore, we have described a mechanism for that case (Section 3: Monitoring Interface), and one for the general case where the monitor node can be present on any interface (Section 4: The Monitor Node Option). Please take a look and send comments. https://datatracker.ietf.org/doc/html/draft-retana-lsr-ospf-monitor-node Thanks! Alvaro. _______________________________________________ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
