Hi, Robert: Aijun Wang China Telecom
> On Nov 25, 2021, at 07:35, Robert Raszuk <rob...@raszuk.net> wrote: > > > Hi Aijun, > > Just few points to your note. > > #1 > > > when ABR does the summary work > > In a lot of your emails you keep stating that ABR or IGPs do summarization. > Well that is not true. It is operators which configure the summarization. > > It is important to recognize this difference. > > It is also operators who configure leaking for a subset of area routes. > > When you configure a summary half of the addresses may be not even > configured. ABRs do nothing about it. [WAJ] OK. The operator let the ABR do something. If we follow this logic, I think these configuration act as the ACL of the prefixes. Won’t some thing likes the following let the work of operator easier? #Deny one #Permit All And, we also can think further under this POV: the IGP itself cannot meet all the scale requirements. The network design, the operator intervention are all key factors for this aim. Then why you and Tony assert that advertise the necessary negative information will significantly degrade the scalability of IGP? I think they are similar with the positive information. > > > #2 > > > As we have discussed on the list, there is no other better solution to > > solve the problem. > > Of course there are. Bunch of them in fact. Trivial to demonstrate too in > shipping code. [WAJ] Please illustrate one of them that can solve the problems that we mentioned simultaneously. For example, the liveness of BGP PEER, the liveness of SRv6 intermediate points . > > But neither lack nor presence of alternative solutions is a valid > justification to any protocol extension. [WAJ] Then, what is the valid justification? > > > #3 > > > [WAJ] It is the IGP advertises the inaccurate information, why let BGP > > clear up? Won’t you estimate the IDR experts will resist? > > There is nothing inaccurate in the IGP advertisement. IGP does precisely what > the operator configured it to do. [WAJ] It lack some more precise control mechanisms. Currently it can only allow all, or advertise all. > > BGP propagates service routes and if service is not up those routes should be > removed asap. I think this is clear to anyone. [WAJ] First, the reachable underlay information is not advertised via BGP. But we can still think further along your proposal: If the BGP advertise this host route is unreachable, but the IGP still think it has the knowledge to reach it, will this puzzle the router? > > In addition BGP can also and with much better scaling properties to a link > state protocol withdraw next hops for such service routes which I am sure > will be much faster end to end then IGP. After all please consider that it is > also BGP which needs to trigger best path on all remote PEs to select > alternative path. [WAJ] The above action is for the overlay prefixes, not for underlying prefixes. > > Last please tell me one person in IDR who will oppose to make BGP withdraws > go faster (if needed as personally if your configuration is rigth I believe > it is already fine - of course provided that you are using decent BGP > implementation all the way). [WAJ] BGP should be responsible for advertising and revoking of the prefixes that it advertised. It should not interfere with the information that other protocol advertised. > > Kind regards, > Robert > > > > > > >> On Thu, Nov 25, 2021 at 12:14 AM Aijun Wang <wangai...@tsinghua.org.cn> >> wrote: >> Hi, Tony: >> >> Aijun Wang >> China Telecom >> >>>> On Nov 25, 2021, at 03:59, Tony Li <tony...@tony.li> wrote: >>>> >>> >>> >>> Hi Aijun, >>> >>>> If the scale is equal, then I would prefer to see flooding positive >>>> information rather than negative information. Operationally this is key: >>>> if there is a failure and positive information doesn’t propagate, then >>>> it’s a bug that will be found in due course and the operator can react >>>> outside of a failure scenario. >>>> [WAJ] What we want to do is the “Positive Summary”+” Specific Negative >>>> Information”. This can have both the summary scale advantage and also >>>> decrease the convergence time that based on the protocol hello timer. >>> >>> >>> I do understand that. Do you understand that I think that that’s a Really >>> Bad Idea? >> [WAJ] No. As we have discussed on the list, there is no other better >> solution to solve the problem. Actually, when ABR does the summary work, it >> may overstate the reachable addresses. >> When the host is within the summary range but is not used, it’s OK. But >> when the in-service host become unreachable and ABR knows this, it should >> give the other nodes the accurate information to assist them to switch to >> other services/backup points. >> >>> >>> >>> >>>> Increasing the size of the LSDB always affects performance. It slows >>>> flooding. Some nodes may not realize that SPF is not needed. When LSP >>>> fragments are rearranged, inferring that SPF is not necessary is >>>> non-trivial. Impacting router and network performance is a given. >>>> [WAJ] PUAM does not increase the overall size of the LSDB. It utilizes the >>>> existing LSA/TLV/Sub-TLV. >>> >>> >>> You’re advertising bits that would not be otherwise advertised. That >>> increases the size of the LSDB. Utilizing existing TLVs is irrelevant. >> >> [WAJ] No. OSPF/ISIS has been designed to be extensible to accommodate the >> newly necessary information. If we stick to your point, the fixed format LSA >> is sufficient. >> >>> >>> >>>> I have no objections to Robert’s BGP propagation ideas if that’s workable. >>>> >>>> This is simply not the IGP’s job and the IGP is not a dump truck. >>>> [WAJ] BGP is used within the internet, adding the false information within >>>> its protocol should be examined more carefully. As we have mentioned >>>> several times, the overall goals are not only for BGP usecaes, but also >>>> the prevailing Tunnel services. >>> >>> >>> Understood. BGP is also not a dump truck, but has far better scaling >>> properties, so is less likely to have catastrophic failures due to some >>> negative information. >> >> [WAJ] It is the IGP advertises the inaccurate information, why let BGP clear >> up? Won’t you estimate the IDR experts will resist? >> >>> >>> T >>> >>> >>> _______________________________________________ >>> 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 > _______________________________________________ > 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
