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

Aijun Wang <wangaijun@tsinghua.org.cn> Thu, 28 July 2022 01:22 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 1D317C14CF00; Wed, 27 Jul 2022 18:22:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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] autolearn=unavailable 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 jBabIwBTob6g; Wed, 27 Jul 2022 18:22:34 -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 4788CC157B4D; Wed, 27 Jul 2022 18:22:34 -0700 (PDT)
Received: from smtpclient.apple (unknown [221.223.102.25]) by mail-m121145.qiye.163.com (Hmail) with ESMTPA id 6C0B7800058; Thu, 28 Jul 2022 09:22:31 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-AFA8AD86-64C3-460B-BE6C-124F8E75A1B8"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Message-Id: <2A8870DE-17C6-4C3A-A0A4-59458B5E66BD@tsinghua.org.cn>
Date: Thu, 28 Jul 2022 09:22:30 +0800
Cc: Ketan Talaulikar <ketant.ietf@gmail.com>, draft-wang-lsr-prefix-unreachable-annoucement@ietf.org, lsr <lsr@ietf.org>
To: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (19F77)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFKTEtLSjdXWS1ZQUlXWQ8JGhUIEh9ZQVkaGk1PVkweQk5OHk5CTB9CQlUTARMWGhIXJB QOD1lXWRgSC1lBWUlJSlVJSUhVSktJVUlOWVdZFhoPEhUdFFlBWU9LSFVKSktITUpVS1kG
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6PD46Qww5MD03AkIwGisxUQEM GBBPChpVSlVKTU5DQkxKSE5KQ0xPVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSUpVSUlIVUpLSVVJTllXWQgBWUFKSE1PTDcG
X-HM-Tid: 0a824265e999b03akuuu6c0b7800058
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/OU_CIl2Z2sMRDmIBKMd-2tt08-4>
Subject: Re: [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: Thu, 28 Jul 2022 01:22:39 -0000



Hi, Les:

I admire you and your comments as usual, but the baseless comments will decrease your credits within the WG. Would you like to review the update of the draft more carefully, then post your comments? Doing this can avoid misleading some of your followers.

To facilitate your review, I copied the related contents again:(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10#section-5)

  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],
   [RFC5305] and [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.

Then, how can the “legacy nodes MUST interpret as meaning reachable.” ? I wish to hear your explanation.

Aijun Wang
China Telecom

> On Jul 28, 2022, at 06:39, Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org> wrote:
> 
> (Preamble: All of what I am going to say I have said many times before – on the list – off the list – in private conversations – in WG meetings…
> I don’t say this to start a discussion with the WG authors – it seems clear that we don’t agree and have no path to agreement.
> My purpose in saying this is to respond to the ongoing existence of this draft and offering my opinion as to what action the WG should take.)
>  
> The mechanism defined in this draft is broken. Not only is it not backwards compatible – the PUA advertisements will be misinterpreted to mean the exact opposite of what is intended i.e., the intent is to signal that a prefix is unreachable, but you do so by using an advertisement which legacy nodes MUST interpret as meaning reachable. This is simply broken and should not be done.
>  
> The authors deserve credit for bringing the attention of the WG to the problem space – but the solution offered is not deployable. Given the long period of time during which this draft has been published and the many times it has been presented/discussed in the WG I think it is now time to say thank you to the authors for their work, but the WG is not interested in adopting this draft.
>  
>    Les
>  
>  
> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Ketan Talaulikar
> Sent: Wednesday, July 27, 2022 1:36 AM
> To: draft-wang-lsr-prefix-unreachable-annoucement@ietf.org
> Cc: lsr <lsr@ietf.org>
> Subject: [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 mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr