Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

Tony Li <tony.li@tony.li> Wed, 05 October 2022 14:25 UTC

Return-Path: <tony1athome@gmail.com>
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 0612FC14F730 for <lsr@ietfa.amsl.com>; Wed, 5 Oct 2022 07:25:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.51
X-Spam-Level:
X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 LR8t7JlV5Z3O for <lsr@ietfa.amsl.com>; Wed, 5 Oct 2022 07:25:14 -0700 (PDT)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 6C0B3C14CE20 for <lsr@ietf.org>; Wed, 5 Oct 2022 07:25:14 -0700 (PDT)
Received: by mail-pg1-x52a.google.com with SMTP id a23so7682756pgi.10 for <lsr@ietf.org>; Wed, 05 Oct 2022 07:25:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:sender:from:to:cc:subject:date; bh=ELF+5ABrsD5coxWOaM3R1wCTq2oy/spGtiGLGhxZv4Q=; b=W93TuIQY0vgh+lBNzV7YbEhPXgRBVkHYEGElJhk7kXFxzkmv9WYOD10kXptEVxneAY HDbml1UVepPYeq4heOneFscEwZ7LiYZPo/a1Bg86PPa6I22bChEf1p/OVFg7Z5+1TjW0 0im8UKQfrBUBYubNk4DzDy7PKToMQDMYhMr8k6nLwnaVey92rGeLgKdwjF6naoMs/ZrY E9b9HZje9ejhS8bXwVo3dQAyx7e53dNKydqtjVhIq3YMRUPK8gTLy0Y04l+NjR59V0M0 GMVy2XOlVCAGAgoc+ceiJ/cFYam917UW6MOd6v982dFVXi2gUF9eewzK6egJ/5sifwbn xtzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:sender:x-gm-message-state:from:to:cc:subject:date; bh=ELF+5ABrsD5coxWOaM3R1wCTq2oy/spGtiGLGhxZv4Q=; b=oJk+kD7tyWINlX0JF0FlSbt8whilJPJL5tnhIQbmgkdjSOrqznhBgYgxsWIMFfUfTO M+9uf4P4msi1hHL8ALXS4O2BwW/fk9UTt6tj7pcG2vCHyoqMHVbMnSMWJ4MHAQW9dhz/ gHsh9fYr1hgalmRV1RDZhwBx3nWuYT63CsjQC4iC7We3YhvKsR2EwIOYxYvyJWXwd9ne PFO888ggLfgkOktgkjBjEAYvm7YQzyEzt73xoniB6V5aASPegSAUvGZGNLZCXs++mqDr SAqZg840DpBDmBTzXFhVDmDwY3hHZ2sj4St+qoKEpD5rDe351xPz5hUkIm8oHvx2JaC0 q5QA==
X-Gm-Message-State: ACrzQf1ragRE5+14SWms7NzZtqw29V+7EGi4h1ujxaFxvWkqyLdUugvA /tLtJtNcmDuvaGTmaAo6TnV484SjNys=
X-Google-Smtp-Source: AMsMyM7QEr4/10GUfAwkalmaQtMDFf6r6LqYs4M76SITjWmfN3xpt8Y1qgiZOCjFIMhHcmziZ/x1/g==
X-Received: by 2002:a63:4408:0:b0:439:befa:3d47 with SMTP id r8-20020a634408000000b00439befa3d47mr107892pga.64.1664979913414; Wed, 05 Oct 2022 07:25:13 -0700 (PDT)
Received: from smtpclient.apple (c-73-158-102-25.hsd1.ca.comcast.net. [73.158.102.25]) by smtp.gmail.com with ESMTPSA id w15-20020a1709026f0f00b0017f59ebafe7sm5572942plk.212.2022.10.05.07.25.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2022 07:25:12 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: Tony Li <tony.li@tony.li>
Message-Id: <194D299D-984F-4140-841A-6D758F0642D0@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4DD44CCC-FE0A-4754-B713-CD6BC505BA8D"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
Date: Wed, 05 Oct 2022 07:25:11 -0700
In-Reply-To: <3745_1664962154_633D4E6A_3745_302_1_11a0555c578c481baf78637a9d1bb642@orange.com>
Cc: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, Christian Hopps <chopps@chopps.org>, Robert Raszuk <robert@raszuk.net>, Henk Smit <henk.ietf@xs4all.nl>, "lsr@ietf.org" <lsr@ietf.org>
To: "<bruno.decraene@orange.com>" <bruno.decraene@orange.com>
References: <m2zgecdhtw.fsf@ja.int.chopps.org> <BY5PR11MB4337A9F4C64AA37F60F17FDCC15B9@BY5PR11MB4337.namprd11.prod.outlook.com> <m2mtacicnz.fsf@ja.int.chopps.org> <BY5PR11MB43376878015C05FA38E67BA7C15A9@BY5PR11MB4337.namprd11.prod.outlook.com> <21CD3D1C-CA12-46A1-AB48-5AE9C0459F0C@tony.li> <BY5PR11MB43378BAB39E605DC3C55869DC15A9@BY5PR11MB4337.namprd11.prod.outlook.com> <3745_1664962154_633D4E6A_3745_302_1_11a0555c578c481baf78637a9d1bb642@orange.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Qlb3070QzUwR0bg79lgCSiOuNvA>
Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt
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, 05 Oct 2022 14:25:15 -0000

Hi Bruno,

> To clarify, are we talking about:
> - different nodes in the flooding domain having a different understanding of the LSDB content


We are trying to prevent that.  We are trying to figure out how we can relax the cases where the specifications imply, but do not clearly state that a TLV may occur multiple times. If some nodes are not prepared for that, then they would misinterpret the advertisements, perceive different information content, and misbehave. What are the necessary and sufficient precautions to prevent this?


> And a standardization group defining specifications to allow for interop?


In particular, how do we propagate information to know which nodes are capable of correctly interpreting multi-part TLVs?

 
> Sure, I’d be interested in an implementation report to at least learn about such (sub) TLV and those implementations.


Chris is not asking for an implementation report, nor is that what I’m working on.

T