Hi, Christian: Aijun Wang China Telecom
> On Nov 18, 2021, at 18:13, Christian Hopps <[email protected]> wrote: > > > >> On Nov 17, 2021, at 6:09 PM, Aijun Wang <[email protected]> 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? > > > As A WG member: > > When I said in the meeting "As a WG member, I agree" I was specifically > referring to the gist of his statement which was that this wasn't worth > putting into the main protocol. I'm unconvinced (again as a WG member) that > there's a problem worth trying to solve here -- at least one that rises above > the "should we add something to the the protocol" level. [WAJ] Should it be “whoever makes a mistake, who corrects”? > > That said, the main point that I believe I was making here was that his > comment was a good one to make during the adoption call (or preferably before > we got to this point), so that discussion around it could happen on the list. [WAJ] Yeah, I think it has happened. There is no other better option to solve such problem now. If exists, please describe it. > > Thanks, > Chris. > >> 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 <[email protected]> wrote: >>> >>> >>> >>>> On Nov 16, 2021, at 10:36 PM, Aijun Wang <[email protected]> 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: [email protected] <[email protected]> On Behalf Of Acee Lindem >>>> (acee) >>>> Sent: Wednesday, November 17, 2021 2:56 AM >>>> To: [email protected] >>>> 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
