Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

[Robert Raszuk <[e-mail]>]

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