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

Hi Acee

Responses in-line

On Mon, Jul 11, 2022 at 10:44 AM Acee Lindem (acee) <acee@cisco.com> wrote:

> Hi Gyan,
>
>
>
> *From: *GROW <grow-bounces@ietf.org> on behalf of Gyan Mishra <
> hayabusagsm@gmail.com>
> *Date: *Monday, July 11, 2022 at 1:41 AM
> *To: *Yingzhen Qu <yingzhen.ietf@gmail.com>
> *Cc: *IDR List <idr@ietf.org>, "grow@ietf.org grow@ietf.org" <
> grow@ietf.org>, lsr <lsr@ietf.org>
> *Subject: *Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol
>
>
>
> Hi Yingzhen
>
>
>
> So with OSPFV2 using RFC 6549 would support multiple instances or OSPFV3
> already supports instances, how is the GT instance differentiated from any
> other routed instance?
>
>
>
> Did you read the draft? The main difference is that since OSPF-GT is
> generalized to be used for non-routing, there is installation of routes.
>
    Gyan> So The routes would be application use case specific “non
routing” routes for example for BGP-LS it would be the related LSDB data
that maybe similar data formatting as in RFC 7752 or new formatting
described in separate draft.  The other possible use cases it’s “non
routing” use cases, however in the BGP-LS case it is routing related info,
not “non routing” related, so would this really be a good solution for
BGP-LS?  I am thinking maybe not.

> OSPF-GT neighbors need not be directly attached (or come with complex OSPF
> Virtual-Link considerations and processing). Depending on the application,
> the extent to which the “condition of reachability” is enforced MUST be
> described in the document describing the application usage of OSPF-GT.
>
>  Gyan> Understood.  So BGP-LS is a possible use case however those details
> would  be in another draft.
>
>
>
> For OSPFV2 it would use Opaque LSA Type 9,10,21 similar to RSVP-TE with an
> opaque option code for GTI.
>
>
>
> For OSPFV3 it would use an OSPFV3 function code for GTI.
>
>
>
> So the NBI BGP-LS peering to the PCE/SDN controller would be replaced with
> a   OSPF GTI neighbor ?
>
>
>
> It could be but that is just one OSPF-GT use case and would need to be
> described in a separate draft.
>

   Gyan> Understood

>
>
> Would you still need a standard routed OSPF neighbor for reachability or I
> guess you could put a static route on the controller across the NBI for
> reachability.
>
>
>
> Yes
>
    Gyan> Got it

>
>
> Is that correct?
>
>
>
> Are there any operators implementations of this using OSPF GTI in place of
> BGP-LS?
>
>
>
> You mean OSPF-GT… Since the draft to describe the details of using OSPF-GT
> in place of BGP-LS is yet to be written, it would be very strange indeed if
> it were already deployed. 😉
>
> Gyan> Understood
>
> RFC 6823 provides the same GTI solution for ISIS.
>
>
>
> Yes and no, OSPF-GT is able to cover a much wider range of applications
> than RFC 683. This is due mostly to OSPF (and especially OSPFv3 with
> extended LSAs) being much more flexible than IS-IS.
>

    Gyan> So could OSPF-GT provide the link state for ISIS instead of using
RFC 6823.

>
>
>
>
> Are there any operators implementations of this using OSPF GTI in place of
> BGP-LS?
>
>
>
> No - answered above.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Sun, Jul 10, 2022 at 1:04 AM Yingzhen Qu <yingzhen.ietf@gmail.com>
> 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 <hayabusagsm@gmail.com> 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 <shares@ndzh.com> 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 <jefftant.ietf@gmail.com>
> *Sent:* Saturday, July 9, 2022 3:40 PM
> *To:* Robert Raszuk <robert@raszuk.net>
> *Cc:* Acee Lindem (acee) <acee@cisco.com>; lsr <lsr@ietf.org>;
> idr@ietf.org; Susan Hares <shares@ndzh.com>; grow@ietf.org grow@ietf.org <
> grow@ietf.org>
> *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 <robert@raszuk.net> 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) <acee@cisco.com> wrote:
>
> Hi Robert,
>
>
>
> *From: *Robert Raszuk <robert@raszuk.net>
> *Date: *Friday, July 8, 2022 at 4:36 PM
> *To: *Acee Lindem <acee@cisco.com>
> *Cc: *lsr <lsr@ietf.org>, IDR List <idr@ietf.org>, Susan Hares <
> shares@ndzh.com>
> *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) <acee@cisco.com> wrote:
>
> Speaking as WG chair:
>
>
>
> *From: *Lsr <lsr-bounces@ietf.org> on behalf of Robert Raszuk <
> robert@raszuk.net>
> *Date: *Friday, July 8, 2022 at 3:21 PM
> *To: *lsr <lsr@ietf.org>
> *Cc: *IDR List <idr@ietf.org>, Susan Hares <shares@ndzh.com>
> *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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*