[PANRG] Feedback on draft-zheng-panrg-path-properties-istn-00

Theresa Enghardt <ietf@tenghardt.net> Thu, 11 March 2021 17:09 UTC

Return-Path: <ietf@tenghardt.net>
X-Original-To: panrg@ietfa.amsl.com
Delivered-To: panrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCF33A13E9 for <panrg@ietfa.amsl.com>; Thu, 11 Mar 2021 09:09:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tenghardt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxnYiRSEuIrJ for <panrg@ietfa.amsl.com>; Thu, 11 Mar 2021 09:09:40 -0800 (PST)
Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4070C3A14B2 for <panrg@irtf.org>; Thu, 11 Mar 2021 09:09:33 -0800 (PST)
Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id 3B48DAA; Thu, 11 Mar 2021 18:09:29 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tenghardt.net; s=20170414; t=1615482570; bh=CnpCJTHlprsNI3ShPBa9drCcA9Mpja8tYhxW8+M/yO0=; h=From:Subject:To:Cc:Date:From; b=LvLRsKaE/2uE1QYrfjZJZHfybDkAtbYbuILsbGzDM7mCJ2p+u5Vej7ZdvsQmZTf9g pC1CGVpoULCSS9DD96IPB/VjoYsEhHP+4QJEcMUy9Obh6J7Tuf3uiRMUlTMsnW4WG7 tllB+oSC/W4SmxeYBQ4LSCzufHOQ/2YHO4NANAP+afbV+sKrn1KN2GZHPVZL5rPuPN 6ZKXvZrKjuIIevynxMy6I6bN9veXXFJRaIMhSMBkLGUlnmNOwZiDQPG519rV7bEtZd CTw7nuzH36ZT1/eVUM23Ev4nCbVcqZW+A72iqseiQkEHHmMz4N1uhtGoZocEIWDD7E qFrRojfgLHUbw==
From: Theresa Enghardt <ietf@tenghardt.net>
To: draft-zheng-panrg-path-properties-istn@ietf.org
Cc: "panrg@irtf.org" <panrg@irtf.org>
Message-ID: <fb02b5ba-ce6e-c503-6872-7e50be3a5ba7@tenghardt.net>
Date: Thu, 11 Mar 2021 09:09:27 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/panrg/plIMp6Zo8JywY_Lt9DudgNEhxOk>
Subject: [PANRG] Feedback on draft-zheng-panrg-path-properties-istn-00
X-BeenThere: panrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" <panrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/panrg>, <mailto:panrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/panrg/>
List-Post: <mailto:panrg@irtf.org>
List-Help: <mailto:panrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/panrg>, <mailto:panrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Mar 2021 17:09:44 -0000

Dear draft authors,

Thank you for posting draft-zheng-panrg-path-properties-istn-00 and for 
presenting it at the IETF 110 PANRG session!

I've read the draft and I agree that ISTN is an interesting field for 
path awareness.

A few questions and comments:

1. The abstract says that the use case is "integrated space-terrestrial 
networks". I think it should be more specific: Is the use case path 
selection? Is it (also) something else? For path selection, does the 
definition in Section 3.1 of the Path Properties draft fit your use 
case, or are you missing anything from that 
section? -> https://tools.ietf.org/html/draft-irtf-panrg-path-properties-02#section-3.1


2. In the introduction, the draft defines a path as a series of links 
that connect a series of nodes from the source node to destination, 
referring to RFC 5136. In Section 2, the draft lists path elements 
corresponding to individual nodes and links. I think that's a good 
starting point, but I'm wondering if a more generic definition would 
work better. Then, path elements could be more abstract: Not just a 
single node or link, but also an entire network, for example. This would 
be useful, as the endpoint may not have insight into all path elements, 
and it may be difficult to make every endpoint aware of every single 
path element. So, would it be better to consider more abstract path 
elements here, e.g., consider an entire network as a path element with 
its own properties?


3. The draft considers properties of the entire path and properties of 
each individual path element (node or link). I think it could be helpful 
to consider subpaths as well, for example, the "space part" of a path or 
the "terrestrial part" of a path, or the subpath traversing a specific 
network. Then, a network provider could expose information about this 
subpath, instead of exposing information about every individual path 
element. What do you think?


4. The draft defines availability as a path property, which makes a lot 
of sense to me. In contrast, the Path Properties draft defines a path as 
a "sequence of adjacent path elements over which a packet can be 
transmitted". Does this part of the path definition work for you? I 
think the definition could be stretched to say "the path exists even 
though a packet cannot be transmitted over it right now, but it will 
become available again soon". Do you agree?


Thank you for the draft, and I'm looking forward to hearing more!

Best,
Theresa