Re: [GROW] [Idr] [Lsr] 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: [GROW] [Idr] [Lsr] 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 LS

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

;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

Re: [GROW] [Idr] [Lsr] 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: > Rober

Re: [GROW] [Idr] [Lsr] 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 AF

Re: [GROW] [Idr] [Lsr] 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 feed

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

Re: [GROW] [Idr] [Lsr] 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 encodings/me

Re: [GROW] [Idr] [Lsr] 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: [GROW] [Idr] [Lsr] 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 se

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

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 in

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? For OSPFV2 it would use Opaque LSA Type 9,10,21 similar to RSVP-TE with an opaque option code for GTI. For OSPFV3

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

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. W

Re: [GROW] [Idr] [Lsr] 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 - assu

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

onents. 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 wishe

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

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 sessio

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

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

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

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 re

Re: [GROW] [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 po

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 add

Re: [GROW] [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 prog