Hi Robert,
From: Robert Raszuk <rob...@raszuk.net>
Date: Tuesday, March 8, 2022 at 7:00 AM
To: Acee Lindem <a...@cisco.com>
Cc: Aijun Wang <wangai...@tsinghua.org.cn>, Alvaro Retana
<alvaro.ret...@futurewei.com>, Lin Han <lin....@futurewei.com>, "lsr@ietf.org"
<lsr@ietf.org>
Subject: Re: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)
Can you please list those standards ?
OSPFv3 -- RFC 5340 (Router-LSA R-Bit)
OSPFv2 – RFC 8770
RFC 6870 – Hiding Transit-Only Networks (could be used for
monitoring link(s))
Another option is to simply not advertise a Router-LSA, this would not prevent
the adjacency from coming up and the bi-directional check in the OSPF SPF would
prevent the router from being added to the OSPF topology.
So, the only gaps we have here are in the understanding of the OSPF protocol
and reading of the previous Email thread (hopefully, neither of those will
require standardization).
Thanks,
Acee
Thank you,
R.
On Tue, Mar 8, 2022 at 12:36 PM Acee Lindem (acee)
<a...@cisco.com<mailto:a...@cisco.com>> wrote:
Hi Robert,
From: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Date: Tuesday, March 8, 2022 at 4:09 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>,
Alvaro Retana
<alvaro.ret...@futurewei.com<mailto:alvaro.ret...@futurewei.com>>, Lin Han
<lin....@futurewei.com<mailto:lin....@futurewei.com>>,
"lsr@ietf.org<mailto:lsr@ietf.org>" <lsr@ietf.org<mailto:lsr@ietf.org>>
Subject: Re: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)
Hi Acee,
Imagine that I would like to place bunch of IGP nodes as anchors just for the
purpose of network testing ... Never to include them in topology for transit.
There are already standards to do this in both OSPFv2 and OSPFv3. No gaps…
Thanks,
Acee
How would I advertise SR segment endpoint (say using SR-MPLS) from such nodes
to construct paths ? Sure we could play with max-metric, but as we discussed
recently those nodes marked as such are still part of full topology graph -
just being discouraged to be used.
That is why I asked for extension to be a controller. IMO there is gap between
passive node and active node which would be cool to fill.
Thx,
R.
On Tue, Mar 8, 2022 at 4:02 AM Acee Lindem (acee)
<a...@cisco.com<mailto:a...@cisco.com>> wrote:
Hi Aijun,
From: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>
Date: Monday, March 7, 2022 at 9:41 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, Robert Raszuk
<rob...@raszuk.net<mailto:rob...@raszuk.net>>, 'Alvaro Retana'
<alvaro.ret...@futurewei.com<mailto:alvaro.ret...@futurewei.com>>
Cc: 'Lin Han' <lin....@futurewei.com<mailto:lin....@futurewei.com>>,
"lsr@ietf.org<mailto:lsr@ietf.org>" <lsr@ietf.org<mailto:lsr@ietf.org>>
Subject: RE: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)
Hi, Acee:
The R-bit/H-bit is used to divert the transit traffic, but there still be
traffic to the advertising node itself.
It seems that the monitor node just want to the topology information from the
network, but not any other forwarding traffic?
In my POV, these special nodes are all connected by the “Stub Link”, we can
unify them under different “Stub Link” Type:
For example:
For R-bit(Clear)/H-bit(Set) Node, the “Stub Link” Type should be “Passive Only
Mode” , that is, the interface in such mode will only receive the LSAs from
other end, but does not advertise any LSA to other end.
For Monitor Node, the “Stub Link” should be “Active Only Mode”, that is the
interface in such mode will only send the LSAs to other end, but does not
receive any LSA from other end.
If you reread my recommendation you’ll note that to avoid local traffic, you
simply don’t advertise the stub links. Why would you advertise them with an
option not to use them? 😉 All the machinery for passive monitoring exists, no
need to invent anything.
Thanks,
Acee
Should we unified such requirements in such way then?
Best Regards
Aijun Wang
China Telecom
From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>
<lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem
(acee)
Sent: Monday, March 7, 2022 11:57 PM
To: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>; Alvaro Retana
<alvaro.ret...@futurewei.com<mailto:alvaro.ret...@futurewei.com>>
Cc: Lin Han <lin....@futurewei.com<mailto:lin....@futurewei.com>>;
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)
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<mailto:lsr-boun...@ietf.org>> on behalf of
Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Date: Monday, March 7, 2022 at 9:59 AM
To: Alvaro Retana
<alvaro.ret...@futurewei.com<mailto:alvaro.ret...@futurewei.com>>
Cc: Lin Han <lin....@futurewei.com<mailto:lin....@futurewei.com>>,
"lsr@ietf.org<mailto:lsr@ietf.org>" <lsr@ietf.org<mailto: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
