Can you please list those standards ? Thank you, R.
On Tue, Mar 8, 2022 at 12:36 PM Acee Lindem (acee) <a...@cisco.com> wrote: > Hi Robert, > > > > *From: *Robert Raszuk <rob...@raszuk.net> > *Date: *Tuesday, March 8, 2022 at 4:09 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) > > > > 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> wrote: > > Hi Aijun, > > > > > > > > *From: *Aijun Wang <wangai...@tsinghua.org.cn> > *Date: *Monday, March 7, 2022 at 9:41 PM > *To: *Acee Lindem <a...@cisco.com>, Robert Raszuk <rob...@raszuk.net>, > '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, 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 <lsr-boun...@ietf.org> *On Behalf Of *Acee > Lindem (acee) > *Sent:* Monday, March 7, 2022 11:57 PM > *To:* Robert Raszuk <rob...@raszuk.net>; Alvaro Retana < > alvaro.ret...@futurewei.com> > *Cc:* Lin Han <lin....@futurewei.com>; 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> 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> > 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 > https://www.ietf.org/mailman/listinfo/lsr > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
