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

From: Theresa Enghardt <[email-masked]>
Date: Thu, 11 Mar 2021 09:12:11 -0800

(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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 11 Mar 2021 17:20:55 -0600

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 <[email-masked]>
wrote:

> section? ->
> https://tools.ietf.org/html/draft-irtf-panrg-path-properties-02#section-3.1
>
>
>
> _______________________________________________
> Panrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/panrg
>

---

From: Zheng Shaowen <[email-masked]>
Date: Sun, 14 Mar 2021 09:18:20 +0000

Dear Theresa,

Thanks for your questions and comments,

For Q1, to my understanding, ISTN can be regarded as a use case of path selection, and protocol selection, because the protocol stacks currently used in this heterogeneous network are different. Or you can take ISTN as a specific scenario.

For Q2, 3, 4 about the path and path elements, I also confused a lot about the definition of the path, so I refereed to the RFC 5137. What in my mind is that,due to the time various topology of Space networks, it is possible that there is no entire path which is available  (and that is why the DTN store the data first).

Since periodicity of space can be used to derive the future link, therefore, I agree with the idea to stretch the path to "the path exists even though a packet cannot be transmitted over it right now, but it will become available again soon". Then, for a large scale networks, a more abstract path elements which is easier to implement is needed.

But providing a fine granular path elements/properties also has pros. A fine granular path elements can provide a more flexible networking and is helpful to do the failure location and recovery.  It is a great idea to have sub-path, and would it be possible that each sub-path is able to have different path elements and path properties?  Is it possible to provide an abstract path element while ensuring the flexibility of the network by allowing each sub-path to have different path elements and path attributes?

looking forward to hearing from you!

Zheng Shaowen

发件人: Theresa Enghardt<mailto:[email-masked]>
发送时间: 2021年3月12日 01:12
收件人: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: [PANRG] Feedback on draft-zheng-panrg-path-properties-istn-00

Dear draft authors,

Best,
Theresa

---

From: Zheng Shaowen <[email-masked]>
Date: Sun, 14 Mar 2021 09:20:57 +0000

Dear Spencer,

Thanks for pointing the issues out,  ATSSS_ph2 is about the procedures to support multi-access PDU session over the 3GPP and  non-3GPP accesses(e.g. satellite access), and it can be a good reference. And there are several related ongoing work item in 3GPP can be referred to as well, for example 5GSAT_ARCH.

This draft focus on the requirements and key issues on the TCP/IP and is a good complimentary of 3GPP’s work.

Thanks~

Zheng Shaowen

发件人: Spencer Dawkins at IETF<mailto:[email-masked]>
发送时间: 2021年3月12日 07:21
收件人: Theresa Enghardt<mailto:[email-masked]>
抄送: Peng Liu<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: [PANRG] Feedback on draft-zheng-panrg-path-properties-istn-00

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 <[email-masked]<mailto:[email-masked]>> 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,

Best,
Theresa

_______________________________________________
Panrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/panrg

---

From: Theresa Enghardt <[email-masked]>
Date: Wed, 17 Mar 2021 08:12:52 -0700

Dear Zheng Shaowen,

On 3/14/21 1:18 AM, Zheng Shaowen wrote:
>
> For Q1, to my understanding, ISTN can be regarded as a use case of 
> path selection, and protocol selection, because the protocol stacks 
> currently used in this heterogeneous network are different. Or you can 
> take ISTN as a specific scenario.
>
I see, thanks for clarifying. Just curious, what kinds of different 
protocol stacks are these, and are they selected by the end hosts or by 
path elements along the path or both?

> For Q2, 3, 4 about the path and path elements, I also confused a lot 
> about the definition of the path, so I refereed to the RFC 5137. What 
> in my mind is that,due to the time various topology of Space networks, 
> it is possible that there is no entire path which is available  (and 
> that is why the DTN store the data first).
>
> Since periodicity of space can be used to derive the future link, 
> therefore, I agree with the idea to stretch the path to "the path 
> exists even though a packet cannot be transmitted over it right now, 
> but it will become available again soon". Then, for a large scale 
> networks, a more abstract path elements which is easier to implement 
> is needed.
>
> But providing a fine granular path elements/properties also has pros. 
> A fine granular path elements can provide a more flexible networking 
> and is helpful to do the failure location and recovery.  It is a great 
> idea to have sub-path, and would it be possible that each sub-path is 
> able to have different path elements and path properties?  Is it 
> possible to provide an abstract path element while ensuring the 
> flexibility of the network by allowing each sub-path to have different 
> path elements and path attributes?
>
Yes to both questions.

The path properties draft defines a subpath as a sequence of adjacent 
path elements, and each of them can have their own properties. And the 
entire subpath can also have its own properties.

I would say it's also possible for one entity to use a granular path 
model with all individual path elements, while another entity considers 
the same path with more abstract entities. Then, the first entity could 
measure path properties for a subpath, and expose these properties for a 
corresponding more abstract path element to the second entity.

Best,
Theresa

> *发件人: *Theresa Enghardt <mailto:[email-masked]>
> *发送时间: *2021年3月12日01:12
> *收件人: [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> *抄送: [email-masked] <mailto:[email-masked]>
> *主题: *[PANRG] Feedback on draft-zheng-panrg-path-properties-istn-00
>