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

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

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

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

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

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 , "g...@ietf.org g...@ietf.org" < >

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

> 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: >

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

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

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-fast-flooding-01.txt

Hi all, Two technical changes: - reflecting the IANA allocated code point. - addition of a sub-TLV to specifically advertise the Receive Window of the flow control algo (aka RWIN). Previously, the "LSP Burst Window" was used, but the latter is more like a QoS/data plane buffer information so

[Lsr] I-D Action: draft-ietf-lsr-isis-fast-flooding-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : IS-IS Fast Flooding Authors : Bruno Decraene Les Ginsberg

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

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

Re: [Lsr] [Idr] [GROW] 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 > wrote: > > Hi Robert, > > I see this name very similar to BMP bgp monitoring

Re: [Lsr] [Idr] IGP Monitoring Protocol

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

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

Hi Robert, Thanks for sharing your point. We are actually very open on a new protocol also. We just want to solve real problems. We organized a side meeting in IETF to discuss this. The feedback from that meeting is a preference on reusing BMP.  Best, Tianran

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

Hi, I think BMP is busy enough that loading more on it will be problematic. Sourcing from two protocols just to leverage single transport session seems not best idea. IMO opening a new unicast session directly by the producer of subject data is best way to share/export it. Many thx, R. On

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

Hi Robert, Since our work is just follow the BMP which is in GROW in OPS area, we presented this in OPSAWG and GROW. We want to reuse BMP for IGP with some simple extensions. We do not want to create a new protocol only because of the BMP name. Cheers, Tianran

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

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

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

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

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

Hello Tianran, Oh I was not aware of such document. Did you ever share it with LSR WG before ? Quick browsing reveals that you have taken a bit different approach .. very IGP centric borrowing IGP encoding at the message level. For example peer state notification I purposely decided not to

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

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

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

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 , "g...@ietf.org g...@ietf.org" , lsr Subject: Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol Hi Gyan, From: GROW on behalf of Gyan Mishra Date:

Re: [Lsr] [GROW] [Idr] 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 , "g...@ietf.org g...@ietf.org" , lsr Subject: Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol Hi Yingzhen So with OSPFV2 using RFC 6549 would support multiple instances or

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

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

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

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>> 抄送：

[Lsr] Data Plane topology ID

Hi 6man and LSR: We submitted a draft of the DataPlane extension Topo ID: https://tools.ietf.org/id/draft-li-6man-topology-id-00.txt

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

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