[Lsr] 答复: Comments on draft-wang-lsr-prefix-unreachable-annoucement
Aijun Wang <wangaijun@tsinghua.org.cn> Wed, 27 July 2022 10:43 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 E5D8EC13C208 for <lsr@ietfa.amsl.com>; Wed, 27 Jul 2022 03:43:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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=ham 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 EkqrMjc9aBac for <lsr@ietfa.amsl.com>; Wed, 27 Jul 2022 03:43:09 -0700 (PDT)
Received: from mail-m121145.qiye.163.com (mail-m121145.qiye.163.com [115.236.121.145]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C228C157B5E for <lsr@ietf.org>; Wed, 27 Jul 2022 03:43:05 -0700 (PDT)
Received: from DESKTOPOSJFVLS (unknown [221.223.102.25]) by mail-m121145.qiye.163.com (Hmail) with ESMTPA id 4BD708000A7; Wed, 27 Jul 2022 18:43:02 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: 'Ketan Talaulikar' <ketant.ietf@gmail.com>
Cc: 'lsr' <lsr@ietf.org>
References: <CAH6gdPymK7cGyfQj=NCEz6tp51vzmwEn_WQOrzG=G2FT72Jdeg@mail.gmail.com> <003f01d8a19a$de3f3730$9abda590$@tsinghua.org.cn> <CAH6gdPw6LWRDL_6T-fu4PKnNREbKDmtg20ZuAdb9w58vu7O1_w@mail.gmail.com>
In-Reply-To: <CAH6gdPw6LWRDL_6T-fu4PKnNREbKDmtg20ZuAdb9w58vu7O1_w@mail.gmail.com>
Date: Wed, 27 Jul 2022 18:43:00 +0800
Message-ID: <007101d8a1a5$a4773060$ed659120$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0072_01D8A1E8.B2A19C50"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGmGgm0DCFR0+v1f8/Cyhl+KgEPnAMerQI6AWvRcuat0sAREA==
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFKTEtLSjdXWS1ZQUlXWQ8JGhUIEh9ZQVkaSx8dVkpMHRkaGk1PThhIQlUTARMWGhIXJB QOD1lXWRgSC1lBWUlJSlVJSUhVSktJVUlOWVdZFhoPEhUdFFlBWU9LSFVKSktITk9VS1kG
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Oio6Fgw5SD0rCkMRQy0OMAMP CxIwC0pVSlVKTU5DQkpDTkNJQ01JVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSUpVSUlIVUpLSVVJTllXWQgBWUFISktLSjcG
X-HM-Tid: 0a823f40b860b03akuuu4bd708000a7
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/5VmXzA8Dgntn7U9N0rO_N2rDFII>
Subject: [Lsr] 答复: Comments on draft-wang-lsr-prefix-unreachable-annoucement
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, 27 Jul 2022 10:43:14 -0000
Hi, Ketan: We have discussed with Bruno offline for the possibilities of defining new flag to indicate the unreachable status explicitly. It’s possible, but the challenge is that for OSPFv3, currently, there only one bit unassigned (https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-4). It may need more works to expand the flag bits for OSPFv3. And, I can’t see there is significant differences between using the originator field and the flag bits to accomplish such aim. Would you like to state more clearly why the NULL value of originator can’t be used to indicate the unreachability explicitly? From my POV, if the prefix became unreachable, there is no originator advertise it, isn’t it? Anyway, this can be discussed further later after the adoption. Best Regards Aijun Wang China Telecom 发件人: Ketan Talaulikar [mailto:ketant.ietf@gmail.com] 发送时间: 2022年7月27日 17:45 收件人: Aijun Wang <wangaijun@tsinghua.org.cn> 抄送: draft-wang-lsr-prefix-unreachable-annoucement@ietf.org; lsr <lsr@ietf.org> 主题: Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement Hi Aijun, Please check inline below for a quick response. On Wed, Jul 27, 2022 at 2:55 PM Aijun Wang <wangaijun@tsinghua.org.cn <mailto:wangaijun@tsinghua.org.cn> > wrote: Hi, Ketan: Thanks for your comments. But I should correct some of them: 1) In the updated version, the indication of prefix unreachability is still the “NULL” value of prefix originator, not the LSInfinity. KT> Right and I am suggesting you go one step further and remove all that prefix originator "business" :-) 2) The LSInfinity is used only for avoiding the misrouting by implementation not support this implementation, as you have also pointed out. As pointed out also in the draft, when all the nodes within the area support such capabilities, the LSInfinity value can be ignored: KT> Well, as indicated, the use of the prefix originator for this purpose is broken in my view. The use of LSInfinity is helpful to navigate through backward compatibility issues. With prefix originator aspects removed, we don't need the capability anymore. What comes out at the other end of this "pivot" for draft-wang is much similar to the other proposal ... and this IMHO is good. “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 [RFC2328 <https://datatracker.ietf.org/doc/html/rfc2328> ], [RFC5305 <https://datatracker.ietf.org/doc/html/rfc5305> ] and [RFC5308 <https://datatracker.ietf.org/doc/html/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 capabilites, the PUAM message can be safely advertised without the additional LSInfinity metric information.” We are glad to cooperate with Peter to forward the solution, but want to say LSInfinity only can’t be used to indicate the unreachable information, we need some explicit indication method. KT> There is some value in having an explicit indication in addition to the use of LSInfinity in draft-ppsenak. Perhaps a prefix attribute flag as was already suggested to the authors of draft-ppsenak (https://mailarchive.ietf.org/arch/msg/lsr/Q9wU3Bo1uzhPd5C7bT_WE7k_3JI/). But certainly not the prefix originator as proposed by draft-wang. Thanks, Ketan Best Regards Aijun Wang China Telecom 发件人: lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org> [mailto:lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org> ] 代表 Ketan Talaulikar 发送时间: 2022年7月27日 16:36 收件人: draft-wang-lsr-prefix-unreachable-annoucement@ietf.org <mailto:draft-wang-lsr-prefix-unreachable-annoucement@ietf.org> 抄送: lsr <lsr@ietf.org <mailto:lsr@ietf.org> > 主题: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement Hello Authors, I am sharing some comments on the latest version of this document since we seem to have a packed agenda in LSR this time. 1) I notice that in the latest update of the draft, there is a big change to start using LSInfinity for indicating prefix unreachability (similar to draft-ppsenak-lsr-igp-ureach-prefix-announce). I see this as a sign of a degree of convergence between the two drafts. 2) However, I then question the motivation of the authors to continue with the bad design of overloading Prefix Originator and the added capability stuff on top. I don't wish to repeat why that design was an absolute NO-GO for me and I am glad to see the authors acknowledge the problem with misrouting by implementations not supporting this specification. So I don't see the point of still retaining all that. Thanks, Ketan
- [Lsr] Comments on draft-wang-lsr-prefix-unreachab… Ketan Talaulikar
- [Lsr] 答复: Comments on draft-wang-lsr-prefix-unrea… Aijun Wang
- Re: [Lsr] Comments on draft-wang-lsr-prefix-unrea… Ketan Talaulikar
- [Lsr] 答复: Comments on draft-wang-lsr-prefix-unrea… Aijun Wang
- Re: [Lsr] Comments on draft-wang-lsr-prefix-unrea… Ketan Talaulikar
- Re: [Lsr] Comments on draft-wang-lsr-prefix-unrea… Les Ginsberg (ginsberg)
- Re: [Lsr] Comments on draft-wang-lsr-prefix-unrea… John E Drake
- Re: [Lsr] Comments on draft-wang-lsr-prefix-unrea… Hannes Gredler
- Re: [Lsr] Comments on draft-wang-lsr-prefix-unrea… Aijun Wang
- Re: [Lsr] Comments on draft-wang-lsr-prefix-unrea… Ketan Talaulikar
- Re: [Lsr] Comments on draft-wang-lsr-prefix-unrea… Ketan Talaulikar
- Re: [Lsr] Comments on draft-wang-lsr-prefix-unrea… Acee Lindem (acee)
- Re: [Lsr] Comments on draft-wang-lsr-prefix-unrea… Aijun Wang
- Re: [Lsr] Comments on draft-wang-lsr-prefix-unrea… Peter Psenak
- Re: [Lsr] Comments on draft-wang-lsr-prefix-unrea… Huzhibo
- Re: [Lsr] Comments on draft-wang-lsr-prefix-unrea… Peter Psenak
- Re: [Lsr] Comments on draft-wang-lsr-prefix-unrea… Aijun Wang
- Re: [Lsr] Comments on draft-wang-lsr-prefix-unrea… Peter Psenak