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

[Theresa Enghardt <[e-mail]>]

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:[e-mail]>
> *发送时间: *2021年3月12日01:12
> *收件人: *[e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>
> *抄送: *[e-mail] <mailto:[e-mail]>
> *主题: *[PANRG] Feedback on draft-zheng-panrg-path-properties-istn-00
>
> (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
> [e-mail]
> https://www.irtf.org/mailman/listinfo/panrg
>