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

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> 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<[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 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 <[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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>