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

[Robert Raszuk <[e-mail]>]

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
>
>
>
>