Re: [Int-dir] Intdir telechat review of draft-ietf-tvr-use-cases-05

Yingzhen Qu <yingzhen.ietf@gmail.com> Sat, 24 February 2024 23:58 UTC

Return-Path: <yingzhen.ietf@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 46B31C14F696; Sat, 24 Feb 2024 15:58:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 WxgXWXN3SOkr; Sat, 24 Feb 2024 15:58:51 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 443B7C14F697; Sat, 24 Feb 2024 15:58:51 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2d27fef509eso7730121fa.3; Sat, 24 Feb 2024 15:58:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708819129; x=1709423929; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=L5RCgQ4jrdD5H1a0PMWub/QrXJA1j4Lz+mNeb2vqjo4=; b=CLH/jvPxPOy54FXJyLwBwFXW3q1TbGI4t7smcSlJxUJaKTXfvm9Bt1rVriAMErKl+v xiKPO5oKdw1MvVhLCCStW7EQ7YYf1p3WbRRmojMf/QzBvJy8OzE0CV5MX9VwT41mZgsS eyjrgc+c8+NrSwEAj2oWtRC9SgtbNelxob9p4fbWCUju7nguJomH6W2eruOPeNylIJaU UZdJDrJTsns93UojpMPo7AhEdvhU6rpBWhvdXPj1SZK8+mAzz6Uk/kjAJhsmL0egrrPp JFNW8Sbgh/TcnFrkMP/wb5go6ccov2MIvSR8M0ZKLO/Onc2CGS7iYFfEN9iHpUjiMKg5 uL8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708819129; x=1709423929; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=L5RCgQ4jrdD5H1a0PMWub/QrXJA1j4Lz+mNeb2vqjo4=; b=N5lAicmweAcohe92fHeqjv2f/WKhjCsJQnLilJ2hbbjxJNNNmjjs9CZGUStEoHapN3 +SjLFO7aexzs6kVq0zLD3sNKcRpEam6OsBxHzbyPBHy66b0ToSaKPqLU6JrX4YwUO5Qg dYlD2nIVoMKXNnI8Sx419PMqAGKq60XxvogZFts0MCuhv6nCFcJ5uV/9cCaQGHEXfa1y 9SuGXCUQs7VhkFw6ZWSEbVPiCis0MLm5rKFfcOelogyaowALKmQuka9/mDFEwzq6jvXl d4NtipZ8GCE85EguWiotOYZ3VOVblDUf7aBzejfgQkgonJuv0K8Kq4kBF5F8o+aq9/+k bFmA==
X-Forwarded-Encrypted: i=1; AJvYcCU3iXmZet/ONwqRiY8C1VVIbAzw76Wr09iEJ82mHMN/IgWsY8Vsb0sAqSOdh0548TQcwluAydtZEQgdxyGniMXOi6WM3TNTcUWrp9+J6OuGzD80W2m3c8mP8iUBOy/wzxxzTBUqHIjU8afbujstS1AIt9/8WuMezg==
X-Gm-Message-State: AOJu0Yy4s+jjQp0cdiE9jEIT8YJshkUbotaNfniEhy0R+6nY1NwWraDY +LlLTbJJRdx/XFfgahOyV/hwDS8Uo0uHjkBAz60gFEqWrN55E8hnKvYHmY81HZ2ZLKi+x+DHkz1 xYJHLFx6Bl2iHjukhQnS1EwQcgrgrd09b7A==
X-Google-Smtp-Source: AGHT+IHy10F7/zSYiw+UPNCyz6qItbXbSEgIeVvJt0Tx3k36fJL9uNneQyUyH49IrFjos1KHPiHoRvmHy0J5YluS18A=
X-Received: by 2002:a2e:7409:0:b0:2d2:7947:37fa with SMTP id p9-20020a2e7409000000b002d2794737famr1680647ljc.0.1708819129154; Sat, 24 Feb 2024 15:58:49 -0800 (PST)
MIME-Version: 1.0
References: <170853383105.39522.5835956175511005021@ietfa.amsl.com>
In-Reply-To: <170853383105.39522.5835956175511005021@ietfa.amsl.com>
From: Yingzhen Qu <yingzhen.ietf@gmail.com>
Date: Sat, 24 Feb 2024 15:58:37 -0800
Message-ID: <CABY-gON_VvuqtS6=RT99_OytttnC+ExgjwjH4QzBRmD0kymJ9Q@mail.gmail.com>
To: Pascal Thubert <pascal.thubert@gmail.com>
Cc: int-dir@ietf.org, draft-ietf-tvr-use-cases.all@ietf.org, last-call@ietf.org, tvr@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002dbf220612297555"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/Vliama7WTkxRYKjk0vmuQ-utC0g>
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: Sat, 24 Feb 2024 23:58:55 -0000

Hi Pascal,

Thanks for the review and comments. Please see my answers below.

Thanks,
Yingzhen

On Wed, Feb 21, 2024 at 8:43 AM Pascal Thubert via Datatracker <
noreply@ietf.org> wrote:

> Reviewer: 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/
> <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
>
>