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 <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 <jefftant.i...@gmail.com> > *Sent:* Saturday, July 9, 2022 3:40 PM > *To:* Robert Raszuk <rob...@raszuk.net> > *Cc:* Acee Lindem (acee) <a...@cisco.com>; lsr <lsr@ietf.org>; > i...@ietf.org; Susan Hares <sha...@ndzh.com>; g...@ietf.org g...@ietf.org < > g...@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 <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 > > _______________________________________________ > GROW mailing list > g...@ietf.org > https://www.ietf.org/mailman/listinfo/grow > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
