> On Nov 17, 2021, at 6:09 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?
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. 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. 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 <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
