Re: [Int-dir] Intdir telechat review of draft-ietf-tvr-use-cases-05
Pascal Thubert <pascal.thubert@gmail.com> Fri, 01 March 2024 05:54 UTC
Return-Path: <pascal.thubert@gmail.com>
X-Original-To: int-dir@ietfa.amsl.com
Delivered-To: int-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68482C14F6A8; Thu, 29 Feb 2024 21:54:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.212
X-Spam-Level:
X-Spam-Status: No, score=-6.212 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, 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, URIBL_BLOCKED=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=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 zuVMZO27ev45; Thu, 29 Feb 2024 21:54:29 -0800 (PST)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 DE67BC14F69A; Thu, 29 Feb 2024 21:54:28 -0800 (PST)
Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-412bb23e5c5so9092725e9.1; Thu, 29 Feb 2024 21:54:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709272467; x=1709877267; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=tfC5yXl+9CbThHjE8RdnHYJh33uLZkPVfl1h/L/FP0c=; b=ilf7b4f1oNdNg4Y/2JNpvKA+3b2znznCo/p1tmFMTKEduAQvp0hu8HqlNMgCQiXSjr wfSUzTYv1mPMynS0QnkMVc9n6V7ifaWCn6w5rpJ1yXqLdenAmVT42f1Ni1/l+bjhePlh f/YhzDCok+Z7/2oryOInczBDjeaFXLVG59Rs7kzgBiBuEkourGI2QI83n6cynubSEqcu veXyZIIp9v4MlTw1S8OOTsSHPSN3J78OmHWcUUDryI6ExE8gNtXBwZM4xfmtxVmOrg87 FxLhHj3Xai8nnqq+ToYmUaQKO2Yof1/3MmFqfUCbAlkksK3BJiE0dYZ+BXb6+XLauwLS jY6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709272467; x=1709877267; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tfC5yXl+9CbThHjE8RdnHYJh33uLZkPVfl1h/L/FP0c=; b=tLJoEt7wkZc/DLpS3jH4BSlNiyqdVYMX4wiSFe70Ce1sbwyM2ErybbyvyHAVd4HZge ufT5xEWYrydCemi/fXzRIddTCnQ57UCMjFqXosk7A50QdWmkDIhqkL2l19+j6W9iJrn+ zfiz94dEzjnP67Yrfa2x6hwyaARyt2qPciqvY/NwfhxE8l4XewJzCZ/DjF7lWMX6SwGj G01FetHYCGKSIXJnNsCtpyVRYNqw5gTFUTr5x+oM9Y5GQYvXq5/+PdxdMwFmBJSc+NOZ ol4Ux4ScbLOBip8ooWUPuvP9bn66OhxsYjHrfJMEP3kQ1v/QmdDvQ1q0WMI3VJ76OR9X jJDg==
X-Forwarded-Encrypted: i=1; AJvYcCUzQXY7aC8j4OGLA8kVm7jZZSNrS7Z9xUVYpMSexZsmdbaUgMMAkpIzC540IgfLH7i8QjMieAv5IbvJ0of3CMH0CZoxqXwNeQbEWnOFyPPINBgIhILowot8S8Veco0HH9ynOtoP6KRt6zR3Z73ZSZ3HazLOzG3zdA==
X-Gm-Message-State: AOJu0YzOspfrneGKsrqBdvaFVHUAAMDuFq30RCc/mEi68bldIFDmzecc eC4NvVFX5Z698btGfpT/akHGdwgMe/YB95V2w2BxQkKUKyfn7yxwLPLn8PsRraM=
X-Google-Smtp-Source: AGHT+IHMs8eD697cLsrOnyAWZWA3jao0sqUj2JaF/mEt6t/TEoj1hwvz/BnEccwr4lHLl0iYoMlMdQ==
X-Received: by 2002:adf:e54b:0:b0:33e:1e0e:17c9 with SMTP id z11-20020adfe54b000000b0033e1e0e17c9mr716788wrm.14.1709272466516; Thu, 29 Feb 2024 21:54:26 -0800 (PST)
Received: from smtpclient.apple ([2a09:bac1:27a0:a0::241:33]) by smtp.gmail.com with ESMTPSA id y10-20020adff14a000000b0033e1be7f3d8sm1123157wro.70.2024.02.29.21.54.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Feb 2024 21:54:25 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-32252925-18CF-4DC2-BA9E-ECF1F6D967D1"
Content-Transfer-Encoding: 7bit
From: Pascal Thubert <pascal.thubert@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Fri, 01 Mar 2024 06:54:15 +0100
Message-Id: <4E0B11D6-0FDB-4841-8C7B-7572074A221B@gmail.com>
References: <CABY-gOMv5ONMTjZrNCLzmZRLxr15RH=NQ7Jy-mF7_A0uEz4JAA@mail.gmail.com>
Cc: int-dir@ietf.org, draft-ietf-tvr-use-cases.all@ietf.org, last-call@ietf.org, tvr@ietf.org
In-Reply-To: <CABY-gOMv5ONMTjZrNCLzmZRLxr15RH=NQ7Jy-mF7_A0uEz4JAA@mail.gmail.com>
To: Yingzhen Qu <yingzhen.ietf@gmail.com>
X-Mailer: iPhone Mail (21D61)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/OfqSOx_RC7oSd_3aQ1BA_SOJOK4>
Subject: Re: [Int-dir] Intdir telechat review of draft-ietf-tvr-use-cases-05
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2024 05:54:33 -0000
Le 29 févr. 2024 à 20:17, Yingzhen Qu <yingzhen.ietf@gmail.com> a écrit :
Hi Pascal,Would you please check whether your comments have been addressed?Thanks,YingzhenHi Pascal,Thanks for the review and comments. Please see my answers below.Thanks,YingzhenReviewer: Pascal Thubert
Review result: Ready with Issues
I am an assigned INT directorate reviewer for draft-ietf-tvr-use-cases (05).
These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/" rel="noreferrer nofollow" target="_blank">https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/" rel="noreferrer nofollow" target="_blank">https://datatracker.ietf.org/group/intdir/about/>."
For non-INT Area document, the reviewer must give a recommendation as to how
the INT ADs are to complete the ballot on the document and the reason for that
recommendation.
I believe that the document is very well written and highly readable.
My comments may be seen as a matter of taste and ignored, or/and be considered
out of scope.
My main concern is that despite a "Routing Impacts" subsection in all main
groups of use cases, there's no text on the scope of routing impact.
- Is the impact local like FRR in which case it can be understood?
- Or is it more global in which cases the impact is harder to assess in
advance? - flows may be rerouted paths that are loaded differently from the
original, meaning that there's a measurable impact at the time of the switch,
for the better or the worse - How, when can the impact be gradual? - Is the
impact a complete reroute of the flow or a variation of the load balancing?
Background fo rthe questions: Rick and myself have a strong RAW background.
Contrary to the examples given (and the WG ovbjectives), RAW is reactive (OAM
based); but once a decision is made, it seems that the RAW methods are
applicable in certain listed use cases and may provide a smpooth solution to
the local TVR use cases.
Related comment is that the "Routing Impacts" subsections are not comparable
from one use case to the other. Again I'd have loved comparable items like the
above to be discussed so we figure if we are looking for common or separate
solutions.
[Yingzhen]: As we know, Fast Reroute (FRR) is a local mechanism designed to handle unexpected node or link failures, and there might be policies for determining which traffic should be switched to the backup path. However, this falls outside the scope of TVR's charter and this document. Scheduled maintenance, such as link shutdowns, is within scope. Ultimately, how routing protocols handle these scheduled events is up to the protocols, including deciding whether a 'one size fits all' solution is appropriate. One of the objectives of the use case document is to clarify the cases considered by TVR.Secondary, on :
"To the extent that the relative mobility
between and among nodes in the network can be
understood in advance, the associated loss and
establishment of adjacencies can also be
planned for."
This is clearly discussing radios. Most radios use cases depend not only on the
relative position, but also the rest of the environment that may obstruct and /
or interfere with the signal. Suggestion:
"To the extent that the relative mobility
between and among nodes in the network and the
impacts of the environment on the signal
propagation can be understood in advance, the
associated loss and establishment of
adjacencies can also be planned for."
[Yingzhen]: thanks for the suggested text. I've published version -06 with the suggested changes.Many thanks again for this document, great and informational read
- [Int-dir] Intdir telechat review of draft-ietf-tv… Pascal Thubert via Datatracker
- Re: [Int-dir] Intdir telechat review of draft-iet… Yingzhen Qu
- Re: [Int-dir] Intdir telechat review of draft-iet… Yingzhen Qu
- Re: [Int-dir] Intdir telechat review of draft-iet… Pascal Thubert