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

I wanted to chime in on something completely different ...

I'm glad the authors brought this work to PANRG. I think there's some
overlap on these issues with 3GPP ATSSS_ph2, especially now that Rel-17 is
including satellites as a way of expanding 5G coverage, and it will
surprise no one that I think PANRG is well placed to look at the issues
that will inevitably arise ...

Best,

Spencer

On Thu, Mar 11, 2021 at 11:12 AM Theresa Enghardt <ietf@tenghardt.net>
wrote:

> (Sending this again because the recipients' mailbox rejected my mail to
> the draft authors alias... Apologies if you get this twice.)
>
>
> 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
>
> _______________________________________________
> Panrg mailing list
> Panrg@irtf.org
> https://www.irtf.org/mailman/listinfo/panrg
>