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 Mon, Jul 11, 2022 at 5:34 PM Tianran Zhou <zhoutian...@huawei.com> wrote: > 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 > > > > > ------------------------------ > > Sent from WeLink > *发件人： *Robert Raszuk<rob...@raszuk.net> > *收件人： *Tianran Zhou<zhoutian...@huawei.com> > *抄送： *Yingzhen Qu<yingzhen.i...@gmail.com>;idr<i...@ietf.org>;grow< > g...@ietf.org>;lsr<lsr@ietf.org> > *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol > *时间： *2022-07-11 23:05:56 > > 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 include as > this is already reflected in the LSDB. > > I will take a more detail read of your spec. Then we can talk if there is > some overlap or both approaches are so different then it makes sense to > progress both. One size does not fit all :) > > Best, > R. > > > > > On Mon, Jul 11, 2022 at 4:54 PM Tianran Zhou <zhoutian...@huawei.com> > wrote: > >> 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 WeLink >> *发件人： *Robert Raszuk<rob...@raszuk.net> >> *收件人： *Tianran Zhou<zhoutian...@huawei.com> >> *抄送： *Yingzhen Qu<yingzhen.i...@gmail.com>;idr<i...@ietf.org>;grow< >> g...@ietf.org>;lsr<lsr@ietf.org> >> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol >> *时间： *2022-07-11 22:05:31 >> >> 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 - point to point >> routing information distribution, protocol observability and enhanced >> operations. It also needs to be highlighted that BMP (while it >> technically could) does not use native BGP sessions to propagate such >> information, but is running a separate transport. IMP authors have >> chosen to reuse selected BMP building blocks and BMP operational and >> deployment experience. >> >> >> >> Many thx, >> R. >> >> On Mon, Jul 11, 2022 at 4:02 PM Tianran Zhou <zhoutian...@huawei.com> >> 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> >>> *收件人： *Yingzhen Qu<yingzhen.i...@gmail.com> >>> *抄送： *idr<i...@ietf.org>;grow<g...@ietf.org>;lsr<lsr@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> >>> 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> 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> >>>> wrote: >>>> >>>>> Hi Robert, >>>>> >>>>> >>>>> >>>>> *From: *Lsr <lsr-boun...@ietf.org> on behalf of Robert Raszuk < >>>>> rob...@raszuk.net> >>>>> *Date: *Sunday, July 10, 2022 at 1:32 PM >>>>> *To: *Yingzhen Qu <yingzhen.i...@gmail.com> >>>>> *Cc: *Gyan Mishra <hayabusa...@gmail.com>, Susan Hares < >>>>> sha...@ndzh.com>, IDR List <i...@ietf.org>, "g...@ietf.org >>>>> g...@ietf.org" <g...@ietf.org>, lsr <lsr@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: >>>>> >>>>> >>>>> >>>>> 1. 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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 1. 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> >>>>> 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/ >>>>> >>>>> >>>>> >>>>> 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> 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> 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 >>>>> >>>>> -- >>>>> >>>>> [image: Image removed by sender.] <http://www.verizon.com/> >>>>> >>>>> *Gyan Mishra* >>>>> >>>>> *Network Solutions Architect * >>>>> >>>>> *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* >>>>> >>>>> *M 301 502-1347* >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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
