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 <[email protected]> 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) <[email protected] > <mailto:[email protected]>> wrote: > Hi Robert, > > > > From: Lsr <[email protected] <mailto:[email protected]>> on behalf of > Robert Raszuk <[email protected] <mailto:[email protected]>> > Date: Sunday, July 10, 2022 at 1:32 PM > To: Yingzhen Qu <[email protected] <mailto:[email protected]>> > Cc: Gyan Mishra <[email protected] <mailto:[email protected]>>, Susan > Hares <[email protected] <mailto:[email protected]>>, IDR List <[email protected] > <mailto:[email protected]>>, "[email protected] <mailto:[email protected]> [email protected] > <mailto:[email protected]>" <[email protected] <mailto:[email protected]>>, lsr > <[email protected] <mailto:[email protected]>> > 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> > Sent: Saturday, July 9, 2022 3:40 PM > To: Robert Raszuk <[email protected] <mailto:[email protected]>> > Cc: Acee Lindem (acee) <[email protected] <mailto:[email protected]>>; lsr > <[email protected] <mailto:[email protected]>>; [email protected] <mailto:[email protected]>; > Susan Hares <[email protected] <mailto:[email protected]>>; [email protected] > <mailto:[email protected]> [email protected] <mailto:[email protected]> <[email protected] > <mailto:[email protected]>> > 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 <[email protected] > <mailto:[email protected]>> 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) <[email protected] > <mailto:[email protected]>> wrote: > > Hi Robert, > > > > From: Robert Raszuk <[email protected] <mailto:[email protected]>> > Date: Friday, July 8, 2022 at 4:36 PM > To: Acee Lindem <[email protected] <mailto:[email protected]>> > Cc: lsr <[email protected] <mailto:[email protected]>>, IDR List <[email protected] > <mailto:[email protected]>>, Susan Hares <[email protected] > <mailto:[email protected]>> > 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) <[email protected] > <mailto:[email protected]>> wrote: > > Speaking as WG chair: > > > > From: Lsr <[email protected] <mailto:[email protected]>> on behalf of > Robert Raszuk <[email protected] <mailto:[email protected]>> > Date: Friday, July 8, 2022 at 3:21 PM > To: lsr <[email protected] <mailto:[email protected]>> > Cc: IDR List <[email protected] <mailto:[email protected]>>, Susan Hares > <[email protected] <mailto:[email protected]>> > 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 > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/idr > <https://www.ietf.org/mailman/listinfo/idr> > _______________________________________________ > GROW mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/grow > <https://www.ietf.org/mailman/listinfo/grow> > -- > > <http://www.verizon.com/> > Gyan Mishra > > Network Solutions Architect > > Email [email protected] <mailto:[email protected]> > M 301 502-1347 > > > > _______________________________________________ > Idr mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/idr > <https://www.ietf.org/mailman/listinfo/idr> > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
