[Lsr] 答复: Comments on draft-wang-lsr-prefix-unreachable-annoucement

Aijun Wang <wangaijun@tsinghua.org.cn> Wed, 27 July 2022 09:26 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 793BAC157B52; Wed, 27 Jul 2022 02:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 f67CoPFDrVlH; Wed, 27 Jul 2022 02:25:59 -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 11725C159827; Wed, 27 Jul 2022 02:25:57 -0700 (PDT)
Received: from DESKTOPOSJFVLS (unknown [221.223.102.25]) by mail-m121145.qiye.163.com (Hmail) with ESMTPA id 020A180008C; Wed, 27 Jul 2022 17:25:54 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: 'Ketan Talaulikar' <ketant.ietf@gmail.com>, draft-wang-lsr-prefix-unreachable-annoucement@ietf.org
Cc: 'lsr' <lsr@ietf.org>
References: <CAH6gdPymK7cGyfQj=NCEz6tp51vzmwEn_WQOrzG=G2FT72Jdeg@mail.gmail.com>
In-Reply-To: <CAH6gdPymK7cGyfQj=NCEz6tp51vzmwEn_WQOrzG=G2FT72Jdeg@mail.gmail.com>
Date: Wed, 27 Jul 2022 17:25:52 +0800
Message-ID: <003f01d8a19a$de3f3730$9abda590$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01D8A1DD.EC666ED0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGmGgm0DCFR0+v1f8/Cyhl+KgEPnK32/gpg
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFKTEtLSjdXWS1ZQUlXWQ8JGhUIEh9ZQVkZTh1OVk9PH08eHhgaQh0YGlUTARMWGhIXJB QOD1lXWRgSC1lBWUlJSlVJSUhVSktJVUlOWVdZFhoPEhUdFFlBWU9LSFVKSktITk9VS1kG
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6OSo6Lww*Ij0yNENCGDABLyhP CRkwChxVSlVKTU5DQkpIQk5OTUpNVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSUpVSUlIVUpLSVVJTllXWQgBWUFKQ0NPSTcG
X-HM-Tid: 0a823efa1d2bb03akuuu020a180008c
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/BmFUzgFvFPHhTBigr_cXswJGGZA>
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 09:26:03 -0000

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.

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:

 

“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.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] 代表 Ketan Talaulikar
发送时间: 2022年7月27日 16:36
收件人: draft-wang-lsr-prefix-unreachable-annoucement@ietf.org
抄送: lsr <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