RFC 5302 section 1.3 nicely describes the ISIS scalability issues with domain wide flooding of prefixes and recommendations for summarization.
https://datatracker.ietf.org/doc/html/rfc5302#section-1.2 RFC 5283 inter-area extension is described in detail problem statement in section 5 of the PUA draft and impact with convergence and not being able to track component prefixes and a how the PUA and event notification drafts solve real world problems that exist for operators. https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08/section-5 Kind Regards Gyan Verizon On Wed, Nov 17, 2021 at 9:46 PM Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > Tony – > > > > Inline. > > > > *From:* Tony Li <tony1ath...@gmail.com> *On Behalf Of *Tony Li > *Sent:* Wednesday, November 17, 2021 5:24 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* Gyan Mishra <hayabusa...@gmail.com>; Aijun Wang < > wangai...@tsinghua.org.cn>; lsr@ietf.org; Christian Hopps < > cho...@chopps.org>; Acee Lindem (acee) <a...@cisco.com>; Tony Przygienda < > tonysi...@gmail.com> > *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 > LSR Meeting Minutes > > > > > > Les, > > > > That’s easy. The summary covers all addresses of all of the nodes (hosts > and routers) in the area. It also may cover addresses within the summary > that are not currently assigned. This is intentional since by advertising a > summary, we gain scalability. The summary provides aggregated reachability > throughout the network. > > > > Reachability and path selection is the responsibility of the IGP, not > liveness. > > > > Should we not advertise a summary because a single address in the summary > is not assigned? No, it is up to correspondents to determine if the > address is populated. > > > > Should we punch holes in our summary for unassigned addresses? No, that > would kill scalability. > > > > Should we punch holes in our summary for host failures? That would kill > scalability too and drag the IGP out of its role. > > > > Why would we then punch holes in the summary for member routers? Just > because we can? > > *[LES:] No. We are doing it to improve convergence AND retain scalability.* > > > > Should we corrupt the architecture just because we can? There are other, > architecturally appropriate solutions available. How about we just use > them? > > > > *[LES:] What are you proposing?* > > > > * Les* > > > > Regards, > > Tony > > > > > > > > On Nov 17, 2021, at 5:08 PM, Les Ginsberg (ginsberg) < > ginsberg=40cisco....@dmarc.ietf.org> wrote: > > > > I think the discussion about using a separate instance is a distraction > and we shouldn’t be debating that right now. > > > > The legitimate question is whether folks see it as appropriate to have an > IGP based solution for the problem. How to do it using the IGP is only a > meaningful question if we are considering using the IGP at all. > > > > In that context…it is clear that it is a legitimate use of the IGP to > advertise summary addresses. > > It is also a legitimate use of the IGPs to advertise all the individual > prefixes covered by a summary if the network operator chooses not to > summarize. > > It therefore seems to me to quite legitimate for the IGP to advertise both > a summary and changes to the reachability of individual destinations > covered by the summary. This is still a type of prefix reachability > advertisement. > > > > It would help me if the folks who think this is NOT a legitimate use of an > IGP could explain why in the context of the above. > > > > Thanx. > > > > Les > > > > *From:* Lsr <lsr-boun...@ietf.org> *On Behalf Of *Gyan Mishra > *Sent:* Wednesday, November 17, 2021 4:32 PM > *To:* Aijun Wang <wangai...@tsinghua.org.cn> > *Cc:* Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org>; > lsr@ietf.org; Christian Hopps <cho...@chopps.org>; Tony Przygienda < > tonysi...@gmail.com>; Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org> > *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 > LSR Meeting Minutes > > > > > > With MT separate control plane common data plane or Multi Instance > separate control plane and separate data plane. > > > > In both transport instance styles peeling the event notification into a > separate instance or topology how do this discrete transport instance or > topology interact with the main instance or topology. > > > > The answer is it can’t. > > > > As Aijun as well as Peter have discussed the problem this is an inherent > issue with use of summarization and these are two solutions to solbe this > real world issue to make summarization viable for operators. > > > > Gyan > > Verizon Inc > > > > On Wed, Nov 17, 2021 at 6:10 PM Aijun Wang <wangai...@tsinghua.org.cn> > wrote: > > Hi, Christian: > > Would you like to describe how to solve the problem via using the > transport instance? The detail interaction process within the node and the > deployment overhead analysis? > If there is no such information, it is doubt whether your judgment is > correct or not, it is also unconvincing. Welcome also Tony gives the > explanation before making the assertions, as we done for PUAM solution. > > > Aijun Wang > China Telecom > > > On Nov 17, 2021, at 22:59, Christian Hopps <cho...@chopps.org> wrote: > > > > > > > >> On Nov 16, 2021, at 10:36 PM, Aijun Wang <wangai...@tsinghua.org.cn> > wrote: > >> > >> Hi, > >> > >> The followings are the responses for the comments on PUAM draft( > https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08 > ) > >> > >> Les: The comment I want to make, I think the discussion on the > >> list highlighted the fact that there's an open question, > >> independent of whether we use the prefix unreachable > >> draft or the Event Notification draft, as to whether this > >> problem should be solved by the IGP or whether it should be > >> solved by BGP, or in some other way. And I think the logical > >> way to proceed on this is to get the consensus of the working > >> group as to whether an IGP solution is desired first, then > >> after we reach consensus on that, then we can start talking > >> about which approach is the better approach. Which one > >> should be adopted? > >> 【WAJ】The problem is occurred due to the summary action by the ABR > router in IGP, it should be solved by IGP itself. > >> As discussed earlier on the list, the possible use case is not limited > to BGP fast convergence. > >> Based on the above considerations, it is not appropriated solved via > BGP. > >> > >> Chris H: Chair hat on. You've been asking for adoption for a while. > >> The event notification draft is new. I agree with Les that > >> in a perfect world that would be the case, but asking for > >> adoption is one way to answer the question. It may be not > >> the perfect way to answer that question, but it is one way. > >> I agree without my chair hat on, I'm not sure we need this, > >> but it's not for me to say by fiat. Acee did put something > >> out on the list to try to engage people again. And I don't > >> think a lot got said. > >> 【WAJ】we have several round discussions for this topic but there is > always no conclusion at the end. > >> Can the expert that reluctant to accept the new idea to give some > specific questions/problems for the current solution? > >> Or else it is not helpful for the solve of the existing problem. > >> Initiate the adoption call maybe the best way to let the experts > express their opinions? > >> We would like to hear the specific and detail comments for the > current solutions, not just general comments. > >> > >> Acee: I didn't see much support other than from the authors. I > >> saw one non-author support on the event notification. > >> 【WAJ】Does anyone not agree what we analyze/summarize at the > presentation material for the two solutions? ( > https://datatracker.ietf.org/meeting/112/materials/slides-112-lsr-05-puam-stublink-00.pdf, > the 5th slide) > >> > >> Chris: Everyone has a right to ask for an adoption. Everyone has a > >> right to say we shouldn't adopt this and there are the > >> reasons. We've let people to express opinions, without > >> seeing a lot of negative opinions it's hard not to just grant > >> the adoption call. > >> 【WAJ】I agree. > >> > >> Tony P: I think this is all making a trash can out of the IGP. One > >> possible solution is to ban or encouraged maybe everyone with > >> these kind of suggestions to go towards the service instance > >> stuff or whatever we call it, which I think is a good idea. > >> Just run a power line up and much lower priority. Don't trash > >> the main protocol that holds the whole thing together. > >> 【WAJ】Do you consider the deployment complexity for independent service > instance to transfer such thing? And also the interaction on the device > among the main IGP instance and the service instances? It’s the fault of > the main protocol, and should be solved by the main protocol. > >> > >> Chris: Great comment for the adoption call. As a WG member, I agree. > > > > This makes it seem like I'm saying that I agree with your response. I'd > strike that "As a WG member, I agree". > > > > Thanks, > > Chris. > > > > > >> > >> > >> > >> From: lsr-boun...@ietf.org <lsr-boun...@ietf.org> On Behalf Of Acee > Lindem (acee) > >> Sent: Wednesday, November 17, 2021 2:56 AM > >> To: lsr@ietf.org > >> Subject: [Lsr] IETF 112 LSR Meeting Minutes > >> > >> The IETF 112 LSR Meeting Minutes have been uploaded. Thanks to Yingzhen > Qu for taking them!!! > >> > >> https://datatracker.ietf.org/meeting/112/materials/minutes-112-lsr-00 > >> > >> The IETF 112 LSR Meeting MeetEcho recording is available here: > >> > >> > https://play.conf.meetecho.com/Playout/?session=IETF112-LSR-20211111-1200 > >> > >> Thanks, > >> Acee > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > -- > > <~WRD0000.jpg> <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > *M 301 502-1347* > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
