Re: [Lsr] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04
Aijun Wang <wangaijun@tsinghua.org.cn> Wed, 06 September 2023 09:03 UTC
Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7477C14CE4F for <lsr@ietfa.amsl.com>; Wed, 6 Sep 2023 02:03:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.013
X-Spam-Level:
X-Spam-Status: No, score=-1.013 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLlx3h5HnBLn for <lsr@ietfa.amsl.com>; Wed, 6 Sep 2023 02:03:14 -0700 (PDT)
Received: from mail-m49197.qiye.163.com (mail-m49197.qiye.163.com [45.254.49.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC3D9C15107B for <lsr@ietf.org>; Wed, 6 Sep 2023 02:03:12 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPV6:240e:404:7900:2735:b4b3:c181:75c4:515c]) by mail-m121145.qiye.163.com (Hmail) with ESMTPA id D665E8000F9; Wed, 6 Sep 2023 17:03:08 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-44F06296-1F44-484F-8CF6-DFD27B934D88"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Wed, 06 Sep 2023 17:02:58 +0800
Message-Id: <E11B5D23-9BF0-4047-858B-B98A733FEEC6@tsinghua.org.cn>
References: <8a9b808f-1a82-5a2a-8bd0-946919900465@cisco.com>
Cc: Acee Lindem <acee.ietf@gmail.com>, Robert Raszuk <robert@raszuk.net>, "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, Huzhibo <huzhibo=40huawei.com@dmarc.ietf.org>, linchangwang <linchangwang.04414@h3c.com>, lsr <lsr@ietf.org>
In-Reply-To: <8a9b808f-1a82-5a2a-8bd0-946919900465@cisco.com>
To: Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (20G75)
X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFITzdXWS1ZQUlXWQ8JGhUIEh9ZQVkaGUtPVhkZTE1IHh1JSh4fSFUTARMWGhIXJBQOD1 lXWRgSC1lBWUlPSx5BT0tPQUxCS0tBSUxITkEZTxlIQRhKQ0pBTE4YT0FOSk4YWVdZFhoPEhUdFF lBWU9LSFVKSktDSEhVSktLVUtZBg++
X-HM-Tid: 0a8a69bb2c5ab03akuuud665e8000f9
X-HM-MType: 10
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6OU06PBw*OD1KHR8WIR8vSC0O IzwaCghVSlVKTUJIQkJLQkJLS0pIVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJT0seQU9LT0FMQktLQUlMSE5BGU8ZSEEYSkNKQUxOGE9BTkpOGFlXWQgBWUFIQ05LTDcG
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/E6Pg6kDppFfrPWJ0h03XivUHB48>
Subject: Re: [Lsr] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Sep 2023 09:03:18 -0000
On Sep 6, 2023, at 15:57, Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org> wrote:
Aijun,
WG adoption should be done based on the draft content, the quality of the solution it describes and not based on the draft age or order.
[WAJ] Not exactly. We should also respect the original contributions.
Multiple people have pointed out over the years that the solution that you propose in your draft - e.g. using router-id of 0 to indicate the unreachability is broken and lacks the backward compatibility aspect. Your original draft did NOT include the unreachable metric and even though you added it later (way after it was proposed in the other draft), your draft still uses the original router-id 0 idea. The fact that you need the PUAM Capabilities Announcement in your draft speaks for itself.
If not all of nodes within one area support the PUAM capabilities, the PUAM message should be advertised with the associated prefix cost set to LSInfinity. According to the description in [https://www.rfc-editor.org/info/rfc2328" class="cite xref" rel="nofollow">RFC2328], [https://www.rfc-editor.org/info/rfc5305" class="cite xref" rel="nofollow">RFC5305] and [https://www.rfc-editor.org/info/rfc5308" class="cite xref" rel="nofollow">RFC5308], the prefix advertised with such metric value will not be considered during the normal SPF computation, then such additional information will avoid the misbehavior of the nodes when they don't recognize the PUAM message.
If all of nodes within one area support the PUAM capabilities, the PUAM message can be safely advertised without the additional LSInfinity metric information.
Even though in all cases the treatment of such metric, or NU-bit, is specified for IS-IS, OSPF and OSPFv3, having an explicit way to signal that the prefix was advertised in order to signal unreachability is required to distinguish it from other cases where the prefix with such metric is advertised.
Though you may have been the first one to try to solve the problem in the IETF draft, your solution is still incorrect. As a result of your inability to listen to the comments an alternative draft was written that is technically superior, backward compatible, has wide support from vendors as well as operators, including ones that were originally co-authors on your draft and decided to join the alternate draft based on its technical advantages, has been implemented and deployed in the field.
[WAJ]There are other reasons for the switch over of co-author, I think we needn’t expand or refer to it. The standard is not the technical implementation of one company. The standard should look forward further the scenarios, deployment considerations and solutions coverages.
As a matter of fact, I have invited you to join our draft several times, but you refused. You insisted on pushing your draft.
[WAJ] I have proposed several times the merger of two drafts, we can discuss the contents and structure of the converged document. It’s pity that we missed the IETF117 on-site meeting.
my 2c,
Peter
On 06/09/2023 07:56, Aijun Wang wrote:Hi, Acee:AGAIN, before making some assertions, please check the following fact:Have you noticed the 00 version of https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/ <https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/> was submitted on July 5, 2021?But the description about the short lived notification in https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7 <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7> was on March 26, 2021.Then, which draft was the first?For the adoption call or merge efforts, I think the WG should consider the following facts:1)Which draft is the first to provide the use cases?2)Which draft is the first to propose explicit signaling for unreachable information?3)Which draft is the first to propose short lived notification?4)Which explicit signaling mechanism is simpler?5)Which draft provides more mechanisms to cover more scenarios?The base document should be selected based on the answers of the above questions.Select the base document doesn’t mean that it can’t be changed before the adoption(I haven’t said “Without Change” is the merge condition).Actually, we welcome more authors to join us to finalize the document and solution.As one of the most important WG within IETF, I think LSR WG should respect the original contributions to the WG.It is too hurry to consider or adopt only the draft that you prefer, especially the follower draft.Best RegardsAijun WangChina Telecom*发件人:*lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] *代表 *Acee Lindem*发送时间:*2023年9月6日0:56*收件人:*Aijun Wang <wangaijun@tsinghua.org.cn>*抄送:*Robert Raszuk <robert@raszuk.net>; Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org>; Huzhibo <huzhibo=40huawei.com@dmarc.ietf.org>; Peter Psenak <ppsenak@cisco.com>; linchangwang <linchangwang.04414@h3c.com>; lsr <lsr@ietf.org>*主题:*Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04Hi Aijun,When the WG discussion first indicated that this was a use case that needed to be addressed, I don’t dispute that you immediately added it to your draft.I have no doubt you would have purported support of any use case under discussion.However, the first draft to address this use case with a short-lived notification was https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/ <https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/>Based on WG feedback and collaboration of multiple vendors, this draft evolved to draft-ppsenak-lsr-igp-ureach-prefix-announce.While you’ve incorporated elements of the draft under discussion, your draft still includes pieces (sometimes conflicting) from previous use cases.There was an effort to merge the drafts but you declined unless your draft was used (without change) as the base. I’m not sure your motivation.Thanks,AceeOn Sep 1, 2023, at 20:25, Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>> wrote:Hi, Acee:Act as LSR chair, I think you should be more responsible to make anyunfounded assertions:We have described the previous statements inhttps://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7 <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7>, March 26, 2021, one year before the 00 version of draft-ppsenak(March 25,2022)Then, which draft copy or incorporate which draft?Aijun WangChina TelecomOn Sep 1, 2023, at 20:05, Acee Lindem <acee.ietf@gmail.com<mailto:acee.ietf@gmail.com>> wrote:Hi Aijun,On Aug 31, 2023, at 23:36, Aijun Wang<wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>> wrote:Hi,Acee:Pleasereadhttps://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-7 <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-7>before making misguide assertions:“The advertisement of PUAM message should only last oneconfigurable period to allow the services that run on thefailure prefixes are switchovered.”I guess I haven’t kept up with all the elements of the draftunder adoption that you continue to incorporate into your draft.This has been a continuing theme since initial discussed of theapplication signaling use case. While I have no interest inimproving your draft, making the LSP/LSA short-lived conflictswith the other scenarios your draft purports to address.AceeBest RegardsAijun WangChina Telecom*发件人:*lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>[mailto:lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>]*代表*Acee Lindem*发送时间:*2023年9月1日0:50*收件人:*Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>*抄送:*Les Ginsberg (ginsberg)<ginsberg=40cisco.com@dmarc.ietf.org<mailto:ginsberg=40cisco.com@dmarc.ietf.org>>; Huzhibo<huzhibo=40huawei.com@dmarc.ietf.org<mailto:huzhibo=40huawei.com@dmarc.ietf.org>>; Peter Psenak<ppsenak@cisco.com <mailto:ppsenak@cisco.com>>; linchangwang<linchangwang.04414@h3c.com<mailto:linchangwang.04414@h3c.com>>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>>*主题:*Re: [Lsr] Working Group Adoption of "IGP UnreachablePrefix Announcement" -draft-ppsenak-lsr-igp-ureach-prefix-announce-04On Aug 31, 2023, at 12:32, Robert Raszuk<robert@raszuk.net <mailto:robert@raszuk.net>> wrote:Hi Acee,In any case, one will need to update the signalingrouters and the routers acting on the signal.I guess this is clear to all.Additionally, your request for the adoption was thatthe draft have a stronger statement about themechanism being used for solely for signaling forapplications (e.g., BGP PIC).As to the applicability my comment was that either draftshould state in strong normative language that this isapplicable only to applications which data plane usesencapsulation to the next hop.Said this draft-wang introduces the additionalsignalling, sort of trying to assure that all nodes inan area understand the new messages - but I am not sureif even advertising PUAM capability means that it willbe actually used for all destinations ?No - but while the draft under adoption (ppsenak-lsr…) isfor an ephemeral signal which the WG agreed was a valid usecase, in the other draft, the LSAs are long-lived and arealso may be used for other purposed than signaling (e.g.,reread both sections 4 and 6 of draft-wang-lsr…). This draftstarting with a whole different use case but selectivelyadded mechanisms from ppsenak-lsr…I seem to recall you were a strong proponent of limiting thescope.By responding to this Email inline, some may believeyou support the assertion that we should start theadoption of both drafts. Please be clarify this.Well the way I see this is that adoption call is a bitmore formal opportunity for WG members to express theiropinion on any document. But maybe LSR (for goodreasons) have different internal rules to decide whichdocument should be subject to WG adoption and does sortof pre-filtering.If adoption call proves document has negative commentsor lacks cross vendor support it simply does not getadopted.Maybe I am just spoiled looking at how IDR WGprocess works :-)You replied to an Email inline suggesting adoption of bothdrafts. That is what I think could have been misconstrued -especially by those who didn’t follow the discussion untilnow who think you are agreeing with this recommendation.As for your other comment that this could beaccomplished with BGP or an out-of-bound mechanism,that is true but that could be true of many problem.However, the solution under adoption has runningcode and wide vendor support.Right ... As I wrote to Peter - perhaps this is just apragmatic approach and flooding is what link state usesso be it.As you know I did try in the past to propose BGPAggregate withdraw but then feedback of the communitywas that PEs do not go down that often to justify theextension.Hmm…We seem to have broad support for the LSR applicationsignaling use case.Thanks,AceeBest,Robert_______________________________________________Lsr mailing listLsr@ietf.org <mailto:Lsr@ietf.org>https://www.ietf.org/mailman/listinfo/lsr<https://www.ietf.org/mailman/listinfo/lsr>_______________________________________________Lsr mailing listLsr@ietf.org <mailto:Lsr@ietf.org>https://www.ietf.org/mailman/listinfo/lsr<https://www.ietf.org/mailman/listinfo/lsr>_______________________________________________Lsr mailing listLsr@ietf.org <mailto:Lsr@ietf.org>https://www.ietf.org/mailman/listinfo/lsr<https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
- [Lsr] Working Group Adoption of "IGP Unreachable … Acee Lindem
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Voyer, Daniel
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Acee Lindem
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… linchangwang
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Peter Psenak
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Les Ginsberg (ginsberg)
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Huzhibo
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Les Ginsberg (ginsberg)
- [Lsr] 答复: Working Group Adoption of "IGP Unreacha… Aijun Wang
- Re: [Lsr] 答复: Working Group Adoption of "IGP Unre… Les Ginsberg (ginsberg)
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Robert Raszuk
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Dongjie (Jimmy)
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Huzhibo
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Robert Raszuk
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Peter Psenak
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Dongjie (Jimmy)
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Peter Psenak
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Robert Raszuk
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Les Ginsberg (ginsberg)
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Acee Lindem
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Robert Raszuk
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Acee Lindem
- [Lsr] 答复: Working Group Adoption of "IGP Unreacha… Aijun Wang
- [Lsr] 答复: Working Group Adoption of "IGP Unreacha… Aijun Wang
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Acee Lindem
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Aijun Wang
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Acee Lindem
- [Lsr] 答复: Working Group Adoption of "IGP Unreacha… Aijun Wang
- Re: [Lsr] 答复: Working Group Adoption of "IGP Unre… Peter Psenak
- Re: [Lsr] 答复: Working Group Adoption of "IGP Unre… Aijun Wang
- Re: [Lsr] 答复: Working Group Adoption of "IGP Unre… Peter Psenak
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Acee Lindem
- [Lsr] 答复: Working Group Adoption of "IGP Unreacha… Aijun Wang
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Thomas.Graf
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Satoru Matsushima
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Gyan Mishra
- Re: [Lsr] Working Group Adoption of "IGP Unreacha… Acee Lindem
- [Lsr] 【Request AD Step In】 Working Group Adoption… Aijun Wang
- Re: [Lsr] 【Request AD Step In】 Working Group Adop… tom petch
- Re: [Lsr] 【Request AD Step In】 Working Group Adop… John Scudder
- Re: [Lsr] 【Request AD Step In】 Working Group Adop… Acee Lindem
- Re: [Lsr] 【Request AD Step In】 Working Group Adop… Aijun Wang
- Re: [Lsr] 【Request AD Step In】 Working Group Adop… tom petch
- Re: [Lsr] 【Request AD Step In】 Working Group Adop… Acee Lindem
- [Lsr] 答复: 【Request AD Step In】 Working Group Adop… Aijun Wang
- [Lsr] 答复: 【Request AD Step In】 Working Group Adop… Aijun Wang
- Re: [Lsr] 【Request AD Step In】 Working Group Adop… tom petch
- Re: [Lsr] 答复: 【Request AD Step In】 Working Group … Aijun Wang
- Re: [Lsr] 【Request AD Step In】 Working Group Adop… John Scudder
- [Lsr] 答复: 【Request AD Step In】 Working Group Adop… Aijun Wang
- Re: [Lsr] 【Request AD Step In】 Working Group Adop… Peter Psenak
- Re: [Lsr] 【Request AD Step In】 Working Group Adop… Acee Lindem