Subject: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)

From: Alvaro Retana <[email-masked]>
Date: Mon, 7 Mar 2022 12:17:18 +0000

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.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 7 Mar 2022 15:57:49 +0100

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 <[email-masked]>
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).
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 7 Mar 2022 15:56:48 +0000

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 <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Monday, March 7, 2022 at 9:59 AM
To: Alvaro Retana <[email-masked]>
Cc: Lin Han <[email-masked]>, "[email-masked]" <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi!

Thanks!

Alvaro.
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 8 Mar 2022 10:41:33 +0800

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.

Should we unified such requirements in such way then?

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Monday, March 7, 2022 11:57 PM
To: Robert Raszuk <[email-masked]>; Alvaro Retana <[email-masked]>
Cc: Lin Han <[email-masked]>; [email-masked]
Subject: Re: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)

Speaking as WG member:

Thanks,
Acee

From: Lsr <[email-masked] <mailto:[email-masked]> > on behalf of Robert Raszuk <[email-masked] <mailto:[email-masked]> >
Date: Monday, March 7, 2022 at 9:59 AM
To: Alvaro Retana <[email-masked] <mailto:[email-masked]> >
Cc: Lin Han <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)

Hi Alvaro,

Thx

Robert

On Mon, Mar 7, 2022 at 1:17 PM Alvaro Retana <[email-masked] <mailto:[email-masked]> > wrote:

Hi!

Thanks!

Alvaro. 
_______________________________________________
Lsr mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 8 Mar 2022 03:02:40 +0000

Hi Aijun,

From: Aijun Wang <[email-masked]>
Date: Monday, March 7, 2022 at 9:41 PM
To: Acee Lindem <[email-masked]>, Robert Raszuk <[email-masked]>, 'Alvaro Retana' <[email-masked]>
Cc: 'Lin Han' <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)

Hi, Acee:

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

Best Regards

Aijun Wang
China Telecom

Speaking as WG member:

Thanks,
Acee

From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 7, 2022 at 9:59 AM
To: Alvaro Retana <[email-masked]<mailto:[email-masked]>>
Cc: Lin Han <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)

Hi Alvaro,

Thx
Robert

Hi!

Thanks!

Alvaro.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 8 Mar 2022 10:09:44 +0100

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.

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) <[email-masked]> wrote:

> Hi Aijun,
>
>
>
>
>
>
>
> *From: *Aijun Wang <[email-masked]>
> *Date: *Monday, March 7, 2022 at 9:41 PM
> *To: *Acee Lindem <[email-masked]>, Robert Raszuk <[email-masked]>,
> 'Alvaro Retana' <[email-masked]>
> *Cc: *'Lin Han' <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *RE: [Lsr] OSPF Monitor Node
> (draft-retana-lsr-ospf-monitor-node)
>
>
>
> Hi, Acee:
>
>
>
> 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
>
>
>
>
>
> *From:* [email-masked] <[email-masked]> *On Behalf Of *Acee
> Lindem (acee)
> *Sent:* Monday, March 7, 2022 11:57 PM
> *To:* Robert Raszuk <[email-masked]>; Alvaro Retana <
> [email-masked]>
> *Cc:* Lin Han <[email-masked]>; [email-masked]
> *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 <[email-masked]> on behalf of Robert Raszuk <
> [email-masked]>
> *Date: *Monday, March 7, 2022 at 9:59 AM
> *To: *Alvaro Retana <[email-masked]>
> *Cc: *Lin Han <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [Lsr] OSPF Monitor Node
> (draft-retana-lsr-ospf-monitor-node)
>
>
>
> Hi Alvaro,
>
>
>
> 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).
>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 8 Mar 2022 11:36:04 +0000

Hi Robert,

From: Robert Raszuk <[email-masked]>
Date: Tuesday, March 8, 2022 at 4:09 AM
To: Acee Lindem <[email-masked]>
Cc: Aijun Wang <[email-masked]>, Alvaro Retana <[email-masked]>, Lin Han <[email-masked]>, "[email-masked]" <[email-masked]>
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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Aijun,

From: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 7, 2022 at 9:41 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>, 'Alvaro Retana' <[email-masked]<mailto:[email-masked]>>
Cc: 'Lin Han' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)

Hi, Acee:

Thanks,
Acee

Best Regards

Aijun Wang
China Telecom

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of Acee Lindem (acee)
Sent: Monday, March 7, 2022 11:57 PM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Alvaro Retana <[email-masked]<mailto:[email-masked]>>
Cc: Lin Han <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)

Speaking as WG member:

Thanks,
Acee

Hi Alvaro,

Thx
Robert

Hi!

Thanks!

Alvaro.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 8 Mar 2022 12:59:38 +0100

Can you please list those standards ?

Thank you,
R.

On Tue, Mar 8, 2022 at 12:36 PM Acee Lindem (acee) <[email-masked]> wrote:

> Hi Robert,
>
>
>
> *From: *Robert Raszuk <[email-masked]>
> *Date: *Tuesday, March 8, 2022 at 4:09 AM
> *To: *Acee Lindem <[email-masked]>
> *Cc: *Aijun Wang <[email-masked]>, Alvaro Retana <
> [email-masked]>, Lin Han <[email-masked]>, "
> [email-masked]" <[email-masked]>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 8 Mar 2022 14:11:07 +0000

Hi Robert,

Date: Tuesday, March 8, 2022 at 7:00 AM

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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 8, 2022 at 4:09 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Aijun Wang <[email-masked]<mailto:[email-masked]>>, Alvaro Retana <[email-masked]<mailto:[email-masked]>>, Lin Han <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)

Hi Acee,

Thanks,
Acee

Thx,
R.

Hi, Acee:

Thanks,
Acee

Best Regards

Aijun Wang
China Telecom

Speaking as WG member:

Thanks,
Acee

Hi Alvaro,

Thx
Robert

Hi!

Thanks!

Alvaro.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 8 Mar 2022 20:29:19 +0100

Hi Acee,

Thank you for forwarding this. Yes I personally missed RFC8770 and
discussions on the list about it. It went smooth and quiet during fall 2019
so it was hard to notice :-)

That was exactly what I was looking for. Is there implementation report
documented anywhere ? I checked LSR WG wiki page but not much content there
...

Best,
Robert.

On Tue, Mar 8, 2022 at 3:11 PM Acee Lindem (acee) <[email-masked]> wrote:

> *Date: *Tuesday, March 8, 2022 at 7:00 AM
> 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.
>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 8 Mar 2022 20:19:05 +0000

HI Robert,

I doubt there is an RFC 8770 implementation right now since the use case was a BGP RR and that wasn’t implemented. However, it is still light years ahead of a new proposal.

Thanks,
Acee

Date: Tuesday, March 8, 2022 at 2:29 PM

Hi Acee,

Thank you for forwarding this. Yes I personally missed RFC8770 and discussions on the list about it. It went smooth and quiet during fall 2019 so it was hard to notice :-)

That was exactly what I was looking for. Is there implementation report documented anywhere ? I checked LSR WG wiki page but not much content there ...

Best,
Robert.

On Tue, Mar 8, 2022 at 3:11 PM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Thanks,
Acee

Thank you,
R.

Hi Acee,

Thanks,
Acee

Thx,
R.

Hi, Acee:

Thanks,
Acee

Best Regards

Aijun Wang
China Telecom

Speaking as WG member:

Thanks,
Acee

Hi Alvaro,

Thx
Robert

Hi!

Thanks!

Alvaro.

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 9 Mar 2022 19:10:03 -0500

Dear Authors

There are routing analytics products such as the post popular Packet Design
now part of  Blue Planet part of Cienna, Cisco WAE former Mate and Juniper
Paragon that provide very rich robust routing analytics supports all
routing area protocols and uses BGP-LS to build the network Graph and as
well Paragon has a built in stateful PCE/SDN controller.  Cisco uses ODL
collaboration for stateful PCE.

Hard to match what the vendors already have with very rich robust solutions
for routing analytics which does much more than just monitoring.

Of course these products are expensive and so cater to larger operators,
however I can definitely see a niche for the ospf monitor for small and
medium scale networks.

Packet Design:
https://www.blueplanet.com/blog/Ciena-Completes-Acquisition-of-Packet-Design.html

Cisco WAE - former Cisco Mate:

https://www.cisco.com/c/en/us/products/routers/wan-automation-engine/index.html

Juniper Paragon - former North Star:

https://www.juniper.net/us/en/products/network-automation/paragon-pathfinder.html

Kind Regards

Gyan

On Tue, Mar 8, 2022 at 3:19 PM Acee Lindem (acee) <acee=
[email-masked]> wrote:

> HI Robert,
>
>
>
> I doubt there is an RFC 8770 implementation right now since the use case
> was a BGP RR and that wasn’t implemented. However, it is still light years
> ahead of a new proposal.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *Date: *Tuesday, March 8, 2022 at 2:29 PM
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 11 Mar 2022 14:51:47 +0800

I  think the scenario described in RFC8770 is different from that described the Monitor Node.

In RFC8770, in order to make the Host-bit takes effect, all the routers within the area must support this functionality, as described in https://datatracker.ietf.org/doc/html/rfc8770#section-5.

But for Monitor Node, it just wants to know the LSA of other routers, no need for other routers know it.

Configure the Stub Link that connected to the Monitor Node as “Active Only(Only send out the LSA on such interface, but does not receive any)” can easily solve such requirements, no backward compatibility issues.

This is another application scenario for Stub-Link Attributes.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Wednesday, March 9, 2022 4:19 AM
To: Robert Raszuk <[email-masked]>
Cc: Alvaro Retana <[email-masked]>; Lin Han <[email-masked]>; Aijun Wang <[email-masked]>; [email-masked]
Subject: Re: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)

HI Robert, 

Thanks,

Acee 

From: Robert Raszuk <[email-masked] <mailto:[email-masked]> >
Date: Tuesday, March 8, 2022 at 2:29 PM
To: Acee Lindem <[email-masked] <mailto:[email-masked]> >
Cc: Aijun Wang <[email-masked] <mailto:[email-masked]> >, Alvaro Retana <[email-masked] <mailto:[email-masked]> >, Lin Han <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)

Hi Acee,

Best,

Robert.

On Tue, Mar 8, 2022 at 3:11 PM Acee Lindem (acee) <[email-masked] <mailto:[email-masked]> > wrote:

Hi Robert, 

From: Robert Raszuk <[email-masked] <mailto:[email-masked]> >
Date: Tuesday, March 8, 2022 at 7:00 AM
To: Acee Lindem <[email-masked] <mailto:[email-masked]> >
Cc: Aijun Wang <[email-masked] <mailto:[email-masked]> >, Alvaro Retana <[email-masked] <mailto:[email-masked]> >, Lin Han <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)

OSPFv2 – RFC 8770 

Thanks,

Acee 

Thank you,

R.

On Tue, Mar 8, 2022 at 12:36 PM Acee Lindem (acee) <[email-masked] <mailto:[email-masked]> > wrote:

Hi Robert, 

From: Robert Raszuk <[email-masked] <mailto:[email-masked]> >
Date: Tuesday, March 8, 2022 at 4:09 AM
To: Acee Lindem <[email-masked] <mailto:[email-masked]> >
Cc: Aijun Wang <[email-masked] <mailto:[email-masked]> >, Alvaro Retana <[email-masked] <mailto:[email-masked]> >, Lin Han <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)

Hi Acee,

Thanks,
Acee

Thx,
R.

 

On Tue, Mar 8, 2022 at 4:02 AM Acee Lindem (acee) <[email-masked] <mailto:[email-masked]> > wrote:

Hi Aijun, 

From: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Date: Monday, March 7, 2022 at 9:41 PM
To: Acee Lindem <[email-masked] <mailto:[email-masked]> >, Robert Raszuk <[email-masked] <mailto:[email-masked]> >, 'Alvaro Retana' <[email-masked] <mailto:[email-masked]> >
Cc: 'Lin Han' <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)

Hi, Acee:

For example:

Thanks,
Acee

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > On Behalf Of Acee Lindem (acee)
Sent: Monday, March 7, 2022 11:57 PM
To: Robert Raszuk <[email-masked] <mailto:[email-masked]> >; Alvaro Retana <[email-masked] <mailto:[email-masked]> >
Cc: Lin Han <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)

Speaking as WG member:

Thanks,
Acee

Hi Alvaro,

Thx

Robert

Hi!

Thanks!

Alvaro.