Hi Les, I think using IGP to *discover* some services is perfectly fine.
For example many years ago I proposed to use IGP to automatically discover BGP route reflectors for the sole purpose of bgp auto discovery. After that originally BGP friends suggested that we will do faster if we do not touch IGP so I moved the proposal to be fully BGP based. However very recently I see new requirements popping up to also support it with IGP. I guess for you this would be a "service or an application" and would meet resistance - understand that opinion. Here however we are talking about so tiny information to be added to IGP to help with seamless operation that frankly I do not understand your resistance at all. Modulo so heavy commitment to PULSE of course which this proposal could freeze. > The service itself doesn’t even need to be running on a router at all. That is true. But for the service to be efficient it should at least listen to the local area IGP to listen to LSAs/LSPs. Now of course discovery of this "server" can be realized out of band (say by CLI). But it beats me why we would not support auto discovery of such a service if it happens to run on an IGP node. What harm would such additional discovery do to the LSDB, CPU, memory, traffic ??? Kind regards, Robert On Mon, Jan 24, 2022 at 10:11 PM Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > Robert – > > > > Please read more carefully. > > > > The draft introduces “a protocol(service) that will provide prompt > notification of changes in node liveness…” > > What I am talking about here is NOT the information being sent by the > service – but rather the service itself. Advertisement of the > existence/location of that service is not within the purview of the IGP. > > That’s all I am saying… > > > > If you don’t like my use of the word “application” feel free to replace it > with “service”. Whatever it is, it is not the IGP itself. The iGP hasn’t > been extended to do anything – in fact that is one of the points of Tony’s > proposal since he doesn’t think the IGP should be in the business of > sending node liveness information. > > The service itself doesn’t even need to be running on a router at all. > > > > Les > > > > > > *From:* Robert Raszuk <rob...@raszuk.net> > *Sent:* Monday, January 24, 2022 12:33 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* Tony Li <tony...@tony.li>; lsr <lsr@ietf.org> > *Subject:* Re: [Lsr] New Version Notification for > draft-li-lsr-liveness-00.txt > > > > Hi Les, > > > > > Advertisement of the availability of an application is not within the > scope of an IGP > > > > Who proposes that ? > > > > AFAIK protocol Tony proposed indicates livness of an IGP node and > specifically not any application on that node. > > > > Thx, > R. > > > > > > > > > > On Mon, Jan 24, 2022 at 9:24 PM Les Ginsberg (ginsberg) <ginsberg= > 40cisco....@dmarc.ietf.org> wrote: > > Tony – > > > > Advertisement of the availability of an application is not within the > scope of an IGP no matter what level of TLV you use to do so. > > > > Existing capability advertisements (e.g., flex-algo participation, SR ) > are indicators of what the IGP implementation supports and/or is configured > to support. Not the same thing as what you are proposing here. > > > > Les > > > > > > *From:* Tony Li <tony1ath...@gmail.com> *On Behalf Of *Tony Li > *Sent:* Monday, January 24, 2022 12:12 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* lsr <lsr@ietf.org> > *Subject:* Re: [Lsr] New Version Notification for > draft-li-lsr-liveness-00.txt > > > > > > Les, > > > > > > My precedent is the use Router Capability for advertising FlexAlgo > definitions. This is a service being provided by the area and it seems > equally relevant. Would you prefer a top level TLV? > > > > *[LES:] Flex Algo is a routing calculation being performed by the IGPs who > also advertise the algorithm specific attributes and algorithm specific > forwarding identifiers.* > > *I don’t see what you are doing as analogous.* > > > > > > Well, IMHO, I can understand the participation of the router in an algo as > a capability. The definition of the algo seems to be somewhat orthogonal. > But it’s there anyway. Similarly, the capability of node liveness is pretty > clear. Yes, the service access point information is orthogonal. > > > > You didn’t respond: Would you prefer a top level TLV? That would the > logical alternative. > > > > Tony > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
