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 <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) <a...@cisco.com> wrote: >> Hi Robert, >> >> >> >> From: Robert Raszuk <rob...@raszuk.net> >> Date: Friday, July 8, 2022 at 4:36 PM >> To: Acee Lindem <a...@cisco.com> >> Cc: lsr <lsr@ietf.org>, IDR List <i...@ietf.org>, 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) <a...@cisco.com> wrote: >> >> Speaking as WG chair: >> >> >> >> From: Lsr <lsr-boun...@ietf.org> on behalf of Robert Raszuk >> <rob...@raszuk.net> >> Date: Friday, July 8, 2022 at 3:21 PM >> To: lsr <lsr@ietf.org> >> Cc: IDR List <i...@ietf.org>, Susan Hares <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: >> >> >> >> 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
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
