Re: [mpls] I-D Action: draft-ietf-mpls-mna-requirements-09.txt

Tony Li <tony.li@tony.li> Tue, 30 January 2024 22:31 UTC

Return-Path: <tony1athome@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D01C14F704 for <mpls@ietfa.amsl.com>; Tue, 30 Jan 2024 14:31:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.508
X-Spam-Level:
X-Spam-Status: No, score=-1.508 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.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no 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 NZClHmzjWDR3 for <mpls@ietfa.amsl.com>; Tue, 30 Jan 2024 14:31:37 -0800 (PST)
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 E9157C14F61B for <mpls@ietf.org>; Tue, 30 Jan 2024 14:31:37 -0800 (PST)
Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-295dd13fe0dso42730a91.1 for <mpls@ietf.org>; Tue, 30 Jan 2024 14:31:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706653897; x=1707258697; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:sender:from:to:cc:subject:date:message-id:reply-to; bh=ECqTk6JdLhPqEuF+gqbHuPllH2Ar6STQZ5WqRAyuG+o=; b=Ap201qRgKCcgH+vo/l/VCs96cX9PXgaJzh/x8g6N9KSTLXz7jVd5ggBYot1Sb/a0v6 j5FBzrN+uFr+/Q6tpLEntC2nV9qMXQsyCY5M+oBemccZKawgZ70mWaCn3ODaLv51FJgD 4urk3x1++1vzvT5tgKebHR4ODCPrb7YogbNC2Q46NRyV+/UF3a7YnszVZpyOL5lmWNXS X7XEKzKxOVTTqj14V00rDMExkokgS6SF7w1U9iXR87O9ZEDnU/Y3q9w7KXJ4Xnx+aLWs RwXTEci2N5cJpDjQkPP8KYhyuZBf/F/EMFkobLdlriA2CyEB1qdTU3G5hCvcV684+5w3 hrkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706653897; x=1707258697; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ECqTk6JdLhPqEuF+gqbHuPllH2Ar6STQZ5WqRAyuG+o=; b=e7uNBf4RAqB0n9wio/Gwy9T+sZvdH9unRM97YfPjjo+MqRCOAr6PplMtkkCJYYfJaq z9AHcwXtonHhSYnWXb6XjyyV02r4rWfn3HW0LUX0bYavpGvVKxjjUppzOY3zmNYmJdBu kbxzLyBplmEVeih7cp/vrqvYD/7udNxAzKA24Dcx72WZhOm6LWlMsPlFYJ10WjEswDzl +LcsvapRACjzCfUn5z4e2MpGnyWKNBQDh0CReKvOW5S7eE6tJ8bZOwMxMvQPqXL2JC8J hYVOHHkns+g3HWAxOlaudQK63NJJG52/POtbNTwNx4SAE90kM6+V59jM8T2wJJZ4zD5+ QjzA==
X-Gm-Message-State: AOJu0Yz5hizgcm6m8S2fN/cKUxlHNxrpB4ugecMqL9OUkaibffTTOvJI JertnWBvIWWO3I29nTde3/IF1KgXUGzn1Bm0CpvRZi44xogMCTC7CagJsgUI
X-Google-Smtp-Source: AGHT+IEL6xmPDGiJidSMVAJFCl/uJMzm4IXgSF76Tv12GN4yu56DQ8b5POkXTEi2hn09e2N7chdH4w==
X-Received: by 2002:a17:90a:71c2:b0:290:38ff:b1eb with SMTP id m2-20020a17090a71c200b0029038ffb1ebmr2648060pjs.27.1706653896872; Tue, 30 Jan 2024 14:31:36 -0800 (PST)
Received: from smtpclient.apple (c-73-158-206-100.hsd1.ca.comcast.net. [73.158.206.100]) by smtp.gmail.com with ESMTPSA id g3-20020a17090adac300b0028b845f2890sm11001933pjx.33.2024.01.30.14.31.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jan 2024 14:31:36 -0800 (PST)
Sender: Tony Li <tony1athome@gmail.com>
From: Tony Li <tony.li@tony.li>
Message-Id: <E60336B6-4822-4D50-BB08-51115C6D39FB@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_668A93FD-5CC5-4FF6-B506-DBAD2B68A3A6"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
Date: Tue, 30 Jan 2024 14:31:25 -0800
In-Reply-To: <AS4PR07MB85364AE94370590C0CAD5EFCEB7E2@AS4PR07MB8536.eurprd07.prod.outlook.com>
Cc: "mpls@ietf.org" <mpls@ietf.org>
To: "Matthew Bocci (Nokia)" <matthew.bocci=40nokia.com@dmarc.ietf.org>
References: <170654742773.48538.2384224719161088763@ietfa.amsl.com> <AS4PR07MB85364AE94370590C0CAD5EFCEB7E2@AS4PR07MB8536.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3774.200.91.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/2Sy_BnyBQ1tdaDbtZnzqvq3o-WI>
Subject: Re: [mpls] I-D Action: draft-ietf-mpls-mna-requirements-09.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jan 2024 22:31:42 -0000

[co-chair hat: OFF]

Hi Matthew, co-authors,

Thank you very much for these revisions.  I have a few comments: 


>  
>      Requirement 53 in section 3.5 (Requirements on Ancillary Data) seems to
>      prohibit an intermediate LSR which is pushing on labels and NAI from
>      pushing on ancillary data along with them. Such a prohibition seems to
>      be a contradict the WG agreements. Please fix.
>  
>  
> Proposed resolution> Reword and split into the following:
>  
> - In-stack ancillary data MUST only be inserted in conjunction with pushing one or more labels
> onto the top of stack. 


I have a concern about this.  Suppose a node wishes to add an action to an existing label stack and there are
already NAS on the stack.  This would prevent the node from adding the action.  An example of this might be a
transit node that wants to add an entropy action because it is the start of an ECMP path.


> - Processing of ancillary data below a swapped label MAY include rewriting the ancillary data.
> A solution to a use case that needs to change the size of the
> ancillary data MUST analyze the implications on packet forwarding and specify how these are addressed..


I’m not following this text. The first sentence is fine. I’m not sure what a “solution to a use case” is. It really seems like
this is a requirement on the specific action.


>   In requirement 22 (apparently related to requirement 21) what does "in the
>   way the imposing node intends" mean?   The text seems more specific than just
>   understanding the operation to be performed.
>  
>  
> Proposal resolution>
>  
>   22.  An NAI MUST NOT be imposed for delivery to a node
>         unless it is known that the processing node can process the NAI correctly.


This is simply not tractable. How does anyone know (including the implementation's authors) whether an implementation is bug free?
Correctness is a bar that is far too high.

Suggested rewording:

	An NAI MUST NOT be imposed for delivery to a node unless it is
        known that the node supports processing the NAI.

Thanks,
Tony