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 > <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 Raszuk<rob...@raszuk.net <mailto:rob...@raszuk.net>> > 收件人： Yingzhen Qu<yingzhen.i...@gmail.com <mailto:yingzhen.i...@gmail.com>> > 抄送： idr<i...@ietf.org <mailto:i...@ietf.org>>;grow<grow@ietf.org > <mailto:grow@ietf.org>>;lsr<l...@ietf.org <mailto: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 <yingzhen.i...@gmail.com > <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 <rob...@raszuk.net >> <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) <a...@cisco.com >> <mailto:a...@cisco.com>> wrote: >> Hi Robert, >> >> >> >> From: Lsr <lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>> on behalf of >> Robert Raszuk <rob...@raszuk.net <mailto:rob...@raszuk.net>> >> Date: Sunday, July 10, 2022 at 1:32 PM >> To: Yingzhen Qu <yingzhen.i...@gmail.com <mailto:yingzhen.i...@gmail.com>> >> Cc: Gyan Mishra <hayabusa...@gmail.com <mailto:hayabusa...@gmail.com>>, >> Susan Hares <sha...@ndzh.com <mailto:sha...@ndzh.com>>, IDR List >> <i...@ietf.org <mailto:i...@ietf.org>>, "grow@ietf.org >> <mailto:grow@ietf.org> grow@ietf.org <mailto:grow@ietf.org>" <grow@ietf.org >> <mailto:grow@ietf.org>>, lsr <l...@ietf.org <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 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 <yingzhen.i...@gmail.com >> <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/ >> <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 <hayabusa...@gmail.com >> <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 <sha...@ndzh.com >> <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 <jefftant.i...@gmail.com >> <mailto:jefftant.i...@gmail.com>> >> Sent: Saturday, July 9, 2022 3:40 PM >> To: Robert Raszuk <rob...@raszuk.net <mailto:rob...@raszuk.net>> >> Cc: Acee Lindem (acee) <a...@cisco.com <mailto:a...@cisco.com>>; lsr >> <l...@ietf.org <mailto:l...@ietf.org>>; i...@ietf.org >> <mailto:i...@ietf.org>; Susan Hares <sha...@ndzh.com >> <mailto:sha...@ndzh.com>>; grow@ietf.org <mailto:grow@ietf.org>grow@ietf.org >> <mailto:grow@ietf.org> <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 <rob...@raszuk.net >> <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) <a...@cisco.com >> <mailto:a...@cisco.com>> wrote: >> >> Hi Robert, >> >> >> >> From: Robert Raszuk <rob...@raszuk.net <mailto:rob...@raszuk.net>> >> Date: Friday, July 8, 2022 at 4:36 PM >> To: Acee Lindem <a...@cisco.com <mailto:a...@cisco.com>> >> Cc: lsr <l...@ietf.org <mailto:l...@ietf.org>>, IDR List <i...@ietf.org >> <mailto:i...@ietf.org>>, Susan Hares <sha...@ndzh.com >> <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/ >> <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 >> <mailto:a...@cisco.com>> wrote: >> >> Speaking as WG chair: >> >> >> >> From: Lsr <lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>> on behalf of >> Robert Raszuk <rob...@raszuk.net <mailto:rob...@raszuk.net>> >> Date: Friday, July 8, 2022 at 3:21 PM >> To: lsr <l...@ietf.org <mailto:l...@ietf.org>> >> Cc: IDR List <i...@ietf.org <mailto:i...@ietf.org>>, Susan Hares >> <sha...@ndzh.com <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: >> >> >> >> https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/ >> <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 <mailto:i...@ietf.org> >> https://www.ietf.org/mailman/listinfo/idr >> <https://www.ietf.org/mailman/listinfo/idr> >> _______________________________________________ >> GROW mailing list >> GROW@ietf.org <mailto:GROW@ietf.org> >> https://www.ietf.org/mailman/listinfo/grow >> <https://www.ietf.org/mailman/listinfo/grow> >> -- >> >> <http://www.verizon.com/> >> Gyan Mishra >> >> Network Solutions Architect >> >> Email gyan.s.mis...@verizon.com <mailto:gyan.s.mis...@verizon.com> >> M 301 502-1347 >> >> >> >> _______________________________________________ >> Idr mailing list >> i...@ietf.org <mailto:i...@ietf.org> >> https://www.ietf.org/mailman/listinfo/idr >> <https://www.ietf.org/mailman/listinfo/idr> >> >> > > _______________________________________________ > 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
