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

[Robert Raszuk <[e-mail]>]

Tony,


> a) configuration is already standardized via NETCONF WG/channels/methods.
> pulling it via this seems redundant.
>

It is optional.


> b) YANG is already pulled via other channels so I see little value of
> pulling it here. same as a) basically
>

Please enumerate what channels ? And in the same time please indicate why
those channels are not good enough such that we need to keep stuffing BGP
protocol with the IGP, SR, Detnet etc .. data.



> c) adding all those "sync" via SNP is basically building a flooding peer
> again as far I can deduct having flown quickly over the draft. Doing that
> over QUIC/TCP is a bad idea due to head-on blocking problems well known
> with flooding. if the consumer cannot keep up with the real stream the
> sender can only start to throw away stuff or reset the session practically
> speaking
>

IMP is NOT doing flooding. If you think that control plane with 100s of CPU
cores will be slower in accepting your RE generated streams please kindly
reconsider.

But if the rate of data change would be a problem we would already choke
with TCP based BGP-LS. So not sure what problem are you seeing. Are you
referring to one interface flood mirroring ? For debugging it either be
nicely packed and sent or screen scraped. Which one do you prefer ?

d) beats me why you would want this to carry BGP-LS again if y6ou can
> simply run another session/BGP instance on any good implementation today.
>

beats me why would ever want to keep polluting BGP protocol like this. Are
you saying that IGP can not open a TCP socket or setup a QUIC session ? Is
it too much to ask ? Too complex ?


> Given all the big wishlist included in the draft protocol needs probably
> something to negotiate WHAT of all the whole panopticum the producer can
> support unless it's somehow in the PUB/SUB (but then again, this probably
> needs mode negotiation as well given the plethora of possibilities there).
>

Please kindly observe what is mandatory and what is optional. Also kindly
notice the split between Producer and Producer's Proxy.

Thx,
R.






>
> -- tony
>
> On Mon, Jul 11, 2022 at 4:54 PM Tianran Zhou <zhoutianran=
> [e-mail]> 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<[e-mail]>
>> *收件人： *Tianran Zhou<[e-mail]>
>> *抄送： *Yingzhen Qu<[e-mail]>;idr<[e-mail]>;grow<
>> [e-mail]>;lsr<[e-mail]>
>> *主题： *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 <[e-mail]>
>> 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<[e-mail]>
>>> *收件人： *Yingzhen Qu<[e-mail]>
>>> *抄送： *idr<[e-mail]>;grow<[e-mail]>;lsr<[e-mail]>
>>> *主题： *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 <[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
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
>