+1 I completely agree.
The failure is with the IGP being able to track the component prefixes that are part of a summary advertisement in large domains with hundreds of thousands of host routes chatter that without summarization could result in a meltdown. BGPs job is to carry the external prefixes and the underlay connected and egress PE LSP loopback FEC binding bgp next hop attribute is the job of the IGP to build the RIB/FIB and MPLS LFIB which is all based on the underlay IGP prefixes for hop by hop forwarding. Kind Regards Gyan On Wed, Nov 17, 2021 at 9:23 PM Acee Lindem (acee) <a...@cisco.com> wrote: > The failure signaling pertains to a summary advertised in a normal routing > instance and. If this problem is to be solved by the IGP, it definitely > should be in the same instance as the summary itself. Hence, I second the > motion to take the OSPF transport instance off the table for this > application. > > > > Thanks, > Acee > > P.S. You probably noticed that I’ve deferred comment on whether or not > this should be solved in the IGP. > > > > > > *From: *"Les Ginsberg (ginsberg)" <ginsberg=40cisco....@dmarc.ietf.org> > *Date: *Wednesday, November 17, 2021 at 8:09 PM > *To: *Gyan Mishra <hayabusa...@gmail.com>, Aijun Wang < > wangai...@tsinghua.org.cn> > *Cc: *"Les Ginsberg (ginsberg)" <ginsb...@cisco.com>, "lsr@ietf.org" < > lsr@ietf.org>, Christian Hopps <cho...@chopps.org>, Tony Przygienda < > tonysi...@gmail.com>, Acee Lindem <a...@cisco.com> > *Subject: *RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 > LSR Meeting Minutes > > > > 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 > > -- > > [image: Image removed by sender.] <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > *M 301 502-1347* > > > -- <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
