Re: [Tsv-art] Tsvart last call review of draft-ietf-mpls-bfd-directed-27

Lars Eggert <lars@eggert.org> Tue, 16 April 2024 09:37 UTC

Return-Path: <lars@eggert.org>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1A9C14F61E; Tue, 16 Apr 2024 02:37:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=eggert.org
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 G8W-O9OZxrTl; Tue, 16 Apr 2024 02:37:11 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400::25]) (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 F0F2CC14F617; Tue, 16 Apr 2024 02:37:10 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 580B480507; Tue, 16 Apr 2024 12:37:06 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eggert.org; s=dkim; t=1713260227; h=from:subject:date:message-id:to:cc:mime-version:content-type: in-reply-to:references; bh=d4CyTPgra84s4kgwhncaxqhqGPayPtd6EHjUELKJhgg=; b=T4gE2IeCL+y8joOHMoZOZuMTh5Tltwff2NsekCcZ3xz8btP48vbpL2eec7RwqtxyCzVme9 WnGGlKFocmQS8Tgyl4F0DD46BzLkOEcwqtteu7LPGEdsiUdmhQBl5PE4WiQcGgARKR6i41 C64gpW+XN/9xXZs31NzL0V/fzJ3taaQe8n/l9KBv3irUJ2BM9PGZVAy3IcC0AxD1rmzQ8O Yp2RGpKTvOEdAvgNDG7KuwyO0gFfVy2TODEObXVqqjxxm6frvw7zvNxbYtky20Rq5PGJbm UeXcXZbpuWdbTLLOQwgspRSL35T9zqF6wUoeDLXKTHrCGFYcYQNjkX2nRoQinQ==
Content-Type: multipart/signed; boundary="Apple-Mail=_BCFD768F-23A7-44F1-8263-9CFFFCF5B603"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
From: Lars Eggert <lars@eggert.org>
In-Reply-To: <CA+RyBmWDZhWN5zrL7L=R0b8N0shXCeHTMMioyh4XqU+UYJfo0A@mail.gmail.com>
Date: Tue, 16 Apr 2024 12:37:06 +0300
Cc: tsv-art@ietf.org, draft-ietf-mpls-bfd-directed.all@ietf.org, last-call@ietf.org, mpls@ietf.org
Message-Id: <6B20B16D-922B-4D59-BF70-F56CB30F3F7D@eggert.org>
References: <171317752654.2149.17792638919970591493@ietfa.amsl.com> <CA+RyBmWDZhWN5zrL7L=R0b8N0shXCeHTMMioyh4XqU+UYJfo0A@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
X-Last-TLS-Session-Version: TLSv1.2
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/ntommpNf2LXVcO7BaTQJoA0s8HA>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-mpls-bfd-directed-27
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2024 09:37:15 -0000

Hi Greg,

On Apr 15, 2024, at 15:50, Greg Mirsky <gregimirsky@gmail.com> wrote:
> ### Section 3.1, paragraph 7
> ```
>      Reverse Path field contains none, one or more sub-TLVs.  Any non-
>      multicast Target FEC Stack sub-TLV (already defined, or to be defined
>      in the future) for TLV Types 1, 16, and 21 of MPLS LSP Ping
>      Parameters registry MAY be used in this field.  Multicast Target FEC
> ```
> I think you mean "no other sub-TLV than X, Y, Z MUST be used"?(The MAY
> makes anything allowed.)
> GIM>> I think that your suggestion is close but could the new wording be interpreted that some of sub-TLV MUST be present? Would the following update make the use of the normative language clear:
> OLD TEXT:
>    Reverse Path field contains none, one or more sub-TLVs.  Any non-
>    multicast Target FEC Stack sub-TLV (already defined, or to be defined
>    in the future) for TLV Types 1, 16, and 21 of MPLS LSP Ping
>    Parameters registry MAY be used in this field.  
> NEW TEXT:
>    Reverse Path field MAY contain none, one, or more sub-TLVs.  Only
>    non-multicast  Target FEC Stack- sub-TLVs (already defined, or to be
>    defined in the future) for  TLV Types 1, 16, and 21 of MPLS LSP Ping
>    Parameters registry MUST be used  in this field. 
> 
> WDYT?

WFM!

> ### Section 3.1, paragraph 6
> ```
>      MAY be included in the BFD Reverse Path TLV.  However, the number of
>      sub-TLVs in the Reverse Path field MUST be limited.  The default
>      limit is 128, but an implementation MAY be able to control that
> ```
> Why must it be limited? And what unit is the default of 128 expressed
> in, bytes (for the "length" field)? Or number of entries?
> GIM>> Yes, the concern is for the number of entries. That is the result of addressing the comments by Andrew Allston. As Andrew explained, the concern is not for the size of the TLV but about the possible impact on the control plane (sort of DoS attack).  

OK, then please make it clear(er) that the limit is in bytes and applies to the Length field?

> ### Section 3.1, paragraph 6
> ```
>      If the egress LSR cannot find the path specified in the Reverse Path
>      TLV it MUST send Echo Reply with the received BFD Discriminator TLV,
>      Reverse Path TLV and set the Return Code to "Failed to establish the
>      BFD session.  The specified reverse path was not found" Section 3.2.
> GIM>> Thank you for pointing that out to me. That must be a forward reference. Would enclosing Section 3.2 in parentheses help? 

Yes, that would have made it clear.

Thanks,
Lars