Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Tianran Zhou]

Hi Jeff,

Our work is not to propose a new protocol.
https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01
Our idea is to use BMP for IGP monitoring. We just choose BMP as the vehicle.

Best,
Tianran

From: Jeffrey Haas [mailto:jh...@pfrc.org]
Sent: Tuesday, July 12, 2022 12:10 AM
To: Tianran Zhou 
Cc: Robert Raszuk ; Yingzhen Qu ; 
idr ; grow ; lsr 
Subject: Re: [Idr] [GROW] [Lsr] IGP Monitoring Protocol

Tianran,

Please note that nothing prohibits BGP-LS from being distributed over BMP today 
aside from implementation support.  It's just another AFI/SAFI.

-- Jeff



On Jul 11, 2022, at 10:02 AM, Tianran Zhou 
mailto:zhoutianran=40huawei@dmarc.ietf.org>>
 wrote:

Hi Robert,

I see this name very similar to BMP bgp monitoring protocol.
Is this the similar function and scope as BMP?


Best,
Tianran


Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Yingzhen Qumailto:yingzhen.i...@gmail.com>>
抄送： 
idrmailto:i...@ietf.org>>;growmailto:grow@ietf.org>>;lsrmailto:l...@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 18:01:47

Hi Yingzhen,

Yes I understand that OSPF-GT is a new protocol leveraging some OSPF elements.

And please do not get me wrong ... way before OSPF Transport Instance I wrote 
BGP Transport Instance proposal and I do consider such additions to protocols 
as a very useful thing. In fact honestly recent discussions on UPA/PUA/PULSE 
could be very well served by OSPF-GT in a stateful fashion.

But I just do not see this fits well as a replacement of BGP-LS.

Yes, protocol designers like a swiss army knife approach (not to use nail and 
hammer analogy). However I think custom tools in the toolkit work much better 
for specific tasks :)

Cheers,
R.



On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:
Hi Robert,

Please think of OSPF-GT as a new protocol and it borrows ideas from OSPF. 
BGP-LS is one use case. In LSR WG, there have been proposals asking IGPs to 
carry non-routing information which will have impacts on protocol convergence, 
and OSPF-GT is meant to be the vehicle for such information.

BMP started before YANG, now with NETCONF/YANG or gNMI, you can retrieve the 
entire LSDB or part of it from a router, or subscribe to some data instances.

Thanks,
Yingzhen


On Jul 10, 2022, at 3:44 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Hi Acee,

My questions were based on section 3.4 of the latest version of the draft.

So I do not think I misinterpreted it.

Thank you,
R.



On Mon, Jul 11, 2022 at 12:38 AM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Robert,

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Robert Raszuk mailto:rob...@raszuk.net>>
Date: Sunday, July 10, 2022 at 1:32 PM
To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>, Susan 
Hares mailto:sha...@ndzh.com>>, IDR List 
mailto:i...@ietf.org>>, "grow@ietf.org 
grow@ietf.org" mailto:grow@ietf.org>>, lsr 
mailto:l...@ietf.org>>
Subject: Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

Hi Yingzhen & OSPF-GT authors,

UP front I must state that anything is better to export IGP information from 
routers to interested nodes than using BGP for it.

But to propose using OSPF to transport ISIS seems pretty brave :) I must admit 
it !

With that I have few questions to the proposal - assuming the use case is to 
distribute links state info in a point to point fashion:

A.What is the advantage - if any - to use a new OSPF instance/process to 
send link state data over a unicast session to a controller ?

It doesn’t have to be unicast, the remote neighbor construct just extends the 
possibilities in OSPF-GT. With an OSPF LSDB, the obvious advantage is all the 
protocol machinery is in place.  Note that LSDB streaming is just but one use 
case and of OSPF-GT. The detals of this application would be specified in a 
separate draft.


B. The draft is pretty silent on the nature of such a p2p session. Please 
be explicit if this is TCP, QUIC or what ?

It is OSPF, OSPF has its own protocol identifier (89). This draft just extends 
OSPF. I think you’ve misinterpreted the draft. Hence, your other questions 
aren’t really applicable or would be answered in a draft of the OSPF/IS-IS LSDB 
usage of OSPF-GT.

Thanks,
Acee



C) The draft is pretty silent on types of authentication for such sessions. 
Security considerations are pretty weak in that respect as well.

   The security considerations for OSPF-GT will be similar to those for
   OSPFv2 [RFC2328] and OSPFv3 [RFC5340].  However, since OSPF-GT is not
   used to update OSPF routing, the consequences of attacks will be
   dependent on advertised non-routing information.

I would actually argue that security considerations of p2p remote neighbors are 
actually quite different from security considerations of flooding data.

Along the 

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

Hi,


> Did you read the draft? The main difference is that since OSPF-GT is
>> generalized to be used for non-routing, there is no installation of routes.
>>
>

> Gyan> So The routes would be application use case specific “non
> routing” routes for example for BGP-LS it would be the related LSDB data
> that maybe similar data formatting as in RFC 7752 or new formatting
> described in separate draft.  The other possible use cases it’s “non
> routing” use cases, however in the BGP-LS case it is routing related info,
> not “non routing” related, so would this really be a good solution for
> BGP-LS?  I am thinking maybe not.
>

Guys,

It really does not matter if the northbound distribution of link state data
results in route installation or not. I understand why Acee is bringing
this point, but holistically looking at the entire domain it is irrelevant.

The data received is used for end to end path computation within a given
domain which is equally critical as local route installation.

So no matter what - Gyan you are correct here - it is better to be
accurate.

Thx,
R.
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Gyan Mishra]

Hi Acee

Responses in-line

On Mon, Jul 11, 2022 at 10:44 AM Acee Lindem (acee)  wrote:

> Hi Gyan,
>
>
>
> *From: *GROW  on behalf of Gyan Mishra <
> hayabusa...@gmail.com>
> *Date: *Monday, July 11, 2022 at 1:41 AM
> *To: *Yingzhen Qu 
> *Cc: *IDR List , "grow@ietf.org grow@ietf.org" <
> grow@ietf.org>, lsr 
> *Subject: *Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol
>
>
>
> Hi Yingzhen
>
>
>
> So with OSPFV2 using RFC 6549 would support multiple instances or OSPFV3
> already supports instances, how is the GT instance differentiated from any
> other routed instance?
>
>
>
> Did you read the draft? The main difference is that since OSPF-GT is
> generalized to be used for non-routing, there is installation of routes.
>
Gyan> So The routes would be application use case specific “non
routing” routes for example for BGP-LS it would be the related LSDB data
that maybe similar data formatting as in RFC 7752 or new formatting
described in separate draft.  The other possible use cases it’s “non
routing” use cases, however in the BGP-LS case it is routing related info,
not “non routing” related, so would this really be a good solution for
BGP-LS?  I am thinking maybe not.

> OSPF-GT neighbors need not be directly attached (or come with complex OSPF
> Virtual-Link considerations and processing). Depending on the application,
> the extent to which the “condition of reachability” is enforced MUST be
> described in the document describing the application usage of OSPF-GT.
>
>  Gyan> Understood.  So BGP-LS is a possible use case however those details
> would  be in another draft.
>
>
>
> For OSPFV2 it would use Opaque LSA Type 9,10,21 similar to RSVP-TE with an
> opaque option code for GTI.
>
>
>
> For OSPFV3 it would use an OSPFV3 function code for GTI.
>
>
>
> So the NBI BGP-LS peering to the PCE/SDN controller would be replaced with
> a   OSPF GTI neighbor ?
>
>
>
> It could be but that is just one OSPF-GT use case and would need to be
> described in a separate draft.
>

   Gyan> Understood

>
>
> Would you still need a standard routed OSPF neighbor for reachability or I
> guess you could put a static route on the controller across the NBI for
> reachability.
>
>
>
> Yes
>
Gyan> Got it

>
>
> Is that correct?
>
>
>
> Are there any operators implementations of this using OSPF GTI in place of
> BGP-LS?
>
>
>
> You mean OSPF-GT… Since the draft to describe the details of using OSPF-GT
> in place of BGP-LS is yet to be written, it would be very strange indeed if
> it were already deployed. 
>
> Gyan> Understood
>
> RFC 6823 provides the same GTI solution for ISIS.
>
>
>
> Yes and no, OSPF-GT is able to cover a much wider range of applications
> than RFC 683. This is due mostly to OSPF (and especially OSPFv3 with
> extended LSAs) being much more flexible than IS-IS.
>

Gyan> So could OSPF-GT provide the link state for ISIS instead of using
RFC 6823.

>
>
>
>
> Are there any operators implementations of this using OSPF GTI in place of
> BGP-LS?
>
>
>
> No - answered above.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Sun, Jul 10, 2022 at 1:04 AM Yingzhen Qu 
> wrote:
>
> Hi,
>
>
>
> Since we’re discussing possible solutions, I’d like to bring up the draft:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/
>
>
>
> We just submitted a new version. The name of the document is changed to
> “OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT
> as a possible replacement of BGP-LS.
>
>
>
> Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate
> routes. It uses the reachability info calculated by routing protocols,
> OSPF, ISIS or static routing etc.. It provides mechanisms to advertise
> non-routing information, and remote neighbor is supported.
>
>
>
> Reviews and comments are welcome.
>
>
>
>
>
> Thanks,
>
> Yingzhen
>
>
>
>
>
> On Jul 9, 2022, at 5:33 PM, Gyan Mishra  wrote:
>
>
>
>
>
> During the interim meeting we should keep it open to discuss all possible
> alternatives to BGP-LS.
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Sat, Jul 9, 2022 at 4:45 PM Susan Hares  wrote:
>
> Jeff:
>
>
>
> An interim sounds like a good plan.
>
>
>
> [IDR-chair hat]
>
> Alvaro has indicated that since all of the proposal received on the IDR
> list are new protocol proposals,
>
> · Capturing IDR’s input on BGP-LS problems and potenti

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

> but kindly don't assert that others can't do it when it's being done.

I did not assert that it can not be done as it is done today.

But not everything which is done today should be kept that way for an
endless future.

Many thx,
R.


On Mon, Jul 11, 2022 at 8:18 PM Jeffrey Haas  wrote:

> Robert,
>
>
> On Jul 11, 2022, at 12:16 PM, Robert Raszuk  wrote:
> On Mon, Jul 11, 2022 at 6:09 PM Jeffrey Haas  wrote:
>
>> Tianran,
>>
>> Please note that nothing prohibits BGP-LS from being distributed over BMP
>> today aside from implementation support.  It's just another AFI/SAFI.
>>
>> -- Jeff
>>
>
> Do you mean to build a dummy Adj_RIB_IN or OUT just to feed BMP with the
> BGP-LS formatted data at the IGP node exporting this data ?
>
>
> Do whatever you'd do in your implementation for BMP for the scenario that
> makes sense for you.
>
> If you want to know what an upstream BGP router sent you, look at your
> rib-in.
> If you want to know what local state you've got and are intending to
> disseminate to your downstreams, look at your loc-rib.
> If you want to know what state you've sent to your downstream, look at
> your rib-out.
>
> None of this is unusual.
>
> rib-in and rib-out are clear from a BGP protocol fundamentals perspective.
>
> loc-rib has a touch of ambiguity, along with exactly the same dose of
> ambiguity about "where does locally originated state manifest in
> implementations" that made for a lot of discussion in GROW "recently" as
> the loc-rib and rib-out specs were being finished for RFC purposes.
>
> In our implementation, where loc-rib tracks the "lsdist.0" table, I'd
> probably use that for the majority of use cases that I'd want to get a feed
> for BGP-LS from BMP.  Or, I could just do a BGP-LS peering session and get
> it that way, but the discussion is that BMP works fine.
>
>
> If this would avoid BGP to check the syntax of what is send it would work
> fine .. but it would not. And BGP has no business on doing that check and
> to understand zoo of foreign extensions completely not related to BGP
> itself.
>
>
> Feel free to speak for your own implementation, but kindly don't assert
> that others can't do it when it's being done.
>
> -- Jeff
>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Jeffrey Haas]

Robert,


> On Jul 11, 2022, at 12:16 PM, Robert Raszuk  wrote:
> On Mon, Jul 11, 2022 at 6:09 PM Jeffrey Haas  > wrote:
> Tianran,
> 
> Please note that nothing prohibits BGP-LS from being distributed over BMP 
> today aside from implementation support.  It's just another AFI/SAFI.
> 
> -- Jeff
> 
> Do you mean to build a dummy Adj_RIB_IN or OUT just to feed BMP with the 
> BGP-LS formatted data at the IGP node exporting this data ? 

Do whatever you'd do in your implementation for BMP for the scenario that makes 
sense for you.

If you want to know what an upstream BGP router sent you, look at your rib-in.
If you want to know what local state you've got and are intending to 
disseminate to your downstreams, look at your loc-rib.
If you want to know what state you've sent to your downstream, look at your 
rib-out.

None of this is unusual.

rib-in and rib-out are clear from a BGP protocol fundamentals perspective.

loc-rib has a touch of ambiguity, along with exactly the same dose of ambiguity 
about "where does locally originated state manifest in implementations" that 
made for a lot of discussion in GROW "recently" as the loc-rib and rib-out 
specs were being finished for RFC purposes.

In our implementation, where loc-rib tracks the "lsdist.0" table, I'd probably 
use that for the majority of use cases that I'd want to get a feed for BGP-LS 
from BMP.  Or, I could just do a BGP-LS peering session and get it that way, 
but the discussion is that BMP works fine.

> 
> If this would avoid BGP to check the syntax of what is send it would work 
> fine .. but it would not. And BGP has no business on doing that check and to 
> understand zoo of foreign extensions completely not related to BGP itself. 

Feel free to speak for your own implementation, but kindly don't assert that 
others can't do it when it's being done.

-- Jeff 

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

HI Jeff,

On Mon, Jul 11, 2022 at 6:09 PM Jeffrey Haas  wrote:

> Tianran,
>
> Please note that nothing prohibits BGP-LS from being distributed over BMP
> today aside from implementation support.  It's just another AFI/SAFI.
>
> -- Jeff
>

Do you mean to build a dummy Adj_RIB_IN or OUT just to feed BMP with the
BGP-LS formatted data at the IGP node exporting this data ?

If this would avoid BGP to check the syntax of what is send it would work
fine .. but it would not. And BGP has no business on doing that check and
to understand zoo of foreign extensions completely not related to BGP
itself.

Thx,
R.
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Jeffrey Haas]

Tianran,

Please note that nothing prohibits BGP-LS from being distributed over BMP today 
aside from implementation support.  It's just another AFI/SAFI.

-- Jeff


> On Jul 11, 2022, at 10:02 AM, Tianran Zhou 
>  wrote:
> 
> Hi Robert,
> 
> I see this name very similar to BMP bgp monitoring protocol.
> Is this the similar function and scope as BMP?
> 
> 
> Best,
> Tianran 
> 
> 
> Sent from WeLink
> 发件人： Robert Raszukmailto:rob...@raszuk.net>>
> 收件人： Yingzhen Qumailto:yingzhen.i...@gmail.com>>
> 抄送： idrmailto:i...@ietf.org>>;grow >;lsrmailto:l...@ietf.org>>
> 主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
> 时间： 2022-07-11 18:01:47
> 
> Hi Yingzhen, 
> 
> Yes I understand that OSPF-GT is a new protocol leveraging some OSPF 
> elements. 
> 
> And please do not get me wrong ... way before OSPF Transport Instance I wrote 
> BGP Transport Instance proposal and I do consider such additions to protocols 
> as a very useful thing. In fact honestly recent discussions on UPA/PUA/PULSE 
> could be very well served by OSPF-GT in a stateful fashion. 
> 
> But I just do not see this fits well as a replacement of BGP-LS. 
> 
> Yes, protocol designers like a swiss army knife approach (not to use nail and 
> hammer analogy). However I think custom tools in the toolkit work much better 
> for specific tasks :) 
> 
> Cheers,
> R.
> 
> 
> 
> On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu  > wrote:
> Hi Robert,
> 
> Please think of OSPF-GT as a new protocol and it borrows ideas from OSPF. 
> BGP-LS is one use case. In LSR WG, there have been proposals asking IGPs to 
> carry non-routing information which will have impacts on protocol 
> convergence, and OSPF-GT is meant to be the vehicle for such information.
> 
> BMP started before YANG, now with NETCONF/YANG or gNMI, you can retrieve the 
> entire LSDB or part of it from a router, or subscribe to some data instances. 
> 
> Thanks,
> Yingzhen
> 
>> On Jul 10, 2022, at 3:44 PM, Robert Raszuk > > wrote:
>> 
>> Hi Acee,
>> 
>> My questions were based on section 3.4 of the latest version of the draft. 
>> 
>> So I do not think I misinterpreted it. 
>> 
>> Thank you,
>> R.
>> 
>> 
>> 
>> On Mon, Jul 11, 2022 at 12:38 AM Acee Lindem (acee) > > wrote:
>> Hi Robert,
>> 
>>  
>> 
>> From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
>> Robert Raszuk mailto:rob...@raszuk.net>>
>> Date: Sunday, July 10, 2022 at 1:32 PM
>> To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
>> Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>, 
>> Susan Hares mailto:sha...@ndzh.com>>, IDR List 
>> mailto:i...@ietf.org>>, "grow@ietf.org 
>>  grow@ietf.org " > >, lsr mailto:l...@ietf.org>>
>> Subject: Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol
>> 
>>  
>> 
>> Hi Yingzhen & OSPF-GT authors,
>> 
>>  
>> 
>> UP front I must state that anything is better to export IGP information from 
>> routers to interested nodes than using BGP for it.
>> 
>>  
>> 
>> But to propose using OSPF to transport ISIS seems pretty brave :) I must 
>> admit it ! 
>> 
>>  
>> 
>> With that I have few questions to the proposal - assuming the use case is to 
>> distribute links state info in a point to point fashion: 
>> 
>>  
>> 
>> What is the advantage - if any - to use a new OSPF instance/process to send 
>> link state data over a unicast session to a controller ? 
>>  
>> 
>> It doesn’t have to be unicast, the remote neighbor construct just extends 
>> the possibilities in OSPF-GT. With an OSPF LSDB, the obvious advantage is 
>> all the protocol machinery is in place.  Note that LSDB streaming is just 
>> but one use case and of OSPF-GT. The detals of this application would be 
>> specified in a separate draft.
>> 
>>  
>> 
>>  
>> 
>> The draft is pretty silent on the nature of such a p2p session. Please be 
>> explicit if this is TCP, QUIC or what ? 
>>  
>> 
>> It is OSPF, OSPF has its own protocol identifier (89). This draft just 
>> extends OSPF. I think you’ve misinterpreted the draft. Hence, your other 
>> questions aren’t really applicable or would be answered in a draft of the 
>> OSPF/IS-IS LSDB usage of OSPF-GT.
>> 
>>  
>> 
>> Thanks,
>> Acee
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> C) The draft is pretty silent on types of authentication for such sessions. 
>> Security considerations are pretty weak in that respect as well. 
>> 
>>  
>> 
>>The security considerations for OSPF-GT will be similar to those for
>>OSPFv2 [RFC2328] and OSPFv3 [RFC5340].  However, since OSPF-GT is not
>>used to update OSPF routing, the consequences of attacks will be
>>dependent on advertised non-routing information.
>> 
>>  
>> 
>> I would actually argue that security considerations of p2p remote neighbors 
>> are actually quite different from security considerations of flooding data. 
>> 
>>  
>> 
>> Along the same lines security is not about protecting your 

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Jeffrey Haas]

Jeff,


> On Jul 10, 2022, at 5:14 PM, Jeff Tantsura  wrote:
> 
> Thanks Sue!
> 
> We don’t have to always reinvent the wheel (at least not every time )
> I’m aware of at least 1 implementation streaming LSDB for TE consumers (gRPC)
> There are most probably some other vendor specific encodings/methods to steam 
> to do that 

Minimally, the Openconfig group has models for the LSDB and some number of 
vendors either have implementation for providing access to that state via 
netconf, or gNMI.

Example model:
https://github.com/openconfig/public/blob/master/release/models/ospf/openconfig-ospfv2-lsdb.yang

I've largely reached the point where when someone uses the term "subscription" 
in terms of operational state, I'm going to think "you want this in YANG 
modeling via one of the access protocols for that".

For general operational state access, it's not bad... just very slow and eats 
your CPU doing too much printf.  (non-ascii versions of the model output become 
discussion points, but also change your ecosystem discussion).

Part of the discussion not fully had is what the consumers for this state are.  
If you're talking operational tools, getting pushed toward YANG models starts 
making more sense.  However, if you have routing driven purposes, either 
directly at consuming routers or at controllers, you want different answers.

Certainly, as you're aware, Jeff, vendors and operators are happily consuming 
BGP-LS state do to Clever Things.  For those cases, I'm not sure there's going 
to be a driver to get it out of BGP.

> I believe – there has been some work around Kafka.

It works quite nicely on collectors.  Serving your ecosystem by consuming the 
state from the network in efficient formats and then feeding tools from the 
collector in your toolchain of choice tends to be a nice model.

> 
> Would be great to  do some study around existing solutions, see what worked, 
> what didn’t’ (and why)  

Getting various parties to discuss this publicly is the larger challenge.

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

Tony,


> a) configuration is already standardized via NETCONF WG/channels/methods.
> pulling it via this seems redundant.
>

It is optional.


> b) YANG is already pulled via other channels so I see little value of
> pulling it here. same as a) basically
>

Please enumerate what channels ? And in the same time please indicate why
those channels are not good enough such that we need to keep stuffing BGP
protocol with the IGP, SR, Detnet etc .. data.



> c) adding all those "sync" via SNP is basically building a flooding peer
> again as far I can deduct having flown quickly over the draft. Doing that
> over QUIC/TCP is a bad idea due to head-on blocking problems well known
> with flooding. if the consumer cannot keep up with the real stream the
> sender can only start to throw away stuff or reset the session practically
> speaking
>

IMP is NOT doing flooding. If you think that control plane with 100s of CPU
cores will be slower in accepting your RE generated streams please kindly
reconsider.

But if the rate of data change would be a problem we would already choke
with TCP based BGP-LS. So not sure what problem are you seeing. Are you
referring to one interface flood mirroring ? For debugging it either be
nicely packed and sent or screen scraped. Which one do you prefer ?

d) beats me why you would want this to carry BGP-LS again if y6ou can
> simply run another session/BGP instance on any good implementation today.
>

beats me why would ever want to keep polluting BGP protocol like this. Are
you saying that IGP can not open a TCP socket or setup a QUIC session ? Is
it too much to ask ? Too complex ?


> Given all the big wishlist included in the draft protocol needs probably
> something to negotiate WHAT of all the whole panopticum the producer can
> support unless it's somehow in the PUB/SUB (but then again, this probably
> needs mode negotiation as well given the plethora of possibilities there).
>

Please kindly observe what is mandatory and what is optional. Also kindly
notice the split between Producer and Producer's Proxy.

Thx,
R.






>
> -- tony
>
> On Mon, Jul 11, 2022 at 4:54 PM Tianran Zhou  40huawei@dmarc.ietf.org> wrote:
>
>> Hi Robert,
>>
>>
>> This is very interesting to me. We had a protocol design for IGP monitoring:
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01
>>
>> It would be a good idea if we can find some common ground.
>>
>> Cheers,
>> Tianran
>>
>>
>>
>>
>> --
>>
>> Sent from WeLink
>> *发件人： *Robert Raszuk
>> *收件人： *Tianran Zhou
>> *抄送： *Yingzhen Qu;idr;grow<
>> grow@ietf.org>;lsr
>> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
>> *时间： *2022-07-11 22:05:31
>>
>> Hi Tianran,
>>
>> Yes it is,
>>
>> I dedicated entire paragraph in section 1 of the document to highlight
>> that point:
>>
>>The primary inspiration for this work has been based on the success
>>of BGP Monitoring Protocol (BMP) [RFC7854] which in a number of
>>aspects shares the same high level requirements - point to point
>>routing information distribution, protocol observability and enhanced
>>operations.  It also needs to be highlighted that BMP (while it
>>technically could) does not use native BGP sessions to propagate such
>>information, but is running a separate transport.  IMP authors have
>>chosen to reuse selected BMP building blocks and BMP operational and
>>deployment experience.
>>
>>
>>
>> Many thx,
>> R.
>>
>> On Mon, Jul 11, 2022 at 4:02 PM Tianran Zhou 
>> wrote:
>>
>>> Hi Robert,
>>>
>>> I see this name very similar to BMP bgp monitoring protocol.
>>> Is this the similar function and scope as BMP?
>>>
>>>
>>> Best,
>>> Tianran
>>>
>>> --
>>>
>>> Sent from WeLink
>>> *发件人： *Robert Raszuk
>>> *收件人： *Yingzhen Qu
>>> *抄送： *idr;grow;lsr
>>> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
>>> *时间： *2022-07-11 18:01:47
>>>
>>> Hi Yingzhen,
>>>
>>> Yes I understand that OSPF-GT is a new protocol leveraging some OSPF
>>> elements.
>>>
>>> And please do not get me wrong ... way before OSPF Transport Instance I
>>> wrote BGP Transport Instance proposal and I do consider such additions to
>>> protocols as a very useful thing. In fact honestly recent discussions on
>>> UPA/PUA/PULSE could be very well served by OSPF-GT in a stateful fashion.
>>>
>>> But I just do not see this fits well as a replacement of BGP-LS.
>>>
>>> Yes, protocol designers like a swiss army knife approach (not to use
>>> nail and hammer analogy). However I think custom tools in the toolkit work
>>> much better for specific tasks :)
>>>
>>> Cheers,
>>> R.
>>>
>>>
>>>
>>> On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu 
>>> wrote:
>>>
 Hi Robert,

 Please think of OSPF-GT as a new protocol and it borrows ideas from
 OSPF. BGP-LS is one use case. In LSR WG, there have been proposals asking
 IGPs to carry non-routing information which will have impacts on protocol
 

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Tony Przygienda]

which as proposal actually looks IMO more interesting than IMP thingy ...
_IF_ we want to do such a thing

As to IMP itself very terse

a) configuration is already standardized via NETCONF WG/channels/methods.
pulling it via this seems redundant.
b) YANG is already pulled via other channels so I see little value of
pulling it here. same as a) basically
c) adding all those "sync" via SNP is basically building a flooding peer
again as far I can deduct having flown quickly over the draft. Doing that
over QUIC/TCP is a bad idea due to head-on blocking problems well known
with flooding. if the consumer cannot keep up with the real stream the
sender can only start to throw away stuff or reset the session practically
speaking
d) beats me why you would want this to carry BGP-LS again if y6ou can
simply run another session/BGP instance on any good implementation today.

Given all the big wishlist included in the draft protocol needs probably
something to negotiate WHAT of all the whole panopticum the producer can
support unless it's somehow in the PUB/SUB (but then again, this probably
needs mode negotiation as well given the plethora of possibilities there).

-- tony

On Mon, Jul 11, 2022 at 4:54 PM Tianran Zhou  wrote:

> Hi Robert,
>
>
> This is very interesting to me. We had a protocol design for IGP monitoring:
>
>
> https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01
>
> It would be a good idea if we can find some common ground.
>
> Cheers,
> Tianran
>
>
>
>
> --
>
> Sent from WeLink
> *发件人： *Robert Raszuk
> *收件人： *Tianran Zhou
> *抄送： *Yingzhen Qu;idr;grow<
> grow@ietf.org>;lsr
> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
> *时间： *2022-07-11 22:05:31
>
> Hi Tianran,
>
> Yes it is,
>
> I dedicated entire paragraph in section 1 of the document to highlight
> that point:
>
>The primary inspiration for this work has been based on the success
>of BGP Monitoring Protocol (BMP) [RFC7854] which in a number of
>aspects shares the same high level requirements - point to point
>routing information distribution, protocol observability and enhanced
>operations.  It also needs to be highlighted that BMP (while it
>technically could) does not use native BGP sessions to propagate such
>information, but is running a separate transport.  IMP authors have
>chosen to reuse selected BMP building blocks and BMP operational and
>deployment experience.
>
>
>
> Many thx,
> R.
>
> On Mon, Jul 11, 2022 at 4:02 PM Tianran Zhou 
> wrote:
>
>> Hi Robert,
>>
>> I see this name very similar to BMP bgp monitoring protocol.
>> Is this the similar function and scope as BMP?
>>
>>
>> Best,
>> Tianran
>>
>> --
>>
>> Sent from WeLink
>> *发件人： *Robert Raszuk
>> *收件人： *Yingzhen Qu
>> *抄送： *idr;grow;lsr
>> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
>> *时间： *2022-07-11 18:01:47
>>
>> Hi Yingzhen,
>>
>> Yes I understand that OSPF-GT is a new protocol leveraging some OSPF
>> elements.
>>
>> And please do not get me wrong ... way before OSPF Transport Instance I
>> wrote BGP Transport Instance proposal and I do consider such additions to
>> protocols as a very useful thing. In fact honestly recent discussions on
>> UPA/PUA/PULSE could be very well served by OSPF-GT in a stateful fashion.
>>
>> But I just do not see this fits well as a replacement of BGP-LS.
>>
>> Yes, protocol designers like a swiss army knife approach (not to use nail
>> and hammer analogy). However I think custom tools in the toolkit work much
>> better for specific tasks :)
>>
>> Cheers,
>> R.
>>
>>
>>
>> On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu 
>> wrote:
>>
>>> Hi Robert,
>>>
>>> Please think of OSPF-GT as a new protocol and it borrows ideas from
>>> OSPF. BGP-LS is one use case. In LSR WG, there have been proposals asking
>>> IGPs to carry non-routing information which will have impacts on protocol
>>> convergence, and OSPF-GT is meant to be the vehicle for such information.
>>>
>>> BMP started before YANG, now with NETCONF/YANG or gNMI, you can retrieve
>>> the entire LSDB or part of it from a router, or subscribe to some data
>>> instances.
>>>
>>> Thanks,
>>> Yingzhen
>>>
>>> On Jul 10, 2022, at 3:44 PM, Robert Raszuk  wrote:
>>>
>>> Hi Acee,
>>>
>>> My questions were based on section 3.4 of the latest version of the
>>> draft.
>>>
>>> So I do not think I misinterpreted it.
>>>
>>> Thank you,
>>> R.
>>>
>>>
>>>
>>> On Mon, Jul 11, 2022 at 12:38 AM Acee Lindem (acee) 
>>> wrote:
>>>
 Hi Robert,



 *From: *Lsr  on behalf of Robert Raszuk <
 rob...@raszuk.net>
 *Date: *Sunday, July 10, 2022 at 1:32 PM
 *To: *Yingzhen Qu 
 *Cc: *Gyan Mishra , Susan Hares ,
 IDR List , "grow@ietf.org grow@ietf.org" ,
 lsr 
 *Subject: *Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol



 Hi Yingzhen & OSPF-GT authors,



 UP front I must state that anything is better to export IGP 

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Acee Lindem (acee)]

See one typo.

From: GROW  on behalf of "Acee Lindem (acee)" 

Date: Monday, July 11, 2022 at 10:45 AM
To: Gyan Mishra , Yingzhen Qu 
Cc: IDR List , "grow@ietf.org grow@ietf.org" , 
lsr 
Subject: Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

Hi Gyan,

From: GROW  on behalf of Gyan Mishra 

Date: Monday, July 11, 2022 at 1:41 AM
To: Yingzhen Qu 
Cc: IDR List , "grow@ietf.org grow@ietf.org" , 
lsr 
Subject: Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

Hi Yingzhen

So with OSPFV2 using RFC 6549 would support multiple instances or OSPFV3 
already supports instances, how is the GT instance differentiated from any 
other routed instance?

Did you read the draft? The main difference is that since OSPF-GT is 
generalized to be used for non-routing, there is installation of routes.

“No installation of routes”…


OSPF-GT neighbors need not be directly attached (or come with complex OSPF 
Virtual-Link considerations and processing). Depending on the application, the 
extent to which the “condition of reachability” is enforced MUST be described 
in the document describing the application usage of OSPF-GT.


For OSPFV2 it would use Opaque LSA Type 9,10,21 similar to RSVP-TE with an 
opaque option code for GTI.

For OSPFV3 it would use an OSPFV3 function code for GTI.

So the NBI BGP-LS peering to the PCE/SDN controller would be replaced with a   
OSPF GTI neighbor ?

It could be but that is just one OSPF-GT use case and would need to be 
described in a separate draft.

Would you still need a standard routed OSPF neighbor for reachability or I 
guess you could put a static route on the controller across the NBI for 
reachability.

Yes.

Is that correct?

Are there any operators implementations of this using OSPF GTI in place of 
BGP-LS?

You mean OSPF-GT… Since the draft to describe the details of using OSPF-GT in 
place of BGP-LS is yet to be written, it would be very strange indeed if it 
were already deployed. 

RFC 6823 provides the same GTI solution for ISIS.

Yes and no, OSPF-GT is able to cover a much wider range of applications than 
RFC 683. This is due mostly to OSPF (and especially OSPFv3 with extended LSAs) 
being much more flexible than IS-IS.


Are there any operators implementations of this using OSPF GTI in place of 
BGP-LS?

No - answered above.

Thanks,
Acee


Kind Regards

Gyan

On Sun, Jul 10, 2022 at 1:04 AM Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:
Hi,

Since we’re discussing possible solutions, I’d like to bring up the draft: 
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/

We just submitted a new version. The name of the document is changed to 
“OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT as a 
possible replacement of BGP-LS.

Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate routes. 
It uses the reachability info calculated by routing protocols, OSPF, ISIS or 
static routing etc.. It provides mechanisms to advertise non-routing 
information, and remote neighbor is supported.

Reviews and comments are welcome.


Thanks,
Yingzhen


On Jul 9, 2022, at 5:33 PM, Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:


During the interim meeting we should keep it open to discuss all possible 
alternatives to BGP-LS.

Thanks

Gyan

On Sat, Jul 9, 2022 at 4:45 PM Susan Hares 
mailto:sha...@ndzh.com>> wrote:
Jeff:

An interim sounds like a good plan.

[IDR-chair hat]
Alvaro has indicated that since all of the proposal received on the IDR list 
are new protocol proposals,
· Capturing IDR’s input on BGP-LS problems and potential solutions is 
appropriate for IDR as BGP-LS home.
· Refining any potential non-BGP solutions is outside of the scope of 
IDR.

[IDR-chair hat off]
[rtgwg WG member]
I’d love to attend an interim on this topic.

Sue Hares


From: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Sent: Saturday, July 9, 2022 3:40 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Acee Lindem (acee) mailto:a...@cisco.com>>; lsr 
mailto:l...@ietf.org>>; i...@ietf.org<mailto:i...@ietf.org>; 
Susan Hares mailto:sha...@ndzh.com>>; 
grow@ietf.org<mailto:grow@ietf.org> grow@ietf.org<mailto:grow@ietf.org> 
mailto:grow@ietf.org>>
Subject: Re: [Idr] [Lsr] IGP Monitoring Protocol



Speaking as RTGWG chair:

Robert - I don’t think we’d have enough time to accommodate a good discussion 
during IETF114 (we got only 1 slot), however would be happy to provide a 
platform for an interim.
The topic is important and personally (being a very large BGP-LS user) I’d like 
to see it progressing.
Cheers,
Jeff

On Jul 8, 2022, at 14:44, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Acee,

Yes, by all means input from the operator's community is needed. It can be 
collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute. We 
have already seen input from some operators and their opinion on a

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Acee Lindem (acee)]

Hi Gyan,

From: GROW  on behalf of Gyan Mishra 

Date: Monday, July 11, 2022 at 1:41 AM
To: Yingzhen Qu 
Cc: IDR List , "grow@ietf.org grow@ietf.org" , 
lsr 
Subject: Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

Hi Yingzhen

So with OSPFV2 using RFC 6549 would support multiple instances or OSPFV3 
already supports instances, how is the GT instance differentiated from any 
other routed instance?

Did you read the draft? The main difference is that since OSPF-GT is 
generalized to be used for non-routing, there is installation of routes. 
OSPF-GT neighbors need not be directly attached (or come with complex OSPF 
Virtual-Link considerations and processing). Depending on the application, the 
extent to which the “condition of reachability” is enforced MUST be described 
in the document describing the application usage of OSPF-GT.


For OSPFV2 it would use Opaque LSA Type 9,10,21 similar to RSVP-TE with an 
opaque option code for GTI.

For OSPFV3 it would use an OSPFV3 function code for GTI.

So the NBI BGP-LS peering to the PCE/SDN controller would be replaced with a   
OSPF GTI neighbor ?

It could be but that is just one OSPF-GT use case and would need to be 
described in a separate draft.

Would you still need a standard routed OSPF neighbor for reachability or I 
guess you could put a static route on the controller across the NBI for 
reachability.

Yes.

Is that correct?

Are there any operators implementations of this using OSPF GTI in place of 
BGP-LS?

You mean OSPF-GT… Since the draft to describe the details of using OSPF-GT in 
place of BGP-LS is yet to be written, it would be very strange indeed if it 
were already deployed. 

RFC 6823 provides the same GTI solution for ISIS.

Yes and no, OSPF-GT is able to cover a much wider range of applications than 
RFC 683. This is due mostly to OSPF (and especially OSPFv3 with extended LSAs) 
being much more flexible than IS-IS.


Are there any operators implementations of this using OSPF GTI in place of 
BGP-LS?

No - answered above.

Thanks,
Acee


Kind Regards

Gyan

On Sun, Jul 10, 2022 at 1:04 AM Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:
Hi,

Since we’re discussing possible solutions, I’d like to bring up the draft: 
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/

We just submitted a new version. The name of the document is changed to 
“OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT as a 
possible replacement of BGP-LS.

Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate routes. 
It uses the reachability info calculated by routing protocols, OSPF, ISIS or 
static routing etc.. It provides mechanisms to advertise non-routing 
information, and remote neighbor is supported.

Reviews and comments are welcome.


Thanks,
Yingzhen



On Jul 9, 2022, at 5:33 PM, Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:


During the interim meeting we should keep it open to discuss all possible 
alternatives to BGP-LS.

Thanks

Gyan

On Sat, Jul 9, 2022 at 4:45 PM Susan Hares 
mailto:sha...@ndzh.com>> wrote:
Jeff:

An interim sounds like a good plan.

[IDR-chair hat]
Alvaro has indicated that since all of the proposal received on the IDR list 
are new protocol proposals,
· Capturing IDR’s input on BGP-LS problems and potential solutions is 
appropriate for IDR as BGP-LS home.
· Refining any potential non-BGP solutions is outside of the scope of 
IDR.

[IDR-chair hat off]
[rtgwg WG member]
I’d love to attend an interim on this topic.

Sue Hares


From: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Sent: Saturday, July 9, 2022 3:40 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Acee Lindem (acee) mailto:a...@cisco.com>>; lsr 
mailto:l...@ietf.org>>; i...@ietf.org<mailto:i...@ietf.org>; 
Susan Hares mailto:sha...@ndzh.com>>; 
grow@ietf.org<mailto:grow@ietf.org> grow@ietf.org<mailto:grow@ietf.org> 
mailto:grow@ietf.org>>
Subject: Re: [Idr] [Lsr] IGP Monitoring Protocol



Speaking as RTGWG chair:

Robert - I don’t think we’d have enough time to accommodate a good discussion 
during IETF114 (we got only 1 slot), however would be happy to provide a 
platform for an interim.
The topic is important and personally (being a very large BGP-LS user) I’d like 
to see it progressing.
Cheers,
Jeff

On Jul 8, 2022, at 14:44, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Acee,

Yes, by all means input from the operator's community is needed. It can be 
collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute. We 
have already seen input from some operators and their opinion on adding and 
distributing more and more link state protocol and topology data in BGP. More 
such input is very welcome.

And to your point about RFC9086 - I see nothing wrong in keeping BGP 
information in BGP. So IGP Monitoring Protocol does not target to shut down 
BGP-LS. It only aims to remov

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Gyan Mishra]

Hi Yingzhen

So with OSPFV2 using RFC 6549 would support multiple instances or OSPFV3
already supports instances, how is the GT instance differentiated from any
other routed instance?

For OSPFV2 it would use Opaque LSA Type 9,10,21 similar to RSVP-TE with an
opaque option code for GTI.

For OSPFV3 it would use an OSPFV3 function code for GTI.

So the NBI BGP-LS peering to the PCE/SDN controller would be replaced with
a   OSPF GTI neighbor ?

Would you still need a standard routed OSPF neighbor for reachability or I
guess you could put a static route on the controller across the NBI for
reachability.

Is that correct?

Are there any operators implementations of this using OSPF GTI in place of
BGP-LS?

RFC 6823 provides the same GTI solution for ISIS.


Are there any operators implementations of this using OSPF GTI in place of
BGP-LS?

Kind Regards

Gyan

On Sun, Jul 10, 2022 at 1:04 AM Yingzhen Qu  wrote:

> Hi,
>
> Since we’re discussing possible solutions, I’d like to bring up the draft:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/
>
> We just submitted a new version. The name of the document is changed to
> “OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT
> as a possible replacement of BGP-LS.
>
> Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate
> routes. It uses the reachability info calculated by routing protocols,
> OSPF, ISIS or static routing etc.. It provides mechanisms to advertise
> non-routing information, and remote neighbor is supported.
>
> Reviews and comments are welcome.
>
>
> Thanks,
> Yingzhen
>
>
> On Jul 9, 2022, at 5:33 PM, Gyan Mishra  wrote:
>
>
> During the interim meeting we should keep it open to discuss all possible
> alternatives to BGP-LS.
>
> Thanks
>
> Gyan
>
> On Sat, Jul 9, 2022 at 4:45 PM Susan Hares  wrote:
>
>> Jeff:
>>
>>
>>
>> An interim sounds like a good plan.
>>
>>
>>
>> [IDR-chair hat]
>>
>> Alvaro has indicated that since all of the proposal received on the IDR
>> list are new protocol proposals,
>>
>>- Capturing IDR’s input on BGP-LS problems and potential solutions is
>>appropriate for IDR as BGP-LS home.
>>- Refining any potential non-BGP solutions is outside of the scope of
>>IDR.
>>
>>
>>
>> [IDR-chair hat off]
>>
>> [rtgwg WG member]
>>
>> I’d love to attend an interim on this topic.
>>
>>
>>
>> Sue Hares
>>
>>
>>
>>
>>
>> *From:* Jeff Tantsura 
>> *Sent:* Saturday, July 9, 2022 3:40 PM
>> *To:* Robert Raszuk 
>> *Cc:* Acee Lindem (acee) ; lsr ;
>> i...@ietf.org; Susan Hares ; grow@ietf.org grow@ietf.org
>> 
>> *Subject:* Re: [Idr] [Lsr] IGP Monitoring Protocol
>>
>>
>>
>>
>>
>> Speaking as RTGWG chair:
>>
>>
>>
>> Robert - I don’t think we’d have enough time to accommodate a good
>> discussion during IETF114 (we got only 1 slot), however would be happy to
>> provide a platform for an interim.
>>
>> The topic is important and personally (being a very large BGP-LS user)
>> I’d like to see it progressing.
>>
>> Cheers,
>>
>> Jeff
>>
>>
>>
>> On Jul 8, 2022, at 14:44, Robert Raszuk  wrote:
>>
>> 
>>
>> Hi Acee,
>>
>>
>>
>> Yes, by all means input from the operator's community is needed. It can
>> be collected through LSR WG, IDR WG or GROW WG. RTGWG could also
>> contribute. We have already seen input from some operators and their
>> opinion on adding and distributing more and more link state protocol and
>> topology data in BGP. More such input is very welcome.
>>
>>
>>
>> And to your point about RFC9086 - I see nothing wrong in keeping BGP
>> information in BGP. So IGP Monitoring Protocol does not target to shut down
>> BGP-LS. It only aims to remove 100% of non BGP sourced information from it.
>>
>>
>>
>> Controllers which today listen to BGP-LS need a number of information
>> sources and that spread will only keep increasing as more inputs are
>> becoming necessary for its computations.
>>
>>
>>
>> Regards,
>>
>> Robert.
>>
>>
>>
>>
>>
>> On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee) 
>> wrote:
>>
>> Hi Robert,
>>
>>
>>
>> *From: *Robert Raszuk 
>> *Date: *Friday, July 8, 2022 at 4:36 PM
>> *To: *Acee Lindem 
>> *Cc: *lsr , IDR List , Susan Hares <
>> sha...@ndzh.com>
>> *Subject: *Re: [Lsr] IGP Monitoring Protocol
>>
>>
>>
>> Hi Acee,
>>
>>
>>
>> Thank you. I was not planning to present it in the upcoming IETF.
>>
>>
>>
>> > Let’s see how many stakeholders actually want to this protocol - then
>> we can talk about a WG home.
>>
>>
>>
>> An alternative approach could be to see how many stakeholders do not want
>> to further (for no good reason) to trash BGP. That to me would be in this
>> specific case a much better gauge.
>>
>>
>>
>> In that case, it seems to me that this discussion should be relegated to
>> IDR. Note that there is already non-IGP information transported in BGP-LS,
>> e.g., Egress Peer Engineering (https://datatracker.ietf.org/doc/rfc9086/).
>> I implemented this on our data center routers (NXOS) years and it is solely
>> BGP specific.
>>

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Jeff Tantsura]

Thanks Sue!We don’t have to always reinvent the wheel (at least not every time )I’m aware of at least 1 implementation streaming LSDB for TE consumers (gRPC)There are most probably some other vendor specific encodings/methods to steam to do that I believe – there has been some work around Kafka. Would be great to  do some study around existing solutions, see what worked, what didn’t’ (and why)   Cheers,Jeff From: Susan HaresSent: Saturday, July 9, 2022 1:44 PMTo: Jeff Tantsura; Robert RaszukCc: Acee Lindem (acee); lsr; i...@ietf.org; grow@ietf.org grow@ietf.orgSubject: RE: [Idr] [Lsr] IGP Monitoring Protocol Jeff: An interim sounds like a good plan.   [IDR-chair hat] Alvaro has indicated that since all of the proposal received on the IDR list are new protocol proposals, Capturing IDR’s input on BGP-LS problems and potential solutions is appropriate for IDR as BGP-LS home. Refining any potential non-BGP solutions is outside of the scope of IDR.  [IDR-chair hat off] [rtgwg WG member] I’d love to attend an interim on this topic.  Sue Hares  From: Jeff Tantsura  Sent: Saturday, July 9, 2022 3:40 PMTo: Robert Raszuk Cc: Acee Lindem (acee) ; lsr ; i...@ietf.org; Susan Hares ; grow@ietf.org grow@ietf.org Subject: Re: [Idr] [Lsr] IGP Monitoring Protocol  Speaking as RTGWG chair: Robert - I don’t think we’d have enough time to accommodate a good discussion during IETF114 (we got only 1 slot), however would be happy to provide a platform for an interim.The topic is important and personally (being a very large BGP-LS user) I’d like to see it progressing.Cheers,Jeff On Jul 8, 2022, at 14:44, Robert Raszuk  wrote:Hi Acee,  Yes, by all means input from the operator's community is needed. It can be collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute. We have already seen input from some operators and their opinion on adding and distributing more and more link state protocol and topology data in BGP. More such input is very welcome.  And to your point about RFC9086 - I see nothing wrong in keeping BGP information in BGP. So IGP Monitoring Protocol does not target to shut down BGP-LS. It only aims to remove 100% of non BGP sourced information from it.  Controllers which today listen to BGP-LS need a number of information sources and that spread will only keep increasing as more inputs are becoming necessary for its computations.  Regards,Robert.  On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee)  wrote:Hi Robert, From: Robert Raszuk Date: Friday, July 8, 2022 at 4:36 PMTo: Acee Lindem Cc: lsr , IDR List , Susan Hares Subject: Re: [Lsr] IGP Monitoring Protocol Hi Acee, Thank you. I was not planning to present it in the upcoming IETF.  > Let’s see how many stakeholders actually want to this protocol - then we can talk about a WG home.   An alternative approach could be to see how many stakeholders do not want to further (for no good reason) to trash BGP. That to me would be in this specific case a much better gauge.   In that case, it seems to me that this discussion should be relegated to IDR. Note that there is already non-IGP information transported in BGP-LS, e.g., Egress Peer Engineering (https://datatracker.ietf.org/doc/rfc9086/). I implemented this on our data center routers (NXOS) years and it is solely BGP specific.  Thanks,Acee Kind regards,Robert  On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee)  wrote:Speaking as WG chair:  From: Lsr  on behalf of Robert Raszuk Date: Friday, July 8, 2022 at 3:21 PMTo: lsr Cc: IDR List , Susan Hares Subject: [Lsr] IGP Monitoring Protocol Dear LSR WG, Based on ongoing discussion in respect to the future of BGP-LS I committed myself to put together an alternate proposal.  The main goal is not to just publish a -00 version of the draft using different encapsulation. The goal is to make a useful tool which can help to export link state information from network elements as well as assist in network observability.  The IGP Monitoring Protocol (IMP) draft has been posted and should be available at: https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/ One of the key points I wanted to accomplish was full backwards compatibility with TLVs defined for BGP-LS. In parallel other formats (optional) are also supported.  The PUB-SUB nature or FILTERING capabilities are in the spec however as noted in the deployment section there is no expectation that this should be supported directly on routers. Concept of Producer's Proxies has been introduced to support this added functionality as well as provide fan-out (analogy to BGP route reflectors).  I encourage everyone interested to take a look and provide comments. At this point this document is nothing more than my individual submission. Offline I have had few conversations with both operators and vendors 

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

Hi Yingzhen & OSPF-GT authors,

UP front I must state that anything is better to export IGP information
from routers to interested nodes than using BGP for it.

But to propose using OSPF to transport ISIS seems pretty brave :) I must
admit it !

With that I have few questions to the proposal - assuming the use case is
to distribute links state info in a *point to point* fashion:

A) What is the advantage - if any - to use a new OSPF instance/process to
send link state data over a unicast session to a controller ?

B) The draft is pretty silent on the nature of such a p2p session. Please
be explicit if this is TCP, QUIC or what ?

C) The draft is pretty silent on types of authentication for such sessions.
Security considerations are pretty weak in that respect as well.

   The security considerations for OSPF-GT will be similar to those for
   OSPFv2 [RFC2328] and OSPFv3 [RFC5340].  However, since OSPF-GT is not
   used to update OSPF routing, the consequences of attacks will be
   dependent on advertised non-routing information.

I would actually argue that security considerations of p2p remote neighbors
are actually quite different from security considerations of flooding data.

Along the same lines security is not about protecting your routing ... it
is much more about protecting the entire network by exposing critical
information externally to non authorized parties.

D) Are there any PUB-SUB options possible for OSPF-GT ?

E) Is there any filtering possible for OSPF-GT ?

F) Are you envisioning use of OSPF-GT proxies and if so are you planning to
add this to the document ?

G) How are you going to address Receivers which do not support OSPF-GT
parser ?

H) As you know many operators are attracted to BGP-LS based on the fact
that it offers the same view of information irrespective of what is the
protocol producing the data. Is there some thought on such normalization in
the OSPF-GT proposal ?

I) What's the take of OSPF-GT draft authors on the YANG model in respect of
using it for normalization of exported data ?

To summarize IMHO we should not stretch routing protocols be it OSPF, ISIS
or BGP to be messengers of link state data running and to artificially
force them to run in a point-to-point model between router and controller.

Kind regards,
Robert


On Sun, Jul 10, 2022 at 7:04 AM Yingzhen Qu  wrote:

> Hi,
>
> Since we’re discussing possible solutions, I’d like to bring up the draft:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/
>
> We just submitted a new version. The name of the document is changed to
> “OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT
> as a possible replacement of BGP-LS.
>
> Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate
> routes. It uses the reachability info calculated by routing protocols,
> OSPF, ISIS or static routing etc.. It provides mechanisms to advertise
> non-routing information, and remote neighbor is supported.
>
> Reviews and comments are welcome.
>
>
> Thanks,
> Yingzhen
>
> On Jul 9, 2022, at 5:33 PM, Gyan Mishra  wrote:
>
>
> During the interim meeting we should keep it open to discuss all possible
> alternatives to BGP-LS.
>
> Thanks
>
> Gyan
>
> On Sat, Jul 9, 2022 at 4:45 PM Susan Hares  wrote:
>
>> Jeff:
>>
>>
>>
>> An interim sounds like a good plan.
>>
>>
>>
>> [IDR-chair hat]
>>
>> Alvaro has indicated that since all of the proposal received on the IDR
>> list are new protocol proposals,
>>
>>- Capturing IDR’s input on BGP-LS problems and potential solutions is
>>appropriate for IDR as BGP-LS home.
>>- Refining any potential non-BGP solutions is outside of the scope of
>>IDR.
>>
>>
>>
>> [IDR-chair hat off]
>>
>> [rtgwg WG member]
>>
>> I’d love to attend an interim on this topic.
>>
>>
>>
>> Sue Hares
>>
>>
>>
>>
>>
>> *From:* Jeff Tantsura 
>> *Sent:* Saturday, July 9, 2022 3:40 PM
>> *To:* Robert Raszuk 
>> *Cc:* Acee Lindem (acee) ; lsr ;
>> i...@ietf.org; Susan Hares ; grow@ietf.org grow@ietf.org
>> 
>> *Subject:* Re: [Idr] [Lsr] IGP Monitoring Protocol
>>
>>
>>
>>
>>
>> Speaking as RTGWG chair:
>>
>>
>>
>> Robert - I don’t think we’d have enough time to accommodate a good
>> discussion during IETF114 (we got only 1 slot), however would be happy to
>> provide a platform for an interim.
>>
>> The topic is important and personally (being a very large BGP-LS user)
>> I’d like to see it progressing.
>>
>> Cheers,
>>
>> Jeff
>>
>>
>>
>> On Jul 8, 2022, at 14:44, Robert Raszuk  wrote:
>>
>> 
>>
>> Hi Acee,
>>
>>
>>
>> Yes, by all means input from the operator's community is needed. It can
>> be collected through LSR WG, IDR WG or GROW WG. RTGWG could also
>> contribute. We have already seen input from some operators and their
>> opinion on adding and distributing more and more link state protocol and
>> topology data in BGP. More such input is very welcome.
>>
>>
>>
>> And to your point about RFC9086 - I see nothing wrong in keeping BGP
>> information in BGP. 

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

ns at the DATA
Types. That IMO is an IMP property. I agree that what specific elements are
sent can be done with the NETCONF/RESTCONF mechanism.

For now I refrained from adding this to the spec. Only added top level TLV
filters.

Said this I am very open to follow your above recommendation for YANG DATA
Types and need for more granular subscriptions. But I think I would rather
see this applicable to Producer's Proxies not Producers directly. Just
trying to keep Producers as light as possible as not all RP/RE can handle
too much of such load.


> Regarding the terminology of "Producer" and "Receiver". I suggest to align
> the wording with existing Network Telemetry (RFC 9232) protocols.
> Unfortunately they aren't aligned among at all even though they are doing
> more or less all the same. Exporting monitoring data to a data collection.
> My personal favorite is Exporting and Collecting Process.
>
>
>
> IPFIX:   Exporting Process, Collecting Process
>
> BMP: Management Station, Monitoring Station
>
> YANG push:   Publisher, Receiver
>
> IMP:  Producer, Receiver
>

I used the Producer term as this is how some implementations call its
components. The receivers are Clients.

But if we think that "Publisher" term is a better fit I have no issue
renaming it such. Receiver could stay as is or could be called Client too.

Many thx and thank you again for your review and excellent comments.

Robert



>
>
> Best wishes
>
> Thomas
>
>
>
> *From:* GROW  *On Behalf Of *Robert Raszuk
> *Sent:* Saturday, July 9, 2022 9:49 PM
> *To:* Jeff Tantsura 
> *Cc:* lsr ; grow@ietf.org grow@ietf.org ;
> idr@ietf. org 
> *Subject:* Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol
>
>
>
> Thx Jeff !
>
>
>
> Also I welcome more reviews and suggestions for additions or deletions of
> parts of it. For now I tried to keep it very simple for routers -
> essentially setup new p2p TCP or QUIC sessions and send over exactly what
> you put in BGP today. In the same time I see use cases beyond that so added
> few optional more DATA Types.
>
>
>
> With basic DATA Types 1 or 2 there is zero changes needed on the receivers
> - some folks told me this is huge advantage.
>
>
>
> Then two optional messages REQUEST and FILTER provide ability for trimming
> excessive data either on the Producer or Producer's Proxy.
>
>
>
> Many thx,
>
> Robert
>
>
>
>
>
> On Sat, Jul 9, 2022 at 9:39 PM Jeff Tantsura 
> wrote:
>
> Speaking as RTGWG chair:
>
>
>
> Robert - I don’t think we’d have enough time to accommodate a good
> discussion during IETF114 (we got only 1 slot), however would be happy to
> provide a platform for an interim.
>
> The topic is important and personally (being a very large BGP-LS user) I’d
> like to see it progressing.
>
> Cheers,
>
> Jeff
>
>
>
> On Jul 8, 2022, at 14:44, Robert Raszuk  wrote:
>
> 
>
> Hi Acee,
>
>
>
> Yes, by all means input from the operator's community is needed. It can be
> collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute.
> We have already seen input from some operators and their opinion on adding
> and distributing more and more link state protocol and topology data in
> BGP. More such input is very welcome.
>
>
>
> And to your point about RFC9086 - I see nothing wrong in keeping BGP
> information in BGP. So IGP Monitoring Protocol does not target to shut down
> BGP-LS. It only aims to remove 100% of non BGP sourced information from it.
>
>
>
> Controllers which today listen to BGP-LS need a number of information
> sources and that spread will only keep increasing as more inputs are
> becoming necessary for its computations.
>
>
>
> Regards,
>
> Robert.
>
>
>
>
>
> On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee)  wrote:
>
> Hi Robert,
>
>
>
> *From: *Robert Raszuk 
> *Date: *Friday, July 8, 2022 at 4:36 PM
> *To: *Acee Lindem 
> *Cc: *lsr , IDR List , Susan Hares <
> sha...@ndzh.com>
> *Subject: *Re: [Lsr] IGP Monitoring Protocol
>
>
>
> Hi Acee,
>
>
>
> Thank you. I was not planning to present it in the upcoming IETF.
>
>
>
> > Let’s see how many stakeholders actually want to this protocol - then we
> can talk about a WG home.
>
>
>
> An alternative approach could be to see how many stakeholders do not want
> to further (for no good reason) to trash BGP. That to me would be in this
> specific case a much better gauge.
>
>
>
> In that case, it seems to me that this discussion should be relegated to
> IDR. Note that there is already non-IGP informatio

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Thomas.Graf]

Dear Robert,

I reviewed draft-raszuk-lsr-imp-00 and have some firsts comments and 
suggestions.

First of all, speaking as a network operator who is using BMP to gain 
visibility into the BGP control-plane, seeing the real benefits in operation 
every day, I was looking very forward at IETF seeing a similar debugging kind 
of approach being applied to IGP. You addressed that aspect very well. Thank 
you very much.

I would like to understand if data type 3-9 described in section 5 exporting 
the initial LSDB state when the transport session is being established and once 
fully exported, only the subsequential updates? Comparable to route-monitoring 
in BMP.

In section 5 you are describing data type 7, 8 and 9. Exporting LSDB as 
structured data in YANG. I like the idea in general but doubt that vendors will 
fancy implementations due to the additional I/O impact on the IGP process. 
However I think it is very valuable to have the LSDB modelled in YANG for data 
correlation purposes. I suggest that the YANG modelling can happen on the 
producer with data type 7, 8 and 9 or on the receiver side by converting data 
type 3-6 and 10-13 into JSON/XML with the YANG data model. I suspect that the 
YANG model itself for modelling the LSDB itself is not part of the document, 
therefore a reference to existing drafts such as draft-ietf-ospf-yang would 
help to better understand that context.


In section 5 you are describing in figure 2 the data message header. Here I 
suggest to add besides the "Router Identifier" also the "Process Identifier" to 
have the proper device context if more than one process is running.

Lessons learned from BMP is that knowing the control-plane state alone isn't 
enough for proper data correlation for IPFIX Flow Aggregation as described in 
RFC 7015. We need also to understand how (active, passive, ecmp, not considered 
etc.) the path is being installed into the RIB. At BMP we are addressing this 
with draft-cppy-grow-bmp-path-marking-tlv. I suggest to include this RIB aspect 
into IMP from day 1. If that makes sense to you as well, I gladly make a 
proposal.

Regarding the subscription aspect described in section 3. Here I would prefer a 
similar approach as draft-cptb-grow-bmp-yang, being done through a 
NETCONF/RESTCONF configured subscription. A YANG model gives the possibility 
not only to define but also to monitor the subscription which is fundamental 
for proper data collection. draft-arokiarajseda-ipfix-data-export-yang-model 
does the same for IPFIX. For YANG push this is defined in RFC 8641.

Regarding the terminology of "Producer" and "Receiver". I suggest to align the 
wording with existing Network Telemetry (RFC 9232) protocols. Unfortunately 
they aren't aligned among at all even though they are doing more or less all 
the same. Exporting monitoring data to a data collection. My personal favorite 
is Exporting and Collecting Process.

IPFIX:   Exporting Process, Collecting Process
BMP: Management Station, Monitoring Station
YANG push:   Publisher, Receiver
IMP:  Producer, Receiver

Best wishes
Thomas

From: GROW  On Behalf Of Robert Raszuk
Sent: Saturday, July 9, 2022 9:49 PM
To: Jeff Tantsura 
Cc: lsr ; grow@ietf.org grow@ietf.org ; idr@ietf. 
org 
Subject: Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

Thx Jeff !

Also I welcome more reviews and suggestions for additions or deletions of parts 
of it. For now I tried to keep it very simple for routers - essentially setup 
new p2p TCP or QUIC sessions and send over exactly what you put in BGP today. 
In the same time I see use cases beyond that so added few optional more DATA 
Types.

With basic DATA Types 1 or 2 there is zero changes needed on the receivers - 
some folks told me this is huge advantage.

Then two optional messages REQUEST and FILTER provide ability for trimming 
excessive data either on the Producer or Producer's Proxy.

Many thx,
Robert


On Sat, Jul 9, 2022 at 9:39 PM Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Speaking as RTGWG chair:

Robert - I don’t think we’d have enough time to accommodate a good discussion 
during IETF114 (we got only 1 slot), however would be happy to provide a 
platform for an interim.
The topic is important and personally (being a very large BGP-LS user) I’d like 
to see it progressing.
Cheers,
Jeff


On Jul 8, 2022, at 14:44, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Hi Acee,

Yes, by all means input from the operator's community is needed. It can be 
collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute. We 
have already seen input from some operators and their opinion on adding and 
distributing more and more link state protocol and topology data in BGP. More 
such input is very welcome.

And to your point about RFC9086 - I see nothing wrong in keeping BGP 
information in BGP. So IGP Monitoring Protocol does not target to shut 

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Yingzhen Qu]

Hi,

Since we’re discussing possible solutions, I’d like to bring up the draft: 
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/ 


We just submitted a new version. The name of the document is changed to 
“OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT as a 
possible replacement of BGP-LS.

Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate routes. 
It uses the reachability info calculated by routing protocols, OSPF, ISIS or 
static routing etc.. It provides mechanisms to advertise non-routing 
information, and remote neighbor is supported.

Reviews and comments are welcome.


Thanks,
Yingzhen

> On Jul 9, 2022, at 5:33 PM, Gyan Mishra  wrote:
> 
> 
> During the interim meeting we should keep it open to discuss all possible 
> alternatives to BGP-LS.
> 
> Thanks 
> 
> Gyan
> 
> On Sat, Jul 9, 2022 at 4:45 PM Susan Hares  > wrote:
> Jeff:
> 
>  
> 
> An interim sounds like a good plan. 
> 
>  
> 
> [IDR-chair hat]
> 
> Alvaro has indicated that since all of the proposal received on the IDR list 
> are new protocol proposals,
> 
> Capturing IDR’s input on BGP-LS problems and potential solutions is 
> appropriate for IDR as BGP-LS home.
> Refining any potential non-BGP solutions is outside of the scope of IDR.
>  
> 
> [IDR-chair hat off]
> 
> [rtgwg WG member]
> 
> I’d love to attend an interim on this topic.
> 
>  
> 
> Sue Hares
> 
>  
> 
>  
> 
> From: Jeff Tantsura  > 
> Sent: Saturday, July 9, 2022 3:40 PM
> To: Robert Raszuk mailto:rob...@raszuk.net>>
> Cc: Acee Lindem (acee) mailto:a...@cisco.com>>; lsr 
> mailto:l...@ietf.org>>; i...@ietf.org ; 
> Susan Hares mailto:sha...@ndzh.com>>; grow@ietf.org 
>  grow@ietf.org   >
> Subject: Re: [Idr] [Lsr] IGP Monitoring Protocol
> 
>  
> 
> 
>  
> 
> Speaking as RTGWG chair:
> 
>  
> 
> Robert - I don’t think we’d have enough time to accommodate a good discussion 
> during IETF114 (we got only 1 slot), however would be happy to provide a 
> platform for an interim.
> 
> The topic is important and personally (being a very large BGP-LS user) I’d 
> like to see it progressing.
> 
> Cheers,
> 
> Jeff
> 
> 
> 
> 
> On Jul 8, 2022, at 14:44, Robert Raszuk  > wrote:
> 
> 
> 
> Hi Acee, 
> 
>  
> 
> Yes, by all means input from the operator's community is needed. It can be 
> collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute. We 
> have already seen input from some operators and their opinion on adding and 
> distributing more and more link state protocol and topology data in BGP. More 
> such input is very welcome. 
> 
>  
> 
> And to your point about RFC9086 - I see nothing wrong in keeping BGP 
> information in BGP. So IGP Monitoring Protocol does not target to shut down 
> BGP-LS. It only aims to remove 100% of non BGP sourced information from it. 
> 
>  
> 
> Controllers which today listen to BGP-LS need a number of information sources 
> and that spread will only keep increasing as more inputs are becoming 
> necessary for its computations. 
> 
>  
> 
> Regards,
> 
> Robert.
> 
>  
> 
>  
> 
> On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee)  > wrote:
> 
> Hi Robert,
> 
>  
> 
> From: Robert Raszuk mailto:rob...@raszuk.net>>
> Date: Friday, July 8, 2022 at 4:36 PM
> To: Acee Lindem mailto:a...@cisco.com>>
> Cc: lsr mailto:l...@ietf.org>>, IDR List  >, Susan Hares  >
> Subject: Re: [Lsr] IGP Monitoring Protocol
> 
>  
> 
> Hi Acee,
> 
>  
> 
> Thank you. I was not planning to present it in the upcoming IETF. 
> 
>  
> 
> > Let’s see how many stakeholders actually want to this protocol - then we 
> > can talk about a WG home.  
> 
>  
> 
> An alternative approach could be to see how many stakeholders do not want to 
> further (for no good reason) to trash BGP. That to me would be in this 
> specific case a much better gauge.  
> 
>  
> 
> In that case, it seems to me that this discussion should be relegated to IDR. 
> Note that there is already non-IGP information transported in BGP-LS, e.g., 
> Egress Peer Engineering (https://datatracker.ietf.org/doc/rfc9086/ 
> ). I implemented this on our data 
> center routers (NXOS) years and it is solely BGP specific.
> 
>  
> 
> Thanks,
> 
> Acee
> 
>  
> 
> Kind regards,
> 
> Robert
> 
>  
> 
>  
> 
> On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee)  > wrote:
> 
> Speaking as WG chair:
> 
>  
> 
> From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
> Robert Raszuk mailto:rob...@raszuk.net>>
> Date: Friday, July 8, 2022 at 3:21 PM
> To: lsr mailto:l...@ietf.org>>
> Cc: IDR List mailto:i...@ietf.org>>, Susan Hares 
> mailto:sha...@ndzh.com>>
> Subject: 

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Gyan Mishra]

During the interim meeting we should keep it open to discuss all possible
alternatives to BGP-LS.

Thanks

Gyan

On Sat, Jul 9, 2022 at 4:45 PM Susan Hares  wrote:

> Jeff:
>
>
>
> An interim sounds like a good plan.
>
>
>
> [IDR-chair hat]
>
> Alvaro has indicated that since all of the proposal received on the IDR
> list are new protocol proposals,
>
>- Capturing IDR’s input on BGP-LS problems and potential solutions is
>appropriate for IDR as BGP-LS home.
>- Refining any potential non-BGP solutions is outside of the scope of
>IDR.
>
>
>
> [IDR-chair hat off]
>
> [rtgwg WG member]
>
> I’d love to attend an interim on this topic.
>
>
>
> Sue Hares
>
>
>
>
>
> *From:* Jeff Tantsura 
> *Sent:* Saturday, July 9, 2022 3:40 PM
> *To:* Robert Raszuk 
> *Cc:* Acee Lindem (acee) ; lsr ;
> i...@ietf.org; Susan Hares ; grow@ietf.org grow@ietf.org <
> grow@ietf.org>
> *Subject:* Re: [Idr] [Lsr] IGP Monitoring Protocol
>
>
>
>
>
> Speaking as RTGWG chair:
>
>
>
> Robert - I don’t think we’d have enough time to accommodate a good
> discussion during IETF114 (we got only 1 slot), however would be happy to
> provide a platform for an interim.
>
> The topic is important and personally (being a very large BGP-LS user) I’d
> like to see it progressing.
>
> Cheers,
>
> Jeff
>
>
>
> On Jul 8, 2022, at 14:44, Robert Raszuk  wrote:
>
> 
>
> Hi Acee,
>
>
>
> Yes, by all means input from the operator's community is needed. It can be
> collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute.
> We have already seen input from some operators and their opinion on adding
> and distributing more and more link state protocol and topology data in
> BGP. More such input is very welcome.
>
>
>
> And to your point about RFC9086 - I see nothing wrong in keeping BGP
> information in BGP. So IGP Monitoring Protocol does not target to shut down
> BGP-LS. It only aims to remove 100% of non BGP sourced information from it.
>
>
>
> Controllers which today listen to BGP-LS need a number of information
> sources and that spread will only keep increasing as more inputs are
> becoming necessary for its computations.
>
>
>
> Regards,
>
> Robert.
>
>
>
>
>
> On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee)  wrote:
>
> Hi Robert,
>
>
>
> *From: *Robert Raszuk 
> *Date: *Friday, July 8, 2022 at 4:36 PM
> *To: *Acee Lindem 
> *Cc: *lsr , IDR List , Susan Hares <
> sha...@ndzh.com>
> *Subject: *Re: [Lsr] IGP Monitoring Protocol
>
>
>
> Hi Acee,
>
>
>
> Thank you. I was not planning to present it in the upcoming IETF.
>
>
>
> > Let’s see how many stakeholders actually want to this protocol - then we
> can talk about a WG home.
>
>
>
> An alternative approach could be to see how many stakeholders do not want
> to further (for no good reason) to trash BGP. That to me would be in this
> specific case a much better gauge.
>
>
>
> In that case, it seems to me that this discussion should be relegated to
> IDR. Note that there is already non-IGP information transported in BGP-LS,
> e.g., Egress Peer Engineering (https://datatracker.ietf.org/doc/rfc9086/).
> I implemented this on our data center routers (NXOS) years and it is solely
> BGP specific.
>
>
>
> Thanks,
>
> Acee
>
>
>
> Kind regards,
>
> Robert
>
>
>
>
>
> On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee)  wrote:
>
> Speaking as WG chair:
>
>
>
> *From: *Lsr  on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Friday, July 8, 2022 at 3:21 PM
> *To: *lsr 
> *Cc: *IDR List , Susan Hares 
> *Subject: *[Lsr] IGP Monitoring Protocol
>
>
>
> Dear LSR WG,
>
>
>
> Based on ongoing discussion in respect to the future of BGP-LS I
> committed myself to put together an alternate proposal.
>
>
>
> The main goal is not to just publish a -00 version of the draft using
> different encapsulation. The goal is to make a useful tool which can help
> to export link state information from network elements as well as assist in
> network observability.
>
>
>
> The IGP Monitoring Protocol (IMP) draft has been posted and should be
> available at:
>
>
>
> https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/
>
>
>
> One of the key points I wanted to accomplish was full backwards
> compatibility with TLVs defined for BGP-LS. In parallel other formats
> (optional) are also supported.
>
>
>
> The PUB-SUB nature or FILTERING capabilities are in the spec however as
> noted in the deployment section there is no expectation that this should be
> supported directly on routers. Concept of Producer's Proxies has been
> introduced to support this added functionality as well as provide fan-out
> (analogy to BGP route reflectors).
>
>
>
> I encourage everyone interested to take a look and provide comments. At
> this point this document is nothing more than my individual submission.
> Offline I have had few conversations with both operators and vendors
> expressing some level of interest in this work. How we proceed further (if
> at all :) depends on WG feedback.
>
>
>
> Kind regards,
>
> Robert.
>
>

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Susan Hares]

Jeff:

An interim sounds like a good plan.

[IDR-chair hat]
Alvaro has indicated that since all of the proposal received on the IDR list 
are new protocol proposals,

  *   Capturing IDR’s input on BGP-LS problems and potential solutions is 
appropriate for IDR as BGP-LS home.
  *   Refining any potential non-BGP solutions is outside of the scope of IDR.

[IDR-chair hat off]
[rtgwg WG member]
I’d love to attend an interim on this topic.

Sue Hares


From: Jeff Tantsura 
Sent: Saturday, July 9, 2022 3:40 PM
To: Robert Raszuk 
Cc: Acee Lindem (acee) ; lsr ; i...@ietf.org; 
Susan Hares ; grow@ietf.org grow@ietf.org 
Subject: Re: [Idr] [Lsr] IGP Monitoring Protocol

Speaking as RTGWG chair: Robert - I don’t think we’d have enough time to 
accommodate a good discussion during IETF114 (we got only 1 slot), however 
would be happy to provide a platform for an interim.
External (jefftant.i...@gmail.com)
  Report This 
Email
  FAQ  GoDaddy Advanced Email Security, 
Powered by INKY

Speaking as RTGWG chair:

Robert - I don’t think we’d have enough time to accommodate a good discussion 
during IETF114 (we got only 1 slot), however would be happy to provide a 
platform for an interim.
The topic is important and personally (being a very large BGP-LS user) I’d like 
to see it progressing.
Cheers,
Jeff


On Jul 8, 2022, at 14:44, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Hi Acee,

Yes, by all means input from the operator's community is needed. It can be 
collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute. We 
have already seen input from some operators and their opinion on adding and 
distributing more and more link state protocol and topology data in BGP. More 
such input is very welcome.

And to your point about RFC9086 - I see nothing wrong in keeping BGP 
information in BGP. So IGP Monitoring Protocol does not target to shut down 
BGP-LS. It only aims to remove 100% of non BGP sourced information from it.

Controllers which today listen to BGP-LS need a number of information sources 
and that spread will only keep increasing as more inputs are becoming necessary 
for its computations.

Regards,
Robert.


On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Robert,

From: Robert Raszuk mailto:rob...@raszuk.net>>
Date: Friday, July 8, 2022 at 4:36 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: lsr mailto:l...@ietf.org>>, IDR List 
mailto:i...@ietf.org>>, Susan Hares 
mailto:sha...@ndzh.com>>
Subject: Re: [Lsr] IGP Monitoring Protocol

Hi Acee,

Thank you. I was not planning to present it in the upcoming IETF.

> Let’s see how many stakeholders actually want to this protocol - then we can 
> talk about a WG home.

An alternative approach could be to see how many stakeholders do not want to 
further (for no good reason) to trash BGP. That to me would be in this specific 
case a much better gauge.

In that case, it seems to me that this discussion should be relegated to IDR. 
Note that there is already non-IGP information transported in BGP-LS, e.g., 
Egress Peer Engineering 
(https://datatracker.ietf.org/doc/rfc9086/).
 I implemented this on our data center routers (NXOS) years and it is solely 
BGP specific.

Thanks,
Acee

Kind regards,
Robert


On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Speaking as WG chair:

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Robert Raszuk mailto:rob...@raszuk.net>>
Date: Friday, July 8, 2022 at 3:21 PM
To: lsr mailto:l...@ietf.org>>
Cc: IDR List mailto:i...@ietf.org>>, Susan Hares 
mailto:sha...@ndzh.com>>
Subject: [Lsr] IGP Monitoring Protocol

Dear LSR WG,

Based on ongoing discussion in respect to the future of BGP-LS I committed 
myself to put together an alternate proposal.

The main goal is not to just publish a -00 version of the draft using different 
encapsulation. The goal is to make a useful tool which can help to export link 
state information from network elements as well as assist in network 
observability.

The IGP Monitoring Protocol (IMP) draft has been posted and should be available 
at:

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

Thx Jeff !

Also I welcome more reviews and suggestions for additions or deletions of
parts of it. For now I tried to keep it very simple for routers -
essentially setup new p2p TCP or QUIC sessions and send over exactly what
you put in BGP today. In the same time I see use cases beyond that so added
few optional more DATA Types.

With basic DATA Types 1 or 2 there is zero changes needed on the receivers
- some folks told me this is huge advantage.

Then two optional messages REQUEST and FILTER provide ability for trimming
excessive data either on the Producer or Producer's Proxy.

Many thx,
Robert


On Sat, Jul 9, 2022 at 9:39 PM Jeff Tantsura 
wrote:

> Speaking as RTGWG chair:
>
> Robert - I don’t think we’d have enough time to accommodate a good
> discussion during IETF114 (we got only 1 slot), however would be happy to
> provide a platform for an interim.
> The topic is important and personally (being a very large BGP-LS user) I’d
> like to see it progressing.
>
> Cheers,
> Jeff
>
> On Jul 8, 2022, at 14:44, Robert Raszuk  wrote:
>
> 
> Hi Acee,
>
> Yes, by all means input from the operator's community is needed. It can be
> collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute.
> We have already seen input from some operators and their opinion on adding
> and distributing more and more link state protocol and topology data in
> BGP. More such input is very welcome.
>
> And to your point about RFC9086 - I see nothing wrong in keeping BGP
> information in BGP. So IGP Monitoring Protocol does not target to shut down
> BGP-LS. It only aims to remove 100% of non BGP sourced information from it.
>
> Controllers which today listen to BGP-LS need a number of information
> sources and that spread will only keep increasing as more inputs are
> becoming necessary for its computations.
>
> Regards,
> Robert.
>
>
> On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee)  wrote:
>
>> Hi Robert,
>>
>>
>>
>> *From: *Robert Raszuk 
>> *Date: *Friday, July 8, 2022 at 4:36 PM
>> *To: *Acee Lindem 
>> *Cc: *lsr , IDR List , Susan Hares <
>> sha...@ndzh.com>
>> *Subject: *Re: [Lsr] IGP Monitoring Protocol
>>
>>
>>
>> Hi Acee,
>>
>>
>>
>> Thank you. I was not planning to present it in the upcoming IETF.
>>
>>
>>
>> > Let’s see how many stakeholders actually want to this protocol - then
>> we can talk about a WG home.
>>
>>
>>
>> An alternative approach could be to see how many stakeholders do not want
>> to further (for no good reason) to trash BGP. That to me would be in this
>> specific case a much better gauge.
>>
>>
>>
>> In that case, it seems to me that this discussion should be relegated to
>> IDR. Note that there is already non-IGP information transported in BGP-LS,
>> e.g., Egress Peer Engineering (https://datatracker.ietf.org/doc/rfc9086/).
>> I implemented this on our data center routers (NXOS) years and it is solely
>> BGP specific.
>>
>>
>>
>> Thanks,
>>
>> Acee
>>
>>
>>
>> Kind regards,
>>
>> Robert
>>
>>
>>
>>
>>
>> On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee)  wrote:
>>
>> Speaking as WG chair:
>>
>>
>>
>> *From: *Lsr  on behalf of Robert Raszuk <
>> rob...@raszuk.net>
>> *Date: *Friday, July 8, 2022 at 3:21 PM
>> *To: *lsr 
>> *Cc: *IDR List , Susan Hares 
>> *Subject: *[Lsr] IGP Monitoring Protocol
>>
>>
>>
>> Dear LSR WG,
>>
>>
>>
>> Based on ongoing discussion in respect to the future of BGP-LS I
>> committed myself to put together an alternate proposal.
>>
>>
>>
>> The main goal is not to just publish a -00 version of the draft using
>> different encapsulation. The goal is to make a useful tool which can help
>> to export link state information from network elements as well as assist in
>> network observability.
>>
>>
>>
>> The IGP Monitoring Protocol (IMP) draft has been posted and should be
>> available at:
>>
>>
>>
>> https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/
>>
>>
>>
>> One of the key points I wanted to accomplish was full backwards
>> compatibility with TLVs defined for BGP-LS. In parallel other formats
>> (optional) are also supported.
>>
>>
>>
>> The PUB-SUB nature or FILTERING capabilities are in the spec however as
>> noted in the deployment section there is no expectation that this should be
>> supported directly on routers. Concept of Producer's Proxies has been
>> introduced to support this added functionality as well as provide fan-out
>> (analogy to BGP route reflectors).
>>
>>
>>
>> I encourage everyone interested to take a look and provide comments. At
>> this point this document is nothing more than my individual submission.
>> Offline I have had few conversations with both operators and vendors
>> expressing some level of interest in this work. How we proceed further (if
>> at all :) depends on WG feedback.
>>
>>
>>
>> Kind regards,
>>
>> Robert.
>>
>>
>>
>> PS, I do believe this work belongs in LSR WG pretty squerly.
>>
>>
>>
>> Let’s see how many stakeholders actually want to this protocol - then we
>> can talk about a WG home.  By stakeholders, I 

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Jeff Tantsura]

Speaking as RTGWG chair:

Robert - I don’t think we’d have enough time to accommodate a good discussion 
during IETF114 (we got only 1 slot), however would be happy to provide a 
platform for an interim.
The topic is important and personally (being a very large BGP-LS user) I’d like 
to see it progressing.

Cheers,
Jeff

> On Jul 8, 2022, at 14:44, Robert Raszuk  wrote:
> 
> 
> Hi Acee, 
> 
> Yes, by all means input from the operator's community is needed. It can be 
> collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute. We 
> have already seen input from some operators and their opinion on adding and 
> distributing more and more link state protocol and topology data in BGP. More 
> such input is very welcome. 
> 
> And to your point about RFC9086 - I see nothing wrong in keeping BGP 
> information in BGP. So IGP Monitoring Protocol does not target to shut down 
> BGP-LS. It only aims to remove 100% of non BGP sourced information from it. 
> 
> Controllers which today listen to BGP-LS need a number of information sources 
> and that spread will only keep increasing as more inputs are becoming 
> necessary for its computations. 
> 
> Regards,
> Robert.
> 
> 
>> On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee)  wrote:
>> Hi Robert,
>> 
>>  
>> 
>> From: Robert Raszuk 
>> Date: Friday, July 8, 2022 at 4:36 PM
>> To: Acee Lindem 
>> Cc: lsr , IDR List , Susan Hares 
>> 
>> Subject: Re: [Lsr] IGP Monitoring Protocol
>> 
>>  
>> 
>> Hi Acee,
>> 
>>  
>> 
>> Thank you. I was not planning to present it in the upcoming IETF. 
>> 
>>  
>> 
>> > Let’s see how many stakeholders actually want to this protocol - then we 
>> > can talk about a WG home.  
>> 
>>  
>> 
>> An alternative approach could be to see how many stakeholders do not want to 
>> further (for no good reason) to trash BGP. That to me would be in this 
>> specific case a much better gauge.  
>> 
>>  
>> 
>> In that case, it seems to me that this discussion should be relegated to 
>> IDR. Note that there is already non-IGP information transported in BGP-LS, 
>> e.g., Egress Peer Engineering (https://datatracker.ietf.org/doc/rfc9086/). I 
>> implemented this on our data center routers (NXOS) years and it is solely 
>> BGP specific.
>> 
>>  
>> 
>> Thanks,
>> 
>> Acee
>> 
>>  
>> 
>> Kind regards,
>> 
>> Robert
>> 
>>  
>> 
>>  
>> 
>> On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee)  wrote:
>> 
>> Speaking as WG chair:
>> 
>>  
>> 
>> From: Lsr  on behalf of Robert Raszuk 
>> 
>> Date: Friday, July 8, 2022 at 3:21 PM
>> To: lsr 
>> Cc: IDR List , Susan Hares 
>> Subject: [Lsr] IGP Monitoring Protocol
>> 
>>  
>> 
>> Dear LSR WG,
>> 
>>  
>> 
>> Based on ongoing discussion in respect to the future of BGP-LS I committed 
>> myself to put together an alternate proposal. 
>> 
>>  
>> 
>> The main goal is not to just publish a -00 version of the draft using 
>> different encapsulation. The goal is to make a useful tool which can help to 
>> export link state information from network elements as well as assist in 
>> network observability. 
>> 
>>  
>> 
>> The IGP Monitoring Protocol (IMP) draft has been posted and should be 
>> available at:
>> 
>>  
>> 
>> https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/
>> 
>>  
>> 
>> One of the key points I wanted to accomplish was full backwards 
>> compatibility with TLVs defined for BGP-LS. In parallel other formats 
>> (optional) are also supported. 
>> 
>>  
>> 
>> The PUB-SUB nature or FILTERING capabilities are in the spec however as 
>> noted in the deployment section there is no expectation that this should be 
>> supported directly on routers. Concept of Producer's Proxies has been 
>> introduced to support this added functionality as well as provide fan-out 
>> (analogy to BGP route reflectors). 
>> 
>>  
>> 
>> I encourage everyone interested to take a look and provide comments. At this 
>> point this document is nothing more than my individual submission. Offline I 
>> have had few conversations with both operators and vendors expressing some 
>> level of interest in this work. How we proceed further (if at all :) depends 
>> on WG feedback. 
>> 
>>  
>> 
>> Kind regards,
>> 
>> Robert.
>> 
>>  
>> 
>> PS, I do believe this work belongs in LSR WG pretty squerly. 
>> 
>>  
>> 
>> Let’s see how many stakeholders actually want to this protocol - then we can 
>> talk about a WG home.  By stakeholders, I mean operators and vendors who are 
>> committed to implementing and deploying it - not simply those who you are 
>> able to enlist as co-authors. Note that our IETF 114 LSR agenda is full 
>> (with multiple agenda items not making the cut). 
>> 
>>  
>> 
>> Thanks,
>> 
>> Acee 
>> 
>>  
>> 
>>  
>> 
>>  
>> 
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow