IETF Logo Mail Archive

Re: [Teas] A suspected issue was found in the TE tunnel draft and a small comment about path computation policy

Tarek Saad <tsaad.net@gmail.com> Fri, 12 January 2024 15:02 UTC

Return-Path: <tsaad.net@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73754C151068; Fri, 12 Jan 2024 07:02:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_RATIO_08=0.001, 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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 3BGSFyuz68Yb; Fri, 12 Jan 2024 07:02:45 -0800 (PST)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 124A6C151061; Fri, 12 Jan 2024 07:02:45 -0800 (PST)
Received: by mail-io1-xd2d.google.com with SMTP id ca18e2360f4ac-7bf2a592ba3so7198639f.1; Fri, 12 Jan 2024 07:02:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705071764; x=1705676564; darn=ietf.org; h=mime-version:content-language:accept-language:in-reply-to :references:message-id:date:thread-index:thread-topic:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=moYjF2Wd3hVyR6j57eIN5A903ejbPaSedOT1HRPkkG8=; b=IIeTJF7823kSQDJLx+9cS7FD2lvb38f4Gp1QTGSE+kypgVoqaP2Uc8bgfeqgyHJZ+n aiKgvZa7h3sJthpNahE3Nvdag/hI7BZ29GyFz5GjckQBKOhcP1N7PopAT1nTZIIgw/3F QGyKoIX9I4NWitGJr3Z84BniHeLxUMMpJHsQfcnbgaou2/Co2CU0V9NPW/3vXe4LL2dQ 03H+PNpgyhn4gnrn25blZh4UxBjmZfCvj6m3whw0PC+k4o/6cnqUmuzSiS09rwIytsJU e0hQXMrcatpXb46s2dzVBup3MIrIz41NKrD+004ha1lZduvPXxoXmIE7QDHOwWvI1DJL 3kKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705071764; x=1705676564; h=mime-version:content-language:accept-language:in-reply-to :references:message-id:date:thread-index:thread-topic:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=moYjF2Wd3hVyR6j57eIN5A903ejbPaSedOT1HRPkkG8=; b=GP3iDP1aOYoJ4nr5U4/jc8xiX5+USqbnxVh3+MHb6bBiTLye+SgUgH3pes/h2UmBqv IsieffunEzdmk1PV0Egjrp0lrGiUjPQZZ7fZTwPUcgIShDN8xzbXzvflwM2KAHcwKlVC V9eU3qdlfxaiOooaiNDsd1mKPSm6XmUgdoT4Cvih049YzsIraMiLbeexRY/g6tj+kEMZ ceTD1RPFdAHKs3XT33mLDV5e254l/V6HElzpXxnUZEjYqjiCyumaESFaQl6n+0DNVYbn bdXIO0C2FCR2W90syGsoWS6j0WBXQBSwqGYCATXJKEsoEsXp8SqAoXCncxr6H+h6ZKnX untQ==
X-Gm-Message-State: AOJu0Yxfleh/5FNFhzQSTWC53TMqt0S5Gzc8OmwiQOy1cQrHWB5lW4xn bomPLRZqG0AB6ZMekfVgFvJig2KpJrlSPw==
X-Google-Smtp-Source: AGHT+IE2/RzT8BWmB/8XuoMtB47qjlLQPBcxvtxwN5CRP/HYKky+n8DLUQXS1T6P1lFleDF0o30faw==
X-Received: by 2002:a05:6602:3fc8:b0:7bf:806:182b with SMTP id fc8-20020a0566023fc800b007bf0806182bmr1743013iob.42.1705071764144; Fri, 12 Jan 2024 07:02:44 -0800 (PST)
Received: from DS0PR19MB6501.namprd19.prod.outlook.com ([2603:1036:5:f::5]) by smtp.gmail.com with ESMTPSA id hr21-20020a056638701500b0046e29fcd2adsm922648jab.160.2024.01.12.07.02.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jan 2024 07:02:43 -0800 (PST)
From: Tarek Saad <tsaad.net@gmail.com>
To: yuchaode <yuchaode=40huawei.com@dmarc.ietf.org>, "teas@ietf.org" <teas@ietf.org>, TEAS WG Chairs <teas-chairs@ietf.org>
Thread-Topic: A suspected issue was found in the TE tunnel draft and a small comment about path computation policy
Thread-Index: AdoppWQbunZDau86SviSra2x8PgtKAFx7XQS
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Fri, 12 Jan 2024 15:02:42 +0000
Message-ID: <IA1PR19MB649830D5F948A055BCB369E0FC93A@IA1PR19MB6498.namprd19.prod.outlook.com>
References: <7ffca8743da44f0890ac84a0e9c25008@huawei.com>
In-Reply-To: <7ffca8743da44f0890ac84a0e9c25008@huawei.com>
Accept-Language: en-US
Content-Language: en-CA
X-MS-Has-Attach: yes
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/related; boundary="_004_IA1PR19MB649830D5F948A055BCB369E0FC93AIA1PR19MB6498namp_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/7VOKe8iRg8fsku_jToHOXFQ86Uw>
Subject: Re: [Teas] A suspected issue was found in the TE tunnel draft and a small comment about path computation policy
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jan 2024 15:02:50 -0000

 Hi yuchaode,

Thank you for your review and comments. Please note, we have uploaded rev 35<https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-te-35> of the draft which may address some of the concerns you raise. Please see inline indexed by [TS].


From: Teas <teas-bounces@ietf.org> on behalf of yuchaode <yuchaode=40huawei.com@dmarc.ietf.org>
Date: Friday, December 8, 2023 at 2:19 AM
To: teas@ietf.org <teas@ietf.org>, TEAS WG Chairs <teas-chairs@ietf.org>
Subject: [Teas] A suspected issue was found in the TE tunnel draft and a small comment about path computation policy
Hi TEAS Working Group,

I found a suspected issue in the latest version of TE Tunnel draft by accident. Please the authors have a look.
It seems like that the previous “p2p-primary-paths” container was renamed into “primary-paths”.
But in the example of session 12.5(https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-te-34#section-12.5-2), the URL still points to “p2p-primary-paths” structure while the response is using “primary-path” structure. Just like the screenshot shows:
[cid:image001.png@01DA29E6.4EDFFD10]
I think the authors probably missed to change the URL. Please the authors check!
[TS]: thanks for pointing it out. This was corrected in the latest revision.

This issue was found when I was doing some research on the path computation policy. I am using an old version, and I was trying to find the “p2p-primary-paths” and then found there was only one case matched.
And I noticed that this “p2p-primary-path” structure was renamed by some previous versions. This is an accidental discovery and does not intentionally delay the release of TE tunnels.

BTW, I found that all the primary & secondary paths and their reverse paths can support to specify different path computation policy. This capability is great.
But what I met is people only wanted to specify a unified path computation policy for all the paths.

So is it possible to specify the path computation policy only in the primary-path, and the other paths use this policy by default if there is no specific policy specified on their paths.

  *   constraints under tunnel apply all paths
  *   override by specifying path specific constraints

If the authors agree with this proposal, can some more description be added in the draft or in the model to make it clear? Thanks!
[TS]: Please note that the model allows specifying some constraints directly under the tunnel (e.g. association-object, bandwidth, etc.). Those are applicable to all paths of the tunnel. However, per path forward/reverse/secondary specific constraints can still be specified for the specific path.

Regards,
Tarek (for the co-authors)

B.R.
Chaode

v2.23.0 | Report a Bug | By Email