Chris, Of course there are more prefixes then PEs in the IGP.
But I understood as in the light of this discussion some folks attempted to say that you can trim that set even more. So for the purpose of the topic I would rather call them as service endpoint nodes and do not attempt to make an impression that only some of them are important. That includes all PEs or PEs & Segment endpoints. Thx, R. On Mon, Jan 24, 2022 at 11:31 AM Christian Hopps <[email protected]> wrote: > > Robert Raszuk <[email protected]> writes: > > > Chris, > > > > I would like to state one important point ... > > > > Some folks used terms "for those special prefixes" or "super > > important prefixes" only to smooth the discussion. But there is not > > such a thing. All what is being discussed is all PEs. Some want to > > also add SR segment endpoints. > > > > No one will be selecting a subset of the above. That's even more > > drastic for the PUA/PULSE approach as it inherently contains a cliff > > effect. > > There are plenty more prefixes in an IGP domain than just PE loopbacks. > For example, all the internal networks, and those are great candidates for > summarization. > > We've been calling out these "important prefixes" for quite a while (and > w/o the need for summarization) -- this is why we added admin tags way back > when, to be able to identify "important" prefixes so e.g., routers could > give them higher priority for insertion in their FIB, etc.. > > Thanks, > Chris. > > > > > Thx, > > R. > > > > > > > > > > > > > > > > > > > > > > On Mon, Jan 24, 2022 at 10:40 AM Christian Hopps <[email protected]> > > wrote: > > > > > > "Aijun Wang" <[email protected]> writes: > > > > > Hi, Chris: > > > We should notice here that it is not "a prefix", it's possible > > for "all node's loopback address, or even some link's address". > > > Gyan's reference for RFC5302 state clearly the disadvantage of > > > non-summarization, and the operators have followed this > > approach also about 20 > > > years, then you just propose to divert to another direction? > > > > > > > For 20 years we haven't needed PUA/PULSE, now your saying we do, > > so I'm saying don't use summarization *for these special prefixes > > it suddenly doesn't work for*. > > > > I have *never* said do not use summarization. I've have tried > > very hard to say very clearly "for those special prefixes" every > > time I have responded to this thread. It's very frustrating. > > > > I'm saying do not summarize these "super important prefixes" -- > > these prefixes you want to modify the summarization process > > because summarization doens't work for them" > > > > Again KISS applies here: > > > > If the summarization process *doesn't work* for a given > > prefix P, then *don't use summarization* for prefix P! > > > > Thanks, > > Chris. > > [As wg member] > > > > > Best Regards > > > > > > Aijun Wang > > > China Telecom > > > > > > -----Original Message----- > > > From: Christian Hopps <[email protected]> > > > Sent: Monday, January 24, 2022 1:50 PM > > > To: Gyan Mishra <[email protected]> > > > Cc: Christian Hopps <[email protected]>; Aijun Wang < > > [email protected]>; > > > Hannes Gredler <[email protected]>; John E Drake < > > [email protected]>; Les > > > Ginsberg (ginsberg) <[email protected]>; Peter Psenak > > (ppsenak) > > > <[email protected]>; Robert Raszuk <[email protected]>; > > Shraddha Hegde > > > <[email protected]>; Tony Li <[email protected]>; lsr < > > [email protected]> > > > Subject: Re: [Lsr] BGP vs PUA/PULSE > > > > > > > > > Ok, I guess I'll repeat what I said, as I don't believe > > anything new was presented here. > > > > > > Yes, having worked intimately with these IGPs for > 20 > > years now, > > > I understand the use and the implications of using summary > > > routes. :) > > > > > > My opinion remains unchanged. > > > > > > "If a prefix is important enough to consider seriously hacking > > the routing > > > protocol to signal the prefix being unreachable, then that > > prefix is important > > > enough to not summarize to begin with." IOW; KISS > > > > > > I'd prefer to not keep repeating this when presented with the > > same arguments, so please take any silence on my part as my > > opinion being unchanged. > > > > > > Thanks, > > > Chris. > > > [As WG member] > > > > > > > > > > > > Gyan Mishra <[email protected]> writes: > > > > > >> Hi Chris > > >> > > >> > > >> Just about every vendor out there recommended best practice is > > to > > >> layout address plan to take advantage of summarization > > wherever > > >> possible and that as well includes PE loopback next hop > > attribute to > > >> limit the router load as well as size of LSDB in the backbone > > as well > > >> as domain wide. > > >> > > >> I think you would be hard pressed to find any vendor that > > would say go > > >> ahead and flood loopbacks domain wide and don’t summarize. > > >> > > >> In large domains flooding domain wide is not feasible and > > >> summarization is requirement even for the critical loopback > > BGP next > > >> hops for most operators. > > >> > > >> RFC 5302 talks about the ramifications of flooding in ISIS > > domain in > > >> section 1.2 excerpt below: > > >> > > >> > > >> 1.2. Scalability > > >> > > >> The disadvantage to performing the domain-wide prefix > > distribution > > >> described above is that it has an impact on the scalability > > of IS-IS. > > >> Areas within IS-IS help scalability in that LSPs are > > contained within > > >> a single area. This limits the size of the link state > > database, > > >> which in turn limits the complexity of the shortest path > > computation. > > >> > > >> Further, the summarization of the prefix information aids > > scalability > > >> in that the abstraction of the prefix information removes > > the sheer > > >> number of data items to be transported and the number of > > routes to be > > >> computed. > > >> > > >> It should be noted quite strongly that the distribution of > > prefixes > > >> on a domain-wide basis impacts the scalability of IS-IS in > > the second > > >> respect. It will increase the number of prefixes > > throughout the > > >> domain. This will result in increased memory consumption, > > >> transmission requirements, and computation requirements > > throughout > > >> the domain. > > >> > > >> It must also be noted that the domain-wide distribution of > > prefixes > > >> has no effect whatsoever on the first aspect of > > scalability, namely > > >> the existence of areas and the limitation of the > > distribution of the > > >> link state database. > > >> > > >> > > >> > > >> > > >> Gyan > > >> On Fri, Jan 14, 2022 at 9:07 PM Christian Hopps < > > [email protected]> > > >> wrote: > > >> > > >> Yes, having worked intimately with these IGPs for > 20 > > years now, > > >> I understand the use and the implications of using summary > > >> routes. :) > > >> > > >> My opinion remains unchanged. > > >> > > >> Thanks, > > >> Chris. > > >> [as wg member] > > >> > > >> > On Jan 14, 2022, at 8:50 PM, Aijun Wang < > > >> [email protected]> wrote: > > >> > > > >> > Hi, Christian: > > >> > > > >> > We should consider the balance and efficiency for the > > summary > > >> or not summary. > > >> > If you don’t summary, then all the areas will be filled > > with > > >> the specified detail routes(all PE’s loopback, may also > > include > > >> all P’s loopback). This can certainly increase the burden > > of the > > >> routers. > > >> > > > >> > But with summary, all these specific routes need not > > exist in > > >> the routing table. The nodes within the IGP need only be > > notified > > >> when one node is failure to accelerate the switchover of > > the > > >> overlay service. > > >> > And, you can also select to not using such mechanism, > > then the > > >> service will be backhole for some time until the service/ > > >> application find this abnormal phenomenon. > > >> > PUA/PULSE are just the mechanism to reduce the abnormal > > >> durations, it is one kind of FRR technique. > > >> > > > >> > Aijun Wang > > >> > China Telecom > > >> > > > >> >> On Jan 15, 2022, at 09:26, Christian Hopps < > > [email protected]> > > >> wrote: > > >> >> > > >> >> > > >> >> > > >> >>> On Jan 14, 2022, at 8:25 PM, Christian Hopps < > > >> [email protected]> wrote: > > >> >>> > > >> >>> I understand the proposal. As I've stated elsewhere, I > > do not > > >> believe there is a problem here that needs solving. The > > "problem" > > >> was created by the user by summarizing prefixes that > > should not > > >> have been summarized -- they mis-configured their network. > > The > > >> routing protocols works just fine (act very quickly) if > > you don't > > >> incorrectly summarize "really important prefixes". > > >> >>> > > >> >>> I was simply pointing out that IGPs also don't deal in > > >> liveness since that keeps coming up. > > >> >> > > >> >> Sorry that was "as wg member". > > >> >> > > >> >>> > > >> >>> Thanks, > > >> >>> Chris. > > >> >>> > > >> >>>>> On Jan 14, 2022, at 8:06 PM, Aijun Wang < > > >> [email protected]> wrote: > > >> >>>> > > >> >>>> Hi, Christian and John: > > >> >>>> > > >> >>>> No. I think you all may misunderstand the proposal. > > What we > > >> are detecting is actually the reachability/liveness of > > node that > > >> connected to the application, not the application itself. > > >> >>>> And, I think the node liveness is same as the node > > >> reachability. They will all influence or break the path to > > their > > >> connected service if their forwarding function is failed. > > >> >>>> > > >> >>>> Aijun Wang > > >> >>>> China Telecom > > >> >>>> > > >> >>>>> On Jan 15, 2022, at 08:56, Christian Hopps < > > >> [email protected]> wrote: > > >> >>>>> > > >> >>>>> Indeed, and in fact the IGP should only be dealing > > with the > > >> reachability to the node, not with the node or > > applications > > >> liveness. > > >> >>>>> > > >> >>>>> Thanks, > > >> >>>>> Chris. > > >> >>>>> [as wg member] > > >> >>>>> > > >> >>>>>> On Jan 14, 2022, at 7:47 PM, John E Drake < > > >> [email protected]> wrote: > > >> >>>>>> > > >> >>>>>> I don’t think so. Today things just work, at a > > given time > > >> scale. What you said you are trying to do is reduce the > > time > > >> scale for detecting that an application on a node has > > failed. > > >> However, conflating the health of a node with the health > > of an > > >> application on that node seems to be inherently flawed. > > >> >>>>>> > > >> >>>>>> Yours Irrespectively, > > >> >>>>>> > > >> >>>>>> John > > >> >>>>>> > > >> >>>>>> > > >> >>>>>> Juniper Business Use Only > > >> >>>>>> From: Aijun Wang <[email protected]> > > >> >>>>>> Sent: Friday, January 14, 2022 7:40 PM > > >> >>>>>> To: John E Drake <[email protected]> > > >> >>>>>> Cc: Les Ginsberg (ginsberg) <[email protected]>; > > Robert > > >> Raszuk <[email protected]>; Christian Hopps < > > [email protected]>; > > >> Shraddha Hegde <[email protected]>; Tony Li < > > [email protected]>; > > >> Hannes Gredler <[email protected]>; lsr <[email protected]>; > > Peter > > >> Psenak (ppsenak) <[email protected]> > > >> >>>>>> Subject: Re: [Lsr] BGP vs PUA/PULSE > > >> >>>>>> > > >> >>>>>> [External Email. Be cautious of content] > > >> >>>>>> > > >> >>>>>> When the node is up, all the following process are > > passed > > >> to the application layer. This is the normal procedures of > > the > > >> IGP should do. > > >> >>>>>> According to your logic, IGP are solving the wrong > > problem > > >> now? > > >> >>>>>> > > >> >>>>>> Aijun Wang > > >> >>>>>> China Telecom > > >> >>>>>> > > >> >>>>>> > > >> >>>>>> On Jan 15, 2022, at 08:30, John E Drake <jdrake= > > >> [email protected]> wrote: > > >> >>>>>> > > >> >>>>>> > > >> >>>>>> Correct, but as Tony, Robert and I have noted, a > > node > > >> being up does not mean that an application on that node is > > up, > > >> which means that your proposed solution is probably a > > solution to > > >> the wrong problem. Further, Robert’s solution is probably > > a > > >> solution to the right problem. > > >> >>>>>> > > >> >>>>>> Yours Irrespectively, > > >> >>>>>> > > >> >>>>>> John > > >> >>>>>> > > >> >>>>>> > > >> >>>>>> Juniper Business Use Only > > >> >>>>>> From: Aijun Wang <[email protected]> > > >> >>>>>> Sent: Friday, January 14, 2022 5:53 PM > > >> >>>>>> To: John E Drake <[email protected]> > > >> >>>>>> Cc: Robert Raszuk <[email protected]>; Les Ginsberg > > >> (ginsberg) <[email protected]>; Christian Hopps < > > >> [email protected]>; Shraddha Hegde <[email protected]>; > > Tony > > >> Li <[email protected]>; Hannes Gredler <[email protected]>; > > lsr < > > >> [email protected]>; Peter Psenak (ppsenak) <[email protected]> > > >> >>>>>> Subject: Re: [Lsr] BGP vs PUA/PULSE > > >> >>>>>> > > >> >>>>>> [External Email. Be cautious of content] > > >> >>>>>> > > >> >>>>>> Hi, John: > > >> >>>>>> Please note if the node is down, the service will > > not be > > >> accessed. > > >> >>>>>> We are discussing the “DOWN” notification, not the > > “UP” > > >> notification. > > >> >>>>>> > > >> >>>>>> Aijun Wang > > >> >>>>>> China Telecom > > >> >>>>>> > > >> >>>>>> > > >> >>>>>> On Jan 15, 2022, at 00:25, John E Drake <jdrake= > > >> [email protected]> wrote: > > >> >>>>>> > > >> >>>>>> > > >> >>>>>> Hi, > > >> >>>>>> > > >> >>>>>> Comment inline below. > > >> >>>>>> > > >> >>>>>> Yours Irrespectively, > > >> >>>>>> > > >> >>>>>> John > > >> >>>>>> > > >> >>>>>> > > >> >>>>>> Juniper Business Use Only > > >> >>>>>> From: Lsr <[email protected]> On Behalf Of > > Robert > > >> Raszuk > > >> >>>>>> Sent: Monday, January 10, 2022 7:15 PM > > >> >>>>>> To: Les Ginsberg (ginsberg) <[email protected]> > > >> >>>>>> Cc: Christian Hopps <[email protected]>; Aijun Wang > > < > > >> [email protected]>; Shraddha Hegde < > > [email protected] > > >> >; Tony Li <[email protected]>; Hannes Gredler < > > [email protected]>; > > >> lsr <[email protected]>; Peter Psenak (ppsenak) < > > [email protected]> > > >> >>>>>> Subject: Re: [Lsr] BGP vs PUA/PULSE > > >> >>>>>> > > >> >>>>>> [External Email. Be cautious of content] > > >> >>>>>> > > >> >>>>>> Hi Les, > > >> >>>>>> > > >> >>>>>>> You seem focused on the notification delivery > > mechanism > > >> only. > > >> >>>>>> > > >> >>>>>> Not really. For me, an advertised summary is like a > > prefix > > >> when you are dialing a country code. Call signaling knows > > to go > > >> north if you are calling a crab shop in Alaska. > > >> >>>>>> > > >> >>>>>> Now such direction does not indicate if the shop is > > open > > >> or has crabs. > > >> >>>>>> > > >> >>>>>> That info you need to get over the top as a > > service. So I > > >> am much more in favor to make the service to tell you > > directly or > > >> indirectly that it is available. > > >> >>>>>> > > >> >>>>>> [JD] Right. Just because a node is up and > > connected to > > >> the network does not imply that a given application is > > active on > > >> it. > > >> >>>>>> > > >> >>>>>> Best, > > >> >>>>>> R. > > >> >>>>>> > > >> >>>>>> > > >> >>>>>> > > >> >>>>>> > > >> >>>>>> > > >> >>>>>> On Tue, Jan 11, 2022 at 1:07 AM Les Ginsberg > > (ginsberg) < > > >> [email protected]> wrote: > > >> >>>>>> Robert - > > >> >>>>>> > > >> >>>>>> From: Robert Raszuk <[email protected]> > > >> >>>>>> Sent: Monday, January 10, 2022 2:56 PM > > >> >>>>>> To: Les Ginsberg (ginsberg) <[email protected]> > > >> >>>>>> Cc: Tony Li <[email protected]>; Christian Hopps < > > >> [email protected]>; Peter Psenak (ppsenak) < > > [email protected]>; > > >> Shraddha Hegde <[email protected]>; Aijun Wang < > > >> [email protected]>; Hannes Gredler < > > [email protected]>; > > >> lsr <[email protected]> > > >> >>>>>> Subject: Re: [Lsr] BGP vs PUA/PULSE > > >> >>>>>> > > >> >>>>>> Les, > > >> >>>>>> > > >> >>>>>> We have received requests from real customers who > > both > > >> need to summarize AND would like better response time to > > loss of > > >> reachability to individual nodes. > > >> >>>>>> > > >> >>>>>> We all agree the request is legitimate. > > >> >>>>>> > > >> >>>>>> [LES:] It does not seem to me that everyone does > > agree on > > >> that – but I appreciate that you agree. > > >> >>>>>> > > >> >>>>>> But do they realize that to practically employ what > > you > > >> are proposing (new PDU flooding) requires 100% software > > upgrade > > >> to all IGP nodes in the entire network ? Do they also > > realize > > >> that to effectively use it requires data plane change > > (sure > > >> software but data plane code is not as simple as PI) on > > all > > >> ingress PEs ? > > >> >>>>>> > > >> >>>>>> [LES:] As far as forwarding, as Peter has > > indicated, we > > >> have a POC and it works fine. And there are many possible > > ways > > >> for implementations to go. > > >> >>>>>> It may or may not require 100% software upgrade – > > but I > > >> agree a significant number of nodes have to be upgraded to > > at > > >> least support pulse flooding. > > >> >>>>>> > > >> >>>>>> > > >> >>>>>> And with scale requirements you are describing it > > seems > > >> this would be 1000s of nodes (if not more). That's massive > > if > > >> compared to alternative approaches to achieve the same or > > even > > >> better results. > > >> >>>>>> > > >> >>>>>> [LES:] Be happy to review other solutions if/when > > someone > > >> writes them up. > > >> >>>>>> I think what is overlooked in the discussion of > > other > > >> solutions is that reachability info is provided by the > > IGP. If > > >> all the IGP advertises is a summary then how would > > individual > > >> loss of reachability become known at scale? > > >> >>>>>> You seem focused on the notification delivery > > mechanism > > >> only. > > >> >>>>>> > > >> >>>>>> Les > > >> >>>>>> > > >> >>>>>> Many thx, > > >> >>>>>> Robert > > >> >>>>>> > > >> >>>>>> _______________________________________________ > > >> >>>>>> Lsr mailing list > > >> >>>>>> [email protected] > > >> >>>>>> https://www.ietf.org/mailman/listinfo/lsr > > >> >>>>> > > >> >>>> > > >> >>> > > >> >> > > >> > > > >> > > >> _______________________________________________ > > >> Lsr mailing list > > >> [email protected] > > >> https://www.ietf.org/mailman/listinfo/lsr > > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
