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

Tony Li <tony.li@tony.li> Thu, 01 February 2024 18:11 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 553F6C14F6E9 for <mpls@ietfa.amsl.com>; Thu, 1 Feb 2024 10:11:11 -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 nl3Ts2t-Nev6 for <mpls@ietfa.amsl.com>; Thu, 1 Feb 2024 10:11:09 -0800 (PST)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 18CBDC14EB17 for <mpls@ietf.org>; Thu, 1 Feb 2024 10:11:07 -0800 (PST)
Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1d7431e702dso10900815ad.1 for <mpls@ietf.org>; Thu, 01 Feb 2024 10:11:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706811066; x=1707415866; 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=aj/s6dpZkgPiZ5Mx331nVBXTdy39x1A9Zs5fj4T7PxU=; b=N6Adf3JwKr8ueje/UXVmfLYpRaG3Z6xWtHO8F65GnPS15ZiiekRBzdbbc/FmyIS+7T txqo0LPmQWtMebc/ZVXzU4tU/AWjFMzu3KlGxwxvbrUp2fPUwgd7iU7XS0wEL3auTMPh uks849CKeRze1Psn+lmitCrPCR9vxLBd73ZLhl3Rgxz+hTnZmMwkXX3k5UHhzlqjeU3M aXaOI1OcNDrtrGyeZKSLNDDLKXvNjnoxm0aHE87Ek3Nwk/LHRGkRDXGx9jWsUnYKWVJk 7QsdqDvkX8UUy2GWnjNnqqM6gub7xMFfswuScTsGDFrWs6bSd2zZZLMcPa+K68ujHzxJ yqcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706811066; x=1707415866; 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=aj/s6dpZkgPiZ5Mx331nVBXTdy39x1A9Zs5fj4T7PxU=; b=BL9WKp67md2dClIf1frXR7i91oRNCeWsLXqg9KcvzI1m4zuMOzYsKTkNfg4lgDKjtQ hI3P+egowZU3AqLNKZX4vHOQei3CBS0HimQ59eSTfK/iOPEd4LY5OSzsc/Ob0mfqa8zC /KcVXfe0SZvbesQlbzUCNq9nSIJOhyZIbkIbv3NoPkoL8scTYNqsYVfqukrMe6uR7Bqe y9knihbo6REVK65NTAyW+1EizO1j2aogA/AkEDCBVLqR6NffQFmiuJP5JuO7vkMGpSHW aCPeZveLfYUql7yD6Et5UMFrs6/CpokUYLEt4TfnCe6jwMipZYHjlvCpk8RG0FUGMSru iQXQ==
X-Gm-Message-State: AOJu0YzMUhfSOR/Voes0d88UiUm9ycrSikPz+SmKo1cfe0L7CJKl+UWR 4pY20OsDvtfDDADy0rAsD+SxCTCQI2aM0g19FZx4PZciLahxExbuV8JC6xLx
X-Google-Smtp-Source: AGHT+IEE+HEAoSXzbDcH6tZo8tIl5J8ytkq9O6T5azpWebuTV4c9o7QI8HNtc4RdVn2GTCVfj4y9Tw==
X-Received: by 2002:a17:902:e748:b0:1d9:61ef:187e with SMTP id p8-20020a170902e74800b001d961ef187emr1493816plf.23.1706811066179; Thu, 01 Feb 2024 10:11:06 -0800 (PST)
X-Forwarded-Encrypted: i=0; AJvYcCUnpPwx73a+CXyrmLWLHol7tTYqjAIbG0YHTy0wvV8EzrupQJgqYLbt74Qbaqb9Eaku53Bo3RqXqls2psK8
Received: from smtpclient.apple (c-73-158-206-100.hsd1.ca.comcast.net. [73.158.206.100]) by smtp.gmail.com with ESMTPSA id g18-20020a170902c99200b001d91b617718sm126833plc.98.2024.02.01.10.11.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Feb 2024 10:11:05 -0800 (PST)
Sender: Tony Li <tony1athome@gmail.com>
From: Tony Li <tony.li@tony.li>
Message-Id: <4DB69B2D-2445-4644-9271-454518DDA0CA@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A5023B42-CFA6-461A-A506-6F44DDD9AA65"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Date: Thu, 01 Feb 2024 10:10:54 -0800
In-Reply-To: <VI1PR0702MB356748A64BC77ED9F7FEC74AEB432@VI1PR0702MB3567.eurprd07.prod.outlook.com>
Cc: "Matthew Bocci (Nokia)" <matthew.bocci=40nokia.com@dmarc.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
To: "Matthew Bocci (Nokia)" <matthew.bocci@nokia.com>
References: <170654742773.48538.2384224719161088763@ietfa.amsl.com> <AS4PR07MB85364AE94370590C0CAD5EFCEB7E2@AS4PR07MB8536.eurprd07.prod.outlook.com> <E60336B6-4822-4D50-BB08-51115C6D39FB@tony.li> <VI1PR0702MB356748A64BC77ED9F7FEC74AEB432@VI1PR0702MB3567.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3774.400.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/KgDqMT9q8DlLcq4luNjJ9JyL91Y>
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: Thu, 01 Feb 2024 18:11:11 -0000

Hi Matthew,

>      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.
>  
> MB> Is this a swap of the top label (or a pop and forward in the case of SR)? Or do you mean pushing a new top label for that downstream ECMP path? If the former, then I think that is contradictory to 3031 because we are inserting something below the forwarding label. At very least it is rewriting the NAS. If the latter, I don’t think that is precluded.


As currently worded, you have precluded just rewriting the NAS.  You are insisting that additional labels be pushed. I’m not sure why, but I certainly don’t understand the rationale. This seems much more restrictive than the language in -08.

Tony