Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Peter Psenak writes: On 26/01/2022 10:40, Robert Raszuk wrote: > The pulse solution does not suffer from the scale issues. It shifts that "suffering" to flood the entire domain with information which is not needed on P routers and selectively useful on the remote PEs. yes, but how much

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Tony, On 26/01/2022 16:46, Tony Li wrote: Peter, The pulse solution does not suffer from the scale issues. It shifts that "suffering" to flood the entire domain with information which is not needed on P routers and selectively useful on the remote PEs. yes, but how much data? Minimal.

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Peter, >> > The pulse solution does not suffer from the scale issues. >> It shifts that "suffering" to flood the entire domain with information which >> is not needed on P routers and selectively useful on the remote PEs. > > yes, but how much data? Minimal. It's not an issue, no matter how

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

On 26/01/2022 10:40, Robert Raszuk wrote: > The pulse solution does not suffer from the scale issues. It shifts that "suffering" to flood the entire domain with information which is not needed on P routers and selectively useful on the remote PEs. yes, but how much data? Minimal. It's not

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

> The pulse solution does not suffer from the scale issues. It shifts that "suffering" to flood the entire domain with information which is not needed on P routers and selectively useful on the remote PEs. Also fast signaling the fact that PE may have been disconnected from the network for a few

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Tony, On 25/01/2022 17:11, Tony Li wrote: Peter, we just moved the problem from IGPs to some "other" application. That was the entire point. Hopefully, you see that as a good thing. actually I don't. I want to solve the problem, not to move it to other app running on the same nodes.

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Tony, If a given PE needs to get all notifications from all other PEs it is > sufficient that it sends to local ABRs a single registration in a form of > 0.0.0.0/0 and be done. > > > If you look a bit more carefully, you will find that registering for 0/0 > doesn’t work without a bit more

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Robert, > If a given PE needs to get all notifications from all other PEs it is > sufficient that it sends to local ABRs a single registration in a form of > 0.0.0.0/0 and be done. If you look a bit more carefully, you will find that registering for 0/0 doesn’t work

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Peter, > we just moved the problem from IGPs to some "other" application. That was the entire point. Hopefully, you see that as a good thing. Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

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 *On Behalf Of *Tony Li > *Sen

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

; lsr 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 n

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

rg (ginsberg) > *Cc:* lsr > *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

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

to support. Not the same thing as what you are proposing here. Les From: Tony Li On Behalf Of Tony Li Sent: Monday, January 24, 2022 12:12 PM To: Les Ginsberg (ginsberg) Cc: lsr Subject: Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt Les, My precedent is the use Router

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

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Tony – Inline. From: Tony Li On Behalf Of Tony Li Sent: Monday, January 24, 2022 10:15 AM To: Les Ginsberg (ginsberg) Cc: lsr Subject: Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt Hi Les, Thank you for commenting. I am not enthused about this solution. Full mesh

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Les, Thank you for commenting. > I am not enthused about this solution. Full mesh isn’t appealing at scale. > But I recognize this as an alternative which some might find useful in some > deployments. Is it clear that the full mesh is only at the ABR level? > I also understand why and

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Indeed. If you have unreliable registrations, and a registration is lost, then subsequent notifications would be lost as well. The entire service could yield no results. What is the use case? On the bright side, you can always claim that the service is already deployed and you just happened

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Yours is a good operational point, Robert. I wonder what others might think. Regards, Greg On Mon, Jan 24, 2022 at 9:30 AM Robert Raszuk wrote: > > Are you sure this is operationally a good idea ? > > It's cool when registrations and up notifications will not get lost. But I > would not like

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Are you sure this is operationally a good idea ? It's cool when registrations and up notifications will not get lost. But I would not like to be the one troubleshooting a network when some registrations or up notifications packets get lost ... It sounds like a nightmare to me. Best, R. On Mon,

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Frankly, I don't see that registrations, at least for the node liveness use case, require using reliable transport. If the registration is lost, the faster convergence doesn't work for that node but the existing slower mechanism still does the job done. I want to note that I'm not proposing

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Robert, thank you for clearly stating the question I was implying - Is the reliable distribution of notifications a requirement or recommendation? I think it is the latter. In some scenarios and use cases, for example, when the pub-sub provides the critical service that doesn't have a backup

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Greg, > thank you for your responses to my notes. I should have been more clear in > explaining the rationale for adding the UDP transport option to the list. > Reliability comes at a cost. If the system already has a mechanism that > guarantees convergence a faster, lightweight though not

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Greg, Granted you are correct, but only if we consider p2p distribution and low level triggers. You are also correct if we would just be continue to use PULSE style. But Tony's proposal is fundamentally different. It does not send PULSE and forgets. It distributed node liveness both down and

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Tony and Robert, thank you for your responses to my notes. I should have been more clear in explaining the rationale for adding the UDP transport option to the list. Reliability comes at a cost. If the system already has a mechanism that guarantees convergence a faster, lightweight though not

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Greg, > I got to think about the benefits of using reliable transport for > notifications. If I understand the use case correctly, the proposed mechanism > allows for a faster convergence but is supplemental to slower BGP > convergence. If that is the case, it seems that if a subscriber to

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Gyan, > So basically the event notification process done in PUAM / Pulse inband, here > we are using an out-of-band transport protocol QUIC / TCP for the Publisher > RDB registration DB service on the ABRs which advertises the node liveliness > service into the L1 and L2 areas for

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Greg, Thank you for your suggestions. > It seems that referencing the multi-hop BFD [RFC5883] in the Introduction > section as the existing mechanism detecting the node liveness can make the > document more thorough. While I have no objection to being thorough, being that thorough would

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Aijun, > [WAJ] Then I think it is not the subject that the LSR should discuss. There > are many modules on the routers. They may all relevant to the IGP modules. > You are trying to accomplish the work that has been done via the management > system, for example

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi, Tony: From: tony1ath...@gmail.com On Behalf Of Tony Li Sent: Thursday, January 20, 2022 11:23 PM To: Aijun Wang Cc: lsr Subject: Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt Hi Aijun, You are proposing to use the Out of Band channel to solve the IGP

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Sounds good. Thx, R. On Thu, Jan 20, 2022 at 6:23 PM Tony Li wrote: > > Hi Robert, > > While perhaps pretty obvious, it would be good to also highlight what > implementation should do in the event of covering prefix changes in the > LSDB if those are to happen after registrations have already

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Robert, > While perhaps pretty obvious, it would be good to also highlight what > implementation should do in the event of covering prefix changes in the LSDB > if those are to happen after registrations have already gone out. Maybe as > simple as de-register and re-register for the new

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Tony, > You mean to show up in registration ? I guess there could be a triggering > threshold with some wisely chosen % of the min. number of host routes in > the summaries to avoid too much noise. > > That seems like a difficult condition to explain. How do you feel about > just always

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Robert, > Ok, this was the intent already. The current text says: > >If an ABR receives a Registration Message for a prefix that is being >injected by a non-attached area, then it should determine the set of >ABRs that are advertising that prefix or less specifics and register >

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Robert, From: Robert Raszuk Date: Thursday, January 20, 2022 at 10:23 AM To: Acee Lindem Cc: Aijun Wang , lsr , Tony Li Subject: Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt Hi Acee, > I’d consider this out-of-band signaling with respect to the IGP as w

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Aijun, > You are proposing to use the Out of Band channel to solve the IGP problem. > There are already existing such channel, why we bother IGP to establish new > one? You’re missing the point completely. I’m proposing an entirely new subsystem. That’s architecturally necessary. One

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

20, 2022 at 4:01 PM Acee Lindem (acee) wrote: > Hi Robert, > > > > > > *From: *Lsr on behalf of Robert Raszuk < > rob...@raszuk.net> > *Date: *Thursday, January 20, 2022 at 4:59 AM > *To: *Aijun Wang > *Cc: *lsr , Tony Li > *Subject: *Re: [Lsr] New Ver

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Robert, From: Lsr on behalf of Robert Raszuk Date: Thursday, January 20, 2022 at 4:59 AM To: Aijun Wang Cc: lsr , Tony Li Subject: Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt [WAJ] The exact description should be “It proposes to use IGP establishing the out

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

> > [WAJ] The exact description should be “It proposes to use IGP establishing > the out of band channel to deliver the PUB/SUB information” > Sorry - no. You seem to be locking IGPs to flooding based transport only. Anything else you call "out of band" - I do not subscribe to this. Many thx,

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

ve >> notification information unless you do some filter action on the ABRs. >> >> Then what the advantages that your proposal when compared to the PUA/PULSE >> solution? >> >> >> >> >> >> Best Regards >> >> >> >

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

t; solution? > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* tony1ath...@gmail.com *On Behalf Of *Tony > Li > *Sent:* Thursday, January 20, 2022 12:19 AM > *To:* Aijun Wang > *Cc:* lsr > *Subject:* Re: [Lsr] Ne

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Tony, Ok, this was the intent already. The current text says: > >If an ABR receives a Registration Message for a prefix that is being >injected by a non-attached area, then it should determine the set of >ABRs that are advertising that prefix or less specifics and register >

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Robert, > Let me perhaps illustrate in two examples what I had in mind. I actually do > see immediate benefit to include it day one both in the spec and in the > protocol: > > *A* ABR locally (from it's own area) received registration requests for 100 > /32s next hops. It knows from

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Tony, > Do you envision any form of aggregation to happen in the messaging > between ABRs (for both registrations and notifications) ? > > Well, as always, I try to generalize mechanisms and solutions. So while I > don’t see an immediate need or benefit to it, I did write the protocol so >

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

> On Jan 19, 2022, at 11:38 AM, Tony Przygienda wrote: > > As only observation, if we do this service as suggested I would like to see > not only port & protocol but also the according address of the endpoint > (since it's really that is the SSAP here. > Operationally it's very often

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Robert, > Do you envision any form of aggregation to happen in the messaging between > ABRs (for both registrations and notifications) ? Well, as always, I try to generalize mechanisms and solutions. So while I don’t see an immediate need or benefit to it, I did write the protocol so

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Aijun, > If we use pub/sub mechanism, why don’t we accomplish it via the management > system, or controller? > No IGP extension needed then. As I recall, you are the one who posed the original problem. If a centralized solution works for you, then that’s certainly fine by me. > Also no