Hi, Robert: I want to add one comments based on Peter’s comments.
Aijun Wang China Telecom > On Nov 18, 2021, at 19:30, Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org> > wrote: > > Robert, > >> On 18/11/2021 11:33, Robert Raszuk wrote: >> Les, All, >> One thing to keep in mind in this entire discussion is the reality of >> compute nodes becoming L3 routing nodes in many new architectures. The >> protocol which is used between TORs and such compute nodes is almost always >> BGP. That means that no matter what we do in the IGP we will not avoid using >> BGP for propagating both service reachability and next hop reachability of >> such service. [WAJ] In the scenarios that you mentioned, BGP nexthop reachability is derived from the directed interface, there is no summary action done by the router. Is that true? >> In all discussions so far I have not seen an indication that the proposed >> solution covers the above case. If I have compute's next hops covered by the >> summary and that compute goes down would I signal it in the IGP across >> areas/levels ? > > If the IGP is aware of the reachability of the compute's next hop and it > summarizes such reachability between areas/domains, it can for sure notify > about such compute's next hop becoming unreachable. > >> On the other hand TORs do not go down that much. So if we are to proceed >> with IGP based signalling of lost reachability I highly encourage to >> consider real problems and keep in mind scalability aspects in the event >> someone would like to punch holes in the summaries also based on specific >> compute nodes going down. Yes often BFD compute to TOR runs BFD so can be a >> trigger. > > first, we are not necessarily punching holes. At least with the event > notification it does not leave any state, so "punching a hole in summary" is > not the correct description of it. Second, remote PE going down may not be a > very frequent event, but it is a possible event and there are existing > solution that covers it. We are trying to extend the coverage for the case > where network is using the summarization. > > > thanks, > Peter > >> We as networking people often put a wall between network and compute ... >> well in reality there is no wall there any more**. So what we build must >> consider service end to end not only traditional routers to be really >> effective. >> Thx, >> R. >> PS. ** I came to know a few week's back that some well known financial >> company is joining network and compute teams into one. >> On Thu, Nov 18, 2021 at 3:47 AM Les Ginsberg (ginsberg) >> <ginsberg=40cisco....@dmarc.ietf.org <mailto:40cisco....@dmarc.ietf.org>> >> wrote: >> Tony –____ >> __ __ >> Inline.____ >> __ __ >> *From:* Tony Li <tony1ath...@gmail.com >> <mailto:tony1ath...@gmail.com>> *On Behalf Of *Tony Li >> *Sent:* Wednesday, November 17, 2021 5:24 PM >> *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com >> <mailto:ginsb...@cisco.com>> >> *Cc:* Gyan Mishra <hayabusa...@gmail.com >> <mailto:hayabusa...@gmail.com>>; Aijun Wang >> <wangai...@tsinghua.org.cn <mailto:wangai...@tsinghua.org.cn>>; >> lsr@ietf.org <mailto:lsr@ietf.org>; Christian Hopps >> <cho...@chopps.org <mailto:cho...@chopps.org>>; Acee Lindem (acee) >> <a...@cisco.com <mailto:a...@cisco.com>>; Tony Przygienda >> <tonysi...@gmail.com <mailto: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 >> <mailto: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 >> <mailto:lsr-boun...@ietf.org>>*On Behalf Of*Gyan Mishra >> *Sent:*Wednesday, November 17, 2021 4:32 PM >> *To:*Aijun Wang <wangai...@tsinghua.org.cn >> <mailto:wangai...@tsinghua.org.cn>> >> *Cc:*Les Ginsberg (ginsberg) >> <ginsberg=40cisco....@dmarc.ietf.org >> <mailto:ginsberg=40cisco....@dmarc.ietf.org>>;lsr@ietf.org >> <mailto:lsr@ietf.org>; Christian Hopps <cho...@chopps.org >> <mailto:cho...@chopps.org>>; Tony Przygienda >> <tonysi...@gmail.com <mailto:tonysi...@gmail.com>>; Acee Lindem >> (acee) <acee=40cisco....@dmarc.ietf.org >> <mailto: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 <mailto: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 <mailto:cho...@chopps.org>> wrote: >> > >> > >> > >> >> On Nov 16, 2021, at 10:36 PM, Aijun Wang >> <wangai...@tsinghua.org.cn >> <mailto: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 >> <mailto:lsr-boun...@ietf.org><lsr-boun...@ietf.org >> <mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem (acee) >> >> Sent: Wednesday, November 17, 2021 2:56 AM >> >> To:lsr@ietf.org <mailto: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 <mailto:Lsr@ietf.org> >> https://www.ietf.org/mailman/listinfo/lsr____ >> --____ >> <~WRD0000.jpg> <http://www.verizon.com/>____ >> *Gyan Mishra*____ >> /Network Solutions Architect /____ >> /emailgyan.s.mis...@verizon.com >> <mailto:gyan.s.mis...@verizon.com>/____ >> /M 301 502-1347/____ >> ____ >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org <mailto:Lsr@ietf.org> >> https://www.ietf.org/mailman/listinfo/lsr____ >> __ __ >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org <mailto: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
